Elasticsearch 7.7では、以前のバージョンに比べてヒープ領域の使用量が大きく減少します。この進化はElasticsearchクラスターの安定性を高め、大きなサイズのデータを格納する際のコスト抑制に貢献します。

<p>Elasticsearchユーザーなら、1つのElasticsearchノードに格納できるデータ量の上限を押し上げるべく奮闘したことがあるかもしれません。その結果、ディスク容量が一杯になる以前にヒープ領域が不足することもあります。これは、ユーザーにとって頭の痛い問題です。<a href="/jp/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster">1ノードあたりに割り当てるデータを可能な限り多くする</a>ことがコスト削減に有効であるケースが少なくないためです。
</p><p>しかしそもそも、なぜElasticsearchはデータを格納するためにヒープ領域を必要とするのでしょうか。なぜディスク容量だけでは不十分なのでしょうか。これには複数の理由がありますが、最大の理由はLuceneがメモリに一部の情報を格納することにより、ディスクのどこを参照するか判断するためです。たとえばLuceneの転置インデックスは、用語をソート順にグループにわけて作ったブロック状の“用語ディクショナリー”と、用語ディクショナリーをすばやく参照するための“用語インデックス”で構成されています。この用語インデックスは用語の接頭辞をディスクのオフセットにマップし、そこにその接頭辞で始まる用語を含むブロックが作成されます。この用語ディクショナリーはディスク上にありますが、用語インデックスの方はつい最近までヒープ領域に置かれていました。
</p><p>実際、インデックスに必要なメモリサイズはどれくらいでしょうか？通常は、インデックス1GBあたり数MB程度です。それほど大きいわけではありません。しかし、ノードに何テラバイトものディスクを装着した結果、数テラバイト分のインデックスの格納に占めるヒープ領域が10GBや10GBに達するケースも散見されます。Elasticはヒープを30GB未満に保つことを推奨していますが、その場合、アグリゲーションなどに消費するヒープ領域は少なくなります。また、JVMに十分なクラスター管理オペレーションの余地がない場合、安定性の問題にもつながります。
</p><p>いくつか、実践的な数値を検討してみましょう。Elasticは複数のデータセットで<a href="https://benchmarks.elastic.co">ナイトリーベンチマーク</a>を実行し、さまざまなメトリック、特にセグメントでのメモリ使用量を長時間にわたって追跡しています。そこで興味深い結果を示したのが、<a href="https://www.geonames.org/">Geonames</a>データセットです。<a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/geonames/nightly/default/6M">Elasticsearch 7.xで導入された変更による影響を、明確に示して</a>います。
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb41b157438550179/5ea2ddf2ae23d30cd1dfb100/heap-reduction-7-7-nightly-geonames-blog.png" data-sys-asset-uid="bltb41b157438550179" alt="Geonamesデータセットのナイトリーベンチマーク" style="display: block; margin: auto;">
</p><p>このインデックスはディスク上で3GBを占め、6か月前は最大5.2MBのメモリを必要としていました。このヒープストレージ比は～1：600です。仮に各ノードに装着したディスクサイズの合計が10TBであれば、必要なヒープは10 TB ÷ 600 = 17GBとなり、Geonamesのようなデータを格納するインデックスをぎりぎり開くことができます。しかしグラフを見ると、時間とともに値が良くなっています。青の“points”が必要とするメモリ量が減り、次にピンクの“terms”、緑の“stored fields”、最後に再び“terms”の値が大きく下がっています。最終的にヒープストレージ比は～1：4000になり、6.xや7.xの初期リリースと比較しておよそ7倍近く向上しています。つまり、10TBのインデックスを開くために必要なヒープ領域はわずか2.5GBになります。
</p><p>どの程度向上するかはデータセットによって<strong>大きく</strong>異なりますが、ここで嬉しいお知らせがあります。実はGeonamesはヒープ使用量の減少率を最も緩やかに示したデータセットの1つで、使用量は最大で7分の1に下がりました。他方、<a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/nyc-taxis/nightly/default/6M">NYC taxis</a>および<a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/http-logs/nightly/default/6M">HTTP logs</a>データセットでは、100分の1以下にまで使用量が下がっています。冒頭でも触れたように、この進化に伴い、Elasticsearchの以前のバージョンに比べて1ノードあたりに格納できるデータが増えれば、コスト削減に貢献します。
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7c2002e630ac3974/5ea2de1f52608c261aab78aa/heap-reduction-7-7-nightly-taxis-blog.png" data-sys-asset-uid="blt7c2002e630ac3974" alt="NYCタクシーのナイトリーベンチマーク" style="display: block; margin: auto;">
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb15c6244ebc49571/5ea2de6952608c261aab78b0/heap-reduction-7-7-nightly-http-logs-blog.png" data-sys-asset-uid="bltb15c6244ebc49571" alt="HTTPログデータセットのナイトリーベンチマーク" style="display: block; margin: auto;">
</p><p>さて、どういう仕組みでこのような進化が起きたのでしょうか。何かデメリットを伴っているといったことはないのでしょうか？これと同じ変更は、Luceneインデックスの複数のコンポーネントに段階的に適用されてきました。すなわち、JVMヒープからディスクにデータストラクチャーを移行し、ファイルシステムキャッシュに依存する（ページキャッシュ、あるいはOSキャッシュとも呼ばれます）ことで使えるメモリの容量を残すという変更です。一見するとまだメモリは使用され、別のどこかに割り当てられているように思えますが、実際、ユースケースによってはメモリの大部分が一切使われなくなります。たとえば最後に<code>Terms</code>が大きく下がったのは、<code>_id</code>フィールドの用語インデックスをディスクに移動したためです。このフィールドはGET APIを使うとき、あるいは明白なIDでドキュメントをインデックスする場合しか役立ちません。Elasticsearchにログやメトリックをインデックスするユーザーの大多数は、こうした操作を一度も行いません。つまり、純粋にメリットだけをもたらす進化ということになります。
</p><h2>7.7で、Elasticsearchのヒープ使用量が下がる！</h2><p>Elasticsearch 7.7より導入されるこの変更は私たちにとって非常にエキサイティングなものであり、ユーザーの皆さんにもそのように感じていただけましたら幸いです。ぜひ今後のリリース発表をチェックして、実際にお試しいただきたいと思います。現在お使いのデプロイでお試しいただくことも、Elastic CloudのElasticsearch Service（いつでも最新バージョンのElasticsearchが提供されます）で<a href="/jp/elasticsearch/service">無料のトライアルを立ち上げる</a>こともできます。また、Elasticは皆さまからのフィードバックをお待ちしています。ぜひご意見を<a href="https://discuss.elastic.co/">ディスカッションフォーラム</a>にお寄せください。
</p>

