アーキテクチャーの概要

Cassandraを理解して使用するための基本情報。

Cassandraは、単一障害点なしで複数のノードにわたってビッグ・データのワークロードを処理するように設計されています。そのアーキテクチャーは、システムおよびハードウェアには障害が発生するものだということを前提にしています。Cassandraは、クラスター内のすべてのノードにデータが分散されるピアツーピア分散システムを均質なノードに横断的に採用することによって障害の問題に対処します。各ノードは、ピアツーピアのゴシップ通信プロトコルを使用して、クラスター全体でそれ自体および他のノードに関する状態情報を頻繁に交換します。各ノードでシーケンシャルに書き込まれるコミット・ログにより、データの永続性を保証するために書き込みアクティビティが捕捉されます。データにはその後インデックスが付けられ、memtableと呼ばれるライトバック・キャッシュに似たインメモリー構造に書き込まれます。メモリー構造が満杯になると、データはSSTableデータ・ファイル形式でディスクに書き込まれます。すべての書き込みは自動的にパーティションされ、クラスター全体にレプリケーションされます。Cassandraは、コンパクションと呼ばれる処理を使用して、定期的にSSTableを統合し、トゥームストーンによって削除と示された古いデータを破棄します。クラスター全体のデータの一貫性を確保するには、さまざまなリペア・メカニズムが採用されています。

Cassandraは、行ストア・データベースにパーティションされます。ここで、行は必要なプライマリ・キーを使用してテーブルに構成されています。Cassandraのアーキテクチャーでは、権限を与えられたすべてのユーザーが、CQL言語を使用して任意のデータ・センターの任意のノードに接続し、データにアクセスできます。使い勝手がいいように、CQLはSQLと同じような構文を使用し、テーブル・データと連動します。開発者は、cqlsh、DevCenter、またはアプリケーション言語向けのドライバー経由でCQLにアクセスできます。通常、クラスターには、さまざまなテーブルで構成されたアプリケーションごとに1つのキースペースがあります。

クライアントの読み取りまたは書き込み要求は、クラスター内の任意のノードに送信できます。要求を持つクライアントがノードに接続されると、そのノードは、クライアントの特定の操作のコーディネーターとしての役目を果たします。コーディネーターは、クライアント・アプリケーションと、要求されたデータを所有するノード間で、代理人としての役目を果たします。コーディネーターは、クラスターがどのように構成されているかに基づいて、リングのどのノードが要求を受け取るかを決定します。

主な構成要素

  • ノード

    データの格納先。Cassandraの基本的なインフラストラクチャー・コンポーネントです。

  • データ・センター

    互いに関連のあるノードの集まり。データ・センターには、物理的なデータ・センターと仮想データ・センターがあります。異なるワークロードごとに、物理的なデータ・センターと仮想データ・センターのいずれかの異なるデータ・センターを使うべきです。レプリケーションは、データ・センターごとに設定されます。異なるデータ・センターを使用することで、Cassandraのトランザクションが他のワークロードの影響を受けることを防げると同時に、互いに近いデータ・センターで要求を処理することによってレイテンシーを下げることができます。レプリケーション係数に基づいて、複数のデータ・センターにデータが書き込まれます。1つのデータ・センターが複数の物理的な所在地をまたぐことがあってはなりません。

  • クラスター

    クラスターには、1つ以上のデータ・センターが含まれています。複数の物理的な所在地をまたぐことが可能です。

  • コミット・ログ

    すべてのデータは、永続性のためにまずコミット・ログに書き込まれます。そのすべてのデータがSSTableにフラッシュされた後、コミット・ログをアーカイブ、削除、または再利用できます。

  • SSTable

    ソート済み文字列テーブル(SSTable)は、Cassandraがmemtablesを定期的に書き込む不変データ・ファイルです。SSTableは追加書き込みのみで、ディスクにシーケンシャルに格納され、Cassandraテーブルごとに維持されます。

  • CQLテーブル

    テーブル行単位でフェッチされる、順序付きのカラムの集まりです。テーブルはカラムから構成され、プライマリ・キーを持ちます。

