Uberの台帳データをDynamoDBからLedgerStoreへ移行

 (uber.com)
2 ポイント 投稿者 GN⁺ 2024-05-21 | 1件のコメント | WhatsAppで共有
  • 先週は、Uberの追加の専用台帳スタイルデータベースであるLedgerStore（LSG）を取り上げた。
  • 今週は、Uberのビジネスにとって重要な台帳データをLSGへ移行した方法を扱う。
  • 1兆件を超える項目（数ペタバイトのデータ）を透過的に移動し、停止なしで実施した方法と、その過程で得た学びを議論する。

経緯

  • GulfstreamはUberの決済プラットフォームで、2017年にDynamoDBを使ってローンチされた。
  • Uberの規模ではDynamoDBのコストが高くなったため、12週間分のデータ（ホットデータ）のみをDynamoDBに保持し、古いデータ（コールドデータ）はUberのblobstoreであるTerraBlobに保存し始めた。
  • 長期的な解決策としてLSGを使いたかった。LSGは決済スタイルのデータを保存するために目的特化で設計されている。
  • LSGの主な機能:
    • 検証可能な不変性（暗号署名を使って記録が変更されていないことを確認できる）
    • コスト管理のための階層型ストレージ（ホットデータはリクエスト処理に適した場所に、コールドデータは保存に最適化された場所に保持）
    • 結果整合性のあるセカンダリインデックスのレイテンシ改善
  • 2021年まで、GulfstreamはDynamoDB、TerraBlob、LSGの組み合わせでデータを保存していた。
    • DynamoDB: 直近12週間のデータ
    • TerraBlob: コールドデータ
    • LSG: データを書き込み、移行先とする対象

なぜ移行が必要だったのか？

  • LSGは不変性を備えているため、台帳スタイルのデータ保存により適している。
  • LSGへ移行することで、継続的なコスト削減効果が大きかった。
  • 3つのストレージから1つのストレージへ移行することで、Gulfstreamサービスのコードと設計を単純化できる。
  • LSGは短いインデックス作成遅延を約束しており、Uberのデータセンター内でオンプレミス稼働するため、より速いネットワークレイテンシを提供する。

データ特性に関連するリスク

  • 移行するデータは、2017年以降のUberの全ビジネス台帳データである:
    • 不変レコード: 圧縮サイズ1.2 PB
    • セカンダリインデックス: 非圧縮サイズ0.5 PB
  • 不変レコードは修正できず、セカンダリインデックスデータには問題修正のために変更できる柔軟性がある。

検証

  • バックフィルがあらゆる面で正しく受け入れ可能であることを確認するには、現在のトラフィックを処理できることと、現在アクセスされていないデータが正しいことを確認する必要がある。
  • 検証基準:
    • 完全性: すべての記録がバックフィルされたか
    • 正確性: すべての記録が正確か
    • 負荷: LSGが現在の負荷を処理できるか
    • レイテンシ: LSGのP99レイテンシが許容範囲内か
    • 遅延: セカンダリインデックス生成の遅延が許容範囲内か

シャドー検証

  • 移行前後のレスポンスを比較し、現在のトラフィックがデータ移行の問題やコードのバグによって妨げられないようにする。
  • シャドー検証により、バックフィルが少なくとも99.99%完全かつ正確であることを確認し、上限は99.9999%に設定した。
  • シャドー検証は、LSGが本番トラフィックを処理できることを確認し、データアクセスコードへの信頼を与える。
  • シャドー検証は、現在アクセス中のデータの完全性と正確性に対する信頼も提供する。

オフライン検証と増分バックフィル

  • LSGの全データをDynamoDBのデータダンプと比較した。
  • オフライン検証は、データバックフィルが正しく実行されたことを確認し、全データを対象とする。
  • オフライン検証はシャドー検証と併せて実施されるべきである。

バックフィルの課題

  • あらゆるバックフィルにはリスクがある。UberのApache Sparkを使ってバックフィルを実施した。
  • 問題への対処方法:
    • スケーラビリティ: 小規模から始めて段階的に拡大する。
    • 増分バックフィル: データを小さなバッチに分けてバックフィルする。
    • 速度制御: バックフィルジョブの速度を調整する。
    • 動的な速度制御: 現在のシステム状態を監視して速度を調整する。
    • 緊急停止: 過負荷が疑われる場合にバックフィルを素早く停止できる機能を提供する。
    • データファイルサイズ: データダンプファイルのサイズを適切に保つ。
    • 耐障害性: データ品質・破損の問題に対処する。
    • ロギング: ログを制限し、ロギング基盤に負荷をかけない。

