PEK2025: Multi-Tenancy Design in Ameba

by Kumo Ishikawa

Slide 1

Slide 1 text

国内最大級のメディアを支えるマルチテナントPlatform設計の全貌石川雲 / Kumo Ishikawa 全レイヤーで実現するスケーラブルなサービス分離

Slide 2

Slide 2 text

❏横断組織 Service Reliability Group (SRG)所属 ❏Ameba Platform 担当 ❏得意領域 Security Multi-Tenant・Zero Trust・Runtime Monitoring CI/CD ArgoCD・FluxCD・Terraform 今年Kubestronautになった石川　雲　Kumo Ishikawa

Slide 3

Slide 3 text

宣伝本日もう一つの登壇 ❏ Sysdig Japan様のスポンサーセッション ❏ 16:45-17:15

Slide 4

Slide 4 text

本セッションついて話す内容 1. Platform Engineering領域のマルチテナント 2. Ameba Platformのマルチテナント設計の過去、現在と未来話さない内容 ❏ Ameba Platformの詳細な話興味があれば、PEFM#12をご覧ください

Slide 5

Slide 5 text

本セッションの資料発表前からXに予約投稿していました。なお、Speaker Deck版が完全版です。発表時間の都合により、以下の部分は省略しています。 ○ Role & Permission設計 ○ 実装例など

Slide 6

Slide 6 text

2024年9月: Ameba 20周年 Amebaについて

Slide 7

Slide 7 text

Ameba Platformについて全てのAmebaサービスを支える開発者プラットフォーム Developer Platform for All Ameba Services Amebaサービスのインフラ基盤 + 開発者プラットフォーム 2019年: PoC開始 2020年: サービス移管開始 2025年: 22サービス以上移管完了最終の目標:

Slide 8

Slide 8 text

初期のテナント課題と解決課題 ❏ サービスごとに閉じてブラックボックス化し、引き継ぎが困難 ❏ 組織の変化で新担当者のリードタイムが大きいアプローチ(2019年~2023年) ★ Ameba Platform立ち上げ ★ 解決の方向性は「みんなで一緒に面倒見よう」 ○ 誰でも状況を把握できるようにし、属人化や引き継ぎ困難を防ぐ ○ この時点では「マルチテナントによる分離」は不要、共通化と可視化を優先

Slide 9

Slide 9 text

共通化の限界と分離の必然サービス移管が進むとともに気づいたこと ❏ サービスには性質があり、どうしても他と分離しなければならない ❏ 例: セキュリティ要件が高いサービス・人員管轄が別組織にあるサービス最初の試み(2021年) ➢ 完全な分離は技術的に実現困難、一部サービスの移管は断念転機(2023年) ❏ 新しい技術アプローチで解決の可能性が見えてきた ❏ 私が入社し、最初に担当したプロジェクトがこの課題解決だった

Slide 10

Slide 10 text

1.マルチテナントの定義と重要性 2.単一テナント設計の限界 3.マルチテナントを支える分離の原則 4.各レイヤーでの実装 5.現行設計の制約とその対処 6.まとめ

Slide 11

Slide 11 text

マルチテナントの定義と重要性

Slide 12

Slide 12 text

マルチテナントとは？

Slide 13

Slide 13 text

マルチテナントの定義広義的なマルチテナントの定義複数のテナントが一つの基盤を利用しながら、互いに干渉せずに共存できるモデル ❏ リソース（主にインフラ）の一部は共有され、一部は専用として確保される ❏ インフラリソースに限らず、システムやアプリケーション層の共有と専用もマルチテナントの範囲（SaaSなど）

Slide 14

Slide 14 text

マルチテナントの定義 Platform Engineering領域のマルチテナント ❏ 成長段階によって重心が異なる ❏ 成長期：インフラ層や開発ツール層でのマルチテナント実現が中心 ❏ 成熟期：Platformのアプリケーション層での抽象化が中心（SaaSと同型）

Slide 15

Slide 15 text

マルチテナントの定義 Platform Engineering領域のマルチテナント ❏ 成長段階によって重心が異なる ❏ 成長期：インフラ層や開発ツール層でのマルチテナント実現が中心 (*今回) ❏ 成熟期：Platformのアプリケーション層での抽象化が中心（SaaSと同型）

Slide 16

Slide 16 text

マルチテナント開始のタイミング？

Slide 17

Slide 17 text

“A core aspect of broadly used platforms is that they are eﬃcient only if they are built to be multitenant ” 「広く使われるプラットフォームの中核的な特徴は、マルチテナントとして構築されているときだけ効率的になることです。」　　　　　　　　　　　　　　–– Camille Fournier, Platform Engineering

