はじめに
受講セッションの個人的な所感と、メモです。
メモの内容は、誤字脱字などあるやもしれませんが、ご了承ください。
概要
クラウド技術のコモディティ化により、エンタープライズ分野では近年、AWS 上での大規模なアプリケーション開発が一般的になりつつあります。これを支えるクラウドインフラ設計についても、求められる非機能要件の高度化と関連する AWS サービスの多様化に伴って、多人数でのチーム設計やアプリケーションチームとの効果的な連携が求められることが増えてきました。 本セッションでは、AWS Professional Services の豊富な実績を元に、クラウドインフラの設計・構築およびテストを円滑に進める上での実践的知見をご紹介します。
所感
私は、バックエンドもインフラもやるけど、フロント寄りなフルスタックエンジニアなのですが、
大規模インフラでなくとも、設計・仕様を明文化し、チーム内に落とし込み、エンジニア活動を運用していく上では、
とても参考になる話でした。
責任分解や、開発方針など、チーム運用する上ではとても大事な考え方ですね。
特に印象的な言葉としては、「人は忘れる」ですね。
当然なのですが、これを前提に考えることが大事な気がします。
聴講メモ
案件での経験に基づく大規模インフラの設計・構築案件の学び
何を作る？
- アプリインフラ
- 運用インフラ
特徴、解決すべき問題
- 関係者が増える
- 想定外が増える
- 堅牢さが求められる
設計
骨組みづくり
どこから手をつける？
- 設計書の一覧
- 可能な限り細分化する
- 運用インフラは要件を精査し、全量洗い出す
- アプリインフラは変わることがあるので as-is で
- 主担当の明確化
- 設計書項目の整理
- 設計事由は必ず含める
- 人は忘れる
- 細かな検討経緯は論点ごとに ADR を作り、設計書からリンク
- 詳細設計書の取り扱いの方針を決める
- 初版は IaC＋文書、以降は IaC を正とする
- 手動管理部分は設計書を継続メンテナンス
- 進捗の定義
- 何が済んでいれば完了かを定める
- 設計メンバーの自走、作業の並列化を促す
アプリ、インフラチームの責任分解
アプリインフラをどちらがどこまで作るか？
CI/CD など、どちらにも関わるものは、どちらがやるか明確にする。
開発方針とガバナンスを軸に検討する。
IAM や EC2 など、どちらがどんな権限を持っていた方がいいか？など。
コーディングルール
IaC にもルールは必要？
- 必要。ルールを定め、自動化支援コードを作成。
- 利用するツール、命名規則、関数の利用方針など
静的解析
セキュリティチェック、リンター
セキュリティの強制（SAST）
コスト管理は今すぐ始める
開発時点で始めるのが鉄則。
開発環境での異常動作や残置リソースなども確認する。
例) タスク定義の問題で無限ループ、ログの異常な書き込みなど
AWS Budgets、Cost Explorer だけでも活用する。
クリティカルパスの特定
IaC さえ書き上げれば OK?
大規模、本番環境では IaC だけでは完結しない。
手動管理の方が合理的なケース、
ルート権限など、IaC で対応できないケースなど。
展開手順の整備
展開手順の組み立て方
読むのは自分ではないので、ローコンテキストを心がける。
クラウドリソースのテスト
IaC のテストはどう考えればいい？
-
実環境
-
疎通性
-
性能
に焦点を当てる。 -
単体テスト
- 生成物が、指定した環境に書いた通りに作成されているか
-
結合テスト
- コード、アプリインフラ、運用インフラが疎通できるか
-
負荷テスト