パブリッククラウドアカウントの DeNA 的管理手法 (全体編) 小池 啓輔

経歴 ● 2019 年に新卒入社 ● インフラ部門所属 (システム本部 IT 統括部 IT 基盤部) ○ 70 %: 全世界向け大型ゲームタイトルのインフラ ○ 30 %: パブリッククラウド管理チームのチームリーダー インフラエンジニア/ SRE ● （楽をするための）自動化・効率化が大好き 自己紹介: 小池 啓輔

パブリッククラウド管理チーム？ 権限管理の標準化 コスト管理の標準化 セキュリティの標準化 アカウント管理の標準化 クラウド化に向けて必要だった標準化 パブリッククラウド管理チームで標準化 ✓ ✓ ✓ ✓ システム基盤の標準化 ネットワークの標準化 ✓ ✓ 全社のパブリッククラウド利用を最適化するチームへ 標準化後 FYI: AWS Summit Online 2021/5/11 での弊社南場の基調講演

DeNA パブリッククラウドアカウント数推移 ● 数十件/月の作成・削除 ● 総計: 1,000 以上！ 完全クラウド移行完了！ 標準化でカオスを避けられた！ 2018-06 標準化 クラウド移行

今日話すこと 権限管理の標準化 コスト管理の標準化 セキュリティの標準化 アカウント管理の標準化 クラウド化に向けて必要だった標準化 ✓ ✓ ✓ ✓ システム基盤の標準化 ネットワークの標準化 ✓ ✓ パブリッククラウド管理チームで標準化 全社のパブリッククラウド利用を最適化するチームへ 標準化後 1,000 以上のパブリッククラウドアカウントを “カオス” にならずに管理するために DeNA インフラ部門がやってきたことを伝えたい

アカウント管理の標準化 要件：アカウント数が増えてもカオスにならないこと アカウントの命名規則 アカウントの粒度 アカウント管理工数の削減 : 名前だけで必要十分な情報を得られるのがベスト ● Organization / Payer ● アカウント台帳 WebApp ● アカウント作成自動化ツール : 権限・費用管理の容易さと管理工数とのトレードオフ。最適点は？ : 技術力で管理工数を削減できないか？

アカウント管理の標準化 〜命名規則〜 dena - $SERVICE_NAME - $ENV $CLOUD_TYPE - ● アカウント名だけで必要十分な情報を得られるのがベスト 規則 目的 Prefix dena 他社とかぶらないように Interfix 1 $SERVICE_NAME 各サービスを判別できるように Interfix 2 $ENV 環境(本番？staging？開発？)を判別出来るように e.g.) -prod / -stg / -dev Suffix $CLOUD_TYPE 各クラウドを判別できるように e.g.) -aws / -gcp / -dd (Datadog) / -fastly アカウントの粒度 mobage とか Pococha とか

アカウント管理の標準化 〜アカウント粒度〜 アカウント粒度 総アカウント数 権限管理工数 費用按分工数 オペミス等の影響範囲 分けない （巨大な1アカウント） 少ない とても大変 とても大変 他の Service に影響が出うる Service 毎 中 Env 毎にすると 手間 Service 毎に 管理できて楽 他 Env に影響が出うる Service + Env 毎 膨大 アカウント毎に 管理できて楽 アカウント毎に 管理できて楽 限定的で安全 膨大なアカウントの管理工数 アカウント台帳 WebApp を下げられれば Service + Env 毎が Best ! 膨大なアカウントの作成工数 アカウント作成自動化 で解決 組織一括管理 (Organization/Payer) mobage とか Pococha とか Production とか Staging とか Development とか

アカウント管理の標準化 〜組織一括管理(Organization/Payer) 〜 AWS GCP PagerDuty Fastly Datadog Photon Cloud cloudpack Zendesk … 【Organization】 アクセス権限やルールなどを一括管理するもの 【Payer】 請求先情報を一括管理するもの 基本的な考え方は 他パブリッククラウドでも同じ Linked Account Linked Account Linked Account パブリッククラウド管理チーム 各サービス管理部門 自身のアカウントの リソース管理だけに注力！

アカウント管理の標準化 〜アカウント台帳 WebApp 〜 【初期】スプレッドシートで管理 要件 ● CRUD 機能 ● 一覧性・検索性 ● 各種社内システムとの連携 ○ 計上関連システム → 非エンジニア用にスプレッドシート出力が必要 ○ クラウド自動監査 ○ アカウント自動作成 API 機能が必要 ● CRUD 機能： ○ ● 一覧性・検索性：△ （数が増えると重い） ● スプレッドシート出力: ○ ● API 機能: × ● ×: 誤操作による削除、転記ミスなどが多発 RoR で WebApp を内製

