AWS完全に理解する

2022-03-05に作成

AWSに対して学習した際のアウトプットを記します。

基本的には、以下から対応するサービスの資料を参照してまとめてます。

サービス別資料 | AWS クラウドサービス活用資料集

所有者限定モードのためこのボードには投稿できません ボードとは?

Amazon ECS完全に理解した

Amazon ECSとは

コンテナ管理サービスの1つです。

Amazon Elastic Container Service とは - Amazon Elastic Container Service

よくEKSと比較されがちです。

学習成果

下記の要約のうち、気になった部分をまとめています。
Dockerやdocker-composeのぼやっとした知識はあるものとします(無いと理解できないと思います)。

20200422 AWS Black Belt Online Seminar Amazon Elastic Container Servise (Amazon ECS) (PDF)

補足として下記を参照しました。

ECSの主要要素

タスク定義

  • タスクを構成するコンテナ群の定義
    • コンテナ定義
    • 要求CPU & メモリ
    • タスクの割当てIAMロール
    • ネットワークモード
    • など
  • AWS Batchのジョブ定義とほとんど同じ

タスク

  • タスク定義に基づき起動されるコンテナ群
    • タスクというのは1つ以上のコンテナの集合
  • タスク内コンテナは同一ホスト上で実行される
    • ホストというのは、実際のEC2インスタンスやFargate内の論理デバイスのこと
    • タスク内のコンテナ間の通信を可能とするため?
  • こちらもAWS Batchのジョブとほどんど同じ
  • 考え方としてはdocker-composeに近い?

サービス

  • タスク実行コピー数の定義
    • タスク実行コピー数とは、タスクを同時にいくつ起動するかということ
  • 起動後のタスク実行コピー数の維持
  • ELBとの連携
  • 起動タイプ (EC2 or Fargate) の設定

クラスター

  • 実行環境の境界
    • EC2インスタンスやFargateといった論理デバイスの1つひとつを表す
      • サービスはクラスターを跨る可能性がある
  • IAM権限の境界
  • スケジュールされたタスクの実行を設定可能
    • なんでサービスで設定できないんだろう?

コンテナの実行環境

EC2

  • EC2インスタンスをコンテナインスタンスとして配置
    • Amazon ECS-optimized AMI
      • Dockerデーモン
      • ECSコンテナエージェント
        • ECSコントロールプレーンと通信
        • コンテナインスタンスの管理
        • タスクの実行/停止
        • このエージェント自体もコンテナ
      • など
  • コンテナインスタンスのドレイン(おそらくECSクラスターからのインスタンス削減)
    • 原因
      • システム更新
      • エージェント/Dockerデーモン更新
      • AutoScalingのスケールイン
      • など
    • ポイント
      • 新規タスクの配置は無し
      • PENDING状態のサービスタスクは即時停止
      • RUNNING状態のサービスタスクは設定に従い停止/代替
  • 課題
    • OSやエージェント類へのパッチ当て/更新
    • EC2インスタンス数のスケーリング
      • あと、適切なEC2インスタンスタイプの選定もある

Fargate

  • EC2インスタンスのプロビジョニングや管理が不要
    • パッチ当てやOSアップグレード
    • エージェント類のアップグレード
    • など

コンピュート

  • タスク割り当てCPUとメモリ設定が比較的柔軟
    • 0.25vCPU: Memory 0.5, 1, 2GB
    • 0.5vCPU: Memory 1, 2, 3, 4GB
    • 1vCPU: Memory 2, 3, 4, ..., 8GB
    • 2vCPU: Memory 4, 5, 6, ..., 16GB
    • 4vCPU: Memory 8, 9, 10, ..., 30GB
  • CPUとメモリの割当て
    • タスクレベル(必須): CPU、メモリ共にハード制約
    • コンテナレベル(オプション)
      • cpu: コンテナ用のcpuユニット数
      • memory: ハード制約
      • memoryReservation: ソフト制約
    • 考え方
      • コンテナレベルのcpuの合計値をタスクレベルのcpuの合計値にするとよいかも
      • コンテナレベルのmemoryの合計値をタスクレベルのメモリ量に設定するとよいかも
      • memoryReservationはmemoryの半分~3/4程度の値にすると揺らぎをある程度許容できそう
  • EC2タイプよりは若干割高
    • EC2オンデマンド料金と比較して約1.17倍
      • 特に、Spotインスタンスの方が安い
    • しかし、EC2の場合、全リソースをアプリケーションに割り当てることは現実的に難しい

ストレージ

  • レイヤストレージ
    • Dockerイメージの最上位レイヤとして、タスクごとに10GBを利用可能
    • 書込み内容はコンテナ間で独立
    • タスク停止後には利用不可
  • ボリュームストレージ
    • タスクごとに4GB
    • タスク定義内でボリュームマウントとして利用可能
      • 複数のコンテナ間での共有
      • ことなるcontainerPathでのマウント
    • タスク停止後には利用不可(レイヤストレージと一緒)

ネットワークモード

  • awsvpcのみ利用可能
  • 詳細は 機能 > タスク定義 > ネットワークモード の節を参照のこと

機能

タスク定義

  • アプリケーションを構成する1つ以上のコンテナを定義するJSON形式のテキストファイル
    • アプリケーション実行時は、タスク定義をインスタンス化したタスクを実行
    • パラメータを指定

