【読書メモ】【3章】AWSコンテナ設計・構築[本格]入門

 

「AWSコンテナ設計・構築[本格]入門」の「3章　コンテナを利用したAWSアーキテクチャ」のメモを残します。

 

前章のメモ

 

AWS Well-Architected

 

AWS Well-Architectedとは、

1. 運用上の優秀性
2. セキュリティ
3. 信頼性
4. パフォーマンス改善
5. コスト最適化
6. 持続可能性

という6つの設計原則に基づいた、アーキテクチャのベストプラクティス。

 

ECS on Fargate を軸にしたアーキテクチャのベストプラクティスを見ていきます！

 

運用設計

モニタリングとオブザーバビリティ

 

モニタリング（監視）：メトリクスやログを監視して異常を検知する

オブザーバビリティ（可観測性）：システム内部を可視化して調査できるようにする

 

オブザーバビリティを高める3つの要素として

1. メトリクス：何が起きたのか
2. トレース：どこで起きたのか
3. ログ：なぜ起きたのか

があります

 

メトリクス

 

1. CloudWatchメトリクス
   • デフォルトで取得されるメトリクス
     • CPUUtilization：CPU使用率
     • MemoryUtilization：メモリ使用率
   • ECSクラスタまたはサービス単位
     • タスク単位ではないため、粒度が粗い
   • 無料
2. CloudWatch Container Insights
   • より詳細な情報をとれるカスタムメトリクス
     • 取得可能な項目はこちら。
     • 有効化する必要あり
   • ECSタスクレベルで情報をとれる
   • カスタムメトリクスなので有料

 

トレース

 

アプリケーションの動きをトレースするサービスとしてX-Rayがあります。

特徴としては

• コンテナで使用するにはサイドカーコンテナとしてX-Rayコンテナを同梱する
• X-Rayへデータを送るため、アプリケーションにコードを書く

 

ログ

 

コンテナのログを取得するには

1. CloudWatch Logs
   • ログの検索や他のAWSサービスとの連携が容易
   • CloudWatch Logs経由でS3へログを送れる
   • S3でログを補完するよりも料金面で高くなる
2. FireLens
   • AWSのみならず他のSaaSサービスへログを転送しやすい
   • サイドカーとしてFluent Bit（もしくはFluentd）コンテナが必要
   • S3とCloudWatch Logsに同時にログ転送できるので安く済む

 

コンテナごとに↑のどちらか１つしか使用できません。

CloudWatch Logsに送ると、ざっくり $0.50/GB かかり料金が高くなりやすいです。

なので、FireLensの使用がオススメ。

 

CI/CD

 

AWSでCI/CDといえばCodeシリーズ。

GitHubなど他のサービスとも連携可能なので柔軟性が高いです。

 

ECS on Fargate におけるCI/CDのポイントは

1. 開発、ステージング、本番環境と環境ごとにAWSアカウントを用意
2. CodeCommitやECRなど共有リソース用アカウントも用意
3. 開発及びステージングは専用のブランチからビルドされたイメージを使う
4. 本番環境はステージング環境でテスト済みのイメージをそのまま使う
   1. 本番環境ではコンテナイメージのビルドはしない

 

イメージのメンテナンス

 

CI/CDでビルドしてECRにコンテナイメージを保存します。

ただ、ECRに保存するのもタダではないので

• ライフサイクルポリシーで指定した期間や世代だけイメージを保存する
• イメージに環境ごとのタグをつける

をうまく利用します

 

セキュリティ設計

 

ECS on Fargate においてセキュリティ対策を考えるのは

1. イメージ
2. レジストリ
3. オーケストレータ
4. コンテナ

 

イメージ

 

• イメージの脆弱性対策
  • ツール：ECRによるスキャン、Trivy
  • CI/CDに組み込んで自動でスキャン
  • さらに、Lambdaを使用するなどして定期的にスキャンが必要
• Dockerfileの不備対策
  • ツール：dockle
  • Dockerのベストプラクティスに沿っているかチェック
