【AWS Developer Live Showを見た感想】Infrastructure as Code 談義 ~ これってやりすぎ？やらなすぎ ?

はじめに

2/25にAWS公式のyoutubeで配信されたAWS Developer Live ShowのInfrastructure as Code 談義 ~ これってやりすぎ？やらなすぎ ?の内容と感想記事になります。

AWS Developer Live Showとは？

プログラミング・開発の課題に特化したライブセッションをyoutubeで配信してくれるイベントです。
ライブセッション中に質問をすることも可能で、その場で回答したりしてくれます。

会員登録などは不要でライブセッションを見ることが出来ますし、過去のライブセッションもこちらから見ることが出来ます。

今回のライブセッションの内容

以下の4つのトピックについて、これはやらなすぎだと思う、これはやりすぎだと思うということをお話されていました。

• Q1.IaCを書き時始めるタイミングは？
• Q2.IaCは運用のどこまでをカバーすべき？
• Q3.IaCでどのくらいドキュメントを書く？
• Q4.IaCでどのくらいテストを書く？

お話されていた方は以下の4人の方でした。※敬称略

• 高野 賢司 (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト)
• 津郷 光明 (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト)
• 友岡 雅志 (アマゾン ウェブ サービス ジャパン合同会社 プロトタイピングエンジニア)
• 杉本 晋吾 (アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト)

Q1.IaCを書き時始めるタイミングは？

IaCをどのタイミングで導入するのが良いか、という話についてでした。

※画像の黄色の付箋はAWSの方が出した意見で、緑色の付箋は視聴者から寄せられた意見です

アプリ完成後、運用フェーズでIaC化

基本的に作り上げるアプリの要件からインフラ構成図を書いて、アプリ開発しながらインフラを構築していくことになると思います。
なので、運用フェーズでIaC化するのはメリットがほとんどないと思っています。

むしろ、後からIaC化することによる差分発生や、IaC化漏れのリスクが高いと思っています。

しいて言うなら、PoCなど一時的なアプリ開発の場合はIaC化しないで、本開発へ入った時にIaC化するというのはあると思います。

新しいAWSサービスだとIaCが大変・できないことも

これはあるあるですね。
新しいAWSサービスや、既存AWSサービスの新機能のCloudFormationサポートが始まるまでに、数か月かかったりします。

この場合は、

• カスタムリソースで作成
• AWS CLIで手動作成
• マネジメントコンソールで手動作成

のいずれかになるとは思います。

最初はマネジメントコンソールかAWS CLIで作っておくのが個人的には良いと思っています。
また、プロジェクトの期間にもよりますが、運用フェーズ入る時期までにCloudFormationサポートされたりするので、そこでIaC化するか検討するのも手かなと思っています。

マネコンである程度触ってから

今まで触ったことがないAWSサービスの場合は、一度マネジメントコンソールで触ってる見るのが良いと思います。
いきなり、CloudFormationやCDKで作ろうとすると、各パラメータの意味や用途がわからないからです。

その点、マネジメントコンソールだと補足説明が充実していますし、設定項目の全体感が把握できます。

逆に、今まで触ったことがあるサービスは、最初からIaC化したほうが時間効率が良いと思います。

生成AI前提だと初手IaCが有効？

当たり前に生成AIをみなさん使っている現在なので、これは良いと思います。
AWSだとCodeWhisper(Q Developerに統合された)を使うことで、CDKのコードを自動生成することも可能ですし、ChatGPTなど他の生成AIを使うのも良いと思います。

ただ、やはり生成AIだけで完璧に要件通りのものを出来ることは少ないでしょうから、大枠のひな形を生成AIで作成して、そこからアプリケーション独自の設定値を追加・修正していくのが個人的には良いと思っています。

いつでも最初からIaC ※すでに秘伝のタレがある時は

CloudFront + S3、ALB + EC2(or ECS)、API Gateway + Lambda、CI/CDなどよく利用する構成に関しては、最初からIaC化するのが良いと思います。

そこから必要に応じて共通化したい部分は、カスタムコンストラクタを作成し、別プロジェクトで再利用することで開発効率も上がっていくはずです。

Q2.IaCは運用のどこまでをカバーすべき？

運用作業の内、IaCでどこまでカバーするべきか、という話についてでした。

最初だけはIaCドリフトは当たり前 ※Change Management = 変更管理が出来ていればいいかも

これは結構極端な考え方かなとは思いました。
せっかくIaC化したのに、手動変更などでドリフト(IaCとの差分)を発生させるのは、元々のメリットを失わせてしまいます。

また、誰がどこを変更したのかも追いづらくなっていしまいます。Excelなどで変更管理してもいいのですが、書き忘れたなどよく起こりますしね...

