コンテナ基盤Orbitの紹介

はじめに

こんにちは。Strategic Products Engineering Unit SREグループの辻田です。

先日の青島太平洋マラソンにて3時間58分でサブ4を達成してきました。1年前のアドベントカレンダー記事でサブ4したいと書いてたので、自分の目標を叶えることができてとても嬉しいです。*1

さて、われわれのチームでは、SRE活動に加えて、Platform Engineeringにも取り組んでいます。SPEUのコンテナ基盤として誕生したOrbitは、開発者の認知負荷を軽減し、リードタイムを削減し、品質を向上させることを目指しています。今回はOrbitの設計概要と、今後の展望についてご紹介します。

本記事はSansan Advent Calendar 2024の22日目です。

プラットフォームの目的

Orbitは「開発者が本質的な課題に向き合う時間を増やす」ことを目的としています。本質的な課題とは、エンドユーザーに価値を提供するための開発作業です。

Orbitは、繰り返し作業を自動化し、開発者の生産性を向上させることで、ユーザへの価値提供を最大化します。

今後生まれてくる新規サービスはもちろん、既存サービスの改善にもOrbitを活用していきます。

われわれはなぜここにいるのか

エレベーターピッチ

名前の由来

Orbitという名前には、さまざまなサービスが滞りなく回り続ける宇宙空間をイメージしています。また、Google Cloudのさんプログラム「Platform Engineering Jump Start」に参加した際、六本木にいたドラえもんが印象的だったことも、この名前の選定に影響を与えました。*2

技術選定

Google Kubernetes Engine (GKE)を採用しました。SPEUのサービスはGoogle Cloudをベースとしており、Cloud RunかGKEのどちらかを選択することになりました。GKEを選択した理由は次の通りです。

監視やセキュリティポリシーを統制しつつ、開発者がオーナーシップを持って開発できる環境を提供したい
Argo CDやSkaffoldなどのKubernetesエコシステムを活用したい
AutopilotモードではGKEの良いところを残しつつ、運用負荷の削減、コスト最適化、セキュリティの向上が実現されている
Kubernetesの学習コストに抵抗がない

アーキテクチャ

アーキテクチャは次の通りです。

PlatformのGoogle Cloudプロジェクトと各サービスのプロジェクトを分離
- プロジェクトが同じだと、サービスごとのリソースへの権限管理が複雑になるため分離。
Namespace、Artifact Registryのリポジトリは部署単位で分離
- 名刺メーカー、Contract Oneなど大きなサービスごとにNamespace、Artifact Registryのリポジトリを分離。
- 各サービスの開発者のみが、自分のサービスのリソースにアクセスできる。
RBAC向けGoogle Groupで開発チームのクラスターアクセスを制御
- メンバーの追加削除は開発チーム側に委譲できる。
- RBACでGoogle Groupが使えるのはGKEだけの機能。*3
Log scopeで各プロジェクトからpodのログを参照
- Log scopeを作成することにより、Platformプロジェクトにあるpodのログをサービス側のプロジェクトから参照できる。*4
- Log Explorerの保存期間は30日間のため、サービス側のログバケットにも転送&保存する。

提供するもの

Orbitは次の標準化されたツールやリソースを提供します。

アプリケーションテンプレートの生成
- Health check, DB connection check ができるエンドポイント
- 単体テスト
- API doc（swagger）
- CI（単体テスト、lintのactions）
- CD（dev環境へデプロイできるSkaffoldの設定ファイル）
インフラお決まりセットの生成
- Cloud SQL, Cloud Storage, Workload Identity Pool, GitHub Actions用Service Accountのterrraformコード
k8sマニフェストの生成
- ベストプラクティスを組み込んだ状態のマニフェスト