KDDIのエンジニア情報ポータル
2022/01/28
Cloud to Ground ハイブリッドクラウドは、パブリッククラウドで提供されているクラウドベンダーのサービス全てまたは一部をオンプレミスで稼働させるためのプラットフォームまたは技術の総称を指します。 本検証では、すでにAWS上でマネージドサービスを用いて稼働しているシステムに対しAmazon ECS Anywhereを利用し、オンプレミスへ拡張することを検証し、実現方法や課題を明確にすることを目的としています。
Amazon Elastic Container Service (ECS) Anywhere は、カスタマー管理のインフラストラクチャでコンテナのワークロードを簡単に実行および管理することを可能にする Amazon ECS の機能です。 ECS Anywhere は、Amazon ECS の使いやすさとシンプルさを土台として構築されているため、コンテナベースのアプリケーション全体で一貫したツールと API エクスペリエンスを提供します。オンプレミスでもクラウドでも、Amazon ECS で使い慣れている同様のクラスター管理、ワークロードスケジューリング、およびモニタリングを利用できます。 Amazon ECS Anywhere に関する詳細はこちら https://aws.amazon.com/jp/ecs/anywhere/
本システムの用途
インターネット上に存在するユーザに対して提供するWebサービス基盤**
利用サービス
Amazon ECS Anywhere稼働環境
前述の"Amazon ECS Anywhere稼働環境"にて、Amazon ECS Anywhere を稼働させ、その際に解決が必要だった事項を洗い出しを行いました。その結果を下記の考慮事項および課題として記載します。
オンプレミス側ノードをECS 外部インスタンスとして登録し、ECSコントロールプレーン配下のインスタンスとして管理するためには https://ecs-xx.ap-northeast-1.amazonaws.com/ へのHTTPS(TLS)接続が必要となる。https://ecs-xx.ap-northeast-1.amazonaws.com/ はリージョンサービスとしてインターネット経由でアクセスが必要なため、ECS 外部インスタンスはインターネットへの接続性を確保しなければならない。
外部インスタンス(オンプレミス側ノード)、外部インスタンス上で稼働するコンテナの正常性監視は、ECS AnywhereのAgentが提供するが、それだけでは不完全なため、個別のモニタリングを適用する必要がある。
例えば、コンテナ(タスク)が稼働するノードが停止した場合、タスクがSTOPとならずRUNNINGのままになることがある。(ノードが復旧した際にSTOPにステータス変更する)
さらに、タスクのステータスはノード内のECS Agentから送信されるため、タスクのステータスが更新される前にノード(またはECS Agent)が停止してしまうとタスクのステータスはその時点のままの状態となり更新されない。
ECS Anywhereは、Fargateとネットワークモードが変わるため、bridge もしくは host のネットワークモードを選択する必要がある。bridge もしくは hostネットワークモードを用いた場合もexposeするポートを重複することができないため、bridgeモードにてホスト側でエフェメラルポートを利用してコンテナとのポートバインディングを構成する必要がある。
Amazon ECS Fargateでは、ホストを意識する必要がないため、コンテナに対しExposeしたポートへの接続性のみを意識すれば良いが、Amazon ECS Anywhereではコンテナに対しExposeしたポートはホスト側でエフェメラルポートとポートバインディングする必要があるため、動的なポートバインディングを管理し、エフェメラルポートとコンテナの紐づけを行うためのサービスディスカバリが必要となる。Amazon ECSでは、Amazon Cloud Map、AWS App Meshなどを利用することでサービスディスカバリを適用することが可能だが、Amazon ECS Anywhereではこれらのサービスは対応していない。Istio もしくは Contourなどを自身で適用し、サービスディスカバリおよびIngress Gatewayを用意する必要がある。
オンプレミス側にマネージドサービスの代替となるミドルウェアなどを構築することなく、AWSとのDirectConnectを用意し、AWS上で稼働するマネージドサービスを利用する方法がある。いずれにしても、ECR、S3、Kinesis Firehorse、CloudWatchなどリージョンサービスへのアクセスが必要となるため、AWS障害発生時などオンプレミス環境単独での動作を求められる環境以外では、AWS上で稼働するマネージドサービスを利用する方が効率的な場合も考えられる。
オンプレミス側へのリクエストは、明示的にAWS WAFを通るように名前解決および経路を設定する必要がある。場合によってはAWS WAFを利用せずに、攻撃遮断くんなどの3rd Partyサービスを利用する方が名前解決および経路の管理工数を削減できる可能性がある。
Amazon ECS Anywhere は、「コンプライアンスとビジネス要件を満たすのに役立つ」、「既存のオンプレミスワークロードをコンテナ化する」、「エッジでのデータ処理ワークロード」、「必要に応じてクラウドにバーストする」、「既存の設備投資を活用する」、「オンプレミスの機械学習や動画処理のワークロード」を目的に提供されており、一見Webサービスなど外部トラフィックを処理する環境においても適用可能なサービスに見えますが、現時点では外部トラフィックを処理する用途としては適していないことがわかりました。 Webサービスにおけるエッジ処理などの用途で Amazon ECS Anywhere を利用する際は、自身で解決しなければならない課題が多く存在することを念頭に検討する必要があります。