まず最初に: トゥームストーンとは何で、なぜそれが問題を引き起こしているのでしょうか？

トゥームストーンは、Cassandraが削除されたデータを示す方法です。データがすべてのレプリカで確実に削除されるようにするための小さな墓石のようなものです。

理論的には素晴らしいですよね？ しかし実際には、トゥームストーンは独身男性の部屋の床に積み上がる洗濯物のように、すぐに溜まってしまいます。これにより以下の問題が発生します:

  • 読み取り遅延の増加
  • SSTableの肥大化
  • 圧縮プロセスの遅延
  • 全体的なパフォーマンスの低下

さらに、マルチクラスターのセットアップやGDPR準拠を考慮すると、これらの問題はクレジットカードの利息のように急速に増大します。

TimeWindowCompactionの登場

TimeWindowCompactionは、Cassandraクラスターを整理整頓するためのMarie Kondoのようなものです。時間枠に基づいてSSTableを整理します。以下のように機能します:

  1. SSTableが時間枠（例: 毎時、毎日）にグループ化されます
  2. 各時間枠内で圧縮が行われます
  3. 古い時間枠は圧縮頻度が低くなります

TimeWindowCompactionを有効にするには、cassandra.yamlファイルを更新します:


compaction:
  class: org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy
  max_threshold: 32
  min_threshold: 4
  timestamp_resolution: MICROSECONDS
  compaction_window_unit: DAYS
  compaction_window_size: 1

この設定は、毎日の時間枠を設定し、SSTableの数が4から32に達したときに各時間枠内で圧縮を行います。

SSTableアタッチメント: 新しい親友

SSTableアタッチメントは、書類をまとめる便利なクリップのようなものです。関連するSSTableを時間枠を超えてリンクすることで、不要な圧縮を減らし、読み取りパフォーマンスを向上させます。

SSTableアタッチメントを有効にするには、cassandra.yamlに以下を追加します:


compaction:
  enable_sstable_attachment: true

これにより、Cassandraは関連するSSTableを一緒に保つようにし、トゥームストーンの散乱効果を減少させます。

リードリペアとヒンテッドハンドオフの微調整

GDPR準拠の削除を行う際には、削除されたデータがすべてのレプリカで確実に消去される必要があります。ここでリードリペアとヒンテッドハンドオフが役立ちます。

リードリペア: 静かな守護者

リードリペアは、読み取り操作中に静かに不整合を修正します。削除が多いワークロードに最適化するには:


read_request_timeout_in_ms: 10000
read_repair_chance: 0.1
dclocal_read_repair_chance: 0.25

この設定は、特に同じデータセンター内でのリードリペアの可能性を高め、過剰な負荷をかけずに行います。

ヒンテッドハンドオフ: 粘り強いメッセンジャー

ヒンテッドハンドオフは、更新（削除を含む）が一時的に利用できない場合でもすべてのレプリカに届くようにします。GDPR準拠のために最適化するには:


hinted_handoff_enabled: true
max_hint_window_in_ms: 10800000 # 3時間
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 4

この設定は、削除操作が最大3時間伝播されるようにし、一貫性とパフォーマンスのバランスを取ります。

すべてをまとめる

個々の要素をカバーしたので、マルチクラスターCassandraセットアップでそれらがどのように機能するかを見てみましょう:

  1. TimeWindowCompactionを実装してトゥームストーンの散乱を減らす
  2. SSTableアタッチメントを有効にして読み取りパフォーマンスを向上させる
  3. リードリペアとヒンテッドハンドオフを微調整して一貫した削除を行う
  4. クラスターのパフォーマンスを監視し、必要に応じて調整する

トゥームストーン関連のメトリクスを監視するためのサンプルスクリプトはこちらです:


import subprocess
import json

def get_tombstone_metrics():
    nodetool_output = subprocess.check_output(["nodetool", "tablestats", "-H"])
    metrics = json.loads(nodetool_output)
    
    tombstone_metrics = {
        "total_tombstones": sum(table["LiveSSTableCount"] for table in metrics),
        "average_tombstones_per_read": sum(table["AvgTombstonesPerRead"] for table in metrics) / len(metrics),
        "max_tombstones_per_read": max(table["MaxTombstonesPerRead"] for table in metrics)
    }
    
    return tombstone_metrics

if __name__ == "__main__":
    print(get_tombstone_metrics())

このスクリプトを定期的に実行して、トゥームストーンの状況を追跡し、必要に応じて設定を調整してください。

まとめ

マルチクラスターCassandraセットアップでのトゥームストーンの過剰処理は、片手で火のついたチェーンソーをジャグリングしながら一輪車に乗るようなものです。難しいですが不可能ではありません。TimeWindowCompaction、SSTableアタッチメント、リードリペアとヒンテッドハンドオフの微調整を活用することで、パフォーマンスを犠牲にせずにGDPR準拠の削除を実現できます。

一つの解決策がすべてに適用されるわけではありません。クラスターのパフォーマンスを監視し、さまざまな設定を試し、手を汚すことを恐れないでください。将来の自分（と会社の法務チーム）が感謝するでしょう！

プロのヒント: これらの設定を本番クラスターに適用する前に、必ずステージング環境でテストしてください。YAMLファイルのコンマの誤りでシステム全体をダウンさせる人にはなりたくないですよね！

さあ、トゥームストーンを征服しましょう！Cassandraクラスターがあなたを待っています。