スタートアップのためのコンテナ入門 – Kubernetes 編

こんにちは、スタートアップソリューションアーキテクトの松田 (@mats16k) です。

「スタートアップのためのコンテナ入門 – 導入編」「スタートアップためのコンテナ入門 – AWS Fargate 編」という記事を公開してきましたが、Kubernetes に興味があるスタートアップも多いのではないでしょうか。今回は Kubernetes にフォーカスしてお話しします。

なお Kubernetes 以前に、「そろそろコンテナやった方がいいか？」「なんとなく使い始めたけれどこれでいいのか？」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といった漠然とした課題感をお持ちの方は「スタートアップのためのコンテナ入門 – 導入編」から目を通して頂ければと思います。

Kubernetes とは

ご存知の方も多いかと思いますが、改めておさらいです。
Kubernetes はオープンソースのコンテナオーケストレーションツールで、Cloud native Computing Foundation (CNCF) が開発プロジェクトをホストしています。CNCF は Kubernetes だけでなく、他の関連するプロジェクトもホストしています。（Prometheus や Envoy といったソフトウェアは聞いたことがある方も多いのではないでしょうか。）

Cloud Native Computing Foundation

では Kubernetes の仕組みについて簡単に触れていきましょう。

Kubernetes クラスターはマスターノードから成る「コントロールプレーン」と、実際にコンテナ稼働するワーカーノードから成る「データプレーン」から構成されます。
コントロールプレーンにはクラスターの情報を保持する etcd や、どのノードで Pod を動かすかをコントロールする kube-scheduler 、API を提供する kube-apiserver などが含まれます。また、各ワーカーノード上には kubelet と呼ばれるエージェントが動いており、各 Pods はこの kubelet を介して実行されます。
開発者は kubectl という CLI ツールを介し、マスターノード上の API Server へリクエストを送ることで、Kubernetes 上のオブジェクトをコントロールすることになります。

Kubernetes Components

この図からも読み取れるかと思いますが、Kubernetes を利用するには多くのコンポーネントが必要です。Kubernetes を利用した開発を行う際は、これらのコンポーネントの運用とどう向き合っていくのかということが重要となってきます。

※ AWS コンテナヒーローの九岡佑介さんに AWS Summit Tokyo 2018 でお話し頂いた「仮想マシン、コンテナ、関数、Kubernetes on AWS の活用方法と展望 #2」や、直近のインタビュー記事である「スタートアップ企業への Kubernetes 導入に必要なこと – Kubernetes エキスパートとコンテナスペシャリスト SA が考える適切な活用法」でも触れているので、合わせてご覧ください。

スタートアップにとっての Kubernetes

急速に注目を集めているコンテナのオーケストレーションツールの Kubernetes ですが、スタートアップのお客様からもよくご相談を頂きます。ではスタートアップにとっての Kubernetes とはどのようなものなのでしょうか。またどの様なお客様が Kubernetes を検討しているのでしょうか。
ここではスタートアップの状況を踏まえた上で、考慮すべきことに触れていきます。

運用について考慮していないスタートアップは多い

前述の通り Kubernetes を利用する際には、多くのコンポーネントの運用が必要不可欠です。しかしながら、技術的な特性やトレンドのみに目を向け、在籍するエンジニアのスキルセットや、組織のリソース/オペレーション、自社のプロダクトの価値向上について考慮していないスタートアップが非常に多くいます。これは、特にエンジニアリングリソースが潤沢に無いシード/アーリーステージのスタートアップにとって致命的な問題です。

スタートアップにとって貴重な時間と資金というリソースをいかに効率よくプロダクトの価値向上に投入できるかがスタートアップが生き残れるかに大きく影響します。Y Combinator のポール・グレアム氏によれば、スタートアップの成功（時価総額40億円以上）は全体の 7% 程度しかなく、Airbnb や Lyft のようにデカコーン企業（時価総額1兆円以上）となるケースはわずか 0.3% です（Lyft は 2019-03-29 に上場済）。自分たち（だけ）は過ちを犯さない、適切に技術選定出来ると自信を持つことも重要ですが、前述の数字を踏まえシビアに検討できてると自信を持って回答できますか？もちろん技術的な側面だけで成功できるほど簡単ではなく、マーケティングやサポート、セールスを含めた全社的なリソースにも気を配る必要があります。

