【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは

提供：ウェルスナビ株式会社

ロボアドバイザーによる個人資産運用サービスを提供するウェルスナビは、サービス基盤をECS中心の運用からEKSを標準基盤へと切り替えた。同社のシステム基盤チームでマネージャーを務める和田雄樹氏が「CloudNative Days Winter 2025」に登壇し、その背景に加え、急増するプロダクトと開発チームに対応するため、AWSとKubernetesエコシステムを組み合わせた基盤設計と、運用の中で明らかになった改善ポイントについて語った。

Kubernetes検討の背景にあった
ECS運用の限界と「Golden Cage」への懸念

ウェルスナビのサービス基盤は長くECSを中心に構築されてきた。ロボアドとしての中核サービスもECS上で運用され、タスク定義の整理や汎用Terraformモジュールの提供など、さまざまな工夫によって高い開発速度と安定性を実現してきた。しかしプロダクト数と開発チームが増える中で、「これまで積み上げてきた仕組みが将来的に運用の重荷となる可能性が浮かび上がっていました」と語るのは、同社のシステム基盤チームのマネージャーを務める和田雄樹氏である(写真)。

2024年に入り、事業のマルチプロダクト化、開発者の急増、CI/CDパイプラインの修正コスト、Terraformの課金モデル変更など、複数の要因が重なり、ECS基盤の運用を根本から見直す必要が生じた(図1)。

抽象化や自動化の効果は大きい。だが、その内部が複雑化していくと、開発者の試行を妨げ、変化への追従を阻害する“Golden Cage”に近づく危険性もある(図2)。

そこで同社は、自社の基盤が本当に“望ましい状態”を保てているのかを判断する指標を求めるようになった。

「自動化や抽象化を進めるときに、私たちが今どこに立っているのかを定期的に確かめる必要があると感じていました。便利さを追求しすぎると、知らないうちに変化へ対応しづらい状態に近づいてしまうことがあるからです」(和田氏)

こうした問題意識を背景に、ウェルスナビは次期プロダクト群の基盤としてKubernetesを検討し始めた。特定プロダクトに最適化された仕組みを量産せず、開発チームの成熟度に応じて柔軟に拡張できる「薄い抽象化」をどう実現するか。組織の成長に合わせて持続的に運用できる構造を求めた結果、同社はKubernetesの可能性を本格的に模索することとなった。

「シンプルさ」か「柔軟性」か?
ECSとEKSの特性比較と選定の決め手

ウェルスナビが次期プロダクト向け基盤を検討する際、最初に向き合ったのはECSとEKSの特性の違いである。ECSは決めることが少なく、シンプルに使える点が大きな強みで、同社でも長年にわたり運用し成果を上げてきた。一方、EKSは柔軟性が高く、ワークロードや組織規模の変化に応じて設計を広げられる仕組みを持つ。

和田氏はこの違いについて「ECSはとにかくシンプルで、決めなければいけないことが少ないのが魅力です。対してEKSは柔軟性がある分、考える範囲も広がります」と説明する。単なる優劣ではなく、どちらが組織の将来に適しているかが検討すべきポイントであった(図3)。

プロダクト数と開発者が急増する中で、これまでECSに積み上げてきた仕組みをそのまま増やしていけば、ツールやパイプラインの複雑さが負債になる懸念もあった。特に複数プロダクトを並行して開発する環境では、環境やネットワークを柔軟に分けられるかどうかが重要な判断軸となった。

この段階で同社が重視したのは、Kubernetesをどのように“始めるか”である。和田氏は「ECSでも運用の手間を抑えられていたので、EKSもまずはFargateから始めるのが良いと考えました。小さく始めて、要件を満たすかどうかを確かめながら進める形です」と振り返る。リスクを抑えながら新しい基盤を試行するという同社の基本方針が、その判断を支えていた。

こうしてウェルスナビは、小さな単位でKubernetesを試しつつ、自社の開発スタイルとの適合性を確認しながら、EKSを新たな基盤として採用する方針を固めていった。

アカウントやネットワークなど
主要設計領域を整備してEKS基盤を具体化した取り組み

ウェルスナビはEKS採用にあたり、将来のプロダクト増加に耐えられる共通基盤として設計領域を整理した。まずAWSアカウントの設計では、環境の境界を明確にしつつ、クラスターはマルチテナントで運用する方針を採用した。複数プロダクトが並行する同社では、責務分担と拡張性を両立するための重要な基盤だ(図4)。

