AWS Summit Japan 2024 Day1の「大規模クラウドインフラ設計・構築案件の歩き方」のセッションについてレポートです。
控えめに言っても満足度の高いセッションでした。
大規模なクラウドインフラの設計構築運用に関わる方なら首がもげるくらい頷きが多い内容であり、アーカイブが公開された際はもう一度見たいと思うほど…。
セッションの内容には「設計書の一覧サンプル」や、「アプリ/インフラチームの責任分界」といった界隈でも関心が高い内容に触れられています。
考え方のひとつとして参考にしていきたい内容がモリモリでしたので、シェアさせていただきます。
セッション概要
大規模クラウドインフラ設計・構築案件の歩き方
- Level 300: 中級者向け
- スピーカー: アマゾン ウェブ サービス ジャパン合同会社 仲谷 岳志 様
クラウド技術のコモディティ化により、エンタープライズ分野では近年、AWS 上での大規模なアプリケーション開発が一般的になりつつあります。これを支えるクラウドインフラ設計についても、求められる非機能要件の高度化と関連する AWS サービスの多様化に伴って、多人数でのチーム設計やアプリケーションチームとの効果的な連携が求められることが増えてきました。 本セッションでは、AWS Professional Services の豊富な実績を元に、クラウドインフラの設計・構築およびテストを円滑に進める上での実践的知見をご紹介します。
アジェンダ
セッションは下記の8項目について解説をされていました。
- 設計
- 設計の骨組みづくり
- アプリ/インフラチームの責任分界
- コーディングルール
- 静的解析
- 構築
- コスト管理は今すぐ始める
- クリティカルパスの特定
- 展開手順の整備
- クラウドリソースのテスト
個人的なオススメ項目に絞って下記に紹介を記載します。
設計：設計の骨組みづくり
まずは設計の第一歩として、設計書一覧の例が掲示されました。
個人的にはこの骨組み例だけでも非常に参考になるものとして、自身のテンプレートとしたい収穫になります。
設計書項目の整理
- 設計書項目の整理
- 設計事由を必ず含める
- 細かな検討経緯は論点ごとにADR（Architecture Decision Record）を作り、設計書からリンクさせる
ヒトは必ず忘れる生き物です。
また、担当変更が起きた際に過去の経緯が埋もれていくというのも必ず発生する事由です。
設計議論の再燃によるちゃぶ台返しの回避、将来の設計改訂への布石が狙いとのことでした。
ADRのサンプルも掲示されました。
こういったドキュメントが残っていると、システムが引き継がれた際も後任が確認しやすいため欲しい内容です。
詳細設計書の取り扱い方針
- 初版：IaC + 文書を準備
- 第二版以降：IaCコードを正とする
初期設計時は「基本設計書＆ADR」「詳細設計書」「IaCコード」を用意します。
これは初期設計時、「ヒト」のインタラクションが多く、コード管理出来ない部分が発生するからです。
第二版以降はADRで討議内容を残したうえで、IaCコードで管理していく手法で継続メンテナンスを行うと良いとのことでした。
設計：アプリ/インフラチームの責任分界
永遠の課題とも言える話題にも触れていました。
参考回答として「開発方針とガバナンスを軸に検討する」とのことでした。
上記図を見て、ざっくりと以下の分け方を想像しました。
- EC2で構築する場合：インフラがOSまで管理、アプリはミドル部分を管理
- サーバレス構成の場合：インフラがデータ領域を管理、アプリはコンテナ部分を管理
- 権限分掌を重視する場合：インフラがIAM等を管理、アプリがリソースとデータを管理
このあたりはプロジェクトによって変わってくる箇所となるため、ある程度の担当分けは事前に調整する箇所でしょう。
最近の流れとしては、アプリとインフラの垣根が無くなっている点も多くあり難しい箇所もあると思います。
個人的な思いとしては、枠組みとして決めておくものの、両担当者が歩み寄った運用を行えればいいなぁという一番難しい箇所を理想として捉えます。
設計：コーディングルール
IaCにもコーディングルールを設けましょう。
ルールを定め、枠組みとなるスケルトンコードを作る必要があります。
コーディングルールの例が掲示されました。
スケルトンルールには生成AIの活用としてAmazon Q Developerが紹介されています。
イチから自身でテンプレートを作成せず、提案されたコードを利用出来るので生成AI活用で時短出来るところは時短していきたいですね。
構築：コスト管理は今すぐ始める
コスト管理は「開発開始時点から始める」のが鉄則です。
まずは下記でコストが見れる状態にしてスタートしましょう。
- AWS Budgets
- AWS Cost Explorer
開発時点の設定ミスによってコストが肥大する可能性があります。
大規模インフラに関わらず悲劇からも救われることもあるかもしれないため、AWSで開発をする方はまずコスト可視化の設定を行うことをオススメします。
構築：クリティカルパスの特定
個人的に一番の共感ポイントです。
大規模インフラや本番環境構築において、IaCでは完結しない箇所が多数含まれます。
手動での設定が必要となるサービス、社内調整が必要となる箇所を事前に特定しましょう。
例としていくつか挙げられていたため、いざ構築時に困ることがないよう覚えておきたい観点です。
構築：クラウドリソースのテスト
今回の発表では「IaCのテスト」の観点でお話されていました。
- 単体テスト：実環境にフォーカス
- 指定した環境に設計通りに作成されているか？
- 結合テスト：疎通性にフォーカス
- コード、アプリインフラ、運用インフラが正常に疎通できるか？
- 負荷テスト：性能にフォーカス
- 想定規模でのアプリアクセス下で、性能要件が満たされているか？
単体テストのアプローチ
- 担当者のコードレビュー
- ツールによる静的解析、自動テスト
実際に構築した環境で最終的な作成物が正しいかは確認します。
この単体テストで正常に動作していることを確認出来ない場合、他のテストに影響が出るため課題潰しはこのタイミングが必須です。
結合テストのアプローチ
アプリチームとインフラチームでの共同で実施します。
- アプリから関連リソースへ疎通が出来るか
- ログ出力などのアプリリソースの運用インフラが正常に出力されているか
負荷テストのアプローチ
この項目も非常に重要な観点です。
インフラチームが考慮すべき負荷テストの箇所として重要点を2つ挙げていました。
- 上限緩和の対象リソースと申請状況の確認
- テスト後の縮退計画の策定
実際に構築のタイミングで、考慮不足により上限に引っかかってしまうケースがあります。
負荷テスト以外でも忘れがちな項目となるので、開発時点で発覚している上限に関しては事前に上限緩和申請を行いましょう。
参考情報：上限緩和申請
最後に
規模に関わらず、商用環境構築に関して重要なTipsがまとめられていたセッションでした。
- 設計書の書き方サンプル
- アプリ/インフラ責任分界の考え方
- IaCの運用方法
- コスト管理の開始タイミング
- 各種テストの考慮事項
特に設計書に関しては後回しにされがちだったり、作成フォーマットが定まっていないと悩んでしまう箇所だったため、設計書サンプルを見れたことは非常に有益でした。
今後のエンジニア人生のなかで設計書が必要になった際は思い出していきたい所存です。
