このページでは、Looker アーキテクチャの特定のコンポーネントに関する一般的なプラクティスを紹介し、デプロイ内でそれらを構成する方法について説明します。
Looker には、サーバーのホスティング、アドホックのワークロードとスケジュールされたワークロードの両方の処理、反復モデル開発の追跡など、さまざまな依存関係があります。このページでは、このような依存関係をコンポーネントと呼んでいます。各コンポーネントの詳細については、次のセクションをご覧ください。
ホストの設定
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 に保存する方法は 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 での 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 はクラスタノード間で開く必要があります。