【読書メモ】AWSコンテナ設計・構築[本格]入門
はじめに
実務でAWSを触るようになりました。
これからコンテナを触っていくことも増えていくので次の本を読みました。
ハンズオンも実施できるので非常におすすめです。
注釈にある公式ドキュメントは、必ず参照したほうがいいと思います。
以下、読書メモにです。
ロギング設計
CloudWatch Logs or FireLens
CloudWatch Logs - 例）サブスクリプションフィルター：指定した文字列を含むログのみを抽出する - 抽出したログをlambdaに連携して障害を通知させる
メトリクス設計
- メトリクス：定量的な指標として定期的に計測/収集されるシステム内部動作のデータ
- CloudWatchメトリクスとCloudWatch Container Insightsに分けられる。 - CloudWatchメトリクス：CPU使用率、メモリ使用率( 1分間隔、ECSサービス単位 ) - CloudWatch：ECSタスクレベルで収取可能。ディスクやネットワーク情報も収集可能
Bastion設計
- 傷害調査等で各サーバへログインしたいとき、セキュリティ面や運用コスト面を考慮した設計が必要。
- セッションマネージャー経由の接続で、SSH接続が不要。IAM権限でログイン可能となるため、セキュリティ設定をIAMに集中管理できる。
コンテナイメージの脆弱性スキャン
- 継続的かつ自動的に実施することが重要。CI/CDに仕組みを取り入れる。 - CI/CDが実行されなければ、脆弱性スキャンが実施されないので、定期的な手動スキャンが必要。 - CloudWatch Eventsからlambdaを実行できる。
平文の秘密情報対策
- 秘密情報をSecrets ManagerやSSMパラメータストアに格納することで、環境変数として安全に提供できる。
- 具体的には各格納先のARNと環境変数名をタスク定義内でマッピングすることで、コンテナイメージ内のOS環境変数として認識させる。
信頼性設計
- マルチAZによる可用性向上 - FargateでECSサービスを稼働させると、ECSサービス内部がベストエフォートでAZ間の負荷バランスを調整しながらタスク配置する。
- 障害児切り離しと復旧 - CloudWatchを活用したECSタスクの障害検知 - RunningTaskCountとTaskCountメトリクスを組み合わせる。 - ECSサービスによるECSタスクの自動復旧 - ALBと連動したECSタスクの切り離しと自動復旧 - リタイア、リサイクル等によるECSタスク停止への対処 - リタイア：AWS内部のHW障害や脆弱性検知時、新しいECSタスクに置き換えるイベント - リサイクル：Fargate上で稼働しているECSタスクについて、パッチ適用や内部インフラストラクチャ更新のイベント
- システムメンテナンス時のサービス停止 - メンテナンス時、SorryページやSorryコンテンツを返却できることが理想。ALBのリスナールールの定義に設定できる。
