セルフホスト型アーキテクチャ ソリューション: コンポーネント チュートリアル

このページでは、Looker アーキテクチャの特定のコンポーネントに関する一般的なプラクティスを紹介し、デプロイ内でそれらを構成する方法について説明します。

Looker には、サーバーのホスティング、アドホックのワークロードとスケジュールされたワークロードの両方の処理、反復モデル開発の追跡など、さまざまな依存関係があります。このページでは、このような依存関係をコンポーネントと呼んでいます。各コンポーネントの詳細については、次のセクションをご覧ください。

• ホストの設定
• JVM の設定
• Looker の起動オプション
• 内部（バックエンド）データベース
• Git サービス
• ネットワーク

ホストの設定

OS とディストリビューション

Looker は、最も一般的な Linux バージョンである RedHat、SUSE、Debian/Ubuntu で正常に動作します。通常、特定の環境で実行するように設計され、最適化されたこのディストリビューションの派生物は問題ありません。たとえば、Linux の Google Cloud ディストリビューションまたは AWS ディストリビューションは Looker と互換性があります。Debian/Ubuntu は Looker コミュニティで最もよく使用されている Linux であり、Looker サポートで最もよく知られているバージョンです。Debian/Ubuntu や、Debian/Ubuntu から派生した特定のクラウド プロバイダのオペレーティング システムを使用するのが最も簡単です。

Looker は Java 仮想マシン（JVM）で実行されます。ディストリビューションを選択する際は、OpenJDK 11 のバージョンが最新かどうかを検討してください。古い Linux ディストリビューションでは Looker を実行できますが、Looker で特定の機能に必要な Java のバージョンとライブラリが最新である必要があります。JVM に推奨するすべての Looker ライブラリとバージョンが含まれていない場合、Looker は正常に機能しません。Looker には、Java HotSpot 1.8 アップデート 161 以降または Java OpenJDK 11.0.12 以降が必要です。

CPU とメモリ

4x16（4 個の CPU と 16 GB の RAM）ノードは、小規模なチームで使用される開発システムや基本的なテスト用 Looker インスタンスに十分です。しかし、本番環境では、通常はこれでは不十分です。経験上、16x64 ノード（16 CPU と 64 GB RAM）が、価格とパフォーマンスのバランスが良好です。64 GB を超える RAM を使用すると、ガベージ コレクション イベントがシングル スレッドで実行され、他のすべてのスレッドの実行が停止するため、パフォーマンスに影響する可能性があります。

ディスク ストレージ

通常、本番環境システムでは 100 GB のディスク容量で十分です。

クラスタに関する考慮事項

Looker は Java JVM で動作し、Java では 64 GB を超えるメモリの管理が難しい場合があります。原則として、より大きな容量が必要な場合は、ノードサイズを 16x64 よりも大きくするのではなく、16x64 のノードをクラスタに追加する必要があります。可用性を高めるために、クラスタ化アーキテクチャを使用することもできます。

クラスタでは、Looker ノードはファイル システムの特定の部分を共有する必要があります。共有データには次のものが含まれます。

• LookML モデル
• デベロッパーの LookML モデル
• Git サーバーの接続

ファイル システムは共有され、多数の Git リポジトリをホストしているため、同時実行アクセスとファイルロックの処理は非常に重要です。ファイル システムは POSIX 準拠である必要があります。ネットワーク ファイル システム（NFS）は Linux ですぐに利用できる機能として認識されています。追加の Linux インスタンスを作成して、ディスクを共有するように NFS を構成する必要があります。デフォルトの NFS は、単一障害点となる可能性があるため、フェイルオーバーの設定または高可用性の設定を検討してください。

Looker メタデータも一元化する必要があるため、内部データベースを MySQL に移行する必要があります。これは、MySQL サービスまたは専用の MySQL デプロイのいずれかになります。このページの内部（バックエンド）データベースのセクションで詳しく説明します。

JVM の設定

Looker JVM 設定は、Looker 起動スクリプト内で定義されます。更新後、変更を反映するには Looker を再起動する必要があります。デフォルトの設定は次のとおりです。

java \
  -XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
  -Xms$JAVAMEM -Xmx$JAVAMEM \
  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
  -Xloggc:/tmp/gc.log ${JAVAARGS} \
  -jar looker.jar start ${LOOKERARGS}

