スケーラブルなElasticsearchデータストレージを設計する

Elasticsearchを使えば、大量の構造化、および非構造化データを格納、検索、分析できます。そのスピードとスケール、フレキシブルな特性を活かし、Elastic Stackは幅広いユースケースにパワフルなソリューションを提供しています。具体的には、システムオブザーバビリティ、セキュリティ（脅威ハンティングと防御）、エンタープライズサーチなどがあります。Elasticsearchがこのようにフレキシブルで、デプロイのデータストレージをスケーラブルに、かつ効率的に設計できることは重要な意味を持ちます。

Elasticsearchが各々異なるユースケースに対応できるのもこのためです。ユースケース、デプロイ、ビジネスの状況によって、たとえば所有コストや投入パフォーマンス、クエリパフォーマンス、バックアップの数やサイズ、平均復旧時間といった指標に対する許容範囲や閾値も異なります。

こうした様々な要素を考慮するにあたっては、次の3つの質問を検討してみましょう。いきなり複雑な意思決定マトリックスとにらめっこせずに済む可能性があります。

• このユースケース/デプロイは、どの程度のデータロスに耐えられるか？
• ビジネス目標に、パフォーマンスがどの程度組み込まれているか？
• このプロジェクトは、どれくらいのダウンタイムを許容できるか？

本ブログ記事では、Elasticプロダクトで利用できる複数のデータストレージオプションと、それぞれのメリットおよびデメリットを紹介します。本記事が、Elasticsearchをデプロイするユースケースに特有の条件に応じて、スケーラブルなデータストレージを設計する方法をより深く理解する手助けとなりましたら幸いです。

そもそもデータストレージで苦労したくない、という方もご心配なく。Elastic CloudのElasticsearch Serviceなら、スケールに最適なアーキテクチャーをElasticに任せることができます。

オプション一覧

下の表は、本ブログ記事で取り上げるElasticsearchデータストレージのアーキテクチャーオプションを簡単にまとめたものです。それぞれのメリット、デメリット、および、データロスやパフォーマンス、ダウンタイムの観点からみた期待値について、詳しくご説明してゆきます。

ディスクキャパシティのスケール方法を検討するにあたっては、すぐれたオプションが複数あります。その一部について詳細を確認し、それぞれのメリットとデメリットを整理してみましょう。Elasticsearchをデプロイするとき、一つとして同じ状況はありません。したがって、すべてのシナリオに役立つ選択もありません。

RAID 0

複数のディスクを組み合わせる基本的な手法として、長年使用されているのがRAIDです。RAIDには、ミラーリング、ストライピング、パリティの3つの構成要素があります。各RAIDの数字は、これらの構成要素の一意の組み合わせを示します。

数字の0は、RAIDのストライピングを示します。ストライピングとは、データをチャンクに分けて、そのチャンクをボリューム中のすべてのディスクにわたって書き込むことです。

パフォーマンスとキャパシティ

すべてのディスクに並列に書き込めることから、ストライピングは読み取り/書き込みパフォーマンスを向上させます。実際に、読み取りと書き込みのパフォーマンスは、アレイにあるディスクの数の倍数分だけ向上します。RAID 0のアレイにディスクが6つある場合、読み取り/書き込みスピードは最大で6倍になります。

復元

RAID 0は復元手段を提供しません。したがって、Elasticsearchの復元はスナップショットか、複製を使用して実施する必要があります。ディスクのサイズと、アレイにデータをコピーする際の転送メカニズムによっては、復元に非常に時間がかかる可能性があります。また復元作業中、ネットワークトラフィックとノードのパフォーマンスに影響が生じます。

注意点

Elasticsearchインデックスは多数のシャードで構成されます。このため、RAID 0ボリュームにシャードを持つインデックスのディスクが故障し、他に複製がない場合は、インデックスも壊れる可能性があります。バックアップの管理を行うスナップショットライフサイクル管理（SLM）、またはElasticsearchの複製を設定していない場合、永久的なデータロスが生じます。

メリットとデメリット

RAID 1

パフォーマンスとキャパシティ

数字の1は、RAIDのミラーリングを示します。ミラーリングとは、同じデータを別のディスクに書き込むプロセスです。実際には、データのコピーを作成します。データは2つのディスクに書き込まれますが、RAIDの多くの実装では、読み取りにディスクを2つ使うことはありません。したがって、読み取りと書き込みのパフォーマンスは実質的に半分になります。どちらのディスクにも同じデータが書き込まれるため、キャパシティも半分になります。

復元

