Apache Igniteクラスターの容量を計画する方法

Alexey Goncharuk （Apache Ignite PMCメンバーおよびチーフアーキテクトGridGain） のスピーチのビデオのトランスクリプトを、3月29日にサンクトペテルブルクで開催されるApache Igniteコミュニティミーティングで公開します。 スライドはこちらからダウンロードできます。







Apache Igniteコミュニティのメンバーは、「このような量のデータをロードするには、いくつのノードとメモリが必要ですか？」とよく尋ねられます。今日、これについてお話したいと思います。 今後の見通し：このような予測は、依然としてかなり複雑であり、重要な作業です。 これを行うには、Apache Igniteデバイスを少し理解する必要があります。 また、予測タスクを単純化する方法、および適用できる最適化についても説明します。



そのため、非常に頻繁にユーザーが私たちのところに来てこう言います。「データはファイル形式で表示されます。 「このデータをApache Igniteに変換するにはどれくらいのメモリが必要ですか？」

この定式化では、異なるファイル形式が完全に異なるモデルに変換されるため、質問に答えることはほとんど不可能です。 たとえば、ファイルが圧縮されている場合があります。 また、ある種の古典的なバイナリ形式に圧縮されていないが、データを重複排除できる場合、ファイルは暗黙的に圧縮されます。



また、Apache IgniteはさまざまなキーまたはSQLインデックスによるデータへの迅速なアクセスを提供することを忘れないでください。したがって、ファイルにあるデータに加えて、追加コストで追加のインデックスを作成します。 したがって、一般的な場合、インデックス付きフィールドのサイズは異なる可能性があるため、単一のインデックスが合計データ量の一部を追加すると言うのは正しくありません。 つまり、一定の割合のメモリをインデックスに割り当てることは間違っています。



問題を再定式化しましょう。 モデルはいくつかのタイプで構成されていると言い、各タイプの構造をよく理解しています。 さらに、モデルに可変サイズのフィールド（文字列など）がある場合、データセット全体のサイズ分布だけでなく、最小および最大データサイズを概算できます。 使用するデータ型の数と各型の情報量に基づいて、メモリとディスクの量を計画します。

経験的アプローチ

経験的なアプローチは少し不正確かもしれませんが、ユーザーの観点からは、システムの構造に深く没頭する必要はありません。 アプローチの本質は次のとおりです。

データの代表的なサンプルを取り、Apache Igniteにアップロードします。 ロード中に、ストレージサイズの増加を観察します。 特定のボリュームでは、「カットオフ」を実行して、データセット全体に必要なストレージボリュームを線形に推定および予測できます。



通常、ここには「代表的なサンプルはどうあるべきですか？」という質問があります。

ランダムにサンプルを生成したら。 しかし、ジェネレーターは、生成中の除算の残りがセットに含まれるようにデータを収集したことが判明しました。 ある時点で、均一な分布を持つはずのランダムな文字列が実際にこの分布を持たないことが判明しました。 したがって、ストレージの量を評価するときは、操作している配布が代表サンプルで実際に実行されていることを確認してください。



また、オブジェクトのサイズの広がりにも注意してください。 それらが同じ長さであると仮定する場合、一般的に、少数のオブジェクトで代表的なサンプルに十分です。 変動性が大きいほど、フィールドサイズの組み合わせが多いほど、関係を理解するためにサンプルをダウンロードする必要が大きくなります。 私自身の経験から言えば、ノードごとに1つのパーティションにロードされる100万個のオブジェクトによって、依存関係はどこかで解消され始めます。



代表的なサンプルのロード中に正確に監視する必要があるものは何ですか？ 永続化を使用する場合、取得するファイルの量を確認できます。 または、リージョンデータのメトリック、Apache Ignite構成のメトリックをオンにし、MX Beanを使用してメモリの増加を監視し、「カットオフ」とプロットを行うことができます。

数値評価

この場合、Apache Igniteでオブジェクトを保存するときにオブジェクトが受けるデータ構造を変更するすべての段階を経て、メモリ消費を増やす可能性のある周囲のデータ構造も調べます。 どのような変化が起こっているのか、どのデータ構造が変化しているのかを理解すれば、データをロードするために必要なメモリ量をかなり正確に推定できます。



Apache Igniteに書き込むときのキャッシュプット操作を分析しましょう。 データは変換の4つの段階を通過します。







一部のユーザーはクラスを操作し、JavaオブジェクトをApache Igniteに渡すため、最初の段階はオプションです。 一部のユーザーはバイナリオブジェクトを直接作成するため、オブジェクトを変換する最初の段階はスキップされます。 ただし、Javaオブジェクトを使用する場合、これはオブジェクトが受ける最初の変換です。



