1. 概要

このチュートリアルでは、 snitch の役割と、Cassandraがそれを使用してリクエストを効率的にルーティングする方法について学習します。 また、Cassandraで利用可能なさまざまなタイプのスニッチについても見ていきます。

2. スニッチとは何ですか？

スニッチは、各ノードが属するラックとデータセンターを報告するだけです。基本的に、スニッチはクラスターのネットワークトポロジを決定し、Cassandraに通知します。

ノード間の相対的な近接性など、クラスターのトポロジーに関するこの知識により、Cassandraはクラスター内の適切なノードにリクエストを効率的にルーティングできます。

2.1. 書き込み操作のスニッチ

Cassandraは、スニッチからの情報を使用して、ノードをラックとデータセンターにグループ化します。 したがって、書き込み操作中の相関障害を回避するために、Cassandraはレプリカを同じラックに格納しないようにあらゆる努力を払っています。

2.2. 読み取り操作のスニッチ

読み取り操作中に、Cassandraは整合性レベルに基づいて多数のノードとレプリカに接続する必要があることを私たちは知っています。 読み取り操作を効率的にするために、Cassandraはスニッチからの情報を使用して、レプリカを最も速く返すノードを識別します。

次に、このノードは完全な行情報について照会されます。 次に、Cassandraは他のレプリカノードにハッシュ値を照会して、最新のデータが返されるようにします。

3. ニッチの種類

デフォルトのスニッチであるSimpleSnitchは、トポロジーに対応していません。 つまり、クラスターのラックとデータセンターを認識していません。 したがって、複数のデータセンターの展開には適していません。

このため、カサンドラは私たちの要件を満たすさまざまな種類のスニッチを考え出しました。 通常、スニッチのタイプは、構成ファイルcassandra.ymlファイルでプロパティ名endpoint_snitchを介して構成できます。

いくつかのタイプのスニッチとそれらがどのように機能するかを見てみましょう。

3.1.  PropertyFileSnitch

PropertyFileSnitch は、ラック対応のスニッチです。 cassandra-topology.properties というファイルで、クラスタートポロジ情報をキー値プロパティとして提供できます。 このプロパティファイルでは、各ノードが属するラック名とデータセンター名を提供します。

さらに、ラックとデータセンターには任意の名前を使用できます。 ただし、データセンター名がキースペース定義でNetworkTopologyStrategyとして定義されている名前と一致することを確認する必要があります。

cassandra-topology.propertiesのコンテンツの例を次に示します。

# Cassandra Node IP=Data Center:Rack 
172.86.22.125=DC1:RAC1 
172.80.23.120=DC1:RAC1 
172.84.25.127=DC1:RAC1 

192.53.34.122=DC1:RAC2 
192.55.36.134=DC1:RAC2 
192.57.302.112=DC1:RAC2 

# default for unknown nodes 
default=DC1:RAC1

上記の例では、2つのラック（RAC1、RAC2）と1つのデータセンター（DC1）があります。 カバーされていないノードIPは、デフォルトのデータセンター（DC1）とラック（RAC1）に分類されます。

このスニッチの欠点の1つは、cassandra-topology.propertiesファイルがクラスター内のすべてのノードと同期していることを確認する必要があることです。

3.2.  GossipingPropertyFileSnitch

GossipingPropertyFileSnitchもラック対応のスニッチです。 PropertyFileSnitch で必要とされるラックとデータセンターの手動同期を回避するために、このスニッチでは、cassandra-rackdc.propertiesファイルでノードごとにラックとデータセンター名を個別に定義するだけです。 。

そして、これらのラックとデータセンターの情報は、ゴシッププロトコルを使用してすべてのノードと交換されます。

cassandra-rackdc.propertiesファイルのコンテンツの例を次に示します。

dc=DC1
rack=RAC1

3.3. Ec2Snitch

