Amazon Web Services ブログ

Amazon EC2 での Apache Cassandra の実行のためのベストプラクティス

Apache Cassandra は一般的に使用されているハイパフォーマンスの NoSQL データベースです。現在 Cassandra オンプレミスを保守している AWS のカスタマーは、Amazon EC2 で Cassandra を実行することによるスケーラビリティ、信頼性、セキュリティ、経済的な恩恵を利用したいと考えているかもしれません。

Amazon EC2 と Amazon Elastic Block Store (Amazon EBS) は、AWS Cloud でセキュアでサイズ変更可能な計算能力およびストレージを提供します。組み合わせられると、Cassandra を要件に従って容量をスケールすることができます。可能性のあるデプロイトポロジーの数を考えると、ユースケースに対して最も適切な戦略を選択することは、必ずしも常に自明であるわけではありません。

この記事では、3 つのCassandra デプロイメントオプションを概説するだけではなく、以下の分野のユースケースに対するベストプラクティスを判別するための指針を与えます。

  • Cassandra リソースの概要
  • デプロイの考察
  • ストレージオプション
  • ネットワーキング
  • 高可用性と弾力性
  • メンテナンス
  • セキュリティ

DynamoDB

AWS で Cassandra を実行するためのベストプラクティスに移動する前に、Cassandra クラスタを管理する代わりに、DynamoDB を使用することにした多くのカスタマーがいることを述べなければなりません。DynamoDB は完全管理され、サーバーレスで、マルチマスタのクロスリージョンレプリケーションの休止中の暗号化、および管理されたバックアップとリストアを提供します。AWS Identity and Access Management (IAM) により、DynamoDB カスタマーはデータセキュリティニーズに対してきめ細かなアクセスコントロールを可能にします。

何年もの間、大規模な Cassandra クラスタを使用してきたいくつかのカスタマーは、DynamoDB に移動し、Cassandra クラスタを管理し、高可用性と耐久性を自分自身で維持していく複雑性を排除しました。Gumgum.com は DynamoDB に移行し、大幅な節約を確認した 1 つのカスタマーです。 詳細については、Hosted CassandraからAmazon DynamoDBへの移行：年間60％のコスト削減へと飛躍を参照してください。

AWS はオプションを提供するため、NoSQL Cassandra データベースを実行するか、完全に管理されたサーバーレスの DynamoDB データベースに移行するか、いずれの場合でも対象となります。

Cassandra リソースの概要

以下に、標準的な Cassandra リソースの短い紹介と AWS インフラストラクチャで実装する方法を示します。Cassandra または AWS デプロイメントをすでにご存じの場合、これはリフレッシャーとして利用できる場合があります。

リソース Cassandra AWS
クラスタ

単一の Cassandra デプロイメント。

 

これは一般的に複数の物理的な場所、キースペース、および物理的サービスから構成されます。

 論理的なデプロイメントは、AWS CloudFormation StackSet にマッピングされる AWS で構築され、それは Cassandra をデプロイするために 1 つから多くの CloudFormation スタックから構成されます。
データセンター 単一のレプリケーショングループとして構成されるノードのグループ。

AWS で構築される論理的デプロイメント。

 

データセンターは、Amazon EC2 インスタンス、ネットワーキング、ストレージ、およびセキュリティリソースから構成される単一の CloudFormation スタックでデプロイされます。
ラック

サーバーの集合。

 

少なくとも １ 個のラックから構成されるデータセンター。Cassandra は異なるラックにレプリカを配置しようとします。

 単一のアベイラビリティーゾーン。