blog-banner-release-elasticsearch.png

blog-thumb-release-elasticsearch.png

Coming in 7.7: Significantly decrease your Elasticsearch heap memory usage

7.7がもたらす進化 - Elasticsearchのヒープ領域使用量が大幅ダウン

Elasticsearch 7.0はタイプを受け入れるAPIを廃止し、新たにタイプレスAPIを導入するほか、_default_マッピングをサポート対象外とします。

<p>Elasticではバージョン5.0よりElasticsearchのタイプ廃止に向けて取り組んできました。そして7.0より、タイプは完全に廃止されます。タイプはこれまで単インデックス内でマルチテナンシーを実現する目的で設けられていましたが、Luceneとの互換性がありませんでした。このため、メリットを上回る数々の問題を生じさせている事実が明らかになっていました。&nbsp;いくつかの回避策（たとえばタイプごとに固有のフィールドを使用するとか、内部では1つのタイプに対し1つのインデックスしか持たせないなど）も長く議論されてきましたが、最終的にタイプへのサポート自体を廃止するという結論に至りました。ユーザーが移行作業をスムーズに行えるよう、この変更は4つのメジャーバージョンで段階的に提供されます。
</p>
<ul>
	<li>5.0は、複数のタイプにわたって同じ名前を共有するフィールド同士に対し、強制的に互換性マッピングを持たせます。</li>
	<li>6.0では複数のタイプを備える新規のインデックスを作成できなくなり、<code>_default_</code>マッピングが廃止されます。</li>
	<li>7.0はタイプを受け入れるAPIを廃止し、新たにタイプレスAPIを導入するほか、_default_マッピングをサポート対象外とします。</li>
	<li>8.0はタイプに対応するAPIを削除します。</li>
