SREがGoogleCloud検証環境をCloudNativeな視点で、 頑張りすぎずでも良い感じに整えた話 Copyright © 3-shake, Inc. All Rights Reserved. 2023/12/13 Jagu'e'r CloudNative分科会- @866mfs

Whoami SaaS企業でWebアプリケーション開発や企業向けパブリッククラウド構築支 援を経験したのち、2023/7月より株式会社スリーシェイクでSREをやってい ます。 現在は、GoogleCloudやk8sを使用したエンプラ企業へのSRE支援を行って います。 海外サッカー観戦が生きがいです。 Annosuke Yokoo (@866mfs) 株式会社スリーシェイク Sreake 事業部

Agenda 01. GoogleCloud検証環境整備の背景 02. やったこと 03. やらなかったこと 04. 活動を通して得られたこと 05. クラウドガバナンス強化に向けて＋α

About 3-shake

　Sreake SRE（SRE総合支援サービス） 技術戦略から設計、構築、運用までワンストップ支援する 技術支援サービス 技術戦略 コンサルティング システム 設計 構築 / 実装 支援 アセスメント （パフォーマンス / セキュリティ） 運用支援 Micro Service , Multi Cloud や k8sをはじめとしたCloud Native な先進的技術及び大規模なサービス運用 に強みを持つエンジニアによる技術支援 ベンダー的な役割ではなく「お客様の チームメンバー」という立ち位置で最新技術の提案から運用支援までをトータ ルご支援

今日話すこと そんなSreake事業部で、無法地帯だった社内のGoogleCloud検証用環境を、 CloudNativeな技術に触れているSREならではの視点から、頑張りすぎず良い感じ に整備した事例のお話です （テクニカルに難しいことはしてないので再現性は高い（はず）です！）

「頑張りすぎず」とは？ このような組織ガバナンス活動においてはゴールが明確でないと、いつまでもダラダラと続いてしまっ たり、途中で頓挫してしまいがちなので活動スコープを定義 活動における前提は以下 ● あくまで社内活動のため案件対応を優先とする ● 活動に当てる工数は各自の10~20% ● 費用対効果の低い改善については実施しない ● 改善活動の期間は2か月と限定し、スコープ内で出来る範囲のことに取り組む

GoogleCloud検証環境整備の背景 01 Copyright © 3-shake, Inc. All Rights Reserved.

活動背景 / 課題 3-shakeでは、社員なら誰でも GoogleCloud の各種サービスを自由に試せる 検証環境用アカウント （以降：test.orgと表記）が存在 【課題：例】 ● 誰でもプロジェクトを作成可能（プロジェクトの課金紐付けは要情シス申請）なので、アカウント統制が皆無の カオス状態 ○ 未使用のプロジェクト・リソースがそのままになってしまっていることも多々ある ● コスト管理についてモニタリングの仕組みが出来ていないので、それなりの高額請求になってしまっているこ ともしばしば ● セキュリティ的に問題が無い使われ方か把握できていない ● 新入社員が把握できていない / 離職者のアセットや権限が放置されている

やったこと 02 Copyright © 3-shake, Inc. All Rights Reserved.

活動目標と意義を明確化 🏁 Sreakeのエンジニアが安心して快適に検証環境を利用できるように、管理・改善活動を行う ● 「Sreakeのエンジニア」 ○ 最小限のスコープとするため他事業部は考慮しない ● 「安心して」 ○ コスト / セキュリティ ● 「快適に」 ○ コスト / セキュリティを考慮しすぎて開発者体験が悪くならないように ● 「管理・改善」 ○ 仕組みと体制作りを行う ○ 形骸化しないように利用状況の把握や認知を行い、ユーザビリティ向上のための活動は継続して実施 ○ 属人化しないように、責任範囲を広げていく（手離れさせることも重要）

活動目標と意義を明確化 🏁 Sreakeのエンジニアが安心して快適に検証環境を利用できるように、管理・改善活動を行う ● 「Sreakeのエンジニア」 ○ 最小限のスコープとするため他事業部は考慮しない ● 「安心して」 ○ コスト / セキュリティ ● 「快適に」 ○ コスト・セキュリティを考慮しすぎて開発者体験が悪くならないように ● 「管理・改善」 ○ 仕組みと体制作りを行う ○ 形骸化しないように利用状況の把握や認知を行い、ユーザビリティ向上のための活動は継続して実施 ○ 属人化しないように、責任範囲を広げていく（手離れさせることも重要） Toilの削減や自動化といったSREライクな視点 ＋ 将来的な周辺エコシステムと連携した利活用を促進できるように CloudNativeな視点も意識して実践していく！

