レプリカ対応ルーティング (sticky sessions、スティッキールーティング、session affinity とも呼ばれます) は、関連するリクエストを同じ ClickHouse レプリカに振り分けます。一時テーブルや名前付きセッション状態をクエリ間で利用可能な状態に保つ必要がある場合、関連するクエリで同じレプリカのローカル cache を再利用する場合、または書き込みとその後の読み取りで書き込み後の読み取り整合性が必要な場合に使用します。
これはベストエフォートであり、分離は保証されません。プロキシ は各ルーティング値を 1 つのレプリカにマッピングします。レプリカ数が変わらない限り、このマッピングは安定していますが、サービス をスケーリングすると、その値が別のレプリカにマッピングされる可能性があります。
HTTP インターフェイスが必要ですレプリカ対応ルーティングは、X-ClickHouse-Replica-Tag ヘッダーを使用して、HTTP/HTTPS インターフェイス上の プロキシ レイヤーで適用されます。レプリカ対応ルーティングは現在、ネイティブプロトコル経由では使用できません (ネイティブポート、たとえばデフォルトのネイティブ mode で使用する clickhouse-go ドライバー) 。ネイティブプロトコルを使うクライアント は HTTP に切り替え、すべてのリクエストでルーティング値を送信する必要があります。
- ご利用のサービスには 2 つ以上のレプリカ が必要です。単一レプリカのサービスでは、固定先となるレプリカがありません。
- この機能が GA になると、Enterprise ではデフォルトで利用可能になります。
- 標準の ClickHouse Cloud サービスでサポートされています。BYOC は現時点ではサポートされていません。
サポートチケットを作成し、HTTP ベースのスティッキーなレプリカルーティングを有効にするよう依頼してください。サービス ID と、必要な理由 (一時テーブル、セッション状態、cache の再利用、または書き込み後の読み取り整合性) を記載してください。再起動は不要です。
ワークロードを特定のレプリカに固定するには、HTTPS インターフェイス経由のリクエストに X-ClickHouse-Replica-Tag ヘッダーを付加します。プロキシはヘッダー値に対して一貫性ハッシュを使用するため、レプリカ数が変わらない限り、同じ値を持つリクエストは同じレプリカに送られます。異なる値はそれぞれ独立してハッシュ化され、同じレプリカまたは別のレプリカに送られる可能性がありますが、値をどのレプリカにマッピングするかを指定することはできません。
既存のサービスホスト名を使用してください。特別な sticky ホスト名や DNS の変更は必要ありません。ヘッダー値には、アプリケーション名、ユーザー ID、ワークロードラベルなど、任意の文字列を指定できます。ヘッダーのないリクエストには、通常の負荷分散が適用されます。
各リクエストに X-ClickHouse-Replica-Tag ヘッダーを設定します。
clickhouse-go (v2) では、Protocol: clickhouse.HTTP を設定し、HttpHeaders 接続オプションを使用してヘッダーを渡します。
X-ClickHouse-Replica-Tag を使用すると、ClickHouse HTTP セッションを作成せずにレプリカアフィニティを実現できます。同時実行リクエストでも、SESSION_IS_LOCKED を発生させることなく同じタグを再利用できます。
X-ClickHouse-Replica-Tag ヘッダーを送信し、後続の読み取りでも同じヘッダー値を使用します。プロキシにより両方のリクエストが同じレプリカにルーティングされるため、他のレプリカの反映が遅れている場合でも、自分で書き込んだデータを読み取れます。このパターンは、対話型アプリケーションや、挿入を検証してから次の処理に進む ETL ジョブなど、書き込み後に同じデータを直ちに読み戻すワークロードに適しています。
すべてのレプリカにわたる、より広範な保証が必要な場合は、ClickHouse Cloud で select_sequential_consistency を 1 に設定することもできます。
同じ X-ClickHouse-Replica-Tag 値を使用して、SELECT hostName() の例を再度実行します。レプリカ数が変わらない限り、同じホスト名が返されるはずです。異なるヘッダー値は、別のレプリカにマッピングされる場合があります。
スケールアウト/スケールインにより、ルーティングのハッシュリングが変化します。その結果、同じルーティング値を共有するリクエストが別のレプリカに振り分けられる場合があります。一時テーブルやセッションレベルの設定に依存している場合は、再マップ後にそれらを再作成できるようにしておいてください。
レプリカ対応ルーティングはワークロードの分離ではありません
レプリカ対応ルーティングには HTTP プロトコルが必要です
X-ClickHouse-Replica-Tag HTTP ヘッダーをキーにします。ネイティブバイナリプロトコルには、プロキシがハッシュのキーとして使えるこの値がないため、ネイティブプロトコルではレプリカ対応ルーティングを利用できません。この機能を使うには、ネイティブプロトコルを使うクライアントは該当するワークロードを HTTP インターフェイスに移す必要があります。
同じルーティング値を使用しているにもかかわらず、クエリが異なるレプリカに送信される
- すべてのリクエストに
X-ClickHouse-Replica-Tag ヘッダーが含まれていることを確認してください。
- すべてのリクエストで、完全に同じルーティング値を使用していることを確認してください。
- 有効化後、しばらく待ってください。反映までに 1 分未満かかることがあります。
- 最近レプリカ数が変更されたかどうかを確認してください。スケーリング後の再マッピングは想定される動作です。新しいマッピングを確認するには、
SELECT hostName() を使用してください。
