AgodaのSQL Server脱却：72シャードをDragonflyDBへ移行した技術的必然性

深夜のオンコール、アラートの嵐、そして「なぜ今ここでデッドロックが発生するのか」という終わりのないログ解析。多くのエンジニアが一度は経験するこの悪夢を、Agodaのエンジニアリングチームはまさに日常の風景として抱えていたはずだ。彼らが直面していたのは、72ものシャードに分割されたMicrosoft SQL Serverによる価格キャッシュの運用という、極めて複雑で脆いアーキテクチャだった。1.5TBもの揮発性データを扱うために、アプリケーション層で複雑なルーティングを実装し、ハードウェアの増強には手動でのシャード再マッピングとデータ移行という、極めてコストのかかる「外科手術」を繰り返さなければならなかった。2024年初頭にハードウェア容量を倍増させたにもかかわらず、わずか1年で再び限界に達したという事実は、このアーキテクチャがもはやスケーラビリティの限界を超えていたことを如実に物語っている。

我々エンジニアにとって、データベースのシャード管理は「技術的負債の温床」そのものだ。特に価格キャッシュのような、読み取りと書き込みが激しく交錯するワークロードにおいて、SQL Serverのような汎用RDBMSをキャッシュとして酷使することは、本来の設計思想から逸脱していると言わざるを得ない。AgodaのリードエンジニアであるClarkson Chang氏が指摘した通り、リソースを積み増すだけの戦略は、もはやコスト対効果の観点からも、運用保守の観点からも破綻していた。期限切れデータのクリーンアッププロセスという、本来のビジネスロジックとは無関係な「ゴミ掃除」に貴重なCPUサイクルを奪われる日々は、エンジニアの生産性を著しく低下させる要因だったはずだ。この状況を打破するために彼らが選んだのは、単なるRDBMSのチューニングではなく、アーキテクチャそのものの刷新という、極めて勇気ある決断だった。

AgodaがDragonflyDBを選択した背景には、単なる「Redis互換」という甘い言葉に惑わされない、極めて冷静な技術選定があった。彼らは公開されているベンチマークを鵜呑みにせず、自社のワークロードを忠実に再現するmemtier_benchmarkを用いて、1:6という読み書き比率と、10キーのMGET操作を徹底的に検証した。この「現場のワークロードを再現する」という姿勢こそ、シニアエンジニアが持つべき真のプロフェッショナリズムである。DragonflyDBの共有なし（shared-nothing）かつマルチスレッド化されたアーキテクチャは、SQL Serverのシャード管理という呪縛から彼らを解放した。結果として、P99の読み取りレイテンシは8倍もの改善を達成し、30万リクエスト/秒を8ミリ秒という驚異的な速度で処理することに成功したのである。

特筆すべきは、その移行プロセスにおける「慎重かつ大胆な」アプローチだ。いきなり全トラフィックを切り替えるような無謀なことはせず、まずは1TBのインスタンスでホットデータを扱い、最終的に1.5TBのデータセットを3シャードのクラスターで完全に収容するという段階的な拡張を行った。さらに、SQL ServerとDragonflyDBのデュアルリードによる検証は、まさに教科書的な移行戦略である。単にペイロードを比較するのではなく、プロメテウスメトリクスを用いた統計的な整合性チェック（99.9%以上のパリティ達成）を行うことで、本番環境での信頼性を担保した。この「観測可能性（Observability）」を重視した移行手法は、大規模分散システムを扱う我々にとって、明日からでも取り入れるべきベストプラクティスと言えるだろう。

今回の移行で最も興味深いのは、単なるデータベースの置き換えに留まらず、障害検知とフェイルオーバーの仕組みを「分散化」した点にある。中央集権的なコーディネーターに依存するのではなく、各アプリケーションポッドがローカルの観測データに基づいて、クラスターの健全性を自律的に判断する仕組みを構築した。5分間の観測でキャッシュヒット率に10%の乖離があれば即座に切り離し、3%以内の差に収まれば復旧とみなす。この「統計的判断による自律的な生存戦略」は、大規模なマイクロサービスアーキテクチャにおいて、単一障害点（SPOF）を排除するための極めて洗練された解である。手動介入なしで2分以内にフェイルオーバーを完了させるという実績は、運用コストの削減だけでなく、エンジニアを深夜の障害対応から解放するという、精神的な救済をも意味している。

しかし、我々はここで立ち止まって考える必要がある。DragonflyDBという強力なツールを手に入れたことで、Agodaは確かにスケーラビリティの壁を突破した。だが、これは「キャッシュの複雑性」を「分散システムの運用複雑性」に置き換えただけではないのか？ ツールが進化し、パフォーマンスが向上する一方で、我々エンジニアが管理すべき「抽象度のレイヤー」は増え続けている。技術の進化は、我々を単純作業から解放する一方で、より高度なシステム設計能力と、統計的な判断力を要求するようになっている。あなたは、自分の管理しているシステムが「自律的に死に、自律的に蘇る」設計になっているだろうか？ それとも、依然として深夜の電話一本で叩き起こされるような、脆い中央集権的なアーキテクチャに依存し続けているだろうか？ 技術の進化を享受するだけでなく、その進化に見合うだけの「設計思想のアップデート」を、我々自身が遂げているのかを今一度問い直すべきである。