Platform Engineeringチームの加藤です。 前回のTech Blog記事 から時間が空いてしまいました。 Cavorのここまでを振り返りつつ、今後についてを考えてみようと思います。 なお、Cavor (ケイヴァー)はオプティム社内で使われているKubernetesベースのプラットフォームの名前です。Tech Blog内でも何度か登場していますが、明言するのは初めてです。
2025年度までの振り返り
プラットフォームの成長とプラットフォームの利用の拡大の二つの観点から振り返ります。
プラットフォームの成長
Cavorは2023年度から活動を開始し、3年目となりました。 それぞれの年度には、まとめると次のテーマがありました。
- 2023年度: Cavorの立ち上げ
- 2024年度: Cavorのマルチテナント化 (複数プロダクトが同一基盤を安全に共有できるよう、権限・ネットワーク・データ・コストを分離/管理できる状態)
- 2025年度: 開発組織A所属プロダクトのCavor利用の促進
※オプティムの開発組織は二つに分かれており、本稿では便宜上「開発組織A/B」と表記します。2025年度はA、2026年度はBを対象としました。
2023年度: Cavorの立ち上げ
2023年度にCavorの開発が始まりました。 当時は専用環境を必要とする案件が多くあり、その都度インフラの設計・開発をしていましたが、多くのケースでAmazon Elastic Kubernetes Service (EKS)を採用していました。 結果として、車輪の再発明を都度行っている状態でした。
このことから、同じEKS環境が必要なのであればInfrastructure as Code (IaC)でテンプレート化し、それを利用すれば良いのではないかという考えに至りました。 また、Platform Engineeringチームの前身であるSREチームがEKS環境をすでにTerraformでコード化しており、ベースとなるコードがすでにあったことも後押しとなりました。
一方で、案件は予算の都合上、保守に必要最低限の工数しかかけられないことが多く、テンプレート自体の保守の余力がないことが懸念としてありました。 そこで、テンプレートの運用実績としてCavorを構築しました。 そして、Cavorの実績をテンプレートへフィードバックしていくことで、テンプレートを保守する方針にしました。 その頃、
- 既存の社内プロダクト基盤が構築から数年が経過し、インフラ構成や保守の観点で課題が大きくなっていたこと。 また、DevOpsへの移行も始められていたこと。
- 既存のAI系のプロダクトが載っているプラットフォームにおいて、マルチテナントでない環境をマルチテナント的に利用することによる課題が発生していたこと。 (元々は特定のAI系プロダクトのための専用インフラ基盤でしたが、他のプロダクトにも利用が広がったことで発生しました)
といった背景があり、オプティムプロダクトのインフラの課題も一緒に解決することにしました。 そして、まず既存の社内プロダクト基盤のCavorへの移行を始め、移行を完了しました。
2024年度: Cavorのマルチテナント化
既存の社内プロダクト基盤が移行したタイミングでは、まだマルチテナント化はできていませんでした。 つまり、プラットフォームを複数のプロダクトで安全に共有できる状態にはなっていませんでした。 具体的には、以下の通りです。(一部はTech BlogやSpeaker Deckに公開してますのでご覧ください。)
- 権限がプロダクトごとに分かれていない
- ネットワーク空間がプロダクトごとに分離されていない
- モニタリングデータをプロダクトごとに分けて保存・参照できない
- コストの按分がプロダクトごとにできない
2024年度は、上記課題を解決するマルチテナント化の開発がまず行われ、後半から少しずつテナント (利用プロダクト)を増やしていきました。
2025年度: 開発組織A所属プロダクトのCavor利用の促進
2025年度は、開発組織A所属プロダクトのCavor利用率原則100%を目指し、プロダクトがCavorを利用するために不足している機能の開発や移行の支援を中心に活動しました。(まだ仕掛かり中のものも含みます)
- コスト按分方法の改善
- 2024年度に実装した方法は、Podに設定されたCPUとメモリのresource requestsを元に計算する方法で、実際の使用量には則していなかったため、Kubecostを導入し、実際の使用量でコスト計算できるように変更しました。
- モニタリングデータの保持期間の可変化
- モニタリングを利用するテナントがモニタリングについてのコストもコントロールできるようにメトリック、ログ、トレースについての保持期間を変更できるようにしました。
- 監視サーバの独立化
- 監視対象と監視サーバが同じ基盤に同居していたため、分離して障害の影響が同時に発生しないようにしました。
- コンテナイメージの脆弱性・SBOMスキャン
- Trivyを使って定期的にスキャンを自動実行するようにしました。
- ゴールデンパスの作成
- ハッカソンでCavorを利用するため、ハッカソンの事前にハンズオンを実施し、そのタイミングに合わせて整備しました。
- 認証機能
- 新卒研修やハッカソンで作成したアプリケーションを保護するための仕組みとして、自動的に認証を挟むようにしていました。この機能の利用要望が多かったため、他のテナントでも使えるようにしました。
- セキュリティ評価
- テナントが安心してCavorを利用できるように、セキュリティ評価を実施しました。
- テナントの移行のための機能拡充
- 利用できるノードの種類の拡張 (Windows, GPU)
- 利用できるPVの種類の拡張 (EFS)
- アプリイベント監視
しかし上期が終わる頃にはテナントも多くなり、可用性やパフォーマンスの課題が増え始めました。 そのため、下期からはその解消も並行して対応しました。
プラットフォームの成長の振り返り
ここまでを振り返ると実現できたことも多くありますが、当初計画していたことから不十分なものもあります。 特に利用テナントが増えてきてからは、前述した可用性やパフォーマンスの課題が顕在化しました。 加えて、運用面や利用のしやすさの面でも課題が浮き彫りになってきたと痛感しています。 しかし、計画に則り、早い段階からプロダクトチームとコミュニケーションし、 Cavor利用に向けた課題の洗い出しと解決を進められており、 プロダクトチームが円滑に移行できるように動けていると考えています。
プラットフォームの利用の拡大
Cavorの利用状況は着実に増えており、社内の複数プロダクト・プロジェクトでの利用が広がっています。 もともと計画にない、あとから立ち上がったプロダクトや社内プロジェクトが、 こちらからのアクションなくCavorの利用を検討・実施したものも多く含まれており、嬉しく思います。
2026年度は開発組織B所属プロダクトのCavor利用率原則100%を目指しているため、開発組織B所属の各プロダクトチームにアプローチを開始しており、Cavor利用の検討が始まっています。 現時点でのオプティムにおけるすべてのアクティブなプロダクトにアプローチしているため、上記の記載がCavorのテナントになりうるプロダクトの最大となります。
2026年度以降の動き方
前述したとおり、2026年度は開発組織B所属プロダクトのCavor利用率原則100%を目指しますが、それ以外にやりたいと考えていることは次の3つです。
- テナントの品質の可視化
- 例: 共通の観点（可用性・レイテンシ・エラー率・運用負荷など）をダッシュボードで見える化
- 品質の改善アシスト
- 例: 推奨設定/テンプレートや診断手順を整備し、改善の着手を支援
- ガードレールの強化
- 例: 危険な設定や運用を未然に防ぐ仕組みをプラットフォーム側で提供
これは、SREチーム時代の活動のリブートです。
SREチーム時代には「組織横断でプロダクトの品質の改善を行う」ことをミッションに活動してきました。 各プロダクトの課題を洗い出し、効果的なものから順に改善を行うというものです。
具体的には、プロダクトのフェーズとフェーズごとに備えるべき品質 (プロダクトフェージング: こちらのTech Blogで概要を説明しています)を定義し、プロダクトごとに品質を可視化しました。 しかし、現実的には可視化に留まり、改善には至りませんでした。 なぜならプロダクトごとに実装が大きく異なり、改善するためにはプロダクトごとに個別に対応を施す必要があったためです (可視化も各プロダクトチームのチェックリストに従った自己診断となりました)。
現在は当時とは状況が変わりました。Cavorという統一された一つのプラットフォームの利用が進んでいます。 つまり、プラットフォームの改修で対応できることであれば、一度にまとめて全てのテナントの改善ができるということです。 また、計測・可視化についても統一した方法でプラットフォーム側で実施できます。 過去と比べて圧倒的に改善がしやすくなったわけです。
一方で、上記のやりたいこと以外にも同じくらい優先して対応しないといけないことがあります。 それは、運用面や利用のしやすさの面の課題の解消です。
CavorはプロダクトのDevOpsを促進するためのプラットフォームであるため、セルフサービス化が不可欠です。これによってテナント側は利用のしやすさが向上し、Platform Engineeringチーム側は対応にかかる工数を減らして、より注力すべき対応に工数をかけられるようになります。
また、現時点でテナントが不便に感じていることの解消も必要です。 そこでCavor満足度・要望ヒアリングを実施しました。 現在Cavorが提供している4つのサービス、
- Platform (Kubernetes as a Service)
- Monitoring (Grafana Stack as a Service)
- Portal (Document)
- Cost Simulator
の観点でヒアリングを行いました。 以下が要望のサマリーです。
- Platform
- Cavorだけで完結するための機能の拡充
- Monitoring
- 使いやすさ・見やすさの改善
- テレメトリ欠損対策
- ログのパフォーマンス改善
- アクセスログの見やすさ改善
- Portal
- Grafana Stackについてのドキュメント拡充
- モニタリングのテンプレート拡充
- ゴールデンパスの拡充
- ドキュメントの検索性の改善
- ドキュメントの修正
- AIがドキュメントやテンプレートなどにアクセスしやすい状態
- Cost Simulator
- 料金のわかりやすさの改善
- パフォーマンス改善
- フォーキャストの追加
利用者が感じているつらさ・不便さが明確になりました。 特にGrafana Stack周りの「使いやすさ」と「信頼性/パフォーマンス」に関する要望が多かったため、優先して改善が必要だとわかりました。
また、AIの活用についても考える必要があります。 AIの台頭はCavorにも大きく影響を与えました。
利用者がAIを活用してプラットフォームの利用を簡単に行えるようになって良い反面、 プラットフォーム提供者としては 「プラットフォームがAIを使って、より効率的にプラットフォームを利用するための手段」を 提供する必要性が出てきました。
Cavorで利用しているOSSツールにおいて、そのマネージド版ではAI機能が提供されつつも、多くの場合プロプライエタリな形式で提供されています。 つまり、OSS版にはその機能が降りてこないため、自前での開発が必要となっています。 AIを活用してどう利用を簡単化し、利用を促進していくかは悩んでいく必要があります。
例えばモニタリングサービスですが、 ヒアリングの結果から利用者にとってGrafana Stackのハードルが高いことがわかりました。 このハードルはAIを活用できることで、下げられる可能性が多分にあります。 一方で、マネージドサービスではAIを導入してこのアプローチを取りやすいのに対し、セルフホストでは同等の機能がすぐに使えるとは限りません。 Cavorではセルフホストを中心に運用しているため、「コストをかけてマネージドを使う」のか、「コストを抑えてAI支援が限定されることを受け入れる」のかが今後の課題です。
まとめ
- 2023〜2025年度で立ち上げ→マルチテナント化→利用促進を進め、 利用が拡大しました。
- 2026年度は「全社のCavor利用をさらに広げる」ことと、 「セルフサービス化とガードレール強化で“使いやすいプラットフォーム”にする」ことに注力します。
最後に
Cavorの価値は、「プロダクト非固有の課題をプラットフォームに任せ、プロダクト固有の課題にフォーカスできること」だと考えていますが、まだプラットフォームとしてはやらないといけないこと、できるはずのことが山ほどあります。 オプティムでは、一緒にCavorをより良くしていくメンバーを募集しています。ご興味のある方は是非ご連絡ください。
