図でざっくり理解する Amazon ECS Anywhere

## はじめに
2021/5/27 Amazon Elastic Container Service Anywhereが一般利用開始になりました🎉

https://aws.amazon.com/jp/blogs/news/getting-started-with-amazon-ecs-anywhere-now-generally-available/

オンプレミス環境で AWS のサービスを使用してコンテナをデプロイするオプションとして、これまでも AWS Outposts 上で Amazon ECS を利用するという選択肢はありましたが、気軽に導入できるものではありませんでした。Amazon ECS Anywhere はユーザーが所有する任意のインフラ環境で、ECS のコントロールプレーンを利用して簡単にコンテナを実行することができる機能です。

詳細な利用手順は他の記事に譲るとして、ECS Anywhere がどのような仕組みで動いているのかや他クラウドの類似サービスと比較したときの違いなどについて書いていきたいと思います。

**2022/4/21 時点で確認できた情報で記載しています。**
## ざっくり理解する ECS Anywhere
ECS Anywhere でコンテナを実行するために必要な環境や設定をざっくり説明していきます。
### 実行環境の準備
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125105/2b4ce076-bb4e-88e0-dd6f-65780167c45e.png)


サポートされる OS は以下です。CPU のアーキテクチャは x86_64 と ARM64 をサポートしています。2022/3/3 のアップデートで Windows インスタンスをサポートしました。

* Amazon Linux 2
* CentOS 7
* CentOS Stream 8
* RHEL 7, RHEL 8
* Fedora 32, Fedora 33
* openSUSE Tumbleweed
* Ubuntu 18, Ubuntu 20
* Debian 9, Debian 10
* SUSE Enterprise Server 15
* Windows Server 2022
* Windows Server 2019
* Windows Server 2016
* Windows Server 20H2

OS 要件を満たし、Amazon ECS のエンドポイントおよび AWS Systems Manager のエンドポイントと通信できる環境であれば、文字通りどこでも実行できます。ECS のエンドポイントとしては以下のドメインと通信します。
 
* `ecs-a-*.<region>.amazonaws.com`
* `ecs-t-*.<region>.amazonaws.com`
* `ecs.<region>.amazonaws.com`

`ecs-a-*` と `ecs-t-*` のエンドポイントについては PrivateLink に対応していないため、DirectConnect を使用して完全な閉域 NW 経由で実行することは現時点で難しそうです (Public VIF を利用している場合を除く)。

### Docker のインストール
実行環境となるサーバー、仮想マシンには Docker がインストールされている必要があります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125105/ed2877d9-04f2-3227-631a-d67413a31d83.png)

### SSM Agent のインストール 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125105/a6984cfa-37f0-ef05-e438-687d811b89d3.png)

実行環境となるサーバー、仮想マシンに AWS Systems Manager の SSM Agent をインストールし、ハイブリットアクティベーションによりマネージドインスタンスとして登録する必要があります。マネージドインスタンスは Systems Manager に以前から存在する機能で、オンプレミスのマシンに SSM Agent をインストールし、アクティベーションコードを登録すると、AWS 上からマネージドインスタンス (プレフィックス「mi-」が付いたマシン) として管理できるようになります。

マネージドインスタンスを使用すると、オンプレミスのマシンに対してハイブリット環境用の IAM サービスロールを割り当てることができます。この IAM ロールを通じて提供される一時クレデンシャルを利用することで、Amazon ECS やその他の AWS サービスと通信できるようになるわけです。オンプレミス環境ごとにアクセスキーを発行して、定期的にローテーション、、、というような面倒でリスクのある作業は不要です。

**参考**

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-service-role.html

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-anywhere-iam.html

### ECS Agent の起動
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125105/48c68ada-8247-f998-f149-d16552c21b2e.png)

Amazon ECS コンテナエージェントをインストール、起動します。ECS Agent はマネージドインスタンスに割当られた IAM ロールの認証情報を利用して ECS のコントロールプレーンと接続します。これで ECS API 経由でコンテナを起動できるようになります。