Slide 18

Slide 18 text

プラットフォームの利用拡大を目指すならマルチテナントは必須条件

Slide 19

Slide 19 text

単一テナント設計の限界

Slide 20

Slide 20 text

単一テナント設計の限界単一テナント設計の特徴 1. 全てのテナントに同じ設計を当てはめる ○ テナント開発者もプラットフォーム開発者も妥協しないといけない 2. 妥協できず、要件に応えられない場合、新しい基盤を作る ○ 基盤がサービスごとに乱立し、少人数ではメンテが回らなくなる結果 ❏ 運用コストがどんどん増える ❏ 特定の人に依存する属人化が進む (Amebaでは上記の全てが発生した)

Slide 21

Slide 21 text

Amebaのテナント設計(2019) 「みんなで一緒に面倒見よう」の設計 (k8s) ❏ 1 Product = 1 Namespace, 1 Tenant = 1 Namespace Group = N Namespace ❏ 二つのNamespace Group: Ameba-System とPlatform-System Hierarchical Namespaces Controller利用 (2025年4月アーカイブ)

Slide 22

Slide 22 text

Amebaのテナント設計(2019) 「みんなで一緒に面倒見よう」の設計 (IAM) ❏ 明確なテナントがない ❏ Resource Tag (Owner)利用、責任範囲とコスト確認用

Slide 23

Slide 23 text

Amebaのテナント設計(2019) 「みんなで一緒に面倒見よう」の真実 ❏ 実質のテナントは一つのみ ❏ 「みんなで一緒に面倒見よう」と言ったのに、一緒に面倒見れたのは一部の人 ❏ 開発者(Developer)は自分のプロダクトだけ見る ❏ 誰も見ていないがプロダクトも誕生してしまった ❏ …

Slide 24

Slide 24 text

Amebaのテナント設計(2019) 権限周りも実は使いにくい ❏ Developer権限はいつも足りないので、ついAdminを付与してしまった ❏ いつもの間にAdmin権限の人が多くなった ❏ Viewer Roleは全く使われなかった ❏ …

Slide 25

Slide 25 text

Amebaのテナント設計の限界(2021) 一部サービスのセキュリティ要件「全レイヤーにおける完全分離」を満たせない 1. 認証認可 ✅ ❏ IAM Role再分離 2. コンピューティング ✅ ❏ Pod Topology Spread Constraintsなど導入 3. ストレージ ✅ ❏ IAM Policy設計 4. ネットワーク ❌　⇦ ボトルネック ❏ Pod to Pod: 2021年当時、EKS上StableなNetwork Policyソリューションがない ❏ Pod to AWS: 2021年当時、Security Groups for Pod機能がIstioと衝突があったため、使用不可

Slide 26

Slide 26 text

Amebaのテナント設計の限界(2021) 一部サービスのセキュリティ要件「全レイヤーにおける完全分離」を満たせない 1. 認証認可 2. コンピューティング 3. ストレージ 4. ネットワーク ⇨該当サービスは別クラウドアカウントで運用 ❏ Platformチームがそのサービスの運用を支援 ❏ セキュリティ要件がクリアしてから移管を検討

Slide 27

Slide 27 text

マルチテナントを支える分離の原則

Slide 28

Slide 28 text

マルチテナントを支える分離の原則 1. 二分法から始める分離戦略 : 一言で説明できるのが目標 2. 成熟度に応じた分離基準 : 分離の成熟度に応じてテナントの種類を増やす 3. 分離の起点は常にIdentity : IdP Role = All Layer Role 4. テナントの境界線の明示 : Identityの一貫性と効果を発揮するため＊あくまで一つの観点です。

Slide 29

Slide 29 text

マルチテナントを支える分離の原則 1. 二分法から始める分離戦略 ❏ 最初から複雑な体系を作ると例外が生じる ❏ まずはシンプルな二分法から始める ❏ 分離のルールは誰もが理解できる共通語彙で統一することが重要例: ○ 保護と非保護 ○ 管轄Aと管轄B ○ 監査対象と非監査対象 ○ 内部利用と外部利用

Slide 30

Slide 30 text

マルチテナントを支える分離の原則 2. 成熟度に応じた分離基準 ❏ 分離の成熟度に応じて、さらなる分離を行い、種類を増やす ❏ 例: 責任範囲・接続性(外部/内部公開)・実行/データ分離例: ○ 保護テナントの追加 ○ 非保護の細分化 ○ 保護テナントの細分化

Slide 31

Slide 31 text

