Looker のクラスタ化

このチュートリアルでは、クラスタ化された Looker 構成を作成する推奨方法について説明します。

概要

Looker アプリケーションは、単一ノードまたはクラスタ化を実行できます。

  • 単一ノードの Looker アプリケーション（デフォルト構成）には、単一サーバーで実行される Looker アプリケーションを構成するすべてのサービスがある。
  • クラスタ化された Looker 構成は、より複雑な構成で、通常はデータベース サーバー、ロードバランサ、Looker アプリケーションを実行する複数のサーバーを含みます。クラスタ化 Looker アプリケーションの各ノードは、1 つの Looker インスタンスを実行するサーバーです。

組織が Looker をクラスタとして実行する主な理由は 2 つあります。

  • 負荷分散
  • 可用性とフェイルオーバーの向上

スケーリングの問題によっては、クラスタ化された Looker で解決できない場合があります。たとえば、少数の大規模なクエリでシステムメモリが消費されている場合、Looker プロセスで使用可能なメモリを増やすことが唯一の解決策となります。

代替のロード バランシング

Looker を負荷分散する前に、Looker を実行する単一のサーバーのメモリと CPU 数を増やすことを検討してください。Looker は、メモリと CPU 使用率の詳細なパフォーマンス モニタリングを設定し、Looker サーバーのサイズがそのワークロードに対して適切な大きさになるようにすることをおすすめします。

大規模なクエリの場合、パフォーマンス向上のためにより多くのメモリが必要になります。クラスタリングは、多くのユーザーが小規模なクエリを実行する場合のパフォーマンス向上につながります。

最大 50 人のユーザーが Looker を軽度に使用する構成では、Looker は、大規模 AWS EC2 インスタンス（M4.large: 8 GB の RAM、2 個の CPU コア）と同等の単一サーバーを実行することをおすすめします。より多くのユーザーがいる構成や、アクティブなパワーユーザーが数多くいる構成では、CPU が急増したか、アプリケーションの速度低下が検出されたかを確認できます。Looker をより大規模なサーバーに移動するか、クラスタ化された Looker 構成を実行します。

可用性/フェイルオーバーの向上

クラスタ環境で Looker を実行することで、サービス停止時のダウンタイムを軽減できます。Looker API をコア ビジネス システムで使用する場合や、Looker がお客様向けのプロダクトに組み込まれている場合、高可用性は特に重要です。

クラスタ化された Looker 構成では、プロキシ サーバーまたはロードバランサが、いずれかのノードがダウンしていると判断したときにトラフィックを再ルーティングします。Looker は、クラスタから離脱したノード、およびクラスタに参加したノードを自動的に処理します。

必須コンポーネント

クラスタ化された Looker 構成には次のコンポーネントが必要です。

  • MySQL アプリケーション データベース
  • Looker ノード（Looker Java プロセスを実行しているサーバー）
  • ロードバランサ
  • 共有ファイル システム
  • Looker アプリケーションの JAR ファイルの適切なバージョン

次の図は、コンポーネント間のやり取りを示しています。

MySQL アプリケーション データベース

Looker はアプリケーション データベース（多くの場合「内部データベース」と呼ばれます）を使用してアプリケーション データを保持します。Looker を単一ノード アプリケーションとして実行している場合、通常はインメモリ HyperSQL データベースを使用します。

クラスタ化された Looker 構成では、各ノードの Looker インスタンスは共有トランザクション データベース（共有アプリケーションまたは内部データベース）を指す必要があります。クラスタ化 Looker のアプリケーション データベースのサポートは次のとおりです。

  • クラスタ化された Looker インスタンスのアプリケーション データベースでは、MySQL のみがサポートされています。Amazon Aurora と MariaDB はサポートされていません。
  • MySQL バージョン 5.7 以降と 8.0 以降がサポートされています。
  • Galera などのクラスター化データベースはサポートされていません。

パフォーマンスと冗長性を向上させるために、リードレプリカ データベースを使用することをおすすめします。リードレプリカ データベースは MySQL データベースである必要はありません。

