コンテナを管理する機能

フルマネージドなコンテナオーケストレータ。コンテナを動かす実行環境のサービスではない。他のAWSサービスとの連携が非常に容易。信頼性も高く、月間稼働率は少なくとも99.99％である

コンテナが動作するコンポーネント。１つ以上のコンテナから構成されるアプリケーションの実行単位

タスクを作成するテンプレート定義。JSONで記述される。デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、CloudWatchLogsの出力先等を指定する。１つのタスク内に複数のコンテナを含められる。

指定した数だけタスクを維持するスケジューラー。オーケストレータのコア機能。作成時は、起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定する。タスクが何らかの理由で終了した場合は、タスク定義をベースに新しいタスクを生成し、指定したタスク数を維持する

ECSサービスとタスクを実行する論理グループ

コンテナ並に軽量で柔軟性をもちつつ、従来の hypervisor 型 VM と同等の機能を持つような仮想マシン。docker のようなコンテナ技術は docker daemon などのコンテナ管理ツールやホスト側の kernel を他コンテナと共有しているため、そこに問題があると他コンテナにも影響が生じるという点で各環境の分離が不十分という指摘がある。 micro VM ではこの点を解消するため、各環境毎にゲストの kernel を用意し、その上で軽量な仮想マシンを動作させることでカーネルレベルでの分離を実現させる構成となっている。

フルマネージドなKubernatesのサービス。コンテナオーケストレータ。KubernatesのコンポーネントはKubernatesコントロールプレーンとKubernatesノード（Workerノード）から構成されている。実行環境としてFargate（フルマネージドなコンテナ実行環境）を選択できる。他のAWSサービスとの連携も可能、月間稼働率は少なくとも99.99％

コンテナが実際に稼働するリソース環境

AWSで仮想マシンを利用できるサービス。必要に応じてスペック（CPUコア数、メモリ容量、ストレージ）を変更できる。運用するコストは高くなるが、要件に合わせた設定が可能である

ECSとEKSの両方で動作する、コンテナ向けサーバーレスコンピューティングエンジン。フルマネージドなデータプレーン。ECSやEKSとセットで利用

ホストの管理が不要。サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドは発生しない。

EC2を使うよりも高い。OSの詳細なチューニングができない。割り当てるCPUやメモリへの制限、コンテナが起動するまでの時間が少し遅い

サービス導入、維持、管理にかかる総費用

ECSのコントロールプレーンをAWSで動作させつつ、データプレーンを自身が管理するサーバー上で動作させることができるサービス。データプレーンの新しい起動タイプ「EXTERNAL」によって、ユーザーの管理するサーバー上でECSタスクを実施可能になる。権限制御はIAMロールを使用可能。オンプレミスの資産をうまく活用したり、セキュリティ要件などの問題を解決できる

オンプレミス上でEKSDistroを展開することでオンプレミスでもEKSと同様の体験が可能になるサービス。自社でかかえるリソース活用、ガバナンス要件などを解決する。EKSDistroのみを利用する場合との違いは、AWSからのサポート体制。（EKS Anywhereは手厚い）

EKSで使われてきたKubernatesのコンポーネント群がOSSときて公開したという内容。Kubernatesの後発バージョンがサポートされる。

開発の仕様やシステム資源に関する情報を一元管理できる場所

フルマネージドなコンテナレジストリ。コンテナイメージを簡単に保存、管理できる。ECSと容易に連携でき、新しいコンテナを立ち上げるときに簡単にコンテナイメージを取得できる。プライベート、パブリックリポジトリどっちもある。AWS上でシステム構築するときは、AWSサービスとの連携ができるためECRを使うといい。

リポジトリ（コード等の集合）を格納・管理する場所（サーバーやサービス）を指す

利用者がコードをアップロードするだけでコードを実行できるサービス。フルマネージドサービス。Firecrackerと呼ばれるコンテナ上で実行され、軽量のマイクロ仮想マシン（microVM）を起動する。

KVMを利用する新しい仮想化技術。仮想化されていない環境では、軽量のマイクロ仮想マシン（microVM）を数秒で起動することができ、従来のVMで提供されているセキュリティとワークロードの分離と、コンテナに伴うリソース効率性を向上

物理 Linux マシンにインストールして仮想マシンを作成できるソフトウェア機能

本番環境でスケール可能なwebアプリケーションを素早く展開するためのマネージドサービス。githubやECRと連携して、即座にビルド&デプロイできる。インフラ周辺の構築をマネージドでやってくれる。

