スタートアップ企業への Kubernetes 導入に必要なこと – Kubernetes エキスパートとコンテナスペシャリスト SA が考える適切な活用法

オープンソースのコンテナオーケストレーションシステムである Kubernetes は、いまや多くの企業が導入する技術となりました。デプロイ・スケーリングの自動化や、コンテナ化されたアプリケーションの統合的な管理を行ううえで、利便性の高い機能を提供してくれます。

ですが、Kubernetes　の適切な活用方法については、模索を続けているエンジニアがほとんどです。とりわけ、人も時間も限られているスタートアップ企業においては、「限られた人的・時間的リソースのなかで、どう Kubernetes を利用すべきか？」「そもそも、自社に Kubernetes を導入した方がいいのか？」と思い悩んでいる方は多いのではないでしょうか。

そうした課題を解決するため、今回は Kubernetes の専門家として知られるゼットラボ株式会社の九岡佑介氏をお招きし、コンテナスペシャリストソリューションアーキテクトの原康紘との対談を実施しました。ファシリテーターを務めるのは、スタートアップソリューションアーキテクトの塚田朗弘です。

「スタートアップ企業に Kubernetes を導入する上で、気をつけるべきことは？」「AWS Fargate や Amazon EKS の登場の背景にあったものは？」など、知っておきたい情報が満載です。

Kubernetes コントローラーの開発経験を積みたくて、ゼットラボへの参画を決めた

塚田：まずは、九岡さんの自己紹介をお願いできますか？

九岡：ヤフー株式会社の子会社であるゼットラボ株式会社（以下、ゼットラボ）で、OpenStack を用いた Kubernetes のマネージドサービスを開発しています。AWS で例えるならば、Amazon EKS を開発するプロダクトチームに所属しているようなイメージです。Container as a Service（CaaS）を作っています。

副業では、業務委託として freee株式会社で Kubernetes 関係の仕事をしていたり、Chatwork株式会社の技術顧問を務めたりしています。趣味でも OSS 開発を行っており、Kubernetes on AWS（kube-aws）など Kubernetes や AWS の課題を解決するようなツールを作成しています。

株式会社ゼットラボ – 九岡佑介氏

原：どのようなモチベーションで、ゼットラボへの参画を決めたのですか？

九岡：Kubernetes コントローラーそのものを開発する経験が積みたかったためです。

CI/CD パイプラインの一部を Kubernetes コントローラーで構築するようなケースにおいて、私は「OSS に不足している機能があれば、自分自身がコントリビュートして直したい」と考えるタイプです。ですが、業務のなかで Kubernetes コントローラーをゼロから開発した経験がないと、そういった領域に手を出すことは難しい。だからこそ、「業務のなかで、その経験を積んでおきたい」と考えていました。

だからこそ、Kubernetes のマネージドサービスを自社内で開発しているゼットラボは、非常に魅力的だったんです。

原：自分自身が技術的にチャレンジしたいことと、扱っている技術領域がフィットする会社を見つけたわけですね。

塚田：すごく良い転職の方法ですよね。では原さんの自己紹介をお願いします。

原：私はアマゾンウェブサービスジャパン株式会社でコンテナスペシャリストソリューションアーキテクト（以下、SA）を務めています。SAの役割は大きく分けて2つあります。

ひとつめは、お客さまに対してアーキテクティングを提供したり、技術的な課題についてお客さまとディスカッションを行ったりします。私はコンテナスペシャリスト SA なので、AWS のコンテナサービスや OSS のコンテナソリューションについての話をすることが多いです。

もうひとつは、お客さまからいただいた製品へのフィードバックや機能リクエストを AWS サービスチーム（開発・運用チーム）に対してインプットし、その内容をベースにディスカッションをすることです。

お客さまからのフィードバックがサービスに影響した例としては、AWS Fargate などが挙げられます。Amazon ECS をお客さまに使っていただくなかで、「コンテナと仮想マシンという両方のレイヤーを管理しなければならず、アプリケーション開発にフォーカスできない」というフィードバックをいただくようになりました。

どうすれば、お客さまにコンテナの利便性を享受していただきながらも運用の手間を軽減し、アプリケーション開発にフォーカスしていただけるかと考えたひとつの結論が、AWS Fargate なんです。

Kubernetes 導入の前に、まずはプランニングを

塚田：スタートアップ企業の方々から「Kubernetes を導入したい」という相談を受けることがよくあります。九岡さんは、もしも自分が「Kubernetes を使いたい」という相談を受けたならば、どのようなアドバイスをしますか？

九岡：「Kubernetes 導入前の段階で、運用のプランニングをすること」をおすすめします。

