このチュートリアルでは、セルフホスト型インスタンス向けにクラスタ化された Looker 構成を作成するおすすめの方法について説明します。
概要
Looker のセルフホスト型デプロイは、単一ノードまたはクラスタ化で実行できます。
- 単一ノードの Looker アプリケーション（デフォルト構成）では、Looker アプリケーションを構成するすべてのサービスが 1 つのサーバー上で実行されています。
- クラスタ化された Looker 構成は、より複雑な構成であり、通常、データベース サーバー、ロードバランサ、Looker アプリケーションを実行する複数のサーバーが関係します。クラスタ化された Looker アプリケーションの各ノードは、単一の Looker インスタンスを実行するサーバーです。
Looker をクラスタとして実行する理由には、主に次の 2 つがあります。
- 負荷分散
- 可用性の改善とフェイルオーバー
スケーリングの問題によっては、クラスタ化された Looker でソリューションを提供できないこともあります。たとえば、少数の大きなクエリがシステムメモリを消費している場合、唯一の解決策は Looker プロセスで使用可能なメモリを増やすことです。
ロード バランシングの代替手段
Looker をロード バランシングする前に、Looker を実行する 1 台のサーバーのメモリと、場合によっては CPU 数を増やすことを検討してください。Looker では、Looker サーバーがワークロードに対して適切なサイズであることを確認するために、メモリと CPU の使用率の詳細なパフォーマンス モニタリングを設定することを推奨しています。
クエリのサイズが大きいほど、良いパフォーマンスを得るためにより多くのメモリを必要とします。クラスタ化を行うと、多くのユーザーが小規模なクエリを実行する際のパフォーマンスを向上できます。
最大 50 人のユーザーで Looker を軽度に使用する構成の場合は、大規模な AWS EC2 インスタンス（M4.large: 8 GB の RAM、2 つの CPU コア）に相当するサーバーを 1 つ実行することをおすすめします。より多くのユーザーがいる構成の場合や、アクティブなパワーユーザー数が多い構成の場合は、CPU が急増するかどうかや、ユーザーがアプリケーションの遅さに気づくかを監視します。その場合は、Looker をより大きなサーバーに移行するか、クラスタ化された Looker 構成を実行します。
可用性 / フェイルオーバーの改善
クラスタ化された環境で Looker を実行することによって、システム停止時のダウンタイムを緩和できます。Looker API が中核となるビジネス システムで使用されている場合や、Looker が顧客向けプロダクトに組み込まれている場合は、高可用性が特に重要です。
クラスタ化された Looker 構成では、1 つのノードが停止していると判断した場合、プロキシ サーバーかロードバランサがトラフィックをルート変更します。Looker では、クラスタを離れるノードと結合するノードが自動的に処理されます。
必須のコンポーネント
クラスタ化された Looker 構成には、次のコンポーネントが必要です。
- MySQL アプリケーション データベース
- Looker ノード（Looker Java プロセスを実行するサーバー）
- ロードバランサ
- 共有ファイル システム
- 適切なバージョンの Looker アプリケーション JAR ファイル
次の図では、コンポーネント間の相互のやり取りを示します。大まかには、ロードバランサはクラスタ化された Looker ノード間でネットワーク トラフィックを分配します。各ノードは、共有 MySQL アプリケーション データベース、共有ストレージ ディレクトリ、各 LookML プロジェクトの Git サーバーと通信します。
MySQL アプリケーション データベース
Looker はアプリケーション データベース（多くの場合、内部データベースとも呼ばれます）を使用してアプリケーション データを保持します。Looker が単一ノードのアプリケーションとして動作する場合は、通常、メモリ内 HyperSQL データベースを使用します。
クラスタ化された Looker 構成では、各ノードの Looker インスタンスが共有トランザクション データベース（共有アプリケーションまたは内部データベース）を指している必要があります。クラスタ化された Looker 用アプリケーション データベースのサポート状況は次の通りです。
- クラスタ化された Looker インスタンス用アプリケーション データベースには、MySQL のみがサポートされています。Amazon Aurora と MariaDB はサポートされていません。
- MySQL バージョン 5.7 以降と 8.0 以降がサポートされています。
- クラスタ化データベース（Galera など）はサポートされていません。
Looker では、データベースのメンテナンスとバックアップを管理しません。ただし、このデータベースはほぼすべての Looker アプリケーション構成データをホストしているため、高可用性データベースとしてプロビジョニングし、少なくとも毎日バックアップする必要があります。
Looker ノード
各ノードは、Looker Java プロセスが動作するサーバーです。Looker クラスタ内のサーバーは、互いにアクセスでき、さらに Looker アプリケーション データベースにアクセスできる必要があります。デフォルトのポートは、このページのノードが通信するポートを開くに記載します。
ロードバランサ
負荷のバランスを確保する、または利用可能なノードにリクエストをリダイレクトするには、ロードバランサやプロキシ サーバー（NGINX や AWS ELB など）が各 Looker ノードにトラフィックを誘導する必要があります。ロードバランサは、ヘルスチェックを処理します。ノードに障害が発生した場合、ロードバランサが残りの正常なノードにトラフィックをルート変更するように構成する必要があります。
ロードバランサを選択して構成する場合は、レイヤ 4 のみで動作するように構成できることを確認します。そのようなもには、たとえば、Amazon Classic ELB があります。さらに、ロードバランサでは、クエリが強制終了されないように長いタイムアウト（3,600 秒）を設定する必要があります。
共有ファイル システム
POSIX 準拠の共有ファイル システム（NFS、AWS EFS、Gluster、BeeGFS、Lustre など）を使用している必要があります。Looker は、共有ファイル システムを、クラスタ内のすべてのノードが使用するさまざまな情報のリポジトリとして使用します。
Looker アプリケーション（JAR 実行ファイル）
Looker 3.56 以降の Looker アプリケーション JAR ファイルを使用する必要があります。
このページの ノードで Looker を起動するで説明するように、クラスタ内の各ノードでは同じ Looker リリースとパッチ バージョンを実行することを強くおすすめします。
クラスタの設定
次のタスクは必須です。
- Looker のインストール
- MySQL アプリケーション データベースの設定
- 共有ファイル システムの設定
- SSH 認証鍵リポジトリの共有（状況に応じて）
- ノードが通信するためのポートを開く
- ノードで Looker を起動する
Looker のインストール
Looker アプリケーションの JAR ファイルと、お客様がホストするインストール手順のページに記載の内容を使用して、Looker が各ノードにインストールされていることを確認します。
MySQL アプリケーション データベースの設定
クラスタ化された Looker 構成の場合、アプリケーション データベースは、MySQL データベースでなければなりません。アプリケーション データベースに HyperSQL を使用する既存のクラスタ化されていない Looker インスタンスがある場合は、アプリケーション データを、HyperSQL データから新しい共有 MySQL アプリケーション データベースに移行する必要があります。
Looker をバックアップし、アプリケーション データベースを HyperSQL から MySQL に移行する方法については、MySQL への移行ドキュメントをご覧ください。
共有ファイル システムの設定
共有ファイル システムには、特定のファイルタイプ（モデルファイル、デプロイキー、プラグイン、場合によってはアプリケーション マニフェスト ファイル）のみ保持されます。共有ファイル システムを設定するには:
- 共有ファイル システムを保存するサーバーで、Looker ユーザー アカウントに
suできる別のアカウントにアクセスできることを確認します。 - 共有ファイル システムのサーバーで、Looker ユーザー アカウントにログインします。
- Looker が動作中の場合は、Looker の構成をシャットダウンします。
- 以前に Linux スクリプトを使用してクラスタリングしている場合は、これらのスクリプトを停止し、cron から削除して、スクリプトを削除します。
- ネットワーク共有を作成し、クラスタ内の各ノードでマウントします。各ノードで自動マウントされるように構成し、Looker ユーザーが読み書きできることを確認します。次の例におけるネットワーク共有名は
/mnt/looker-shareです。 1 つのノードでデプロイキーをコピーし、プラグインとモデルファイルを格納する
looker/modelsディレクトリとlooker/models-user-*ディレクトリをネットワーク共有に移動します。次に例を示します。mv looker/models /mnt/looker-share/ mv looker/models-user-* /mnt/looker-share/ノードごとに、
--shared-storage-dir設定をLOOKERARGSに追加します。次の例に示すように、ネットワーク共有を指定します。--shared-storage-dir /mnt/looker-share設定が更新の影響を受けないように、
LOOKERARGSを$HOME/looker/lookerstart.cfgに追加する必要があります。そのファイルにLOOKERARGSが記載されていない場合は、$HOME/looker/lookerシェル スクリプトに直接追加されている可能性があります。クラスタ内の各ノードは、一意の
/logディレクトリ（少なくとも 1 つの一意のログファイル）に書き込む必要があります。
SSH 認証鍵リポジトリの共有
- 既存の Looker 構成から共有ファイル システム クラスタを作成します。
- Looker 4.6 以前で作成されたプロジェクトがあります。
SSH 認証鍵リポジトリを共有するように設定します。
共有ファイル サーバーに、
ssh-shareという名前のディレクトリを作成します。例:/mnt/looker-share/ssh-share。ssh-shareディレクトリが Looker ユーザーによって所有され、権限が 700 であることを確認します。また、ssh-shareディレクトリの上のディレクトリ（/mntや/mnt/looker-shareなど）がワールド書き込み可能でも、グループ書き込み可能でもないことも確認します。1 つのノードで、
$HOME/.sshの内容を新しいssh-shareディレクトリにコピーします。例:cp $HOME/.ssh/* /mnt/looker-share/ssh-shareノードごとに、既存の 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-* ディレクトリを保持する共有ディレクトリの設定を指す必要があります。 |
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"
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-db.yml ファイルに保存しない場合は、looker-db.yml ファイルの各行のキーと値のリストを含めるように環境変数 LOOKER_DB を構成します。次に例を示します。
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 つの方法があります。
より安全な方法
- アプリケーション データベースのバックアップを作成すします。
- クラスタのすべてのノードを停止します。
- 各サーバーの JAR ファイルを置き換えます。
- 各ノードを 1 つずつ起動します。
より高速な方法
このように速いが不完全な方法を使用して更新するには:
- Looker のアプリケーション データベースのレプリカを作成します。
- レプリカを参照する新しいクラスタを起動します。
- 後で古いノードを停止できる新しいノードを、プロキシ サーバーやロードバランサが指すようにします。