研究開発部でのEKS導入

研究開発部が抱えていた課題

Sansanの研究開発部では、プロダクトのコアとなる技術を開発し、事業部門からの要望に応えるかたちで新機能を継続的に提供することが求められていました。 組織内には、機械学習アルゴリズムなどの研究を行う“研究員”と、その成果を実際に運用・提供するための仕組みを整える“エンジニア”が在籍しています。 両者が連携しながら成果をプロダクトへと結びつけていくことが求められていましたが、その体制にはいくつかの課題がありました。

まず大きな悩みだったのが、研究成果を素早くプロダクトへ反映できないことです。 当時、エンジニアは新しい研究員の成果物をリリースするたびに、インフラやシステムのアーキテクチャを毎回ゼロから設計し直す必要がありました。 そのため、構築作業には多くの時間と工数がかかり、せっかくの研究成果をスピーディに事業へ還元することが難しい状況でした。

さらに、デプロイ方法にも統一性がなく、CodeBuild、CodePipeline、GitHub Actions, CircleCI など複数のサービスが混在していました。 プロジェクトや担当者ごとに手順が異なる状態で、属人化が進んでしまっていたのです。 このような状況では、たとえば全プロジェクトに一斉で修正パッチを適用するような場合、膨大な確認作業と調整が必要となり、運用負荷が非常に高くなっていました。

目指していた状態

そこで私たちはワークショップを通じて、研究開発部全体の目指す姿を明確化しました。 その中で掲げた「Circuit」のビジョンが次のようなものでした。

“属人性を排除し、研究成果を最短5日でプロダクトにリリースできる仕組みを整備する。” “評価と改善のサイクルを高速に回すことで、ビジネス価値を素早く生み出せる状態を実現する。”

• GKE (Google Kubernetes Engine)
• EKS (Amazon Elastic Kubernetes Service)
• ECS (Amazon Elastic Container Service)

決め手になったポイントとしては大きく2点あります。

一つ目は既存システムとの連携性です。 当時のデータ基盤や既存システムは AWS 上にあり、それらとの統合を考えると同一クラウド上に構築する方が権限管理・レイテンシ・ネットワークコストの面で有利でした。この観点からも AWS を採用する判断をしました。

二つ目は CI/CD の構築が容易であったこと です。 Kubernetes には豊富なエコシステムがあり、CI/CD を構築する際にも ArgoCD などの成熟したツールが利用できました。一方で、当時の ECS では同等のパイプライン構成を実現するには独自の仕組みを構築する必要がありました。 また、MLOps や監視など将来的な拡張を考えたときに、CRD などで自分たちの要件に合わせて拡張できる点も大きな魅力でした。こうした理由から、最終的にEKS を選定しました。

導入後の成果として、リリース速度が基盤導入前から最大で 10 ～ 15倍まで向上しました。 また、デプロイ手順の共通化や簡略化により、研究員が参加することのできる開発フェーズが増えました。その結果、エンジニアのメンバーの負荷が下がり基盤開発や運用に注力できるようになりました。

導入時に最も苦労した点は、社内に Kubernetes の知見がほとんどなかったことです。 そのため、メンバーへの知識インプットを進めながら、最良の形で基盤として整備していく必要がありました。 また、研究員が Kubernetes のリソースを扱い、アプリケーションを容易にデプロイできるようにするにはどうすればよいかという課題もありました。

一方で、Kubernetes を採用することで得られるメリットとして例えば、将来的な拡張性や、MLOps・監視など他領域との統合性が学習コストを上回ると判断しました。 そのため、運用に乗り出す前に GitHub Actions を用いてアプリケーションのテンプレートを整備し、研究員が意識すべき部分を大幅に減らすことで、学習コストを実務上の負担にしない工夫を行いました。

Kubernetesは、インフラを程よい抽象度で扱える仕組みを提供してくれるため、拡張性に優れたプラットフォームです。新しいサービスを展開する上で大きな助けになりますが、その柔軟性ゆえに、標準機能だけでは痒いところに手が届かないと感じる場面もあります。

そうした場合には、プラグインの追加や自作によって機能を補うことが一般的です。 ただしその分、新機能のキャッチアップやアップデート対応など、継続的な改善タスクが発生します。 また、EKS（Amazon Elastic Kubernetes Service）を利用する場合でも、少なくとも年に一度はクラスタ更新が必要です。このため、導入にあたっては組織としての運用体制や、継続的に改善を続けられる体力を見込んでおくことが重要です。

一方で、Kubernetesを運用に乗せることができれば、多数のサービスを効率的に管理できるようになります。従来のように個別対応に追われることがなくなり、結果として開発スピードを維持しながら安定性を高めることが可能になります。

最後に忘れてはならないのは、Kubernetesは「銀の弾丸ではない」ということです。 インフラにも適材適所があり、組織の状況やサービスの特性に応じて最適な選択をすることが大切です。そうした前提を踏まえて導入すれば、Kubernetesは間違いなく強力な基盤になります。

今後の展望として強く進めていきたいこととしては、可観測性の向上があります。 標準的なMetricsだけでなく、インフラレイヤーでのネットワークトレースや、アプリケーションレイヤーでのカスタムメトリクスやTracing を活用し、障害発生時の復旧速度の向上や日々の開発生産性の向上を目指していきたいです。