マルチテナントを支える分離の原則 3. 分離の起点は常にIdentity ❏ 唯一の真実源（SSOT）として Role を管理し、すべての権限の出発点にする ❏ 人 → グループ → Role → 権限の流れをCloud/K8s/DevTools全レイヤーに展開

Slide 32

Slide 32 text

マルチテナントを支える分離の原則 4. テナントの境界線の明示 ❏ Ownerタグ/K8s Label でテナントの境界を一貫して表現 ❏ Cloud/K8s/DevTools全レイヤーで同じ語彙を使い回すことが重要

Slide 33

Slide 33 text

各レイヤーでの実装

Slide 34

Slide 34 text

各レイヤーでの実装 Ameba Platformで実際に実装された内容 1. Identity : Role & Permission 2. Cloud（AWS） : IAM 3. Kubernetes（EKS） : RBAC & Security Groups For Pod & NetworkPolicy 4. DevTools （ArgoCD/Github/Datadog ）: Identity連携

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Identityレイヤーでの実装 IdPの統一内製認証/認可基盤PERMAN（Permission Manager） ❏ RBACとLDAPベース、SAML2/OIDC/WebAuthn/FIDO U2Fなど対応 ❏ CyberAgent Groupでは、PERMAN認証とPERMAN RoleによるRBAC が主流 ❏ AWS/Google Cloud/Azure ❏ Datadog/Figma/Cloudﬂare/Notionなど

Slide 37

Slide 37 text

Identityレイヤーでの実装統一したIdentity ❏ Cloud/DevTools/K8s全部同じRole名を利用するように改修 ❏ Role名はTenant名と同じにする必要がない ❏ OnboardingはPERMAN Roleのみ

Slide 38

Slide 38 text

Role＆Permissionの実装例時間のため省略詳細版はSpeakerDeckで公開

Slide 39

Slide 39 text

Identityレイヤーでの実装 Roleの分け方 ○ 使われないViewer Roleは削除、必要に応じて作成 ○ Developerは該当Tenant内のAdmin ○ Platform AdminはSuper Admin扱い (安易に付与しない)

Slide 40

Slide 40 text

Identityレイヤーでの実装 Permissionの分け方 (別のレイヤーで実現) ○ Protected Tenant Developer = Common Developer + Tenants Permission ○ Platform Admin = Common Developer + Tenants Permission - Secret Permission

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Cloudレイヤーでの実装 IAM上の分離例 •ProtectedのAttribute Protectedを持つ •Non-ProtectedのAttribute Protectedを持たない •テナントの固有Attribute Owner= ServiceCode=

Slide 43

Slide 43 text

IAM Policyの設計 Fine-grainedのABAC設計ポイント 1. Allowベースで最小権限を構成 Denyを挟むと設計が複雑になるため 2. NotActions/NotResourcesを活用例外的なActionとResourceを除外 3. 複数のStatementに分割してOR条件を実現 Allowの積み上げ、除外されたResource/Actionの追加、AND Conditionの回避 4. Tag Base(ABAC)とARN BaseのCondition/Resource管理 ResourceTagが使えるサービスと使えないサービスがあるため、TagとARNを併用 5. 上位権限のロールは、下位権限Policyを継承しつつ追加Policyで拡張

Slide 44

Slide 44 text

時間のため省略詳細版はSpeakerDeckで公開 IAM Policyの設計例

Slide 45

Slide 45 text

Non-Protected IAM Policyの例 IAM Policyの設計 S3などはResourceTagで制御できないため、別途で許可許可時に Protected ServiceNameを除外する

Slide 46

Slide 46 text

Non-Protected IAM Policyの例 IAM Policyの設計同じStatementに複数のConditionを書くとAND条件になるため、Statementを分けることでOR条件を実現できる

Slide 47

Slide 47 text

IAM Policyの設計 Protected IAM Policyの例 • Non-Protected IAM Policyを継承した上、以下を追加 S3などはResourceTagで制御できないため、別途で許可許可時に Protected ServiceNameを除外する

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Kubernetesレイヤーでの実装 RBACの特徴 ❏ Role (何を許可するか) + Subject (誰に許可するか User/Group) ❏ Allowベースで権限を追加する仕組み、指定がない限り禁止 ❏ Label等による条件付き制御ができないため、Namespaceごとに権限を分ける ❏ Namespace / Namespace Group = テナント、Namespaceが実質的な境界線 ❏ そのNamespace/Namespace GroupにどのUser/Groupを紐付けるかが分離の核心 Namespace Groupについて Hierarchical Namespace ControllerなどのNamespace抽象化ツールで、RBACの継承・伝搬を実現可能、ただし小規模環境では導入不要

