この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ども、もこ@札幌オフィスです。AWS Summit Tokyo 2023に参加しています！！
本日は、2日目 AWS-25 「オンプレミスで始めるモダナイゼーション 〜 AWS のハイブリッドコンテナ環境の最新情報」のセッションを見させていただきましたため、セッションレポートを投稿させていただきます。
セッション概要
アマゾン ウェブ サービス ジャパン合同会社
コンピュート事業本部
ソリューションアーキテクト コンテナ担当
林 政利氏
オンプレミスからモダナイゼーションを進める際、その第一歩はクラウドへのシフトだけではありません。Amazon EKS、Amazon ECS はクラウドのみならず、オンプレミス、エッジなどさまざまな場所でコンテナを管理できます。このセッションでは、AWSのハイブリッド Kubernetes の最新情報と、モダナイゼーションの多様な選択肢について議論します
セッションレポート
セッションのゴール
- AWSコンテナサービスのオンプレミス運用の選択肢を理解する
- オンプレミスにおいて、コンテナ化したアプリケーションの運用をする方法をご紹介
- 一方で、「コンテナ化する」は一言では表せないリファクタリング・リアーキテクティングもあるが、本セッションでは触れないが、重要な箇所
アジェンダ
- なぜクラウドへ移行できないのか
- オンプレミス環境で「すぐに」コンテナ化する選択肢
- AWS Outposts
- Amazon EKS / ECS Anywhere
- AWSとオンプレミスの接続洋件
なぜクラウドへ移行できないのか
- モダナイゼーションを考えたとき、クラウドに移行してからコンテナ化する選択肢もある（リホスト)
- オンプレにあるVMをAWS Application Migration ServiceでAWSに移行した後に、コンテナ化してECS/EKSに移行する場合
- 実際に多くのお客様がこの手法を採っている
- お客様によっては、オンプレミスから動かすことが難しくて、リホストの作業が進まない、リホストに時間と予算を使ってしまいリホストで止まってしまう場合がある
- リホスト自体はできるが、なかなかコンテナ化に着手できないといった話がよくある
- アプリケーションがクラウドに移行できない理由
- 性質上、オンプレミス環境で動かす必要がある
- 低レイテンシー
- 証券など、公平性の観点から、超低遅延で、遅延にばらつきがないように処理をする必要がある
- データを置く場所に制限がある場合。社内のポリシーや、業界のポリシーなど
- そもそも、外部ネットワーク接続が無い場合
- 海の上、空の上など
- 膨大な工数が掛かるためすぐに移行できない
- 社内基盤の移行が困難
- オンプレミス環境に大規模なデータがある場合
- データグラビティー
- 既存のデータセンター投資がある場合
- 既にオンプレミス環境に対して大規模な投資を行っているため、クラウドには移行できない
- オンプレミスにおいても、コンテナ化するためには、何らかの形で運用する必要がある
- 一点だけ確認しておくべき箇所として）本当にクラウドに移行できないのかを確認する必要がある
- 例えば低遅延の場合、ネットワークではなくアプリケーションの処理そのものに時間が掛かっているパターンがある
- アプリケーションの実装が問題で遅延が発生している場合、それをクラウドに持っていっても問題は無いはず
- クラウドはCloudFrontのEdge Locationがあるのでそれで賄えないか等を検討
- それらを検討してもクラウドに持って行けないと判断した場合は、オンプレミスでもECS/EKSを利用する方法をご紹介
オンプレミス環境で「すぐに」コンテナ化する選択肢
- オンプレミスでコンテナを活用する方法
- EKS / ECS on AWS Outpostsを活用する事により、オンプレミスであっても、フルマネージドのECS/EKSを利用する事ができる
- 様々な理由でOutpostsが利用できなかったり、手元にあるサーバーを活用したい場合、ECS/EKSを管理できる、 ECS Anywhere, EKS Anywhereを活用してコンテナをデプロイすることもできる
- クラウドに対しての移行に時間が掛かってしまうケースが結構あるが、事前にオンプレミス側でコンテナ化しておくことで、クラウドに移行するタイミングですぐにクラウドに移行できる
- ECS Anywhere, EKS Anywhereを使っておくことで、クラウドにも、オンプレミスにも両方の環境でデプロイ出来るようになる
オンプレミスでコンテナを運用するためのAWSサービス
- まず選択するべき内容は「Kubernetes」が必要かどうか
- Kubernetesを利用する必要は無い場合は、ECSを利用
- Managedで管理したい婆は AWS Outposts, 所有しているハードウェアを利用する場合はECS Anywhere
- Kubernetesが必要な場合は、 AWS Outposts もしくはEKS Anywhereを利用できる
- AWS Outposts
- AWSのラックをオンプレミス環境に設置して、
- AWSのリージョンがオンプレミスまで伸びてくるようなイメージ
- 基盤のアップデート・パッチと行った管理は、AWSの東京リージョンと同じように、AWSがオンプレミスでも担当してくれる
- Outpostsの上でESC, EKSを実行することができる
- AWSのリージョンの上で動いているECS/EKSのコントロールプレーンがオンプレミスにあるコンテナも管理するようなモデルで動作する
- クラウドのリージョンがオンプレミスまで伸びてくるようなイメージと合致するように動く
- Outpostsでは、フルマネージドなECS/EKSが使えるので、運用・管理コストの点からはOutpostsを利用するのが最適
- 既にオンプレミス環境に対して多くの投資を行っていて、大量のサーバー、GPUがある場合、Outpostsがオンプレミス環境のデータセンターにマッチしない、コスト面から利用できない場合
- EKS Anywhere, ECS Anywhereを使う事ができる
- ECS Anywhere
- 今持っているサーバーをAWSのクラウド上にあるECSのコントロールプレーンに接続して、オンプレミスのサーバーの上でコンテナを管理できる、ECSの機能
- ECS Anywhereを利用すると、AWSのコンソール上で、コンテナをデプロイすると、オンプレミスのサーバー上でコンテナを実行・起動・死活監視などの管理作業ができる
- ECS Anywhereの場合、Kubernetesではないので、管理が楽
- ECS Anywhereのユースケース
- 現時点ではロードバランサー、サービスディスカバリーをサポートしてない
- 外部から通信を受けたり、ワークロード同士が通信する場合は作り込みが必要
- 何らかの処理を内部で行って結果を外部に送信するような場合は、機械学習やバッチのワークロードなどでは最適なサービス
- 外には出しにくいデータや、大量にあるGPUリソースを使ってオンプレミスで処理して、モデルを学習。S3に結果を保存などもできる
- オンプレミス環境に対してもIAMが利用できて、権限管理ができる。
- SageMakerを使ってS3にアップデートしているモデルを使って推論エンドポイントを作成することもできる
- EKS Anywhere
- 自身のサーバーでKubernetesのクラスターを実行できる
- Kubernetesを既に活用されていたり、オンプレミス環境に大量のアプリケーションやマイクロサービスがある場合に検討できる
- コマンドラインのツールを提供していて、手元でコマンドラインツールを利用することで、Kubernetesクラスターを管理することができる
- Kubernetesのクラスターを良い感じに管理できるのがEKS Anywhere
- EKS Anywhereは、Amazon EKS Distroを使っている
- Kubernetesを実行するためには、オープンソースで開発されている様々なコンポーネントを組み合わせてクラスタを提供する必要がある
- etcd, API Server, Controller Manager, kube-proxy, CoreDNSなど・・・
- Amazon EKS Distroは、それらのコンポーネントをまとめて管理されているDistro
- 安定したKubernetesクラスターを管理するためには、それぞれのコンポーネントに対して互換性があるかを確認したり、負荷試験などの検証が必要
- 例えばEKSでKubernetes 1.22を導入しようとした場合
- etcd 3.5 には高負荷時におけるバグがあった
- EKS 1.22の場合には、 etcd 3.4を導入するように決定して、 etcd 3.5の問題点をAWSのエンジニアが協力して修正するといった事をしていた
- EKSが安定したクラスターを提供するために様々な検証をしているが、それらを EKS Distroにまとまっている
- EKS AnywhereでEKS Distroを利用すると、それらの検証を全て通った安定した環境を簡単に用意できる
- VMware vSphere, Nutanix, CloudStack ベアメタル環境などで可能
- EKS Anywhereはシングルノードでもクラスタ構築が可能
- コマンド一発でDHCP, TFTP, Controll Planeを作成可能
- Node側はiPXEブートでネットワークブート
- 作成後、通常通りkubectlで使用可能になる
AWSとオンプレミスの接続要件
- AWS Outposts
- AWSとOutposts間で安定した通信が必要
- 特にEKSの場合、KubernetesのControll Planeがクラウド上にあるため、クラウドと接続ができなくなった場合はコンテナの管理ができなくなり、アプリケーションのダウンタイムが発生する場合もある
- Outposts上でKubernetesのControll Planeを起動するオプションもある
- この場合においてもクラウドのとの通信が切れた場合は、様々な考慮が必要
- 例えばAWSLoadBalancerControllerを利用している場合、通信が切れるとコンテナがロードバランサーにぶら下がらなくなる
- ECS Anywhere
- コンテナの管理はAWS上で行っているため、接続が切れるとコンテナを管理できなくなる
- EKS Anywhere
- AWSと接続しながら使うこともできるし、使わないこともできる
- EKS Anywhereで構築した物は、独立してAWSとは関係無いクラスターになる
- AWSフルマネージドだけど、AWSとは繋がらないクラスターもできる
- インターネットに繋がっていない状態でも利用可能
- EKS Anywhereにアドオンを入れると、AWSコンソ−ル上で確認することが出来るようになる
まとめ
- オンプレミスでそのままコンテナを実行するオプションを紹介
- 今回紹介したような様々なハイブリッドオプションがあるので、状況に合わせて好きな所にデプロイできる
- ECS Anywhere, EKS Anywhereはすぐに試すことがあるので、ぜひこのあと触ってみてください！
感想
普段業務でコンテナを使っているため、ECS Anywhere, EKS Anywhereでのコンテナ実行について学べる面白いセッションでした。
また、普段触る機会が無いOutpostsを活用したオンプレミス環境でのコンテナ実行の例が見れて、個人的にはめちゃめちゃテンションがあがるセッションでした。
AWS Summit Tokyo 2023では、 会場内に実際にAWS Outpostsや400G Switch, Nitro, Graviton等が展示されています。ぜひ一度実物をご覧になってみてはいかがでしょうか！
0