RAID 1は2ディスクだけで構成されます。一方のディスクが故障しても、もう一方のディスクにデータが保存されています。つまり、パフォーマンスとキャパシティの対価と引き換えに、高度なデータ冗長性を実現しています。一方のディスクが故障した場合はディスクを交換し、新しいディスクにデータをコピーします。

注意点

RAID 1は2ディスクしかサポートしないため、多くのケースではRAID 1とRAID 0が併用されています。具体的には、複数のRAID 1ボリュームと、ストライピングされたRAID 0に組み合わせるという使い方です。これはRAID 10と呼ばれ、ディスクが4つ以上の場合に使用されます。

RAID 0のパフォーマンス上のメリットと、RAID 1の冗長性を組み合わせる手法です。RAID 10のパフォーマンスはアレイのディスク数に依存します。すなわち、パフォーマンスはNx/2となります。

メリットとデメリット

RAID 5、RAID 6

パフォーマンスとキャパシティ

RAIDの数字のうち、2、3、4、5、6はパリティを示します。2、4、3はほとんどの場合別のRAIDに代替されることから、このセクションでは5と6を中心に取り上げます。パリティは、コンピューターがディスク障害により失われたデータを修正、または計算する手段です。パリティで、ストライピングのすぐれたパフォーマンスにデータ保護を追加することができます。データ復元にはデメリットを伴います。RAID 5は1ディスク相当のキャパシティを、RAID 6は2ディスクをパリティに使用します。

復元

RAID 5とRAID 6について考慮しておきたい点としてもう1つ、復元のリビルド時間があります。リビルドは、アレイのディスク交換のため、新しいディスクを追加する際の処理です。回転メディアでは、ディスクキャパシティを増やす代わりに、ディスクを追加する手法が取られます。ディスクを増やすと、読み取り・書き込み時間と、リビルド時間が長くなります。SSDについては、高キャパシティディスクが高速な読み取り・書き込みパフォーマンスも備えているか、確認する必要があります。多くの高キャパシティSSDディスクは高速な読み取り・書き込みパフォーマンスを備えています。その場合、高キャパシティディスクが読み取り・書き込みのパフォーマンスに貢献します。RAID 5では、1つのディスクが故障しても、アレイのデータは失われません。RAID 6では、2つのディスクが故障しても、データは失われません。

注意点

RAID 5とRAID 6にはディスク障害耐性がありますが、まったく影響が生じないわけではありません。RAID 5は、新しいディスクを追加し終えるまで、実質的にRAID 0と同程度に脆弱です。つまり、もう一方のディスクが故障すると、アレイのすべてのデータが失われ、他のシャードやスナップショットから復元する必要があります。したがって、ディスクがほぼ同時にバッチで故障する可能性を考慮し、多くの場合、RAID 6の実行が推奨されます。この2つから選択するにあたっては、最初にご説明したように、プロジェクトのパフォーマンスとデータ完全性に対する許容度を理解しておくことが重要です。

アレイはディスクから読み取るデータの再計算にパリティを使用する必要があるため、ディスクの喪失は、RAID 5とRAID 6のいずれのパターンでもパフォーマンスに大きな影響を及ぼします。

メリットとデメリット

Elasticsearchの複数データパス（MDP）

Elasticsearchにはpath.dataと呼ばれる設定があり、Elasticsearchデータファイルのファイルシステムロケーションを指定するために使用されます。path.dataにリストが指定されている場合、Elasticsearchは複数のロケーションを使用してデータファイルを格納します。たとえば、elasticsearch.ymlに

path.data: [ /mnt/path1, /mnt/path2, /mnt/path3 ]

が含まれている場合、Elasticsearchは書き込みを複数のファイルシステムロケーションに行います。この際、各パスを別個のディスクにすることもできます。

複数のデータパスを定義することにより、複数のデータストアを使ってElasticsearchを動作させることができます。

パフォーマンスとキャパシティ

Elasticsearchはデータをシャードに分割します。このシャードは、もっとも空き容量のあるデータパスに書き込まれます。1つのシャードに大多数の書き込みが集中すると、1データパスのスピードを上回るパフォーマンスは実現できません。しかし、複数のデータパスで均等にデータの書き込みが行われる場合、使用ディスクの数だけスピードが上がります。Elasticsearchは書き込みが複数のデータパスで行われることを保証しないため、パフォーマンスは可変的で、一貫しません。

MDPは、データのミラーリングやパリティを提供しません。詳細な説明はメリットとデメリットのセクションにありますが、使用レベルが上限に達した場合を除き、ディスクのすべてのキャパシティがデータの格納に使用されることになります。ディスクキャパシティを完全に使用するには、少なくともデータパスと同じ数のシャードが必要です。

