MoTLab -GO Inc. Engineering Blog-MoTLab -GO Inc. Engineering Blog-

GCPプロジェクトを組織間で移行した時の話

GCP
June 07, 2022

Mobility Technologies(MoT)では、MoTの前身の時代から、Googleが提供しているクラウドインフラサービス群であるGoogle Cloud Platform(GCP)を利用していました。MoTが新しくスタートするにあたり、以前まで、各々の会社のGoogle Cloudの組織内で作成し運用していたGCPプロジェクトを、MoT名義のGoogle Cloudの組織内で管理するため、必要なGCPプロジェクトの精査を行ったのち、組織間の移行作業を実施しました。 　今回は、この時に実施した組織間でGCPプロジェクトを移行した事例を紹介できればと思います。

はじめに

　SREグループ・ヒロチカです。Mobility Technologies(MoT)では、サービスのクラウドインフラの設計から構築・運用までを担当しています。

　MoTは、JapanTaxi株式会社と株式会社ディー・エヌ・エーのMOV/DRIVE CHART事業などが統合しスタートした会社ですが、MoTになる以前より、各サービス提供のインフラ基盤の一つとしてGoogle Cloud Platform(GCP)を利用しており、一部には本番のサービスでも利用しているリソースがあるGCPプロジェクトも複数保持していました。

　今後、MoTとしてサービス提供を行うにあたり、以前より利用しているGCPプロジェクトを、あらたにスタートさせたMoTのGoogle Cloudの組織の管理下に移行し、MoTとして管理していく必要が出てきました。 　今回は、その際に行った、Google Cloudの組織間の移行についての事例を紹介できればと思います。

組織間の移行作業概要

　Google Cloudのリソースは、組織・フォルダ・プロジェクト・リソース群からなる階層構造をとっています。基本的には利用したいリソースをプロジェクトという単位でまとめて管理し、そのGCPプロジェクト群を、階層の一番上に位置する「組織」でまとめて管理します。この「組織」は、基本的に会社単位で保持することとなります。

　今回は、以前の「組織」の配下にあったGCPプロジェクトを、MoTの「組織」の配下に移行する作業の事例となります。

An image from Notion

　また、このGCPプロジェクトの組織間の移行手順については、公式にドキュメントが存在します。今回この手順に則って作業を行いました。

  • 公式ドキュメント(プロジェクト移行)

https://cloud.google.com/resource-manager/docs/project-migration?hl=ja

移行作業に必要な権限の管理

　組織間で、GCPプロジェクトを移行するには、作業を行うIAMユーザに対して、下記の権限が必要です。

  • 移行するプロジェクトにて

　　プロジェクト IAM 管理者（roles/resourcemanager.projectIamAdmin）

  • 移行元プロジェクトの親リソース（現在所属している組織レベルでの権限）にて

　　プロジェクト移転者（roles/resourcemanager.projectMover）

  • 移行先プロジェクトの親リソース（移行したい先の組織レベルでの権限）にて

　　プロジェクト作成者（roles/resourcemanager.projectCreator）

　付与するべき権限については、移行するGCPプロジェクト自体に付与する権限と、GCPプロジェクトの上位階層にあたる、組織レベルで付与する権限があります。組織レベルの権限は、組織内にある各GCPプロジェクトに継承される形でも付与されます。

　今回の作業では、複数のプロジェクトを移行するため、組織レベルでプロジェクトIAM管理者の権限を付与しました。

　また、必要な権限レベルを見ていただければわかる通り、組織間の移行を行う場合には、移行元・移行先の両方組織に、組織レベルでの権限が付与された強い権限をもつ作業用ユーザが必要となってきます。

　今回の作業において、移行元組織、移行先組織とも、一時的でも他組織に属しているユーザに、組織レベルの権限を付与するのは難しいという組織内での権限ポリシーがあったため、回避策として、移行にのみ利用する中間組織を一時的に準備し、移行元と中間組織、中間組織と移行先、それぞれの必要な権限を持った作業用ユーザを移行元・移行先それぞれの組織にて作成し、中間組織を仲介する形で、GCPプロジェクトの移行を実施しました。