ネットワークはVPC共有とPrivateLinkを中心に据え、プロダクトが増えても通信構成が破綻しないよう、拡張しやすい(スケーラブルな)構造を重視した。さらに、Datadogを用いたオブザーバビリティ設計により、ログ／メトリクス／トレースを統合的に観測できる体制を整えた。和田氏は「EKSは可視化できる範囲が広いので、観測環境を最初から整えておく必要があります」と語る。

CI/CDではArgo CDを中心としたGitOps方式を採用し、アプリケーションの変更管理を開発チームに寄せる形へ移行した。Terraformとの責務を分離し、基盤部分はTerraform、アプリケーションはGitOpsという明確な境界を設けたことにより、変更の衝突を防ぐ仕組みを確立した。

またDatadogとAWSのコスト可視化を組み合わせ、クラスター単位・サービス単位での利用状況を把握する仕組みを導入した。これにより、Kubernetes特有の“意図しないリソース浪費”を防ぎやすくなった。

「こうした設計を重ねた結果、プロダクト数やチーム規模が増えても破綻しない、マルチテナント運用に対応したEKS基盤を整備することができました」(和田氏)

Fargateの強制再起動やGitOpsの競合
ー運用で直面した課題と解決策

EKSの導入は順調に進んだが、運用を始めてみると想定していなかった課題にも直面した。同社はそれらを1つずつ検証し、仕組みとして解消していった。

最初に明らかになったのは、Fargateのメンテナンス予告に伴う、ワークロードの強制再起動だ。ECSでは影響が限定的だったが、EKSのFargateではPodの再作成が必ず発生するため、ワークロードによっては業務時間帯に影響が及ぶ懸念があった。これに対し同社は、自動再起動を前提にした設計や冗長化を徹底し、影響範囲を最小限に抑える方針を取った(図5)。

次に発生したのがCoreDNSのスケール問題である。クラスター内の名前解決が増えた際、CoreDNSが処理しきれず遅延が発生する場面があった。プロダクトが増えるほど影響が大きくなるため、リクエスト数を踏まえたレプリカ設定や、キャッシュの活用、可視化による負荷傾向の把握を行うことで安定運用を実現した。

さらに、GitOps方式とコスト削減のための「夜間停止」との相性も課題となった。ウェルスナビではEKSのコスト最適化を目的に、一部環境を夜間停止させていたが、停止中にGitリポジトリが更新されると、反映タイミングがずれて整合性が崩れる恐れがあった。これに対しては、停止時間帯の更新を避ける運用ルールと、起動時に同期状態を自動で確認する仕組みを導入し、対処した。

またTerraformとManifestの責務分離も難しい領域であった。ECSではTerraform側に多くの設定を集中させる構成が採られていたが、Kubernetes環境では同じ方式が適さない場面が多い。和田氏は「最初はどこまでTerraformに寄せるべきか迷いましたが、クラスタやネットワークはTerraform、アプリケーション部分はGitOpsと、責務を分ける形に落ち着きました」と語る。これにより、開発チームと基盤チームの責任境界が明確になり、変更の衝突が減少した。

これらの課題を乗り越えたことで、同社のEKS運用は大きく安定し、プロダクトが増えても破綻しない基盤として成熟していった。

成長に耐える共通基盤の確立
ーEKS移行で実現した柔軟性と運用性

ECS中心の運用からEKSへ舵を切ったのは、事業と開発組織の拡大に長期的に耐えられる基盤が必要だったためでもある。ECSはシンプルで扱いやすい一方、プロダクトやチームが増えるほど作り込みが積み重なり、運用の複雑性が将来の負債になりかねなかった。これに対しEKSは、Kubernetesエコシステムを活用しながら環境の分離、観測性、変更管理、コスト最適化を柔軟に組み合わせられる点が大きな利点であった。

同社はアカウント分割やテナント設計、GitOpsによるセルフサービス化、Datadogを用いた可観測性、IaCの境界整理といった要素を組み合わせ、「プロダクトと開発チームが10倍に増えても運用が破綻しない」構造を整えていった。運用開始後にはFargateの再起動やCoreDNSのスケール、夜間停止とGitOpsの整合性などの課題もあったが、いずれも設計と運用プロセスに反映し、基盤の強度を高める結果につながった。

和田氏は「EKSでもECSと同じようにシンプルに運用できますし、そのうえでKubernetesの柔軟性という強みも得られるようになってきています。プロダクトが増えていく状況でも、構造として無理なく対応できる点を実感しています」と語る。

ウェルスナビの取り組みは、ECSとEKSの比較軸、拡張性を支える設計、つまずきの克服という3つの視点を通じて、EKS検討時に必要な判断材料を具体的に示す実践例となっている。