アカウント管理の標準化 〜アカウント台帳 WebApp 〜 スプレッドシート出力機能 検索機能 Google OAuth 2.0 アカウントの一覧 ● CRUD の権限管理用 ● スプレッドシート出力用権限用

アカウント管理の標準化 〜アカウント台帳 WebApp 〜 アカウント情報 費用負担部門情報 社内管理用情報 ● アカウントを特定できる情報 ● 何のためのアカウントか？ ● どの部署のどのサービスの持ち物か？ ● どこに費用を請求するか？ ● 担当者の連絡先は？ ● 作成時の申請 kintone は？ 必要十分な機能・情報！ アカウントのステータス ● 稼働中？解約済み？ ● いつ解約された？

アカウント管理の標準化 〜アカウント台帳 WebApp 〜 転記ミスがなくなり 工数・ストレスも削減！ 手入力せざるをえない場合も validation でミスを防ぐ 各種ツール群とも連携！ 手軽に Export !

アカウント管理の標準化 〜アカウント作成自動化〜 ● 毎月数十の新規作成依頼 ● 依頼は kintone に集約 ○ 自動化ツールも kintone から情報取得 ● ほぼ全自動。手入力はない。 ○ 工数削減 & データの信頼性向上 https://engineering.dena.com/blog/2020/03/improved-public-cloud-accounts-creation/

アカウント管理の標準化のまとめと効果 アカウントの命名規則 アカウントの粒度 Organization / Payer アカウント台帳 WebApp ● "謎アカウント" の発生： 2, 3 件/年 → ゼロ 件 ！ ● 一括管理により工数削減・ルールの厳格化 ● サービス管理部門も リソース管理だけに注力 アカウント作成自動化 ● アカウント管理の標準化設定のとりまとめ ● 自動化による工数削減 ( 実働： 45 分/件 → 5 分/件 ！ ) ● 作成依頼 → アカウントの提供 の時間も短縮 ○ 基本的には 当日対応 （ベストエフォート） 行方不明・未使用アカウントの放置

権限管理の標準化 要件：アカウント数が増えてもカオスにならないこと 退職者・異動者棚卸の効率化 SSO login (Okta) 権限管理工数の削減 : 社員情報が入っている Active Directory と連携 : クレデンシャルの一元管理。PW 変更等の工数削減。 : 通常運用はサービス管理部門で... パブリッククラウド管理チームは基本的に動かない 権限管理用 Google Groups で実現！

権限管理の標準化 〜なぜ Google Groups ？〜 ● 社員 : Google アカウントが 1 対 1 対応 ● という仕組みが整っていた 社内事情 運用メリット ● パブリッククラウド管理チームの管理対象が激減 ○ Google Groups だけの管理で ok。byname IAM User 不要 ● アカウント作成時のキッティングが楽 ○ アカウントの権限と Google Groups を紐付けるだけ ● アカウントの権限管理者の学習コストが低い ○ Google Groups のメンバーを追加・削除するだけ : Google Groups でメンバーを管理するという文化

権限管理の標準化 〜権限管理用 Google Groups〜 ネストが出来るので 管理 Google Groups をまとめられる キッティング時に Owner だけ追加

権限管理の標準化 〜 GCP での権限管理用 Google Groups 〜 GCP では直接 Google Groupsに 権限をつけられる ● IAM に Google Group を紐付け → Google Workspace に Okta Login ● 簡単！ シンプル！

権限管理の標準化 〜 AWS での権限管理用 Google Groups 〜 ● AWS では 直接 Google Groups 連携はできない…… ● 複雑そうに見えるが、使い勝手は AWS/GCP で大差ない ● Switch Role 用の設定は Batch 処理で順次追加 Okta の AWS フェデレーション設定工数 大 ↓ step アカウントのみにして回避

権限管理の標準化のまとめと効果 退職者・異動者棚卸の効率化 SSO login (Okta) 権限管理工数の削減 権限管理周りの消耗なし！！ ● クレデンシャル管理工数減 ● UX 向上 ● 「アカウントにログインできなくなった！」 が ゼロ に！ ● 退職者のクレデンシャル持ち出しリスクの軽減 ● サービス管理部門で完結！ ● パブリッククラウド管理チームの "強い" 権限は必要なし ○ クラウド化前後の対応件数：2, 3 件/月 → ゼロ 件！

まとめとその他の標準化に関して 権限管理の標準化 コスト管理の標準化 セキュリティの標準化 アカウント管理の標準化 クラウド化に向けて必要だった標準化 ✓ ✓ ✓ ✓ システム基盤の標準化 ネットワークの標準化 ✓ ✓ ● 2022/03/12 6 社合同 SRE勉強会 Torigoe / Birukawa の発表 ● DeNA Tech Blog (クラウドネットワーク編) ● 本日お話しした内容 ● (まとまったものはない mm) FYI: AWS Summit Online 2021/5/11 での弊社南場の基調講演