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

SREがGoogle Cloud検証環境をCloud Nativeな視点で、 頑張りすぎずでも...

SREがGoogle Cloud検証環境をCloud Nativeな視点で、 頑張りすぎずでも良い感じに整えた話

Jagu'e'r - CloudNative分科会 2023/12/13の登壇内容です。

Annosuke Yokoo

December 13, 2023
Tweet

More Decks by Annosuke Yokoo

Other Decks in Technology

Transcript

  1.  Sreake SRE(SRE総合支援サービス) 技術戦略から設計、構築、運用までワンストップ支援する 技術支援サービス 技術戦略 コンサルティング システム 設計 構築 /

    実装 支援 アセスメント (パフォーマンス / セキュリティ) 運用支援 Micro Service , Multi Cloud や k8sをはじめとしたCloud Native な先進的技術及び大規模なサービス運用 に強みを持つエンジニアによる技術支援 ベンダー的な役割ではなく「お客様の チームメンバー」という立ち位置で最新技術の提案から運用支援までをトータ ルご支援
  2. 活動背景 / 課題 3-shakeでは、社員なら誰でも GoogleCloud の各種サービスを自由に試せる 検証環境用アカウント (以降:test.orgと表記)が存在 【課題:例】 •

    誰でもプロジェクトを作成可能(プロジェクトの課金紐付けは要情シス申請)なので、アカウント統制が皆無の カオス状態 ◦ 未使用のプロジェクト・リソースがそのままになってしまっていることも多々ある • コスト管理についてモニタリングの仕組みが出来ていないので、それなりの高額請求になってしまっているこ ともしばしば • セキュリティ的に問題が無い使われ方か把握できていない • 新入社員が把握できていない / 離職者のアセットや権限が放置されている
  3. 活動目標と意義を明確化 🏁 Sreakeのエンジニアが安心して快適に検証環境を利用できるように、管理・改善活動を行う • 「Sreakeのエンジニア」 ◦ 最小限のスコープとするため他事業部は考慮しない • 「安心して」 ◦

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

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

    roles/viewer ◦ roles/resourcemanager.folderCreater ◦ roles/resourcemanager.projectCreater • 新規プロジェクト作成時 ◦ roles/owner Adminグループ • 運用に携わる GoogleCloud検証環境整備チーム • 継承Role ◦ roles/resourcemanager.folderAdmin
  7. Terraform構成管理 • main.tf ◦ module呼び出し / resource作成処理 • modules/managed-folders ◦

    第2階層フォルダリソースを管理する ◦ フォルダに対するRoleを管理 • modules/personal-sandbox-folder ◦ 第3階層以下(sandboxフォルダ配下)のフォルダ リソースを管理 • variables.tf ◦ 次スライドで後述
  8. その他 ❏ 既存プロジェクトの要否確認 📃 構成に基づき、元々全 33プロジェクトあったうちの 18プロジェクトを削除 プロジェクトを削除する際には、アナウンスの頭出しからメンバーへのヒアリング、整理実行までの期間をおよそ 10日前後設け、活動周知や合意 形成の期間を十分に確保しながら実施

    (このあたりはハレーションも起きる可能性があるので結構気を使ったポイント) ❏ 啓蒙活動 📣 そもそもの活動背景から認知してもらうため、ドキュメントとしてナレッジの展開や事業部メンバーが集う会での周知活動など、メンバー各人にオー ナーシップを持ってもらう啓蒙活動も実施
  9. やらなかったこと ❏ 他事業部関連プロジェクトへの介入 スコープを最小限にするという点から他事業部に関することはフォルダー作成・該当プロジェクト配置のみを行い、中身の精緻化については実施 せず ❏ CI/CD 組織のスケールやシュリンクが現状頻繁に発生しない点と、 CI/CD構築に対する稼働コストパフォーマンスの観点からこのタイミングで実施するこ とは見送り

    ❏ 組織ポリシーの適用 GoogleCloudには組織ポリシーと呼ばれる組織レベルからリソース使用に関わる制約を適用する機能が存在 • 適用した方が良さそうな制約を選定 ◦ iam.allowedPolicyMemberDomains ◦ constraints/gcp.resourceLocations ◦ constraints/compute.vmExternalIpAccess ◦ etc.. • 制約に対する脅威とリスクの洗い出し • チーム内にて協議 協議の結果、組織ポリシーを適用することが GoogleCloud検証環境利用における本質的な課題解決につながらないかつ、 あくまでも「検証環境」という位置付けのため、 利用制限・運用負荷は最小限にし、 検証の柔軟性が下がらない ことを考慮し実施せず
  10. 活動を通して得られたこと クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナ ミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらしま す。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラク チャ、および宣言型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各種ログと連携することでさらにクラウドガバナンス向上が見込まれる • 堅牢な自動化により、頻繁かつ期待通りに最小限の労力で大きな変更が可能 ◦ 組織のスケール対して最小限の変更かつ運用フローと統合して環境のスケールが可能
  11. クラウドガバナンス強化(例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を特定し、リソース使用の有無を選択できる機能
  12. 参考資料 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