ツール整備はスケーリング戦略である

運用不能なシステムを作ろうとする人はいません。それは徐々に起こります。クラスターが大きくなり、サービスが一つ増え、コスト削減のためにマルチテナント化を導入します。

一つひとつの判断は合理的です。ところがある夜、何かが壊れます。オンコールのエンジニアは読み解けないダッシュボードを見つめ、コマンドで得たデータを全体の理解につなげられず、自分の把握できる範囲を超えたシステムについて判断を迫られます。破綻したのはシステムではなく、頭の中のモデルでした。

よりよいツールが必要になるのは、規模がそれを要求するからです。Valkey が生まれた背景にも、多くのプラットフォームチームが同じ壁にぶつかったことがあります。分散キャッシュが、当初のツールでは運用できないほどのインフラへと成長したのです。今年の Unlocked で行われた二つの講演は、その壁が実際にどう現れ、本格的なエンジニアリング組織がどう対処するかを示していました。

誰にも見えなかった障害の要因

Ignacio Alvarez は、ラテンアメリカ最大の EC プラットフォーム、Mercado Libre の Senior Principal Engineer です。彼のチームは、他のすべてのエンジニアリングチームが製品を構築する土台となる社内プラットフォームを開発しています。

毎年 30～60% 成長するインフラ上で、およそ 8,000 のキャッシュ、約 30,000 ノードを運用しています。この規模になると、標準的な方法は通用しなくなります。

初代のキャッシュソリューションでは、各アプリケーションに専用クラスターを与えていました。明確に分離でき、ノイジーネイバーもなく、仕組みも単純です。その代償は効率でした。使われないインフラが生まれ、容量の利用率は低く、リソースが実際にどう使われているかも見えませんでした。さらに重要なのは、ガバナンスがなかったことです。各チームが好きな Memcached クライアントを選び、勘でクラスターのサイズを決め、問題が起きてもプラットフォームチームに制御する手段がありませんでした。

第 2 世代では、無駄をなくすためマルチテナント化しました。同時に、はるかに理解しにくい、新たな種類の障害を持ち込むことにもなりました。

帯域幅の飽和でノードが停止したのです。

共有クラスターのノードが、出入りする膨大なデータ量によって停止していました。この障害は、一つのサービスの内部からは見えません。あるテナントは正常です。複数のテナントを個別に見ても、すべて正常です。テナント全体のトラフィックが積み重なり、基盤となるノードの処理上限に達して初めて問題が見えます。ノードが落ち始めた時点で、システムは既に不安定になっています。

これは、個別のサービスチームには観測も診断も修正もできない問題です。アプリケーションの境界より上で起きています。どれだけ注意深く監視しても、単独のチームには見えないため防げません。

Mercado Libre は、複数の要素からなる構造的な対策を取りました。SDK ラッパーにより、キャッシュに触れるすべてのサービスに対して、プラットフォームチームが一か所でルールを適用できるようにしました。具体的には、シリアライズ形式を制御し、書き込みを試みる前にペイロードの最大サイズを強制し、値が一定のサイズを超えると透過的に圧縮しました。サービスチームは無効化も、誤設定も、迂回もできません。そのため、ラッパーへの一度の変更をフリート全体のすべてのワークロードに行き渡らせられます。8,000 のキャッシュで機能するガバナンスは、こうした仕組みです。数千もの独立したチームと、動作の変更を個別に交渉することはできません。

ラッパーに加え、一元化したコントロールプレーンにより、テナントをまたぐ影響が初めて見えるようになりました。ペイロードサイズを明示的に観測することで、危機になる前に本当のボトルネックを把握できました。また、システム全体のリスクを高める設定項目を意図的に削り、開発者ができることを絞りました。

この最後の点は重要です。プラットフォームチームは意図的に柔軟性を減らしました。大規模な環境では、柔軟性があるために、見えない障害が見えないまま残ることがあります。

キャッシュがインフラへと成長する

キャッシュは長い間、アプリケーションの関心事として扱われてきました。遅い処理を速くするために Redis や Memcached を加え、サービスごとにクラスターを用意し、TTL を調整し、追い出しポリシーを検討します。考え方は局所的で、このキャッシュはこのアプリケーションを支えるために存在する、というものでした。

この前提が成り立つのは、アプリケーション、クラスター、ノードが増えて、キャッシュのフリート自体が一つのシステムになるまでです。

そこに達すると問題が変わります。サービスの性能を調整する仕事から、数百、数千のサービスにまたがる共有インフラを運用する仕事になります。クラスターのトポロジー、スロットの所有権、安全な再配置、テナントをまたぐ可視性が日々の課題になります。考えるべきことは、「キャッシュをどう使うか」から「このフリートをどう安全に運用するか」へ移ります。

Mercado Libre は、その規模で制御を取り戻すために社内ツールを構築しました。しかし、同社だけの問題ではありません。分散キャッシュを運用する大規模なプラットフォームは、最終的に同じ制約に直面します。意図したかどうかに関係なく、フリートはインフラとして振る舞うのです。同社が社内で埋める必要があったツールの不足を、プロジェクト全体で解消しようとしているのが Valkey です。

