Wantedlyがマイクロサービス基盤としてKubernetesを選んだ理由

CloudNative Days Summer 2024にて、Wantedly株式会社のエンジニアである田中 篤志氏が「マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由」というタイトルで講演を行った。セッションでは2016年からKubernetesを本番運用し続けているWantedlyが、マイクロサービスの運用と開発の両面でKubernetesの拡張性を必要としていること、そしてその結果として高いメンテナンスコストを受け入れる決断をした背景が語られた。

マイクロサービス基盤の選択肢

セッションは「なぜWantedlyがフルマネージドサービスではなくKubernetesを選んだのか」という疑問に答えることから始まった。「まず私たちはマイクロサービスをどの基盤上で運用するかという選択肢がありました。手動構築のKubernetes、マネージドKubernetesサービス、そしてフルマネージドサービスの三つです」と田中氏は説明する。

2016年、Wantedlyは一部のサービスをKubernetes上で本番運用を開始し、2018年にはすべてのサービスをKubernetesに移行した。その背景には、当時のクラウドベンダーが提供するマネージドサービスやフルマネージドサービスでは、マイクロサービスの運用に必要な機能や拡張性が不足していたことがある。「当時のマネージドサービスは、信頼性や保守性は高いものの、機能面で私たちの求めるレベルに追いついていませんでした。そこで拡張性に優れたKubernetesを選択しました」と田中氏は言う。

さらに田中氏はKubernetesの各選択肢を比較し、その利点と欠点を明らかにした。「手動構築のKubernetesは、すべてを自前で管理するため機能性は抜群です。しかし保守性や信頼性が課題です。一方でマネージドKubernetesサービスはクラウド側がコントロールプレーンを管理するため信頼性は向上しますが、Kubernetes自体の難解さは残ります。そしてフルマネージドサービスでは、保守性や信頼性は高いものの、自由度や機能性が大幅に制限されることが多いです」という。

マイクロサービス基盤の比較

WantedlyがKubernetesを選んだ理由

「では、なぜKubernetesを選んだのか？」という質問に対して、田中氏は明確な答えを出している。「Wantedlyでは、マイクロサービスの開発にKubernetesの拡張性がどうしても必要だったからです」。Wantedlyが求めていたのは運用だけでなく、開発環境においても高い柔軟性を持つ基盤だった。そしてKubernetesはその要件を満たすものであったというわけだ。

田中氏は続けて、Wantedlyでの具体的な事例を紹介した。「開発者ごとに専用の仮想クラスタを提供し、他の変更の影響を受けない環境を整えています。この仕組みにより、開発者は依存するサービスを意識することなく、自分の作業に集中できます」。この仮想クラスタの提供は、Wantedly独自の「kubefork」という仕組みで、これにより開発者ごとの環境を容易に切り替えられるという。

「開発と運用の差異を最小限にし、リリースまでの時間を短縮することができます。この開発と運用のギャップを埋めることが、マイクロサービスの利点を最大限に活かすために重要です」と田中氏。Kubernetesの拡張性がこの要件を満たし、Wantedlyはその利点を最大限に引き出しているのだ。

メンテナンスコストの課題

一方でKubernetesを選択したことによって、Wantedlyは高いメンテナンスコストというデメリットにも直面している。田中氏は「Kubernetesのメンテナンスコストは非常に高いです」と率直に語った。そして「それは主に学習コストと頻繁なリリースによるものです」と続けた。Kubernetesの機能は豊富であり、その分だけシステムの複雑さが増し、正しく運用するためには高度な知識が必要となるという。

「さらに、Kubernetesは約3ヶ月ごとに大規模なアップデートが行われます。これによりAPIの変更が生じ、クラスタに依存するアドオンの互換性を維持するための対応が必要になります」と田中氏は具体的な課題を挙げた。これらのメンテナンス作業は手間がかかるだけでなく、クラスタの安定性にも大きく影響を及ぼす可能性があるため、慎重に行わなければならない。

こうした課題に対して、Wantedlyはどのように対応しているのか。田中氏は「私たちは、クラウドサービスの利用や運用フローの改善、そして組織的な対応によって、これらのコストを受け入れる体制を整えています」と説明した。

メンテナンスコストに対する方針