Slide 50

Slide 50 text

Kubernetesレイヤーでの実装テナント分けの例 ❏ Protected テナント専用のNamespace Group (-System)

Slide 51

Slide 51 text

RBACの実装例時間のため省略詳細版はSpeakerDeckで公開

Slide 52

Slide 52 text

Kubernetesレイヤーでの実装 RBACの例 Protected Tenant Developer = Common Developer + Tenants Permission

Slide 53

Slide 53 text

Kubernetesレイヤーでの実装 Networkの制御 ❏ ネットワーク ❌　⇦ ボトルネック ○ Pod to Pod: 2021年当時、EKS上StableなNetwork Policyソリューションがない ○ Pod to AWS: 2021年当時、Security Groups for Pod機能がIstioと衝突があったため、使用不可 ❏ 2023年以降いずれも改善された ✅ ○ Pod to Pod: EKS vpccniにL4のNetwork Policy が実装 ○ Pod to AWS: Security Groups for Pod 再検証した結果、衝突現象が解消された ❏ DB/CacheのSGでPod SGのみを許可する ○ Network PolicyがL7まで対応できたら、Security Groups for Podが不要になる

Slide 54

Slide 54 text

Kubernetesレイヤーでの実装 Networkの制御 ❏ Namespace GroupのNetworkPolicy継承

Slide 55

Slide 55 text

Kubernetesレイヤーでの実装 Networkの制御 ❏ Ingress: ○ Child Namespaceのみ許可 ○ Exposed Pod向けの通信を許可 ❏ Egress: ○ 全て許可

Slide 56

Slide 56 text

各レイヤーでの実装 Ameba Platformで実際に実装された内容 1. Identity : Role & Permission 2. Cloud（AWS） : IAM & Security Groups 3. Kubernetes（EKS） : RBAC & Security Groups For Pod & NetworkPolicy 4. DevTools （ArgoCD/Github/Datadog ）: Identity連携

Slide 57

Slide 57 text

DevToolsレイヤーでの実装 Github ❏ Role = Github Teams 、ProtectedはRootに属する ❏ 基本Repositoryを別々で運用 ❏ 共通Repositoryでは、Code Ownerを設定

Slide 58

Slide 58 text

DevToolsレイヤーでの実装 Argo CD ❏ DexのSAML 2.0 Connectorは非推奨(2025/7) ❏ Github Teams経由で連携 ❏ NamespaceごとにProjectを作成 ❏ 各Argo CD ProjectにGroupsを設定

Slide 59

Slide 59 text

Datadog ❏ Datadog Teams SAML 2.0連携 ❏ 難点 ❏ 既存リソースの多くが手動作成→Access設定も手動 ❏ APM Trace/Spanは未対応 ❏ 個人情報など、APMに入る前に難読化 DevToolsレイヤーでの実装

Slide 60

Slide 60 text

現行設計の制約とその対処

Slide 61

Slide 61 text

1. テナント境界線表現の限界 ❏ Ownerタグだけでは表現しきれないケースもある ❏ 例: Protected Tenant A と B が限定的に共有する Job System・中間処理ワークロード 2. Protected Tenant間通信の複雑さ ❏ 既存設計はNon-Protected / Protected 間の分離が中心 ❏ Protected Tenant間で共有するワークロードを扱えない ❏ 例: Cloudﬂare Tunnel・外部API向けのGateway Podなど現行設計の制約とその対処

Slide 62

Slide 62 text

1. テナント境界線表現の限界 ○ 補助語彙を新しいタグとして追加し、境界線を新規設定する ○ 難点 ■ 共有元と共有先のIAM Policy全部追記する必要がある→IAM Policyの複雑化テナント境界線表現の限界

Slide 63

Slide 63 text

2. Protected Tenant間通信の複雑さ ○ Network Policyの特例・組み合わせを増やす ○ Tenantの需要に応じた宣言的設定をサポート ○ Open Application Model(KubeVela)の活用 ○ 難点: ■ CrossNamespaceのリソース管理 ■ →NetworkPolicyの複雑化 Protected Tenant間通信の複雑さ

Slide 64

Slide 64 text

まとめ

Slide 65

Slide 65 text

❏ Amebaのテナント設計の背景 ❏ テナント分離の原則 ❏ 二分法から始める分離戦略 ❏ 成熟度に応じた分離基準 ❏ 分離の起点は常にIdentity ❏ チーム境界線の明示 ❏ 現行設計の詳細、制約と対処まとめ