サーバー/ノード Cassandra ソフトウェアを実行中の物理的な仮想マシン。 EC2 インスタンス
トークン 概念的に、クラスタにより管理されるデータは、リングとして表します。このリングはその後、ノードの数と等しい範囲に分割されます。1 つまたは複数のデータの範囲を対象とする各ノード。各ノードがトークンにより割り当てられ、それは本質的に範囲からのランダム数です。トークン値は、リングとそのデータの範囲のノードの位置を判別します。 Cassandra 内で管理されています。
仮想ノード (vnode) データの範囲の保存を担当します。各 vnode は、リングで 1 つのトークンを受け取ります。クラスタ (デフォルトによる) は 256 個のトークンから構成され、Cassandra データセンターのすべてのサーバー全体に均等に分散されます。 Cassandra 内で管理されています。
レプリケーション係数 クラスタ全体のレプリカの合計数。 Cassandra 内で管理されています。

デプロイの考察

Amazon EC2 で Cassandra をデプロイすることの多くの利点の 1 つは、多くのデプロイメントタスクを自動化できることです。さらに、AWS はクラウド環境ですべてのインフラストラクチャーリソースを説明し、プロビジョニングできるようにする CloudFormations などのサービスを含みます。

各 Cassandra リングを 1 つの CloudFormation テンプレートで調整することをお勧めします。複数の AWS リージョンでデプロイする場合、これらのスタックを管理するために、CloudFormation StackSet を使用できます。すべてのメンテナンスアクション (スケール、アップグレード、バックアップ) は、AWS SDK によりスクリプトされる必要があります。これはメンテナンス中にオンデマンドで呼び出すことができるスタンドアロンの AWS Lambda 関数として存在する場合があります。

デプロイメントパターン

このセクションで、当社は Amazon EC2 の Cassandra に対して使用可能なさまざまなデプロイメントオプションについて取り上げます。デプロイの成功はこれらのオプションを思慮深く考察することから始まります。データの量、ネットワーク環境、スループット、およびアベイラビリティーについて考えます。

  • 単一の AWS リージョン、3 つのアベイラビリティ―ゾーン
  • アクティブ-アクティブ、マルチリージョン
  • アクティブ-スタンバイ、マルチリージョン

単一リージョン、3 つのアベイラビリティ―ゾーン

このパターンで、1 つの AWS リージョンと 3 つのアベイラビリティ―ゾーンで Cassandra クラスタをデプロイします。クラスタの 1 つのリングのみがあります。3 つのゾーンで EC2 インスタンスを使用することで、レプリカはすべてのゾーンで均等に分配されることを保証します。

すべてのアベイラビリティ―ゾーン全体でデータの均等な分配を保証するために、3 つすべてのアベイラビリティ―ゾーンで EC2 インスタンスを分配することをお勧めします。クラスタの EC2 インスタンスの数は、3 つの倍数です (レプリケーション係数)。

このパターンは、アプリケーションがあるリージョンにデプロイされている場合や、データのプライバシーやその他の法的要件により、異なる地域のデプロイが同じリージョンに制限される場合に適しています。

長所 短所

●    高い可用性、1 つの アベイラビリティーゾーンの障害を抑止できます。

●    単純なデプロイメント

 ●    リージョン内の多くのリソースが断続的な障害を経験している場合に保護しません。

 

アクティブ-アクティブ、マルチリージョン

このパターンで、2 つの異なるリージョンで 2 つのリングを展開し、それらをリンクします。2 つのリージョンの VPC はピアリングされ、2つのリング間でデータを複製できます。

2つのリージョンの2つのリングは、本質的に同一で、ノード数、インスタンスタイプ、およびストレージ構成が同じであることを推奨します。

このパターンは、Cassandra クラスタを使用するアプリケーションが複数のリージョンにデプロイされている場合に最適です。

長所 短所

●     フェイルオーバーの間はデータは失われません。

●    高い可用性。リージョン内の多くのリソースが断続的な障害を経験している場合に持続できます。

●    読み/書きトラフィックは、低いレイテンシーと高いパフォーマンスに使用するために、最も近いリージョンにローカライズできます。

●    非常に高い運用オーバーヘッド

●    2 番目のリージョンがコストを効率的に倍増

 

