追記事項メモ
2016/12/19 : Shrink Index APIの使いみちに関して追記
はじめに
12/15に開催されたElastic {ON} Tour 2016 東京に参加しました。サンフランシスコで開催されているカンファレンスのサテライトのようなイベントで、世界中の各都市を回って開催されています。日本での開催は去年に続いて2回目となります。
去年も参加しましたのでどんな感じに変わったのかも絡めつつ、アジェンダに沿ってレポートしてみようと思います。
なお、ユーザ事例については省略します。思ったより分量が多くなったのと、写真撮影、録音、録画がNGというユースケースもあったためです。
1. 早朝トレーニング
参加登録時点で既に満席だったためこれは参加できませんでした。後から動画が公開されるとのことです。
2. 受付、ネットワーキング、AMA (Ask Me Anything)
会場の印象や冒頭の司会進行で触れられていたことで注目ポイントは3つ。
机がなくなった
会場自体は去年と同じ場所ですが、去年は椅子と机があったのが今年は椅子だけになっていました。その分増えた席数は全部で350ほどで、参加登録数は去年の2倍だったそうです。参加者の半分くらいは去年も参加していたようで、つまり去年の参加者は大半が今年も参加していたということになります。2回目の開催ではありますがイベント自体のリピート率は相当高いようです。
AMAに通訳が付いた
AMAブースには日本語話者のエンジニアが待機していたのは同じですが、今年は通訳の方も控えていたそうです。参加者自体が増えたこともあり去年より盛況だったように思います。
冒頭に流れる紹介動画が新しくなっていた
少し前まで「セクシーサーチ」って話が出てくる動画を各所で流していたように思うのですが、新しくなっていました。
3. ELKからElastic Stackへ
若干曖昧ですが、今年の春のElastic{ON}でElastic Stackとしての統合、そして「5系」が発表されたと記憶しています。気になった話をいくつかピックアップします。
関連プロダクトのDL数は7500万
Elastic{ON}(2016年3月)時点で5000万くらいという資料が出ていたはずです。なので相変わらず順調に伸びているようです。
Prelertとの提携
教師無し学習による異常検知のシステムを扱う会社で、今年の9月に提携が発表されていました。個人的にはこれが今回のカンファレンスの目玉だったと思っています。個別のセッションもあったので詳細は後述。
Elastic Stackへの統合とバージョン番号の統一について
たくさんのプロダクトのバージョンの対応関係が複雑化してわかりにくいので統一した、という話。確かに「Elaticsearch 2.xに対応するKibanaのバージョンは？」とか聞かれてもすぐに答えられないですね。リリース日も揃うので、各プロダクトごとの変更点を同じ日にまとめて確認すれば良いというのも地味に利点かなと思っています。
こんなかんじで丸ごとリリースが告知されます。
数字の話
「検索もしくは分析の用途が60%以上」
思ったより低い印象です。それ以外だとアラートやDBとしての用途でしょうか。
「ログ処理関連が40%以上」
これも少ない印象です。
「セキュリティ系用途は年に200%のペースで成長している」
これはなんとなく感じていました。1年ほど前からセキュリティに関するユースケースを目にすることが多くなった気がします。Prelertとの提携も追い風になるはずです。
「複数の用途に使っているケースが75%以上」
これもそうだろうな、という感想です。学習コストは依然としてそれなりに高く、使えるようになったからにはあちこち使ったほうがお得というのもあります。
「クラウド事業の成長はこの1年で250%」
Elastic CloudおよびElastic Cloud Enterpriseのことですね。
4. Elasticsearch 5.0: 知っておくべきこと
ここからは各プロダクトの話です。それぞれ気になったことをピックアップしていきます。
Rollover api
時系列データを自動でindex分割してくれる機能。すぐに名前が出てきませんが以前は似た機能のpluginがあったと思います。
そもそもindexの扱いとして、ログ等の日々増加していくデータに関しては1つのindexに延々貯めていくのではなく、適度な量で分割するのが良いやり方だと思います。たしかmarvelのindexも日毎に分割されています。
一定期間で過去のdocumentを削除するような運用で効果的です。さもないとdelete by queryのようなものを使うことになり、経験上それは結構怖いことです。ついでに言うと、いくらスケーラブルだからといって時間が経つにつれて際限なくデータが増えていくような運用はそれ自体オススメできません。
Shrink Index API
初めて名前が出てきたのは前回のElastic{ON}(本体かTour 東京)だったと思います。既存indexのshard数を元の約数に減らすAPIのようです。例えば15 shardのindexを5 shardにするなど。
shard数の変更はReindex APIでも実現できそうではあります(約数という縛りもないし、増やすこともできる)。また、Elasticsearchの分散処理の単位はshardであることがほとんどなので、潜在的なスケーラビリティが低下するということでもあります(大雑把に言うと、15shardなら最大15nodeで分散所理ができるが、5shardにしてしまうと5nodeまでしか分散できない)。
というわけで、今の所は「1つ1つが小さすぎて分散のオーバーヘッドのほうが大きい」shardを最適化するというような使い方をイメージしています。最初から適切なshard数を設定できていればそんなことは不要なんですが、index数やshard数は「ケースバイケース」の要素が強く特に設計が難しいポイントです。逆に、最初はある程度適当でもいいやと割り切れるようになるのは素早い開発と検証のサイクルを回すスタイルには強い味方になるはずです。
(2016/12/19追記)
時系列データなど「鮮度」によって参照頻度が変わるデータというのがあるわけですが、「参照頻度が落ちてきたが削除するにはまだ早い」というような段階においてshard数を減らすというのは十分に考慮に値する最適化だと思い始めました。
例えば高性能なSSDのnodeが6台と大容量のHDDのnodeが2つのヘテロなクラスタを構成し、新しいデータは6 shardsでSSDのnodeに配置、古くなってきたら2 shardsに減らしてHDDのnodeに移動するなど。
Wait for Refresh
これはまだ機能がよくわかっていません。聞き逃したかも。
私が面倒見ているclusterでは現時点でも運用上、明示的にRefresh APIをあちこちで発行しています。その辺りを意識しなくて良くなるのかなぁ。
Ingest Node
Elasticsearchへのデータ投入を担う新しい種類のnodeです。BeatsやLogstashと合わせて使うことになるようです。
これに関してちょっと気にかかっているのはデータ投入先cluserと一体になるというアーキテクチャです。投入先clusterの障害発生時に共倒れしないかどうか、つまりElasticsearchの手前にRedisやKafkaを挟むことでデータロスを回避するような用途を代替できるのか、という懸念。
まあうちはそんな高度な使い方してないですが
Keyword datatype
これまで文字列を扱うfieldはstring型でしたが、今後はkeywordとtextの2種類の型になります。
keywordはstatus codeやhostname、usernameなどの「完全一致での検索、ソート、aggregationに使う」ための文字列型です。うまく説明するのが難しいのですが、「IDに変換可能な文字列」、これまでであればnot_analyzedを指定して使っていたような種類の文字列に適しています。
textはメールの本文やブログ記事の本文などのフリーテキストのための文字列型です。kuromoji-analyzerなどを使って形態素解析をして使っていたような文字列に使うことになるでしょう。
これは「analyzerを適用したstring(doc_valuesを使えない)に対してaggregationやソートを使ってしまいメモリを食い尽くす」というよくある悲劇を回避するための変更だと思います。
5. Kibana 5: Elastic Stackへの入り口
Timelion
以前は公式には「タイムライン」と呼んでいた気がしますが、いつの間にか「タイムライオン」に変わっていました。visualizeに比べて柔軟に表現を調整できるとのこと。
DevTool
consoleとprofilerというタブが並んでいました。consoleはsenseと呼ばれていた機能、profilterはSQLの実行計画のようなものだそうです。
各プロダクトの統合UIという側面について
xpackに含まれるプロダクトを筆頭に、様々な機能をkibanaのUIから操作できるようになっています。kibanaを触る人もシステムエンジニアや分析担当者など多岐にわたるようになってくるので、shieldによる権限周りの制御がこれまで以上に重要になりそうです。
6. データの投入: BeatsとLogstash
BeatsとLogstash
beatsはシンプルで軽量、logstashは機能がリッチ、という関係で両立していくようです。
Ingest Node
前述の通り、clusterの一部としてデータの中間処理などを担う新しいnodeです。
Logstash Monitoring API
logstash自体の状況を監視する仕組み。正直あまり意識したことがなかったです。
7. X-Pack: Elastic Stackを拡張する
各プロダクトの様々な拡張機能をまとめたものがxpackです。
report
ダッシュボードの情報をpdfで共有するための機能。今後pngなどの形式もサポートする方針とのこと。シンプルながら実運用では使う場面が必ずあると思います。
graph
個人的に前回のElastic{ON}で一番目を引いたのはこれでした。データごとの関係性を可視化する新しいUIで、グラフがうねうね動きながら動的に描かれていくのが楽しいです。
これを使うにはプラチナライセンスが必要なんですが、例によって14日くらいお試しができます。しかし前回Elastic{ON}の直後、試用ライセンスでちょっと触ってからベーシックライセンスにアップグレードしたことでその後試用ができなくなり、実はあまり触ってません。
monitoring
デモでちらっと見えましたがelaticsearchだけでなくkibanaのoverviewもありました。間も無くlogstashのmonitoringも仲間入りとのこと。
8. Elastic Stackを利用した異常検知
個人的に今回一番の目玉。会場内でもカメラのフラッシュが一番多かったのはこのセッションでした。search、aggregation、visualizeにmachine learningが加わり「教師なし学習による異常検知」が可能になります。
KibanaのUIからポチポチするだけで既存データを元に正常時のモデルを作成し、そこから外れた異常値を検知するという仕組み。機械学習やデータ解析の知識がなくても使えるものだと思います。
来年春頃にリリース予定で、プラチナライセンスのラインナップに追加されるとのこと。現在prelertのHPから14日の試用ができるそうです。
機械学習やAI自体の流行もあり、かなりのキラーアプリになると予想してます。
おわりに
全体的に去年よりも熱気が強まったと感じました。
単に参加人数という意味でも、来年はもっと広い場所が必要になるんじゃないでしょうか。