移管前の確認事項

移行前に、確認しておいたほうがよい箇所をあげてみます。

1. GCPプロジェクト内の利用状況のデータ

　すべてのクラウドリソースは組織ごとに管理されているため、組織間の移行を行った時には、以前の組織に所属していた時の利用状況のデータは参照できなくなってしまいます。弊社では、Big QueryのINFORMATION_SCHEMA ジョブビューにある、移行前までのジョブ履歴データが無くなったという問い合わせがありました。 　必要であれば、移行前に、モニタリング系などの利用状況関連のデータを取得しておくことをおすすめします。

2. サポートケース

　利用状況のデータ同様、以前の組織で問い合わせていたサポートケースも移行後に参照できなくなってしまいます。必要であれば、以前の組織の管理者に問い合わせる、もしくは、移行前に問い合わせの内容を、テキストなどに残しておくことをおすすめします。

3. 請求先アカウント

　GCPプロジェクトを組織から別の組織に移行しても、課金内容自体には影響はありません。元々、紐づけている請求先アカウントに請求されるままですが、GCPの設定によっては、新しい組織側で管理している請求先アカウントへの移行が必要になる場合があります。

　多くの場合で、各組織別に、請求先アカウントのルールがあるかと思いますので、組織間の移行の前に、請求先アカウントをどう管理するかは整理し、事前に変更するなどの対応をしておく方が良いかと思います。

移行時の作業

　必要な権限や環境が整い、移行前の確認が終わったら、いよいよ移行作業です。 移行作業は、マネジメントコンソール上でも可能ですが、複数のプロジェクトを移行することを鑑みて、gcloudコマンドにて実施します。

  • gcloudコマンドの確認をし、作業ユーザを確認
gcloud config list # 作業想定のユーザであることを確認
  • プロジェクトを移行しあう両方の組織で、相手の組織に対してのImport許可とExport許可
    • 移行元と移行先の組織両方で実施するため、許可する組織のIDには注意
    • ImportとExportの設定を両方とも行うのは、切り戻しに備えるため
    • 今回の移行の場合は、MoTの組織と中間組織との間でこの許可設定を実施
# Import
gcloud beta resource-manager org-policies allow constraints/resourcemanager.allowedImportSources --organization 移行先組織ID under:organizations/移行元組織ID
# Export
gcloud beta resource-manager org-policies allow constraints/resourcemanager.allowedExportDestinations --organization 移行先組織ID under:organizations/移行元組織ID
  • GCPプロジェクト 移行コマンド
gcloud beta projects move 移行したいプロジェクトのID --organization 移行先組織ID

　これで、GCPプロジェクトの移行は完了です。移行コマンドの実行時間は、MoTの場合、数秒程度でした。

　プロジェクト内で付与されている権限は、基本、以前からの内容が引き継がれますが、元の組織から継承されていた権限については剥奪され、新しい組織からの権限が新たに継承される形になります。

　その間、MoTではリソースにサービス影響は確認されませんでしたが、万が一のことを考えて、サービス影響の可能性や社内アナウンス等は行う方が良いかと思います。

おわりに

　MoTでのGCPプロジェクトの組織間の移行の事例を紹介いたしました。移行にあたっては、事前に移行先でのGCPプロジェクトのIAM権限管理のルールを定めておくと、移行後の運用もスムーズに進むかと思います。

　今回のような、GCPプロジェクトの組織間の移行作業は、通常めったに発生するような作業ではないため参考事例も少ないかと思います。この記事が、誰かの参考となっていれば、幸いです。

We're Hiring!

📢
Mobility Technologies ではともに働くエンジニアを募集しています。

興味のある方は 採用ページ も見ていただけると嬉しいです。

Twitter @mot_techtalk のフォローもよろしくお願いします！