長々と説明してしまいましたが、準備が面倒そうだなと感じましたか？
ECS で External インスタンスを登録する際に表示されるスクリプトを実行すると、Docker のインストール、SSM Agent のインストールとマネージドインスタンスの登録、ECS Agent の起動まで 1 発でセットアップしてくれるため、実はめちゃくちゃ簡単です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125105/86a6cae0-cb53-7ec4-dc12-e7e1f9f53e65.png)

### これが ECS Anywhere だ!!
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125105/01ba5cf0-0753-6bbd-1fcb-f43e131ad751.png)

セットアップが完了したらマネージドコンソール、CLI、使い慣れたデプロイツールなどからサービスやスタンドアロンタスクを起動できるようになります。これらのコンテナが NLB や RDS といった VPC 上のリソースと通信する必要がある場合は、Direct Connect または Site-to-Site VPN 接続が必要です。

## 利用料金
ECS Anywhere の利用料金として、External インスタンス 1 台ごとに1 時間あたり、$0.01025 かかります。External インスタンス＝登録するホスト環境なので、コンテナの台数ではありません。1 台あたり月 1,000 円弱といったところでしょうか。
 
https://aws.amazon.com/jp/ecs/anywhere/pricing/

Systems Manager は基本的には無料で利用可能ですが、マネージドインスタンスのアドバンスドインスタンス層を使用する場合は料金が発生します。ECS Anywhere としては無料の標準インスタンス層で問題ありませんが、以下のケースではアドバンスドインスタンス層を利用する必要があります。

* マネージドインスタンスの管理台数が1アカウント、リージョンで  1,000 台を超える場合
* Session Manager でマネージインスタンスにリモート接続したい場合

アドバンスインスタンス層はインスタンスごとに 1 時間あたり $0.00695 かかります。1 台あたり月 500 円くらいです。

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-managedinstances-advanced.html

## ECS Anywhere の利点とユースケース
ECS Anywhere の製品ページには以下のような利点とユースケースが記載されています。

https://aws.amazon.com/jp/ecs/anywhere/

### 利点
* フルマネージドなコントロールプレーン
    * 自前でコンテナオーケストレーションの仕組みを構築、運用する必要がない
* オペレーションの統一
    * AWS でもオンプレミスでも、同じツールを用いて運用することができる
* ハイブリット対応
    * EC2, Fargate, External インスタンスを同じクラスター内に配置可能

###  ユースケース
* コンプライアンス & ビジネス要件
* 既存のオンプレミスワークロードのコンテナ化
* エッジコンピューティング (低レイテンシーが要求されるワークロード)
* 既存の設備投資を活用
* オンプレミスで実行しつつ追加容量はクラウドにバースト

注目すべきはオンプレミスにおけるコンテナワークロードに特化している点だと考えています。AWS としてマルチクラウドのユースケースは (現時点で) 謳っていません。これは他社とは異なる傾向です。


## 類似サービスとの違い
Microsoft や Google Cloud もオンプレミスやクラウド環境でコンテナ化したアプリケーションを実行可能にする Azure Arc や Anthos といったサービスを提供しています。また AWS は 2021/9/8 にAmazon EKS Anywhere の一般提供を開始しました。これらのサービスは一見 ECS Anywhere と同じような機能を提供するようにも見えますが、根本的に異なる点が 2 つあります。

### ECS Anywhere はフルマネージドコントロールプレーンである
マルチクラウドで実行される Kubernetes を統合管理可能な [Azure Arc enabled Kubernetes](https://docs.microsoft.com/ja-jp/azure/azure-arc/kubernetes/overview) やオンプレミスおよびマルチクラウド環境で Google Kubernetes Engine を動作させることができる [Anthos クラスタ](https://cloud.google.com/anthos/clusters?hl=ja) は Kubernetes をベースとしている関係で、コントロールプレーンもユーザー環境で動作することになります。

例えば Anthos clusters on AWS の場合、ざっくりと以下のような構成になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125105/bb33abf8-88c1-b695-6b38-433bbefa2297.png)

