TL;DR
- Kubernetesはマイクロサービスには適しているが複雑
- 未だに学習コストが高く、周辺ツールにも振り回される
- ECSはKubernetesよりはるかに運用しやすい
- AWSへのベンダーロックインによる悲観は必要ない
- Kubernetesのデメリットを把握した上で導入するべき
オーケストレーションツール
KubernetesとAmazon ECSは、同じくDockerコンテナのオーケストレーションツールに位置する。
そもそもオーケストレーションツールはなぜ必要かというと、プロダクションレベルでの運用を実現するためである。複数ホストに分散されて起動されているDockerコンテナの死活監視、オートスケーリングなどを管理するのはそう簡単ではない。これらの課題を解決するためにKubernetesやECSなどのオーケストレーションツールが存在している。
Kubernetes
このツールの代表的な存在にあるのがKubernetes。KubernetesはGoogle内で利用されていた「Borg」というツールがオープンソース化したものであり、現在は様々な開発者やクラウドプロバイダによってメンテナンスされている。
Amazon ECS
Amazon ECSは、AWSが提供するコンテナのオーケストレーションサービス。ECSはKubernetesにある様々な概念をなくし、ライトなオーケストレーションツールという位置付けになる。必要なタスク定義（起動するコンテナ数やリソースなど）を指定すれば、それだけでECSがマネージドよろしく管理してくれる。
Kubernetesの懸念点とは何か
サービス/チームへの過剰な権限管理
KubernetesはNamespaceというサービスの空間のようなものを設定し、このNamespaceごとに細かく権限を与えられる。これにより、例えば各マイクロサービスチームが1つのサービスを自律的に運用することが可能になる。
マイクロサービスのアーキテクチャならまだしも、一つのアカウントで複数のモノリシックサービスを運営するケースにおいては不要と言いきれる。各チームへKubernetesの基礎を教え、そして「これからは自立して運用してくださいね」と言っても、そこに何もメリットは無いし、多くの組織ではスキルセット的に難しい。
インフラが属人化すること
Kubernetesは様々な環境や用途を想定して高度に抽象化されており、自分の組織で運用するために具象化していくのには、ECSに比べて多くの時間やリソースが必要になる。後述する周辺ツールの乱立期を踏まえると、Kubernetesがただの時間泥棒になる恐れを感じている。
カナリアデプロイは必要か
KubernetesのContinuous Deliveryツールとして「Spinnaker」が有名であり、Spinnakerはカナリアデプロイを行える。ただカナリアデプロイがKubernetesを導入する理由となるかは怪しい。多くの場合、ブルー・グリーンデプロイメントで十分だし、そもそも毎回カナリアを使わなければならないほどデプロイを恐れている状態は不健全であり、根本的な解決にはならない。
またSpinnakerそのものの構築や運用も必要になる。私もSpinnakerの構築をしたことがあるが、多くの人が導入や運用にハマるような印象を受けている。それに対しAWSではマネージドなデプロイサービスであるCodeDeployを提供し、CodeDeployはECSへのブルー・グリーンデプロイメントをサポートしている。もちろんCodeDeployは構築や運用の手間は必要ない。
App Meshの登場
サービスメッシュは各マイクロサービス間の通信やその経路を制御するための考え方であり、これらは複数のサービスにまたがって考慮しなければならない。ECSでは現状、サービスメッシュの導入は難しいが、KubernetesではIstioやEnvoyなどを使って導入することができる。
ただECSやEKSに統合できるマイクロサービスの管理基盤としてAWS App Meshのようなものも出ている。（まだ正式にリリースされているわけではない。）こうしてAWSがマネージドなサービスを出していく中で、Kubernetesを自分達自身で運用していくメリットは、次第に小さくなっていくだろう。
非ベンダーロックインであるべきか
Kubernetesの利点を一つ上げるとなれば、特定のベンダーに依存しない点がある。Amazon ECSではAWSでの稼働を前提としており、例えばGCPや自社サーバーではKubernetesを使うしか他ない。
このように「ベンダーへ依存してしまうことがECSを使うべきではない理由だ」という意見もある。しかしベンダーロックに関しては事実避けられないものであり、クラウドをAWSから他に移動するという事もほぼ起こりえない。仮にクラウドを移行することになっても、ECSで10～30個のモノリシックサービスが運用されている程度では移行の障壁となるとは到底思えない。
周辺ツールの乱立期
もしECSを使う場合、アプリケーションの設定やContinuous Deliveryの構築まで、全てTerraform上で完結できる。例えばNuxt.jsをECSで動かしてCodePipelineでCDしたい、となれば全てこのTerraformリポジトリのように1リポジトリで管理することができる。
しかしKubernetesの場合、HelmやKustomizeなどを使ってのYAMLの作成や、必要であればSpinnakerとの統合も行う必要がある。個人的にKubernetesのYAMLの管理はツールが多すぎてとっつきづらい。未だに周辺ツールの乱立期から抜けられていないし、ツールに振り回されるという印象も否めない。
結論
AWS使えてECSで十分なら、ECSでいこう。
上述の通り、Kubernetesを使う理由は、多くの組織には存在しない。ECSで本番レベルのDockerアプリケーションを十分に運用できる。
Kubernetesでしかできない試みとしてKubernetesで数百以上のDocker開発環境を運用していたりする。採用のアピール活動としてKubernetesを導入する場合は、慎重に考えていきたい。