EC2上にECSのタスクを起動してタスク上でコンテナを稼働させる。 コスト面↓ ・サービス利用料‥EC2とEBS。EC2のキャパシティプランニングが適切にできればコストは比較的抑えられる ・運用コスト‥高い。EC2のメンテナンスが発生するから。 ・学習コスト‥低い。ECSやEC2は馴染み深いから。 拡張性↓ ・デプロイの速さ‥速い。デプロイする際に利用するイメージのキャッシュをEC2のホスト上に保持できるから。コンテナレジストリからコンテナイメージを取得する時間を削減できる ・水平スケーリング‥キャパシティプランニングの精度に影響するため少し弱い。確保したキャパシティ分までしか水平スケーリングできないため。 ・リソース拡張‥優秀。EC2のサイズアップやインスタンスファミリーを変更する等、リソース拡張は容易に可能。 信頼性↓ ・障害復旧面‥ECSはマネージドなのでAWSの責任。EC2は比較的障害調査しやすい。サーバーにログインして調査できるから。 ・問題発生時のサポート‥ECSのサポートは手厚い。AWS純正のコンテナオーケストレータのため、内部の動きも全てAWS側の設計だから エンジニアリング観点↓ ・エンジニアの確保がしやすい。ECSもEC2も古くあるサービスだから。

Fargate上にECSのタスクを起動してタスク上でコンテナを稼働させる。 コスト面↓ ・サービス利用料‥Fargate。コンテナ化されたアプリケーションに必要なvCPUとメモリリソースに対する料金が発生。vCPUとメモリリソースは、コンテナイメージを取得した時点からECSタスクが終了するまでを対象として計算される。EC2と比較して料金は少し割高 ・運用コスト‥かなり低い。EC2でネックであったインフラ管理の保守管理コストから解放されるから。コンプライアンス準拠の観点でも価値あり。クレカ業界のセキュリティ基準であるPCIDSSなどにも準拠。 ・学習コスト‥低い。ECSonEC2の知識を利用できる。 拡張性↓ ・デプロイの速さ‥比較的遅い。１つ目の理由は、Fargate上で稼働するコンテナは、コンテナごとにENIがアタッチされるため。ENIの作成には少し時間がかかる。２つ目の理由は、イメージキャッシュができないから。コンテナ起動時に毎度コンテナイメージを取得する必要がある。 ・水平スケーリング‥Fargateがリソースを調達するため容易に実施できる ・リソース拡張‥制限が複数ある。タスクに割り当てられるエフェメラルストレージの容量は拡張できない。永続的なストレージが欲しいときはEFSボリュームも利用できる。 信頼性↓ ・障害復旧面‥Fargateはマネージドなホストのため、基本的にSSHによるログインはできない。だが、2021年にAmazon ECSExecが発表。コンテナに対して対話型のシェル、あるいは１つのコマンドが実行可能になった。 ・問題発生時のサポート‥サポートは手厚い。 エンジニアリング観点↓ ・エンジニアの確保がしやすい。古くあるサービスだから。

一時的なストレージ

EC2上にEKSのPodを起動してPod上でコンテナを稼働させる。 コスト面↓ ・サービス利用料‥EC2とEBS、EKSにもかかる。 ・運用コスト‥高い。EC2のメンテナンスとEKSのバージョンアップ対応が必要だから。 ・学習コスト‥高い。kubernatesの学習は難しいから 拡張性↓ ・デプロイの速さ‥速い。デプロイする際に利用するイメージのキャッシュをEC2のホスト上に保持できるから。コンテナレジストリからコンテナイメージを毎回取得しなくていい。 ・水平スケーリング‥キャパシティプランニングの精度に影響するため少し弱い。確保したキャパシティ分までしか水平スケーリングできないため。 ・リソース拡張‥優秀。EC2のサイズアップやインスタンスファミリーを変更する等、リソース拡張は容易に可能。 信頼性↓ ・障害復旧面‥EKSはマネージドなのでAWSの責任。だが、kubernates自体に問題があった場合はAWSの責任ではない。EC2は比較的障害調査しやすい。サーバーにログインして調査できるから。 ・問題発生時のサポート‥kubernates自体はAWSのサポート対象外であるため、独力による復旧が求められる場合もある エンジニアリング観点↓ ・エンジニアの確保がしやすい。EC2は馴染み深い技術のため容易。kubernatesはコンテナオーケストレータ利用者の中で割合が多い。十分な運用体制と技術にキャッチアップしたいエンジニアがいればEKSは採用価値あり。

CNCF関連ソフトウェアとKubernatesを組み合わせることでさまざまな機能を自由度高く実装できる

クラウドネイティブアプリケーション開発・運用関連のオープンソースプロジェクトを提供する等の活動を行っている団体

Fargate上にEKSのタスクを起動してPod上でコンテナを稼働させる。常駐起動が必要な処理についてはEC2を用意し、スポット処理にはFargateを適用できる。 コスト面↓ ・サービス利用料‥FargateとEKS。スポット利用をしてコストの削減もできる。 ・運用コスト‥低い。EC2でネックであったインフラ管理の保守管理コストから解放されるから。kubernatesバージョンアップ時の対応もデータプレーンは必要ない。onEC2だと必要。 ・学習コスト‥高い。KubernatesとFargateの学習が大変だから。 拡張性↓ ・デプロイの速さ‥比較的遅い。１つ目の理由は、Fargate上で稼働するコンテナは、コンテナごとにENIがアタッチされるため。ENIの作成には少し時間がかかる。２つ目の理由は、イメージキャッシュができないから。コンテナ起動時に毎度コンテナイメージを取得する必要がある。 ・水平スケーリング‥Fargateがリソースを調達するため容易に実施できる ・リソース拡張‥制限が複数ある。タスクに割り当てられるエフェメラルストレージの容量は拡張できない。永続的なストレージが欲しいときはEFSボリュームも利用できる。 信頼性↓ ・障害復旧面‥Fargateはマネージドなホストのため、基本的にSSHによるログインはできない。だが、2021年にAmazon ECSExecが発表。コンテナに対して対話型のシェル、あるいは１つのコマンドが実行可能になった。EKSはkubernates自体に問題がある場合は独力での対応が求められることもある。 ・問題発生時のサポート‥Fargateはサポートは手厚い。kubernates自体は対象外。 エンジニアリング観点↓ ・どちらとも最新技術のため人材確保は難しい。十分な運用体制と技術へのキャッチアップがおこなえるエンジニアがいるなら採用価値あり。

