表示されているのは Looker のドキュメントです。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

このページは Cloud Translation API によって翻訳されました。

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

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

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

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

ホストの設定

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

Looker は、RedHat、SUSE、Debian/Ubuntu などの一般的な Linux バージョンで正常に動作します。通常、特定の環境で実行するように設計され、最適化されたこのディストリビューションの派生物は問題ありません。たとえば、Google Cloud または AWS の Linux ディストリビューションは 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 サーバーは、独自の構成、データベース接続、ユーザー、グループ、ロール、フォルダ、ユーザー定義のルックとダッシュボード、その他のさまざまなデータを内部データベースに保持します。

中規模のスタンドアロン 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 と連携することが知られています。

System Activity クエリ

MySQL データベースは、ユーザーが Looker をどのように使用しているかに関する情報を保存するために使用されます。システムアクティビティモデルを表示する権限を持つすべての Looker ユーザーは、事前に構築された複数の Looker ダッシュボードにアクセスして、このデータを分析できます。ユーザーは、Looker メタデータの Explore にアクセスして、追加の分析を作成することもできます。MySQL データベースは、主に小規模で高速な「運用」クエリに使用されます。System Activity Model によって生成される大規模で遅い「分析」クエリは、これらのオペレーションクエリと競合し、Looker の速度を低下させる可能性があります。

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

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

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

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 スレッドのボトルネックが発生する可能性があります。バッファプールインスタンスの数を増やすと、ボトルネックの発生可能性が低くなります。innodb_buffer_pool_instances は、各バッファプールに 1 GB 以上のメモリが割り当てられるように設定する必要があります。

[mysqld]
...
innodb_buffer_pool_instances=32

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

トランザクションが 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 に使用し、innodb_io_capacity にはその半分から 3 分の 4 の値を使用します。次の例では、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 は、Git サービスと連携して LookML ファイルのバージョン管理を行うように設計されています。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

git@gitlab.com:accountname/subgroup/reponame.git

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

Google Cloud Source

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

Bitbucket Cloud

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

Bitbucket Server

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

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

Phabricator diffusion

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

ネットワーク

インバウンド接続

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

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

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

多くのスケジューラのデスティネーション（特に Webhook と Looker 管理パネルで有効になっているデスティネーション）では、HTTPS リクエストを使用してデータが送信されます。

Webhook の場合、これらの宛先はユーザーが実行時に指定するため、アウトバウンド接続のファイアウォール設定の目的と矛盾する可能性があります。
アクションハブの場合、これらのリクエストは 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 はクラスタノード間で開く必要があります。

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

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