アクティブ-スタンバイ、マルチリージョン

このパターンで、2 つの異なるリージョンで 2 つのリングを展開し、それらをリンクします。2 つのリージョンの VPC はピアリングされ、2つのリング間でデータを複製できます。

しかし、2 番目のリージョンはアプリケーションからのトラフィックを受け取りません。災害復旧の理由のための二次的な場所としてのみ機能します。プライマリリージョンは使用できません。2 番目のリージョンがトラフィックを受け取ります。

2つのリージョンの2つのリングは、本質的に同一で、ノード数、インスタンスタイプ、およびストレージ構成が同じであることを推奨します。

このパターンは、Cassandra クラスタを使用するアプリケーションが低いリカバリポイント目標 (RPO) とリカバリ時間目標 (RTO) を必要とするときに最も適しています。

長所 短所

●     フェイルオーバーの間はデータは失われません。

●     高い可用性。障害児に持続するか、リージョン全体を区画化します。

●    高い運用オーバーヘッド。

●     結果整合性のための書き込みに対する高いレイテンシー。

●    2 番目のリージョンがコストを効率的に倍増。

ストレージオプション

オンプレミスのデプロイメントで、Cassandra デプロイメントはデータの保存にローカルディスクを使用します。EC2 インスタンスには 2 つのストレージオプションがあります。

ストレージの選択は、Cassandra クラスタによりサポートされるワークロードのタイプに密接に関係しています。インスタンスストアは、ほとんどの汎用目的の Cassandra デプロイメントに最も良く機能します。しかし、特定の読み取りの多いクラスタで、Amazon EBS はより良い選択しとなります。

インスタンスタイプの選択肢は、一般的にストレージのタイプにより決まります。

  • アプリケーションにエフェメラルストレージが必要な場合、ストレージが最適化された (I3) インスタンスが最良のオプションになります。
  • ワークロードが Amazon EBS を必要とする場合、コンピューターで最適化された (C5) インスタンスを使用するのが最良です。
  • Burstable インスタンスタイプ (T2) は、Cassandra デプロイメントの良好なパフォーマンスを提供しません。

インスタンスストア

エフェメラルストレージは、Amazon EC2 インスタンスにローカルです。インスタンスタイプに基づいて、1秒当たり高い入力/出力オペレーション (IOP) を提供する場合があります。SSD ベースのインスタンスストアは、I3 インスタンスで最大 ３．３M IOP をサポートできます。この高いパフォーマンスは、Cassandra などのトランザクションまたは書き込みの多いアプリケーションにとって理想な選択肢にします。

一般的に、インスタンスストレージは、トランザクション、大規模、中規模の Cassandra クラスタにお勧めします。大規模なクラスタの場合、読み/書きトラフィックは、多数のノードにわたって分散されるので、1 つのノードの喪失はあまり影響しません。しかし、小規模なクラスタの場合、障害のあるノードの迅速なリカバリは重要です。

たとえば、100 ノードがあるクラスタの場合、1 ノードの喪失は 3.33% の喪失です (レプリケーション係数が 3 )。同様に、10 ノードのあるクラスタの場合、1 ノードの喪失は 33% 少ない容量です (レプリケーション係数が 3)。

  エフェメラルストレージ Amazon EBS コメント

IOPS

(より高いクエリパフォーマンスに変換します)

 I3 で最大 3.3M

80k/インスタンス

10K/gp2/容量

32K/io1/容量

これは、各ホストのより高いクエリパフォーマンスを導きます。しかし、Cassandra は暗黙のうちに水平スケールに関してうまくスケールします。一般的には、水平スケールを最初に推奨します。次に、特定の問題を軽減するために、垂直にスケールします。

 

注: 3.3M IOPS は、Amazon Linux の 4-KB ブロックサイズで 100% ランダム読み取りで観察されます。
AWS インスタンスタイプ I3 計算の最適化、C5 異なるインスタンスタイプの中から選択できることは、水平および垂直スケーリングのためのCPU、メモリなどの面で利点です。
バックアップとリカバリ カスタム 基本構築ブロックは、AWS から選択できます。

