Amazonは、Aurora DSQLのマルチリージョン、アクティブ・アクティブクラスターをストックホルム、スペイン、ムンバイ、シンガポールに拡大し、単一の論理データベースが2つのリージョンにわたって書き込み可能な状態を維持し、一方が障害を起こしても稼働し続けることを可能にした。
戦略的なシグナルは、機能リスト以上に重要だ。リージョン間で強整合性を持つ分散SQLは、これまでGoogle Spannerクラスのエンジニアリングか、脆弱な自社開発レプリケーションを意味してきた。これをサーバーレスかつ従量課金制にすることで、AWSは真にグローバルなトランザクションシステムを運用できる企業を定義してきた能力をコモディティ化している。これはCockroachDB、YugabyteDB、GoogleのAlloyDB/Spannerに直接的な圧力をかけ、マルチリージョンレジリエンスを夢物語からチェックボックス項目へと再定義する。
リージョンの選択は、真の需要ドライバーを明らかにする:データ主権だ。スペインとストックホルムはEUの居住要件とGDPRローカライゼーションに対応し、ムンバイはインドのデータローカライゼーション制度を支え、シンガポールは東南アジアのコンプライアンスハブである。経営幹部はこれを、断片化する規制地図に追いつくインフラストラクチャとして読み取るべきだ。可用性を維持しながらデータを管轄区域に固定する能力は、フィンテック、ヘルステック、決済プラットフォームにとって厳格な要件になりつつある。
機会:グローバルアプリを構築するチームは、災害復旧の複雑さを削減し、特注のレプリケーション層なしでRPO/RTOを短縮できる。落とし穴はロックインだ。独自の整合性モデル上のアクティブ・アクティブは粘着性が高く、リージョン間の書き込みトラフィックは無視できないコストとレイテンシーを伴う可能性がある。CIOは、マーケティング主張ではなく実際のワークロードでベンチマークを行い、コアシステムをコミットする前にエグレスと競合解決の動作をモデル化すべきだ。
推奨アクション:厳格な居住性要件を持つ、限定的でレイテンシー許容度の高いワークロードでDSQLをパイロット運用する;退出条件を交渉し、スキーマの可搬性を維持する;そして、これを法的にリージョン内に留まる必要があるデータセットを監査するきっかけとして扱う。投資家にとって、この傾向は次のデータベース戦場がコンプライアンスグレードのグローバル整合性であることを確認し、スタンドアロンの分散SQLベンダーよりも、密なリージョンフットプリントを持つハイパースケーラーに有利に働く。