話を戻しましょう。誤解を生まないよう明言しますが、Kubernetes を利用すること自体がスタートアップにとって誤った技術選定であるという訳ではありません。技術特性だけでなく、Kubernetes という市場的に盛り上がりつつあるソフトウェアを利用し、情報発信することで、Kubernetes そのものに興味があるエンジニアの採用に繋がるかもしれない、といった狙いがある場合もあるかと思います。ですが、スタートアップはプロダクトの価値向上にフォーカスすべきであり、そのためにも “Undifferentiated Heavy Lifting” （差別化に繋がらない重労働）を積極的に削減していくことが、スタートアップの成功確率を上げるうえで大変重要となってきます。スタートアップはプロダクトの価値向上に繋がらない重労働をいかに削減していくかということを常に考える必要があります。

また、場合によって Kubernetes などの特定のツールを利用することが、プロダクトの価値向上に繋がる、大幅に開発期間を短縮できることもあるかと思います。そのような場合は積極的に採用すべきです。（具体的なケースについては後述）

全てをコンテナや Kubernetes で動かすことに縛られない

スタートアップの多くのお客様がコンテナを利用しサービスを提供しています。ですが、これは全てのお客様がコンテナを使うべき、移行すべきということではありません。「誤解１：コンテナに移行「しなければならない」と漠然と思っている」でも触れていますが、コンテナを活用されている企業の多くは技術特性を踏まえた上で、コンテナだけではなく Amazon EC2 (仮想マシン)や AWS Lambda 等を使い分けています。また、私達がご相談を頂いた際に、あえてコンテナ化を勧めないケースも多くあります。

Kubernetes についても同様です。何がプロダクトの価値向上に繋がるかを考慮することが重要です。例えばメルペイ様は Anti-Money Laundering (AML) の基盤に Amazon ECS / AWS Fargate を採用し、仮想マシン周りのセキュリティを AWS にオフロードされました。一方で、他のサービスでは Kubernetes を利用されています。

※参考: merpay の AML 基盤における AWS Fargate 活用事例、その選定理由

この様に、「プロダクトの価値向上のために何が必要か」ということを考えていくことが重要です。

Kubernetes クラスターの管理運用について

「Kubernetes クラスターの運用」と聞いて具体的に何が必要かピンとこないエンジニアも多いのではないでしょうか。多くの Contributor により飛躍的に進化している開発状況や、多くの関連するマネージドサービスや OSS の存在もあり、運用面の検討が疎かになっているケースも多く見られます。（実際、勢いで稼働させた後の運用まわりについてご相談いただくことが多くあります。）運用業務をサポートするマネージドサービスや OSS により負荷が軽減されることは事実ですが、実作業に加えクラスタのアップデート戦略やバージョンごとの変更箇所など気を配るべきこともあるため運用業務は依然として必要になります。

多くの場合、検証の中でこれらの運用業務を具体的にイメージ出来るようになっていくかと思いますが、中には後述の内容を意識しないまま、とりあえず Kubernetes 上で動くようになったアプリケーションをそのまま本番運用にもっていかれるお客様もいらっしゃいます。そのような方もこれから検証される方も、全体感を把握しておくことは有益でしょう。運用業務は大きく分けて「クラスターを構成するホストマシンの管理運用」と「Kubernetes というソフトウェアの管理運用」の２つに分類できます。

クラスターを構成するホストマシンの運用や Kubernetes のバージョン管理

AWS Fargate 編の「コンテナ利用時のホストマシンの運用」でも触れていますが、Kubernetes を利用する際はコンテナだけでなく、クラスターを構成するホストマシンの管理を行う必要があります。コントロールプレーンのマネージドサービスである Amazon EKS や Managed Node Groups 、Amazon EKS 最適化 AMI や CloudFromation のテンプレート、eksctl などのサービス/ツールも充実してきているので過度に警戒する必要はありませんが、これらを適切に利用しホストマシンを管理運用していくことはエンジニアの責務になります。