CNCF曰く CloudNativeとは？ クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナ ミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらしま す。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラク チャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自 動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うこ とができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維 持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノ ベーションを誰もが利用できるようにします。 CNCF Cloud Native Definition v1.0 https://github.com/cncf/toc/blob/main/DEFINITION.md#%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88

テクニカルに CloudNativeなポイントは？ クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナ ミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらしま す。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラク チャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自 動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うこ とができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維 持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノ ベーションを誰もが利用できるようにします。 CNCF Cloud Native Definition v1.0 https://github.com/cncf/toc/blob/main/DEFINITION.md#%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88 ● 疎結合である ● 復元力がある ● 管理しやすい ● 可観測である ● 堅牢な自動化により、頻繁かつ期待通りに最小限の労力で大きな変更が可能

現状把握（Before）

現状把握 - いけてないポイント ● Org 配下にフォルダ・プロジェクトが無秩序に乱立 ● MyFirstProject大量発生 ● 権限に制限は無く、他プロジェクトも自由に参照・更新・削除可能 ● どのプロジェクトが使用中か分からない🤦 ● etc..

フォルダ構成設計（After）

フォルダ構成設計 ❏ 第1階層 ❏ 事業部ごとでプロジェクト運用の仕方や使い方が異なるため、組織横断とはぜず事業部単位でのフォルダ管理とすること で、責任範囲の明確化と独立性の高い構成 ❏ 第2階層 ❏ 事業部内での活動もいくつかあるため、検証のメインとする sandboxフォルダとその他プロジェクトを分別し配置

フォルダ構成設計 ❏ 第3階層以下 ❏ 「社員番号_name」フォルダという命名規則の元、個人フォルダを作成 ❏ 命名規則統一と責任範囲の明確化による管理のしやすさを向上 ❏ management ❏ コストアラートやその他管理に必要なリソースが存在 ❏ terraform ❏ stateファイルを管理する GCSが存在

権限設計 👈設計したリソース階層構造 GoogleCloudはリソース階層を使用したアクセス制御が行われる ”組織ノードが階層のルートノードで、プロジェクトは組織の子ノード、その 他のリソースはプロジェクトの子孫になります。許可ポリシーは、リソース 階層のさまざまなレベルに設定できます。リソースは親リソースの許可ポ リシーを継承します。リソースで有効な許可ポリシーは、そのリソースに 設定された許可ポリシーとその親リソースから継承された許可ポリシーを 組み合わせたものです。”

権限設計 Stuffグループ ● Sreake事業部メンバー（ Adminグループのメンバーも含む） ● 継承Role ○ roles/browser ○ roles/viewer ○ roles/resourcemanager.folderCreater ○ roles/resourcemanager.projectCreater ● 新規プロジェクト作成時 ○ roles/owner Adminグループ ● 運用に携わる GoogleCloud検証環境整備チーム ● 継承Role ○ roles/resourcemanager.folderAdmin

Terraform構成管理 ● main.tf ○ module呼び出し / resource作成処理 ● modules/managed-folders ○ 第2階層フォルダリソースを管理する ○ フォルダに対するRoleを管理 ● modules/personal-sandbox-folder ○ 第3階層以下（sandboxフォルダ配下）のフォルダ リソースを管理 ● variables.tf ○ 次スライドで後述

Terraform構成管理 variables.tf ● メンバー情報をvariableとして保持 ● メンバースケール時には、当ファイルに user_account と folder_nameを追記して applyするだけで管理可能に！

IaCスコープによる責任範囲の明確化 ★ 各メンバーの責任範囲を考える際に意識したこと ● 運用チームの負荷を最小限にしつつ、各メンバーがガバナンス意 識を持って使用できること ● 個人フォルダ（社員番号_nameXX）配下については、当該メン バーが責任を持つこと 検証の柔軟性とオーナーシップの強化を図り、個人フォルダ配下は terraformでの構成管理には含めず、権限もroles/ownerをアタッチ

その他 ❏ 既存プロジェクトの要否確認 📃 構成に基づき、元々全 33プロジェクトあったうちの 18プロジェクトを削除 プロジェクトを削除する際には、アナウンスの頭出しからメンバーへのヒアリング、整理実行までの期間をおよそ 10日前後設け、活動周知や合意 形成の期間を十分に確保しながら実施 （このあたりはハレーションも起きる可能性があるので結構気を使ったポイント） ❏ 啓蒙活動 📣 そもそもの活動背景から認知してもらうため、ドキュメントとしてナレッジの展開や事業部メンバーが集う会での周知活動など、メンバー各人にオー ナーシップを持ってもらう啓蒙活動も実施

