これなに
いちアーキテクト兼プログラマ兼インフラエンジニアのサーバレスと付き合うときの特に初回のめんどうくささお気持ち表明。
2023年の中頃の定点観測、AWSの話。
Serverlessの現状
サーバレス・・その最大のメリットといえば何も考えなくても可用性やキャパシティが確保されること。
VPCレスであるため可用性を確保するための面倒な手続きをやらなくてよい、かつその維持のためのコストを払わなくてすむ。
しかも使わなければタダか、それに近いコストになる。
後述のIaCと組み合わせると環境の量産がコスト安く気軽にできるため、いつでもまっさらな邪魔されない環境で検証、機能追加の実験ができる。
デメリットとしてはとっつきにくい、実装や機能上の制約がどこかしらにある、方式を確立するまでPoCなどががめんどくさい。
いろいろなサービスが絡まっている場合はなおのこと。
幸いチュートリアルや事例はたくさんあるので、下記の手順でPoCをやるとスムーズです
まだ出くわしたことがないけれどログがあまりでないのでAWSの障害時にトレースが非常に難しくなるんじゃないかと思う。
そしてその制約は大規模開発の足を引っ張ることになる場合もあるため、まだEC2, ECS, k8sの中で動くプログラムほどの利便性は確保できていないように感じる。
希望的な側面では、サーバレスをカバーするフレームワーク群やIaCが充実してきていて、そこに乗っかれると幸せ、かもしれない。
導入の手順こうするといいんじゃないかな？
- まず最初にチュートリアルどおりにやってみて、動く状態のお手本を手元に確保する
- お手本をもとにインフラ、設定を構築してやりたいようにカスタマイズする。
- カスタマイズした環境でPoCする
- 環境の量産をなんらかのIaC（terraform, CDK, CDKTF）に執筆する。
- IaCで作った環境がworkするようになったらチュートリアル及びお手本環境を削除
- IaCで環境を量産する。prodとかstgとかdevとか
私の持っている駒
下記のどれで執筆するのが妥当かをPoCしながら見極めながら、最終的にどれを使うかを判断していく。
- cdkの実装運用テク
- ↑やってると自然と身につくCloudFormationのtemplate
- cdktfの実装運用テク
- ↑やってると自然と身につくterraform
- たまに落とし穴のようにバグっているところがあるからcdkよりは不完全
- Serverless Fwamework
- Lambda使うとき便利＆CloudFormationのtemplateを埋め込めるのでインフラの執筆も可能、痒いところに手が届くかもしれないプラグインもそこそこ充実
ついでにこれらをgithub actionsでデプロイできるようにして、本番のインフラは絶対にコードの支配下に置くことを徹底する。AWS Consoleで設定をいじることを一切なくす。
自動化していないところ
ただしすべてを自動化はできていない、人間が手で準備ところもある。
ACMとかRoute53のHostedZone作るところとかSecretManagerにクレデンシャルぶちこむところとか。
ドメイン取得〜Route53に登録〜CMで証明書の作成、SecretManagerにCredentialsを自動作成（パスワードの自動ジェネレート）も。
やれるのかもしれないけれど、今はまだ早いかなー
Web3とかDAOのテンプレートみたいなのはもうほぼ自動で作れるようになっていると思う。
という雑感でした。