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 の原則とツールをよく理解する
  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 プロバイダを使用している場合は、ID プロバイダのコールバック URL を Looker（Google Cloud コア）URL に更新して、新しい Looker（Google Cloud コア）インスタンスへの認証を許可する必要があります。
    • 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>）。
  4. 移行専用の新しいサービス アカウントを作成します（例: <export-service-account>）。

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

  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> ではない）に付与します:
  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（オリジナル）インスタンスに固有のファイアウォールまたはトンネルを介してデータベースにアクセスしている場合、ファイアウォールまたはトンネルの再構成が必要になることがあります。各接続をテストし、必要に応じて再確立してください。

Git リポジトリの接続

インスタンスがベアメタル Git リポジトリを使用している場合は、変更せずに動作します（コピーはされますが共有はされません）。ただし、インスタンスがリモート リポジトリに接続する場合は、データベース接続と同様に、これらの接続を確認して再度有効にする必要があります。

その他のネットワーク構成

Looker インスタンスは、受信と送信の両方を含む他のタイプのネットワーク接続を持つことができます（たとえば、プライベート IP、アクションハブ、Marketplace、メールなど）。これらのネットワーク接続も確認する必要があります。

Looker（Google Cloud コア）インスタンスにアクセスするための URL

Looker（Google Cloud コア）インスタンスには、ランダムに割り当てられたプライマリ URL が用意されています。特定の URL を介してインスタンスにアクセスする必要がある場合は、カスタム ドメインを構成できます。

スケジュールとアラート

Looker（オリジナル）インスタンスと Looker（Google Cloud コア）インスタンスの両方が同時にアクティブの場合、重複するスケジュール済みアクションとアラートが生成され、接続されたデータベースにアクセスする重複するバックグラウンド オペレーションが実行されることがあります。これらのアクティビティは、できるだけ早くいずれかのインスタンスで無効にする必要があります。

メンテナンスの時間枠

Looker（オリジナル）とは異なり、Looker（Google Cloud コア）にはメンテナンス ポリシーを指定できます。

エリート システム アクティビティ

エリート システム アクティビティ データは移行の一環としてコピーされません。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 カスタマーケアでチケットを開いて問題を解決する必要があります。このオペレーションでお客様が直接確認できる診断は比較的少数です。

次のステップ