Azure VM 上で Apache Cassandra を実行する
注意事項
この記事では、サポート終了 (EOL) となっている Linux ディストリビューションである CentOS について説明します。 適宜、使用と計画を検討してください。 詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。
この記事では、Azure 仮想マシン上で Apache Cassandra を実行する際のパフォーマンスに関する考慮事項について説明します。
以下の推奨事項は、GitHub で確認できるパフォーマンス テストの結果に基づいています。 これらの推奨事項をベースラインとして使用し、お客様独自のワークロードに対してテストを行う必要があります。
Azure Managed Instance for Apache Cassandra
Azure 仮想マシン上で Apache Cassandra を実行するために、さらに自動化されたサービスを探している場合は、Azure Managed Instance for Apache Cassandra の使用を検討してください。 このサービスにより、Apache Cassandra クラスター内のノードのデプロイ、管理 (パッチの適用とノードの正常性)、スケーリングが自動化されます。 また、ハイブリッド クラスターの機能も備えているため、Azure にデプロイされた Apache Cassandra データセンターは、既存のオンプレミスまたはサードパーティのホステッド Cassandra リングへの結合が可能です。 このサービスは、Azure Virtual Machine Scale Sets を使用してデプロイされます。 このサービスの開発中に、次の推奨事項が採用されました。
Azure VM のサイズとディスクの種類
Azure 上の Cassandra ワークロードには、通常、Standard_DS14_v2、Standard_DS13_v2、Standard_D16s_v5、または Standard_E16s_v5 仮想マシンを使用します。 Cassandra ワークロードは VM のメモリ容量が大きいほど効率よく処理できます。そのため、メモリ最適化仮想マシン サイズ (Standard_DS14_v2 や Standard_E16s_v5 など)、またはローカル ストレージ最適化サイズ (Standard_L16s_v3 など) を検討してください。
持続性を確保するために、データ ログとコミット ログは、通常、2 つから 4 つの 1 TB Premium マネージド ディスク (P30) のストライプ セットに格納します。
Cassandra ノードのデータ密度は大きすぎないようにしてください。 VM あたり最大で 1 ～ 2 TB のデータを保持し、圧縮のために十分な空き領域を確保することをお勧めします。 Premium マネージド ディスクを使用して、可能な限り高い合計スループットと IOPS を実現するには、2 TB または 4 TB の単一ディスクを使用するのではなく、複数の 1 TB ディスクでストライプ セットを作成することをお勧めします。 たとえば、DS14_v2 VM の場合、1 つの 4 TB ディスクでは最大 IOPS が 7.5 K であるのに対し、4 つの 1 TB ディスクでは 4 x 5000 = 20 K となります。
より小さいディスク容量を必要とする Cassandra ワークロードでは、Azure Ultra Disks を評価してください。 Standard_E16s_v5 や Standard_D16s_v5 などの VM サイズでは、より高い IOPS/スループットと低遅延を実現できます。
持続的なストレージを必要としない Cassandra ワークロード場合、つまり別のストレージ メディアからデータを簡単に再構築できる場合は、Standard_L16s_v3 または Standard_L16s_v2 VM の使用を検討します。 これらの VM サイズには、大容量で高速なローカル NVM Express (NVMe) 一時ディスクが用意されています。
詳細については、GitHub の「Comparing performance of Azure local/ephemeral vs attached/persistent disks (Azure のローカルのエフェメラル ディスクと接続された永続ディスクのパフォーマンス比較)」を参照してください。
高速ネットワーク
Cassandra ノードでは、ネットワークを多用してクライアント VM との間でデータを送受信し、レプリケーションのためにノード間の通信を行います。 Cassandra VM でパフォーマンスを最適化するには、高スループットで低遅延のネットワークが適しています。
Cassandra ノードの NIC と、Cassandra にアクセスするクライアント アプリケーションを実行している VM で、高速ネットワークを有効にすることをお勧めします。
高速ネットワークを使用するには、最新の Linux ディストリビューション (Cent OS 7.5 以上または Ubuntu 16. x/18.x) と最新のドライバーが必要です。 詳細については、高速ネットワークを使った Linux 仮想マシンの作成に関するページを参照してください。
Azure VM のデータ ディスクのキャッシュ
Cassandra の読み取りワークロードは、ランダムアクセス ディスクが低遅延である場合に最適に実行されます。 読み取り専用キャッシュが有効になっている Azure マネージド ディスクを使用することをお勧めします。 読み取り専用キャッシュでは、バックエンド ストレージではなく、ホスト上のキャッシュからデータが読み取られるため、平均待機時間が短くなります。
Cassandra のような読み取り負荷の高いランダム読み取りワークロードでは、キャッシュ モードはキャッシュ無効モードよりもスループットの上限が低くなりますが、読み取り待機時間は短くなります (たとえば、DS14_v2 仮想マシンでは、最大スループットがキャッシュ無効モードの場合の 768 MBps に対してキャッシュ モードでは 512 MBps になります)。
読み取り専用キャッシュは、Cassandra の時系列ワークロードなどで特に役立ちます。このようなワークロードでは、作業データセットがホスト キャッシュに配置され、データが絶えず上書きされることがないためです。 たとえば、DS14_v2 では 512 GB のキャッシュ サイズが提供されます。これにより、1 TB から 2 TB のデータ密度を持つ Cassandra ノードのデータの最大 50% を格納できます。
読み取り専用キャッシュを有効にしても、キャッシュミスによる大幅なパフォーマンス低下はありません。そのため、最も書き込み負荷の大きいワークロードを除くすべてのケースでキャッシュ モードを使用することをお勧めします。
詳細については、GitHub の「Comparing Azure VM data disk caching configurations (Azure VM データ ディスクのキャッシュ構成の比較)」を参照してください。
Linux の先読み
Azure Marketplace のほとんどの Linux ディストリビューションでは、既定のブロック デバイスの先読み設定は 4096 KB です。 Cassandra の読み取り I/O は通常、ランダムであり、比較的小さいものです。 そのため、不要なファイルの一部を読み取ることによって、大きな先読みでスループットを浪費することになります。
不要な先読みを最小限に抑えるには、Linux ブロック デバイスの先読み設定を 8 KB に設定します (DataStax ドキュメントの「Recommended production settings (推奨される運用環境設定)」をご覧ください)。
ストライプ セット内のすべてのブロック デバイスとアレイ デバイス自体 (たとえば、/dev/md0) に対して 8 KB の先読みを構成します。
詳細については、GitHub の「Comparing impact of disk read-ahead settings (ディスク先読み設定の影響の比較)」を参照してください。
ディスク アレイ mdadm のチャンク サイズ
Azure で Cassandra を実行するとき、通常、複数のデータ ディスクの mdadm ストライプ セット (つまり、RAID 0) を作成して、VM の上限近くまで全体的なディスク スループットと IOPS を引き上げます。 最適なディスク ストライプ サイズは、アプリケーションに固有の設定です。 たとえば、SQL Server OLTP ワークロードの場合、推奨値は 64 KB です。 データ ウェアハウスのワークロードの場合、推奨値は 256 KB です。
Microsoft が実施したテストでは、Cassandra 読み取りワークロードについては、64 K、128 K、256 K のチャンク サイズの間で大きな違いは見つかりませんでした。 128 K のチャンク サイズには、わずかで識別できるくらいの小さな優位性があるようです。 そのため、以下のことを推奨します。
既に 64 K または 256 K のチャンク サイズを使用している場合、128 K サイズを使用するようにディスク アレイを再構築することは合理的ではありません。
新しい構成で、最初から 128 K を使用するのは理にかなっています。
詳細については、GitHub の「Measuring impact of mdadm chunk sizes on Cassandra performance (Cassandra のパフォーマンスに対する mdadm のチャンク サイズの影響を測定する)」を参照してください。
コミット ログ ファイル システム
Cassandra の書き込みは、コミット ログが高スループットで低遅延のディスク上にある場合に、最適に実行されます。 既定の構成では、Cassandra 3.x は最大 10 秒ごとにメモリからコミット ログ ファイルにデータをフラッシュしますが、書き込みごとにディスクにアクセスすることはありません。 この構成では、コミット ログが、接続された Premium ディスク上にあるか、ローカル/エフェメラル ディスク上にあるかに関係なく、書き込みパフォーマンスはほぼ同じです。
コミット ログには持続性が必要です。そのためは、再起動されたノードで、フラッシュされたコミット ログからデータ ファイルにまだ格納されていないデータを再構築できるようにします。 持続性を高めるために、コミット ログはローカル ストレージではなく Premium マネージド ディスクに格納します。ローカル ストレージは、VM が別のホストに移行された場合に失われる可能性があるためです。
Microsoft のテストに基づくと、CentOS 7.x 上の Cassandra の書き込みパフォーマンスは、コミット ログを XFS ファイル システムに配置した場合 ext4 と比べて "低く" なる可能性があります。 コミット ログの圧縮を有効にすると、XFS のパフォーマンスは ext4 の場合と同等になります。 Microsoft のテストでは、圧縮 XFS パフォーマンスは、圧縮および非圧縮の ext4 と同等です。
詳細については、GitHub の ext4 および XFS ファイル システムと圧縮コミット ログについての観察結果に関するページをご覧ください。
VM のベースライン パフォーマンスの測定
Cassandra リング用の VM をデプロイした後でいくつかの合成テストを実行して、ネットワークとディスクのベースライン パフォーマンスを確立します。 これらのテストを使用して、VM サイズに基づいて、パフォーマンスが期待どおりになっていることを確認します。
パフォーマンスのベースラインを把握していることによって、後で実際のワークロードを実行したときに潜在的なボトルネックの調査が容易になります。 たとえば、VM でのネットワーク送信のベースライン パフォーマンスを把握しておくと、ボトルネックとしてのネットワークを除外するのに役立ちます。
パフォーマンス テストの実行の詳細については、GitHub の「Validating baseline Azure VM Performance (Azure VM のベースライン パフォーマンスの検証)」を参照してください。
ドキュメント サイズ
Cassandra の読み取りと書き込みのパフォーマンスは、ドキュメント サイズによって異なります。 大きなサイズのドキュメントの読み取りまたは書き込みを行うと、待機時間が長くなり、1 秒あたり操作数が少なくなることが予想されます。
詳細については、GitHub の「Comparing relative performance of various Cassandra document sizes (さまざまな Cassandra ドキュメント サイズの相対的パフォーマンスの比較)」を参照してください。
レプリケーション係数
ほとんどの Cassandra ワークロードでは、接続された Premium ディスクを使用する場合はレプリケーション係数 (RF) 3 を、ローカルの一時/エフェメラル ディスクを使用する場合は計数 5 を使用します。 Cassandra リング内のノード数は、レプリケーション係数の倍数にする必要があります。 たとえば、RF 3 はノードが 3、6、9、または 12 のリングを意味し、RF 5 では 5、10、15、または 20 のノードが含まれます。 1 より大きい RF と、整合性レベル LOCAL_QUORUM を使用している場合、通常、RF 1 で実行される同じワークロードよりも読み取りと書き込みのパフォーマンスが低下します。
詳細については、GitHub の「Comparing relative performance of various replication factors (さまざまなレプリケーション係数の相対的パフォーマンスの比較)」を参照してください。
Linux のページ キャッシュ
Cassandra の Java コードでは、データ ファイルを読み取るときに通常のファイル I/O を使用するため、Linux のページ キャッシュの利点が得られます。 ファイルの一部が 1 回読み取られると、読み取られたコンテンツは OS のページ キャッシュに格納されます。 同じデータに対する後続の読み取りアクセスは、はるかに高速になります。
このため、同じデータに対して読み取りパフォーマンス テストを実行すると、2 回目以降の読み取りは元の読み取りよりもはるかに高速になるように思われます。元の読み取りでは、リモート データ ディスクまたはホスト キャッシュ (読み取り専用が有効になっている場合) のデータにアクセスする必要があるためです。 以降の実行で同様のパフォーマンス測定値を得るには、Linux のページ キャッシュをクリアし、Cassandra サービスを再起動して内部メモリをクリアします。 読み取り専用キャッシュを有効にすると、データがホスト キャッシュに格納され、その後の読み取りが、OS のページ キャッシュをクリアして Cassandra サービスを再起動した後でも高速になります。
詳細については、GitHub の「Observations on Cassandra usage of Linux page caching (Cassandra で Linux のページ キャッシュを使用した場合に関する観察結果)」を参照してください。
マルチデータセンター レプリケーション
Cassandra では複数データセンターという概念をネイティブでサポートしているため、1 つの Cassandra リングを 複数の Azure リージョン、または 1 つのリージョン内の複数の可用性ゾーンにまたがって簡単に構成できます。
複数リージョンのデプロイでは、Azure グローバル VNET ピアリングを使用して、異なるリージョンの仮想ネットワークを接続します。 VM が同じリージョン内の別の可用性ゾーンにデプロイされている場合は、その VM は同じ仮想ネットワーク内に存在することができます。
リージョン間のベースライン ラウンドトリップ待機時間を測定することが重要です。 リージョン間のネットワーク待機時間は、リージョン内の待機時間の 10 倍から 100 倍になることがあります。 LOCAL_QUORUM 書き込み整合性を使用した場合、2 番目のリージョンでデータ間に遅延が見られることが予想されます。また、EACH_QUORUM を使用した場合、書き込みのパフォーマンスが大幅に低下します。
特にマルチ DC 環境で Apache Cassandra を大規模に実行する場合、ノード修復が困難になります。 Reaper などのツールを使用すると、大規模な修復を調整することができます (データセンター内のすべてのノードにわたって修復する、データセンターを 1 つずつ修復する、クラスター全体の負荷を制限する、など)。 ただし、大規模なクラスターのノード修復は、まだ完全には解決されていない問題であり、オンプレミスかクラウドかにかかわらずすべての環境に当てはまります。
ノードをセカンダリ リージョンに追加しても、パフォーマンスが直線的にスケーリングするわけではありません。これは、帯域幅と CPU/ディスクの一部のリソースがリージョン間のレプリケーション トラフィックの送受信に使用されるためです。
詳細については、GitHub の「Measuring impact of multi-dc cross-region replication (マルチ DC リージョン間レプリケーションの影響の測定)」を参照してください。
ヒント付きハンドオフの構成
マルチリージョンの Cassandra リングでは、整合性レベルが LOCAL_QUORUM のワークロードを書き込むと、セカンダリ リージョンでデータが失われる可能性があります。 既定では、Cassandra のヒント付きハンドオフは、比較的低い最大スループットと 3 時間のヒント有効期間に制限されています。 書き込み負荷の大きいワークロードの場合、ヒントがレプリケートされる前に削除されないように、ヒント付きハンドオフのスロットルとヒント期間を増やすことをお勧めします。
詳細については、GitHub の「Observations on hinted handoff in cross-region replication (リージョン間レプリケーションのヒント付きハンドオフに関する観察結果)」を参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Arsen Vladimirskiy | プリンシパル カスタマー エンジニア
その他の共同作成者:
- テオ ヴァン クレイ |シニア プログラム マネージャー
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
これらのパフォーマンス結果の詳細については、「Cassandra on Azure VMs Performance Experiments (Azure VM 上の Cassandra のパフォーマンス実験)」を参照してください。
Azure 固有ではなく、一般的な Cassandra 設定の詳細については、以下を参照してください。