Looker（オリジナル）から Looker（Google Cloud コア）へのセルフサービス移行

このドキュメントでは、既存の Looker インスタンスを Looker（オリジナル）環境から Looker（Google Cloud コア）に移行する技術的な手順について説明します。

Looker（Google Cloud コア）は、Google Cloud Platform と緊密に統合されているデプロイ環境です。Looker（Google Cloud コア）は Google Cloud インフラストラクチャでホストされ、Google Cloud コンソールから直接管理できます。Google Cloud の他の多くのプロダクト、サービス、機能とは緊密に統合されています。

準備

1. 次のドキュメントで、Google Cloud の原則とツールをご確認ください。
• Google Cloud の概要
• IAM の概要
• Looker（Google Cloud コア）の概要
• Cloud Billing の概要
2. 移行と Looker（オリジナル）インスタンスが対象かどうかについては、アカウント担当者にお問い合わせください。インスタンスが移行の対象であり、既存の Looker（オリジナル）契約を Looker（Google Cloud コア）に対応するようにアップグレードしている場合は、このドキュメントの手順に沿ってインスタンスを移行できます。

3. 移行の準備に必要な権限を取得するには、Looker（Google Cloud コア）インスタンスが存在する Google Cloud プロジェクトに対して次の IAM ロールを付与するよう管理者に依頼してください。

   • Looker（Google Cloud コア）インスタンスを作成する（Looker 管理者（roles/looker.admin））。
   • Google Cloud プロジェクトで IAM ロールを割り当てる（プロジェクト IAM 管理者（roles/resourcemanager.projectIamAdmin））。
   • Cloud Storage バケットを作成する（ストレージ管理者（roles/storage.admin））。

   ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

   必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

4. 移行の準備として Looker（オリジナル）インスタンスを管理するには、そのインスタンスで 管理者の Looker ロールが必要です。

5. 新しい「空の」Looker（Google Cloud コア）インスタンスを作成します。

   新しい Looker（Google Cloud コア）インスタンスで適切なエディション、ネットワーク接続タイプ（パブリック IP またはプライベート IP）を選択し、その他の構成属性（CMEK、VPC-SC）を必ず選択し、必要な機能が備わっていることを確認します。Looker（Google Cloud コア）の一部の機能は、選択したエディションによって異なり、また選択したネットワーク タイプによっても異なります。

   インスタンスは「空」のままにします。モデルファイル、ユーザー、接続、Explore、ダッシュボード、フォルダなどのデータを入力しないでください。インポートのステップで、設定やコンテンツはすべて消去され、移行元のデータに置き換えられます。

   ただし、Google Cloud コンソールで指定する Looker（Google Cloud コア）の構成属性、またはインスタンス作成時にのみ指定できる構成属性は、移行プロセス中に上書きされません。

概要

大まかに、移行は次の手順から構成されます。

1. Looker（オリジナル）インスタンスが移行の準備ができていることを確認する
2. Looker インスタンス（オリジナル）からデータをエクスポートします。
3. 新しい「空の」Looker（Google Cloud コア）インスタンスにデータをインポートします。
4. Looker（Google Cloud コア）インスタンスの設定を完了します。
5. Looker（オリジナル）インスタンスを廃止します。

以降のセクションでは、これらの各ステップについて詳しく説明します。

Looker（オリジナル）インスタンスが移行の準備ができていることを確認する

移行の対象となるには、Looker（オリジナル）インスタンスが次の前提条件を満たしている必要があります。

• Looker（オリジナル）インスタンスは Google によって管理され（つまり、お客様がホストしていない）、Google Cloud または Amazon Web Services でホストされている必要があります。

• Looker（オリジナル）インスタンスは、現在の Looker（Google Cloud コア）バージョンの月次リリース以内のバージョンを使用している必要があります。Looker（Google Cloud コア）の現在のバージョンを確認するには、Looker リリースノートで最新のデプロイに関するお知らせをご覧ください。

また、移行前に次の作業を行います。

• Looker（オリジナル）と Looker（Google Cloud コア）には、機能の違いがいくつかあります。これらの違いを確認して、Looker（Google Cloud コア）の機能が継続的なニーズを満たしていることを確認します。

