いよいよ2月も終わって3月になりましたが、皆さんいかがお過ごしでしょうか。
こちらサンフランシスコも先ほど日付が変わって3月となり、サンガツフランシスコ！！ ・・・みたいな感じのボケも考えたのですが、どうにも滑りが悪いですね、@cero_t です。
Elastic{ON}では、今日から通常セッションが始まりました。
今日参加したセッション
私が本日参加したセッションは次の通りです。
- Watching Overwatch at Activision Blizzard
- オンラインゲーム「オーバーウォッチ」で、サーバ運用にElasticsearchを活用した事例
- ツイートまとめ: https://twitter.com/hashtag/ecjp_overwatch?f=tweets
- Guide to Finding a Doctor in Spanish
- 医者と患者のマッチングサイトで、英語とスペイン語が混ざった検索を行った事例
- ツイートまとめ: https://twitter.com/hashtag/ec_doctor?f=tweets
- Reliable by Design
- TLA+やIsablle/HOLを使い、分散システムのモデルを数学的に検証する
- ツイートまとめ: https://twitter.com/hashtag/ec_design?f=tweets
- BoF: Custom Kibana Graphs with Vega
- Vegaを使ってKibanaのVisualizationを自作する
- BoF: Ingesting Data From Oracle Databases
- OracleのデータをElasticsearchに投入する方法
- ツイートまとめ: https://twitter.com/hashtag/ec_oracle?f=tweets
- Visualizing Content Performance with Elastic at Canadian Broadcasting Corporation (CBC)
- カナダの放送局CBCで、パフォーマンスを可視化した事例
- Ask Me Anything
- 検索スコアのboostについて
- Parent Childについて
ユーザー事例やニッチめの話など、なかなか他では聞けない話を中心に聞いて回りました。この中でも特に印象深かった「オーバーウォッチの話」と「Ask Me Anything」について、詳しくレポートします。
オーバーウォッチ運用チームの、KPI収集と改善活動を垣間見た
Blizzard社のオンラインゲーム「オーバーウォッチ」の運用チームが、どのようにゲームサーバのモニタリングをしているかなど紹介するセッションです。
Blizzardと言えばDiabloシリーズやWarcraftシリーズ、最近ではカードゲームのハースストーンなどでも有名です。学生時代、Diabloに手を出したがばかりにオンラインゲーム沼にハマってしまった私としては、このセッションは見逃せませんでした。
ツイートまとめ: https://twitter.com/hashtag/ecjp_overwatch?f=tweets
オーバーウォッチの運用チームは、サーバのメトリクス情報やサービスの状態をsyslogやbrubeck (https://github.com/github/brubeck) などで収集し、それをKafka経由でElasticsearch / Cassandra / HDFSに保存しています。
Elasticsearchには直近の1週間分のデータのみ保存し、それより過去のデータはHDFSに保存しているとのこと。私も過去の案件で同じようなことをやったので、このあたりはだいぶ共感できます。
またBEAMSという自作ツールで、収集したデータからアラートなどを飛ばす仕組みも作っていました。
BEAMSは、データの加工やルールの定義、アラートの内容などをブラウザから簡単に設定できるシステムのようですね。
ちょうど、Logstash + Watcherをまとめたような位置づけでしょうか。
さて、面白いのは、ここからです。
このようなデータプラットフォームを整備したことで、オーバーウォッチの運用チームは様々な情報を可視化・分析できるようになりました。その一例が、ゲームプレイ中の切断です。どの時間に、どれぐらいの頻度で、どの地域で切断が起きているかなどを可視化することで、サーバ障害やその影響範囲などを探ることができます。
このような可視化やアラートを整備することで、オーバーウォッチの運用チームは2017年に起きた134の大きめの障害のうち、78%をアラートで気づくことができたそうです。また障害のうち30%は、モニタリングの改善にフィードバックすることもできました。
この数字がキッチリ出てくるところが、良いですよね。
システムの運用中に発生する障害は、必ずしもリアルタイムに検知できるわけではなく、時にはお客様からの連絡やクレームで初めて気づくことだってあります。ただその際に、どうすればリアルタイムに検知できるのかを考えて運用にフィードバックするという改善活動を行い、またリアルタイムに検知できた/できなかった件数をKPIとして計測することで、改善の効果を確認することができます。このような活動が、オンラインゲームのように難しいシステムを安定稼働させるうえで欠かせなかったのだと思います。
そんなのはSREの人にとっては当たり前のこと（SRE本などにも書いてあること？）なのかも知れませんが、私にとってはすごく良い知見になりました。面白かったです！
やっぱりAMAは最高だな！
Elastic{ON}名物のAsk Me Anythingブース、通称AMA。
このブースは、Elasticsearchの開発者やサポートチームに直接質問をすることができるもので、言い換えればElasticsearchのコンサル（すごくお値段が高いんだヨ！）を無料で受けられるようなコーナーです。
そんなわけで人気があり、どうしても休憩時間などは大変な混雑になってしまいます。そこでいくつかのセッションをキャンセルし、セッション時間中にAMAブースに立ち寄ることにしました。正味、セッションに出るよりもコスパが良いと思うんですよね。
さて、AMAブースで聞いた1つめの質問が、Elasticsearchの検索スコアを調整する「boost」をどのように利用するべきかという話。機能ではなく、いかに利用して運用していくかという質問です。
このようなオープンクエスチョンに対しても、開発者自身の経験や見聞きしたユースケースなどから、取りうる戦略をアドバイスしてもらいました。またElasticsearch 6.2で実験的に導入された機能も使える可能性があるなど、見落としていた新機能なども教えてもらうことができました。
もう一つ質問したのが、ElasticsearchでRDBMSのような親子関係を扱うための「parent-child relationship」の話。この機能は5.xを最後にdeprecatedになり、6.xからはjoin datatypeを使うことが推奨されています。ただその互換性や将来性に疑問があったため、この機能の開発者（！）に直接質問をぶつけてみました。
この機能の将来性や、この機能とElasticsearch SQLの関係性など、いくつか話を重ねた後で、ふと「SQLのhavingに相当するクエリって、Elasticsearchで実現する方法ないですよね」と聞いたところ、「裏技だけど、あるよ」と言って教えてくれました。私的にはこの裏技が本日最大の衝撃でした。細かすぎて伝わらない内容ですがｗ
こちらはまた日本に帰ってから試してみたいと思います。
・・・という感じで、質問する側にもそれなりの知識や問題意識が必要になるとは言え、これぐらい深めの話を聞けるのが、AMAブースの特徴です。そもそも開発者と1対1と話せること自体、かなり豪華ですよね。本当に貴重な機会ですし、こう言いうのも何ですが、すごく効率がよくてありがたいです！