リソース

リソース設定は、Looker の起動スクリプトで定義されます。

JAVAMEM="2300m"
METAMEM="800m"

JVM のメモリ割り当てでは、Looker が実行されているオペレーティング システムのオーバーヘッドを考慮する必要があります。一般的な経験則として、JVM には合計メモリの最大 60% を割り当てることができますが、マシンのサイズによっては注意点があります。合計メモリが 必要最低限の 8 GB のマシンでは、Java に 4 ～ 5 GB、Meta に 800 MB を割り当てることをおすすめします。マシンが大きいほど、オペレーティング システムに割り当てられるメモリの割合は小さくなります。たとえば、合計メモリが 60 GB のマシンの場合、Java に 36 GB、Meta に 1 GB を割り当てることをおすすめします。通常、Java のメモリ割り当てはマシンの合計メモリに応じてスケーリングしますが、Meta では 1 GB で十分であることに留意することが重要です。

また、Looker はレンダリングのために Chromium などの他のプロセスとシステム リソースを共有するため、Java に割り当てるメモリ量は、想定されるレンダリング負荷とマシンのサイズを考慮して選択する必要があります。レンダリング負荷が低いと予想される場合は、Java に合計メモリのより大きな割合を割り当てることができます。たとえば、合計メモリが 60 GB のマシンの場合、Java には一般的に推奨される 60% よりも高い 46 GB を安全に割り当てることができます。デプロイごとにふさわしい正確なリソース割り当ては異なるため、60% をベースラインとして使用し、使用状況に応じて調整します。

ガベージ コレクション

Looker では、Java バージョンで利用可能な最新のガベージ コレクタを優先して使用します。デフォルトでは、ガベージ コレクションのタイムアウトは 2 秒ですが、起動構成で次のオプションを編集することで変更できます。

-XX:MaxGCPauseMillis=2000

複数のコアを備えた大規模なマシンでは、ガベージ コレクションのタイムアウトが短縮される可能性があります。

ログ

デフォルトでは、Looker のガベージ コレクション ログは /tmp/gc.log に保存されます。これを変更するには、起動構成で次のオプションを編集します。

-Xloggc:/tmp/gc.log

JMX

Looker の管理では、リソーシングの絞り込みに役立つモニタリングが必要になる場合があります。JVM メモリ使用量をモニタリングするには、JMX を使用することをおすすめします。

Looker の起動オプション

起動オプションは lookerstart.cfg というファイルに保存されます。このファイルは、Looker を起動するシェル スクリプトで取得されます。

スレッドプール

マルチスレッド アプリケーションである Looker には、複数のスレッドプールがあります。これらのスレッドプールは、コアのウェブサーバーから、スケジューリング、レンダリング、外部データベース接続などの特殊なサブサービスまで多岐にわたります。ビジネス ワークフローによっては、これらのプールをデフォルト構成から変更する必要がある場合があります。特に、セルフホスト型インフラストラクチャ アーキテクチャ パターンとベスト プラクティスに記載されているクラスタ トポロジに関する特別な考慮事項があります。

高スケジューリング スループット オプション

すべてのスケジューラ以外のノードでは、lookerstart.cfg の LOOKERARGS 環境変数に --scheduler-threads=0 を追加します。スケジューラ スレッドがないと、これらのノードでスケジュールされたジョブは実行されません。

すべての専用スケジューラ ノードでは、lookerstart.cfg の LOOKERARGS 環境変数に --scheduler-threads=<n> を追加します。Looker では、デフォルトで 10 個のスケジューラ スレッドが開始しますが、<n> に増やすことができます。<n> 個のスケジューラ スレッドを使用して、各ノードは <n> 個の同時スケジュール ジョブを実行できます。通常は、<n> を CPU 数の 2 倍未満に保つことをおすすめします。推奨される最大ホストは、16 個の CPU と 64 GB のメモリを備えたホストであるため、スケジューラ スレッドの上限は 32 未満である必要があります。

高レンダリング スループット オプション

すべてのレンダリングされていないノードでは、lookerstart.cfg の LOOKERARGS 環境変数に --concurrent-render-jobs=0 を追加します。レンダリング ノードがない場合、これらのノードでレンダリング ジョブは実行されません。