Amazon EBS は明確な優位性をここで提供されます。バックアップ/リストア戦略を確立することは、小さなエンジニアリングの努力です。

a) インスタンスの障害が発生した場合、障害のあるインスタンスからの EBS ボリュームが新しいインスタンスにアタッチされます。

b) EBS ボリュームの障害の場合、データは最後のスナップショットから新しい EBS ボリュームを作成することにより、リストアされます。

Amazon EBS

EBS ボリュームは高い柔軟性を提供し、IOP はストレージのニーズに基づいて構成できます。EBS ボリュームはまた、リカバリ時間の観点でいくらかの明確な優位性も示します。EBS ボリュームはボリューム当たり最大 32K IOPS、RAID 構成のインスタンス当たり最大 80K IOPS をサポートできます。それらは EBS ボリュームを典型的なコモディティディスクドライブより 20 倍信頼性の高いものにする 0.1-0.2％ の年間障害率（AFR）を持っています。

Cassandra のデプロイメントで Amazon EBS を使用する主な利点は、ノードに障害があるか、交換が必要な時のデータ転送トラフィックを大幅に減らすことにあります。交換ノードは、クラスタをかなり早く結合します。しかし、Amazon EBS はデータストレージのニーズに応じて、よりコストがかかる可能性があります。

Cassandra は構成可能な数のインスタンスにわたり、データ区画をレプリケーションすることで、耐障害性を組み込みます。それは、ノードの障害に耐えるこおとができないばかりか、他のレプリカから新しいノードにデータをコピーすることによってもリカバリできます。アプリケーションに応じて、このことは数十ギガバイトのデータをコピーすることを意味する場合があります。これは、リカバリプロセスをさらに遅らせ、ネットワークトラフィックを増やし、リカバリ中に Cassandra クラスタのパフォーマンスに影響を与える可能性があります。

Amazon EBS に保存されたデータは、インスタンスの障害や終了の場合でも持続します。EBS ボリュームに保存されたノードのデータは、そのまま残されるので、EBS ボリュームを新しい EC2 インスタンスにマウントできます。交換ノードのためにレプリケーションされたほとんどのデータはすでに EBS ボリュームで取得可能で、別のブローカーからネットワーク上でコピーする必要はありません。元のブローカーに障害が発生した後で行った変更のみが、ネットワークを通じて転送する必要があります。そのことは、このプロセスを大幅に早くします。

EBS ボリュームは定期的にスナップショットされます。したがって、ボリュームに障害が発生した場合、新しいボリュームを最後の既知の良いスナップショットから作成して、新しいインスタンスにアタッチすることができます。これは、新しいボリュームを作成して、すべてのデータをそれにコピーするよりも早く行うことができます。

ほとんどの Cassandra のデプロイメントでは、3 つのレプリケーション係数が使用されます。しかし、Amazon EBS はフォールトトレランスの対象範囲内で独自のレプリケーションを行います。実際に、EBS ボリュームは一般的なディスクドライブよりも約 20 倍信頼性が高くなっています。したがって、2 つのうちの 1 つのレプリケーション係数を使用する可能性があります。これにより、コストが削減するだけではなく、2 つのアベイラビリティ―ゾーンをもつリージョンでデプロイメントすることができるようになります。

EBS ボリュームは、大量のデータのストレージを必要とする読み取りが多い、小さなクラスタ(ノードが少ない)の場合に推奨されます。Amazon EBS プロビジョンド IOPS はコストがかかることに留意してください。汎用 EBS ボリュームは、必要なパフォーマンスに適したサイズのときに、最も良く動作します。

ネットワーキング