• 移行では、すべての本番環境モード プロジェクトと、そこに含まれるモデルファイルがコピーされますが、個々のユーザーに属する開発モード プロジェクトはコピーされません。Development Mode ファイルが確実に移行されるようにするには、移行を開始する前に、すべての Development Mode プロジェクト内のすべてのファイルを Git リポジトリに commit する必要があります。

• Looker（Google Cloud コア）では、Google OAuth、SAML、OpenID Connect の認証方法のみがサポートされます。

  • Looker（オリジナル）インスタンスで別の認証方法（メールとパスワード、LDAP など）を使用している場合は、すべてのユーザーを Looker（Google Cloud コア）でサポートされている認証方法に変換する必要があります。
  • Looker（オリジナル）インスタンスがすでに Google OAuth を使用している場合、すべてのユーザー レコードが移行されますが、Looker（Google Cloud コア）インスタンスのプロジェクトのユーザー用に IAM 権限を手動で作成する必要があります。
  • Looker（オリジナル）インスタンスで SAML が使用されている場合は、[SAML 認証] 管理パネルページの [次を使用してユーザーを統合] 設定を Google または OIDC に設定して　SAML 認証のテスト時のエラーを回避します。
  • Looker（オリジナル）インスタンスで OIDC が使用されている場合は、[OpenID Connect 認証] 管理パネルページの [ユーザーの統合] 設定を Google または SAML に設定して、OpenID Connect 認証のテスト時のエラーを回避します。
  • 外部 ID プロバイダを使用している場合は、新しい Looker（Google Cloud コア）インスタンスへの認証を許可するために、ID プロバイダのコールバック URL を Looker（Google Cloud コア）URL に更新する必要があります。
  • Looker（Google Cloud コア）インスタンスで認証方法として SAML または OpenID Connect を使用する場合は、Looker（Google Cloud コア）のバックアップ認証方法として機能する Google OAuth も設定することをおすすめします。
  • Looker（Google Cloud コア）インスタンスでカスタム ドメインを使用する場合は、カスタム ドメインが有効になるまで、インスタンスに SAML または OpenID Connect を設定しないでください。

• 移行中、2 つの Looker インスタンス（1 つの Looker インスタンス（オリジナル）と 1 つの Looker（Google Cloud コア））が一定期間並行して実行されます。実行される自動アクティビティ（アラート、スケジュール設定されたデータ配信、バックエンド データベースにアクセスするバックグラウンド アクティビティなど）が重複する可能性があります。アクティビティの重複を避けるには、Looker（オリジナル）インスタンスまたは Looker（Google Cloud Core）インスタンスで自動アラートとスケジュールを削除します。

Looker（オリジナル）インスタンスからデータをエクスポートする

Looker（オリジナル）インスタンスからデータをエクスポートするには、次の 2 つのステップが必要です。

1. 移行データを保存する場所を作成します。
2. エクスポートを開始します。

移行データを保存する場所を作成する

次のすべてのオペレーションは、Looker（Google Cloud コア）インスタンスを作成した同じ Google Cloud プロジェクトで実行します。

1. 新しい Cloud Storage バケットを作成します（例: <bucket-name>）。
   • このバケットは、移行データの保存に使用されます。
   • バケットを作成するのドキュメント ページの手順に沿って操作します。
   • <bucket-name> は Google Cloud 全体で一意である必要があります。バケット名の前にプロジェクト ID などの一意の識別子を追加することをおすすめします。
2. Cloud Storage バケット内のフォルダの名前を決定します（例: <folder-name>）。この時点ではフォルダは作成しません。フォルダ名はエクスポート リクエスト中に指定します。エクスポート プロセス中に自動的に作成されます。
3. Cloud KMS でキーリングと鍵を作成します（例: <kms_keyring_id> と <kms-key-id>）。
   • この鍵は、移行データの暗号化に使用されます。これは KMS 鍵であるため、Looker（オリジナルの）管理者パネルの エクスポート ページに鍵自体ではなく、鍵名のみを開示する必要があります。
   • ドキュメント ページのキーリングを作成すると鍵を作成するの手順に沿って操作します。