すべての専用のレンダリング ノードでは、lookerstart.cfg の LOOKERARGS 環境変数に --concurrent-render-jobs=<n> を追加します。Looker はデフォルトで 2 つのレンダリング スレッドから開始しますが、<n> 個に増やすことができます。<n> 個のレンダリング スレッドの場合、各ノードは <n> 個の同時レンダリング ジョブを実行できます。

各レンダリング ジョブでは、大量のメモリが使用される可能性があります。レンダリング ジョブごとに約 2 GB を割り当てます。たとえば、コア Looker プロセス（Java）に合計メモリの 60% が割り当てられ、残りのメモリの 20% がオペレーティング システム用に予約されている場合、レンダリング ジョブには残りの 20% が割り当てられます。64 GB のマシンでは、残りは 12 GB で、6 つの同時レンダリング ジョブに十分な容量です。ノードがレンダリング専用で、インタラクティブ ジョブを処理するロードバランサ プールに含まれていない場合、より多くのレンダリング ジョブを許可するように Looker のコア プロセスのメモリを減らすことができます。64 GB のマシンでは、Looker コアプロセスに約 30%（20 GB）を割り当てることができます。一般的な OS の使用には 20% を予約し、残りの 50%（32 GB）はレンダリングに必要です。これは、16 個の同時レンダリング ジョブに十分な容量です。

内部（バックエンド）データベース

Looker サーバーは、独自の構成、データベース接続、ユーザー、グループ、ロール、フォルダ、ユーザー定義の Look とダッシュボード、その他のさまざまなデータに関する情報を内部データベースに保持します。

中規模のスタンドアロン Looker インスタンスの場合、このデータは Looker プロセス自体に埋め込まれたインメモリ HyperSQL データベース内に保存されます。このデータベースのデータは <looker install directory>/.db/looker.script ファイルに保存されます。このデータベースは便利で軽量ですが、頻繁に使用すると、パフォーマンスの問題が発生します。そのため、リモート MySQL データベースから始めることをおすすめします。これがうまくいかない場合は、~/looker/.db/looker.script ファイルが 600 MB に達したら、リモート MySQL データベースに移行することをおすすめします。クラスタは MySQL データベースを使用する必要があります。

Looker サーバーは、MySQL データベースに対して多くの小規模な読み取りと書き込みを行います。ユーザーが Look または Explore を実行するたびに、Looker は、データベースをチェックして、ユーザーが引き続きログインしていること、ユーザーにデータへのアクセス権があること、ユーザーが Look や Explore を実行する権限があることを確認します。また、Looker は、実行された実際の SQL、リクエストの開始時間と終了時間などのデータを MySQL データベースに書き込みます。ユーザーと Looker アプリケーションの間の 1 回のインタラクションで、MySQL データベースに対して 15 ～ 20 回の小規模な読み取りと書き込みが発生する可能性があります。

MySQL

MySQL サーバーは、バージョン 8.0.x であり、utf8mb4 エンコードを使用するように構成する必要があります。InnoDB ストレージ エンジンを使用する必要があります。MySQL の設定手順と、既存の HyperSQL データベースから MySQL にデータを移行する方法については、Looker バックエンド データベースを MySQL に移行するのドキュメント ページをご覧ください。

MySQL を使用するように Looker を構成する場合は、接続情報を含む YAML ファイルを作成する必要があります。YAML ファイルに looker-db.yml という名前を付け、lookerstart.cfg ファイルの LOOKERARGS セクションに -d looker-db.yml 設定を追加します。

MariaDB

MySQL は、デュアルライセンスであり、オープンソースと商用プロダクトの両方として提供されています。Oracle は MySQL の強化を続けており、MySQL は MariaDB としてフォークされています。MariaDB 同等バージョンの MySQL は Looker と連携できることが知られていますが、Looker のエンジニアリング チームによる開発やテストは行われていません。そのため、機能はサポートまたは保証されません。

クラウド バージョン

Looker をクラウド インフラストラクチャでホストする場合は、同じクラウド インフラストラクチャで MySQL データベースをホストするのが論理的です。3 大クラウド ベンダー（Amazon AWS、Microsoft Azure、 Google Cloud）クラウド プロバイダは、MySQL データベースのメンテナンスと構成の大部分を管理し、バックアップの管理や迅速な復元などのサービスを提供します。これらのプロダクトは、Looker との連携が確認されています。

