コンテンツに移動
デベロッパー

使っていない Google Cloud プロジェクトの自動クリーンアップ

2022年11月30日
Google Cloud Japan Team

※この投稿は米国時間 2022 年 11 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。


プロジェクトの自動クリーンアップによって時間と金を節約するとともに、セキュリティ リスクを低減する

組織のクラウドへの依存度が高まるにつれ、クラウド プロジェクトの数も増えていきます。やがてプロジェクトが無秩序に増え、組織に数十、数百もの不要なプロジェクトが残されかねません。不要なプロジェクトは一括で削除できるとは言え、どのプロジェクトが不要なのかを判断するのは困難になります。プロジェクトを把握するために一つひとつ手作業で調べるとなると、この骨の折れるタスクのために貴重なリソースを無駄にすることになります。さらに悪いことに、不要なプロジェクトがリソースを消費することで、費用も温室効果ガス排出量も増えるだけでなく、セキュリティ リスクも高まります。

Remora の概要

Remora は、組織内の使用されていないプロジェクトの数を削減するためのサーバーレス ソリューションです。Renoma は放置プロジェクトの Recommender と連動して、使用されていないプロジェクトについてプロジェクト オーナーに通知し、通知をエスカレーションします。そして事前に決められた期間内に対応がなされない場合は、それらのプロジェクトを削除します。

仕組み

このソリューションの仕組みは単純明快です。放置プロジェクトの Recommender が組織内のプロジェクトの使用状況を分析して、放置されたプロジェクトの再利用あるいは削除について推奨事項を提示します。Remora ではこれらの推奨事項をさらに一歩進んだものにして、放置されたプロジェクトのオーナーを特定してから、そのオーナーにカスタマイズ可能なメール通知を送信するか、Jira チケットを割り当てられるようになっています。ユーザーは、通知を繰り返す頻度を事前定義し、初回以降の通知メールに CC として加える重要な連絡先(フォルダー オーナーなど)を指定できます。所定のプロジェクトについて 3 回メールが送信された後に、未使用のプロジェクトを存続させる有効期間(TTL)を設定し、TTL に達した時点で未使用のプロジェクトを削除できます。削除対象のプロジェクトには、Remora によって削除予定日のラベルが付けられます。
https://storage.googleapis.com/gweb-cloudblog-publish/images/image2_3_6u8bjxc.max-1800x1800.png
Remora の図
  1. Cloud Scheduler により、スケジュールされた頻度で実行される Cloud Workflows のワークフローが開始されます。

  2. Cloud Workflows のワークフローが Recommender API を使用して、組織内の放置されたプロジェクトに対するアクティブな、または申請された推奨事項をチェックします。

  3. 各推奨事項とそれぞれの推奨事項が処理された回数を格納する BigQuery テーブルがクエリされ、更新されます。

  4. Cloud Workflows のワークフローによって、必要なアクション(プロジェクトの削除ならびに通知すべき連絡先など)が決定されます。

  5. Cloud Workflows のワークフローが Pub/Sub トピックにメッセージをパブリッシュします。

  6. Pub/Sub サブスクリプションにより、メッセージが Cloud Functions の関数に push されます。

  7. Cloud Functions の関数は、指定された連絡先に通知するために、Jira または Sendgrid の認証情報を Secret Manager から取得します。

  8. Jira はチケット、Sendgrid はメールによって、放置されたプロジェクトについて連絡先に通知します。

  9. プロジェクトの連絡先は、放置されたプロジェクトに対する推奨事項を承認または拒否することによって対処できます。

  10. 推奨事項を適用または拒否すると、Recommender API でその状態が更新されます。

Remora のコア機能

組織ごとに固有の要件を満たせるよう、Remora にはカスタマイズに不可欠な次の機能が組み込まれています。

  • ドライラン モード: ドライラン モードはデフォルトで有効です。この場合、Remora はプロジェクトを削除できません。ソリューションでプロジェクトが削除されるようにするには、ドライラン モードを無効にする必要があります。

  • 複数の通知: 使用されていないプロジェクトのオーナーには、推奨事項に対処する機会が複数設けられます。Remora は実行されるたびにオーナーに通知します。この Remora の実行頻度(たとえば 1 週間に一度)は、Cloud Scheduler を使用して設定できます。

  • サマリー通知: 使用されていないプロジェクトを複数持っているプロジェクトのオーナーには、すべてのプロジェクトを記載した 1 通のメール通知が送信されます。

  • 通知のエスカレーション: 最初の通知は常に、プロジェクト オーナーに直接送信されます。それ以降の通知のエスカレーションのために、次の 2 つのメカニズムが実装されています。

    • 重要な連絡先: Remora は、プロジェクトに指定されたカテゴリの重要な連絡先に通知をエスカレーションします。ID がメールアドレスとは異なる場合、Remora に正しいエスカレーション先メールアドレスを通知するには、重要な連絡先を構成します。

    • フォルダ管理者または組織管理者: 重要な連絡先のカテゴリが指定されていない場合、Remora はプロジェクトの親フォルダーまたは組織のいずれか(リソース階層で親に相当する方)の管理者に通知をエスカレーションします。

  • 有効期間: 組織管理者は、使用されていないプロジェクトを組織内に残しておける日数を設定できます。Remora はプロジェクトに削除予定日のラベルを付け、指定された期間が過ぎ、通知が 3 回送信された後、プロジェクトを削除します。

  • 通知メカニズム: Remora は Sendgrid を使用してメール通知を送信するか、Jira チケットを作成します。

  • Google Cloud CLI または Terraform を使用したデプロイ: Remora は gcloud コマンドを使用して手動でデプロイすることも、Terraform モジュールとしてデプロイすることもできます。