Javaオブジェクトをバイナリオブジェクトに変換した後、クラスに依存しない形式を取得します。 その本質は、クラスの説明がなくても、クラスター内のバイナリオブジェクトを操作できることです。 これにより、クラスの構造を変更し、オブジェクトの構造の変更のいわゆるローリングを実行できます。 つまり、モデルが成長し、変化し、クラスをクラスターにデプロイすることなく、クラスを変更せずにデータを操作する機会が得られます。



変更の第3段階、追加のオーバーヘッドの導入-ディスクへの書き込み。 ディスクの作業単位は、従来はページです。 また、Apache Ignite 2.0以降、ページアーキテクチャに切り替えました。 これは、各ページにオプションのタイトル、一部のメタデータがあり、ページにオブジェクトを書き込むときにもスペースを占有することを意味します。



また、考慮する必要がある最後の部分は、インデックスの更新です。 SQLを使用していない場合でも、Apache Igniteではキーにすばやくアクセスできます。 これは、メインのApache IgniteキャッシュAPIです。 したがって、主キーのインデックスは常に構築され、スペースも無駄になります。



これはバイナリオブジェクトです。







構造を深く掘り下げることはせず、一般的には、一種の見出し、次にフィールド、重要なデータとフッターとして表現できます。 バイナリオブジェクトヘッダーには24バイトが必要です。 おそらくこれはたくさんありますが、クラスのないオブジェクトの可変性をサポートするためには非常に多くが必要です。



キャッシュに入れるデータのモデルに何らかの内部構造の拡散が含まれる場合、いくつかの小さなオブジェクトを元の大きなオブジェクトにインライン化できるかどうかを確認する価値がありますか？ 原則として、このようなインライン化はオブジェクトごとに24バイトを節約します。モデルが十分に大きい場合、大幅に増加します。



フッターのサイズはcompactFooterフラグに依存します。これにより、オブジェクトの構造を追加のメタデータに書き込むことができます。 つまり、オブジェクト自体のフィールドの順序を記述する代わりに、それらを個別に保存します。 compactFooterがtrueの場合、フッターは非常に小さくなります。 しかし同時に、Apache Igniteはこのメタデータを保存および維持するために追加の手順を実行します。 compactFooterがfalseの場合、オブジェクトは自給自足であり、追加のメタデータなしでその構造を考慮することができます。



現時点では、パブリックAPIにはバイナリオブジェクトのサイズを返すメソッドはありません。 したがって、これが非常に興味深い場合は、ハックしてオブジェクトを実装することができ、そのサイズが表示されます。 Apache Ignite 2.5では、オブジェクトのサイズを取得するメソッドを追加すると思います。

ページのアーキテクチャ

先ほど言ったように、ディスクの作業単位はページです。 これは、ディスクへの読み取りと書き込みを最適化するために行われます。 しかし同時に、ディスクに保存されるデータ構造はページでも機能する必要があるため、Apache Igniteの内部アーキテクチャに制限を課します。



言い換えれば、データ構造は、ツリーであれフリーリストであれ、ブリックページから構築されます。 ページは一意の識別子によって相互にリンクします。 同じ一意の識別子を使用して、一定の時間、これらのページを読み取ることができるファイル、またはこのファイルからこのページまたはそのページを読み取るオフセットを決定できます。



多くのページに分割された単一のセクションは、そのようなスキームとして表すことができます。







開始メタページでは、他のページにアクセスできます。 それらはさまざまなタイプに分けられ、その多くがありますが、例を単純化するために、次のようにします。

• データを保存するデータページ。
• インデックスツリーを構築できるインデックスページ。
• フリーリストやメタデータなどの構造の補助ページ。

なぜこれが必要なのか、もう少し詳しく説明します。



データページから始めましょう。 このブロックは、Apache Igniteにデータを書き込むときにキーと値を取ります。 まず、情報に対応できるデータページが取得され、そこにデータが書き込まれます。 それらへのリンクが受信されると、情報がインデックスに書き込まれます。



データページにはテーブル構成があります。 最初に、キーと値のペアへのオフセットを含むテーブルがあります。 キーと値のペア自体は逆の順序で書き込まれます。 最初のエントリはページの最後にあります。 これは、空き領域での作業をより便利にするために行われます。 なぜそんなに複雑だったのかと尋ねますか？ ページに直接データを書き込んで、ページ内のオフセットを参照できないのはなぜですか？ これは、ページを最適化するために行われます。







ここでレコード番号2を削除すると、2つの空きゾーンが形成されます。 将来、レコード3を右に移動して、ここでより大きなレコードに対応する必要が生じる可能性があります。 また、間接アドレス指定がある場合は、テーブル内の対応するレコードのオフセットを変更するだけです。 この場合、このページにリンクする外部リンクは一定のままです。



文字列は、そのサイズがページサイズよりも大きくなるという意味で断片化できます。 この場合、空白ページを取得し、行の末尾をそのページに書き込み、残りをデータページに書き込みます。