また、Kubernetes のリリースサイクルにも注意が必要です。マイナーバージョンがおよそ３ヶ月毎にリリースされ、直近３バージョンのみが Kubernetes プロジェクトとしてのサポート対象です。それらのサポート対象のバージョンに対してのみ、脆弱性対応などが行われます。これは、１年経たないうちに、理想的には Kubernetes のバージョンライフサイクルに合わせたおよそ3ヶ月ごとに自身のクラスタをアップデートしていく必要があることを意味します。（※ なお、バージョンを跨いでのアップデートは Kubernetes プロジェクトで推奨されておらず、基本的には１つずつあげることをおすすめします。）。

Amazon EKS ではクラスターのバージョンアップを行う API や Amazon EKS 最適化 AMI 、Managed Node Groups を提供しているため作業自体は比較的容易になりますが、新しいバージョンの Kubernetes クラスター上で利用しているアドオンやプラグインが正常に動作することを事前に確認することは避けられないでしょう。作業工数だけでなく、脆弱性情報の収集やリリースノートの確認などを含め、エンジニアのリソースを割くことが出来るか改めて考えてみて下さい。（もちろんスタートアップなので、リスクを承知でノールックでバージョンアップをしていくこともあるかとも思いますが、技術選定の際は抑えておくべき内容でしょう。）

※ Kubernetes のバージョンライフサイクルの詳細については Kubernetes version and version skew support policy をご覧ください。
※ 「Amazon EKS Kubernetes バージョン」に記載のとおり、Amazon EKS のサポート対象は直近３バージョンとなります。

Kubernetes 上のリソースの管理運用

Kubernetes は一般に YAML で宣言された内容を元に、Pod や Service, Deployment といったリソースを構成します。ですが、宣言された内容に不備が’無く正常に kubectl apply が通ったとしても、実際の現場では様々な理由で Kubernetes が正常にリソースを展開できないことが起こり得ます。例えば、ディスクに空き容量が無くコンテナイメージを Pull 出来ない場合や、Amazon VPC CNI プラグイン利用時に VPC サブネットの IP に空きがない場合、あるいは利用している Kubernetes アドオンが正常に動作していない場合もあるでしょう。また、ALB Ingress Controller 利用時にエンジニアが誤って必要な IAM の権限を外してしまうなど、オペレーション上の不備に起因することもあるかと思います。これらはあくまで一例ですが、このような事象を全て事前に予見し対策や監視をすることは難しいため、実際には Pod の展開状況等を監視することになります。

例えば Amazon EKS では、コントロールプレーンログの CloudWatch Logs への出力や Container Insights を利用したメトリックスの収集が比較的容易に実装できますが、これらを活用しワークロードに応じた監視設計を行うなどです。このあたりは一般的なシステム運用と変わらないのですが、Kubernetes を使うこととそのものに注力するあまり、（なぜか）後回しになったり忘れられたりすることが多いです。

スタートアップが Kubernetes を利用するために

ここまで Kubernetes を利用する際の考慮事項などについて触れて来ましたが、具体的にどのように利用していけばいいでしょうか。クラスターの運用やバージョンアップを容易にするという観点で、順に説明いたします。

マネージドサービスを積極的に利用活用する

AWS ではフルマネージドな Kubernetes のコントロールプレーンを提供する Amazon Elastic Kubernetes Service (Amazon EKS) を利用することが出来ます。複数のアベイラビリティーゾーンに分散されたコントロールプレーンを簡単に構築でき、管理運用も AWS 側にオフロードすることが可能です。また、設定１つでコントロールプレーンのログを CloudWatch Logs に出力することが出来、そうした作り込みが不要なのも嬉しいポイントです。