Looker は、そのデータベースのメンテナンスとバックアップを管理しません。ただし、データベースはほぼすべての Looker アプリケーション構成データをホストしているため、少なくとも 1 日に 1 回、高可用性データベースとしてプロビジョニングし、バックアップを行う必要があります。

Looker ノード

各ノードは、Looker Java プロセスが実行されているサーバーです。Looker クラスタ内のサーバーは、相互に接続でき、Looker アプリケーション データベースにアクセスできる必要があります。デフォルトのポートについては、このページのノードが通信するためのポートを開くをご覧ください。

ロードバランサ

ロード リクエストやリダイレクト リクエストを使用可能なノードに分散するには、トラフィックを各 Looker ノードに転送するロードバランサまたはプロキシ サーバー（NGINX や AWS ELB など）が必要です。ロードバランサがヘルスチェックを処理します。ノードに障害が発生した場合、残りの正常なノードにトラフィックを再ルーティングするようにロードバランサを構成する必要があります。

ロードバランサを選択して構成するときは、レイヤ 4 としてのみ動作するように構成できることを確認してください。Amazon Classic ELB はその一例です。さらに、クエリが強制終了されないように、ロードバランサには長いタイムアウト（3,600 秒）が必要です。

共有ファイル システム

POSIX 準拠の共有ファイル システム（NFS、AWS EFS、Gluster、BeeGFS、Lustre など）を使用する必要があります。Looker は、共有ファイル システムをクラスタ内のすべてのノードが使用するさまざまな情報のリポジトリとして使用します。

Looker Marketplace からアプリケーションやツールをインストールするには、共有（ネットワーク）ファイル システムを使用する必要があります。

Looker アプリケーション（JAR 実行可能）

Looker 3.56 以降の Looker アプリケーション JAR ファイルを使用する必要があります。

Looker 6.18 以降、Looker JAR ファイルは 2 つの JAR ファイル（Looker コア JAR ファイルと Looker 依存関係の JAR ファイル）に分割されました。Looker 6.18 以降をインストールまたは更新する場合は、必ず両方の JAR ファイルをダウンロードしてください。

このページのノードで Looker を起動するで説明されているように、Looker ではクラスタ内の各ノードが同じ Looker リリースとパッチ バージョンを実行することを強くおすすめします。

クラスタの設定

次のタスクを行う必要があります。

  1. Looker をインストールする
  2. MySQL アプリケーション データベースを設定する
  3. 共有ファイル システムをセットアップする
  4. SSH 認証鍵リポジトリを共有する（状況に応じて）
  5. ノードが通信するためのポートを開く
  6. ノードで Looker を起動する

Looker のインストール

Looker アプリケーション JAR ファイルとお客様がホストするインストール手順のドキュメント ページの手順に沿って、各ノードに Looker がインストールされていることを確認します。

MySQL アプリケーション データベースの設定

クラスタ化された Looker 構成の場合、アプリケーション データベースは MySQL データベースである必要があります。アプリケーション データベースに HyperSQL を使用している既存のクラスタ化されていない Looker インスタンスがある場合は、HyperSQL データから新しい共有 MySQL アプリケーション データベースにアプリケーション データを移行する必要があります。

必ず Looker ディレクトリをバックアップしてください。移行プロセスは、HyperSQL データベースから MySQL データベースにのみ移行でき、その逆はできません。

Looker をバックアップしてから HyperSQL から MySQL へアプリケーション データベースを移行する方法については、MySQL への移行に関するドキュメント ページをご覧ください。

共有ファイル システムの設定