クラスタが高い読み/書きトラフィックを予想する場合、10 Gb/秒のパフォーマンスを提供するインスタンスタイプを選択してください。例として、i3.8xlarge と c5.9xlarge の両方は、10-Gb/秒 のネットワーキングパフォーマンスを提供します。同じファミリのより小さなインスタンスタイプは、比較的低いネットワーキングスループットを導きます。

Cassandra はインスタンスに対する IP アドレスに基づいて、各ノードに汎用固有識別子 (UUID) を生成します。この UUID は、リングの vnode の分配に使用されます。

AWS デプロイメントの場合、IP アドレスは EC2 インスタンスが作成されるときに、インスタンスに自動的に割り当てられます。新規 IP アドレスで、データの分配は変更され、リング全体のバランスが再度取られる必要があります。これは望ましくありません。

割り当てられた IP アドレスを保持するためには、二次的なエラスティックネットワークインターフェイスを固定 IP アドレスで使用します。EC2 インスタンスを新しいものとスワップする前に、古いインスタンスからセカンダリネットワークインターフェイスをデタッチして、それを新しいものにアタッチします。このようにして、UUID は同じままになり、データがクラスタで分配される方法に変わりはありません。

複数のリージョンをデプロイしている場合、クロスリージョン VPC ピアリングを使用して、2 つのリージョンの 2 つの VPC を接続できます。

高可用性と弾力性

Cassandra は複数のノードの障害の間、フォルトトレランスで高い可用性をもつように設計されています。この記事で前述したパターンで、3 つのレプリケーション係数のうちの 1 つで Cassandra を 3 つのアベイラビリティ―ゾーンにデプロイします。AWS リージョンの選択肢を 3 つ以上のアベイラビリティーゾーンに制限することを通じてでも、1 ゾーンの障害と単一リージョン内のネットワーク区画の事例を保護します。この記事で前述したマルチリージョンのデプロイメントは、リージョンのリソースの多くが断続的な障害を敬虔しているときに保護します。

インフラストラクチャの自動化を通じて弾力性が保証されます。デプロイメントパターンはすべて、障害のあるノードの迅速な交換を必要としています。リージョン全体に障害がある場合、マルチリージョンオプションでデプロイするとき、インフラストラクチャが障害のあるリージョンをリカバリしている間に、トラフィックは他のアクティブなリージョンに仕向けられる場合があります。予測できないデータの方かいの場合、Amazon S3 に保存されたポイントインタイムのバックアップでスタンバイクラスタをリストアできます。

メンテナンス

このセクションでは、Cassandra クラスタが健全であることを保証する方法を見ていきます。

  • スケーリング
  • アップグレード
  • バックアップとリストア

スケーリング

Cassandra はリングにインスタンスを追加することにより、水平スケールされます。1 つのスケールオペレーションにスケールアップするために、クラスタのノードの数を倍増させることをお勧めします。これにより、アベイラビリティ―ゾーン全体にわたり、データが均等に分配されたままになります。同様に、スケールダウンするときには、インスタンスの数を半分にして、データを均等に分散したままにすることが最良です。

Cassandra は各ノードの計算能力を増強することにより、垂直にスケールされます。大きなインスタンスタイプは、比例してより大きなメモリをもちます。デプロイメントの自動化を使用して、インスタンスをより大きなインスタンスに、ダウンタイムやデータの損失なしに、スワップします。

アップグレード

3 つすべてのタイプのアップグレード (Cassandra、オペレーティングシステムのパッチング、インスタンスタイプの変更) は、同じローリングアップグレードパターンに従います。

このプロセスでは、新しい EC2 インスタンスで開始し、ソフトウェアとパッチをそれにインストールします。その後で、リングから 1 つのノードを削除します。詳細については、Cassandra クラスタローリングアップグレード を参照してください。次に、リングの EC2 インスタンスの 1 つからセカンダリネットワークインターフェイスをデタッチして、それを新しい EC2 インスタンスにアタッチします。Cassandra サービスを再開して、それを同期するために待ちます。クラスタのすべてのノードについて、このプロセスを繰り返します。

