PEK2025: Multi-Tenancy Design in Ameba

Transcript

1. 国内最大級のメディアを支える マルチテナントPlatform設計の全貌 石川 雲 / Kumo Ishikawa 全レイヤーで実現するスケーラブルなサービス分離
2. ❏横断組織 Service Reliability Group (SRG)所属 ❏Ameba Platform 担当 ❏得意領域 Security Multi-Tenant・Zero Trust・Runtime Monitoring CI/CD ArgoCD・FluxCD・Terraform 今年Kubestronautになった 石川　雲　Kumo Ishikawa
3. 宣伝 本日もう一つの登壇 ❏ Sysdig Japan様のスポンサーセッション ❏ 16:45-17:15
4. 本セッションついて 話す内容 1. Platform Engineering領域のマルチテナント 2. Ameba Platformのマルチテナント設計の過去、現在と未来 話さない内容 ❏ Ameba Platformの詳細な話 興味があれば、PEFM#12をご覧ください
5. 本セッションの資料 発表前からXに予約投稿していました。 なお、Speaker Deck版が完全版です。 発表時間の都合により、以下の部分は省略しています。 ◦ Role & Permission設計 ◦ 実装例など
6. 2024年9月: Ameba 20周年 Amebaについて
7. Ameba Platformについて 全てのAmebaサービスを支える開発者プラットフォーム Developer Platform for All Ameba Services Amebaサービスのインフラ基盤 + 開発者プラットフォーム 2019年: PoC開始 2020年: サービス移管開始 2025年: 22サービス以上移管完了 最終の目標:
8. 初期のテナント課題と解決 課題 ❏ サービスごとに閉じてブラックボックス化 し、引き継ぎが困難 ❏ 組織の変化で新担当者のリードタイム が大きい アプローチ(2019年~2023年) ★ Ameba Platform立ち上げ ★ 解決の方向性は 「みんなで一緒に面倒見よう 」 ◦ 誰でも状況を把握できるようにし、属人化や引き継ぎ困難を防ぐ ◦ この時点では「マルチテナントによる分離」は不要、共通化と可視化を優先
9. 共通化の限界と分離の必然 サービス移管が進むとともに気づいたこと ❏ サービスには性質があり、どうしても他と分離しなければならない ❏ 例: セキュリティ要件が高いサービス・人員管轄が別組織にあるサービス 最初の試み(2021年) ➢ 完全な分離は技術的に実現困難 、一部サービスの移管は断念 転機(2023年) ❏ 新しい技術アプローチで解決の可能性が見えてきた ❏ 私が入社し、最初に担当したプロジェクトがこの課題解決だった
10. 1.マルチテナントの定義と重要性 2.単一テナント設計の限界 3.マルチテナントを支える分離の原則 4.各レイヤーでの実装 5.現行設計の制約とその対処 6.まとめ
11. マルチテナントの定義と重要性
12. マルチテナントとは？
13. マルチテナントの定義 広義的なマルチテナントの定義 複数のテナントが一つの基盤を利用しながら、互いに干渉せずに共存できるモデル ❏ リソース（主にインフラ）の一部は共有され、一部は専用として確保される ❏ インフラリソースに限らず、システムやアプリケーション層 の共有と専用もマルチテナ ントの範囲（SaaSなど）
14. マルチテナントの定義 Platform Engineering領域のマルチテナント ❏ 成長段階によって重心が異なる ❏ 成長期：インフラ層や開発ツール層でのマルチテナント実現が中心 ❏ 成熟期：Platformのアプリケーション層での抽象化が中心（SaaSと同型）
15. マルチテナントの定義 Platform Engineering領域のマルチテナント ❏ 成長段階によって重心が異なる ❏ 成長期：インフラ層や開発ツール層でのマルチテナント実現が中心 (*今回) ❏ 成熟期：Platformのアプリケーション層での抽象化が中心（SaaSと同型）
16. マルチテナント開始のタイミング？
17. “A core aspect of broadly used platforms is that they are efficient only if they are built to be multitenant ” 「広く使われるプラットフォームの中核的な特徴は、 マルチテナントとして構築されているときだけ効率的 になることで す。」 　　　　　　　　　　　　　　–– Camille Fournier, Platform Engineering
18. プラットフォームの利用拡大を目指すなら マルチテナントは必須条件
19. 単一テナント設計の限界
20. 単一テナント設計の限界 単一テナント設計の特徴 1. 全てのテナントに同じ設計 を当てはめる ◦ テナント開発者もプラットフォーム開発者も妥協しないといけない 2. 妥協できず、要件に応えられない場合、新しい基盤を作る ◦ 基盤がサービスごとに乱立し、少人数ではメンテが回らなくなる 結果 ❏ 運用コストがどんどん増える ❏ 特定の人に依存する属人化が進む (Amebaでは上記の全てが発生した)
21. 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月アーカイブ)
22. Amebaのテナント設計(2019) 「みんなで一緒に面倒見よう」の設計 (IAM) ❏ 明確なテナントがない ❏ Resource Tag (Owner)利用、責任範囲とコスト確認用
23. Amebaのテナント設計(2019) 「みんなで一緒に面倒見よう」の真実 ❏ 実質のテナントは一つのみ ❏ 「みんなで一緒に面倒見よう」と言ったのに、一緒に面倒見れたのは一部の人 ❏ 開発者(Developer)は自分のプロダクトだけ見る ❏ 誰も見ていないがプロダクトも誕生してしまった ❏ …
24. Amebaのテナント設計(2019) 権限周りも実は使いにくい ❏ Developer権限はいつも足りないので、ついAdminを付与してしまった ❏ いつもの間にAdmin権限の人が多くなった ❏ Viewer Roleは全く使われなかった ❏ …
25. 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と衝突があったため、使用不可
26. Amebaのテナント設計の限界(2021) 一部サービスのセキュリティ要件「 全レイヤーにおける完全分離 」を満たせない 1. 認証認可 2. コンピューティング 3. ストレージ 4. ネットワーク ⇨該当サービスは 別クラウドアカウント で運用 ❏ Platformチームがそのサービスの運用を支援 ❏ セキュリティ要件がクリアしてから移管を検討
27. マルチテナントを支える分離の原則
28. マルチテナントを支える分離の原 則 1. 二分法から始める分離戦略 : 一言で説明できるのが目標 2. 成熟度に応じた分離基準 : 分離の成熟度に応じてテナントの種類を増やす 3. 分離の起点は常にIdentity : IdP Role = All Layer Role 4. テナントの境界線の明示 : Identityの一貫性と効果を発揮するため ＊あくまで一つの観点です。
29. マルチテナントを支える分離の原 則 1. 二分法から始める分離戦略 ❏ 最初から複雑な体系を作ると例外が生じる ❏ まずはシンプルな二分法から始める ❏ 分離のルールは誰もが理解できる共通語彙で統一することが重要 例: ◦ 保護と非保護 ◦ 管轄Aと管轄B ◦ 監査対象と非監査対象 ◦ 内部利用と外部利用
30. マルチテナントを支える分離の原 則 2. 成熟度に応じた分離基準 ❏ 分離の成熟度に応じて、さらなる分離を行い、種類を増やす ❏ 例: 責任範囲・接続性(外部/内部公開)・実行/データ分離 例: ◦ 保護テナントの追加 ◦ 非保護の細分化 ◦ 保護テナントの細分化
31. マルチテナントを支える分離の原 則 3. 分離の起点は常にIdentity ❏ 唯一の真実源（SSOT） として Role を管理し、すべての権限の出発点 にする ❏ 人 → グループ → Role → 権限 の流れをCloud/K8s/DevTools全レイヤーに展開
32. マルチテナントを支える分離の原 則 4. テナントの境界線の明示 ❏ Ownerタグ/K8s Label でテナントの境界を一貫して表現 ❏ Cloud/K8s/DevTools全レイヤーで同じ語彙を使い回す ことが重要
33. 各レイヤーでの実装
34. 各レイヤーでの実装 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連携
35. 各レイヤーでの実装 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連携
36. Identityレイヤーでの実装 IdPの統一 内製認証/認可基盤PERMAN（Permission Manager） ❏ RBACとLDAPベース、SAML2/OIDC/WebAuthn/FIDO U2Fなど対応 ❏ CyberAgent Groupでは、PERMAN認証 とPERMAN RoleによるRBAC が主流 ❏ AWS/Google Cloud/Azure ❏ Datadog/Figma/Cloudflare/Notionなど
37. Identityレイヤーでの実装 統一したIdentity ❏ Cloud/DevTools/K8s全部同じRole名 を利用するように改修 ❏ Role名はTenant名と同じにする必要がない ❏ OnboardingはPERMAN Roleのみ
38. Role＆Permissionの実装例 時間のため省略 詳細版はSpeakerDeckで公開
39. Identityレイヤーでの実装 Roleの分け方 ◦ 使われないViewer Roleは削除、必要に応じて作成 ◦ Developerは該当Tenant内のAdmin ◦ Platform AdminはSuper Admin扱い (安易に付与しない)
40. Identityレイヤーでの実装 Permissionの分け方 (別のレイヤーで実現) ◦ Protected Tenant Developer = Common Developer + Tenants Permission ◦ Platform Admin = Common Developer + Tenants Permission - Secret Permission
41. 各レイヤーでの実装 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連携
42. Cloudレイヤーでの実装 IAM上の分離例 •ProtectedのAttribute Protectedを持つ •Non-ProtectedのAttribute Protectedを持たない •テナントの固有Attribute Owner=<xxx> ServiceCode=<xxx>
43. 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で拡張
44. 時間のため省略 詳細版はSpeakerDeckで公開 IAM Policyの設計例
45. Non-Protected IAM Policyの例 IAM Policyの設計 S3などはResourceTagで制御できないため、別途で許可 許可時に Protected ServiceNameを除外する
46. Non-Protected IAM Policyの例 IAM Policyの設計 同じStatementに複数のConditionを書くとAND条件になるため、Statementを分けることでOR条件を実現できる
47. IAM Policyの設計 Protected IAM Policyの例 • Non-Protected IAM Policyを継承した上、以下を追加 S3などはResourceTagで制御できないため、別途で許可 許可時に Protected ServiceNameを除外する
48. 各レイヤーでの実装 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連携
49. 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の継承 ・伝搬を実現可能 、ただし小規模環境では導入不要
50. Kubernetesレイヤーでの実装 テナント分けの例 ❏ Protected テナント専用のNamespace Group (<Tenant>-System)
51. RBACの実装例 時間のため省略 詳細版はSpeakerDeckで公開
52. Kubernetesレイヤーでの実装 RBACの例 Protected Tenant Developer = Common Developer + Tenants Permission
53. 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が不要になる
54. Kubernetesレイヤーでの実装 Networkの制御 ❏ Namespace GroupのNetworkPolicy継承
55. Kubernetesレイヤーでの実装 Networkの制御 ❏ Ingress: ◦ Child Namespaceのみ許可 ◦ Exposed Pod向けの通信を許可 ❏ Egress: ◦ 全て許可
56. 各レイヤーでの実装 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連携
57. DevToolsレイヤーでの実装 Github ❏ Role = Github Teams 、ProtectedはRootに属する ❏ 基本Repositoryを別々で運用 ❏ 共通Repositoryでは、Code Ownerを設定
58. DevToolsレイヤーでの実装 Argo CD ❏ DexのSAML 2.0 Connectorは非推奨(2025/7) ❏ Github Teams経由で連携 ❏ NamespaceごとにProjectを作成 ❏ 各Argo CD ProjectにGroupsを設定
59. Datadog ❏ Datadog Teams SAML 2.0連携 ❏ 難点 ❏ 既存リソースの多くが手動作成→Access設定も手動 ❏ APM Trace/Spanは未対応 ❏ 個人情報など、APMに入る前に難読化 DevToolsレイヤーでの実装
60. 現行設計の制約とその対処
61. 1. テナント境界線表現の限界 ❏ Ownerタグだけでは表現しきれないケースもある ❏ 例: Protected Tenant A と B が限定的に共有する Job System・中間処理ワークロード 2. Protected Tenant間通信の複雑さ ❏ 既存設計はNon-Protected / Protected 間の分離が中心 ❏ Protected Tenant間で共有するワークロードを扱えない ❏ 例: Cloudflare Tunnel・外部API向けのGateway Podなど 現行設計の制約とその対処
62. 1. テナント境界線表現の限界 ◦ 補助語彙を新しいタグとして追加し、境界線を新規設定する ◦ 難点 ▪ 共有元と共有先のIAM Policy全部追記する必要がある→IAM Policyの複雑化 テナント境界線表現の限界
63. 2. Protected Tenant間通信の複雑さ ◦ Network Policyの特例・組み合わせを増やす ◦ Tenantの需要に応じた宣言的設定をサポート ◦ Open Application Model(KubeVela)の活用 ◦ 難点: ▪ CrossNamespaceのリソース管理 ▪ →NetworkPolicyの複雑化 Protected Tenant間通信の複雑 さ
64. まとめ
65. ❏ Amebaのテナント設計の背景 ❏ テナント分離の原則 ❏ 二分法から始める分離戦略 ❏ 成熟度に応じた分離基準 ❏ 分離の起点は常にIdentity ❏ チーム境界線の明示 ❏ 現行設計の詳細、制約と対処 まとめ
66. 採用情報 中途採用(Ameba Platform) 中途採用(SRG)
67. ありがとうございました