他のパスのデータを持つノードに新しいパスを追加すると、新しいディスクでホットスポットを起こす可能性があります。Elasticsearchはデータパス間でシャードをバランスしないため、新しいシャードはすべて、もっとも空き容量のある新しいパスに送信されます。Elasticsearchは起動時にしか、elasticsearch.ymlの変更を読み取りません。したがって新規ディスクを追加するには、ノードの完全な再起動が必要です。

復元

ディスクは劣化します。複数のデータパスが使用する1台のストレージデバイスが故障すると、ノードのステータスは黄色（イエロー）になり、そのデバイス上のデータにはアクセスできなくなります。しかし、データパスがIOExceptionをthrowしても、Elasticsearchは障害が生じているデータパスに書き込みを続ける可能性があります。これを防ぐには、以下の手順を実施して、Elasticsearchノードの設定から問題のデータパスを削除することが重要です。

1. シャードの割り当てを無効化する。
2. ノードを停止する。
3. Elasticsearch configから障害が起きたデータパスを削除する。
4. ノードを再起動する。
5. シャードの割り当てを再有効化する。

永久的なデータロスを防ぐには、Elasticsearchの複製が有効であることを確認します。デフォルトでは、1シャードにつき1つの複製が設定されています。

次に、Elasticsearchは他のノードから来るシャードをリバランスします。Elasticsearchはデータパス間でシャードをバランスしません。詳しくは、「注意点」のセクションをご確認ください。クラスターにリバランスのための十分なキャパシティがない場合、ノードは黄色（イエロー）のままとなります。

新しいディスクに交換するには、十分に注意してディスクをアンマウントし、LVMグループを無効化します。この手順により、OSが新しいディスクを適切に扱うことができるようになります。新しいディスクのインストール後、Elasticsearchのpath.data設定にパスを追加する必要があります。故障したディスクの交換が終了すると、Elasticsearchは新しいパスを使いはじめます。

注意点

複数のデータパスに指定された1台のデバイスが故障すると、そのパスは次のシャード割り当てがあるまで無視されます。しかし後続のラウンドで、このパスはシャードの再割り当て可能と見なされます。このため、上述の手順を実施しない限り、IOExceptionエラーの原因となります。

Elasticsearchは使用レベルをノード単位で扱います。1つのデータパスで使用レベル上限に達すると、そのノード全体が使用レベル上限に達してしまうことに注意する必要があります。この現象は、他のデータパスに十分な空き容量がある場合も発生します。ノードが使用レベル上限に達すると、新しいシャードの受け入れを停止し、ノードから積極的にシャードを移動させる、あるいはノードを読み取り専用のステータスに移行させることになります。

たとえば、500GBのデータパスが6つあり、合計のキャパシティが約3TBというノードについて考えてみましょう。1つのデータパスでディスクの90％を使用することもあり得ます。結果的にノード全体として使用レベル上限に達してしまい、ノードは読み取り専用に移行します。たとえノードの他のディスクの使用状況が50％以下であっても、このようになります。

Elasticsearchは単一のノード内でシャードをバランス化する対応を行いません。つまり、データパス間でシャードはバランスされません。ユーザーが複数のデータパスを使用している場合、Elasticsearchはその時もっとも空き容量のあるディスクにシャードを置きます。1つのシャードに他のシャードより多くのデータがあり、ディスクをいっぱいにしても、Elasticsearchはシャードをバランスしません。このため、気づかないうちにIO負荷の分散が不均一になる可能性があります。また、他のデータを持つノードに新しいディスクを追加すると、新規のパスに高いIO負荷をかける可能性があります。

メリットとデメリット

まとめ

データ量を増加する必要があるというのはエキサイティングなことですね！本記事では多数のオプションやツールをご紹介しましたが、スケーラブルなデータストレージを設計する際、「あらゆるシナリオにフィット」するソリューションは存在しない、ということを念頭に置いていただければと思います。

スケーラブルなElasticsearchのデプロイのストレージアーキテクチャーについてご質問やご不明点がおありの場合は、ディスカッションフォーラムで筆者や、成長を続けるユーザーコミュニティにご相談ください。

また、ハードウェアの管理を自前では行わない、という選択もあります。冒頭でもご紹介しましたが、Elastic Cloudなら、Elasticに管理を任せることができます。ノードを追加するだけでデータ増に対応でき、サーバーを調達、設置、管理する必要もありません。Amazon Web Services、Google Cloud Platform、Microsoft Azureという、おなじみのクラウドで利用できます。ぜひ無料のトライアルをお試しください。