前書き

ISUCON12予選に@tesso、@toshi00、@Rasがチーム「tetora」で参加した際に@Rasがダッシュボードを自作した話です。参加記は多分後で書きます。

メンバーのブログもぜひ。

• @tesso
• @toshi00
• @Ras

今回作ったのはElasticsearch(分析エンジン)、Fluent Bit(ログ収集/転送ツール)、Kibana(ダッシュボードUI)を組み合わせたEFKと呼ばれるダッシュボードです。全てGithub上にOSSとして公開されていて、Docker imageも用意されています。

完成品をあげておきます。スターを押してくれるとあなたの心の中の@Rasが喜びます。もちろんIssue/PRも大歓迎です。

• ダッシュボード：tetoraorg/isucon-dashboard
• テンプレート：tetoraorg/isucon-dashboard-template
• ISUCONサーバーに置く設定ファイル群：tetoraorg/isucon-setup/fluent-bit

GitHub - tetoraorg/isucon-dashboard

Contribute to tetoraorg/isucon-dashboard development by creating an account on GitHub.

GitHubtetoraorg

これらを全てセットアップするとこんな感じになります。かっけ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

前回のISUCON11でOBの@nagatechさんがダッシュボードを自作していて便利そうだったので作ってしまいました。完全に二番煎じです。

今回自作してみて、結論はこんな感じになりました。

• 良かった点
  • EもFもKも知らない技術だったので学べた
  • ついでにDocker Compose、Nginx、TLS、Luaの知識も学べた
  • Kibanaの範囲指定がめちゃめちゃ便利
    • 上の画像の時系列グラフをマウスで範囲選択するとそこの部分だけ分析してくれる
  • 思っていたより安く済んだ
  • 可視化されているのでテンションが上がる
  • シナリオが見える
    • ISUCON12は序盤/終盤でリクエストの傾向が違うことが分かって楽しかった
    • 利用できたかというと、、、
• 悪かった点
  • Fluent Bitのパーサーを自分で書いたのでバグるときはバグる
    • ISUCON11予選ではMariaDBを使っていたためスロークエリログの出力が違うため練習時に結構沼った
  • 自己満で終わりがち
    • チームメンバーは案外見てなくて自分しか見てないみたいなことが往々にしてあると思います
    • Twitterとか見ると作ったけどあんまり見なくて来年から使ってないみたいなのをよく見る
    • 今回は2人ともそこそこ使ってくれてたらしい、うれしい
  • チームメンバーに相談せずに先に作ってしまった
    • ちゃんと需要を聞いてから作ろうな
  • ISUCON12ではsqliteを使っていたためスロークエリログがほとんど取れなかった

今回、ISUCON運営から配布されたさくらのクラウドのクーポンを使ってダッシュボードを作成しました。@nagatechさんが5000円弱と話していたので練習も含めたらほぼ使い切るかなと思ったのですが、ちゃんと使わないときはサーバーを落としていたからか、貰った分(2万円)の1/4も使わないという結果になりました。
(サーバーは練習時は4Core/4GB、本番では4Core/8GBを使用しました)

実装してみて

苦悩の数々が@Rasのscrapboxにまとまっています(scrapなのでまとまってはないです)

• nginx(複数) → fluentd → fluentd → elasticsearch → kibanaをするメモ
• docker composeでelasticsearchの設定ファイルを作るとkibanaにUnable to retrieve version information from Elasticsearch nodesで怒られる
• dockerで立てたelasticsearchがエラーコード137で落ちる

Fluent Bit編

作り始めた当初はEFKのFがFluent BitではなくFluentdでした。しかしRuby製のFluentdよりもC製のFluent Bitの方が高速ということで、速度を求められるISUCON用であることを考慮してFluent Bitに乗り換えました。公式ドキュメントで比較されています(どちらともCloud Nativeという企業が制作しています)。

• Fluentd & Fluent Bit

Fluent Bitの方が高速である理由として、C言語で作られていることに加えて特定のプラグインを使わなければ依存が0になることだと言及されています。

つまりFluent Bitの方がシンプルに記述できるのですが、裏を返すとFluentdに比べてプラグインが圧倒的に少ないことが大きなデメリットとなります。Fluent Bitのプラグインの数は公式が配布している70個程度ですがFluentdは有志がプラグインを作ることができるため現在1000個以上も用意されています。

何も考えずに「速い」だけでFluent Bitに乗り換えた結果、NginxのアクセスログとMySQL/MariaDBのスロークエリログを自分で書く羽目になってしまいました、、、(これが一番つらかった)

まだしっかり見てはいないのですが、次で紹介するElasticsearchと同じ企業が作ったLogstashを使ってみてもよかったかもしれません。(こっちはELKシステムと呼ぶことが多いようです)

練習時はISUCONサーバー上でログのフィルタリングとパースを行い、30秒ごとにダッシュボードサーバーに送信していたのですが、結構メモリを占有するため(htopで見るとサーバーの1/2くらいのときもあった)前日に急いでサーバーでこれらを行うようにしました。ちゃんと計測はしてないのですが、このおかげで本番はそこまで負荷が気にならなかった気がしています。

Elasticsearch & Kibana編

この2つはどちらもElasticという企業のプロジェクトで、公式ドキュメントにDocker composeを使う方法が記載されているのでそれに従えば環境構築はスッと終わります。

• Install Kibana with Docker | Kibana Guide [8.3] | Elastic

苦労した点としてはこれらが挙げられます。

• メジャーバージョンの違いで結構大きな変更が入っているので過去のQ&Aを見ても参考にならないことが多々あった
• 公式の環境構築記事では設定を直書きしていたが、これをYAMLに移そうとすると結構大変だった
• 公式はTLSの使用を推奨しているが証明書周りの設定が結構複雑だった
• プラグイン(Integrations)が豊富だが使い道が分からずあまり使わなかった
• 簡単なダッシュボードはスッと作れるが痒い所に手が届かない感じがある
  • 今回の場合だとスロークエリごとにメトリクスを取る場面でクエリがフルで表示されて肝心のデータがほぼ見えないみたいなことがあった
• Elasticsearchは最低4GBのメモリを確保することが推奨されているため、前日までこれに気づかずMEM_LIMITを1GBに設定していてしばしばダッシュボードが落ちていた

痒い所に手が届かなかったのはKibanaをGrafanaとかに変えれば良さそうな気がするので来年はもう少しダッシュボードを強化させたいですね。

また、ダッシュボードではアクセスログとスロークエリログを可視化するようにしたのですが、競技中はhtopやpprofなども並行してみるため、結局見るところがばらついててしまいました。当日の朝htopと同等の情報ををダッシュボードに導入しようとしたのですがあまりうまくいかず辞めました。htopは時差があると困るため、30秒ごとにサーバーから送られてくるよりは手元で見るほうが良いという結論に至ったのですが、pprofはダッシュボードに乗るとめちゃめちゃうれしいと思っています。Kibanaでフレームグラフを作る方法が分からず断念しました(これもGrafanaとかだったらできるのかな)。良い方法があれば教えてください。

とはいえ、去年はkataribe、pt-query-digest、pprofをベンチを回すたびにDiscordにテキストファイル形式で投げていて結構見づらかったのでそれよりは使いやすくなったと思っています。

終わりに

ダッシュボードの反省点をつらつらと嘆くブログになってしまいました。今年は学生10位(一般枠通過を除けば7位)で惜しくも枠から弾かれてしまったのですが、来年はダッシュボードをめちゃめちゃ強化して(か他にいい方法を考えて)本選に行くぞ！！！！！！！！！！！！