はじめに
AWS認定ソリューションアーキテクトアソシエイトを取得する際に学習した内容をアウトプットします。
本記事はコンテナ技術についてです。
ハイパーバイザー型とコンテナ型の違い
コンテナは仮想化技術の１つ
コンテナ仮想化技術のデファクトスタンダードとなっているのがDocker
コンテナは従来のハイパーバイザー型仮想化技術に比べて以下のような利点がある
-
ハードウェアリソースの消費が少ない
- 起動が速い
- 同じハードウェアリソースでより多くのコンテナを同時に動かすことができる
-
開発の効率化
- アプリの実行に必要な構成や依存関係をコンテナにひとまとめにしておくことができるのでOSを含めた環境構築の工数が大幅に削減できる
- 開発環境から本番環境まで同一の環境（コンテナ）でアプリケーションを動作させることができる
AWSのコンテナサービス構成要素
主に以下３つの構成要素からなる。
-
データプレーン
- コンテナが稼働するための実行環境。コンテナを起動するためのホストマシンとしてEC2やFargateを稼働させることが可能。
-
コントロールプレーン
- コンテナの管理を行うもの。コンテナをどのデータプレーンのホストで稼働させるかの管理やコンテナの死活監視を担当する。
-
レジストリ
- コンテナの起動元となるイメージが格納されている置き場所。（上図左のECRが該当）
各コンテナサービス郡の詳細
■ データプレーン
EC2
- EC2インスタンス上でコンテナを動かす方式。
- コンテナに加え、「コンテナの実行環境となるホストマシン」の両方を管理・運用しなければならない。
- リソースが不足した場合はEC2インスタンスのスケールアップ・スケールアウトで対応。
Fargate
- AWS 側がインスタンスを管理してくれる方式。
- コンテナを実行するためのホストマシンはAWSが面倒を見てくれるので利用者側でホストマシンの管理・運用が不要となる。
- コンテナを実行するホストマシンのリソースは気にせず、コンテナ実行時に必要な CPUとメモリの組み合わせを選択するだけでOK。
■ コントロールプレーン
Amazon Elastic Container Service（ECS）
- AWS 独自のコンテナオーケストレーションサービス。
- データプレーンとしてEC2とFargateを利用できる。
Amazon Elastic Container Service for Kubernetes（EKS）
- オープンソースのKubernetesを実行するサービス。
-
データプレーンとしてEC2のみサポート2019年12月より、EC2に加えFargateと組み合わせることができるようになった。
コンテナオーケストレーション
コンテナは手軽に開発・実行環境を構築できるメリットがある半面、管理対象のコンテナの数が増えると運用・管理が複雑で手間がかかるという課題がある。
また、サービスの信頼性／可用性の観点で考えると、単一のホストマシンのみで複数台のコンテナを動かすことは望ましくない。複数のホストマシンにまたがってコンテナを稼働させることが必要だが、複数のコンテナ／ホストマシンを１台１台管理するは大変。
この問題を解決するのが「コンテナオーケストレーションサービス」。コンテナのデプロイや負荷に応じたスケーリング、障害検知・自動復旧等、コンテナに関わる運用や操作の自動化および一元管理が可能。
■ レジストリ
Amazon Elastic Container Registory（ECR）
- Dockerコンテナイメージの保存・管理・デプロイができる。
- VPC内のプライベートなDockerレジストリ。
ECS と EKS の使い分けについて
-
ECS （学習コストが低い反面、自由度はEKSに劣る）
- コンテナが稼働するホストマシンのメンテナンス負荷を下げたい場合
- ホストマシンのバージョンアップ対応等が不要
- 複雑度が低いアーキテクチャの場合
- AWS中心の設計にする場合
- コンテナが稼働するホストマシンのメンテナンス負荷を下げたい場合
-
EKS（自由度が高い反面、ECSに比べて学習コスト/メンテナンスコストがかかる）
- 既存システムでKubernetesを利用しており、AWSに移行する場合
- Kubernetesへの深い知見がある場合
- 複雑度が高いアーキテクチャ/比較的大規模で拡張性が求められるサービス構成の場合
- AWSのベンダーロックインの回避したい場合
※参考記事