• マルウェア対策
  • 提供元が信頼できるかどうかをチェック
  • GuardDutyで不審な通信を検出
• 機密情報
  • Secrets ManagerやSSMパラメータストアを使用
• イメージの改ざんへの対策
  • DCT(Docker Content Trust)という署名による整合性チェックを有効化

 

レジストリ（＝ECR）

 

• イメージのライフサイクルポリシー
  • 古いイメージを削除することはセキュリティ的にも良い
  • 誤ってデプロイされるリスクが減るため。
• プライベートリポジトリ
  • 特段パブリックに公開したいイメージがあればパブリックリポジトリへ。
• リポジトリポリシー
  • S3のバケットポリシーのECR版。
  • 環境によってCLIでイメージのプルはいいけど、プッシュはダメとか。

 

オーケストレータ（＝ECS）

 

• アクセス制限をかける
  • コンテナアプリケーションの中心となるので特に権限周りは気を付けたい
  • 絞りすぎるとデプロイサイクルが低下するので、トレードオフかなと。

 

コンテナ

コンテナ間や他のネットワークとの通信

 

1. インターネット→VPCへの通信
   • ECSタスクはプライベートサブネットに置く
   • インターネットからの通信はALBで受け、ECSタスクへ。
     • ECSタスクのセキュリティグループはALBからのみ許可。
   • ALBにはWAFを連携させる
2. ECSタスク間の通信
   • セキュリティグループを制御して対応。
3. VPC→インターネットへの通信
   • NAT Gatewayを使う
     • 使ったことあるけど、思ったよりもお金かかる
   • もしくはVPC Endpointを使う
     • ゲートウェイ型は無料だけど、インターフェイス型は割とお金かかる

 

未承認のコンテナへの対策

 

テストができていないコンテナが本番環境にデプロイされたらインシデントにつながります

なので、例えば

1. 開発環境
   • CI/CDよるコンテナイメージを主に使う
   • 手動でもコンテナイメージをプッシュできる
2. ステージ環境
   • CI/CDよるコンテナイメージのみ使う
   • 手動によるコンテナイメージのプッシュを禁止
3. 本番環境
   • ステージ環境でテストに通ったコンテナイメージのみ使う
   • CI/CD、手動によるコンテナイメージのプッシュは禁止

 

信頼性設計

 

1. マルチAZで可用性UP
2. ALBと連動させてECSのタスク切り離しと復旧
3. EC2やFargateのメンテナンスによるECSタスク停止への対応
   • SIGTERMシグナルに対して30秒以内にアプリケーションを終了させる
4. アプリケーションのメンテナンス時のSorryページ
5. サービスクォータの引き上げ

 

パフォーマンス設計

 

1. パフォーマンス要件を定義
   • レスポンスタイムやどの程度の負荷まで耐えられるかなど
2. リソースやスケール戦略を決める
   • スケールアップは停止が必要なのでスケールアウトを推奨
   • Auto Scalingはいったんターゲット追跡ポリシーで考える
3. テストを実施し、メトリクスを確認
4. リソースやスケール戦略を見直し、再度テスト

 

コスト最適化設計

 

• ECSタスク数とリソースの最適化
• 料金を前払いしておく、Compute Saving Plans
• 停止が許容できるのならFargate Spotを使う
• ECRにあるコンテナイメージのメンテナンス
• dev, stg環境の稼働時間を限定する
• コンテナイメージのサイズ縮小化

 

持続可能性

 

公式ドキュメントを見ると、

アーキテクチャを見直し効率を上げるとともに、エネルギー消費量を削減することが目的。

SDGs的な側面が強く、環境面に配慮したもの。

 

運用していく中で個々のシステムごとに違ったアプローチで追及していくもののイメージ。

そのため、本書において詳しい言及はされていないのかなと思います。（推測ですみません。。）

 

設計原則やベストプラクティスは公式ドキュメントをご参照ください。

 

次章のメモ