https://cloud.google.com/anthos/clusters/docs/aws/concepts/architecture?hl=ja

ECS Anywhere の場合、AWS 上でフルマネージドされている ECS のコントロールプレーンを利用してコンテナをオーケストレーションできます。つまりユーザーは External インスタンス上でコンテナを稼働させることだけに集中できると言えます。

### マルチクラウドで AWS サービスを展開することはできない
自明なことではあるのですが、ECS Anywhere 上では AWS のサービスを実行することはできません。Azure や Google Cloud は他社クラウドやハイブリット環境で動作する自社サービスを提供することで、クラウド間でのデータ移動を必要とせずにあらゆる環境で一貫性のあるエクスペリエンスを提供する方向性です。ECS Anywhere は前述のとおりオンプレミス環境でのコンテナワークロードの実行に特化しており、この点からも AWS は現時点でマルチクラウドには注力していない状況が伺えます。

Google Cloud は Anthos クラスタ上で動作する BigQuery Omni や Cloud Run for Anthos といったサービスをリリースしています。

https://cloud.google.com/blog/ja/products/data-analytics/introducing-bigquery-omni

Microsoft は Microsoft Build 2021 で Azure App Service や Functions, Logic Apps, API Magement, Event Grid といった Azure サービスをどの Kubernetes 環境でも実行できるようにする Azure Arc enabled application services を発表しています。

https://azure.microsoft.com/ja-jp/blog/build-cloudnative-applications-that-run-anywhere/

## 現時点で ECS Anywhere でサポートされない機能
* Service Load Balancing
* Service Discovery
* Capacity Provider
* UpdateContainerAgent API によるリモートでの ECS Agent アップデート
* AWS AppMesh との統合
* SELinux
* Amazon EFS ボリュームの使用

一番大きいのはサービス負荷分散に対応していない点ではないでしょうか。サービス負荷分散は ELB といい感じに連携してタスク間でトラフィックを分散する機能です。サービスの作成、更新時に「ネットワーク、ロードバランシング、オートスケーリングの設定は、EXTERNAL 起動タイプでは使用できない」というメッセージが表示されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125105/b9bde9f9-c92a-7f62-c3dc-a82405f6b507.png)

External インスタンスの IP アドレスとコンテナが使用するポートを手動で ELB に登録することはできますが、本番ワークロードでの Web サービスの実行は現実的ではありません。この点は[ドキュメント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-anywhere.html#ecs-anywhere-networking)にも明確に記載されています。

**引用 & 参考訳**
> Amazon ECS 外部インスタンスは、アウトバウンド トラフィックを生成したり、データを処理したりするアプリケーションを実行するために最適化されています。アプリケーションで Web サービスなどのインバウンド トラフィックが必要な場合、Elastic Load Balancing のサポートがないため、これらのワークロードをロードバランサーの背後に配置することがサポートされていないため、これらのワークロードの実行効率が低下します。

## まとめ
### Amazon ECS Anywere のいいところ
* コントロールプレーンを一切管理せずに、コンテナをオーケストレーションできる
* 普段 AWS で使用しているものと同じツール群で運用できる

### これからに期待するところ
* Web サービスの実行には向かない
    * ECS Anywhere が ELB をサポートしておらず、Service Load Balancing を利用できないため
    * 現時点ではデータ処理系のアプリケーションの実行に最適化されている
* マルチクラウドを想定したサービスではない
    * オンプレミスにおけるコンテナワークロードに特化
    * もちろん他クラウドの VM を External インスタンスとして登録してコンテナ実行することは可能


## 参考
https://aws.amazon.com/jp/blogs/news/building-an-amazon-ecs-anywhere-home-lab-with-amazon-vpc-network-connectivity/

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-anywhere.html

以上です。
参考になれば幸いです。