Elasticsearch, the server
2010年の前半、Elasticsearchがリリースされた時、未来(私たちが確信していた)はオレンジでした。もしくは黒?緑?それは誰も知らないことでした。また、NoSQLの分野がどのようになり、Elasticsearchがどのように使われるか誰も知りませんでした。
当時、全てのレースに出ることができる馬になろうとしていました。 Elasticsearchに対してJSON、YAML、SMILE、CBOR、Thrift、Memcachedプロトコルで通信できました。また、設定については、JSON、YAML、Java properties、環境変数を使えました。 LogはLog4JとSLF4Jでした。マッピングを設定する方法も3種類ありました。 templateやanalyzerもあります。また、Elasticsearchはスタンドアローンでも組み込みでも実行できました。HTTP WebサーバもElasticsearchのクラスタに実際のノードとしてジョインさせることもできました。プラグインはElasticsearchのほぼどんな機能でもオーバーライドでき、コアの一部も置き換えできました。
Elasticsearchが人気が出た理由の1つがこの柔軟性と扱いやすさでした。 簡単に開始でき、アプリケーションに組み込むことが簡単にできました、普通ではないデザインであったとしても。
6年後、Elasticsearchはパワフルな検索、解析エンジンとなりました。数百万の人々にダウンロードされ、何十万というユーザや企業によって利用されるコアテクノロジーとなりました。 柔軟性や寛容さはもはや次のものよりも重要ではありません。
- 信頼性のある安定したクラスタ
- 予測可能な性能
- 明確なエラーメッセージ
- プロダクションで発生するであろう問題の早期検知
- 攻撃に対する安全
柔軟性はかなりの犠牲があります。複雑性です。多くの代替手段に対して、それら全てをテストし実際に動作するかを確認するのは困難です。複雑性は先ほどの目標を妨げます。全てを持つことはできないので、信頼できる手段を提供するために注力する部分を絞る必要があります。
Elasticsearchはスタンドアローンのサーバとして実行でき、他のアプリ系ションはクライアント経由で通信するべきです。これにより、Elasticsearchを安全にでき、危険な方法で実行することを防ぐことができます。
bootstrap処理の一部として、Java Security Managerを使っています。これにより、必要最低限のモジュールに対してだけに特権を制限しています。 また、Linuxでは<a href="https://github.com/elastic/elasticsearch/pull/13753">seccomp</a>
を使い、アプリケーションをサンドボックス化しています。さらに、JAR Hellで、クラスパスにあるライブラリのバージョンが1つしかないことをチェックしています。 — あなたでさえ気づいていない、不正確なバージョンのライブラリを使うことによる問題をデバッグできるように。
version 5.0で、bootstrap checks も追加しました。これは、ヒープサイズや十分なファイルデスクリプタ、十分な仮想メモリが設定されていることを確認する機能です。 — プロダクション環境でよく見てきた、一般的なエラーです。これらのチェックはdevelopment modeではwarningとしてログに出力されますが、production mode(localhost以外にバインドした場合)に切り替えるとエラーとなります。このチェックがみなさんを守ってくれます。
さらにcircuit breakerを追加しました。 多くのリクエストの実行やaggregations 組み合わせ爆発によって多くのバケットを生成するようなaggrecationからクラスタを保護します。 また、soft limitsにより10億件もヒットするようなクエリを実行したり、analyzedな string fieldに対してコストのかかるAggregationを実行したり、IP addressesをフィールド名にしてマッピングが巨大になるようにしたり、パラメータ化されていないスクリプトを実行したりするユーザからシステム管理者を守ります。
代替案を減らしています。現在は設定に使えるのはYAMLだけですし、ロギングにはLog4j(もうすぐLog4j2)だけです。インデックスの設定やマッピング、アナライザの設定はファイルシステムや設定ファイル経由で設定できません。 — 現在はインデックス作成時もしくはインデックステンプレートで設定する必要があります。間違った設定は無視されなくなりました。 — もし問題がある設定があった場合、エラーを通知するだけでなく、 正しい設定を推奨するためにファジーマッチングを使っています。この変更によって、最終的に打ち間違いであるというのがわかるまでのデバッグの無駄な時間の浪費から開発者を救ってくれます。
コードベースをクリーンアップする一部として、より安定したインターフェースやクリーンアップする目的でplugin APIを公式化し、この過程でGuiceを完全に排除するために、徐々に依存を減らしています。また、コア機能をユーザによって外部にさらすことを防ぐために、プラグインのスコープも制限しています。いくつかのもの(Luceneのディレクトリやシャードのルーティングなど)はアクセスするにはあまりにも繊細なものです。もしどうしても内部に手を入れたい場合はElasticsearchをフォークしてください。もし、すでにあるものよりも良いものができた場合には、ぜひプルリクエストを送ってください。
これまでは、Javaを除くすべてのプログラミング言語はElasticsearchに対してHTTP clientsでアクセスします。 Elasticsearch 5.0では、Java HTTP clientの最初のバージョンをリリースします。現時点では、clientは本当に基本的な部分だけです。IDEやアプリケーションなどで使いやすくするためのAPIを追加しますが、 clientはすでにv2とv5の両方を利用することができます。HTTP clientのパフォーマンスを見ることができるBenchmarksがTransport clientと同じように存在します。HTTP clientが十分に利用できるようになった時、Java transport clientを非推奨にし、その後削除するでしょう。すべての外部とのコミュニケーションはHTTPで行うことで、Elasticsearchのクラスタと外部との境界線を明確にすることが簡単になります。
あるユーザはElasticsearchを組み込み(embedded)として実行しています。私たちはこの方法を止めようとはしませんが、サポートはできません。Embedding Elasticsearchはセキュリティマネージャや、Jar Hellチェック、プラグインの読み込みをバイパスします。それはそもそも危険なため本番では推奨しません。私たち開発者とサポートチームの正気のためにも、私たちが安全のために組み込んだ機能をすべて使用しないようにするユーザをサポートできません。同様の理由で、組み込みのユースケースをサポートするための特殊な変更やプルリクエストも受け付けません。
これらの変更により、Elasticsearchのこれらの機能を頼りにしてきたユーザに対して影響を与えることをわかっています、そして申し訳なく思っています。これらの目的はユーザの人生を難しものにするためではなく、より良く、より合理化し、よりユーザが頼ることができる安定した製品となるようにするためのものです。