バックアップとリストア

デプロイメントで使用されるストレージのタイプに応じて、バックアップとリストア戦略が決まります。Cassandra はスナップショットと増分バックアップをサポートします。インスタンスストアを使用するとき、ファイルベースのバックアップツールが最も良く動作します。カスタマーは再同期またはその他のサードパーティ製品を使用して、インスタンスから長期的なストレージにデータバックアップをコピーします。このプロセスは、完全なバックアップのために、クラスタのすべてのインスタンスに対して繰り返されなければなりません。これらのバックアップファイルは、新しいインスタンスに戻されてコピーされ、リストアされます。長期的なストレージのために、バックアップファイルを永久に保存するために S3 を使用することをお勧めします。

Amazon EBS ベースのデプロイメントの場合、ボリュームをバックアップするためにEBS ボリュームの自動スナップショットを有効にできます。新しい EBS ボリュームは、復元のためにこれらのスナップショットから容易に作成できます。

セキュリティ

デプロイメントのすべての局面でセキュリティについて考えることをお勧めします。最初の手順は、データを休止中および移動中に暗号化することです。2番目の手順は、未承認のユーザーへのアクセスを制限することです。セキュリティの詳細については、Cassandra のドキュメントを参照してください。

休止中の暗号化

休止中の暗号化は、暗号化が有効の状態で、EBS ボリュームを使用して行うことができます。Amazon EBS は暗号化のために、AWS KMS を使用しています。詳細については、Amazon EBS 暗号化を参照してください。

インスタンスストアベースのデプロイメントは、暗号化されたファイルシステムまたは AWS パートナーソリューションを使用する必要があります。

移動中の暗号化

Cassandra はクライアントとノード間通信に Transport Layer Security (TLS) を使用します。

認証

セキュリティのメカニズムはプラグ式で、1 つの認証方式から別の認証方式に容易にスワップできることを意味します。また、Cassandra に Karberos チケットなどを認証する場合や、LDAP ディレクトリなど、別の場所にパスワードを保存する場合に、独自の認証方式を提供することもできます。

認証

デフォルトによりプラグインされている認証は、org.apache.cassandra.auth.Allow AllAuthorizer です。Cassandra はまた、ロールベースのアクセスコントロール (RBAC) 機能もそなえており、ロールを作成し、これらのロールに対する権限を割り当てます。

結論

この記事では、AWS Cloud で実行中の Cassandra のいくつかのパターンについて取り上げました。この記事は、Amazon EC2 で実行中の Cassandra データベースを管理する方法について説明します。AWS はまた多くのデータベースに対する管理対象のオファーも提供します。詳細については、すべてのアプリケーションニーズに対する専用データベース を参照してください。

ご質問またはご提案については、以下でコメントを残してください。

 

 

その他の参考資料

この記事が有効であるとわかった場合は、Analyze Your Data on Amazon DynamoDB with Apache Spark と Analysis of Top-N DynamoDB Objects using Amazon Athena and Amazon QuickSight もお読みください。

著者について

Prasad Alle は、AWS プロフェッショナルサービスのシニアビッグデータコンサルタントです。AWS エンタープライズおよび戦略的顧客のために、スケーラブルで信頼性の高いビッグデータ、Machine Learning、人工知能、IoT ソリューションをリードおよび構築するのに尽力しています。関心のあるテクノロジーは、先進的なエッジコンピューティング、エッジでのMachine Learning 等、多岐にわたります。余暇の楽しみは家族と過ごすこと。

 

 

 

Prasad Alle は、AWS プロフェッショナルサービスのシニア IoT コンサルタントです。彼は当社のカスタマーの非常にスケール自在で信頼性の高い IoT と機械学習ソリューションに従事しています。余暇には、エレクトロニクスとガゼットを手にしたり、家族との時間を楽しんでいます。