4. 移行専用の新しいサービス アカウントを作成します（例: <export-service-account>）。
   • これは、Looker サービス アカウントと同じサービス アカウントではありません。
   • サービス アカウントを作成するドキュメント ページの手順に沿って操作します。

5. <export-service-account> に次の 2 つの特定の IAM ロールを付与します。

   • Cloud Storage バケットに対する Storage Object Creator
   • KMS 鍵の Cloud KMS CryptoKey Encrypter
   • IAM 権限の使用（Cloud Storage）と IAM を使用したアクセス制御（KMS）のドキュメント ページの手順に沿って操作します。

6. <export-service-account> に関連付けられたサービス アカウント キーを作成し、JSON キーファイルをダウンロードします。

   • サービス アカウント キーの作成と削除のドキュメント ページの手順に沿って操作します。

エクスポートをリクエストする

インスタンスの移行の準備ができていることを確認したら、「空の」Looker（Google Cloud コア）インスタンスを作成し、移行データを保存する場所を作成して次の情報を　Looker（オリジナル）インスタンスの [管理] パネルの書き出しページに入力します。

• 前に作成した Cloud Storage バケットの名前
• Cloud Storage フォルダ名 - この名前のフォルダがエクスポート中に自動的に作成されます。エクスポートが完了すると、作成した Cloud Storage バケット内のこのフォルダ内のタイムスタンプ付きサブフォルダにエクスポート ファイルが表示されます。
• KMS 鍵の名前。
• サービス アカウント キーを含む JSON テキスト。

[エクスポート] ページで情報を入力したら、[エクスポートをリクエスト] をクリックしてエクスポートを開始します。

エクスポート処理には数分から数時間かかります。エクスポートが完了すると、Cloud Storage バケットとフォルダに（人間が読み取れない形式の）複数のエクスポート ファイルが表示されます。これらのファイルは、次のインポート ステップで入力されます。

新しい「空の」Looker（Google Cloud コア）インスタンスにデータをインポートする

インスタンス データがエクスポートされたら、Looker（Google Cloud コア）インスタンスにインポートできます。

Cloud Storage から Looker（Google Cloud コア）インスタンスへのデータのインポートページの手順に従って、エクスポート ファイルが配置されているバケットとフォルダに対してコマンドを指定します。

要約すると、次のようになります。

1. バケットと KMS 鍵にアクセスするための次のロールをLooker サービス アカウント（<export-service-account> ではない）に付与します:
   • Cloud Storage バケットに対する Storage Object User
   • KMS 鍵の Cloud KMS CryptoKey Decrypter
2. Google Cloud コンソールまたは gcloud CLI からインポートをトリガーします。

インポート オペレーションには数分から数時間かかります。完了すると、Looker（Google Cloud コア）インスタンスが再起動され、すべてのデータが移行されます。

Looker（Google Cloud コア）インスタンスの設定を完了する

この時点で、Looker 管理者はインスタンス URL に移動してインスタンスにログインし、設定を完了できます。

移行プロセスでは、Looker（オリジナル）インスタンスの構成を可能な限りコピーします。ただし、一部のアイテムは移行できないか、Looker（Google Cloud コア）では異なって機能するため、調整が必要です。

特に注意が必要な項目には次のようなものがあります。

