Elasticsearchのこれから
大谷純氏（以下、大谷）：よろしくお願いします。まず、6.1と書いていますが、6.X系の話をさせていただきます。現状、6.1が最新なので、6.1と書いています。
自己紹介です。
ふだんはあんな髪形をしていますが、冬は面倒で髪を切っていなくて、今日は酷い頭になっていますが、すみません。元々エヴァンジェリストというのがいいのか、Developer Advocate と名乗るのが良いのか、よくわからないのですが、最近はDeveloper Advocate と名乗るようにしようかなと思っています。
私はもともと検索の人間です。そのため、ログのお話が実は少し苦手です。このような本も書いていますので、興味ある方はぜひ読んでいただければと思います。
会社の説明……、知らない方いますか？ さすがにいいですかね。オープンソースをやっています。今日はうちの人間も何人か来てます。サポートのエンジニアも何名か来ていますので、興味があれば懇親会に……残るよね？（笑） 残って話を聞いていただければ面白いかなと思います。
さて、質問です。まだ、1系を使用している方はいますか？ さすがにいないですね、良かったです。では2系……、1名いらっしゃいますね。5系の方、さっき5系でしたねみなさん。だいたい5系ですか。では6系の方、ああ、少ないですね（笑）。
ちょうどよかったです、今日お話聞いて帰っていただいて、6系に更新していただければという算段のスライドになっています。
4つのオープンソースですね、Elasticsearch、Kibana、Logstash、Beatsの順でお話をさせていただきます。
Elasticsearch6.x系の変更点
まず6系のなにが嬉しいか、というところですね。みなさん5系のようでしたので、ぜひ6系に更新していただいて、ハッピーな感じになっていただければなと思っています。昔話をしますと、2系のアップデートはとても辛かったです。
自分でリリースのchangesを見ていただいて、自分のアプリとどう違うのかを見比べていただきながら、アプリ側を書き換えてから、アップグレートするというかたちですね。なので結構大変です。思ったように動かないことが時々あります。
5系になって大きく楽になっており、クラスタ側に設定のチェックが入るようになりました。2系も実施していましたが、クラスタの中にあるIndexをチェックして、次のメジャーバージョンで使用できなくなる設定に関してはエラーが出るようヘルパーを用意しました。そのため、対応が楽になりました。
かつ、クライアント側から渡されるクエリなど、サーバーの設定を確認してもクエリがどのような内容が渡されるかによって、5系、6系での使用可否もチェックを行い、次のバージョンで利用できなくなる機能に関してはログを出力する機能を5系から用意しました。
デプリケーションログ（Deprecation Log）と呼ばれる機能となりますが、こちらを利用していただけると、古いクエリがあったとしても、次のバージョンで該当のクエリがあれば、「こちらを使用してください」または「別の対応法を採用してください」ということがログに出力されますので、ログを確認することでアップデートが楽になります。
また、5系の最新版から6系に関してはフルクラスタリスタートが不要になりました。今まではメジャーバージョンのアップグレードをする場合には、サービスをすべて止めていただいて、サービスのバージョンを更新してからクラスタを起動することが必要でした。
マイナーバージョンに関しては、1台ずつアップデートすることでクラスタを停止する必要はありませんでしたが、メジャーバージョンのアップデートではできなかった。このアップデートが6系からは可能になりました。そのため、5.6から6.0に更新する場合は、サービスを完全に止める必要はなく、順番にアップデートすることが可能になります。
アップデートする際に活用していただきたいのが、こちらのUIになります。Kibana上に搭載しており、X-Packというプラグインが使われているので、ライセンスの登録が必要になりますが、そちらをインストールいただくと使用できるようになります。
先ほどお話をしたDeprecation Logの設定を管理する画面もありますが、クラスタチェックアップという機能を使用していただけると、現在使用されているIndexの設定、クラスタの設定で6のバージョンで使用できなくなる設定がある場合には、ログに明示されるようになります。
この機能を導入いただいて、現状のクラスタの設定の確認と、バージョンアップデートが可能かどうかを確認してください。もう1点便利な機能が、問題があるIndexの設定があった場合、そのIndexを内部でリインデックスしていただく必要があります。
マッピングや、6系になり使用できなくなる機能を画面で確認できるようになっています。現状、5.6を使用されている方は、こちらの機能を活用することができます。
Indexサイズが小さくなり性能が向上
ここから先は、6系の良いところの話となります。6系では、Indexのサイズは小さくなっており、効率良くデータを持つように改善が入っています。
特に、ログを監視されている方にはかなり有効に使用できる機能になっており、Indexのサイズが小さくなり性能が向上すると考えています。
データが必ず入っているデータには大きな性能変化はありませんが、疎なデータ、各カラムに対してデータがそれほど入っていない場合、例えば、複数のサービスのログを一か所にまとめてあるような場合、今回のデータの持ち方の改善によってデータサイズが小さくなるため、ディスクアクセスも少なくなり、検索速度も向上する、ということになります。そのため、6系にバージョンアップするだけで、Indexの性能が向上します。
もう1つは、Index sorting という機能を用意しました。
Elasticsearchは元々、検索時に必ずソートを実施する処理がありましたが、Iindexの処理を重くする代わりに、検索処理が早くなるという機能が追加されました。あらかじめ、ソートをしながらデータを投入する仕組みとなります。
この仕組みはあくまでもソートする項目が決まっている場合に有効になります。サンプルで言うと、トップスコア、トップ10のユーザーを表示するような場合に効果的な改善になります。
続いてが、信頼性を向上させています。
先ほど、リカバリーに時間がかかるお話がありましたが、6系からはリカバリーの時間も短縮するような仕組みが内部で導入されました。内部処理では、データの投入、データの更新時のリクエストを受ける都度、リクエストに対してシーケンシャルなIDを採番するようになりました。
そのため、このシーケンシャルなIDを採番することで操作の順序が保証されるようになるため、どこまで操作が完了しているかなどが自明になるため、リカバリー時に簡単に後追いができる仕組みが導入されました。そのため、利便性を向上させつつ、リカバリー時の性能が良くなる形になっており、こちらは今後も改善が行われていく予定ですので、楽しみにしていてください。
typeが段階的になくなる
続いて、Breaking changesです。
まだ、Elasticsearchは活発に開発をしています、先ほども5系の設定であり6系でどうなるかわかりません、という点ありましたが、かなりアグレッシブに変更してしまいます、すみません。
先ほど紹介しましたこの辺の仕組みを使っていただいて、現状、どのように設定が変わるのかなという点を見ていただくことが重要となります。あとは必ずテストをお願いをしています。特にクライアントサイドのアプリケーションに関して使えないパラメーターになっていないかなど確認をお願いします。
あと、気を付けていただかなければいけないのが、今までElasticsearchはindex, type, documentというデータの持ち方をしていましたが、typeがなくなります。これは6から始まっており、typeを複数持てなくなっています。5系のindexは問題ありませんが、6系からは段階的に無くしていきますので、非推奨としていきます。6系で使えなくなり7系で削除、8系以降で徐々に他項目も削除していきます。
そのため、typeに関しては、今後新たにElasticsearchを導入していく方は、typeはないものとして扱っていただくのが良いと思います。
その他、細かい話がいくつかあります。先ほど紹介のあったindex templateのパラメーターが少し変更されています。templateというパラメーターが、index patternという名称に変更されています。
続いて、content typeですが、httpでElasticsearchにアクセスする場合、content typeが必須となります。jsonを送信していることを明示しないとcurlコマンドなどで正しくデータが取得できずにエラーが返却されることがあります。
Kibanaなどを利用している場合には気にする必要はありませんが、curlコマンドを使用する場合には問題になる場合があるので注意が必要です。Kibana関連で特に気にされる部分が、_allの箇所と思います。_allはなんでも検索できるフィールドが存在していましたが、6系ではなくなりました。今まで、_allに対して検索を行っていた方はご注意ください。
新たなライブラリが登場
あと、先ほど紹介のあったHigh Level REST Clientというものができます。そのため、Javaでアプリケーションを実装してElasticsearchに接続する方は、今後はこちらのライブラリを使用してください。
現状は、検索系の処理だけのAPIが用意されています。GitHubのissue上で必要なAPIのリクエストページが用意されていますので、必要と感じるAPIがあれば、issueをあげていただければ実装される、という形になると思います。
このライブラリを利用するとなにが便利かというと、今まではElasticsearchのサーバーのバージョンとクライアントライブラリのバージョンが完全に一致しないと接続ができませんでした。
ただ、httpのRESTクライアントを使っていただくとElasticsearchのクライアントのライブラリのバージョンとサーバーのバージョンがミスマッチでもそれほど影響が出なくなるという利点があります。そのため、サーバーのみ先にアップデートして、その後、クライアントアプリ側を調整することができるようになりますので、今後はこの形を活用していただけるのがおすすめになっていきます。
X-Packを使っている人、いないですよね。
一応、Alertingという機能がありまして、それが分散で1つできる仕組みができました、という点と、セキュリティを気を付けています、という点をお話します。
Elasticsearch内部のクラスタでセキュアな通信経路を確保したい場合は、この点が重要になっています、ということを書いています。