名前が示すように、 Ec2Snitch は、Amazon Web Service（AWS）EC2でのクラスターのデプロイに関連しています。 単一のAWSリージョンデプロイメント内では、リージョン名はデータセンターとして扱われ、アベイラビリティーゾーン名はラックと見なされます。

単一のデータセンター展開のみが必要な場合は、プロパティの構成は必要ありません。 一方、複数のデータセンターを導入する場合は、cassandra-rackdc.propertiesファイルでdc_suffixを指定できます。

たとえば、 us-east リージョンで、いくつかのデータセンターが必要な場合は、dc_suffix構成を次のように提供できます。

dc_suffix=_1_DC1
dc_suffix=_1_DC2

上記の各構成は、2つの異なるノードに入ります。 その結果、データセンターの名前としてus_east_1_DC1とus_east_1_DC2になります。

3.4. Ec2MultiRegionSnitch

AWSでのマルチリージョンクラスターのデプロイの場合、Ec2MultiRegionSnitchを使用する必要があります。 さらに、cassandra.yamlとcassandra-rackdc.properties。の両方を構成する必要があります

パブリックIPアドレスをbroadcast_addressとして構成する必要があります。また、必要に応じて、cassandra.yamlのシードノードとして使用します。 さらに、プライベートIPアドレスを listen_addressとして構成する必要があります。最後に、パブリックIPファイアウォールでsession_portまたはssl_session_portを開く必要があります。

これらの構成により、ノードはAWSリージョン間で通信できるため、リージョン間での複数のデータセンターのデプロイが可能になります。 単一のリージョンの場合、Cassandraノードは接続が確立された後に通信のためにプライベートIPアドレスに切り替えます。

リージョン全体の各ノードのcassandra_rackdc.propertiesのdc_suffixデータセンター構成は、Ec2Snitchと同様です。

3.5. GoogleCloudSnitch

名前が示すように、GoogleCloudSnitchは、1つ以上のリージョンにわたるGoogleCloudPlatformでのクラスター展開用です。 AWSと同様に、リージョン名はデータセンターと見なされ、アベイラビリティーゾーンはラックです。

単一のデータセンター展開の場合、構成は必要ありません。 逆に、 Ec2Snitch と同様に、複数のデータセンターを導入する場合は、cassandra-rackdc.propertiesファイルにdc_suffixを設定できます。

3.6. RackInferringSnitch

RackInferringSnitch は、ノードのIPアドレスの3番目と2番目のオクテットからラックとデータセンターへのノードの近接性を推測します。

4. ダイナミックスニッチング

デフォルトでは、Cassandraは、 cassandra.yml ファイルで構成するすべてのスニッチタイプを、 DynamicEndpointSnitchと呼ばれる別のタイプのスニッチでラップします。この動的スニッチは、からクラスタートポロジの基本情報を取得します。すでに構成されている基になるスニッチ。 次に、ノードの読み取りレイテンシーを監視し、任意のノードでの圧縮操作を追跡します。

このパフォーマンスデータは、動的スニッチによって使用され、読み取りクエリに最適なレプリカノードが選択されます。このようにして、Cassandraは、読み取り要求を不良またはビジー（パフォーマンスの遅い）レプリカノードに再ルーティングすることを回避します。

動的スニッチは、ゴシップが使用する Phi発生障害検出メカニズムの修正バージョンを使用して、読み取り要求で最適なレプリカノードを決定します。 badnessしきい値は、優先ステータスを失うために、最高のパフォーマンスのノードと比較して、優先ノードのパフォーマンスがどれだけ悪いかを決定する構成可能なパラメーターです。

Cassandraは、各ノードのパフォーマンススコアを定期的にリセットして、パフォーマンスの悪いノードを回復し、パフォーマンスを向上させて、優先ステータスを再利用できるようにします。

5. 結論

このチュートリアルでは、Snitchとは何かを学び、Cassandraクラスター展開で構成できるSnitchタイプのいくつかについても説明しました。