DataStax Enterpriseのアンチパターン

DataStax Enterpriseの実稼働インストール環境で効果のない、あるいは逆効果となる実装パターンまたは設計パターンを示します。ほとんどの場合について、正しいパターンを提案しています。

次の実装パターンまたは設計パターンは、DataStax Enterpriseの実稼働インストール環境で効果がない、あるいは逆効果となります。ほとんどの場合について、正しいパターンを提案しています。

ストレージ・エリア・ネットワーク

DataStaxでは、オンプレミス・デプロイにSANストレージを使用しないことを強く推奨しています。

注: クラウドでの保管は機能がまったく異なり、問題はありません。

SANストレージは、Enterprise IT環境ではよく使用されますが、分散データベースと組み合わせて使用することは、さまざまな理由から困難でコストがかかりすぎるアーキテクチャーであることが明らかになっています。理由としては、以下が挙げられます。

SAN ROI（投資収益率）は、資本支出とエンジニアリング・リソースの点で、DataStax Enterpriseの投資収益率に伴って増えるわけではありません。
分散アーキテクチャーでは、SANにより一般にボトルネックと単一障害点がもたらされてしまいますが、これはデータベースのIOが配列コントローラーの維持能力を超えることがよくあるためです。
外部ストレージでは、高速ネットワークおよびSSDと組み合わせても、すべての操作で遅延が発生します。
ヒープ圧力が増しますが、これは保留中のI/O操作に時間が余計にかかるためです。
SANトランスポートが、操作を内外のDataStax Enterpriseトラフィックと共有すると、ネットワークが飽和してしまい、ネットワーク可用性問題が発生しかねません。

これらの要因が1つに合わさると、実稼働環境で解決が困難な問題が引き起こされる可能性があります。特に、SANでDataStax Enterpriseをデプロイする新規ユーザーは、最初に適切な方法を策定し、実稼働環境で問題になる前に、十分なエンジニアリング・リソースを割り当ててこれらの問題点を突き止める必要があります。たとえば、稼働率やSANファイバー飽和など、すべての主要なスケーリング要素について、適切な方法が必要になります。

注意: それでもSANを使用する予定がある場合は、推奨されない理由の詳細についてDataStaxサービス・チームにお問い合わせください。

ネットワーク接続ストレージ

DataStaxでは、NAS（Network Attached Storage：ネットワーク接続ストレージ）デバイスにSSTableを格納することを推奨していません。NASデバイスを使用すると、読み取りと書き込みの両方で生じる高水準のI/O待ち時間に起因して、しばしばネットワーク関連のボトルネックが生じます。これらのボトルネックの原因には、以下が含まれます。

ルーター・レイテンシー
ノードのネットワーク・インターフェイス・カード（NIC）
NASデバイスのNIC

重要: NASを使用する必要がある場合は、DataStaxサービス・チームにご連絡ください。

CPU周波数スケーリング

最新のLinuxシステムには、CPU周波数スケーリングまたはCPU速度スケーリングと呼ばれる機能があります。この機能により、サーバーのクロック速度を動的に調整して、要求や負荷が低いときはサーバーを低いクロック速度で実行できます。これにより、サーバーの消費電力と発熱量（冷却コストに大きな影響を与える）が低減されます。残念ながら、スループットが低速で上限に達する可能性があるため、この動作はDataStax Enterpriseを実行しているサーバーに悪影響を及ぼします。

詳細については、「CPU周波数スケーリングを無効にする」を参照してください。

過剰なヒープ・スペース・サイズ

この情報は、単一トークン・アーキテクチャーにのみ適用されます。仮想ノードには適用されません。「Java仮想マシンの調整」を参照してください。

単一トークン・アーキテクチャーのデプロイにおけるDSEのラック機能

この情報は、単一トークン・アーキテクチャーにのみ適用されます。仮想ノードには適用されません。「データ分散およびレプリケーションについて」を参照してください。

全クラスターに対して1つのラックを定義するのが、最も簡単で一般的な実装方法です。複数のラックは、以下の理由から避けることを推奨します。

ラックは交互の順番になるように編成する必要があるというラック要件を、ほとんどのユーザーは無視するか忘れがちです。この順序によって、データが安全かつ適切に分散されます。
多くのユーザーは、ラック情報を効果的に使用していません。たとえば、ノードと同じ数のラックをセットアップする（または、利点のない似たようなシナリオ）などです。
ラックを使用しているときにクラスターを拡張するのは、煩雑な作業です。手順には、通常、いくつかのノードの移行が伴い、ラックによってデータが適切かつ平等に分散されなければなりません。クラスターをすぐに拡張する必要があるとき、ラックに煩わされるべきではありません。

複数のラックを適切に使用するには：