Valkey 9.0 はアトミックなスロット移行を導入し、毎秒 10 億件超のリクエストを処理する 2,000 ノードのクラスターへ対応を拡大しました。アトミックなスロット移行は、理解する価値があります。従来、スロット間でキーを移行する際には、移行元にも移行先にもキーが存在しない時間帯が生じ得ました。検索に失敗するため、運用者は防御的な対処を用意する必要がありました。アトミックな移行は、その時間帯を完全になくします。キーは常に、ちょうど一つのスロットに属します。再配置時にプラットフォームチームが考慮する障害要因が、一つ減るのです。

主要なリリースが、予測可能な移行のセマンティクスやフリート規模のクラスターの挙動を重視しているなら、対象とする利用者は変わっています。これはレイテンシを調整するアプリケーション開発者ではなく、共有インフラを運用するプラットフォームチームのための機能です。

すべての組織が、インフラ層の制御を増やすことで対応するわけではありません。問題の形自体を変える組織もあります。

システム自体を理解しやすくするには

Nubank の Principal Software Engineer、Joe Lane は別の方法を取っています。運用の複雑さをツールで補う代わりに、チームは複雑さの原因を取り除きました。

Joe の議論は、従来のデータベースではあまりに基本的で、多くのエンジニアが意識しなくなった問題から始まります。

「同じクエリを続けて 2 回実行しても、異なる結果が返ることがあります。答えについて考えるための、しっかりした土台がありません。」

この不安定さが、膨大な防御的実装を必要にします。キャッシュの無効化があるのは、その下のデータが変わり続けるためです。分散ロックの調整があるのは、並行する書き込みによって予測できない状態が生じるためです。線形化可能性の確認、防御的コピー、整合性プロトコルはすべて、同じ問題から派生しています。可変の状態には、安定して拠り所にできるものがないのです。

Nubank は Datomic を使っています。Datomic は、データモデルの段階で異なる方法を取ります。レコードをその場で更新せず、事実を蓄積します。更新のたびに、順序付けられた台帳へ新しいアトミックな事実が加わります。削除も上書きもありません。データベース自体が足元で変わらないため、どこにでもキャッシュできるものになります。

Mercado Libre が共有状態を管理するために制御を加えたのに対し、Nubank は状態の不安定さそのものをなくしました。その結果、可変なシステムでは成立しないものの、ここでは完全に機能するキャッシュアーキテクチャが生まれました。

無効化プロトコルも、読み取りの調整も不要です。クエリは決定的です。ある時点の基準とクエリを誰かに渡せば、1 週間後でも同じ答えが得られます。クエリエンジンはアプリケーション内にあります。読み取りは、データベースが接続を処理できる容量ではなく、コンピュートに合わせて拡張します。

Joe はコストを計算しました。Nubank が数十億件の読み取りを多層キャッシュではなく DynamoDB で処理した場合、年間 9,700 万ドルかかります。読み取りの累積待ち時間は、毎年 124,000 年に達します。

データモデルによって、エンジニアは安定した土台に基づいて考えられます。多くの防御的ツールが不要になり、運用負担も減ります。

二つの戦略に共通する根本問題

Ignacio と Joe は正反対の解決策にたどり着きましたが、人間の認知能力を超えたシステムという、同じ制約に対応しています。

Mercado Libre は、仕組みがなければ障害の要因が見えないため、ガバナンス、ルールの適用点、オブザーバビリティのインフラを構築しました。SDK ラッパーは、数千の独立したサービスチームが運用する 8,000 のキャッシュに対し、小規模なプラットフォームチームが実質的な制御を保つための唯一の仕組みです。

Nubank は、そもそも防御的ツールが必要になる不安定さを取り除くデータモデルを選び、ツールへの依存を減らしました。不変の台帳によって、運用負担の種類そのものをなくしています。

両者の前提は共通です。ボトルネックは人間であり、何かを変える必要があります。

大規模なシステムが障害を起こすのは、人間が対処に間に合う速さで理解できなくなるからです。一定の規模を超えると、複雑さはどのチームも頭の中で把握できる範囲を超えます。散在するログ、独立したメトリクス、意味を得るために頭の中で再構成しなければならない CLI 出力は、障害が進む最中にすばやく理解することを妨げます。

Valkey の台頭も、Mercado Libre や Nubank のアーキテクチャの判断も、同じ圧力を示しています。規模の拡大により、人間の限界に合わせてインフラを進化させる必要があるのです。その進化を、一社の社内プラットフォームではなく、プロジェクト全体で実現した姿が Valkey です。Unlocked での対話は、多くの組織がこの圧力を感じ、エンジニアリングコミュニティが本格的な対応を模索していることを明らかにしました。

その隔たりを埋めるのがツールです。望ましくない状態に到達できなくする仕組みを作る場合もあれば、最初からそうした状態が少なくなるアーキテクチャを選ぶ場合もあります。大規模な運用では、意図的にツールを整えるか、人々が対応できない複雑さにのみ込まれるのを見守るか、という選択になります。

こうした問題は、孤立していては解けません。最も難しいシステムを運用する人々が知見を交換することで解決されます。 Unlocked は今年 5 月、Seattle で開催されます。実践で得た経験をぜひ共有してください。