キーと値に加えて、システムの正しい動作のための補助情報、たとえばバージョン番号がデータページに記録されます。 有効期限ポリシーを使用する場合、有効期限もそこに書き込まれます。 一般に、追加のメタデータは35バイトを占有します。 バイナリオブジェクトとキーのサイズがわかったら、35バイトを追加して、データページの特定のレコードの量を取得します。 次に、ページに収まるレコード数を計算します。



データページには、どのレコードも収まらない空き領域があることが判明する場合があります。 その後、メトリックに1に等しくない曲線因子が表示されます。



そして記録手順についての少しの言葉。 空白のページがあり、そこにデータを書き込んだとします。 空き領域がたくさんあります。 単にページを捨てて、ページがどこかに横たわって使用されないようにするのは間違っています。



考慮に入れる意味のある空き領域があるページに関する情報は、空きリストデータ構造に格納されます。 この実装で、現時点でページに含まれるバイトが8バイト未満の場合、8バイトに収まるようなキーと値のペアが存在しないため、ページはフリーリストに分類されません。



データページを把握してその数を見積もった後、必要なインデックスページの数を見積もることができます。



Apache IgniteのインデックスはすべてBツリーです。 これは、最低レベル-ワイドレベル-が絶対的にすべてのキーと値のペアへのリンクであることを意味します。 インデックスはルートページから始まります。 各内部ページには、下位レベルへのリンクがあります。



主キーであるインデックスの場合、インデックスページに書き込まれるアイテムのサイズは12バイトです。 閲覧しているページ-内側またはシート-に応じて、最大要素の数が異なります。 このような数値の推定値を使用すると、コード内の最大要素の数を確認できます。 プライマリインデックスの場合、リンクサイズは常に12バイトに固定されます。 ページ要素の最大数を大まかに計算するには、ページサイズ（デフォルトでは4メガバイト）を12バイトで除算できます。



ツリーの成長を考えると、データのロード順序に応じて、各ページが50％から75％に満たされると想定できます。 ツリーの下位レベルにすべての要素が含まれている場合、インデックスを保存するのに必要なページ数も推定できます。

SQLインデックス（またはセカンダリインデックス）の場合、ページに格納される要素のサイズは、構成されたインラインサイズによって異なります。 インデックスページの数を計算するには、データモデルを慎重に分析する必要があります。



多くの質問により、ユニットパーティションごとに追加のメモリ消費が発生します。 文字通り1つの要素が各パーティションに書き込まれる空のキャッシュを開始するには、かなりの量のメモリが必要です。 実際、この構造では、パーティションごとに必要なすべてのメタデータを初期化する必要があります。



<イラスト>



デフォルトのパーティション数は1024であるため、1つのノードを開始し、各パーティションで1つの要素の書き込みを開始すると、非常に多数のメタステージをすぐに初期化するため、初期メモリオーバーヘッドが非常に大きくなります。



経験的なアプローチでは、かなり大量のデータをロードし、パーティションのメモリ消費量は目立たなくなります。 しかし、より正確な評価のために考慮に入れる必要があります。 パーティション、すべてのデータページおよびインデックスページにメモリオーバーヘッドを追加すると、必要なメモリサイズを正確に計算できます。

最適化

将来、ユーザーの生活をどのように楽にすることができますか？ Apache IgniteはSQLシステムに移行しており、オーバーヘッドを削減するための多くのアイデアがあります。



バイナリ形式を変更して 、ヘッダーのサイズを小さくすることができます 。 キャッシュのいずれかでより厳密に型指定されたデータ構造に切り替えても、オブジェクトを混在させることはできませんが、消費されるメモリ量は減少します。



2番目の解決策は、ページ内で同じタイプのオブジェクトをグループ化し、タイトルまたはその一部を選択することです。 この場合、Apache Igniteは、ページレベルで既にデータを重複排除します。



別の賢明なアイデア： freelistにカスタムデータアカウンティングのしきい値を実装します 。 ページが100バイトになるように断片化され、データが100バイト未満にならないことを理解している場合、ページがそこに到達せず、このフリーリスト自体にスペースを使用しないようにフリーリストを強化することは理にかなっています。



ユーザーに対して透過的な、ページレベルでのシステムデータ圧縮により積極的に議論および実行されます。 技術的な問題はいくつかありますが、一般的なケースでは、よりコンパクトなデータ配置を優先してパフォーマンスを犠牲にします。



そして、最後の、非常に一般的な最適化は、 クラスター容量計算機です。 大きな問題は、このようなユーティリティの入力は何になるかです。 そのようなスキームを見ることができます：ユーザーはオブジェクトの構造を計算機にロードし、ロードする予定の行数を示し、計算機はApache Igniteのすべてのインデックスと内部オーバーヘッドを考慮して、必要なメモリ量を示します。

