Cassandra ドキュメント

バージョン

プレリリース版のドキュメントを表示しています。

本番環境推奨事項

cassandra.yaml ファイルと jvm.options ファイルには、本番環境での使用に関する多数の注意事項と推奨事項が含まれています。このページでは、ファイルに記載されている情報の一部について詳しく説明します。

トークン

ノードごとに複数のトークン範囲を使用することは、仮想ノード、または vnodes と呼ばれます。 vnodes は、新しいノードがクラスタにブートストラップするときに、より多くのストリーミングピアによる柔軟な拡張を容易にします。ストリーミングの悪影響 (I/O および CPU オーバーヘッド) を制限することで、段階的なクラスタ拡張が可能になります。ただし、トークンが多くなると、より多くのピアとデータを共有することになり、可用性が低下します。これらの 2 つの要素は、クラスタの特性の読み取りと書き込みに基づいてバランスを取る必要があります。詳細については、仮想ノードにおける Cassandra の可用性、Joseph Lynch および Josh Snyder をお勧めします。

cassandra.yaml ファイルの設定を使用してトークン数を変更します

num_tokens: 16

一般的なトークン数とその使用方法と理由を簡単に説明します。

トークン数 説明

1

最大の可用性、最大のクラスタサイズ、最小のピア数ですが、拡張性は柔軟ではありません。バランスを維持するために、常にクラスタのサイズを 2 倍にする必要があります。

4

弾力性と可用性の健全な組み合わせ。最終的に 30 ノードを超えるクラスタに推奨されます。バランスを維持するために、約 20% 多くのノードを追加する必要があります。クラスタを縮小すると、クラスタのバランスが崩れる可能性があります。

8

8 つの vnode を使用すると、約 10% の分散でシステム間でワークロードが分散され、パフォーマンスへの影響は最小限に抑えられます。

16

定期的に拡張および縮小する弾力性の高いクラスタに最適ですが、大規模なクラスタでは可用性の問題が発生する可能性があります。50 ノードを超えるクラスタにはお勧めしません。

トークン数を設定することに加えて、cassandra.yamlallocate_tokens_for_local_replication_factor を適切なレプリケート数に設定して、トークンが均等に割り当てられるようにすることが非常に重要です。

先読み

先読みは、できるだけ多くのデータをページキャッシュにロードしておくためのオペレーティングシステムの機能です。スピニングディスクはシーク時間が長いため、遅延が大きくなる可能性があるため、ページキャッシュを使用した読み取りのスループットを向上させることでパフォーマンスを向上させることができます。先読みを活用することで、OS は追加のシークなしで追加のデータをメモリにプルできます。この方法は、使用可能な RAM がホットデータセットのサイズよりも大きい場合に適していますが、逆の場合 (データセット > RAM) には問題が発生する可能性があります。ホットデータセットが大きいほど、先読みの有効性は低下します。

先読みは、次の場合に明らかに役立ちません

  • 単一パーティションキーを持つテーブルなど、小さなパーティション

  • ソリッドステートドライブ (SSD)

先読みは実際にディスク使用量を増やす可能性があり、場合によっては遅延とスループットのパフォーマンスが最大 5 倍低下する可能性があります。読み取りが多い、行が小さい (1KB 未満) キー/バリューテーブルは、特にこの問題が発生しやすいです。

推奨される先読み設定は次のとおりです

ハードウェア 初期推奨事項

スピニングディスク

64KB

SSD

4KB

Linux システムでは、blockdev ツールを使用して先読みを調整できます。

たとえば、ディスク /dev/sda1 の先読みを 4KB に設定します

$ blockdev --setra 8 /dev/sda1

blockdev 設定は、先読みする 512 バイトセクタの数を設定します。上記の引数 8 は 4KB、つまり 8 * 512 バイトに相当します。

すべてのシステムは異なるため、これらの推奨事項を出発点として使用し、SLA とスループットの要件に基づいて調整してください。先読みがディスクリソースの使用状況にどのように影響するかを理解するには、詳細分析、外部ツールの使用 セクションをよく読んでください。

圧縮

圧縮データは、固定サイズのバイトバッファを圧縮し、データをディスクに書き込むことによって保存されます。バッファサイズは、WITH COMPRESSION のテーブルのスキーマ設定の圧縮マップの chunk_length_in_kb 要素によって決まります。Cassandra 4.0 以降のデフォルト設定は 16KB です。

圧縮されたバッファ全体をディスクから読み取る必要があるため、圧縮チャンクの長さが長すぎると、小さなレコードを読み取るときに大きなオーバーヘッドが発生する可能性があります。デフォルトの先読み設定と組み合わせると、特定のワークロードで massive read amplification が発生する可能性があります。したがって、この設定に適切な値を選択することが重要です。

LZ4Compressor は、デフォルトであり、推奨される圧縮アルゴリズムです。圧縮に関する追加情報が必要な場合は、圧縮パフォーマンスに関する The Last Pickle ブログ記事 を読んでください。

コンパクション

さまざまなワークロードに使用できるさまざまな コンパクション 戦略があります。環境に最適な戦略を理解するために、さまざまな戦略について読むことをお勧めします。同じクラスタ内の異なるテーブルで、異なるコンパクション戦略を使用することがよくあります。

暗号化

本番クラスタをセットアップするときは、ピアツーピア暗号化とクライアントサーバー暗号化をセットアップすることをお勧めします。クラスタが本番トラフィックを処理した後にセットアップするのは、正しく行うのが困難です。いずれかのタイプのネットワーク暗号化を使用する予定がある場合は、クラスタを最初に設定するときにセットアップすることをお勧めします。後でこれらの設定を変更することは不可能ではありませんが、ミスによってダウンタイムやデータ損失が発生する可能性があります。

NetworkTopologyStrategy でキースペースが作成されていることを確認します

本番クラスタでは、SimpleStrategy を使用しないでください。本番キースペースでは、NetworkTopologyStrategy (NTS) を使用する必要があります。例えば

CREATE KEYSPACE mykeyspace WITH replication =     {
   'class': 'NetworkTopologyStrategy',
   'datacenter1': 3
};

NetworkTopologyStrategy で初期化された Cassandra クラスタは、複数のラックとデータセンターを設定する機能を利用できます。

ラックとスニッチの設定

**クラスタをプロビジョニングした後にラックを正しく設定または変更することは、サポートされていないプロセスです**。単一ラックから複数ラックへの移行もサポートされておらず、データ損失が発生する可能性があります。GossipingPropertyFileSnitch を使用するのが、オンプレミスまたは混合クラウド環境に最適なソリューションです。 Ec2Snitch は、AWS EC2 専用環境に信頼できます。