共有ファイル システムに属するのは、特定のファイル形式（モデルファイル、デプロイキー、プラグイン、場合によってはアプリケーション マニフェスト ファイル）のみです。共有ファイル システムを設定するには:

  1. 共有ファイル システムを保存するサーバーで、Looker ユーザー アカウントにsuできる別のアカウントにアクセスできることを確認します。
  2. 共有ファイル システムのサーバーで、Looker ユーザー アカウントにログインします。
  3. Looker を現在実行中の場合は、Looker の構成をシャットダウンします。
  4. 以前に inotify Linux スクリプトを使用してクラスタリングしていた場合は、それらのスクリプトを停止し、cron から削除して、削除してください。
  5. ネットワーク共有を作成し、クラスタ内の各ノードにマウントします。各ノードに自動マウントされるように構成され、Looker ユーザーがそのノードに読み書きできることを確認します。次の例で、ネットワーク共有の名前は /mnt/looker-share です。

  6. 1 つのノードで、デプロイキー、プラグイン、モデルファイルを格納する looker/models ディレクトリと looker/models-user-* ディレクトリをネットワーク共有に移動します。例:

    mv looker/models /mnt/looker-share/
mv looker/models-user-* /mnt/looker-share/

  7. ノードごとに、--shared-storage-dir 設定を LOOKERARGS に追加します。次の例に示すように、ネットワーク共有を指定します。

    --shared-storage-dir /mnt/looker-share

    更新による影響を受けないように、LOOKERARGS を $HOME/looker/lookerstart.cfg に追加する必要があります。このファイルに LOOKERARGS 表示されない場合は、誰かが $HOME/looker/looker シェル スクリプトに直接追加している可能性があります。

    クラスタ内の各ノードは一意の /log ディレクトリ、または少なくとも一意のログファイルに書き込む必要があります。

SSH 認証鍵リポジトリの共有

  • 既存の Looker 構成から共有ファイル システム クラスタを作成する。
  • Looker 4.6 以前で作成されたプロジェクトがある。

次の手順では、Looker ユーザーの $HOME/.ssh directory を変更する必要があります。その結果、構成にエラーがあると、ログインや修正が難しくなる可能性があります。以下の手順を行う前に、Looker ユーザー アカウントに su できる別のアカウントへのアクセス権があることを確認してください。

