Uberの800万ドル規模の台帳システム設計ミス：なぜ誰も責任を問われないのか
本記事は、Uberが過去10年間でレジャーシステムを5回も書き直してきた経緯を分析し、特に2017年にDynamoDB上に構築された台帳システム（LedgerStore）の設計上の致命的な欠陥を指摘しています。筆者は、この設計が単なる技術的な失敗に留まらず、組織的な「悪いインセンティブ」によって引き起こされたと主張しています。
具体的には、DynamoDBはグローバルな支払いシステム（Payments System）には適していますが、全領域での一貫性（Full Linearizability）が必須である「台帳（Ledger）」システムには根本的に不向きです。DynamoDBは消費量ベースの料金体系（Consumption-priced database）であり、Uberが処理する1日1500万件の移動（トリップ）から発生する膨大な読み書き（Read/Write）処理は、コスト面で持続不可能でした。筆者によると、この規模での運用は、年間で数百万ドルに上る膨大な費用を発生させていました。
このコスト問題を回避するため、Uberは後にDynamoDBから自社開発の内部データベース（DocStore）を基盤とするLedgerStoreへと移行しました。しかし、筆者は、この一連の設計変更が、技術的な必要性ではなく、関与したエンジニアたちの「昇進プロジェクト」として推進された結果であると批判しています。結果として、技術的な欠陥が「ケーススタディ」として美化され、業界に誤った認識を与えている現状に強い懸念を表明しています。
背景
本記事は、大規模な金融データ処理システム（台帳システム）の設計における技術的選択と、それがもたらす経済的影響に焦点を当てています。特に、クラウドデータベースの特性（DynamoDB）が、金融システム特有の厳格な要件（グローバルな一貫性）と、運用コストの観点からどのように矛盾するかを解説しています。
重要用語解説
- DynamoDB: Amazonが提供するNoSQLデータベース。高いスケーラビリティと低レイテンシが特徴で、支払いシステムなどには適するが、全領域での厳格な一貫性（Linearizability）の確保が難しい。
- LedgerStore: UberがDynamoDBの限界を認識した後、自社開発のDocStoreを基盤として構築した、金融取引履歴を管理する台帳システム。
- Full Linearizability: システム内の全ての操作が、時間軸に沿って完全に順序付けられ、常に最新の状態が保証されるという、金融システムに必須の厳格な一貫性モデル。
今後の影響
本記事は、単なる技術批判に留まらず、大規模な金融システム設計における「コスト最適化」と「技術的健全性」の重要性を再認識させます。企業が技術的な難しさやコストを無視してシステムを構築することは、長期的な事業継続性を脅かすリスクとなるため、設計プロセス全体の見直しが求められます。