この記事は AWS Amplify Advent Calendar 2020 14日目の投稿です。
突然ですが、私は非エンジニアです。Amplify Console は実際に実務で使っている立場（マーケター）になります。エンジニアの人たちに混じって、Amplify Console について何を書こうか迷った末、実際に使ってる中での感じたこととかなど開発の Tips ではなく運用にまつわることに触れ、簡単に共有できたらと思います。
はじめに… Jamstackとは？
Jamstack is an architecture designed to make the web faster, more secure, and easier to scale. It builds on many of the tools and workflows which developers love, and which bring maximum productivity.
Jamstack は、Web をより速く、より安全に、そしてより簡単に拡張できるように設計されたアーキテクチャです。これは、開発者が愛用し、最大の生産性をもたらす多くのツールとワークフローに基づいて構築されています。
Jamstack の公式サイトに書かれているように、Web をより早く・安全に・簡単に拡張できるように設計されたアーキテクチャです。
実際にベーシックな Jamstack な Web 開発のシンプルな構成についていくつかチュートリアルを体験しました。一部紹介します。このチュートリアルは Jamstack な構成や ヘッドレスCMS ってなんなのかが大体の仕組みが体で理解できるものなので、非エンジニアやこれから初めてみようという方にもおすすめです。
Gridsome を使った Jamstack 構成
Using Gridsome and AWS Amplify Console with Shifter Headless WordPress
Gatsby を使った Jamstack 構成
Using Gatsby and AWS Amplify Console with Shifter Headless WordPress
ヘッドレスCMS の部分は WordPress の HeadlessCMS（Shifter Headless）を主としてこのようなチュートリアルを何本も行いました。
ホスティングの部分は構成（SPA, SSR）によって Amplify Console だけではなく Netlify や Ionic、Vercel など様々なサービスを体験しました。
その中で感じたこととしては、Amplify Console は AWS ユーザーにとって 使いやすいものだなと思いました。が、チュートリアルや試すことはあくまでも学習の一つ。やはり、どのサービスも結局のところ実際運用になったらどうなんだろう？なところが正直な感想です。私は、運用で使う立場なのでどうしたって実運用のことは考えてしまいます。実運用で使う話の前に、紹介したこれらの構成が何に適しているのかおさらいすることにします。
ヘッドレスCMS を実運用で役に立つポイントとは？
1. 柔軟な UI/UX デザインのサイト開発・実装が可能
- フロントエンド開発が行えるため、多彩な開発手法の選択ができる。
- 自由度の高いデザインを構築することができる。
- マルチデバイス管理ができる。
2. マルチサイト管理が可能
- 1レコード（データソース）として取り扱いができる。
- 同じコンテンツデータソースを複数サイトに表示させることができる。
3. コンテンツをモジュール化してサイトに組み込むことが可能
それでは、実際に私が現時点で活用していることについて触れたいと思います。
更新時は Amplify Console で Redeproy
ヘッドレスCMS で記事を投稿し、Amplify Console の一部機能が触れる IAM を発行してもらって、デプロイを行っています。
記事側の Publish が終わると、Amplify Console に入らなくとも自動デプロイはできるのですが、現時点では Amplify Console に入り、公開作業を行っています。また、Amplify Console 側で誰かがビルドする際は、Backlog 側に通知が入ってきます。サイトに関するアプリは、master と staging があり、両方ともにデプロイが走ると通知がくるので何か問題があった場合はこの通知を利用して社内共有を行い、解決に進めていきます。
運用してみて個人的に感じたこと
どこでこけたのかわかることが嬉しい
大体こける時は、ビルドでこけます。その時は、Amplify Console のビルドログをチェックしてどこでこけてるのかチェックして、社内の人に相談します。ログを見れるようにすることは、運用する立場の人もみれた方がいいなぁと個人的には思います。非エンジニアでも見てるとなぜか慣れてきますので、運用者は怖がらずにログを見ることをおすすめします。
大体こけるのは Gatsby 側の取得？！
Gatsby 側と噛み合ってないと大体こけるだなぁという所感。何がどう噛み合ってないのかは、残念ながらなんとなくでしか私はわからないのですが、それでも Amplify 側ではなく Gatsby 側をみてチューニングをしないといけないことはわかります。直し方はさておきですが。このあたりで調査がスムーズに行ったり行かなかったり、、、新しい技術なだけにとにかくエンジニアに助けてもらわないとどうにもならないことはわかりました。
社内コミュニケーション/チームワークが必須
関わる人たちがどんな構成でどんなことをしているのか把握していないと問題究明には時間がかかります。どんなシステムでも同じではありますが、完全に分業しているからこそ、スタートの開発構想段階からチームみんなが構成をわかってないとスムーズな運用は成り立たないと思います。
当たり前のことですが、いろいろなサービスを絡めて使うことは、問題の切り分けや問題が起きた時にどうするかの判断をすることが重要だと思いました。そのためにもチームが何をしているのか、運用している側の目線でどこまでチームに伝えることができるのか、チームと足並みや目線を揃えているか、など一人で作って運用しない限りはJamstack な構成で Web サイトやアプリケーションを運用する場合は「チームで運用する」ことの重要なポイントですね。
次はヘッドレスコマースに挑戦しようかと思います！奮闘はまだまだ続く、、、