Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Google Cloudの管理を楽にする、 トイルを減らすクラウドガバナンス

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.

Google Cloudの管理を楽にする、 トイルを減らすクラウドガバナンス

Avatar for Annosuke Yokoo

Annosuke Yokoo

February 11, 2024
Tweet

More Decks by Annosuke Yokoo

Other Decks in Technology

Transcript

  1. Copyrights©3-shake Inc. All Rights Reserved. 2 現在は、GoogleCloudやk8sを使用したエンプラ企業へのSRE支援を行って います。 Cloud Native分科会

    / Observability-SRE分科会 中心に参加中 学生時代の修学旅行は関西だったので、沖縄には人生で一度もまだ行けて いません... ですが、心は「はいさーい!」と叫んでいます! Annosuke Yokoo (@866mfs) 株式会社スリーシェイク Sreake 事業部 Who am I
  2. Copyrights©3-shake Inc. All Rights Reserved.  Sreake SRE(SRE総合支援サービス) 技術戦略から設計、構築、運用までワンストップ支援する 技術支援サービス 技術戦略

    コンサルティング システム 設計 構築 / 実装 支援 アセスメント (パフォーマンス / セキュリティ) 運用支援 Micro Service , Multi Cloud や k8sをはじめとしたCloud Native な先進的技術及び大規模なサービス運用 に強みを持つエンジニアによる技術支援 ベンダー的な役割ではなく「お客様の チームメンバー」という立ち位置で最新技術の提案から運用支援までをトータ ルご支援
  3. Copyrights©3-shake Inc. All Rights Reserved. Agenda 01. GoogleCloud検証環境整備の背景 02. やったこと

    03. やらなかったこと 04. 活動を通して得られたこと FYI. クラウドガバナンス強化に向けて+α
  4. Copyrights©3-shake Inc. All Rights Reserved. 活動背景 / 課題 3-shakeでは、社員なら誰でも Google

    Cloud の各種サービスを自由に試せる 検証環境用アカウント (以降:test.orgと表記)が存在 【課題:例】 • 誰でもプロジェクトを作成可能なので、アカウント統制が皆無のカオス状態 ☠ • コスト管理についてモニタリングの仕組みが出来ていないので、それなりの高額請求になってしまっているこ ともしばしば • セキュリティ的に問題が無い使われ方か把握できていない • 新入社員が把握できていない / 離職者のアセットや権限が放置されている
  5. Copyrights©3-shake Inc. All Rights Reserved. 活動背景 / 課題 3-shakeでは、社員なら誰でも Google

    Cloud の各種サービスを自由に試せる 検証環境用アカウント (以降:test.orgと表記)が存在 【課題:例】 • 誰でもプロジェクトを作成可能なので、アカウント統制が皆無のカオス状態 ☠ • コスト管理についてモニタリングの仕組みが出来ていないので、それなりの高額請求になってしまっているこ ともしばしば • セキュリティ的に問題が無い使われ方か把握できていない • 新入社員が把握できていない / 離職者のアセットや権限が放置されている 社内の検証環境、誰が管理していますか? 情シス?古参の偉い人?プロダクトチーム? 明確に決まっていない?
  6. Copyrights©3-shake Inc. All Rights Reserved. 活動目標と意義を明確化 🏁 Sreakeのエンジニアが安心して快適に検証環境を利用できるように、管理・改善活動を行う • 「Sreakeのエンジニア」

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

    ◦ 最小限のスコープとするため他事業部は考慮しない • 「安心して」 ◦ コスト / セキュリティ • 「快適に」 ◦ コスト・セキュリティを考慮しすぎて開発者体験が悪くならないように • 「管理・改善」 ◦ 仕組みと体制作りを行う ◦ 形骸化しないように利用状況の把握や認知を行い、ユーザビリティ向上のための活動は継続して実施 ◦ 属人化しないように、責任範囲を広げていく(手離れさせることも重要) Toilの削減や自動化といったSREライクな視点 + 将来的な周辺エコシステムと連携した利活用を促進できるように CloudNativeな視点も意識して実践していく!
  8. Copyrights©3-shake Inc. All Rights Reserved. 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
  9. Copyrights©3-shake Inc. All Rights Reserved. テクニカルに 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 • 疎結合である • 復元力がある • 管理しやすい • 可観測である • 堅牢な自動化により、頻繁かつ期待通りに最小限の労力で大きな変更が可能
  10. Copyrights©3-shake Inc. All Rights Reserved. 現状把握 - いけてないポイント • Org

    配下にフォルダ・プロジェクトが無秩序に乱立 • 「MyFirstProject」大量発生 • 権限に制限は無く、他プロジェクトも自由に参照・更新・削除可能 • どのプロジェクトが使用中か分からない🤦 • etc..
  11. Copyrights©3-shake Inc. All Rights Reserved. フォルダ構成設計 ❏ 第1階層 ❏ 事業部ごとでプロジェクト運用の仕方や使い方が異なるため、組織横断とはぜず事業部単位でのフォルダ管理と

    することで、責任範囲の明確化と独立性の高い構成 ❏ 第2階層 ❏ 事業部内での活動もいくつかあるため、検証のメインとするsandboxフォルダとその他プロジェクトを分別し配置
  12. Copyrights©3-shake Inc. All Rights Reserved. フォルダ構成設計 ❏ 第3階層以下 ❏ 「社員番号_name」という命名規則の元、個人フォルダを作成

    ❏ management ❏ コストアラートやその他管理に必要なリソースが存在 ❏ terraform ❏ stateファイルを管理するGCSが存在
  13. Copyrights©3-shake Inc. All Rights Reserved. 権限設計 Stuffグループ(事業部メンバー全員) • 継承Role ◦

    roles/browser ◦ roles/viewer ◦ roles/resourcemanager.folderCreater ◦ roles/resourcemanager.projectCreater • 新規プロジェクト作成時 ◦ roles/owner Adminグループ(GoogleCloud検証環境整備メンバー) • 継承Role ◦ roles/resourcemanager.folderAdmin
  14. Copyrights©3-shake Inc. All Rights Reserved. Terraform構成管理 • main.tf ◦ module呼び出し

    / resource作成処理 • modules/managed-folders ◦ 第2階層フォルダリソースを管理する ◦ フォルダに対するRoleを管理 • modules/personal-sandbox-folder ◦ 第3階層以下(sandboxフォルダ配下)のフォルダ リソースを管理 • variables.tf ◦ 次スライドで後述
  15. Copyrights©3-shake Inc. All Rights Reserved. Terraform構成管理 variables.tf • メンバー情報をvariableとして保持 •

    メンバースケール時には、当ファイルに user_account とfolder_name を追記して applyするだけで管理可能に!
  16. Copyrights©3-shake Inc. All Rights Reserved. IaCスコープによる責任範囲の明確化 ★ 各メンバーの責任範囲を考える際に意識したこと • 運用チームの負荷を最小限にしつつ、各メンバーがガバナン

    ス意識を持って使用できること • 個人フォルダ(社員番号_name)配下については、当該メン バーが責任を持つこと 検証の柔軟性とオーナーシップの強化を図り、個人フォルダ(社員番 号_name)配下はterraformでの構成管理には含めず、権限も roles/ownerをアタッチ
  17. Copyrights©3-shake Inc. All Rights Reserved. その他 ❏ 既存プロジェクトの要否確認 📃 構成に基づき、元々全

    33プロジェクトあったうちの 18プロジェクトを削除 プロジェクトを削除する際には、アナウンスの頭出しからメンバーへのヒアリング、整理実行までの期間をおよそ 10日前後設け、活動周知や合意 形成の期間を十分に確保しながら実施 (このあたりはハレーションも起きる可能性があるので結構気を使ったポイント) ❏ 啓蒙活動 📣 そもそもの活動背景から認知してもらうため、ドキュメントとしてナレッジの展開や事業部メンバーが集う会での周知活動など、メンバー各人にオー ナーシップを持ってもらう啓蒙活動も実施
  18. Copyrights©3-shake Inc. All Rights Reserved. やらなかったこと ❏ 他事業部関連プロジェクトへの介入 スコープを最小限にするという点から他事業部に関することはフォルダー作成・該当プロジェクト配置のみを行い、中身の精緻化については実施 せず

    ❏ CI/CD 組織のスケールやシュリンクが現状頻繁に発生しない点と、 CI/CD構築に対する稼働コストパフォーマンスの観点からこのタイミングで実施するこ とは見送り ❏ 組織ポリシーの適用 GoogleCloudには組織ポリシーと呼ばれる組織レベルからリソース使用に関わる制約を適用する機能が存在 協議の結果、組織ポリシーを適用することが GoogleCloud検証環境利用における本質的な課題解決につながらないかつ、 あくまでも「検証環境」という位置付けのため、 利用制限・運用負荷は最小限にし、 検証の柔軟性が下がらない ことを考慮し実施せず
  19. Copyrights©3-shake Inc. All Rights Reserved. 活動を通して得られたこと 1. 一定レベルのクラウドガバナンス 権限管理、構成管理を適切に実施することで、クラウドガバナンスレベルの水準底上げ (メンバー各自のガバナンス意識に依存してしまう部分もあるが)

    2. 運用負荷低減 運用の自動化を推進することで定常的に行う作業の削減(トイル削減) 現在は月次でMTGを実施し、利用状況のモニタリング、運用事項のブラッシュアップへ向けたディ スカッションを実施 3. 容易なコストモニタリング・利用状況の可視化 事業部ごとやメンバーごとフォルダ構成としたことにより、 Billing Reportの標準的なフィルタリングの みでコストやリソース使用状況の取得可能
  20. Copyrights©3-shake Inc. All Rights Reserved. 活動を通して得られたこと クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナ ミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらしま す。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラク

    チャ、および宣言型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各種ログと連携することでさらにクラウドガバナンス向上が見込まれる • 堅牢な自動化により、頻繁かつ期待通りに最小限の労力で大きな変更が可能 ◦ 組織のスケール対して最小限の変更かつ運用フローと統合して環境のスケールが可能
  21. Copyrights©3-shake Inc. All Rights Reserved. クラウドガバナンス強化(例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を特定し、リソース使用の有無を選択できる機能