プロダクトチームの自律性を加速するEKSマルチアカウント戦略

1. はじめに

こんにちは！グロービス・デジタルプラットフォーム部門(GDP) SREチームの松井です。

本記事では、私たちが実践するEKSマルチアカウント戦略について、その背景思想とアーキテクチャ、そしてチームの役割と責務の変化に焦点を当ててご紹介します。

中央集権モデルの課題とマルチアカウントへの挑戦

グロービスでは、Amazon EKS (Elastic Kubernetes Service) クラスタを中央のAWSアカウント（以下、ホストアカウント）で集権的に管理し、各プロダクトチームに安定したコンテナ実行環境を提供してきました。また、EKSだけでなく、Amazon RDS、S3、ElastiCache、CloudFrontといった各プロダクト向けのバックエンドリソースもこのホストアカウントで共通管理してきました。このモデルは、一貫したガバナンスと効率的なリソース共有を実現する一方で、事業の成長と共にいくつかの課題が顕在化してきました。

• 知識のサイロ化とオーナーシップの課題: インフラに関するドメイン知識がSREチームに集中し、IaC化されてはいるものの、運用知識がチーム内に閉じており、一部ブラックボックス化している部分がありました。これにより、プロダクトチームはインフラの変更に対して心理的なハードルを感じ、積極的に運用に関わることが難しい状況が生まれていました。結果として、プロダクトチームのインフラに対するオーナーシップが育まれにくいという課題がありました。
• 権限管理の複雑化と自律性の阻害: 単一アカウントで多数のプロダクトの権限を安全に分離することは、IAMポリシーの肥大化と認知負荷の増大を招きました。結果として、他プロダクトへの影響を懸念するあまり、開発者に渡せる権限は最小限に制限されがちでした。これは、プロダクトチームがインフラを自律的に変更・試行錯誤する上での技術的な壁となり、オーナーシップの醸成を妨げる一因となっていました。
• リソースクォータの懸念: 単一アカウントを共有する環境では、特定のプロダクトがAWSのリソースを大量に消費することで、アカウント全体に設定されたクォータ（上限値）に抵触し、他のプロダクトに影響を及ぼすリスクがありました。
  実際に、複数のプロダクト/環境でCloudFront Realtime Logsを利用した結果、AWSアカウントごとの設定上限（ハードクォータ）に達してしまいました。これにより、それ以上のログ設定の追加や拡張ができなくなり、一部の環境ではリアルタイムでのログ取得ができないという深刻な事態が発生しました。このような、あるプロダクトの活動が意図せず他チームを阻害してしまう「ノイジーネイバー問題」が顕在化していました。
• コスト(所有権)の曖昧さ: プロダクト固有のインフラ（データベース、WAFルール、ドメイン等）もEKSホストアカウントに同居することで、リソースの一部コストの帰属が曖昧になっていました。これらはAWSリソースタグの活用や、Terraform Stateの管理ポリシーを徹底する事により、一定克服できていますが、完全ではありませんでした。

これらの課題を解決し、プロダクトチームの自律性と開発ベロシティを向上させるため、私たちはマルチアカウント戦略を推進しています。具体的には、プラットフォームリポジトリで管理されるOrganization全体の統制と、プロダクトインフラリポジトリ内の共通基盤ディレクトリで管理されるEKSプラットフォームはSREが責務を持ちつつ、プロダクト固有のAWSリソースは各チームが自身のプロダクトアカウントで自律的に管理するモデルです。

本記事では、この戦略転換の全体像と、それによって各チームの役割や責任がどう変わりつつあるのかを解説します。そして、この取り組みを具体的に示す一例として「クロスアカウントでのALB公開」を取り上げ、続編記事でその技術詳細を解説します。

2. 新アーキテクチャ：プラットフォームとプロダクトの分離

私たちの新しいアーキテクチャは、「プラットフォームを提供するSRE」 と 「プラットフォームを利用するプロダクトチーム」 の役割分担を明確に分離することを目的としています。

アーキテクチャ全体像

このモデルでは、AWSアカウントと、これを管理するTerraform IaCリポジトリの責務を以下のように明確に分けています。

• プラットフォーム層 (SRE管轄)
  • リポジトリ: プラットフォームリポジトリ
  • AWSアカウント: AWS Organizationsの管理アカウント、ログ集約アカウント、セキュリティアカウントなど
  • 責務: Organization全体のガードレール設定 (SCP)、ControlTower管理、CloudTrail/GuardDuty等の集約、共通IAMロールの管理、コスト/予算管理など、事業部横断的なITガバナンスの維持。
• EKSホスト層 (SRE管轄)
  • リポジトリ: プロダクトインフラリポジトリ (共通基盤ディレクトリ)
  • AWSアカウント: EKSホストアカウント
  • 責務: EKSクラスタ自体のプロビジョニングとライフサイクル管理、VPCやサブネットなどの共通ネットワーク基盤、KarpenterやAWS Load Balancer Controllerなどのコアコンポーネントの運用。
