AWSのコンテナ責任者が語るFargate、ECS、App Mesh、EKS、そしてKubernetes：AWS Summit Tokyo 2019で聞いた（2/2 ページ）

[三木泉，＠IT]

　「現在、モノリシックなアプリケーションを運用しており、今後どのようなアーキテクチャに移行しようか迷っているところがある。Fargateを使うか、ECS、あるいはEKSに移行するか、どんなマイクロサービスを使うか、即座に決めたくはない。そこで、まずApp Meshを適用した上で、ゆっくりとアプリケーションを小さな単位に切り出していく。こうすれば、App Meshによって管理される部分はそのままで、現在の状態から、将来進みたい方向への道筋を描くことができる。その上で、何をやっているかをより綿密に可視化し、トラフィックについてもよりきめ細かく制御できるようになる。はっきり言って、多くの顧客は現在のところ、マイクロサービス化をどうすべきか決めかねているところがある。こうした顧客は、今話したような考え方に共感できると思う」

　App Meshでは、さまざまなアーキテクチャのアプリケーションを対象とし、場合によっては異なるスタイルのアプリケーションを組み合わせる形で統合的な運用ができる。

　「運用担当者はどのようなアプリケーションについても、一貫した可視性を確保できる。一方、アプリケーション開発者は、自分たちのやりたい方法で開発が行える。アプリケーションをメッシュにデプロイすれば、適切な通信、ポリシー、可視化ができるという安心を得ることができる」

　App Meshは今後、ECSとの緊密な統合、さらにLambdaへの対応が予定されている。

デベロッパーエクスペリエンスをどう改善できるか

　コンテナサービスに関連して、シン氏はAWSにおけるデベロッパーエクスペリエンス改善への取り組みを強調する。

　「この点で重要な取り組みの一つは、『AWS Cloud Development Kit（CDK）』だ。現時点では開発者プレビューを提供している。CDKは『Infrastructure as Code』を実現するツールで、宣言的なJSONやYAMLの代わりに、例えばJavaScriptでアプリケーションに必要なインフラ要素を定義し、（CloudFormationで）デプロイできる。このCDKで、Fargate、ECSなどのユーザーが最大のメリットを得られるよう、必要なコンストラクトを全てCDKに組み込んだ。CDKは、真にエキサイティングだと思う。開発者が、自分たちの日常的に使っている開発言語を用い、コードだけでアプリケーションサービス全体を動かせるからだ。（現在JavaScript、TypeScript、Python、Java、.NETをサポートしているが）利用できる言語をさらに増やしていく計画だ。オープンソースプロジェクトなので、顧客がコントリビュートすることもできる。Pulumiなども近いことをやっているが、こうした新たなモデルは、顧客の間で大きな人気を獲得するようになるだろう」

　別の取り組みには、各種のCI/CDパイプラインツールとの連携強化があるという。

　「例えば、AWS上で広く使われているツールの一つにSpinnakerがある。そこでAWSでは、Spinnakerプロジェクトに、ECSやFargateとの連携を強化するコードをコントリビュートするなどしている」

「AWSはKubernetesを動かす最善の場所であり続ける」

　上記の通り、AWSではECSで他サービスとの高度な統合を含め、開発者がよりアプリケーションに専念できるような環境を整備していく。だからといって、KubernetesやKubernetesベースのコンテナサービスであるEKSを軽んじるつもりはないという。

　「AWS上でKubernetesを使う人たちには、幾つかの種類があるが、典型的なのはKubernetesでコンテナの世界に入った人たち、そしてオンプレミスでKubernetesを使ってきた人たちだ。Kubernetes環境でさまざまなツールを構築し、ノウハウも蓄積している。こうしたスキルを生かし続けたいと考えている人たちが多い。また、Kubernetesのエコシステムに魅力を感じている人たちもいる。例えば機械学習でKubeflowを使いたいと考えている人がいる。この人たちにとって、Kubeflowが快適に使えるためには、Kubernetesがうまく動作する必要がある。そしてもちろん、Kubernetesを熱烈に愛する人たちがいて、クラウド上でも自らチューニングを加えながら、Kubernetesを運用したいと考えている。こうした顧客全てにとって、AWS上のKubernetes体験が素晴らしいものであり続けるよう、私たちは努力し続ける必要がある」

　EKSでは、ミッションクリティカルな用途で利用しているユーザーのため、特に高いサービスレベル、可用性の確保とコンプライアンス対応に力を入れているという。一方、EKSを使わずにKubernetesを自らAWS上で運用するユーザーも多く、こうしたユーザーに向けた努力も続けていくという。

　「例えばEKSにおいて、ネットワークプラグインや認証をはじめとし、何らかの機能を追加した場合、アップストリームコミュニティーに必ず還元する。これにより、自身でKuberentesクラスタを運用する人たちも、同様なメリットを得られるようにしている。こうして、KubernetesをAWSで使う人たちが、『自分たちは最良の判断をした』と確信できるように努力していきたい」

オンプレミス、IoT／エッジにおけるコンテナ環境は？

　AWSは、コンテナ環境のハイブリッドクラウド、エッジ／IoTにおける展開については、どのような方針なのだろうか。例えばGoogle Cloudにおける「Anthos」のようなサービスは考えていないのだろうか。

　これについて聞くと、ハイブリッドクラウドについては、EKSと「AWS Outposts」の組み合わせを推進すると、シン氏は答えた。現在プライベートプレビュー段階のOutpostsは、オンプレミスのデータセンターにAWSのプラットフォームをハードウェア込みで持ち込み、動かすもの。AWSはこの上でEKSを、マネージドKubernetesとして提供する計画がある。

　ハードウェア込みのソリューションは「重い」のではないかと聞くと、「電源を入れてネットワーク設定をするだけなので、これ以上導入が簡単なものはない」と答えた。

　他に、一般的なオンプレミスKubernetes環境を使うという選択肢もあると、シン氏は話す。AWSのサービスと高度に連携するわけではないが、例えばオンプレミスで開発したコンテナアプリケーションをEKSやAWS上のKubernetes環境で動かすことができる。

　では、IoT／エッジについてはどうか。AWSがこの分野に向けて提供している「AWS IoT Greengrass」「AWS Snowball Edge」におけるローカルなアプリケーション実行環境は、Lambda（とEC2インスタンス）だ。だが、エッジでコンテナ環境を動かしたいというニーズは高まっているのではないか。シン氏の答えは次の通りだ。

　「顧客からそうしたニーズを聞くことは、確かに増えてきた。そこで、適切なやり方は何なのかを考えているところだ。現時点で話せることは何もないが、私たちは確実に、検討を進めている」