</ul>
<h2>タイプレスAPI</h2>
<p>URLパス、リクエストbody、またはレスポンスbodyでタイプを受け入れるすべてのAPIが、新たに"タイプレス"カウンターパートを取得します。この挙動はindex creationやindex、GET APIなどの非常に一般的なAPIで生じます。具体的な説明は長くなるので割愛しますが、7.0クラスターとのやり取りは下のようになります。
</p>
<pre class="prettyprint">PUT index
{
  "mappings": {
    "properties": { // Note how there is no top-level key with the type name
      "@timestamp": {
        "type": "date"
      }
    }
  }
}
PUT index/_doc/1 // _doc becomes the new endpoint for document index, get and delete requests
{
  "@timestamp":"2019-02-20"
}
POST index/_bulk
{"index": {"_id":"2"}} // no _type in the URL or in document metadata
{"@timestamp":"2019-03-01"}
{"update": {"_id":"1"}}
{"@timestamp":"2019-02-21"}
GET index/_doc/2
GET index/_search // unchanged, the `GET index/{type}/_search` endpoint is deprecated however
{
  "query": {
    "range": {
      "@timestamp": {
        "gte":"2019-01-01"
      }
    }
  }
}
GET index/_explain/1 // note how the type does not appear in the URL anymore, this would have been "GET index/{type}/1/_explain" in 6.x
{
  "query": {
    "range": {
      "@timestamp": {
        "gte":"2019-01-01"
      }
    }
  }
}
</pre>
<h2>対応にあたって必要となる作業</h2>
<p>一部の変更は破損を招く内容となるため、7.0への<strong>アップグレードの前に</strong>お使いのクラスターを変更していただく作業が必要です。その他の変更は、8.0へのアップグレードに際してのみ実施する必要があり、かつ7.0へのアップグレード完了後に実施しなければなりません。
</p>
<h3>アップグレード前の手順</h3>
<h4>6.8にアップグレードしておく</h4>
<p>ダウンタイムを設けず連続的にアップグレードすることを検討されている場合、はじめにバージョン6.8にアップグレードする必要があります。6.8は6.x台のリリースで唯一<code>include_type_name</code>パラメーターといった機能をサポートするバージョンで、こうした一連の機能は7.0にスムーズにアップグレードする上で必要となります。
</p>
<h4>_default_マッピングの使用をやめる</h4>
<p><code>_default_</code>マッピングは7.0以降でサポートされません。6.xの既存のインデックスに<code>_default_</code>マッピングがある場合、新しいインデックスでは<code>_default_</code>マッピングがリジェクトされるだけなので問題にはなりません。
</p>
<p>この場合、実際のタイプを<code>_default_</code>マッピングに含めるのではなく、インデックステンプレートとアプリケーションコードを更新してこれらのマッピングを実際のタイプに追加する必要があります。タイプの名称を重視しない場合に推奨されるやり方として、<code>_doc</code>を使用する方法があり、将来のタイプレスAPIへの移行をより容易にします。
</p>
<h4>インデックス作成とテンプレート、およびマッピングAPIに<code>include_type_name=true</code>をパスする</h4>
<p>タイプレスAPIに移行すると、従来リクエストbodyがタイプを要求していたAPIは、期待値と異なるフォーマットを受け取ることになります。
</p>
<ul>
	<li>create index</li>
	<li>put mapping</li>
	<li>put template</li>