• プロダクト層 (プロダクトチーム管轄)
  • リポジトリ: プロダクトインフラリポジトリ (プロダクト個別ディレクトリ)
  • AWSアカウント: プロダクトアカウント
  • 責務: プロダクトが必要とするあらゆるAWSリソース（Cloudfront,ALB,WAF, RDS, ElastiCache, S3等）の構築・運用。アプリケーションのデプロイと、それに伴うインフラ構成の責務を持つ。

プラットフォームリポジトリの責務範囲

SREが管理するプラットフォームリポジトリは、AWS Organizationsを基盤とした全社的なガバナンスを担います。これにより、各アカウントがセキュリティとコンプライアンスの基準を満たすことを保証します。

プロダクトインフラリポジトリの責務範囲

プロダクトインフラリポジトリでは、SREとプロダクトチームが協業します。SREは中央のEKSホスト環境を、プロダクトチームは自身のプロダクトアカウント内のリソースをそれぞれ管理し、VPC Peeringなどを介して連携します。

3. チームの役割と責任の変化

このアーキテクチャ移行は、単なる技術的な変更ではなく、チームの文化とマインドセットの変革でもあります。

SREチーム：基盤の提供者から「イネーブラー」へ

SREチームの役割は、プロダクトチームのインフラを直接管理する「オペレーター」から、彼らが自律的に活動できるための「イネーブラー（実現を支援する者）」へと変革しようとしています。

• 責務:
  • 信頼性の高いプラットフォームの提供: EKSクラスタ、ネットワーク、コアコンポーネントの安定稼働に責任を持つ。
  • 「舗装された道」の整備: プロダクトチームが共通の課題を効率的に解決できるよう、標準化されたTerraformモジュール、テンプレートコードやCI/CDパイプライン、各種ガイドドキュメントを提供する。
  • ガードレールの設定: セキュリティとガバナンスを担保するため、IAMの権限分離やネットワークセキュリティアーキテクチャの雛形を設計・提供する。
  • コンサルテーション: プロダクトチームからの技術的な相談に応じ、アーキテクチャのレビューやベストプラクティスの共有を行う。
  • 知識共有: プロダクトチームからの技術的な相談に応じるだけでなく、知識のサイロ化を防ぐために勉強会やワークショップを定期的に開催し、プロダクトチーム全体の技術力向上を支援する。

プロダクトチーム：「利用者」から「オーナー」へ

プロダクトチームは、インフラを「利用する」立場から、アプリケーションに付随するインフラ全体を「所有する」立場へと変わりつつあります。

• 責務:
  • インフラのライフサイクル管理: 自身のプロダクトアカウント内で、必要なAWSリソース（ALB、RDS等）の設計、構築、運用、そしてコスト管理まで、エンドツーエンドで責任を持てるようになる。
  • プラットフォームの活用: SREが提供するTerraformモジュールやガイドラインを積極的に活用し、迅速かつ安全にインフラを構築できるようになる。
  • セキュリティと信頼性の担保: アプリケーションレイヤーだけでなく、自身が管理するインフラを含めたプロダクト全体のセキュリティと信頼性に責任を持てるようになる。

4. 移行を成功させるためのポイント

このような大きな変化を伴う移行は、慎重な計画と実行が不可欠です。

• 段階的な移行: 全てを一度に移行するのではなく、まずは影響範囲を限定できる小規模なプロダクトを対象に、プロダクトチームとの協業のもとで移行の検証を進めています。このパイロットプロジェクトから得られた学びや課題を、今後の大規模な移行計画に反映させていくアプローチを取っています。
• 徹底したドキュメントとテンプレートの提供: SREは、プロダクトチームが迷わず作業できるよう、クロスアカウント連携に必要なIAMロールのTerraformモジュールや、Kubernetes manifestの設定例といった具体的な「お作法」をドキュメント化して提供することが重要です。現在、グロービスのSREチームはこれらの標準化に向けた取り組みも現在進行形で行っています。
• コミュニケーションと期待値調整: SREとプロダクトチーム間で、新しい役割分担と責任範囲について密にコミュニケーションを取り、期待値をすり合わせます。プロダクトチームがインフラのオーナーシップを持つことへの動機付けも重要です。
• 失敗を許容する文化: プロダクトチームがインフラを触る中で発生しうる小さな失敗を許容し、それを学びの機会として捉える文化を醸成します。SREは、障害発生時に迅速にサポートできる体制を整えます。
• 安全な移行計画の策定と実行: 大規模な移行対応を行う際に、プロダクトへの影響を最小限に抑えるための移行計画を策定し、プロダクトチームと協力しながら実行する事が重要です。

5. まとめと次回予告

本記事では、プロダクトチームの自律性と開発速度の向上を目指す、私たちのEKSマルチアカウント戦略の全体像をご紹介しました。このモデルは、SREチームを「イネーブラー」へと進化させ、プロダクトチームにインフラの「オーナーシップ」を与えることで、スケーラブルでモダンな開発体制を築くことを目的としています。

この戦略の鍵は、明確な責任分界と、それを支える標準化されたツールやプロセスの提供、そして何よりもチーム間の信頼関係です。

次回は、この戦略を具体化させる為の技術的な一例として、「プロダクトアカウントのALBとEKSホストアカウントのPodを安全に連携させる方法」について、TerraformやKubernetesマニフェストのコードを交えながらステップ・バイ・ステップで解説します。