また、Amazon EKS 最適化 AMI や Managed Node Groups といったものも提供されており、データプレーンの構築や運用も比較的簡単に行うことが出来ます。その中でもスタートアップのお客様に特におすすめしたいのが、AWS re:Invent 2019 にて Amazon EKS のサポートが発表された AWS Fargate です。（東京リージョンでもご利用可能です！）AWS Fargate を利用することによりお客様はデータプレーンについても完全に AWS 側に管理運用をオフロードすることが出来るようになりました。AWS Fargate は Pods の起動リクエストに応じてワーカーノードをクラスターに参加せるため、今まで cluster-autoscaler 等で実現していたワーカーノードの増減を行うこと無く、コストを最適化することが出来ます。また、ホストマシンのセキュリティについても AWS にオフロード出来る点もスタートアップにとって嬉しいポイントではないでしょうか。

過度な作り込みをしない

前述のとおり Kubernetes のバージョンアップについても、Amazo EKS ではバージョンアップを行う API 等が用意されているため、バージョンアップ作業は比較的容易に行うことが出来ますが、事前の検証は必須と言えるでしょう。
その際の検証項目を減らす、あるいは検証後のインプレースでのバージョンアップの可能性を残すために、過度な作り込みを避けることも考慮すべきです。アドオンやプラグインの利用も注意が必要です。（新バージョンへの追従状況は各 OSS プロジェクト次第です。）過度な自粛は、後述の Kubernetes 長所とのトレードオフとも言えるので絶対ではありませんが、 Kubernetes 上でアプリケーションを構築するのであれば将来のバージョンアップの際に起こりうるオペレーションについても考慮するべきです。

Kubernetes を積極的に採用するべきケース

ここまで注意すべきポイントを中心に説明してきましたが、ここでは Kubernetes を積極的に採用するべきケースについて触れます。冒頭でも触れていますが、Kubernetes を利用することがプロダクト開発の加速（開発期間の削減や、運用コストの大幅な削減）や急激なビジネスグロースに繋がるというのはどの様な場合でしょうか。いくつか具体例をあげていきます。

カスタムリソースやオペレータパターンを活用した高度な自動化

Kubernetes では Pod や Service, Deployment といった既定のリソースの他に、自身でカスタムリソース (Custom Resource Definition / CRD) を定義し API を拡張することが出来ます。Kubernetes 内だけでなく外部のリソース（例えば Amazon RDS など）も Kubernetes のリソースとして宣言し、管理運用することが可能です。ユーザが独自に API を拡張できることは何を意味するのでしょうか。

メルカリ様のカスタムリソース・カスタムコントローラによる MLOps パイプラインの実装（記事内前半）を例に見てみましょう。こちらの事例では機械学習のトレーニングジョブの一連の流れをカスタムリソースやカスタムコントローラとして実装しています。これは、パイプラインの各工程で必要なライブラリバージョンなどの複雑な依存関係や、学習に用いるデータソースを Kubernetes のリソースとして扱っていることを意味します。Kubernetes の自動化機構の上に自分たちの業務とワークフローを実装することで、MLOps パイプラインのユーザーは慣れ親しんだ Kubernetes の体験の延長線上で機械学習を行えますし、MLOps パイプラインの実装者は Kubernetes の自動化機構をフレームワークのように利用できるため、Kubernetes によって実装者・利用者の双方の生産性を高めている良い例と言えるでしょう。

参考：メルカリ写真検索における Amazon EKS の活用事例 | AWS Summit Tokyo 2019

ビジネスをドライブする OSS がある

Kubernetes の強みの一つに広大なエコシステム（CNCF の各種プロジェクトを中心としたコミュニティや OSS の盛り上がり）があります。

CNCF Cloud Native Interactive Landscape

Kubernetes 前提の OSS も数多くありますが、それらの活用によりビジネスが大幅に前進する、差別化やプロダクトの価値向上に繋がるのであれば積極的に採用すべきです。また、上記のクラスターの管理運用に加え OSS 周りの追従も必要となる点についても考慮が必要でしょう。

※ 便宜上分けて記述していますが、OSS 内でカスタムリソースやカスタムコントローラを実装している場合も数多くあります。

Kubernetes に関するよくある質問

質問１：Kubernetes はデファクトスタンダード「だから」使うべきですよね？

