- Stripeは2023年に総決済額1兆ドルを処理しながら、99.999%の稼働率を維持した
- Stripeのデータベースインフラチームは、APIの基盤レイヤーとしてDocDBというdatabase as a service（DBaaS）を提供している
- DocDBはMongoDB Communityの拡張版で、Stripe社内で構築した複数のサービスで構成されている
- 毎秒500万件を超えるクエリを処理し、ペタバイト級の重要な金融データを2,000超のデータベースシャードに分散して5,000超のコレクションへ保存している
- MongoDB Communityを選んだ理由は、ドキュメントモデルの柔軟性と大規模なリアルタイムデータ処理能力にあった
- 2011年当時はMongoDB Atlasが存在せず、クラウド上で動作する自己管理型MongoDBインスタンスのクラスターを構築した
- DocDBの中核はData Movement Platform
- もともとはMongoDBの垂直スケーリングの限界を克服するための水平スケーリングソリューションとして構築されたが、多様な目的向けにカスタマイズされた
- 稼働率と効率向上のための未使用データベースシャードの統合、信頼性向上のためのデータベースエンジンのメジャーバージョンアップグレード、大規模ユーザー向けのマルチテナントからシングルテナントへの移行など
- Data Movement Platformにより、少数の大容量データベースシャードから多数の小容量データベースシャードへの移行が可能になった
- さらに、クライアントに透過的な移行とゼロダウンタイムを実現し、高い弾力性を持つDBaaSを提供できる
- DocDBはトラフィック急増時にはデータベースシャードを分割し、トラフィックが低いときにはbin packingによって数千のデータベースを統合できる
データベースインフラの構築方法
- Stripeは2011年のサービス開始時、標準的なリレーショナルデータベースより開発者生産性に優れるMongoDBをオンラインデータベースとして採用した
- MongoDB上でAPIの安定性を最優先する堅牢なデータベースインフラを運用したかったが、要件を満たす既製のDBaaSは見つからなかった
- 最高水準の可用性、耐久性、性能を満たすこと
- クライアントアプリケーションの最適化されていないクエリによる独自の問題を防ぐため、データベース機能の公開を最小限にすること
- シャーディングによる水平スケーラビリティをサポートすること
- 強制クォータ付きマルチテナンシーへの一級のサポートを提供すること
- 認可ポリシーの適用による強力なセキュリティを提供すること
- 解決策は、MongoDBを基盤ストレージエンジンとしてDocDBを構築することだった。真に弾力的でスケーラブルなDBaaSであり、オンラインデータ移行がその中核となっている
- Stripeのプロダクトアプリケーションは、信頼性、スケーラビリティ、許可制御、アクセス制御の問題を適用するためにGoで社内開発したデータベースプロキシサーバーフリートを通じて、データベース内のデータにアクセスする
- 水平スケーリング機構としてシャーディングを採用するという中核的なアーキテクチャ判断を行った
- 累積データの小さなチャンクをそれぞれ保持する数千のデータベースシャードが、現在ではStripeのすべての製品の基盤となっている
- アプリケーションがデータベースプロキシサーバーにクエリを送ると、クエリを解析して1つ以上のシャードへルーティングし、その結果を結合してアプリケーションへ返す
- データベースプロキシサーバーは、チャンクメタデータサービスに依存してチャンクをデータベースシャードへマッピングすることで、与えられたクエリに関連するシャードを容易に検索できる
- データベースへの書き込みによる変更イベントはストリーミングソフトウェアシステムへ送られ、最終的には変更データキャプチャ（CDC）パイプラインを通じてオブジェクトストレージに保存される
- Stripeのチームは、プロダクトアプリケーション層で社内のドキュメントデータベース制御プレーンを使い、関連する目的を持つドキュメントで構成される1つ以上のDocDBコレクションを含む「論理データベース」と呼ばれるデータの論理コンテナをプロビジョニングする
- これらのDocDBコレクションのデータは、コレクションの小さなチャンクを保持する複数のデータベース（物理データベース）に分散している
- DocDBの物理データベースは、プライマリノードと、レプリケーションおよび自動フェイルオーバーを備えた複数のセカンダリノードから成るレプリカセットとしてデプロイされたシャード上に配置される
Data Movement Platformの設計方法
- プロダクトアプリケーションの要求に応じてスケールアウト・スケールインできる、水平方向に拡張可能で高い弾力性を持つDBaaSを構築するには、クライアントに透過的な形でゼロダウンタイムのままデータベースシャード間でデータを移行できる機能が必要だった
- これは、重要な金融データ特有の要件によってさらに複雑になる、難易度の高い分散システムの課題である
- データ整合性と完全性: 移行対象データがソースシャードとターゲットシャードの両方で整合性と完全性を維持することを保証しなければならない
- 可用性: データ移行中の長時間のダウンタイムは許されない。何百万もの企業が24時間365日、顧客の決済を受けるためにStripeへ依存しているため
- 目標は、移行プロセスの中核ステップを、計画されたデータベースプライマリのフェイルオーバー時間（通常は数秒程度）より短く保ち、プロダクトアプリケーションのリトライ予算に収めること
- 粒度と適応性: Stripeの規模では、任意の数のデータチャンクを任意の数のソースからターゲットシャードへ移行できなければならない
- フリート内で進行中のデータベースチャンク移行数に制限がなく、特定時点で特定のシャードが関与できる移行数にも制限がないことが必要
- また、多くのデータベースシャードがテラバイト級のデータを含むため、さまざまなサイズのチャンクを高スループットで移行できる必要がある
- ソースシャードへの性能影響なし: データベースチャンクをシャード間で移行する際、ユーザークエリの性能や利用可能スループットに悪影響を与えないよう、ソースシャードの性能とスループットを保全することが目標
- これらの要件に対応するため、専用構築したサービスを呼び出してデータベースシャード間のオンラインデータ移行を管理するData Movement Platformを構築した
- Data Movement PlatformのCoordinatorコンポーネントは、オンラインデータ移行に関わる複数のステップをオーケストレーションする役割を担い、以下で説明する各構成ステップを実行するために関連サービスを呼び出す
1段階: チャンク移行の登録
- まず、チャンクメタデータサービスで、データベースチャンクをソースシャードから任意のターゲットシャードへ移行する意図を登録する
- その後、移行対象チャンクについてターゲットシャード上にインデックスを構築する
2段階: 大量データの取り込み
- 次に、時刻Tにおけるソースシャードのチャンクスナップショットを使って、データを1つ以上のデータベースシャードへロードする
- 大量データ取り込みを実行するサービスはさまざまなデータフィルタに対応し、フィルタ条件を満たすデータチャンクだけを取り込む
- 当初は単純に見えたが、DocDBシャードにデータを大量ロードする際にスループット制限へ直面した
- 書き込みをバッチ化し、最適な大量データ収集のためにDocDBエンジンのパラメータ調整も試みたが、大きな成果は得られなかった
- しかし、DocDBがB-treeデータ構造を使ってデータを整列する点を活用し、挿入順序を最適化する方法を模索したことで大きな突破口を得た
- コレクションで最も一般的なインデックス属性に基づいてデータを並べ替え、その順序で挿入することで書き込み局所性が大幅に向上し、書き込みスループットを10倍に高めた
3段階: 非同期レプリケーション
- ターゲットシャードへデータを取り込んだ後、移行中のデータベースチャンクについて時刻T以降、ソースからターゲットシャードへの書き込みレプリケーションを開始する
- 非同期レプリケーションシステムは、CDCシステムのソースシャードへの書き込みで生じた変更を読み取り、ターゲットシャードで書き込みを実行する
- operation log、またはoplogは、各DocDBシャードの特別なコレクションであり、そのシャードのデータベース内データを変更するすべての操作の記録を保持する
- すべてのDocDBシャードのoplogをイベントストリーミングプラットフォームであるKafkaへ送信し、その後Amazon S3のようなクラウドオブジェクトストレージサービスに保存する
- KafkaおよびAmazon S3上のoplogイベントを使って、1つ以上のソースDocDBシャードから1つ以上のターゲットDocDBシャードへ変更をレプリケートするサービスを構築した
- CDCシステムのoplogイベントに依存することで、ソースシャード上のユーザークエリに使える読み取りスループットを消費して速度を低下させることなく、かつソースシャードのoplogサイズ制約にも縛られないようにした
- このサービスは、ターゲットシャードが利用できない場合でも弾力的であり、いつでもチェックポイントから同期の開始、一時停止、再開ができるよう設計されている
- レプリケーションサービスはレプリケーション遅延を取得する機能も提供する
- 移行中チャンクの変更は、ソースシャードからターゲットシャードへ、またその逆方向にも双方向でレプリケートされ、レプリケーションサービスは循環する非同期レプリケーションを防ぐため、自ら発行する書き込みにタグを付与する
- これは、ターゲットシャードへトラフィックを切り替えた際に問題が発生しても、ソースシャードへトラフィックを戻せる柔軟性を持たせるための意図的な設計選択だった
4段階: 正確性の検証
- ソースシャードとターゲットシャード間のレプリケーションが同期した後、特定時点のスナップショットを比較し、データ完全性と正確性を包括的に検証する
- これはシャードのスループットへ影響を与えないよう、意図的に選ばれた設計判断である
5段階: トラフィック切り替え
- チャンクのデータがソースからターゲットシャードへ取り込まれ、変更が活発にレプリケートされるようになると、Coordinatorによってトラフィック切り替えがオーケストレーションされる
- 移行対象データチャンクの読み取り・書き込み経路を切り替えるには、まずソースシャードのトラフィックを一時停止し、チャンクメタデータサービス内の経路を更新し、プロキシサーバーがターゲットシャードへ読み取り・書き込みをリダイレクトする必要がある
- トラフィック切り替えプロトコルは、バージョンゲーティングの考え方に基づいている
- 定常状態では、各プロキシサーバーはDocDBシャードへのリクエストにバージョントークン番号を付加する
- MongoDBにカスタムパッチを追加し、シャード側がプロキシサーバーから受け取ったリクエストのバージョントークン番号が、自身の認識している番号より新しいかを確認し、この条件を満たすリクエストだけを処理できるようにした
- チャンク経路を更新するため、Coordinatorを使って以下の手順を実行する:
- まずソースDocDBシャードのバージョントークン番号を引き上げる。バージョントークン番号はDocDBの特別なコレクション内ドキュメントに保存されており、この時点でソースシャード上のそのチャンクへのすべての読み取り・書き込みは拒否される
- 次に、レプリケーションサービスがソースシャード上の未解決書き込みをレプリケートし終えるまで待つ
- 最後に、チャンクメタデータサービスでチャンクの経路をターゲットシャードとそのバージョントークン番号を指すよう更新する
- 完了すると、プロキシサーバーはチャンクメタデータサービスから、そのチャンクの更新済み経路と最新のバージョントークン番号を取得する
- プロキシサーバーは更新済みのチャンク経路を使い、そのチャンクへの読み取り・書き込みをターゲットシャードへルーティングする
- トラフィック切り替えプロトコル全体の実行時間は2秒未満で、ソースシャードへ送られた失敗した読み取り・書き込みは、リトライ時にすべて成功する
6段階: チャンク移行登録の解除
- 最後に、チャンクメタデータサービスで移行を完了済みとしてマークし、ソースシャードからチャンクデータを削除して移行プロセスを終了する
Data Movement Platformの活用
- DocDBシャード間でオンライン方式によりデータチャンクを移行できる機能は、Stripeの成長速度に合わせてデータベースインフラを水平方向に拡張する助けとなっている
- データベースインフラチームのエンジニアは、ボタンをクリックするだけでサイズとスループットに応じてDocDBシャードを分割でき、プロダクトチーム向けにデータベースストレージとスループットの余裕を確保できる
- 2023年には、Data Movement Platformを使ってデータベースインフラの活用効率を改善した
- 具体的には、プロダクトアプリケーションに透過的な形で1.5ペタバイトのデータを移行し、低利用率の数千のデータベースをbin-packして、基盤となるDocDBシャード総数をおよそ4分の3まで削減した
- また、Data Movement Platformを用いて、中間のメジャー／マイナーバージョンを経由せず、データを1段階で新しいMongoDBバージョンへforklift移行し、データベースインフラフリートをアップグレードした
- Stripeのデータベースインフラチームは、インターネット経済の成長に合わせて拡張する堅牢で信頼性の高い基盤の構築に注力している
- 現在はサイズとスループットに基づいてシャード間で事前にデータを平準化するヒート管理システムを試作しており、トラフィックパターンの変化に動的に対応するシャード自動スケーリングにも投資している
まだコメントはありません。