リスク軽減

  • さまざまな検証およびバックフィル統計データを分析し、LSGのロールアウトを保守的に進めた。
  • 当初は、バックフィルが失敗した場合にDynamoDBからデータを取得するフォールバックを使っていた。
  • フォールバックログを確認し、LSGに実際にデータ欠損がないことを確認した。

結論

  • この記事では、大規模でビジネスクリティカルな台帳データを、あるデータストアから別のデータストアへ移行する過程を扱った。
  • 移行基準、検証、バックフィルの課題、安全性など、さまざまな側面を取り上げた。
  • 2年間にわたり、中断や障害なしで移行を完了した。

GN⁺の意見

  • データ移行の重要性: 大規模なデータ移行は複雑でリスクを伴うが、コスト削減とシステム単純化により長期的に大きな利点をもたらす。
  • シャドー検証の有用性: シャドー検証は、実トラフィックに影響を与えずにデータの完全性と正確性を確認できる強力な手段である。
  • オフライン検証の必要性: シャドー検証だけでは見えない問題を発見できるため、オフライン検証も不可欠である。
  • バックフィルの段階的アプローチ: バックフィル作業は小さなバッチに分けて段階的に実施することが、システム過負荷の防止に効果的である。
  • 緊急停止機能: バックフィル作業中に問題が発生した場合、迅速に停止できる機能はシステム安定性の維持に重要である。

関連記事

1件のコメント

 
GN⁺ 2024-05-21
Hacker Newsの意見

Hacker Newsコメントまとめ

  • 2 billion rides per quarter

    • Uberは四半期ごとに20億件のライドを処理している。これは1秒あたり約1000件のトランザクションに換算できる。なぜインフラの拡張性にそれほど気を遣うのか理解しにくい。

  • Using DynamoDB poorly

    • UberはDynamoDBの使い方が良くなかった。特定の重要なユーザージャーニー（CUJ）には強い整合性が必要で、過去の取引のためのデータウェアハウジングも必要だ。DynamoDBとRedshiftのアーキテクチャに移行しなかったのは不思議だ。

  • Google rejects

    • UberはGoogleで失敗したプロジェクトを持ってきたように見える。こうしたプロジェクトはたいてい大きな昇進を狙っている。「独自システムを設計・構築して$Xm節約しました！昇進させて！」というようなものだ。だが構築コストのほうが高くつき、数年後には廃止される可能性が高い。

  • SQLite on a single server

    • 1.7ペタバイトのデータ（1兆件のインデックス付きレコード）を、1台の高性能ベアメタルサーバーにSQLiteで保存できるのか気になる。例のリンクも示されている。

  • LedgerStore not open source

    • LedgerStoreはオープンソースではない。関連情報を探すにはUberのブログ記事をたどる必要がある。2021年の記事リンクが示されている。

  • Era of custom infrastructure

    • 2015年ごろにはNetflix、Spotify、SoundCloud、Uberなど多くのテック企業がインフラやデータベースツールを数多く構築していた。最近はAWSやクラウド用語で語るエンジニアが多い。今でもツールを自作する組織を見るのは新鮮だ。

  • Expensive proprietary cloud

    • 独自仕様のクラウドベースデータストアがどれほど高価かをよく示す例だ。他のものへ移行することは可能だ。

  • Considered TigerBeetle?

    • TigerBeetleを検討したのだろうか。

  • DynamoDB is expensive

    • このプロジェクトの採算性は分からないが、DynamoDBは本当に高い。他の人たちが使い方を間違えているのだと思っていたが、分散ハッシュテーブルとして使ってもなおコストが大きい。

  • Cost of running the team

    • プロジェクトチームを運営するコストは、削減額（600万ドル）と大差ないように思える。保守コストもさらにかかる。決済システムは長期的な賭けではない可能性が高い。なぜこうしたプロジェクトを進めるのか興味深い。既存のエンジニアリングチームに関わる埋没費用なのかもしれない。