各ラックに同じ数のノードを使用します。
ラックを使用するとき、ノードが交互に異なるラックに配置されるようにします。ラック機能には、迅速に、完全に機能するクラスター拡張ができるというメリットがあります。クラスターが安定したら、ノードを交換したり適切に移動したりして、確実に各ノードがラックに対して交互になるようにリングに配置されるようにします。

SELECT ...INまたはインデックスの検索

SELECT ...INおよびインデックス検索（従来のセカンダリ・インデックス）は、特定のシナリオ以外では避けることを推奨します。「SELECT」の「INを使用すべきでない場合」の項および「インデックス作成」の「インデックスを使用すべきでない場合」の項を参照してください。

バイト順序指定パーティショナーの使用

バイト順序指定パーティショナー（BOP：Byte Ordered Partitioner）は推奨されません。

代わりに仮想ノードを使用してください。vnodeを使用すると、各ノードが、クラスター全域に分散される個別の小さなトークン範囲を多数所有できるようになります。vnodeを使用することで、トークンの生成およびノードへのトークンの割り当ての手間が不要になります。vnodeを使用しない場合は、これらのパーティショナーの使用が推奨されます。なぜなら、すべての書き込みがキーのハッシュに対して発生するため、リング全体のトークン範囲の間で分散されるからです。これらのパーティショナーは、キーのハッシュ値を使用して、正しいトークンにキーを配置することによってクラスターに均等にデータが分散されるようにします。

書き込み前の読み取り

読み取り要求は、通常、求めるものがキャッシュになければディスクに複数回アクセスするので時間を要します。書き込み前に読み取りを必要とする作業フローでは、この小さなレイテンシーがスループット全体に影響することがあります。データベースのすべての書き込みI/Oはシーケンシャルなので、データ・サイズやキー分散にかかわらず、パフォーマンスにほとんど差はありません。

ロード・バランサー

データベースは、ロード・バランサーが不要なように設計されています。DataStax Enterpriseとクライアントの間にロード・バランサーを置くと、パフォーマンス、コスト、可用性、デバッグ、テスト、拡張性などに悪影響を与えます。JavaやPythonのDataStax Enterprise用ドライバーなどの高レベルのクライアントは、ロード・バランス機能を直接実装しています。使用可能なドライバーについては、「DataStaxドライバー」を参照してください。

テストが不十分な場合

拡大規模および実稼働環境の負荷でのテストを必ず行ってください。これは、アプリケーションを運用したときにシステムが正しく機能するかどうかを確かめる最良の方法です。テストから収集する情報は、将来の拡張計算に必要な、ノードあたりのスループットの最良の目安となります。

正しくテストをするには、「プロダクション前のDataStax Enterpriseクラスターのテスト」を参照してください。また、優れたテスト例を示す「Netflix case study」もご覧ください。

テーブルが多すぎる場合

クラスター内のテーブルが多すぎると、重大なパフォーマンス低下の原因となる場合があります。パフォーマンスはその他さまざまな要因の影響を受けるため、汎用のテーブルしきい値を特定するのは困難ですが、DataStaxでは以下のガイドラインを提供しています。

警告しきい値：200テーブル。このしきい値を超えてもクラスターはスムーズに実行される可能性がありますが、お使いのデータベースがこの警告しきい値を超えたら、監視を開始してアーキテクチャーの再構築を計画する時期が来たとお考えください。可能であれば、使用していない、または使用頻度の低いテーブルを削除してください。
エラーしきい値：500テーブル。テーブル数が500を超えるクラスターでは、メモリー使用量の多さとコンパクションに関連した（しかしこれに限定されない）課題などの問題およびエラーが想定されます。

注: このテーブルしきい値は、JVMヒープとそのバイト数に追加の依存関係があります。各テーブルは、約1 MBのメモリーを使用します。影響がある各テーブルごとに、JVMヒープにmemtable表現ができます。大きいデータ・モデルを持つテーブルでは、メモリーにかかる負荷が大きくなります。各キースペースもJVMメモリーのオーバーヘッドが追加される原因となるため、キースペースが多いために、テーブルしきい値が下がる場合もあります。

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：ネットワーク接続のリストを表示します。接続は帯域幅使用量で順番付けられ、最もトラフィック量が多いホストのペアがリストの最上位に表示されます。このツールによって、ネットワーク輻輳の原因となるホストの識別が容易になります。

推奨設定なしの実行

必ず推奨設定を使用してください。

DSE Tiered Storage（DSE階層化ストレージ）テーブルでのDSE Searchの使用

DataStaxでは、DSE Tiered Storage（DSE階層化ストレージ）テーブルでDSE Searchを使用することを推奨していません。DSE Tiered Storage（DSE階層化ストレージ）で使用されるデータ・セットは非常に大きくなる可能性があります。DSE Tiered Storage（DSE階層化ストレージ）テーブルに適した一般的なユース・ケースについては、DataStaxブログ投稿に記載されています。