Amazon EC2クラスターの計画

実稼働のCassandraクラスターをAmazon EC2にデプロイするための重要な情報。

Amazon EC2クラスターを計画する前に、『ユーザー・ガイド』を参照してください

DataStax AMIのデプロイ 

DataStax AMIは、1つのリージョンおよびアベイラビリティー・ゾーンのみを対象としています。複数のリージョンおよびアベイラビリティー・ゾーンにまたがるEC2クラスターについては、「複数のリージョンおよびアベイラビリティー・ゾーンにまたがるEC2クラスター」を参照してください。

信頼できる入手先からのAMIを使用 

信頼できる入手先からのAMIのみを使用してください。任意に入手したAMIはセキュリティ上のリスクをもたらし、EC2インストールの構成方法に起因して、予期しているよりもパフォーマンスが低い可能性があります。以下は、信頼できるAMIの例です。

複数のリージョンおよびアベイラビリティー・ゾーンにまたがるEC2クラスター 

複数のリージョンおよびアベイラビリティー・ゾーンにまたがるEC2クラスターを作成する場合は、OpsCenterを使用してクラスターをセットアップしてください。サポートされているプラットフォームのいずれかを使用できます。すべてのノードに同じプラットフォームを使用するのがベスト・プラクティスです。DataStax AMIを使用してクラスターがインスタンス化されている場合は、追加ノードとしてUbuntuを使用してください。Ec2MultiRegionSnitchを使用して複数データ・センター・クラスターとしてクラスターを構成してください。以下のトピックでは、OpsCenterのプロビジョニングについて説明します。

EC2上のCassandra実稼働クラスター 

EC2上のCassandra実稼働クラスターの場合は、以下のガイドラインに従ってインスタンスの種類を選択します。

  • Development and light production:m3.large
  • Moderate production:m3.xlarge
  • SSD production with light data:c3.2xlarge
  • Largest heavy production:m3.2xlarge (PV)またはi2.2xlarge (HVM)
注: Cassandraで使用するm1インスタンス・タイプとm3インスタンス・タイプの主な違いは、m3には高速で小型のSSDドライブが搭載されており、m1には低速で大型の回転式ドライブが搭載されている点です。レイテンシーSLAのトレランスを高く設定しており、クラスターのサイズを小さくする必要がある場合はm1インスタンス・タイプを使用しますが、もう一方も使用できます。ワークロードが大きい場合は、m3インスタンス・タイプを適切なサイズのクラスターとともに使用します。

実稼働環境に推奨されるEBSボリューム 

実稼働環境のワークロードには、SSDベースの汎用ボリューム（GP2）またはプロビジョンされたIOPSボリューム（PIOPS）が適しています。これらのボリューム・タイプは、一貫性のある低遅延パフォーマンスを発揮するように設計されています。
GP2 PIOPS
  • ほとんどのワークロードにとって、最善の選択。3.5 TBを超えるボリュームがインスタンスに接続されているときに、10,000件のIOPSが保証されるという利点があります。
  • 遅延が1桁のミリ秒台に収まるように設計されています。
  • 時間の99.0%で、プロビジョンされたパフォーマンスを発揮するように設計されています。
  • 遅延が1桁のミリ秒台に収まるように設計されています。
  • 時間の99.9%で、プロビジョンされたパフォーマンスを発揮するように設計されています。

マグネティック（標準）EBSボリュームは推奨されない 

EBSボリュームは、以下の理由でCassandraデータ・ストレージ・ボリュームに推奨されません。

  • EBSボリュームは標準パケットとネットワーク・スループットをめぐって直接競合します。この競合の結果、ネットワーク・リンクを飽和状態にすると、EBSスループットで障害が発生する可能性が高くなります。
  • EBSボリュームのパフォーマンスは不確かです。I/Oパフォーマンスが極めて遅く、全クラスターが応答不能になるまでシステムが読み取りおよび書き込みが滞る原因となります。
  • ホストあたりのEBSボリュームの数を増やすことにより容量を追加してもスケールは確保できません。効率的なバッファ・キャッシュを維持し、管理する必要があるデータのすべてに対する要求に同時に応えるためのシステムの能力を簡単に上回ってしまいます。
注: Cassandraデータストレージには、エファメラルinstance-storeデバイスのみを使用してください。

エフェメラルのパフォーマンスとEBSパフォーマンスの対比に関連する情報およびグラフについては、ブログ記事の「Systematic Look at EC2 I/O」を参照してください。

ディスク・パフォーマンスの最適化 

マウントされているドライブの高ディスク・パフォーマンスを確保するには、実稼働環境で使用する前にすべてのドライブの場所にデータを1回書き込むことによりドライブをウォーミングアップしておくことを推奨します。EC2の状態によっては、かなりのスループット向上を期待できます。Amazon Elastic Compute Cloudドキュメントの「Optimizing Disk Performance」を参照してください。

Cassandra 1.2以降のストレージに関する推奨事項 

Cassandra 1.2以降はJBOD（just a bunch of disks）をサポートしています。JBODは、ディスク・アレイの部分的障害に対する耐性に優れています。cassandra.yamlファイルの中でdisk_failure_policyを使用して構成してください。追加情報は、「Handling Disk Failures In Cassandra 1.2」ブログと「JBODを使用した単一ディスク障害からの復旧」にあります。

注: Cassandra JBODのサポートにより、標準ディスクを使用できます。ただし、RAID0は、各ブロックを別のデバイスに振り分けるため、RAID0の方がより良いスループットを提供できる場合があります。なぜなら、書き込みがディスクに対してシーケンシャルに行われるのではなく並行して行われるからです。
cassandra.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/cassandra/cassandra.yaml
tarボール・インストール install_location/resources/cassandra/conf/cassandra.yaml
Windowsインストール C:\Program Files\DataStax Community\apache-cassandra\conf\cassandra.yaml

Cassandra 1.1以前のストレージに関する推奨事項 

エフェメラル・ディスクをRAID 0構成にします。その後、データ・ディレクトリーとコミット・ログを一緒にそのボリュームに配置します。その方が、共有リソースであるルート・ボリュームにコミット・ログを置くよりも良いということが実践において証明されています。データの冗長性を高めるために、複数のアベイラビリティー・ゾーンにわたってCassandraクラスターをデプロイするか、EBSボリュームを使用してCassandraバックアップ・ファイルを格納するかを検討してください。