ファミリー

  • タスク定義の名前のようなもの
  • ファミリーとリビジョン番号で1つのタスク定義が特定
    • リビジョン番号とは?
  • タスク定義を更新する際は、ファミリーの新しいリビジョンを作成する必要がある
    • タスク定義そのものはイミュータブル
    • 実行中のタスクは更新されない
    • サービスから利用している場合はサービスの更新が必要

コンテナ定義

  • コンテナの設定項目
    • 名前: コンテナの名前
    • イメージ: 使用するコンテナのイメージ
    • メモリ
      • memory: ハード制約(これを超えたらバーストする)
      • memoryReservation: ソフト制約(これを維持するようにある程度の揺らぎは許容する)
    • logConfiguration: ログドライバーの設定(awslogsなど)
    • environment: 環境変数
    • secrets: AWS Secrets Manager シークレット、AWS SSM パラメータストアのパラメータを参照
    • dependsOn: 起動依存性の設定
      • 起動順や停止順が設定可能
        • START: 依存元コンテナが起動開始したら起動する
        • COMPLETE: 依存元コンテナの実行が完了(終了)したら起動する
        • SUCCESS: 依存元コンテナの実行が正常終了したら起動する
        • HEALTHY: 依存元コンテナのhealthcheckが合格したら起動する
      • 依存先コンテナが起動しない/異常終了する場合
        • startTimeout: 依存先コンテナが起動しないことを依存元コンテナが待機する時間
        • stopTimeout: 依存先コンテナが正常終了しなかった場合に強制終了されるまでの待機時間
      • docker-composeのdepends_onと同等?

タスクロール

  • コンテナのIAMロール
    • コンテナ内のアプリケーション向け

タスク実行ロール

  • ECSコンテナエージェントのIAMロール
    • コンテナのイメージのpullやCloudWatch Logsへの書込みなど

ネットワークモード

  • コンテナのDockerネットワークモード
    • none: 外部との接続無し
    • bridge (default for EC2): Dockerの組込み仮想ネットワークを使用して外部ネットワークとの通信(コンテナリンク利用可)
    • host: コンテナポートとホストEC2インスタンスのNICのマッピングによる外部ネットワークとの通信
    • awsvpc (default for Fargate): タスクをECS管理下のENIに自動割当て
      • ENIをEC2にアタッチすることで実現するため、EC2起動タイプの場合、EC2インスタンスタイプのENI上限によってタスク配置が制限される可能性がある
        • ENI Trunkingを有効にすると、1インスタンスのENI上限数を上げることが可能
      • タスク内のコンテナはlocalhostインタフェースを共有
      • VPC無いの他のリソースはプライベートIPでの通信が可能
      • ロードバランサーの種類
        • ALB
        • NLB
      • VPC外へのアクセス
        • イメージのプル、ログ送信は可能
          • タスク実行ロールへのIAMロールアタッチが必要
        • 他は IG-(EIP)-ENI 経由で通信可能

ボリューム

  • データの共有先
    • Dockerボリューム(EC2のみ)
      • タスク間での共有や明示的なライフサイクル管理が可能
    • バインドマウント
      • ホストマシン上のファイル/ディレクトリをコンテナにマウント
    • EFSボリューム
      • コンテナインスタンスにかかわらず、同じ永続的ストレージにアクセス可能

タスクサイズ

  • タスクに適用するハード制約
    • vCPU
    • メモリ

コンテナの実行

コンテナの実行方法

  • タスク起動
    • タスク定義にに従う
    • バッチジョブのような、処理が終わると停止するワークロードなどに適切
      • Amazon Batchを使うほどでもないような低規模タスクに良い
  • サービス起動
    • 指定したタスク数を維持する
      • ECSにおけるコンテナオーケストレーションの機能の1つ
    • Webアプリケーションなどの長時間実行するアプリケーションなどに適切

タスクのライフサイクル

  1. Provisioning
  2. Pending
  3. Activating
  4. Running
  5. Deactivating
  6. Stopping
  7. Deprovisioning
  8. Stopped

タスクの配置

  • タスクの配置方法を、AZやインスタンスタイプに基づいて制約を設定可能

サービススケジューラ戦略

  • レプリカ
    • クラスタ全体で必要数のタスクを分散配置
  • デーモン
    • コンテナインスタンス毎に配置
  • Amazon ECSクラスターキャパシティープロバイダー
    • タスク配置先のコントロールがより柔軟に可能

サービスのAuto Scaling

  • ターゲット追跡スケーリングポリシー
    • 指定したメトリクスの値が指定値に近づくように調整
  • ステップスケーリングポリシー
    • アラームをトリガーに調整値に基づいて増減
  • スケジュールに基づくスケーリング
    • 日付と時刻に基づいて増減

Container Insights

  • 既存のメトリクス情報はサービス単位
    • タスクレベルやコンテナレベルでの負荷を検知できなかった
  • 料金体系
    • CloudWatchカスタムメトリクス費用
      • 計算式: 既存のECSクラスターメトリクス8個 + (既存のECSタスクメトリクス6個 * 一意のタスク名) + (既存のECSサービスメトリクス11個 * 一意のサービス名)
    • CloudWatch Logs費用