システム アクティビティのクエリ

MySQL データベースは、ユーザーが Looker をどのように使用しているかに関する情報を保存するために使用されます。システム アクティビティ モデルを表示する権限を持つ Looker ユーザーは、このデータを分析するために事前に構築された複数の Looker ダッシュボードにアクセスできます。ユーザーは、Looker メタデータの Explore にアクセスして、追加の分析を作成することもできます。MySQL データベースは、主に小規模で高速な「運用」クエリに使用されます。システム アクティビティ モデルによって生成される大規模で遅い「分析」クエリは、これらの運用クエリと競合し、Looker の速度を低下させる可能性があります。また、長年の履歴を含む大規模なメタデータ テーブルを対象とするバックグラウンドの自動メンテナンス クエリ（集中的なクリーンアップ）は、大量のデータベース IOP を消費し、全体的なパフォーマンスに影響する可能性があります。メタデータ テーブルの管理に関するベスト プラクティスについては、バックエンド データベースのメンテナンスとメタデータの保持セクションをご覧ください。

このような場合、MySQL データベースを別のデータベースに複製できます。セルフマネージド システムと特定のクラウド マネージド システムの両方で、他のデータベースへのレプリケーションの基本構成が提供されます。レプリケーションの構成については、このドキュメントでは扱いません。

システム アクティビティ クエリでレプリカを使用するために、looker-db.yml ファイル（たとえば、名前付き looker-usage-db.yml ）を作成し、レプリカを指すように変更し、設定 --internal-analytics-connection-file looker-usage-db.yml を lookerstart.cfg ファイルの LOOKERARGS セクションに追加します。

システム アクティビティ クエリは、MySQL インスタンスまたは Google BigQuery データベースに対して実行できます。他のデータベースに対してテストされません。

バックエンド データベースのメンテナンスとメタデータの保持

セルフマネージド バックエンド データベース（MySQL など）を使用するセルフホスト型の Looker インスタンスは、メタデータ テーブル（クエリ履歴テーブルなど）の集中的なクリーンアップなど、自動化されたバックグラウンド メンテナンス タスクを実行します。これらのテーブルには、数年間の使用で数百万件の古いレコードが蓄積される可能性があります。これらの大規模なテーブルで自動クリーンアップ プロセスを実行すると、使用可能な 1 秒あたりの IO オペレーション（IOP）が枯渇し、バックエンド データベースのパフォーマンスが大幅に低下して、本番環境システムに影響を与える可能性があります。

アクティブなクリーンアップの結果としてシステムで IOP の使用率が高くなっている場合は、自動の集中的なクリーンアップ プロセスを完了させる必要があります。パフォーマンスの低下を防ぎ、メタデータ テーブルを適切なサイズに維持するには、管理者は次のベスト プラクティスを実装する必要があります。

1. メタデータの保持を減らす: Looker の [**管理**] パネルの [抽出履歴の保持日数] パラメータを 90 日以下に減らして、これらのテーブルのサイズを制限します。
2. 物理メンテナンスを実行する: 最大のテーブル（クエリ履歴テーブルなど）の手動レコード クリーンアップを実行し、MySQL OPTIMIZE TABLE コマンドを実行して物理ディスク容量を再利用し、テーブル インデックスを再構築します。
3. メモリ構成を確認する: データベースのメモリ構成（InnoDB バッファプールなど）が、負荷の高いクエリを処理するのに十分であることを確認します。アクティビティの高いクラスタでは、innodb_buffer_pool_size の調整が必要になることがあります（このページの後半の MySQL パフォーマンス構成セクションをご覧ください）。

MySQL のパフォーマンス構成

Looker バックエンド データベースを MySQL に移行するために必要な設定に加えて、アクティビティの高いクラスタでは、追加のチューニングと構成が有効になる場合があります。これらの設定は、/etc/my.cnf ファイルに対して、またはクラウド管理インスタンスの Google Cloud コンソールで行うことができます。

my.cnf 構成ファイルは複数の部分に分かれています。このセクションで説明する設定変更は、[mysqld] 部分で行われます。