・Fargateノード上にPodを１つしか作成できない。そのためDaemonSetが使えない。Podのログ集約を代わりに実現させるため、デーモンが必要な場合はPod内にサイドカーコンテナとしてデーモンを起動させる必要がある。 ・特権コンテナを利用できない。 ・ALBとNLBをIngressのサービスとして登録可能

メイン処理をするコンテナの横に補助的な処理をするコンテナを利用する構成のこと。コンテナが出力したログを、サイドカーが読み取り、ログ集約サーバーに転送するパターンがよくある。

通常のコンテナよりも高い権限の付与されたコンテナ

EKSonEC2。 EKSの理由↓ ECSにしようとすると、kubernatesマニフェストで定義されている構成を変更する必要があり、そのコストは非常に大きいから。 EC2の理由↓ EKSonFargateは制約が多く、DaemonSetが使えないから。

ブロックチェーン基盤のEthereumのロールのフルノードはすべてのトランザクションを取り込むため、大容量のデータをローカルに保持する必要がある。また、ブロックチェーンは高速なスループットを必要としない。 データプレーンはEC2。 EC2はEBSで容量を確保でき、最大64TB。Fargateは200GBだから。 コントロールプレーンは、AWS以外のクラウドやオンプレミスで動かすことを視野に入れるならEKS。学習コストや運用コストを加味するならECS。

ビットコインやEtuereumに代表されるような暗号通貨の基盤として用いられている技術。さまざまな情報をブロックチェーンに乗せて改ざん性や透明性を保持した基盤として用いられていることもある。

フルノード‥全てのトランザクションのブロックやトランザクションを保有、管理、共有 バリデータ‥送信されたトランザクションを検証。Blockchain Networkへトランザクションを取り込む。 マイナー‥マイニングを行う人。

仮想通貨の取引の内容を確定させることで報酬を得ることを指します。改ざんできないように、仮想通貨の取引を成り立たせる仕組み。膨大な量の計算を処理しなくてはならないため、高度な計算能力を備えたマシンが必要。マイニングに成功すると、仮想通貨ごとに決められたルールに従って新たなコインが発行され、報酬として受け取ることができる。

機会学習をする際にボトルネックとなる箇所は推論モデルの構築と推論処理。この処理は膨大で並列可能なケースが多い。そのため、CPUよりも並列処理が得意なGPUを使う。 データプレーン‥ EC2 機会学習に特化したインスタンスがあり、GPUや機会学習に特化したチップも使える。一方でFargateはGPU未対応だから。 コントロールプレーン‥どちらでも プロダクト開発をしているチームのみで組み上げるならECS。運用フェーズも含めてインフラをしっかりみられる体制があり、AWS以外のクラウドやオンプレミスで動かすことを視野に入れるならEKS。

高いリソース集約率とは、インスタンスに割り当てたCPUとメモリを無駄なく使うこと。処理に応じて適切なリソースを割り当てる必要がある。 データプレーン‥Fargate。EC2は処理ごとに異なるインスタンスタイプのEC2を立ち上げて処理するのは大変。Fargateはインスタンスタイプの選択が不要。処理に応じてCPUやメモリの要件を指定してホストを立ち上げ、処理を実行するケースに向いている。 コントロールプレーン‥ECSとEKSどちらでもよい

SIは発注者の利益につながりにくい提案は難しい。プロダクトの機能に直接関係のないカイゼンは難しい。 データプレーン‥Fargate。プロダクトの特性（障害復旧のしやすさ、エフェメラルストレージの容量、GPU利用、起動速度など）が許せば、運用コストを極小化できるから。 コントロールプレーン‥ECS 事例がEKSより多い。EKSは数ヶ月に一度のアップデートがあり、また運用も大変。 開発と運用が上手く連携できればEKSもあり。

行き当たりばったりな開発で最適化されていないプロダクトであったり、古い状態のままで問題を抱えているプロダクトの状態

「改善」は欠点や問題を正す意味合いだが、「カイゼン」は物事をよりよくすることにフォーカスしている

自社開発ではチャレンジしたことによるノウハウは自社に残る。チャレンジの価値がある。 データプレーン‥Fargate。 運用コストを減らすため。制約が多いことが障害になる場合は、EC2も視野に入れる。 コントロールプレーン‥ECSとEKSどちらでも。

豊富なサービス群をブロックのようにうまく組み合わせて利用すること