Tweet
Tweet

Slide 1

Slide 1 text

Copyrights©3-shake Inc. All Rights Reserved. Google Cloudの管理を楽にする、 トイルを減らすクラウドガバナンス 2024/2/11 Jagu'e'r Meetup in Okinawa- @866mfs

Slide 2

Slide 2 text

Copyrights©3-shake Inc. All Rights Reserved. 2 現在は、GoogleCloudやk8sを使用したエンプラ企業へのSRE支援を行って います。 Cloud Native分科会 / Observability-SRE分科会 中心に参加中 学生時代の修学旅行は関西だったので、沖縄には人生で一度もまだ行けて いません... ですが、心は「はいさーい！」と叫んでいます！ Annosuke Yokoo (@866mfs) 株式会社スリーシェイク Sreake 事業部 Who am I

Slide 3

Slide 3 text

Copyrights©3-shake Inc. All Rights Reserved. About 3-shake

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Copyrights©3-shake Inc. All Rights Reserved. バーチャルチーム結成 Google Cloud 検証環境 整備 プロジェ クトを 立 ち 上 げ よ う そ う だ 、

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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 ● 疎結合である ● 復元力がある ● 管理しやすい ● 可観測である ● 堅牢な自動化により、頻繁かつ期待通りに最小限の労力で大きな変更が可能

Slide 17

Slide 17 text

Copyrights©3-shake Inc. All Rights Reserved. 現状把握（Before）

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Copyrights©3-shake Inc. All Rights Reserved. フォルダ構成設計（After）

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Copyrights©3-shake Inc. All Rights Reserved. フォルダ構成設計 ❏ 第3階層以下 ❏ 「社員番号_name」という命名規則の元、個人フォルダを作成 ❏ management ❏ コストアラートやその他管理に必要なリソースが存在 ❏ terraform ❏ stateファイルを管理するGCSが存在

Slide 22

Slide 22 text

Copyrights©3-shake Inc. All Rights Reserved. 権限設計 - リソース階層構造

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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 ○ 次スライドで後述

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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各種ログと連携することでさらにクラウドガバナンス向上が見込まれる ● 堅牢な自動化により、頻繁かつ期待通りに最小限の労力で大きな変更が可能 ○ 組織のスケール対して最小限の変更かつ運用フローと統合して環境のスケールが可能

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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を特定し、リソース使用の有無を選択できる機能

Slide 37

Slide 37 text

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