InnoDB バッファプール サイズを設定する

InnoDB バッファプール サイズは、InnoDB データファイルの状態をメモリに保存するために使用される合計 RAM です。サーバーが MySQL の実行専用である場合、innodb_buffer_pool_size はシステム メモリの合計の 50 ～ 70% に設定する必要があります。

データベースの合計サイズが小さい場合は、InnoDB バッファプールをメモリの 50% 以上ではなく、データベースのサイズに設定してもかまいません。

この例では、サーバーのメモリが 64 GB であるため、InnoDB バッファプールは 32 GB ～ 45 GB の範囲にする必要があります。通常、大きいほど良いです。

[mysqld]
...
innodb_buffer_pool_size=45G

InnoDB バッファプール インスタンスを設定する

複数のスレッドが大きなバッファプールを検索しようとすると、競合が発生する可能性があります。これを防ぐため、バッファプールは競合なしに異なるスレッドからアクセスできる小さな単位に分割されます。デフォルトでは、バッファプールは 8 つのインスタンスに分割されます。これにより、8 つのスレッドのボトルネックが発生する可能性があります。バッファプール インスタンスの数を増やすと、ボトルネックが発生する可能性が低くなります。各バッファプールに少なくとも 1 GB のメモリが割り当てられるように、innodb_buffer_pool_instances を設定する必要があります。

[mysqld]
...
innodb_buffer_pool_instances=32

InnoDB ログファイルを最適化する

トランザクションが commit されると、データベースは実際のファイル内のデータを更新するか、トランザクションの詳細をログに保存できます。データファイルが更新される前にデータベースがクラッシュした場合、ログファイルを「再生」して変更を適用できます。ログファイルへの書き込みは、小さな追加オペレーションです。commit 時にログに追加し、データファイルに対する複数の変更をバッチ処理して、1 回の IO オペレーションで書き込むのが効率的です。ログファイルがいっぱいになると、データベースは新しいトランザクションの処理を一時停止し、変更されたすべてのデータをディスクに書き戻す必要があります。

一般的な経験則として、InnoDB ログファイルは 1 時間分のトランザクションを格納するのに十分な大きさにする必要があります。

通常、InnoDB ログファイルは 2 つあります。これらのファイルは InnoDB バッファプールの約 25% にする必要があります。たとえば、バッファプールが 32 GB のデータベースの場合、InnoDB ログファイルの合計は 8 GB（ファイルあたり 4 GB）にする必要があります。

[mysqld]
...
innodb_log_file_size=8GB

InnoDB IO 容量を構成する

MySQL は、サーバーに過負荷がかからないように、ディスクへの書き込み速度を調整します。デフォルト値は、ほとんどのサーバーで控えめな値になっています。最高のパフォーマンスを得るには、sysbench ユーティリティを使用してデータディスクへのランダムな書き込み速度を測定してから、その値を使用して MySQL がデータをより速く書き込めるように IO 容量を構成します。

クラウドホスト型のシステムでは、クラウド ベンダーはデータ ストレージに使用されているディスクのパフォーマンスを報告できる必要があります。自己ホスト型の MySQL サーバーの場合、データディスクへのランダムな書き込み速度を IO オペレーション/秒（IOPS）で測定します。Linux ユーティリティ sysbench は、これを測定する 1 つの方法です。その値を innodb_io_capacity_max に使用し、その値の 2 分の 1 から 4 分の 3 の値を innodb_io_capacity に使用します。したがって、次の例では、800 IOPS を測定した場合に値が表示されます。

[mysqld]
...
innodb_io_capacity=500
innodb_io_capacity_max=800

InnoDB スレッドを構成する

MySQLは、サービスを提供するクライアントごとに少なくとも1つのスレッドを開きます。多数のクライアントが同時に接続すると、処理されるスレッド数が膨大になる可能性があります。その結果、システムは処理時間よりもスワップ処理に多くの時間を費やすことになります。

ベンチマークを実施して、最適なスレッド数を決定する必要があります。テストするには、スレッド数をシステムの CPU（または CPU コア）の数から CPU の数の 4 倍の範囲で設定します。16 コアのシステムの場合、この値は 16 ～ 64 の範囲になる可能性があります。