原：例えば、「既存のワークフローが動いている状態で、どうすればクラスタのアップグレードを安全にできるか」「クラスタのバージョンを下げなければならなくなったら、どのようなオペレーションを行うか」など、運用で実際に発生しうるシチュエーションに対して、どう対応するかを考えるようなイメージですかね？

アマゾンウェブサービスジャパン株式会社コンテナスペシャリスト SA 原康紘

九岡：はい。まさに、そういうイメージです。「Kubernetes を導入したい」というモチベーションはもちろん大事ですが、それ以上に「現実的に、自社で Kubernetes を運用し続けられるかどうか」という観点は重要になってきます。

塚田：Kubernetes クラスタを立てる作業はわずかでも、その後の運用は何年も続きますからね。だからこそ、導入前の検討が重要なんですね。

九岡：その通りです。それから、特にスタートアップ企業の場合は人や時間のリソースが限られているので、なるべく Kubernetes を素のままで使用して、独自のカスタマイズをしない方がいいと思います。メンテナンスコストや学習コストがかかってしまいますから。

どうしても作りこむ必要が出てきた場合は、なるべく OSS にして他社にも公開することで、自社でしか使えないコードを極力少なくすることが重要です。OSS として世に公開し、ユーザーとやりとりした内容を Issue やドキュメントとしてまとめていきます。そうすることで、ノウハウを蓄積しやすいんです。

逆に、ゼットラボのように数十名のリソースを Kubernetes まわりの開発・運用に割けるならば、社内だけでドキュメント作成や開発、テスト、オンボーディング勉強会などを完結させた方がいいです。OSS にも良い点ばかりではなく、Issue への回答に時間を割く必要があるなど、面倒な部分もありますから。

Amazon EKS 登場の背景にあったもの

塚田：Kubernetes に関連した AWS のマネージドサービスとして、2018年に登場した Amazon EKS についてもぜひ触れておきたいです。

九岡：Amazon EKS があのタイミングで出てきたのには、どのような背景があったんですか？

原：Amazon EKS が登場する前の段階で、相当数のお客さまが、Amazon EC2 に Kubernetes をセットアップして使っていました。CNCF（Cloud Native Computing Foundation）が2018年に発表した調査結果によると、51％の Kubernetes ユーザーが AWS 上でワークロードを動かしているという結果が出ていました。

Kubernetes　は、プラットフォームのコンポーネント全体をコントロール下に置こうという設計思想に基づいたシステムです。その設計思想のもと、AWS の各種サービスを Kubernetes のコントロール配下に置こうとした場合、Kubernetes を Amazon EC2 上に配置するのが一番都合が良いというわけです。

ですが、コントロールプレーンの運用を自社で行い続けるのは、労力が大きい。当然、お客さまから「AWS で Kubernetes のマネージドサービスを出してほしい」というリクエストが挙がってきました。だからこそ、Amazon EKS が出てきた。要するに、先ほど話題にのぼった AWS Fargate と同じように、まずお客さまからのフィードバックがあるわけです。

九岡：すごく共感しますね。ユーザーとしては Kubernetes の利便性を享受したいけれど、コントロールプレーンの運用は怖い。できるだけステートフルなものは自分たちで運用したくないです。だからこそ、適切なタイミングで、マネージドサービスである Amazon EKS が登場したことに、大きな価値があったと思います。

Kubernetes クラスタのブルー/グリーンデプロイは、まだ発展途上

塚田：Kubernetes 運用まわりで、今後もっと楽になってほしい作業はありますか？

アマゾンウェブサービスジャパン株式会社シニアソリューションアーキテクト塚田朗弘

九岡：CI/CD に関連する作業でしょうか。Kubernetes に関連する話でいえば、インフラ変更の作業を適切に CI でコード化できるようにしたい。将来的には、CI を“適切なタイミングで回すこと”そのものも、自動化できるようになってほしいと思います。

例をあげると、Amazon EKS のクラスタ A とクラスタ B を CI によってコード管理するとします。クラスタ A をブルー/グリーンデプロイによってバージョン更新したい場合、通常は「クラスタAのコピーを作り、それをコミットして CI で走らせる。結果が OK であれば古い方のファイルを消して、再度 CI を回す」という流れになりますよね。

つまり、この作業のなかで「結果の是非を判断して、CI をトリガーする」という人力のタスクが残っているんです。願わくばそういう部分も、今後は自動化されていけばいいと思っています。

原：クラスタレベルのブルー/グリーンデプロイを自動化しようとした場合、シンプルにクラスタを横に並べるだけであれば、少し頑張って CI/CD を作り込めばできそうな気がします。どのあたりに難しさを感じますか？