総合的なソリューション

このソリューションは、以下のコンポーネントを組み合わせて構成されています。

放置プロジェクトの Recommender

放置プロジェクトの Recommender はプロジェクトの使用状況を分析して、使用されていないプロジェクトの削除についての推奨事項を提示します。一般的に、過去 30 日間に使用量が少なく、かつ、過去 180 日間に OAuth トークンが使用されていない場合は、プロジェクトを削除するよう推奨されます。この場合、Remora は放置されたプロジェクトに削除対象としてラベルを付けます。

Google Cloud Workflows と Scheduler 

Workflows は、Google Cloud のさまざまなサービスと API を接続してパイプラインおよびプロセス自動化を作成するために使用できるサービスです。Workflows のワークフローを構成するには、一連のステップを実行順にリストした YAML ファイルまたは JSON ファイルを使用します。このソリューションでは、Workflows のワークフローを使用して推奨事項を追跡する BigQuery の初期データセットとテーブルを作成し、Recommender API から最新の放置されたプロジェクトに関する推奨事項を取得するとともに、Pub/Sub を呼び出して、特定された放置プロジェクトのオーナーに対する通知プロセスを開始します。ワークフローは、Cloud Scheduler と Google Cloud の crontab-as-a-service ソリューションを使って構成されたスケジュールに沿って実行されます。Cloud Scheduler では、放置されたプロジェクトに関する推奨事項の Remora による処理頻度を構成します。

Cloud Functions

Cloud Functions は Google Cloud の Function-as-a-Service です。このサービスを使用すると、サーバーを管理することなく軽量の関数を実行できます。Cloud Functions の関数は、Cloud Storage、Pub/Sub、Firebase、または HTTP リクエストのイベントからのトリガーを受けプログラマティックに実行できます。このソリューションでは、Pub/Sub を介して Cloud Functions の関数をトリガーし、Sendgrid を使用したメールで、または Jira の課題を介しプロジェクト オーナーへの通知を行います。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_1_4VUFlyC.max-1000x1000.png
放置された GCP プロジェクトに関する Jira の課題

Terraform

Remora のデプロイを単純化および効率化するために、個々の Google Cloud CLI コマンドをまとめて 1 つの Terraform モジュールにコンパイルし、Remora を実行するために必要なすべてのリソースがこのモジュールによって作成されるようにしています。Terraform モジュールとしての Remora を指定の Google Cloud プロジェクトにデプロイして、わずかな数の変数だけでカスタマイズできます。

Terraform モジュールは Workflows、Cloud Scheduler、Cloud Functions の作成と構成を処理し、プロジェクトに対するカスタムロールと組織の IAM ポリシーを割り当てたサービス アカウントを作成します。Cloud Functions で使用するコードは、このモジュールに含まれており、アーカイブ ファイルとして Cloud Storage バケットにアップロードされます。

こちらのリポジトリ内にあるドキュメントで、詳細な使用方法に関する情報使用例をご確認ください。簡単な一例として、モジュールの内容を以下に示します。
読み込んでいます...

上記の例では、毎週日曜日の夜に放置プロジェクトの Recommender から推奨事項を取得し、放置されたプロジェクトのオーナーに Sendgrid を使ってメールを送信します。

具体的な作業

組織で Remora をデプロイするとすぐに、Workflows が指定された間隔で Recommender API に対してクエリを実行するようになります。Sendgrid を通知手段として構成すると、プロジェクト オーナーには次のようなメールが送信されます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image3_1_Z00VIHe.max-1000x1000.png
放置された GCP プロジェクトに関する最初の Sendgrid 通知

放置されたプロジェクトのオーナーは、通知を受けた後に 2 つのオプションのいずれかを選択できます。一つはプロジェクトをすぐに削除すること、もう一つは推奨事項を却下して、Recommender API によってそのプロジェクトが再び通知されないようにすることです。

最初の通知に対して対応しなければ、次の通知は指定のカテゴリの重要な連絡先にも送信されます。重要な連絡先カテゴリが設定されていない場合、代わりに、リソース階層の次のオーナー(フォルダまたは組織レベルのオーナー)に通知が送信されます。2 番目のメッセージは次のような内容です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image4_1_LBThMS3.max-1100x1100.png
放置された GCP プロジェクトに関する 2 番目の Sendgrid 通知

3 回目の通知が送信されても対応が取られず、TTL に達した場合、プロジェクトは自動的にシャットダウンされて、Remora が実行された時点で削除される対象としてマークされます。プロジェクトを手動でシャットダウンする場合と同じように、誤って削除された場合に備え、30 日間はプロジェクトを復元できます

Active Assist のレコメンデーション API のインテリジェンス、Workflows、Cloud Functions を活用する Remora によって、放置されたプロジェクトをプルーニングすれば、頻繁な手動監査でオーバーヘッドを生じさせることなくセキュリティ リスクの解決、温室効果ガス排出量の削減、クラウド インフラストラクチャに伴う費用の節約が可能になります。さらに、Remora はオープンソース プロジェクトであるため、組織のニーズに合わせてソリューションを調整するために、Workflows や Cloud Functions で使われているロジックを確認してカスタマイズすることもできます。Remora を導入するには、GitHub のプロジェクト リポジトリを確認し、提供されている Terraform モジュールを使用して Remora をデプロイしてください。Active Assist の詳細については、Active Assist とそのインテリジェントな機能について紹介している、こちらの YouTube プレイリストをご覧ください。

- プロダクト マネージャー Bakh Inamov

デベロッパーリレーションズ エンジニア Roger Martinez
投稿先