[mysqld]
...
innodb_thread_concurrency=32

Transaction durability

トランザクション値が 1 の場合、MySQL はすべてのトランザクションでディスクに書き込みます。サーバーがクラッシュした場合、トランザクションは失われませんが、データベースのパフォーマンスは影響を受けます。この値を 0 または 2 に設定すると、パフォーマンスが向上しますが、数秒分のデータ トランザクションが失われる可能性があります。

[mysqld]
...
innodb_flush_log_at_trx_commit=1

フラッシュ メソッドを設定する

通常、オペレーティング システムはディスクへの書き込みをバッファリングします。MySQL と OS の両方がバッファリングを行うため、パフォーマンスの低下が発生します。フラッシュ メソッドのバッファリングを 1 つのレイヤに減らすと、パフォーマンスが向上する可能性があります。

[mysqld]
...
innodb_flush_method=O_DIRECT

テーブルごとに 1 つのファイルを有効にする

デフォルトでは、MySQL はすべてのデータに単一のデータファイルを使用します。innodb_file_per_table 設定では、テーブルごとに個別のファイルが作成されるため、パフォーマンスとデータ管理が向上します。

[mysqld]
...
innodb_file_per_table=ON

メタデータで統計を無効にする

この設定により、内部メタデータ テーブルでの統計の収集が無効になり、読み取りパフォーマンスが向上します。

[mysqld]
...
innodb_stats_on_metadata=OFF

クエリ キャッシュを無効にする

クエリ キャッシュは非推奨であるため、query_cache_size と query_cache_type を 0 に設定すると無効になります。

[mysqld]
...
query_cache_size=0
query_cache_type=0

結合バッファを拡大する

join_buffer は、メモリ内で結合を実行するために使用されます。これを大きくすると、特定のオペレーションを改善できます。

[mysqld]
...
join_buffer_size=512KB

一時テーブルと最大ヒープサイズを拡大する

tmp_table_size と max_heap_table_size は、ディスクに記録される前に、一時的なインメモリ テーブルに適切なデフォルトの値を設定します。

