目次
Sansan株式会社のInternal Developer Platform構築：GKE Autopilot活用事例
参考になった
0
レビュー投稿日の情報になります
Sansan株式会社 / Misaki Tsujita
メンバー / インフラエンジニア / 従業員規模: 1,001〜5,000名
最終更新日投稿日
| 利用機能 | ツールの利用規模 | ツールの利用開始時期 |
|---|---|---|
Autopilotモード | 11名〜50名 | 2024年7月 |
| 利用機能 | Autopilotモード |
|---|---|
| ツールの利用規模 | 11名〜50名 |
| ツールの利用開始時期 | 2024年7月 |
アーキテクチャ
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
- 開発者の認知負荷の増大: 開発チームがインフラ構築（Terraform管理）、CI/CDパイプラインの整備、監視設定などを個別に行う必要があり、本来のプロダクト価値向上（機能開発）に集中しづらい状況だった。
- 属人化と管理コスト: 新規プロダクトに専任のインフラ担当がおらず、設定が属人化したり、Terraformと実環境の不一致が発生していた。
- セキュリティガードレールと標準化の欠如: ダッシュボードの管理不足や、セキュリティ・コストへの意識不足などの課題があった。また、サービスごとに設定をコピー＆ペーストして使い回すなど、非効率な運用が発生していた。
どのような状態を目指していたか
- 認知負荷の低減と開発生産性の向上: 開発者がインフラの複雑さを意識せず、セルフサービスで利用できる「Golden Path（舗装された道路）」を提供し、アプリケーション開発に集中できる環境を作ること。
- 標準化と自動化: インフラ、CI/CD、セキュリティ、監視などのベストプラクティスをテンプレート化し、品質とスピードを両立させること。
- 開発者体験（DX）の最大化: アプリケーションの構築からデプロイまでのプロセスを「高速道路」のようにスムーズにすること。
比較検討したサービス
- Cloud Run
- Google Kubernetes Engine (GKE)
比較した軸
- 抽象度と柔軟性のトレードオフ: Cloud Runは抽象度が高く管理が楽だが、バックエンドサービスやNEG、ロードバランサ等のリソース管理が別になる点が懸念だった。GKEは柔軟性が高い。
- 運用負荷とエコシステム: 開発者がオーナーシップを持てる環境を作りつつ、運用負荷を抑えられるか。また、Argo CDなどのKubernetesエコシステムを活用できるか。
選定理由
- GKE Autopilotの採用: ノード管理やセキュリティパッチ適用（コントロールプレーン、ノード）をGoogle側が担うため、運用負荷を大幅に削減できる点。
- コスト最適化とベストプラクティス: Pod単位の課金によるコスト最適化や、セキュリティのベストプラクティスが自動適用される点。
- 一元管理のしやすさ: Cloud Runでは別管理となるロードバランサ等のリソースも、GKEであればマニフェストで一元管理できる点。
- Google Cloudの支援プログラム: Platform Engineering Jump Start に参加し、懸念点が解消され、アーキテクチャ選定に自信が持てたこと。
導入の成果
改善したかった課題はどれくらい解決されたか
- 「認知負荷」の解消: インフラ、CI/CD、監視設定などが「Platform」としてテンプレート化されたことで、開発者はパラメータを指定するだけで環境構築が可能になり、インフラの詳細を意識する必要がなくなった。
- 「属人化」の解消: プラットフォームチームがマニフェストや設定のベースを一元管理することで、特定の人しか触れない環境が減少し、チーム全体で標準化されたフローに乗ることができた。
- ガードレールによる信頼性と安全性の確保: セキュリティ設定やリソース制限などのベストプラクティスが基盤側で強制・自動適用されるため、開発者が意識せずとも安全な状態で開発が進められるようになった。
- ダッシュボード共有、コストの可視化: Metrics Scopeを活用し、GKEダッシュボードを開発チームに公開。コストはプロジェクト按分した結果をSlackに通知して可視化を実現した。
どのような成果が得られたか
- リリース頻度: アプリケーションのデプロイ頻度が約8%上昇
- リードタイム: アプリケーションのリードタイムが約89%短縮
- 工数削減: あるプロジェクトではリリース予定を1週間前倒しでき、約20人日分の工数削減効果があった。
- 開発者の意識変化: 「アプリの構築からデプロイまでが高速道路のようだった」「デプロイパイプラインの構築が爆速だった」というフィードバックが得られ、開発者が本来の業務に集中しやすくなった。
導入時の苦労・悩み
- Google Cloud IAMとk8s RBACの切り分け: IAM権限周りの設定が予想以上に複雑で、Namespace間の通信の制御や、開発チームの初期構築時のトラブルシューティングに時間がかかった。
導入に向けた社内への説明
上長・チームへの説明
- 「インセプションデッキ」の作成: プロジェクトの目的（Why）、エレベーターピッチ、スコープ（やること・やらないこと）を言語化し、方向性を明確にして関係者に共有した。
- 社内営業: 全社向けのLTに加え、個別の開発チームへヒアリングを行い、「Platformを使えばこの課題が解決できる」と提案・実証して信頼を獲得した。
活用方法
よく使う機能
- 自動アップグレード: コントロールプレーンおよびノードのサージアップグレード機能により、運用負荷をかけずにクラスターを常に最新かつ安全な状態に保つことができる。
- Backup for GKE: GKE Autopilotのアップグレードは不可逆（一方通行）であるため、万が一の際に以前の状態へ確実にリストアするための必須機能として利用。
ツールの良い点
- Autopilotによりインフラ管理の手間が最小限で済む
- リリースチャンネルで機能の可用性と安定性のバランスを考慮した自動アップグレードができる
- Interactive Troubleshooting Playbook機能やGeminiとの連携により、エラー原因の特定が比較的やりやすい
ツールの課題点
- Gateway ControllerでのIAP権限設定が不便。IAPの有効化自体はマニフェストで可能だが、Backend Serviceの名前が生成されるまで不明なため、IAM権限を事前に定義できない。これにより、リソース作成後にIAM設定を行う必要が生じ、作業のタイムラグが発生してしまう。
- Autopilotモード特有の制約がある（Windows Serverが使えない、継続利用割引 (SUDs) が適用されない、など）
- GKE Nativeのscaling to 0の機能がないため、KEDAやKnativeを別途導入する必要がある
今後の展望
- AI/ML ワークロードへの対応（Multi Cluster Orchestrator + GKE Inference Gateway + Custom Compute Class）
- 必要なチェックに合格していないイメージのデプロイを制限しセキュリティ強化（Binary Authorization）
Sansan株式会社 / Misaki Tsujita
メンバー / インフラエンジニア / 従業員規模: 1,001〜5,000名
よく見られているレビュー
Sansan株式会社 / Misaki Tsujita
メンバー / インフラエンジニア / 従業員規模: 1,001〜5,000名
