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

それではこちらの長いタイトルで発表させていただきます
石川雲といいます
先ほどの発表と同じく横断組織のグループのSRGに所属しています
私は主にAmebaプラットフォームを担当しています
そして得意領域はセキュリティとCICDになります
そして余談ですけど今年Kubeストロノートになりました
ちょっとその前に一つの宣伝ですけど
本日もう一つのセッションで登壇いたします
これはCistic Japan様のスポンサーセッションです
この後の時間のルームAで発表させていただきます
こちらはKubernetes上のセキュリティの話になりますので
興味ある方はぜひ聞いてください
本日のセッションについて
本日は主にプラットフォームエンジニア領域の
マルチテナントの話をする予定です
実例としてAmebaプラットフォームの
マルチテナントの設計の過去
現在と未来について詳しく話する予定です
本日話さない内容としては
Amebaプラットフォームの詳細の話です
こちらと同じく
先ほどのセッションと同じく
プラットフォームエンジニアルグミットアップの
12回目の発表でご覧ください
本日の資料ですけど
先ほどうまく投稿できるか分からないですけど
一応予約投稿してありまして
スピーカーデックに上がっています
それは完全版になります
発表時間の都合で
以下の部分を省略しています
本日はAmebaの話をしますので
このAmebaは皆さんご存知の
Amebaです
去年の9月に20周年になりました
そしてAmebaプラットフォームについては
Amebaサービスのインフラ基盤
プラス開発者プラットフォームになります
6年前からポック開始して
今年時点で
既に22サービス以上の
移管完了しております
最終的な目標は
全てのAmebaサービスを支える
開発者プラットフォームを目指しています
まず導入として
まずAmebaのテナントの話をさせてください
Amebaは当時
これ2019年当時ですけど
引き続きとか
リードタイムに関して課題がありまして
アプローチとしては
Amebaプラットフォームの立ち上げと
この課題の解決の方法性を決まりました
それはみんなで一緒に面倒を見ようという理想です
当時は誰でも状況を把握できるようにしたいので
そうすることで
俗人化とか引き続き困難とかを防ぐという狙いでした
当時はマルチテナントによる分離がまだ不要というような考え方で
共通化とか可視化とかを優先していました
しかしサービス遺憾が進むとともに気づいたことがあります
それはサービスには性質がありまして
どうしても他のサービスと分離しなければならないことが発生します
例えばセキュリティ要件が高いサービスとか
管轄がそもそも別組織にあるサービスとか
この問題を解決するために
2021年一応試してみました
しかし完全な分離が技術的に実現することは困難だったので
一部のサービスの遺憾が丹念しました
一応転機としては2年後
新しい技術のアプローチがありまして
それで解決の可能性が見えてきました
そして当時私がちょうど入社して
最初にサイバーエジェントを担当したプロジェクトが
この課題の解決でした
本日の目次になります
まずマルチテナントの定義から話しましょう
マルチテナントとはどういうものかというと
抗議的な定義というと
複数のテナントが一つの基盤を利用しながら
お互いに干渉せずに共存できるモデルになります
この中にリソース
主にインフラですけど
一部が共有されて一部が専用として確保されています
そして最近だとSaaSなどでは
インフラリソースに限らずに
システムとかアプリケーション
その共有と専用もマルチテナントの範囲になります
そしてプラットフォームエンジニアリング領域の
マルチテナントでは
成長の段階によって
重心が少し異なります
まず成長期だと
インフラ層
開発ツール
左下のような図になるんですけれど
ここにリアのマルチテナントの実現が中心になります
そして成熟期に入ると
プラットフォーム時代も
コントロールプレーンなどできたり
アプリケーションレイヤーの抽象化が中心になります
この点についてはSaaSと同じような形になります
そして今回の話は成長期の話になります
ではマルチテナントをいつ開始すればいいか
という質問に対して
ちょっとプラットフォームエンジニアリングという本から
少し言葉を借りました
ちょっと翻訳っぽいですけど
広く使われるプラットフォームの中核的な特徴は
マルチテナントとして構築されているときだけ
効率的になることです
少し言い直すと
プラットフォームの利用拡大を目指すなら
マルチテナントが必須条件になります
ではマルチテナントの前に
まず単一テナント
シングルテナントでもありますけど
その設計の限界について見ていきます
まず単一テナントの設計の特徴は
個人的には多い2点があるかなと思います
まず全てのテナントに同じ設計を
当てはめるという特徴です
これいい点もありますけど
悪い点としては
テナント開発者もプラットフォーム開発者にも
脱協点を探さないといけないです
そしてもし脱協できないときに
要件に応えられない場合に
新しい基盤を作るしかないです
しかしこの新しい基盤を作ると
サービスごとに乱立したり
少人数でそれらのメンテンを回さないといけないので
結果的に俗人化とか
あと運用コストとかも増えることになります
ちなみにAmoebaでは全部発生していました
これは2019年のAmoebaのKubernetesの設計です
当時のテナントの考え方は
まず1プロダクトが1ネームスペースを利用して
1テナントが1ネームスペースグループ
このネームスペースグループが複数のネームスペースを入っています
という考えをしていました
そして当時は2つのネームスペースグループがあります
Amoebaシステムとプラットフォームシステム
これは先ほどのステッションでも少し触れたんですけど
このHNC ネームスペースのコントローラーを利用していました
しかしこれ今年の4月アカイブされていました
AWSレイヤーでは特に明確的なテナントがありまして
ただ各リソースにリソースタッグ
オーナーとかも付与したり
それで責任分野 範囲とかコストの確認
そのために使われています
その図を見ると多分気づく人いると思うんですけど
実はこの図から見ると
実質的なテナントは1つしかないです
そしてみんなで一緒に見ようと言ったんですけど
結局一緒に面倒見れたのは一部の人です
開発者は結局自分のプロダクトだけを見ている感じです
そして退職者とか出てきたり
とうとう誰も見ていないプロダクトも誕生してしまいます
そして一部サービスには高いセキュリティ要件もありまして
移管するときにこれらは完全に満たすことができなくて
例えばその全レイヤーにおける完全無理
認証認可 コンピューリングストレージとネットワークなど
理由としては1つネットワークの方のボトルネックがありまして
これらは最後のページで少し話します
結果としてはそのサービスは別のクラウドアカウントで運用して
自分で基盤を持っていました
それでは単一テラントもいいので
これからはマルチセンターの話をしたいと思います
これは個人的な観点ですけど
マルチセンターの分離どうすればいいのか
個人的には4つの原則があるかなと考えています
まず2分後から始める分離戦略
これは何を目指しているかというと
一言で説明できるのが目標です
あと成熟度に応じた分離基準
これ分離の成熟度もありますので
それに応じてテナントの種類を適切に増やしたり
そういうことがあります
そして3点分離の起点は常にアイデンティティ
理想としてはIDPのロール
イコール全てのレイヤーのロールを目指しています
そして4番テナントの境界線の明示
アイデンティティの遺憾性とか
その効果を発揮するためのものだと考えています
これあくまで一つの観点です
では詳しく見ていきましょう
2分後から始める分離戦略
これはなぜこうするかというと
最初から複雑な体系を作ると
割と例外とか含まれてない
そういうテナントも発生してしまいます
まずはシンプルに
今の既存のテナントを2分後で分けてみましょう
そして分離の重要なところとしては
誰もが理解できるような共通語彙で
統一することが大事かなと考えています
例えばこの図のように
これは英語ですけど
保護と非語彙の意味で
いわゆるセキュリティ要件が高いような
テナントと特に要求がないようなテナントを分けています
その他にも管轄Aとか
監査対処とか非監査対処とか
そういう分離でもあります
そして2番
成熟度に応じた分離基準
こちらは分離の成熟度に応じて
さらなる分離を行って
種類を増やすことです
いろいろ基準がありまして
例えばさっき非保護のノンプロジェクトの方のテナントに
さらに接続性という観点で
外部向けのテナントと内部向けのテナントなど
あとそのプロジェクトの方に新しいテナントを追加したり
あと新しいテナントデータセキュアというようなテナントを増やすことも全然できます
そして3番
分離の起点は常にアイデンティア
これは本当に理想なんですけれど
実現は難しいかなと思いますが
内容としては唯一の真実権
そしてロールを管理して
全ての権限の出発点にすることです
そして人からグループ
グループからロール
ロールから権限の流れで
クラウド
Kubernetes
Devツールを全てのレイヤーに展開することです
4番
テナントの境界線の明示
AWSではリソースタグ
Kubernetes上ではラビルとか
そうやってテナントの境界を一貫して表現することは
結構大事かなと思います
あともう一つは
全てのレイヤーでは同じ語彙を使い回すことは結構大事かなと思います
それではこれらの原則を利用した各レイヤーの実装を見ていきましょう
今回はちょっと4つにまとめてみました
本来もっとネットワークレイヤーというのを作りたかったんですけど
ちょっと時間なかったんで
まずアイデンティティから
ロール&ポミッシュの方に
まずアイデンティティのレイヤーの実装は
一番大事なのがやっぱりITPの統一です
弊社では内製した認証人間基盤
パーマンというツールを使って
パーマンロールによるアルバックとか
それの連携が結構主流になっています
例えばAWSアカウントとか
Google Cloud
データドークフィグマンとか
全部パーマン認証を利用しています
そしてアメーバでは
実際このようなテナント
アイデンティティですね
主に3つに分けています
ノンプロジェクト
これ保護してないテナント
あと保護してるテナント
あと最後にデータセキュラーのテナント
それらは全部パーマンのIDP的には
それぞれロール名が持っていまして
そのロール名で各ツール
AWSとかKubernetesとか
全部同じようなロール名で
回収しております
ただロール名とテナント名
同じにする必要はありませんので
例えばノンプロジェクトフォーム
公文デベロッパーというような
名前にしています
そしてこれの効果としては
新しいメンバーが入るときに
オンボーディングは本当に
一つのパーマンロールだけで
全ての権限を付与することができました
ちょっとロール&ポリシー
ポリミッションの方は
ちょっと話したらあかんですけど
ちょっと時間ないので省略します
次にクラウドの方
AWSの方を話していきます
これは一つの分離例です
先ほどの見せた通り
プロジェクトとノンプロジェクト
両方ありまして
それらはIM上では
それぞれアトリビュート
いわゆるABCの認証方法を利用しています
ほぼテナントの方は
主にプロジェクトという
リソースタグを利用しています
加えてテナント雇用の
そういうアトリビュート
オーナーとかサービスコードとか
そういう組み合わせで
IMロールとかIMポリシーとか設計しています
ちょっとIMポリシーの設計の
一応設計ポイントを
5つまとめたんですけど
読み上げる時間ないので
後ほど各自で
もし読んでいただければ嬉しいです
ポリシーも実践経路も
結構長いんですけど
スピーカーデックでもし読んでいただければ
嬉しいです
次にKubernetesレイヤーの話です
これ主に3つですね
Rバック
Security Group for Bot
あとネットワークポリシーです
まずRバック
KubernetesのRバックの特徴としては
それはアローベースで権限追加する仕組みで
プラス条件付き制御で
できないということがあります
そして
ネームスペースイコールテナントの
結構そういう考え方が多くて
ネームスペース自体が
実質的な境界線になってます
そのネームスペースに
どのユーザーと
どのロールを追加するのか
それ分離の確信になります
あと
Avebaでは
ネームスペースグループと以外に
HNCを使ってて
ネームスペースを中小化してるんですけど
これメリットが1つありまして
それがRバックの継承とか
伝播が実現可能です
これ後ほど
こちらの図で説明していきます
例えばプロデクトの方は
テナントの
ペアレント
テナントシステムという名前
これネームスペースグループを設定します
これは1つのテナントです
このネームスペースグループに
テナントネーム
デベロッパーロールというような
ロールを作って
このロールは
自動的に
地主によって
全てのネームスペースに
継承していきます
結構付けやすいかなと思います
あと実装例も省略します
ネットワーク関しては
主にセキュリティグループと
ネットワークポリシーですけど
当時ボットルネックだったのも
この2つ
2点でした
そして2023年以降
いずれも改善されて
使えるようになりましたので
主に両方とも利用しています
ポットとポットの通信は
ネットワークポリシー
ポットとAWSソースタブは
データベースとか
セキュリティグループ4ポットを
使っています
ただ現時点では
ネットワークポリシーは
まだL4まで
対応していないので
もしL7まで対応できたら
セキュリティグループ4ポットが
不要になるかなと思います
ネットワークポリシーに関しても
こちらもさっきのHNC
ネームスペースグループによって
継承することができます
ここでは1つの設計例を
示しています
主にこのネームスペースグループを
利用して
チャイルドネームスペースのみ
許可するような
この設計例になります
最後に
Devツールに関しては
ちょっと軽く飛ばしていきます
GitHubに関しては
同じロールを使用しています
ただこのロールは
リポジトルを分けているときに
使えるので
共通リポジトルのときに
コードオーナーとか設定して
チーム名とか
設定したほうがいいかなと思います
R50に関しては
同じロールを使っています
ただサムルを使えないので
GitHub Teamsを
経由で連携しています
ネームスペースごとに
プロジェクトを作成して
そのプロジェクトに
グループとか結びつき入っています
データドッグの方も
似ているような感じで
データドッグのチームズを
連携しています
ただ
対応しないリソースも多いので
そこをちょっと気をつけて
使ったほうがいいかなと思います
第5部
現行政権の制約について
主に2点ですけど
話していきます
まずテナント境界線表現
実は限界がありまして
先ほどオーナータグとか
設定したんですけど
これ実はこれだけでは
表現しきれないケースがあります
例えば
保護テナントの
オーナー事業
保護テナントのAとBありまして
その間に原点的に
共有するジョブシステムがあります
そのジョブシステムは
どうやって表現するのか
結構難しかったです
あともう一つ
テナント間の通信が
結構ありますので
既存設計では
プロテクトのテナント間ではなくて
プロテクト非プロテクトの
そういう分離が結構中心だったので
この間も
テナント間の通信も
結構難しいかなと思います
一応現段階の設計方法としては
まずテナント境界線に関しては
補助の語彙を追加して
新しい追加することです
タグ
例えばこの右下のように
新しいタグ
シェアドウィズテナントとか
シェアドウィズテナント
こういうタグを設計してます
ただ難しいのは
これ共有元の
IMポリシーと共有先のIMポリシー
全部追記する必要がありますので
結局IMポリシーの複雑化が
避けられないです
2番のほう
テナント間通信の複雑化
これもネットワークポリシーで
組み合わせで解決できるかなと思います
ただ
一つのケースを実現するには
複数のネットワークポリシーが必要なので
できるだけ
テナントの需要に応じた
そういう宣言的な設定を
サポートしたほうがいいかなと
考えています
こちらは
オープンアプリケーションモデル
先ほどの
セッションで紹介した
クビベラというアプリケーションを
使っています
そこで
YAMLとか
自分の定義することができますので
ここに
例えば
アローテナントの
YAMLに
BとCが置いて
それらは
自動的に
こういう複数の
ネットワークポリシーの
YAMLに
変換されます
ただこれは
クロスネームスペースの
リソース管理なので
結構難しいかなと
考えています
最後にまとめです
本日は
まず
Amoebaの設計
テナント設計の背景について
話ししました
そして
個人的な観点ですけど
テナント分離の原則を
主に4つ
説明しました
最後に
この原則を
使用した
原稿の設計とか
その設計の制約とか
対処方法とかも
説明しました
こちらも同じく
左右情報です
Amoebaプラットフォーム
採用しています
そして私の所属の
SRGも採用しています
ご清聴ありがとうございました
素晴らしいご講演
ありがとうございました
それではこれより
Q&Aセッションに移ります
こちらのQRコードから
ぜひ読み取っていただいて
質問をお願いいたします
早速1つ質問いただきましたね
1つ目の質問として
設定を行うのは
開発者ですかね
という質問ですが
こちらの設定というのは
どちらの設定ですかね
もし
そうですね
プラットフォーム的に
例えば先ほどの
ネットワークポリシーとか
そういう設定でしたら
提供したYAMLなら
開発者が
自分で設定するんですけれど
そのYAMLを
使えるようになるまでは
プラットフォーム開発者が
行うという感じで
それ以外だと
例えば認証とか
あとIDなどの設定は
これはプラットフォーム開発者が
設定しています
これで質問回答できたら
ありがとうございます
他に質問などあれば
お待ちしております
早速1ついただきました
ネットワークポリシーの設定
正しいかどうか
担保を行っていますでしょうか
基本的に
テストはいっぱいしてますね
あとネットワークポリシーの設計に関して
一応のシミュレーターみたいな
ツールもありますので
そちらでテストをして
あと実環境でテストをして
最後に提供する形になります
もちろんテンプレート化すると
結構
複数のネットワークポリシーを
組み合わせて
動作できるかというと
そこはちょっと微妙なところがありますので
そこはネットワークポリシーの複雑さかなと
考えています
ありがとうございます
続いての質問に移ります
ワンプロダクト
ワンネームスペースの運用だと
具体的にどの部分が
辛みだったとかありますか
という質問です
そうですね
弊社の特にアメーバのプロダクトだと
一つのプロダクトに結構
マイクロサービスが複数分かれていて
ちょっと歴史的な背景もありまして
その同じプロダクトを複数のチームが
同時に開発することもあります
それなのでそもそもネームスペースの分け
設計の段階では結構複数のネームスペースに
分けることも結構多かったので
そうですね
つらみですね
ちょっとあんまりそこのつらみとか考えてなくて
多分当時は開発者はそういう風に想定して
複数に分けたんじゃないかなと考えています
ありがとうございます
続いての質問に移ります
HNCはアーカイブ化されていますが
今後もHNCをベースとしていく予定でしょうか
という質問です
そうですね
HNC意外とユーザーもいまして
今確かサイボーズ様がそれをフォークして
独自に開発を追加しているらしいんですけど
近いうちにサイバージドも
特にアメーバプラスチームもそのフォークの開発にも参加しようかなと考えています
現時点はちょっとHNCの代用できるようなエコシスマは存在しないので
結構現時点は結構迷っている感じかなと思います
ありがとうございます
続いての質問に移ります
デプロイの単位
結合テストシステムテストの単位との関連はどうされていますかという質問です
結構テストシステムテストに関しては
すいませんちょっと私が把握できていません
デプロイの単位に関しては
基本的に先ほど見せたクベベラというものを利用したアプリケーションという単位になります
このクベベラアプリケーションを
複数のクベベラアプリケーションを
一つのR5CDアプリケーションに集合して
まとめてデプロイしています
あとテストの関連ではないですけど
一応デプロイの順番とかありまして
そこら辺の制御はR5ワークフローで制御しています
ありがとうございます
続いての質問ですが
ロールに与えるパーミッションや
IAMは当初の設計で期待通り機能していますか
ユーザーからの要望で頻繁に変更されたりしますか
という質問ですがいかがでしょうか
実は発表省略された部分の中では
2019年の設計で
当時のデベロッパーロールとアドミンロールでは
開発者が全然要望が来たりして権限足りないとか
そういうことがあったので
それに対して
実はそれも省略のページで説明したんですけど
不要だったロールを消したり
あと開発者向けのデベロッパーロールを一定の範囲でアドミンのような権限を付与したり
そういうこともしています
そうすることで今のところ特に変更の要望とかまだ来ていません
ありがとうございます
他に質問はございますでしょうか
もしなければ残りわずかに時間ありますので
何か伝えたいこととかあればぜひお願いします
そうですね
結構PDF
IMロールのポリシーの設計の方は結構力入れたので
特にノートアクションとかノートリソースというところを使っています
ぜひ設計の一例として参考にいただければと思います
それはPDFにあります
PDFじゃないスピーカーデックにありますので
ぜひ読んでみてください
ありがとうございます
以上でセッションを終了いたします
皆さまもう一度盛大な拍手をお願いいたします
拍手