Amazon EC2でのDataStax Enterpriseクラスターの計画

実稼働のDataStax EnterpriseクラスターをAmazon EC2にデプロイする際の情報。

Amazon EC2クラスターを計画する前に、「Amazon EC2 - 仮想サーバー・ホスティング」をお読みください。

重要: ここで紹介する推奨事項はガイドラインです。実装が予想どおりに機能するよう、DataStaxではDataStaxサービス・チームにご相談いただき、デプロイする前に構成を十分にテストすることを推奨しています。

DataStax AMIのデプロイ

DataStax（DSE）ではDataStax ComboAMIのホストを終了しました。DataStax Enterpriseは、以下の2つの方法でインストールできます。

サポートされるプラットフォームや信頼できる入手先からのAMIを使用してインスタンスを作成します。次にご使用のプラットフォームに適したインストール方法を使用します。
バージョン4.7以降のDataStax Enterpriseクラスターを簡単にプロビジョニングするには、DSE OpsCenterのLifecycle Managerを使用します。
1. サポートされるプラットフォームや信頼できる入手先からのAMIを使用してインスタンスを作成します。
2. Lifecycle Managerを使用して、クラスターをプロビジョニングおよび構成します。

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

サポートされるプラットフォームや信頼できる入手先からのAMIのみを使用してください。信頼性の低いAMIはセキュリティ上のリスクをもたらし、EC2インストールの構成方法によっては予想したパフォーマンスを下回る可能性もあります。以下は、信頼できるAMIの例です。

複数のリージョンおよびアベイラビリティー・ゾーンでのEC2のデプロイ

これらのデプロイについては、各ノードでサポートされているプラットフォームを使用してください。

すべてのノードに同じプラットフォームを使用するのがベスト・プラクティスです。DataStax AMI（サポート廃止）を使用してクラスターがインスタンス化されている場合は、追加ノードとしてUbuntuを使用してください。Amazon EC2マルチリージョン・スニッチを使用し、クラスターを複数データ・センター・クラスターとして構成します。

EC2実稼働クラスターのガイドライン

DSEでは、ノードごとに最低10,000件のIOPS（1秒あたりの入力/出力操作）が必要です。このパフォーマンス・レベルを達成するためのAWSストレージの選択肢は以下のとおりです。

EBS汎用SSD（gp2）ボリューム: DSEで必要とされるIOを達成するには、gp2ではGBごとに3 IOPSが提供されるため、使用している実際の領域に関係なく、3.5 TBのボリュームを使用する必要があります。
Amazon EBSプロビジョンされたIOPS SSD（io1）ボリューム: 10,000件のプロビジョンされたIOPS（PIOPS）を持つEBS io1は、少ないボリュームでgp2と同じパフォーマンス・レベルを発揮しますが、コストが増大します。
直接接続したローカルSSD: エファメラル、またはインスタンスSSDとも呼ばれます。このストレージ型を使用すると、i3インスタンスで最適なコスト・パフォーマンスが得られます。価格については、Amazon AWSを参照してください。

インスタンスの種類を選択するには、以下のガイドラインを使用してください。

トランザクション・ノードのみで使用量が非常に軽量な、小規模な実稼働環境：m4.2xlarge（最小限）。開発にも適しています。
中規模な実稼働環境：i3.4xlarge
大規模な実稼働環境：i3.8xlarge
DSE SearchノードとDSE Analyticノード：i3.4xlargeまたはi3.8xlarge

注: EC2では、それぞれのvCPUがIntel Xeonコアのハイパースレッドとなります。これは2つの仮想コアが1つの物理コア上に存在することを意味します。たとえばi3.8xlargeインスタンスの種類には32個のvcCPUがありますが、これは16個の物理コアと同等です。

m4インスタンスの種類に推奨されるEBSボリューム

SSDベースの汎用ボリューム（GP2）またはプロビジョンされたIOPSボリューム（io1）は、m4インスタンス（使用量が非常に少ないトランザクション・ノード）を使用する際の実稼働環境のワークロードに適しています。これらのボリューム・タイプは、一貫性のある低遅延パフォーマンスを発揮するように設計されています。


GP2	PIOPS
ほとんどのワークロードにとって、最善の選択。3.5 TBを超えるボリュームがインスタンスに接続されているときに、10,000件のIOPSが保証されるという利点があります。遅延が1桁のミリ秒台に収まるように設計されています。時間の99.0%で、プロビジョンされたパフォーマンスを発揮するように設計されています。	遅延が1桁のミリ秒台に収まるように設計されています。時間の99.9%で、プロビジョンされたパフォーマンスを発揮するように設計されています。

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

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

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

注: DataStax Enterpriseデータ・ストレージには、エフェメラルinstance-storeまたは推奨されるEBSボリューム・タイプのみを使用してください。

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

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

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

ストレージに関する推奨事項

DataStax EnterpriseではJBOD（just a bunch of disks）をサポートしています。JBODは、ディスク・アレイの部分的障害に対する耐性に優れています。cassandra.yamlでdisk_failure_policyを構成します。「JBODを使用した単一ディスク障害からの復旧」を参照してください。

注: JBODのサポートにより、標準ディスクを使用できます。ただし、RAID0は、各ブロックを別のデバイスに振り分けるため、RAID0の方がより良いスループットを提供できる場合があります。なぜなら、書き込みがディスクに対してシーケンシャルに行われるのではなく並行して行われるからです。

EC2セキュリティ・グループ

DataStax EnterpriseをEC2上にデプロイするには、同じセキュリティ・グループの他のノードに対してポートを開くセキュリティ規則を作成する必要があります。EC2セキュリティ・グループは、クラスター内で開くプロトコルとポートを選択できるようにするファイアウォールとしての役割を担います。プロトコルとポートはIPアドレスの範囲またはセキュリティ・グループによって指定できます。詳細については、セキュリティ・グループのAmazon EC2ヘルプを参照してください。

警告: ソースIPを0.0.0.0/0に指定すると、すべてのIPアドレスからの着信トラフィックに対して外部からアクセスできるポートが開かれます。データ喪失のリスクが高くなります。

「DataStax Enterpriseポートのセキュリティ保護に関する表」には、ノード間通信とクライアント通信に対して開かれるポートの一覧が記載されています。

注: 一般的に、マシン間にファイアウォールがある場合、ネットワーク全体にわたってJMXを実行してセキュリティを維持するのは困難です。これは、JMXがポート7199に接続され、ハンドシェイクして、1024以上の範囲内にあるポートを使用するためです。SSHを使用してコマンドをリモートで実行するのではなく、ローカルでJMXに接続するか、DSE OpsCenterを使用してください。