Opsへの落とし込み これまでGoogleCloud検証環境は、使いたい人が自由にプロジェクトを作成するような環境となっており、運用フローは全く定まっていなかった →　GoogleGroupのAdminグループメンバーが運用の役割を担当 →　運用フローとして乗せやすい入社時・離職時の オンボーディング & オフボーディング に組み込む

やらなかったこと 03 Copyright © 3-shake, Inc. All Rights Reserved.

やらなかったこと ❏ 他事業部関連プロジェクトへの介入 スコープを最小限にするという点から他事業部に関することはフォルダー作成・該当プロジェクト配置のみを行い、中身の精緻化については実施 せず ❏ CI/CD 組織のスケールやシュリンクが現状頻繁に発生しない点と、 CI/CD構築に対する稼働コストパフォーマンスの観点からこのタイミングで実施するこ とは見送り ❏ 組織ポリシーの適用 GoogleCloudには組織ポリシーと呼ばれる組織レベルからリソース使用に関わる制約を適用する機能が存在 ● 適用した方が良さそうな制約を選定 ○ iam.allowedPolicyMemberDomains ○ constraints/gcp.resourceLocations ○ constraints/compute.vmExternalIpAccess ○ etc.. ● 制約に対する脅威とリスクの洗い出し ● チーム内にて協議 協議の結果、組織ポリシーを適用することが GoogleCloud検証環境利用における本質的な課題解決につながらないかつ、 あくまでも「検証環境」という位置付けのため、 利用制限・運用負荷は最小限にし、 検証の柔軟性が下がらない ことを考慮し実施せず

活動を通して得られたこと 04 Copyright © 3-shake, Inc. All Rights Reserved.

活動を通して得られたこと 1. 一定レベルのクラウドガバナンス 権限管理、構成管理を適切に実施することで、クラウドガバナンスレベルの水準底上げ （メンバー各自のガバナンス意識に依存してしまう部分も一定あり） 2. 運用負荷低減 運用の自動化を推進することで定常的に行う作業の削減（トイル削減） 現在は月次でMTGを実施し、利用状況のモニタリング、運用事項のブラッシュアップへ向けたディスカッションを実施 3. コストモニタリング・利用状況の可視化が容易 事業部ごとやメンバーごとフォルダ構成としたことにより、 Billing Reportの標準的なフィルタリングのみでコストやリソース使用状況の取得可能

活動を通して得られたこと クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナ ミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらしま す。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラク チャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自 動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うこ とができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維 持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノ ベーションを誰もが利用できるようにします。 CNCF Cloud Native Definition v1.0 https://github.com/cncf/toc/blob/main/DEFINITION.md#%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88 ● 疎結合である ○ 利用に際して事業部間 / メンバー間での依存関係が無く、独立性が高くオーナーシップ増加にも寄与 ● 復元力がある ○ terraformで構成管理をしているため即時のプロビジョニング / リカバリーが可能 ● 管理しやすい ○ 構成内容が明文化されているかつ冪等性のある構成を実現 ● 可観測である ○ 差分検知にはプルリクエスト , Logベースで管理できる GoogleCloud各種ログと連携することでさらにクラウドガバナンス向上が見込まれる ● 堅牢な自動化により、頻繁かつ期待通りに最小限の労力で大きな変更が可能 ○ 組織のスケール対して最小限の変更かつ運用フローと統合して環境のスケールが可能

クラウドガバナンス強化に向けて+α 05 Copyright © 3-shake, Inc. All Rights Reserved.

クラウドガバナンス強化（例1 ❏ GoogleCloudに関する様々なログ情報を一元的にBigQueryに集約し、監視したいメトリクスをBigQueryから取得 ❏ Cloud Run Jobs or Cloud Functionsから定期的にクエリを実行し、モニタリングを行いアラート検知したらSlack通知

クラウドガバナンス強化（例2 ❏ Cloud Monitoring と Cloud Run を使用したカスタム通知の作成 ❏ https://cloud.google.com/blog/ja/products/operations/write-and-deploy-cloud-monitoring-alert-notifications- to-third-party-services ❏ Billing Reportからプロジェクト単位で抜粋して条件をユーザが選択できる Slack通知ボット ❏ Cloud Audit Logsを併用してresource createrを特定し、リソース使用の有無を選択できる機能

参考資料 Copyright © 3-shake, Inc. All Rights Reserved. ● 「VM 時代の開発とKubernetes による Cloud Native な開発のこれから」 Infra Study Meetup #2 / infrastudy2-k8s ○ https://speakerdeck.com/masayaaoyama/infrastudy2-k8s ● 新米Google Cloud管理者の奮闘記のその後 〜Organizationの秩序を維持する試み〜 ○ https://techblog.zozo.com/entry/gcp-governance-after

Thank you Copyright © 3-shake, Inc. All Rights Reserved.