Cassandraにおけるアンチパターン
Cassandraの実稼働インストール環境で効果のない、あるいは逆効果となる実装パターンまたは設計パターンを示します。ほとんどの場合について、正しいパターンを提案しています。
Cassandraの実稼働インストール環境で効果のない、あるいは逆効果となる実装パターンまたは設計パターンを示します。ほとんどの場合について、正しいパターンを提案しています。
ストレージ・エリア・ネットワーク
SANストレージは、オンプレミス・デプロイには推奨されません。
- SAN ROI（投資収益率）は、資本支出とエンジニアリング・リソースの点で、Cassandraの投資収益率に伴って増えるわけではありません。
- 分散アーキテクチャーでは、SANにより一般にボトルネックと単一障害点がもたらされてしまいますが、これはCassandraのIOが配列コントローラーの維持能力を超えることがよくあるためです。
- 外部ストレージでは、高速ネットワークおよびSSDと組み合わせても、すべての操作で遅延が発生します。
- ヒープ圧力が増しますが、これは保留中のI/O操作に時間が余計にかかるためです。
- SANトランスポートが、操作を内外のCassandraトラフィックと共有すると、ネットワークが飽和してしまい、ネットワーク可用性問題が発生しかねません。
これらの要因が1つに合わさると、実稼働環境で解決が困難な問題が引き起こされてしまう可能性があります。特に、SANでCassandraをデプロイする新規ユーザーは、最初に適切な方法を策定し、実稼働環境で問題になる前に、十分なエンジニアリング・リソースを割り当ててこれらの問題点を突き止める必要があります。たとえば、稼働率やSANファイバー飽和など、すべての主要なスケーリング要素について、方法が必要になります。
「Impact of Shared Storage on Cassandra（共有ストレージがCassandraに及ぼす影響）」では、パフォーマンスがどれほど深刻な影響を受ける可能性があるのかに関する評価指標について、詳しく説明されています。
ネットワーク接続ストレージ
NAS（Network Attached Storage：ネットワーク接続ストレージ）デバイスにSSTableを格納することは推奨されません。NASデバイスを使用すると、読み取りと書き込みの両方で生じる高水準のI/O待ち時間に起因して、しばしばネットワーク関連のボトルネックが生じます。これらのボトルネックの原因には、以下が含まれます。
- ルーターのレイテンシー
- ノードのネットワーク・インターフェイス・カード（NIC）
- NASデバイスのNIC
NASを使用する必要がある場合は、DataStaxの技術担当者にご連絡ください。
過剰なヒープ・スペース・サイズ
DataStaxでは、ほとんどの場合、デフォルトのヒープ・スペース・サイズの使用を推奨しています。このサイズを超えると、Java仮想マシン（JVM）によるなめらかなガーベージ・コレクション（GC）の実行が損なわれる可能性があります。以下の表に、あるCassandraユーザーから報告されたヒープ・スペースのパフォーマンスの比較を示します。
| ヒープ | CPUの使用率 | 1秒あたりのクエリー数 | レイテンシー |
|---|---|---|---|
| 40 GB | 50% | 750 | 1秒 |
| 8 GB | 5% | 8500（最大限度以下） | 10 ms |
ヒープ・サイズの決定方法については、「Javaリソースの調整」を参照してください。
Cassandraのラック機能
この情報は、仮想ノードではなく、単一トークン・アーキテクチャーにのみ該当します。
全クラスターに対して1つのラックを定義するのが、最も簡単で一般的な実装方法です。複数のラックは、以下の理由から避けることを推奨します。
- ラックは交互の順番になるように編成する必要があるというラック要件を、ほとんどのユーザーは無視するか忘れがちです。この順序によって、データが安全かつ適切に分散されます。
- 多くのユーザーは、ラック情報を効果的に使用していません。たとえば、ノードと同じ数のラックをセットアップする（または、利点のない似たようなシナリオ）などです。
- ラックを使用しているときにクラスターを拡張するのは、煩雑な作業です。通常、その手順にはいくつかのノードの移動が含まれ、各ラックにデータを確実に正しく均等に分散させる必要があります。クラスターをすぐに拡張する必要があるとき、ラックに煩わされるべきではありません。
ラックを適切に使用するには：
- 各ラックに同じ数のノードを使用します。
- ラックを使用するとき、ノードが交互に異なるラックに配置されるようにします。これにより、Cassandraのラック機能の利点を維持しながら、迅速に、完全に機能するクラスター拡張が可能になります。クラスターが安定したら、ノードを交換したり適切に移動したりして、確実に各ノードがラックに対して交互になるようにリングに配置されるようにします。
また、Cassandra 1.1ドキュメントの「About Replication in Cassandra」も参照してください。
SELECT ...INまたはインデックスの検索
SELECT ...INおよびインデックス検索（従来のセカンダリ・インデックス）は、特定のシナリオ以外では避けることを推奨します。CQL for Cassandra 2.2.xの「SELECT」の「INを使用すべきない場合」の項および「インデックスの作成」の「インデックスを使用すべきでない場合」の項を参照してください。
バイト順序指定パーティショナーの使用
バイト順序指定パーティショナー（BOP：Byte Order Partitioner）は推奨されません。
仮想ノード（vnode）を使用し、さらにMurmur3Partitioner（デフォルト）またはRandomPartitionerのいずれかを使用してください。vnodeを使用すると、各ノードが、クラスター全域に分散される個別の小さなトークン範囲を多数所有できるようになります。vnodeを使用することで、トークンの生成およびノードへのトークンの割り当ての手間が不要になります。vnodeを使用しない場合は、これらのパーティショナーの使用が推奨されます。なぜなら、すべての書き込みがキーのハッシュに対して発生するため、リング全体のトークン範囲の間で分散されるからです。これらのパーティショナーは、キーのハッシュ値を使用して、正しいトークンにキーを配置することによってクラスターに均等にデータが分散されるようにします。
書き込み前の読み取り
読み取り要求は、通常、求めるものがキャッシュになければディスクに複数回アクセスするので時間を要します。書き込み前に読み取りを必要とする作業フローでは、この小さなレイテンシーがスループット全体に影響することがあります。Cassandraのすべての書き込みI/Oはシーケンシャルなので、データ・サイズやキー分散にかかわらず、パフォーマンスにほとんど差はありません。ロード・バランサー
Cassandraは、ロード・バランサーが不要なように設計されています。CassandraとCassandraクライアントの間にロード・バランサーを置くと、パフォーマンス、コスト、可用性、デバッグ、テスト、拡張性などに悪影響を与えます。JavaやPythonのCassandra用ドライバーなどの高レベルのクライアントは、ロード・バランス機能を直接実装しています。
不十分なテスト
拡大規模および実稼働環境の負荷でのテストを必ず行ってください。これは、アプリケーションを運用したときにシステムが正しく機能するかどうかを確かめる最良の方法です。テストから収集する情報は、将来の拡張計算に必要な、ノードあたりのスループットの最良の目安となります。
正しくテストをするには、小さなクラスターを用意し、実稼働環境の負荷をかけます。クラスターのパフォーマンスが限界に達するまでに、ノード数に応じた最大のスループットに達します。このクラスター・サイズでの最大スループットを、異なるサイズのクラスターに線形に適用します。次に、結果を外挿（グラフ化）して、実稼働クラスターに必要なスループットを達成できる正しいクラスター・サイズを予測します。これにより、将来要求されるスループットに対する正しいクラスター・サイズを予測できます。「Netflix case study」は、優れたテスト例を示しています。
キースペースまたはテーブルが多すぎる
Cassandraの各キースペースには、JVMメモリーを使用する特定量のオーバーヘッドが存在します。各テーブルは、約1 MBのメモリーを使用します。たとえば、テーブル数が3,500であれば、約3.5 GBのJVMメモリーを使用します。あまりにも多くのテーブルを使用したり、拡張によって多くのキースペースを使用したりすると、メモリー要件が肥大します。妥当な経験則は、1つのクラスター内のテーブル数を多くても1,000に抑えて、できれば500以下を目指すことです。
Linuxに対する不十分な理解
Linuxには、有益なツールが多数用意されています。Linuxの組み込みツールに慣れてください。慣れれば、大いに役立ち、通常の日常的な業務における運用と管理のコストを低減します。ツールとテクニックの主なリストは以下のとおりです。
- 並列SSHおよびクラスターSSH：psshおよびcsshツールを使用して複数のノードに対してSSHアクセスができます。調査やクラスター全体の変更に役立ちます。
- パスワードなしSSH：SSH認証が、公開鍵および秘密鍵を使用して実行されます。これにより、パスワード・アクセスなしでノードからノードに簡単にSSH接続を切り替えられます。より強固なセキュリティが必要な場合は、要塞ホストやVPNを実装できます。
- 便利な一般的なコマンドライン・ツールには、以下が含まれます。
- dstat:すべてのシステム・リソースを即座に表示します。たとえば、ディスク使用量をIDEコントローラーからの割り込みと組み合わせて比較したり、ネットワーク帯域幅数をディスク・スループットと直接比較（同じ間隔で）したりすることができます。
- top：CPUプロセッサーのアクティビティをリアルタイムで監視できます。
- システム・パフォーマンス・ツール：iostat、mpstat、iftop、sar、lsof、netstat、htop、vmstat、および類似ツールは、システム動作のさまざまなメトリックを収集して報告できます。
- vmstat：プロセス、メモリー、ページング、ブロックI/O、トラップ、およびCPUアクティビティについての情報を報告します。
- iftop：ネットワーク接続のリストを表示します。接続は帯域幅使用量で順番付けられ、最もトラフィック量が多いホストのペアがリストの最上位に表示されます。このツールによって、ネットワーク輻輳の原因となるホストの識別が容易になります。
推奨設定なしの実行
Cassandraドキュメントの推奨設定を使用してください。
ハードウェアを購入する前に、ハードウェアおよび推奨事項を説明している「Planning a Cassandra cluster deployment」ドキュメントをお読みください。