</ul>
<p>一方、レスポンスでタイプを返していたAPIの場合は、これまでと異なるレスポンスフォーマットを持つことになります。
</p>
<ul>
	<li>get index</li>
	<li>get mapping</li>
	<li>get field mapping</li>
	<li>get template</li>
</ul>
<p>この変更による問題を回避するには、お使いのアプリケーションからこれらのAPIコールに<code>include_type_name=true</code>をパスする必要があります。include_type_name=trueは6.xでは無処理（no operation）ですが、7.xではAPIに6.xと同じ挙動を命じます。一例として、このパラメーターを使ったインデックス作成コールを見てみましょう。6.8と7.xで同じように動作します。
</p>
<pre class="prettyprint">PUT index?include_type_name=true
{
  "mappings": {
    "my_type": {
      "properties": { // Note how there is no top-level key with the type name
        "@timestamp": {
          "type": "date"
        }
      }
    }
  }
}
</pre>
<h3>アップグレード後の手順</h3>
<p>推奨の手順に沿って事前アップグレードを完了すると、あらゆる面で正常な動作を保つことができます。しかし、この段階でまだタイプを受け入れるAPIを使用している場合は、"サポート終了"の警告が発生します。この警告を回避するには、タイプレスAPIに移行する必要があります。
</p>
<p>インデックス作成、テンプレートとマッピングAPIではURLパラメーターから<code>include_type_name=true</code>を削除し、リクエストbodyやレスポンスフォーマットの期待値にタイプを含めないよう修正する必要があります。リクエストbodyやレスポンスにマッピングが含まれているとき、通常は次のようなセクションがあります。
</p>
<pre class="prettyprint">{
  "my_type": { // this key is no longer accepted in mappings as of 7.0
    "properties": ...
  }
}
</pre>
<p>今後タイプ名を含めないようアップデートする必要があります。その修正後は次のようになります。
</p>
<pre class="prettyprint">{
  "properties": ...
}
</pre>
<p>インデックスやGET、アップデートなどその他のAPIの場合、URL中のタイプ名を<code>_doc</code>に置き換える必要があります。この手順は、インデックスのタイプ名にかかわらず有効です。たとえば<code>my_type</code>というタイプ名のインデックス向けにインデックスコールを実施していた場合、置き換え前のインデックスコールは次のような感じです。
</p>
<pre class="prettyprint">PUT index/my_type/1
{
  "@timestamp":"2019-02-20"
}
</pre>
<p>置き換え後はこのようになります。
</p>
<pre class="prettyprint">PUT index/_doc/1
{
  "@timestamp":"2019-02-20"
}
</pre>
<h2>その他のリソース</h2>
<p>タイプの削除やタイプレスAPIへの移行についてより詳しい情報に関心をお持ちの方は、<a href="/guide/en/elasticsearch/reference/7.0/removal-of-types.html">タイプの廃止に関するドキュメント</a>をご一読いただくことをおすすめいたします。このドキュメントは、変更の実装や対応に関する準備についてさらに豊富な情報を提供しています。
</p>
<p>ぜひ<a href="/jp/downloads/elasticsearch">7.0.0をダウンロード</a>して、新しいタイプレスAPIをお試しください。お気づきの点がありましたら、フィードバックを<a href="https://discuss.elastic.co/">ディスカッション</a>ページにお寄せください。お待ちしています。
</p>

AUTHOR

の記事 Adrien Grand

7.7がもたらす進化 - Elasticsearchのヒープ領域使用量が大幅ダウン

"タイプ"廃止へ。"タイプレス"が登場！

Elastic Cloudの無料トライアルに登録

プロダクト＆ソリューション

Elasticについて

各種資料

ソリューション

Elastic (ELK) Stack

NEW

AUTHOR

の記事 Adrien Grand

7.7がもたらす進化 - Elasticsearchのヒープ領域使用量が大幅ダウン

"タイプ"廃止へ。"タイプレス"が登場！

Elastic Cloudの無料トライアルに登録

Elasticについて

各種資料