ディスク/メモリの割合を決定する

保存されるデータの量が利用可能なメモリの量よりも大きい場合、どのくらいのメモリを割り当てる必要がありますか？ メモリが不足すると、Apache IgniteはOSとほぼ同じ方法で動作します。メモリからデータを取り出し、必要なデータをロードします。 一部のデータは破棄できませんが、ほとんどの場合、これは重要ではありません。



ここでは、ページ自体の外観はレコードを意味するものではないことを覚えておく必要があります。 メモリからのデータの取り出しは安価です。 また、ディスクからミスが発生したデータのその後の読み取りは、高価な操作です。 ほとんどの場合、注意する必要がある最も重要な機能は、ドライブが発行できるIOPSの数です。 クラウド展開を使用している場合、IOPSの数を見つけることは非常に簡単です。



たとえば、Amazonでイメージを開始してマウントするとき、Mb / sの記録速度を持つディスクから選択できます。 しかし、私たちの経験では、IOPSを知る方がはるかに便利です。 実際、ページを操作するため、IOPSは単位時間あたりにディスク上で実行できる読み取りまたは書き込み操作の最大数です。



メモリから消去されるページを選択する方法は？ これは、ランダムLRUアルゴリズムに従って行われます。 Apache Igniteには、データが配置されているメモリ内の特定の物理アドレスへの同じページ識別子のマッピングを保存するメモリ内のページが含まれています。 ページの1つを破棄する必要がある場合、このテーブルからn個のランダムページを取得し、最も古いページを選択します。 彼女は常に絶対的な意味で最年長になるとは限りません。 しかし、ほとんどの場合、n番目の部分に分類されます。nは選択したサンプルの数です。



これまで、ランダムLRUアルゴリズムはフルスキャンに耐性がありませんが、Apache Igniteで別のタスクに使用されるランダムLRU 2アルゴリズムの実装が既にあります。 また、ランダムなLRU 2を使用してページを置き換えると、フルスキャンに対する耐性の問題が解決されます。



ページの押し出しは、単一のキャッシュ操作のレイテンシに大きく影響します。 最悪の状況：キャッシュにある種の十分に使用されていないSQLインデックスまたは領域があり、この領域のすべてのページがディスクに完全にプッシュされた、つまりメモリから消去されたことが判明しました。 nページすべてにアクセスするキーを使用すると、ディスクから順番に読み取られます。 そして、ディスクからの読み取りの可能性を最小限に抑える必要があります。



Apache Ignite 2.3から、キャッシュを異なるデータ領域に分割できるようになりました。 ホットデータのサブセットがあることを知っていて、おそらくそれらを操作し、さらに履歴データのサブセットがある場合は、これらのサブセットを異なるデータ領域に分割することは理にかなっています。



また、ディスク/メモリ比を決定するには、キャッシュ内の単一操作のアクセス時間の中央値または平均ではなく、パーセンタイルを常に監視する必要があります。これは、パーセンタイルが情報を提示する最も完全な方法だからです。



最悪のシナリオでは、ページをディスクから読み取る必要があるため、ケースの1％で遅延が大幅に大きくなります。 単純に平均を見ると、この機能に気付かないでしょう。 厳密なSLAが重要な場合は、割合を決定する際にパーセンタイルを分析するだけです。



最後に言及する価値があるのは、同じ物理メディアで永続性を有効にして多くのApache Igniteノードを実行しないでください。 物理ディスクは1つしかないため、IOPSの数はApache Igniteノード間で共有されます。 ノード間で帯域幅を共有するだけでなく、これに加えて、各ノードでIOPSの容量が不足する可能性があり、クラスター全体の動作が予測不能になります。



何らかの理由で同じマシンで複数のApache Igniteノードを実行する場合は、ノードの物理リポジトリを異なるものにしてください。 これは、先行書き込みログを別の物理メディアに転送する推奨事項に追加されます。

CPUおよびネットワーク帯域幅の計画

1ギガビット未満の帯域幅のネットワークを使用しないでください。 今日、ネットワークの帯域幅が少ない人はほとんどいません。 CPUの選択は、負荷プロファイル、インデックスの数に大きく依存します。 ここでは、経験的なアプローチに戻り、アプリケーションに必要な負荷プロファイルを単純に生成し、すべてのシステムパフォーマンスを注意深く監視する価値があります。 一部のリソースが完全に使い果たされていることがわかった場合は、追加するのが理にかなっています。



Apache Igniteを改善するための質問やアイデアを歓迎します。



モスクワとサンクトペテルブルクでの会議に参加してください。

チャンネルの他の興味深いビデオ：

• Apache Ignite 2.4の新機能
• アーキテクト向けのApache Igniteクラスタースケーリング