エンジニアリング

検索可能スナップショットの大規模な活用を叶える、Elasticsearchの新しいColdティア

著者
Dimitrios Liappis
•
Yannick Welsch

Elasticsearch 7.10においてベータで提供されていた検索スナップショット向けColdティアが、Elasticsearch 7.11より一般公開へ移行しています。この新しいデータティアを使うと、Warmティアと比較してクラスターのストレージ使用量を最大で50％削減できる一方、信頼性と冗長性をHotティアおよびWarmティアと同水準に保つことができます。 

本ブログ記事では、Coldティアが大規模データに対してもそつなく動作することを複数のシナリオを使って検証します。またこの検証を通じて、各種ソリューションの品質と信頼性を重視するElasticの取り組みの一端をご紹介します。

Coldティアとは？

Coldティアはプライマリシャードだけをローカルストレージに置くことにより、クラスターのコストを引き下げます。レプリカシャードを作成する必要がない代わり、スナップショット（AWS S3やGoogle Storage、Microsoft Azure Storageなどのオブジェクトストアに入れることが可能）を使うことで必要なレジリエンシーを提供します。したがってローカルストレージは実質的に、レポジトリに入っているスナップショットデータのキャッシュバージョンのように動作します。

Coldノード、またはローカルストレージのヘルスに問題がある場合、検索可能スナップショットは自動的に復元され、他のノード上のシャードがリバランスされます。

フルクラスターのリスタート、またはローリングリスタート（あるいはノードリブート）を実行する場合も、ローカルストレージが永続性を保ち、ローカルで利用可能なデータがスナップショットから再ダウンロードされることはありません。これによりクラスターがグリーンに戻るまでの時間を最小化でき、また不要なネットワークコストを回避することが可能です。

この挙動が大規模なデータに対しても期待通り動作するか確認するために、Elasticは3つのシナリオで検証を行いました。すべてのシナリオで使用した設定は、以下の通りです。

  • Elasticsearchノード×5（16Gヒープ）
  • 2TBの磁気ディスク×6（RAID-0に設定）
  • 10のインデックスに分散し、各インデックスに5つのシャードを持たせて1つのセグメントに強制的にマージしたロギングデータのスナップショット、合計5TB分（強制的なマージにより、読み取りアクセス向けのインデックスを最適化し、また障害イベント発生時の復元に必要なファイル数を削減している）

シナリオ1 ― フルクラスターのリスタート

Elasticが最初に検証したシナリオはフルクラスターのリスタートです。この検証は、次の手順で実施しました。

  1. 5TBの検索可能スナップショットをマウントし、ローカルキャッシュが完全にプリウォームされるまで待機する（フェーズ0）。
  2. フルクラスターリスタートのガイドラインに沿って、フルクラスターのリスタートを実行する。
  3. 割り当てを再有効化した後、クラスターが次の状態になるまでの時間を測定する。
    1. グリーンになる
    2. キャッシュプリウォームのためのバックグラウンドダウンロードがすべて完了する
  4. 手順3の後、シャードリバランスが追加で実行されていないことを確認する。

Elasticsearch 7.11から登場した永続性レイヤーのおかげで、すべてのノードをリスタートして割り当てを再有効化した後、クラスターはすぐにグリーンに戻り、バックグラウンドでのダウンロードも一切発生しません。

下のスクリーンショットでは、マウント中（フェーズ0）に累積的にネットワークトラフィックが増加している様子と、フルクラスターのリスタートと割り当ての再有効化後（フェーズ1）でネットワークトラフィックの増加が止まった様子を確認できます。

シナリオ2 ― ローリングリスタート

Elasticが2番目に検証したシナリオがクラスターのローリングリスタートです。

検証手順は、フルクラスターのリスタートの時とさほど変わりません。

  1. 5TBの検索可能スナップショットをマウントし、ローカルキャッシュが完全にプリウォームされるまで待機する。
  2. 各ノードを停止させる前に、シャードの割り当てを無効化することにより、1番目のノードでローリングリスタートの手順を実行する。
  3. ノードを起動し、シャードの割り当てを再有効化した後、クラスターのステータスがグリーンになるまでの時間を測定する。永続性キャッシュによってステータスがすぐにグリーンになると期待されるので、その挙動を確認。また各々のリスタート後に不要なバックグラウンドダウンロードがないことも確認する。
  4. クラスターのほかのすべてのノードについて、手順2および3を反復する。

2つ目のシナリオでも検証は成功しました。Elasticsearch 7.11で導入された永続性キャッシュのおかげで、クラスターは実質的に瞬時にグリーンに戻り、またスナップショットからのバックグラウンドダウンロードも追加発生しないことが確認されました。 

シナリオ3 ― ノードキャッシュ

最後のシナリオは、1本のノードがクラッシュした場合に、適切に動作することを確認するものです。この検証は、次の手順で実行しました。

  1. 5TBの検索可能スナップショットをマウントし、ローカルキャッシュが完全にプリウォームされるまで待機する（フェーズ0）。
  2. 5本のノードのうち、1本のElasticsearchノードをキルし（node-1にSIGKILLを使用）、クラスターが再びグリーンに戻るまで待機する（フェーズ1）。
    1. バックグラウンドでのダウンロードが、キルされたノードにホストされていたシャードのデータ取得に関連するものであることを確認する。
    2. ステータスがグリーンになった後、追加でリバランスが実行されていないことを確認する。
  3. フェイルしたノードを起動する（フェーズ2）。
    1. シャードのリバランスにあたり、ピアリカバリーのみ実行されることを確認する（全データが残る4本のノードにあるため）
    2. クラスターがグリーンに戻ることを確認する

こちらの検証も、成功しました。node-1がキルされた後、停止したノードでホストされていたシャードを、残ったノードが検索可能スナップショットから自動で復元しました。

クラスターがグリーンに戻った後、追加のリバランスも生じませんでした。これは、ノード別のネットワークトラフィックを可視化した下のチャートで確認できます。

停止したノードが復旧した後にピアリカバリーが開始され、node-1は最終的に、均等にクラスターを分散させるために必要な量のシャードを再びホストしています。

今すぐ使いはじめる

この機能の検証結果は、Elasticチームにとって非常にエキサイティングでした。この記事をお読みくださった方にも、興味深いご報告となりましたら幸いです。

検索可能スナップショットを使ってColdティアにデータを格納するには、Elastic Cloudでクラスターを立ち上げるか、Elastic Stackの最新バージョンをインストールしてご利用ください。すでにElasticsearchを導入済みの方は、お使いのクラスターを7.11にアップグレードするだけで新機能をお試しいただくことができます。各機能について詳しくは、データティアに関するドキュメント、および検索可能スナップショットに関するドキュメントをご覧ください。