全般設定（Looker の [管理] パネル）	全般設定（および**管理**パネルの他の設定）のほとんどは、自動的にコピーされません。これは、Looker（Google Cloud コア）では異なっているか、または同じ形式で存在しないためです。選択した Looker（Google Cloud コア）構成のコンテキストの中で、すべての設定を慎重に確認して構成する必要があります。Looker の設定（Google Cloud コア）の詳細については、Looker からの Looker（Google Cloud コア）インスタンスの管理と Google Cloud コンソールからの Looker（Google Cloud コア）インスタンスを管理のドキュメントをご覧ください。
ユーザー	Looker（Google Cloud コア）では、Google OAuth、SAML、OpenID Connect の認証方法のみがサポートされます。 Looker（オリジナル）インスタンスも Google OAuth 用に構成されている場合、ユーザー レコードとその属性はコピーされます（両方のインスタンスで同じ Google ID とメールアドレスに関連付けられている場合）。プロジェクト IAM 管理者は、インスタンスが配置されている Google Cloud プロジェクトに対して Looker 管理者または Looker インスタンス ユーザーの IAM ロールを各ユーザーに付与する必要があります。 Looker（オリジナル）インスタンスが SAML または OpenID Connect 用に構成されている場合は、認証方法の [次を使用してユーザーを統合] フィールドに、Looker（Google Cloud コア）でサポートされている認証方法のみが表示されていることを確認します。 Looker（オリジナル）インスタンスのユーザーが Looker（Google Cloud コア）でサポートされていないメカニズム（LDAP、メール/パスワードなど）で認証されている場合は、それらのユーザー アカウントを再作成して、サポートされている認証方法に変換する必要があります。
データベース接続	Looker（Google Cloud コア）は、Looker（オリジナル）とは若干異なるデータベース言語のセットをサポートしています。データベース接続のすべての構成プロパティ（該当する場合は接続文字列やパスワードなど）がコピーされます。ただし、Looker（Google Cloud コア）のネットワーク トポロジが異なると、データベース接続がすぐに機能しないことがあります。たとえば、データベースにアクセスする際に、Looker（オリジナル）インスタンスに固有のファイアウォールまたはトンネルを使用する場合は、ファイアウォールまたはトンネルを再構成する必要があります。各接続をテストし、必要に応じて再確立する必要があります。
OAuth を使用したデータベース接続	Looker（オリジナル）から Looker（Google Cloud コア）への移行では、個々のユーザーの BigQuery または Snowflake へのデータベース接続の OAuth アクセス トークンまたは更新トークンは保持されません。移行後、Looker（Google Cloud コア）ユーザーは、OAuth データベース接続を参照する Explore またはダッシュボードを表示するときに、OAuth を再認証するよう求められます。[アカウント] ページに移動し、[OAuth 接続認証情報] の見出しで各データベースの [ログイン] を選択して、データベースの認証を再実行することもできます。1 人のユーザーが所有し、OAuth 接続を参照する自動スケジュールやアラートは、そのユーザーが OAuth 認証情報でログインするまで機能しません。
Git リポジトリの接続	インスタンスがベアメタル Git リポジトリを使用している場合は、変更せずに動作します（コピーはされますが共有はされません）。ただし、インスタンスがリモート リポジトリに接続する場合は、データベース接続と同様に、これらの接続を確認して再度有効にする必要があります。
その他のネットワークの構成	Looker インスタンスは、受信と送信の両方を含む他のタイプのネットワーク接続を持つことができます（たとえば、プライベート IP、アクションハブ、Marketplace、メールなど）。これらのネットワーク接続も確認する必要があります。
Looker（Google Cloud コア）インスタンスにアクセスするための URL	Looker（Google Cloud コア）インスタンスには、ランダムに割り当てられるプライマリ URL が付属しています。特定の URL からインスタンスにアクセスする必要がある場合は、カスタム ドメインを構成できます。
スケジュールとアラート	Looker（オリジナル）インスタンスと Looker（Google Cloud コア）インスタンスの両方が同時にアクティブの場合、重複するスケジュール済みアクションとアラートが生成され、接続されたデータベースにアクセスする重複するバックグラウンド オペレーションが実行されることがあります。これらのアクティビティは、できるだけ早くいずれかのインスタンスで無効にする必要があります。 1 人のユーザーが所有し、そのユーザーの個々の OAuth 接続を参照する自動スケジュールやアラートは、そのユーザーが OAuth 認証情報でログインするまで機能しなくなります。
メンテナンスの時間枠	Looker（オリジナル）とは異なり、Looker（Google Cloud コア）にはメンテナンス ポリシーを指定できます。
エリート システム アクティビティ	Elite System Activity のデータは、移行の一部としてコピーされません。Looker（Google Cloud コア）インスタンスは新しい履歴で開始されます。
カスタム ドメイン	Looker（Google Cloud コア）インスタンスのカスタム ドメインを作成できます。SSL 証明書のデプロイを確実に行うには、DNS レコードを設定する必要があります。また、カスタム ドメインを有効にして認証方法を設定したら、認証クライアントのコールバック URL をカスタム ドメインに更新してください。looker.com ドメインを使用して Looker（Google Cloud コア）のカスタム ドメインを作成することはできません。 Looker（オリジナル）インスタンスのカスタム URL を使用して Looker（Google Cloud コア）インスタンスのカスタム ドメインを作成する場合は、移行の完了後と Looker（Google Cloud コア）インスタンスが使用できることを確認した後にカスタム ドメインを設定する必要があります。カスタム ドメインを有効にすると、ユーザーがインスタンス URL にアクセスしたときに、Looker（オリジナル）インスタンスではなく Looker（Google Cloud コア）インスタンスが表示されます。 インスタンスの使用準備が整い、DNS レコードが更新され、カスタム ドメインが有効になるまで、Looker（Google Cloud コア）インスタンスに SAML または OpenID Connect を設定しないでください。
ブックマーク	Looker（オリジナル）インスタンスで カスタム URL（looker.com ドメインを使用しない）を使用している場合、Looker（オリジナル）インスタンスと同じ URL を使用して Looker（Google Cloud コア）インスタンスのカスタム ドメインを作成すると、この移行プロセスでユーザーのブックマークが保持されます。 カスタム ドメインが有効になると、https://www.yourcustomdomain.com/dashboard/123 などの Looker（オリジナル）コンテンツへのブックマークは、Looker（Google Cloud コア）インスタンス内のコンテンツを指すようになります。（注: Looker（Google Cloud コア）の Enterprise および Embed 版では、URL に数値のコンテンツ ID ではなく英数字のコンテンツ スラッグが使用されますが、コンテンツ ID があるブックマークは引き続き同じコンテンツに正しくリダイレクトされます）。 このプロセスは、ドメイン looker.com を使用する Looker（オリジナル）の URL では使用できません。