グローバルで Kubernetes 事例が増えていますが、自社のワークロードで採用するにあたっては Kubernetes 以前にコンテナで動かすべきかどうかを含めて検討しましょう。コンテナをうまく活用している企業の多くは、ワークロードの要件に合わせてコンテナのみでなく Amazon EC2 や AWS Lambda を使い分けています。「プロダクトの価値向上のために何が必要か」という視点で技術選定を行うことが重要であり、その必要なものはワークロードや会社のステージによって異なります。この様な思考の結果として Kubernetes を採用していることが望ましいでしょう。もちろん、事例が増えている、コミュニティが活発であるという点も、自社のプレゼンス向上や採用の観点で間接的にプロダクトの価値向上に繋がるので、この点も考慮するべきです。

また、技術の流行には理由があり、なぜ流行っているのかを知る目的でまずは触ってみる、というのも継続的な技術スタックの改善のために必要といえまし、実際によくあることかと思います。その様な場合も、上記のような視点で検証に取り組むことが重要です。

質問２：Kubernetes の運用は大変ですか？

前述の通り、昨今はマネージドサービス/ツールが充実していますが、お客様の声の中で多いのは「クラスターのバージョンアップが大変」ということでしょうか。バーションアップの作業自体はマネージドサービス/ツールの活用により容易に行うことが可能ですが、バージョンアップに伴う変更点の確認や新しいバージョンのクラスター上で自社のアプリケーションやアドオンが動くかの確認をおよそ３ヶ月毎に行うことになります。（※ 繰り返しになりますが、バージョンを跨いでのアップデートは Kubernetes プロジェクトで推奨されていません。）シード/アーリーステージのスタートアップのような、リソースに限りのあるチームには厳しいかも知れません。

※ Amazon EKS の事例ではありませんが、「Kubernetesの自前運用は難しい？　はてなの撤退事例」も参考になるかと思います。

質問３：マイクロサービスにするなら Kubernetes で、サービスメッシュも必要ですよね？

Sidecar Injection の様なことができるなど、 Kubernetes と相性がいい部分があるのも事実ですが、あくまでユースケースのうちの１つです。コンテナだけではなく EC2 や Lambda を組み合わせたマイクロサービスも一般に良く見られますので、マイクロサービスかどうかといった視点だけで Kubernetes を選定するのは早計です。前述の通り、ワークロード全体を考慮し「プロダクトの価値向上のために何が必要か」という視点で考えることが重要です。

また、マイクロサービス化するにあたり必ずしもサービスメッシュは必要ではありません。実際、サービスメッシュを利用せずにマイクロサービス化しているお客様は数多くいらっしゃいます。こちらについては以前コンテナスペシャリストソリューションアーキテクトの原が講演した「サービスメッシュは本当に必要なのか、何を解決するのか | AWS Summit Tokyo 2019」が参考になるのでご覧頂ければと思います。

そもそもですが、スタートアップにとってマイクロサービスアーキテクチャは必要なのでしょうか？マイクロサービスアーキテクチャは何を解決するものなのでしょうか？こちらついては「スタートアップのためのマイクロサービス入門」を公開する予定ですので、お待ち頂ければと思います。

まとめ

いかがでしょうか。Kubernetes の利用について理解が深まったでしょうか。Kubernetes は使いこなせば非常にパワフルなソフトウェアですが、実際の運用に対して適切なイメージやプランニングが無いまま利用を開始し、困っておられるお客様も多くいらっしゃいます。スタートアップにとってあまりに細か過ぎるプランニングは開発速度を落とすことに繋がりかねないため綿密さは求められないものの、本記事の内容が実運用のプランニングの一助となれば幸いです。
また、AWS Fargate はワーカーノードの実運用を AWS にオフロードできる大変強力な機能です。ぜひ積極的に活用して、事業やプロダクトを成長させることに集中してください。一社でも多くのスタートアップが成功出来るよう私達もサポートいたします。（AWS Loft Tokyo やイベントでもお待ちしております！）

このブログの著者

松田和樹 (Kazuki Matsuda) @mats16k

コンテナやビッグデータが得意分野なスタートアップソリューションアーキテクト。好きなサービスは AWS Fargate, AWS Chalice 。最近は AWS Amplify が好きです。

AWS Startup ブログ