[mysqld
...
tmp_table_size=32MB
max_heap_table_size=32MB

開いているテーブルのキャッシュを調整する

table_open_cache 設定は、開いているテーブルのファイル記述子を保持するキャッシュのサイズを決定します。table_open_cache_instances 設定では、キャッシュが複数の小さな部分に分割されます。table_open_cache ではスレッド競合が発生する可能性があるため、小さく分割することで並行性を高めることができます。

[mysqld]
...
table_open_cache=2048
table_open_cache_instances=16

Git サービス

Looker は、LookML ファイルのバージョン管理を行うために Git サービスと連携するように設計されています。GitHub、GitLab、Bitbucket などの主要な Git ホスティング サービスがサポートされています。Git サービス プロバイダは、コード変更を表示するための GUI や、pull リクエストや変更承認などのワークフローのサポートなど、さらに付加価値を提供します。必要に応じて、Git は簡易な Linux サーバーで実行できます。

セキュリティ ルールにより Git ホスティング サービスがデプロイに適していない場合は、これらのサービス プロバイダの多くが独自の環境で実行できるバージョンを提供しています。特に GitLab は、一般的にセルフホスト型で、ライセンス費用なしのオープンソース プロダクトとして使用することも、サポート対象のライセンス プロダクトとして使用することもできます。GitHub Enterprise は自己ホスト型のサービスとして提供されており、サポート対象の商用プロダクトです。

以降のセクションでは、最も一般的なサービス プロバイダのニュアンスについて説明します。

GitHub/GitHub Enterprise

Git 接続の設定とテストのドキュメント ページでは、GitHub を例として使用しています。

GitLab/gitlab.com

GitLab の詳細な設定手順については、Looker でのバージョン管理用の GitLab の使用の Looker コミュニティの投稿をご覧ください。リポジトリがサブグループに含まれている場合は、HTTPS 形式または SSH 形式のいずれかを使用してリポジトリの URL に追加できます。

https://gitlab.com/accountname/subgroup/reponame

[e-mail]:accountname/subgroup/reponame.git

また、Looker で生成された SSH 認証鍵を GitLab に保存する方法は、ユーザー SSH 認証鍵、リポジトリ デプロイキー、グローバル共有デプロイキーの 3 つがあります。詳細な説明は、GitLab のドキュメントをご覧ください。

Google Cloud ソース

Cloud Source Repositories で Git を設定する手順については、Looker でのバージョン管理用の Cloud Source Repositories の使用のコミュニティ投稿をご覧ください。

Bitbucket Cloud

Bitbucket Cloud で Git を設定する手順については、Looker でのバージョン管理用の Bitbucket の使用のコミュニティ投稿をご覧ください。2021 年 8 月の時点で、Bitbucket Cloud はデプロイ ウェブフックのシークレットをサポートしていません。

Bitbucket Server

Bitbucket Server で pull リクエストを使用するには、次の手順を完了する必要がある場合があります。

1. プルリクエストを開くと、Looker は URL でデフォルトのポート番号（7999）を自動的に使用します。カスタムポート番号を使用している場合は、URL のポート番号を手動で置き換える必要があります。
2. Looker の本番環境ブランチをリポジトリのメインブランチと同期するには、プロジェクトのデプロイ Webhook に適合する必要があります。

Phabricator diffusion

Phabricator で Git を設定する手順については、バージョン管理用の Phabricator と Looker の設定のコミュニティ投稿をご覧ください。

ネットワーク

インバウンド接続

Looker ウェブ アプリケーション

デフォルトでは、Looker はポート 9999 で HTTPS リクエストをリッスンします。Looker では、CN が self-signed.looker.com の自己署名証明書を使用します。Looker サーバーは、以下を交互に行うように構成することもできます。

1. --ssl-provided-externally-by=<s> 起動フラグを使用して、SSL 終端ロードバランサ/プロキシからの HTTP 接続を受け入れます。値は、プロキシの IP アドレス、またはプロキシの IP アドレスにローカルで解決できるホスト名に設定する必要があります。Looker は、この IP アドレスからの HTTP 接続のみを受け入れます。
2. --ssl-keystore=<s> 起動フラグを使用して、顧客が提供した SSL 証明書を使用します。

Looker API

Looker API はポート 19999 をリッスンします。インストールで API にアクセスする必要がある場合は、ロードバランサには必要な転送ルールが必要です。SSL に関する考慮事項は、メインのウェブ アプリケーションと同じです。ウェブ アプリケーションとは異なるポートを使用することをおすすめします。

ロードバランサ

多くの場合、ロードバランサは、お客様の証明書を使用してポート 443 で HTTPS リクエストを受け入れてから、自己署名証明書または HTTP を使用してポート 9999 の Looker サーバーノードにリクエストを転送するために使用されます。ロードバランサが Looker 自己署名証明書を使用している場合は、その証明書を受け入れるように構成する必要があります。

アイドル接続とタイムアウト

ユーザーが Looker で大規模なリクエストを開始すると、データベースで実行するのにコストがかかる可能性があるクエリが生じる可能性があります。ノートパソコンのカバーをシャットダウンする、ネットワークから切断する、ブラウザでそのタブを強制終了するなど、ユーザーがなんらかの方法でそのリクエストを中止した場合、Looker はそのデータベース クエリを把握して、終了します。

この状況に対処するため、クライアント ウェブ アプリケーションがデータベース クエリの実行をリクエストすると、ブラウザは Looker サーバーへの長時間存続する HTTP リクエストを使用してソケット接続を開きます。この接続は開いたままアイドル状態になります。このソケットは、クライアント ウェブ アプリケーションが強制終了されたり、何らかの方法で切断されたりすると切断されます。サーバーは、関連するデータベース クエリを切断してキャンセルすることを認識します。

多くの場合、ロードバランサはこうしたオープンなアイドル状態の接続を認識し、強制終了します。Looker を効果的に実行するには、ユーザーが実行する可能性のある最長のクエリの実行時間だけ接続が開いたままになるようにロードバランサを構成する必要があります。少なくとも 60 分のタイムアウトをおすすめします。

送信接続

Looker サーバーは、公共のインターネットを含むすべてのリソースへのアウトバウンド アクセスを無制限に持つことができます。これにより、Linux ディストリビューションのパッケージ リポジトリへのアクセスが必要な Chromium のインストールなど、多くのタスクが簡素化されます。

Looker で作成が必要となる可能性のある送信接続は次のとおりです。

内部データベース接続

デフォルトでは、MySQL はポート 3306 で接続をリッスンします。Looker ノードは、このポートで MySQL への接続を開始できる必要があります。リポジトリがどのようにホストされているかによっては、ファイアウォールの走査が必要になる場合があります。

外部サービス

Looker テレメトリー サーバーとライセンス サーバーは、公共のインターネットで HTTPS を使用して利用できます。Looker ノードから ping.looker.com:443 および license.looker.com:443 へのトラフィックを許可リストに追加することが必要になる場合があります。

データ ウェアハウス接続

クラウド ホスト型のデータベースの場合は、公共のインターネットを使用した接続が必要になる場合があります。たとえば、BigQuery を使用している場合は、accounts.google.com:443 と www.googleapis.com:443 を許可リストに追加することが必要になる場合があります。データベースが独自のインフラストラクチャの外部にある場合は、データベース ホストにネットワークの詳細についてお問い合わせください。

SMTP サービス

デフォルトでは、Looker は SendGrid を使用して発信メールを送信します。場合によっては、許可リストへの smtp.sendgrid.net:587 の追加が必要になる場合があります。SMTP 設定は、別のメール ハンドラを使用するように構成で変更することもできます。

アクション ハブ、アクション サーバー、Webhook

多くのスケジューラ宛先（特にウェブフックと Looker 管理パネルで有効になっている宛先）では、HTTPS リクエストを使用してデータを送信します。

• ウェブフックの場合、これらの宛先はユーザーによって実行時に指定されるため、アウトバウンド接続のファイアウォール設定の目的と矛盾する可能性があります。
• アクション ハブの場合、これらのリクエストは actions.looker.com に送信されます。詳しくは、Looker Action Hub の構成に関するドキュメントをご覧ください。
• 他のアクション サーバーの場合、これらのリクエストは、Looker の [管理者] パネルで管理者によってアクション サーバーの構成で指定されたドメインに送信されます。

プロキシ サーバー

公共のインターネットに直接アクセスできない場合は、次のような行を lookerstart.cfg に追加して、HTTP(S) リクエストにプロキシ サーバーを使用するように Looker を構成できます。

JAVAARGS="-Dhttp.proxyHost=myproxy.example.com
  -Dhttp.proxyPort=8080
  -Dhttp.nonProxyHosts=127.0.0.1|localhost
  -Dhttps.proxyHost=myproxy.example.com
  -Dhttps.proxyPort=8080"

ノード間通信は HTTPS を介して行われるため、プロキシ サーバーを使用していてインスタンスがクラスタ化されている場合、通常はクラスタ内のすべてのノードの IP/ホスト名を Dhttp.nonProxyHosts 引数に追加します。

ノード間通信

内部ホスト ID

クラスタ内では、各ノードが他のノードと通信できる必要があります。これを許可するには、起動構成で各ノードのホスト名または IP アドレスを指定します。ノードの起動時に、この値が MySQL リポジトリに書き込まれます。クラスタの他のメンバーは、これらの値を参照してこのノードと通信できます。起動構成でホスト名または IP アドレスを指定するには、lookerstart.cfg の LOOKERARGS 環境変数に -H node1.looker.example.com を追加します。

ホスト名はノードごとに一意である必要があるため、lookerstart.cfg ファイルはインスタンスごとに一意である必要があります。ホスト名や IP アドレスをハードコードする代わりに、hostname -I コマンドまたは hostname --fqdn コマンドを使用して、実行時にこれらを検出することもできます。これを実装するには、-H $(hostname -I) または -H $(hostname --fqdn) を lookerstart.cfg の LOOKERARGS 環境変数に追加します。

内部ポート

ウェブサーバーと API サーバーにそれぞれ使用されるポート 9999 と 19999 に加えて、クラスタノードはメッセージ ブローカー サービスを介して相互に通信します。このサービスはポート 1551 と 61616 を使用します。ポート 9999 と 19999 はエンドユーザー トラフィックに対して開く必要がありますが、1551 と 61616 はクラスタノード間で開く必要があります。

関連リソース

• セルフホスト型インフラストラクチャ アーキテクチャ パターン