このリストはすべてを網羅したものではありません。移行が完了したと見なす前に、インスタンスの最も重要なすべての要素をテストします。

移行が完了し、別のエクスポートが必要ないことを確認したら、前に作成した <export-service-account> を削除できます。これにより、共有された JSON キーが無効になります。

Looker（オリジナル）インスタンスを廃止する

移行された Looker（Google Cloud コア）インスタンスが正常に機能したら、ユーザーにインスタンスの URL を送信し、インスタンスへのアクセスを開始して Looker（オリジナル）インスタンスへのアクセスを停止するようユーザーに指示できます。

トラブルシューティング

次のセクションでは、インポートまたはエクスポート中に発生する問題の解決に役立つ情報を提供します。

エクスポート中の問題

Looker（オリジナル）データのエクスポートに問題がある場合は、管理者パネル の [Export] ページに [ERROR] のステータスが表示されます。[ERROR] ステータスをクリックすると、エラー メッセージが表示されます。

一般的なエラーの原因は次のとおりです。

• Cloud Storage バケット、KMS 鍵、または <export-service-account> が無効である。
• <export-service-account> に必要な権限がありません。

エクスポート リクエストを送信する前に、これらのオブジェクトのステータスを確認することをおすすめします。

インポート中の問題

インポート オペレーションが 4 時間後までに完了しない場合（ソース インスタンスが非常に大きい場合はそれ以上）、またはエラーが発生した場合は、Cloud カスタマーケアにチケットを登録して問題を解決する必要があります。このオペレーションでお客様に直接表示される診断情報は比較的少ないです。

次のステップ

• 管理者設定 - エクスポート
• Looker（Google Cloud コア）をデータベースに接続する
• Looker（Google Cloud コア）インスタンスを設定する
• Looker（Google Cloud コア）インスタンスへのユーザー アクセスを管理する
• Google Cloud コンソールから Looker（Google Cloud コア）インスタンスを管理する
• Looker から Looker（Google Cloud コア）インスタンスを管理する