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

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

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

このシリーズは、3 つのパートで構成されています。

セルフホスト型インフラストラクチャの概要
セルフホスト型インフラストラクチャアーキテクチャパターン
セルフホスト型インフラストラクチャコンポーネントのチュートリアル（このページ）

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 とメモリ

小規模なチームで使用する開発システムや基本的なテスト Looker インスタンスには、4x16（4 個の CPU と 16 GB の RAM）ノードで十分です。しかし、本番環境では、通常はこれでは不十分です。経験上、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 のメタデータも一元化する必要があるため、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 の管理では、リソーシングの絞り込みに役立つモニタリングが必要になる場合があります。JMX を使用して JVM メモリ使用量をモニタリングすることをおすすめします。

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 のエンジニアリングチームによる開発やテストは行われていません。そのため、機能はサポートまたは保証されません。

Cloud バージョン

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

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

MySQL データベースは、ユーザーによる Looker の使用状況に関する情報を保存するために使用されます。システムアクティビティモデルを表示する権限を持つ Looker ユーザーは、多くの事前構築された Looker ダッシュボードにアクセスして、このデータを分析できます。ユーザーは、Looker メタデータの Explore にアクセスして、追加の分析を作成することもできます。MySQL データベースは主に、小規模で高速な「運用」クエリに使用されます。System Activity モデルによって生成された大規模で低速の「分析」クエリは、これらの運用クエリと競合し、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 ～ 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 されると、データベースでは実際のファイルのデータを更新するか、トランザクションの詳細をログに保存できます。データファイルの更新前にデータベースがクラッシュした場合、ログファイルを「再生」して変更を適用できます。ログファイルへの書き込みは小規模な追加オペレーションです。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 にはその値の 2 分の 1 から 4 分の 3 の値を使用します。たとえば、次の例では、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

flush メソッドを設定する

オペレーティングシステムは通常、ディスクへの書き込みのバッファリングを行います。MySQL と OS はどちらもバッファリングであるため、パフォーマンスが損なわれます。フラッシュメソッドのバッファリングのレイヤを 1 つ減らすと、パフォーマンスが向上します。

[mysqld]
...
innodb_flush_method=O_DIRECT

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

デフォルトでは、MySQL はすべてのデータに対して 1 つのデータファイルを使用します。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 に保存する方法には、ユーザーの SSH 認証鍵、リポジトリデプロイキー、グローバル共有デプロイキーの 3 つがあります。詳細な説明は、GitLab のドキュメントをご覧ください。

Google Cloud Source

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

Bitbucket Cloud

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

Bitbucket Server

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

pull リクエストを開くと、Looker は自動的に 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 証明書を --ssl-keystore=<s> 起動フラグとともに使用します。

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 管理パネルで有効になっている Webhook）には、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 はクラスタノード間で開いておく必要があります。

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