まずWantedlyはkOpsというツールからAmazon EKSへ移行することで、コントロールプレーンの管理をクラウドに任せている。これによりメンテナンス作業の一部をクラウドにオフロードし、手動での管理作業を大幅に減らすことを実現している。「例えばetcdというKubernetesの重要なコンポーネントのバージョンアップが原因で、クラスタが壊れてしまうことが数回ありました。しかしEKSに移行してからは、そうした問題は一度も発生していません」と田中氏は語った。

さらに運用フローの改善として、Wantedlyは「kube」という内製ツールを開発し、学習コストを削減する取り組みを行っている。このツールは、Kubernetesの操作を簡略化し、よく使われる機能を一つのコマンドにまとめることで、エンジニアが学習しやすい環境を提供している。「このツールによりエンジニアがKubernetesを簡単に使えるようにしています。もちろんkubectlの標準ツールも提供しているので、経験のあるエンジニアはそのまま高度な操作も行えるようにしています」。

自動化による作業負担の軽減と組織的な対応

Wantedlyでは、Kubernetesのアドオン管理を自動化することで、運用の負担を軽減している。アドオンとは、Ingress ControllerやCSI Driverなど、Kubernetesクラスタ上で動作する機能拡張であり、これらの管理は手動で行うと煩雑になることが多い。「クラスタアドオンを手動で管理していた頃は、バージョン互換性の問題で何度もトラブルが発生していました」と田中氏は語る。

この問題を解決するために、WantedlyはHelmfileとRenovateを活用し、アドオンの更新作業を自動化している。さらにArgo CDを用いて、GitHubとKubernetesクラスタを連携させ、アドオンの更新プロセスを効率化している。「これにより手動作業が大幅に削減され、アドオンの管理作業が効率化されました」と田中氏は語る。クラスタアドオンの管理は、Kubernetesの運用において不可避の課題であり、その一部を自動化することにより、エンジニアの負担を軽減し、システムの安定性を確保することができている。

さらに田中氏は、アップデート作業の改善に取り組んでいることを強調した。「アップデート作業自体をマニュアル化し、振り返りのプロセスを導入することで、次のアップデートに向けての改善点を洗い出し、作業の効率を上げることができるようになりました」。これにより単なるアップデート作業が、継続的な改善プロセスとして企業全体に浸透しているという。

またWantedlyは組織的な対応で高いメンテナンスコストの課題に向き合っている。田中氏は「運用経験者の採用や、既存チームのキャパシティを増やすことで、Kubernetesのメンテナンスをスムーズに行う体制を整えています」と説明する。これはKubernetesを効果的に運用するために、技術的なリソースを確保し、スキルを持った人材を増やすことが重要であることを示している。また経営陣とのコミュニケーションも欠かせない要素だ。田中氏は「Kubernetesの運用にリソースが必要であることを経営層にしっかりと伝えることで、サポートを得ることができている」と語った。これにより企業全体でKubernetesの運用を支える体制が整い、長期的な安定運用が実現している。

Kubernetesの未来：クラウドへの移行の可能性

さらに田中氏は、今後の技術選定に関する見通しにも触れた。「将来的にクラウドベンダーが提供する機能が十分に整えば、フルマネージドサービスへの移行も視野に入れています」と田中氏。しかしながら、現時点ではKubernetesが最も適した選択肢であることを強調した。

フルマネージドサービスが進化し、マイクロサービスの運用と開発に必要な機能がクラウドベースで提供されるようになれば、Wantedlyはクラウドへの移行を検討するかもしれない。それでもKubernetesが持つ拡張性と柔軟性は、依然としてWantedlyの開発プロセスに不可欠な要素である。「Kubernetesのエコシステムは非常に充実しており、既存の資産を利用しながら、必要に応じて自社のニーズに合わせたカスタムコントローラーを作成することができます。この柔軟性が私たちにとってKubernetesを選び続ける理由の一つです」と田中氏は説明した。

マイクロサービス基盤の選定

最後に田中氏は「技術選定は、その技術が誕生した時期や進化の度合いによって結果が大きく変わります。とくにフルマネージドサービスは進化が著しいため、Kubernetesを選ぶユースケースは減少傾向にあると感じています。マイクロサービスの開発にはKubernetesの拡張性が必要ですが、運用だけならマネージドサービスで十分です。高いメンテナンスコストを支払う価値があるかどうかは、慎重に見極めるべきです」として、セッションを締めくくった。