Lookerが実行するクエリが意図せずキャンセルされたりタイムアウトしたりする場合にチェックすること

人生にはキャンセルやタイムアウトはありません

「カスタマーストーリー」を支えるツール特集

#ビッグデータ

#ビジネス・アナリティクス

#Looker

たまちゃん

2020.05.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

奈良県の自宅でリモートワークしている玉井です。

Lookerはデータを色々な形で可視化できますが、その実体はデータソースにSQLクエリを実行しています。で、時として、そのクエリが意図しない形でキャンセルされたりタイムアウトしたりすることがあります。クエリが実行されないとダッシュボードを見たりExploreで分析することができませんので、早急に原因を調査して改善する必要があります。

今回は、そんな時にチェックしたほうがいいと思う事柄についてまとめてみました。

基本的に、当記事最下部に載せているリンクの記事を参考にしていますので、そちらもご確認ください。

まずLookerの仕様を把握しておく

大前提

Lookerは一度DBに投げたクエリを勝手にキャンセルすることはありません。

Looker上でクエリが実行される流れ

ダッシュボードを読み込んだりExploreを使ったりSQL Runnerを使ったりしたとき、Lookerはデータソースにクエリを実行します。その時の流れは下記のようになります。

ユーザーのWebブラウザ　→　Looker　→　データソース

ちなみに「クエリを実行しているLookerを開いているタブ」を閉じると、Lookerはそれを検知してクエリをキャンセルします。

つまり…

Lookerが投げたクエリが意図せずキャンセル（またはタイムアウト）される場合、原因の箇所は下記のどちらかになります。

Lookerがデータソースにクエリを投げる前
Looker以外のどこか

原因と思われる部分を確認する

1. Lookerの設定を確認

「Lookerは一度投げたクエリをキャンセルしない」と書きましたが、言い方をかえると「データソースに投げる前の段階ではキャンセルされる可能性がある」ということです。

そのデータソースのConnection設定画面に、下記の項目があります。

Lookerは「同時に接続できるクエリ数の上限」があります。その上限を超えたクエリは「キュー」に入れられ、待機中となります。実行されないまま待機時の上限を超えたキューはキャンセルされます。

その「同時に接続できるクエリ数の上限」と「キューの待機時間」にあたる設定が、上記のMax ConnectionsとConnection Pool Timeoutにあたります。

つまり、「おかしいな。クエリが勝手にキャンセルされたぞ？」となった場合、まずここの設定を見て、これらの上限が超えていなかったかどうかを確認しましょう。

2. データソース側の設定を確認

上記の設定に該当していない場合（「っていうかそもそもクエリ自体はDBに到達してるんよ！」という場合）、次に確認するのはデータソース側の設定です。データベースやDWH側のタイムアウトや同時実行数等の設定に引っかかっていないか確認しましょう。また、Lookerがクエリを実行する際に用いるユーザー（DBユーザー）の権限等も確認しておきましょう。

3. Webブラウザの設定を確認

「（原因は）Looker側でもデータ側でもなさそう…」となった場合、次に確認するのは（Lookerを開いている）ブラウザの設定です。

ブラウザによっては、それ独自でタイムアウトの設定が存在します。例えばFirefoxでは下記のような設定があります。

自分が使用している（Lookerにアクセスする）ブラウザも確認しましょう。

4. Webブラウザ～Looker間のネットワークを確認

Lookerでもデータソースでもブラウザでもない…となった場合、いよいよブラウザ～Looker間のネットワークを疑います。結論からいうと、プロキシやファイアウォール等が、一連の処理を邪魔している可能性はあります。

これらは、Lookerの外の話となるため、そのネットワークの管理者（担当者、情シス等）と相談する形になると思います。（もし環境が許せば）まずは、プロキシやファイアウォール等を経由しないルートでクエリが実行できるかどうか試したいところです。

あたりをつけていった結果、例えばプロキシが怪しい場合、プロキシのログや設定の確認等を実施したり、ブラウザでHARファイルを生成し、ネットワークの通信状態を確認したりすることになると思われます。

ちなみに、ファイアウォールが怪しい場合で、データソースがAmazon Redshiftの場合、下記に該当している可能性もあります。

どちらにしろ、ここまでくると、ネットワーク担当者と協力して色々と調査する段階になります。場合によっては「Lookerに関してはプロキシ等をバイパスする経路」を用意したりすることになるかもしれません。

ネットワークが怪しいかどうかLooker上でテストしてみる

「本当にネットワークに原因があるのか」をチェックするために、指定した時間だけ実行するクエリをLooker上で実行し、指定した時間未満でクエリがキャンセルされるかどうかをテストすることができます。この方法は当記事の最下部に記載しているLookerのDiscourse記事に載っているものです（そのままでは動作しなかったので、多少変更しています）。

Modelファイル等に下記のExploreを定義して実行します。

※Testing and troubleshooting socket based query killing - Administration - Looker Communityより

ただ、上記そのままだとLookMLのバリデーション自体が通らなかったため、下記のように書き換えてみました。

explore: query_kill_test{
# キャッシュが効かないようにする
  persist_for: "0 seconds"
}

view: query_kill_test {
# 指定した時間だけクエリが実行される関数を記述する
  derived_table:{
    sql:select SYSTEM$WAIT(300) as sleep ;;
    }
  dimension: sleep {
    type: number
    sql: ${TABLE}.sleep ;;
  }
}

実行するとこんな感じ。