はじめに

SPA開発を始めるにあたってコンテナ関連のサービスの知識が必要だと感じ、AWS ECR ECS Fargateについてまとめてみました。

AWS ECR

正式名称はAmazon Elastic Container RegistryでDockerコンテナイメージの保存・管理・デプロイが可能であり、以下の特徴がある。

フルマネージドサービスなのでインフラの管理が不要
Docker CLI コマンドを利用することが可能
コンテナイメージ/アーティファクトはAmazon S3に保存される

なぜDocker HubではなくECRを使うのか

コンテナレジストリにはDocker社のDocker Hubがあるが、なぜAmazon ECRを使用するのか。
それは既存のAWSサービスとの統合が容易になることが大きな理由であり、以下のようなメリットがある。

IAMを使用した細かいアクセス許可設定が可能
Amazon ECSやEKS（Elastic Kubernetes Service）などのAWSコンテナオーケストレーションサービスとシームレスに連携し、コンテナイメージのデプロイを簡素化できる。
AWSリソースとの高速なネットワーク通信が可能になり、イメージのダウンロード時間を削減できる。
VPCエンドポイントを通じて、コンテナイメージをプライベートネットワーク内で管理・配布することができる。

コンテナオーケストレーション
コンテナ化されたアプリケーションのデプロイやスケーリング、管理などが自動化できることを言う

ECRの機能

ECRはレジストリとリポジトリから構成されている。
1つのリージョンに対して1つのパブリックレジストリと1つのプライベートレジストリを持つことが出来る。
レジストリの中にはリポジトリを1つ以上作ることができ、コンテナイメージはリポジトリの中に保存する。

レジストリ

レジストリには2つ種類がある。

パブリックレジストリ

保存したコンテナイメージをAWS内外の世界中に公開可能
公開されたコンテナイメージは、ECR Public Galleryからpullが可能
URLは public.ecr.aws/エイリアス/ という形式
- カスタムエイリアスを申請し、承認されれば任意の名前を設定することも可能

プライベートレジストリ

保存したコンテナイメージを制限された範囲に公開可能
- 自社アプリケーションの開発運用は、これを選択
URLは アカウントID.dkr.ecr.リージョン.amazonaws.com という形式
プルスルーキャッシュ
- パブリックレジストリのリポジトリを、プライベートレジストリにキャッシュすることが可能
- プライベートサブネットからパブリックレジストリの更新内容にアクセス可能(ECRのインターフェイスVPCエンドポイントを使用)
- 同期は24時間に1回
許可 (基本的にプライベートレジストリを利用するにはIAMベースの認証が必要)
- プルスルーキャッシュ機能とレプリケーション機能の許可をIAMのプリンシパルに付与
- レジストリポリシーを使用して許可を記述
レプリケーション
- クロスリージョンレプリケーション
  - 他リージョンを選択してレプリケーション
- クロスアカウントレプリケーション
  - 送信先AWSアカウントとリージョンを選択してレプリケーション
  - 送信先のアカウントにはアクセス許可のためのレジストリポリシーの設定が必要
スキャン
- 基本スキャン
  - プッシュ時に脆弱性のスキャンが可能
- 拡張スキャン
  - 自動継続的なスキャンが可能(Amazon Inspectorを使用)
  - OSとプログラミング言語パッケージの両方の脆弱性についてスキャン

リポジトリ

リポジトリには2つ種類がある。

パブリックリポジトリ

リポジトリ名を設定する際にオプションとして、ロゴやコンテンツタイプ、リポジトリの概要、イメージの使用方法に関する情報を提供することも可能

プライベートリポジトリ

タグのイミュータビリティ
- タグは、コンテナイメージを特定のバージョンや状態でラベル付けするために使用される
- 有効化すると、同じタグを使用した後続イメージのプッシュによりイメージタグが上書きされることを防ぐことが出来る
暗号化
- KMSを使用して、リポジトリに保存されているイメージを暗号化
- 暗号化キーはデフォルトではAWS所有のキー
- 自身で作成したKMSキーを設定することも可能

イミュータビリティ（Immutability）
オブジェクトやデータの変更が不可能である性質を指します。
つまり、一度作成されたオブジェクトやデータは変更されることなく、新しいバージョンが作成される必要があるという概念

AWS ECS

正式名称はAmazon Elastic Container Serviceでフルマネージドなコンテナオーケストレーターであり、以下の特徴がある。

クラウドでコンテナを本番環境利用するためのオーケストレーター
他のAWSサービスと連携しコンテナを大規模に実行
フルマネージドなコントロールプレーン
多様なワークロードをサポートする「タスク」「サービス」というシンプルなリソース表現

なぜコンテナオーケストレーターを使う必要があるのか

コンテナ化されたアプリケーションの管理、デプロイメント、スケーリング、監視、保守などの複雑なタスクを自動化し、効率的に実行するため
使用すると以下のメリットがある。

複雑なアプリケーションの管理
スケーリングと負荷分散
デプロイメントの自動化
高可用性と耐障害性
環境の一貫性と再現性

ECSの機能

ECSにはデータプレーンとコントロールプレーンという概念がある。

データプレーン

コンテナが稼働する環境のことを言う。
以下の3つに分類される。

データプレーンサービス	ECS on Fargate	ECS on EC2	ECS on Anywhere
管理負荷	低	中	高
設定の柔軟性	低	中	高

※ここではECS on Fargate以外の説明は割愛します。

ECS on Fargate

コンテナ実行環境をサーバーレスに実現したものであり、以下の特徴がある。

フルマネージドで、EC2インスタンスのプロビジョン、スケール、管理などが不要
仮想マシンを意識しないシームレスなスケーリングを実現
コンテナの起動時間・使用リソースに応じた従量課金
各種AWSサービスと連携が可能

コントロールプレーン

コンテナ環境を管理する機能のことを言う。
主に4つの設定が存在する。

タスク定義
- JSON形式で記述されるタスクのテンプレート
- コンテナで使用するDockerイメージや各タスク・コンテナに割り当てるCPUやメモリの量、環境変数などの稼働するタスクの設定を記述する。
- 複数のコンテナを指定することも可能
タスク
- タスク定義を元に作られる、アプリケーションの実行単位
サービス
- 指定した数のタスクを同時に実行して維持するスケジューラー
クラスター
- コンテナを動かすためのタスクまたはサービスの論理グループ

参考記事