Cassandraを構成するための主なコンポーネント

  • ゴシップ

    Cassandraクラスターに属する他のノードの場所および状態についての情報を得て共有するピアツーピア通信プロトコルです。ノードが再起動されるとすぐに使用できるように、ゴシップ情報も、各ノードによってローカルに保持されます。

  • パーティショナー

    パーティショナーは、クラスター内のノードにデータをどのように横断的に分散させるか、データの最初のコピーをどのノードに置くかを決定します。基本的には、パーティショナーはパーティション・キーのトークンを計算するハッシュ関数です。データの各行は、パーティション・キーによって一意に識別され、トークンの値に応じてクラスター全体に分散されます。Murmur3Partitionerは、新しいCassandraクラスター用のデフォルトのパーティション・ストラテジであり、新しいクラスターではほとんどの場合に正しい選択肢となります。

    パーティショナーを設定して、各ノードのnum_tokens値をノードに割り当てる必要があります。割り当てるトークンの数は、システムのハードウェア能力によって異なります。仮想ノード(vnode)を使用しない場合は、initial_token設定を使用してください。

  • レプリケーション係数

    クラスター全体のレプリカの総数です。レプリケーション係数1は、各行のコピーが1つしかなく、1つのノード上にあることを意味します。レプリケーション係数2は、各行のコピーが2つあり、それぞれ異なるノード上にあることを意味します。すべてのレプリカの重要性は同じで、プライマリ・レプリカやマスター・レプリカといった区別はありません。各データ・センターにレプリケーション係数を定義します。通常は、レプリケーション・ストラテジを1以上、クラスターのノード数以下に設定する必要があります。

  • レプリカ配置ストラテジ

    Cassandraは信頼性とフォールト・トレランスを確保するために、データのコピー(レプリカ)を複数のノードに格納します。レプリケーション・ストラテジは、レプリカをどのノードに配置するかを決定します。データの最初のレプリカは、単に最初のコピーであるということだけです。いかなる意味合いにおいても独自性を持つわけではありません。将来拡張する必要が生じたときに、複数のデータ・センターに拡張するのが簡単なため、ほとんどのデプロイには、NetworkTopologyStrategyを強く推奨します。

    キースペースを作成する際、レプリカ配置ストラテジおよびレプリカ数を定義する必要があります。

  • スニッチ

    スニッチは、レプリケーション・ストラテジがレプリカを配置するために使用するデータ・センターおよびラック(トポロジー)としてマシンのまとまりを定義します。

    クラスターを作成するときは、スニッチを構成する必要があります。どのスニッチも、パフォーマンスを監視し、読み取りに最適なレプリカを選択する動的スニッチ層を使用します。これはデフォルトで有効になっており、ほとんどのデプロイで使用を推奨されます。各ノードの動的スニッチしきい値をcassandra.yaml構成ファイル内で構成します。

    デフォルトのSimpleSnitchは、データ・センターまたはラック情報を認識しません。単一データ・センターへのデプロイ時またはパブリック・クラウドの単一ゾーンに使用します。実稼働環境にはGossipingPropertyFileSnitchを推奨します。これはノードのデータ・センターとラックを定義し、この情報をその他のノードに伝えるためにゴシップを使用します。

  • cassandra.yaml構成ファイル

    クラスターの初期化プロパティの設定、テーブルのキャッシング・パラメーター、調整およびリソース利用のプロパティ、タイムアウト設定、クライアント接続、バックアップ、およびセキュリティのためのメインの構成ファイルです。

    デフォルトでは、ノードは管理対象のデータをcassandra.yamlファイルに設定されているディレクトリーに格納するように構成されます。

    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

    実稼働環境クラスター・デプロイでは、commitlog-directorydata_file_directoriesとは異なるディスク・ドライブに変更できます。

  • システム・キースペース・テーブルのプロパティ

    ストレージ構成属性は、プログラムで、またはCQLなどのクライアント・アプリケーションを使用して、キースペースまたはテーブルごとに設定します。