【Sisense Administration】サーバ再起動より、全サービス再起動を

シャローム！Sato-Gです。
今日はボーっと画面を見ていた。
サーバの障害でサーバに接続はできるのにそのあと画面は真っ白、サーバを再起動しても変わらず…
というわけで、サーバがコケた時の対処方法の紹介。
無いにこしたことはないんだけど。

1. どんな状態だったか

ビルド中にエラーになった。メモリ不足のアラートが出ていたので、このエラーはリソース不足の可能性が高い。
その直後からサーバのログイン認証は通るのに画面は真っ白になり、何も表示されなくなってしまった。

Sisenseのサービスのうち、これかなと思われるやつを再起動してみたが改善しない。
じゃあサーバそのものを再起動しちまえ。
しかし、サーバを再起動しても状況は変わらず…

2. 関連サービスを一括再起動する

こうなるとSisenseさんのサポート頼み。
チケットを上げたらレスが来た。
「PowerShellでSisenseのサービスを全て再起動して」
でもね。サーバの再起動もやってるのに…
リソース不足のサーバではこういうことが起こりうるらしく、そんな時はサーバ再起動してもダメで、明示的にサービス再起動したら直ったりするらしい。
PowerShellを管理者として立ち上げて以下のコマンドを実行。

PS> Restart-Service -DisplayName sisense*

で、繋いでみたら本当にあっさり直った！
今ひとつ納得いかないところもあるんだが、深く考えずに、どうにもならない時は「サーバ再起動ではなく、Sisenseの全サービス再起動」と心得ることにした。

3. 原因は何だったのか？

日頃からお世話になっているSisenseのサポートの方と会話した。
なぜこうなったのか原因を教えてほしい。CPUなのかメモリなのか。
彼はサーバ名を教えてくれと言う。
Sisenseさんにサーバ名とか登録してないんだけど、どういうこと？
サーバ名を教えてもらえれば調べられるっていうのだ。

その後、連絡がきて、Zoomで繋いで見せてもらったのだが、Sisense社はライセンス登録したサーバはLogz.ioというツールでログを収集している。それによるとメモリが上限に達している時間帯にCPUが100%の状態が続いたため、Connection Lostとなり落ちたということのようだ。

ログを取られているとは知らなかった。ライセンス違反とか絶対にできないな。
さすがイスラエル！
SisenseがBI製品のサポート満足度調査で1位になる理由もわかった気がする。

4. 今回の障害で学んだこと

SisenseにETL機能はない。理由は
①デーベースからSELECTしてテーブルを作る
② ①のテーブルをJoinしたりUnionしたりしてカスタムテーブルを作る
やっていることはこの2つであって、作ったSQLをSisenseが中を解読してSQLの実行順を決めているからだ。
できたテーブルをDROPすることはできないから、出来上がったデータモデルは極力綺麗にしたいので中間テーブルを作らずに処理しようとすると自ずとサブクエリの多い数百行のSQLになる。
パフォーマンスを考えるといかにシンプルなデータモデルを作るかー
そう考えると使うことのない無駄なテーブルは残したくない。
しかし、無駄なテーブルは非表示にすれば、ダッシュボードでは全く使わないのだからパフォーマンスには影響を与えないはずだ。
であれば、ディスクのスペースは多少占有するとはいえ、CPUやメモリのリソースを有効に活用するならば、一見無駄と思える中間テーブルも無駄とはいえないかもしれない。

5. まとめ

障害から学んだことを整理すると

・データモデルはシンプルなほうがいい（この原則は変わらない）
・しかし、ビルド時のCPUやメモリを考えるとSQLもシンプルなほうがいい（そのためには中間テーブルが多少できても仕方がない）
・中間テーブルは非表示テーブルにし、ダッシュボードでは使用しないようにする（性能には影響しないはず）

ではどの程度が最適なのかーそれはやってみないとわからない。
んー、場数だね。
まだまだっす。

ではまた！