共有する SSH 認証鍵リポジトリを設定します。

  1. 共有ファイル サーバーで、ssh-share という名前のディレクトリを作成します。例: /mnt/looker-share/ssh-share。

    ssh-share ディレクトリが Looker ユーザーによって所有されており、権限が 700 であることを確認します。また、ssh-share ディレクトリの上のディレクトリ（/mnt や /mnt/looker-share など）がワールド書き込み可能、グループ書き込み可能でないことを確認します。

  2. 1 つのノードで、$HOME/.ssh の内容を新しい ssh-share ディレクトリにコピーします。例:

    cp $HOME/.ssh/* /mnt/looker-share/ssh-share

  3. ノードごとに、既存の SSH ファイルのバックアップを作成し、ssh-share ディレクトリのシンボリック リンクを作成します。例:

    cd $HOME
mv .ssh .ssh_bak
ln -s /mnt/looker-share/ssh-share .ssh

    この手順は、すべてのノードで行ってください。

ノードが通信するためのポートを開く

クラスタ化された Looker ノードは、自己署名証明書と、アプリケーション データベースのシークレットのローテーションに基づく追加の認証スキームを使用して、HTTPS 経由で相互に通信を行います。

クラスタノード間で開く必要があるデフォルトのポートは、1551 ～ 61616 です。これらのポートは、ここに示す起動フラグを使用して構成できます。クラスタホスト間のトラフィックのみを許可するように、これらのポートへのネットワーク アクセスを制限することを強くおすすめします。

ノードで Looker を起動する

必要な起動フラグを指定して、各ノードでサーバーを再起動します。

クラスタ内の各ノードは同じリリースとパッチ バージョンを実行する必要があります。

使用可能な起動フラグ

次の表に、クラスタの起動や参加に必要なフラグを含む、使用可能な起動フラグを示します。

フラグ 要否 値 目的
--clustered ○ このノードがクラスタモードで実行されていることを示すフラグを追加します。
-H または --hostname ○ 10.10.10.10 他のノードがこのノードに接続するために使用するホスト名（ノードの IP アドレスやシステムのホスト名など）。クラスタ内の他のすべてのノードのホスト名とは異なるものにする必要があります。
-n × 1551 ノード間通信用のポート。デフォルト値は 1551 です。すべてのノードで、ノード間通信に同じポート番号を使用する必要があります。
-q × 61616 クラスタ全体のイベントをキューに入れるポート。デフォルトは 61616 です。
-d ○ /path/to/looker-db.yml Looker アプリケーション データベースの認証情報を保持するファイルのパス。
--shared-storage-dir ○ /path/to/mounted/shared/storage このオプションは、このページで前述した、looker/model ディレクトリと looker/models-user-* ディレクトリを保持する共有ディレクトリの設定を指す必要があります。

--clustered 起動フラグに値を含めないでください。

LOOKERARGS の例とデータベース認証情報の指定

Looker 起動フラグを、Looker JAR ファイルと同じディレクトリにある lookerstart.cfg ファイルに配置します。

たとえば、次のような情報が Looker に届きます。

  • looker-db.yml という名前のファイルをデータベース認証情報に使用するには、次のようにします。
  • ノードがクラスタ化されていること、かつ
  • クラスタの他のノードが IP アドレス 10.10.10.10 でこのホストと通信する

この場合、

LOOKERARGS="-d looker-db.yml --clustered -H 10.10.10.10"

ノードに正しい IP アドレスを指定してください。

looker-db.yml ファイルには、次のようなデータベース認証情報が含まれます。

host: your.db.hostname.com
username: db_user
database: looker
dialect: mysql
port: 3306
password: secretPassword

また、MySQL データベースに SSL 接続が必要な場合は、looker-db.yml ファイルに次のものも必要です。

ssl: true

認証情報をファイルに保存する際は、セキュリティに関するベスト プラクティスに沿って行ってください。理想的には、Looker アプリケーションを実行する Linux アカウントが所有する looker-db.yml ファイルの権限を 600 に設定します。このファイルは Git リポジトリにチェックインしないでください。

構成をディスク上の looker-db.yml ファイルに保存しない場合は、環境変数 LOOKER_DB を構成して、looker-db.yml ファイルの各行の Key-Value のリストを格納できます。例:

export LOOKER_DB="dialect=mysql&host=localhost&username=root&password=&database=looker&port=3306"

Git SSH デプロイキーを見つける

Looker による Git SSH デプロイキーの保存先は、プロジェクトが作成されたリリースによって異なります。

  • Looker 4.8 より前に作成されたプロジェクトの場合、デプロイ鍵はサーバーのネイティブ SSH ディレクトリ ~/.ssh に保存されます。
  • Looker 4.8 以降で作成されたプロジェクトの場合、デプロイキーは Looker が管理するディレクトリ ~/looker/deploy_keys/PROJECT_NAME に保存されます。

Looker クラスタの変更

Looker クラスタを作成した後、他のクラスタ化ノードを変更せずにノードを追加または削除できます。

クラスタを新しい Looker リリースに更新する

更新には、以前のバージョンの Looker と互換性のない Looker の内部データベースに対するスキーマ変更が含まれる場合があります。Looker を更新する方法は 2 つあります。

より安全な方式

  1. アプリケーション データベースのバックアップを作成します。
  2. クラスタのすべてのノードを停止します。
  3. 各サーバーの JAR ファイルを置き換えます。
  4. 各ノードを 1 つずつ開始します。

迅速な方法

この方法ではダウンタイムが短縮されますが、レプリカの作成からプロキシ サーバーと新しいノードの指定の間の変更は失われます。たとえば、移行中にユーザーがユーザーを追加したり、Look を作成したりすると、それらの変更が新しいアプリケーション データベースに反映されないことがあります。

更新をより迅速に、ただし完了度の低い方法を使用して更新するには:

  1. Looker のアプリケーション データベースのレプリカを作成します。
  2. レプリカを指す新しいクラスタを起動します。
  3. プロキシ サーバーまたはロードバランサを新しいノードにポイントします。その後、古いノードを停止できます。