九岡：レイヤーの違う話が2つありますね。ひとつは、クラスタ間のロードバランシングをどうすべきかという問題です。AWS においては、Application Load Balancer を用いて、その後段に Kubernetes クラスタが並ぶ構成にすれば、確かにクラスタのブルー/グリーンデプロイは実現できます。

ですが、Application Load Balancer のフロントエンドは HTTP/2 に対応していますが、バックエンドは HTTP/1.1 になるので、gRPC サーバーなどの前に置けないです。これが原因で問題が発生するケースがあって。例えば、複数のクラスタがあり、その上で動いているアプリケーションが gRPC など HTTP/2 によって疎通する方式を取っている場合、Application Load Balancer を間に置く構成がとれなくなってしまいます。

ならば Network Load Balancer を使えばいいかというと、それも難しさがあって。HTTP/2 を扱う gRPC ではコネクションを保持し続ける形で複数のリクエストを処理するので、L4 レイヤーでバランシングを行う場合、コネションが切断されなければサーバー負荷が偏るという問題があります。

これらの問題を解決するには、「HTTP/2 を扱えるロードバランシングの仕組みを、自分たちで構築するしかないのでは」という話になってしまうわけです。正直、大変ですよね。

つまり、クラスタのブルー/グリーンデプロイをやった方がいいことは誰もがわかっているんですけど、そのために解決しなければならない課題が非常に大きい。だからこそ、「インプレースアップグレードでやろうか」という方向性になってしまうんだと思います。

原：Kubernetes クラスタ自体のブルー/グリーンデプロイを行おうとすれば、Kubernetes のさらに上のレイヤーから、Kubernetes を管理するソリューションが必要になりますね。でも、可能ならばその機能は Kubernetes 本体ではなく、別のシステムに切り出した方がいいかもしれません。あまりに Kubernetes の担う役割が増えすぎて、収拾がつかなくなりそうですから（笑）。

九岡：同意見です（笑）。必ずしも　Kubernetes　本体にその機能が入っている必要はない。Kubernetes の担う役割が大きくなればなるほど、Kubernetes が爆発したときのサービス影響も大きくなってしまいますから。

AWS や Kubernetes を活用したい、スタートアップ企業の方々へ

塚田：では最後に、AWS や Kubernetes を活用したいと考えている、スタートアップ企業の方々にメッセージをお願いします。

原：今回のインタビューではコンテナや Kubernetes やコンテナついての技術的な話がメインでしたが、私がスタートアップ企業の方々に本当に伝えたいのは「まずは事業の成長を優先して、ビジネスが健全に回るスキームを作ってほしい。その後に、新しい技術や自分が興味を持っている技術の習得・活用に時間を割いてほしい」ということです。事業がしっかりと成長したならば、その頃には R＆D チームを作れるだけの資金も企業に貯まっているはずですから。

スタートアップ企業は、「数あるタスクにどう優先順位をつけるか」が会社の命運を分けます。そして、何よりも優先順位が高いのは、自分たちのビジネスをグロースさせることです。その目標に対して、技術がどう貢献できるかという視点でものごとを考えていただきたいですね。

だからこそ、スタートアップ企業の方々に AWS Fargate を最初に検討していただきたいです。AWS Fargate を使うことで、コンテナの利便性を享受しながら、運用にかかる手間を格段に減らせます。エンジニアがビジネスにフォーカスする時間を増やせるんです。

九岡：私は「興味を持っている技術領域を、自分がやりたい方向性でやりきってください」と伝えたいです。Kubernetes に興味があるならば、Kubernetes を徹底的に活用して、その分野についての高い技術を身につけてほしいです。

何か特定の技術を突き詰めていけば、それが企業のブランディングにもつながります。外部の方々から「あの会社は○○の技術に強みを持っているから、入社したら楽しそうだ」と思われるくらいになれば、自然とエンジニアにとって魅力的な環境が生まれていくはずです。

私は根っからのエンジニアなので、やはり「エンジニアが働きたいと思える環境をつくる」ということを、すごく大事にしたいですね。

AWS Fargate プロダクトページ

Amazon Elastic Container Service プロダクトページ

【AWS DevDay 2019 での九岡氏の講演資料】
『フロントエンドエンジニアがK8sエンジニアになるまでの10年間を振り返る』

【AWS Summit 2018 Tokyoでの九岡氏の講演ログ】『なぜKubernetesを使うべきではないのか？スタートアップにおけるオーケストレーションの必要性を考える』

AWS Startup ブログ