なので、緊急対応以外はIaCで変更していくのが良いと思います。

ライフサイクルの長いものはIaC管理から外す

DBを入れる/入れない、の話がありましたが基本的に全てIaC管理にするのが良いと思います。
IaC管理すると、リストアやフェイルオーバーなどが難しくなるとのことでしたが、そもそもこういった作業自体なかなか少ないので...

手動操作は絶対に許さない

以下の場合は、手動操作しても問題ないと思いました。

• CloudFormation化されていないAWSリソース(そもそも手動対応しかできない)
• 本番環境の緊急対応(いちいちIaCを修正している時間がない)

Q3.IaCでどのくらいドキュメントを書く？

IaCについてどこまでドキュメントを残すべきか、という話についてでした。

デプロイコマンドだけ書く

割とこれはよくやってしまっていますが、小規模なら問題なかったりします。
READMEにデプロイコマンドと、AWS CLIコマンドと、簡単な説明だけ書いたりするイメージです。

構成を生成AIで出力させるのもいい

構成図を先に作ってからインフラ構築する場合はdrawioなどで書いていくことになるとは思います。
しかし、時間の都合上などでインフラ構築してから構成図を作りたい場合や、視覚的に構成を書きながらAWS構成を作りたい場合は、Application Composerを利用したりします。
※VsCodeの拡張もあります。

コードを読めばわかることは書かない(二重管理の防止)

基本的にVsCodeなどのIDEを使って、みなさん開発すると思うので各パラメータの説明などはコメントに書かずとも確認出来るので、不要だと思っています。

スタックの分け方や、なぜこのアーキテクチャにしたか、普段と違う設定、などプロジェクト独自の設定や設計思想を書いておくと、別の人への引継ぎもしやすいと思います。

Docも含め全てGitで管理する

パスワードなどの秘密情報以外のドキュメントは全てGit管理したほうが、集中管理されていいと思います。
もちろん、Excelなどで管理したほうが管理しやすいケースもあると思うので、一概には言えませんが...

設計書には設計根拠を書く。コードにコメントも付ける

インフラ構成図で設計意図などを補足として書き、細かい設定に関するコメントについてはCDKなどのコードにコメントを残すのが良いと思っています。

パラメータシートに全部転記する

全てのパラメータ(環境変数など)をパラメータシートに書くと、二重管理する量が多くなります。
なので、パラメータストアやシークレットマネージャーに登録するパスワードなどの秘密情報だけをパラメータシートとしてExcelなどにまとめるのが良いと思っています。

それ以外は、parameter.tsのように1つのファイルにまとめておけば、そこまで管理に困らないはずです

Q4.IaCでどのくらいテストを書く？

IaCのテストコードをどこまで書くべきか、という話についてでした。

デプロイさえ出来ればOK

開発・検証・本番のように複数環境が存在する場合は、これでも問題ないとは思っています。
基本的にデプロイエラーが発生したり、設定に問題が出るのは開発環境だけで、検証・本番では正常に通るものをデプロイするだけだからです。

(CDK)スナップショットテストのみ

私はやってはいないですが、比較的導入は簡単になりますのでやってみるのは良いと思っています。
他にもAssertionテストがあります。

スナップショットテストは、事前に記録されたスナップショット（CloudFormationテンプレート）に対して、テスト実行時の実装から作成したCloudFormationのテンプレートを検証（比較）します。
ここで、差分がなければテスト結果OK、差分があればテスト結果NG となります。

E2E(エンドツーエンド)テストまでデプロイの中で書く

ユーザーの実際の利用環境に基づき、システムが正しく動作するか・データフローが適切に機能するかどうかを、システム全体を通して検証するテストです。
やったことがないので特に感想はありませんが、それなりに実行コストはかかるようです。
TerraformのE2Eテスト

(CDK)コミットごとにインテグレーションテスト(integ-runner)で担保

CDKでインテグレーションテストをするモジュールです。使ったことはないので感想はありませんが、サーバーレスのAPIを構築している場合などに役立ちそうです。
AWS CDK アプリケーションのためのインテグレーションテストの作成と実行

AWS触ったことがない人に、いきなりIaCは無理だと思うけど、いつからIaCをやるといいのか、の解がない

これは難しいですね...何もAWSサービスを知らない人にいきなり、IaCを書いてと言われても難しいとは思っています。
CDKであれば、普段開発している言語で構築できるので実装自体に抵抗は少ないと思います。

なのでSAAなどの資格で基本的なAWSサービスの機能を把握したら、チャレンジしてみるのが一番いいかなとは思います。

おわりに

今回は、AWS Developer Live Showの感想記事を紹介しました。
こういうワイガヤてきな内容って、いろんな意見が出て面白いですよね