Uber の大規模決済システムの構築中に学んだ分散アーキテクチャの概念

[[243320]]

2年前、私はバックエンド開発経験を持つモバイルソフトウェアエンジニアとしてUberに入社し、APP決済機能の開発と再構築を担当しました。その後、エンジニアリング管理チームに加わり、独立してチームを率いました。私のチームは多くのバックエンド決済関連システムを担当しているため、決済システム全体のバックエンドの知識に触れる機会が多くあります。

Uber で働く前は、分散システムを扱った経験はほとんどありませんでした。私の経歴は、伝統的なコンピュータサイエンスの学位と 10 年間のフルスタック ソフトウェア開発です。しかし、アーキテクチャ図を描いてトレードオフについて議論することはできましたが、分散の概念 (一貫性、可用性、またはべき等性) についてはあまり知りませんでした。

この記事では、大規模で可用性の高い分散システム (Uber を支える支払いシステム) を構築する際に習得して適用することが不可欠だと思われる概念のいくつかをまとめました。これは 1 秒あたり数千件のリクエストを処理するシステムであり、システムの一部に障害が発生した場合でも重要な支払い機能が正しく動作できる必要があります。これは完全なリストですか?おそらくそうではないでしょう。しかし、これらの概念をもっと早く知っていたら、私の仕事と生活はもっと楽になっていたでしょう。それでは、まず、SLA、一貫性、データの永続性、メッセージの永続性、べき等性など、仕事で学ぶ必要のあるその他の事柄について見ていきましょう。

サービスレベル保証

毎日何百万ものイベントを処理する必要がある大規模なシステムでは、問題が発生することは避けられません。システムの設計に取り掛かる前に、健全なシステムを構成する要素を決定することが最も重要だと私は考えています。システムの健全性は測定可能である必要があり、一般的な方法は SLA (サービス レベル契約) です。私が目にした最も一般的な SLA は次のとおりです。

1. 可用性: サービスが稼働している時間の割合。 100% 利用可能なシステムを持つという考えは魅力的ですが、この目標を達成するのは非常に困難で費用もかかります。 VISA クレジットカード ネットワーク、Gmail、インターネット プロバイダーなどの大規模で重要なシステムでも、100% の可用性は確保されておらず、数年の間に数秒、数分、または数時間ダウンする可能性があります。多くのシステムでは、4 つの 9 の可用性 (99.99%、つまり年間約 50 分のダウンタイム) が高可用性であると考えられており、通常、このレベルを達成するには多大な作業が必要です。
2. 正確性: システム内の一部のデータが不正確であったり欠落していたり​​しても許容されますか?もしそうなら、何パーセントまでが許容範囲でしょうか?私が取り組んでいる決済システムでは、精度要件は 100% であり、データが失われることは許されません。
3. 負荷容量: システムはどの程度の負荷をサポートできると予想されますか?これは通常、1 秒あたりのリクエスト数で表されます。
4. レイテンシ: システムはどのくらい速く応答する必要がありますか?リクエストの 95% と 99% に対する応答時間はどれくらいですか?システムでは通常、ノイズの多い要求が多数発生するため、実際のシステムでは P95 および P99 応答時間の方が実用的です。

大規模な支払いシステムを構築するときに SLA が重要なのはなぜですか?新しいシステムを構築し、既存のシステムを置き換えます。適切なシステムを構築できたことを確認するには、新しいシステムが古いシステムよりも優れていることを確認する必要があります。ここで、SLA を使用して期待値を定義できます。可用性は最も重要な要件の 1 つです。可用性の目標を決定したら、その目標を満たすアーキテクチャを設計する際にトレードオフを行う必要があります。

水平および垂直スケーリング

新しいシステムを利用するビジネスが拡大し続けると、負荷は増加し続けることになります。ある時点で、既存の構成では追加の負荷をサポートできなくなり、システム容量を追加する必要があります。現時点で最も一般的に使用されている拡張戦略は、水平拡張と垂直拡張の 2 つです。

水平拡張とは、システムにマシン/ノードを追加して、システム全体の容量を増やすことを指します。水平スケーリングは、分散システムの容量を増やす最も一般的な方法です。特に、クラスターに (仮想) マシンを追加するのは、通常、Web ページ上のボタンをクリックするのと同じくらい簡単なためです。

垂直スケーリングは、基本的に、より強力なマシンを購入することによって実現されます。これは、（仮想）マシンにプロセッサ コアやメモリなどを追加することにすぎません。垂直スケーリングは、水平スケーリングよりもコストがかかるため、分散システムでは通常あまり人気がありません。ただし、StackOverflow などのいくつかの重要なサイトは、システムの需要を満たすために垂直方向にスケーリングすることに成功しています。

大規模な決済システムを構築するときに、システムスケーリング戦略がなぜそれほど重要なのでしょうか?私たちは早い段階で、水平方向にスケーラブルなシステムを構築することを決定しました。垂直スケーリングは場合によっては可能ですが、当社の支払いシステムはすでに推定負荷に達しているため、将来は言うまでもなく、今日のこの状況で単一の高価なメインフレームがそれをサポートできるかどうかについては悲観的です。私たちのチームには、かつて大手決済プロバイダーで働いていて、当時利用可能だったメインフレーム上でシステムを垂直に拡張しようとして失敗したエンジニアもいます。

一貫性

あらゆるシステムの可用性は重要です。分散システムは、可用性の低いマシン上に構築されることがよくあります。 99.999% の可用性 (年間で約 5 分間の非可用性) を備えたシステムを構築することが目標であるとします。当社が使用するマシン/ノードの平均可用性は 99.9% (年間のダウンタイムは約 8 時間) です。目標の可用性を達成する簡単な方法は、クラスターに複数のマシン/ノードを追加することです。クラスター内の一部のノードに障害が発生した場合でも、他のノードが利用可能であり、システム全体の可用性は単一ノードの可用性よりも高くなります。

一貫性は高可用性システムにおける重要な問題です。クラスター内のすべてのノードが同時に同じデータを参照して返す場合、システムは一貫しています。以前のモデルに戻ると、可用性を高めるためにノードのセットを追加しましたが、システムの一貫性を維持することは簡単な作業ではありません。各ノードが同じデータを持つようにするには、ノード間でメッセージを送信してデータの同期を維持する必要があります。しかし、相互に送信されたメッセージが届かない、メッセージが失われる、または一部のノードが利用できなくなる可能性があります。

一貫性は、理解するのにかなりの時間を要した概念です。一貫性モデルにはいくつかありますが、分散システムで最も一般的に使用されるのは、強い一貫性、弱い一貫性、結果的な一貫性です。 Hackernoon のこの最終的な一貫性と強い一貫性に関する記事では、これらのモデル間のトレードオフの実用的な概要が示されています。一般的に、一貫性が弱いほど、システムは高速になる傾向がありますが、最新のデータセットが返されない可能性も高くなります。

大規模な支払いシステムを構築するときに一貫性が重要なのはなぜですか?システム内のデータは一貫している必要がありますが、どの程度一貫しているのでしょうか?システムの一部では、強力に一貫性のあるデータのみが有効です。たとえば、ユーザーの支払い操作が開始されたかどうかを知ることは、強力な一貫性のある方法で保存する必要があります。ビジネス上重要ではないその他の部分については、最終的な一貫性は妥当なトレードオフと見なされます。良い例としては、最近のトランザクションを一覧表示する機能があります。これは、最終的に一貫性のある方法で実装できます (つまり、最新のトランザクションは、しばらくしてからクラスター内の一部のノードにのみ表示され、その代わりに、クエリはより低いレイテンシまたはより少ないリソース消費で返されます)。

データの永続性

永続性とは、データがデータ ストアに正常に追加されると、将来も常に利用可能になることを意味します。システム内の一部のノードがオフラインになったり、クラッシュしたり、データが破損したりした場合でも、データの可用性は影響を受けません。

分散データベースによって永続性は異なります。マシン/ノード レベルでの永続性をサポートするものもあれば、クラスター レベルでサポートするものもあり、この機能をサポートしないものもあります。耐久性を高めるために、何らかの形式のレプリケーションがよく使用されます。つまり、データが複数のノードに保存されている場合、1 つ以上のノードに障害が発生してもデータは引き続き利用できます。分散システムでデータの永続性を実装することがなぜ難しいのかについて説明した優れた記事があります。

大規模な決済システムを構築するときにデータの永続性が重要なのはなぜですか?支払い機能など、システムのほとんどの機能ではデータが非常に重要であるため、データの損失は許可されません。私たちが構築する分散データ ストアは、クラスター レベルのデータの永続性をサポートする必要があります。これにより、クラスター内のインスタンスがクラッシュしても、完了したトランザクションは永続化されます。現在、Cassandra、MongoDB、HDFS、Dynamodb などのほとんどの分散データ ストレージ サービスは、さまざまなレベルのデータ永続性をサポートしており、構成を通じてクラスター レベルの永続性を提供できます。

メッセージの永続性

分散システム内のノードは、計算の実行、データの保存、および相互へのメッセージの送信を担当します。メッセージングの重要な特徴は、メッセージの信頼性です。ビジネスクリティカルなシステムでは、通常、メッセージ損失がゼロであることが求められます。

分散システムの場合、メッセージングは​​通常、RabbitMQ、Kafka などの分散メッセージング サービスによって行われます。これらのメッセージング サービスは、さまざまなレベルのメッセージング信頼性をサポートしている (またはサポートするように構成されている) 場合があります。

メッセージの永続性とは、メッセージを処理しているノードで何らかの障害が発生した場合、障害が解決された後もメッセージが引き続き処理されることを意味します。メッセージの永続性は通常、メッセージ キュー レベルで使用されます。永続的なメッセージ キューの場合、メッセージが送信された後にキュー (またはノード) がオフラインになった場合でも、オンラインに戻ったときにメッセージを受信できます。このトピックの詳細については、この記事を参照してください。

大規模な決済システムを構築するときに、メッセージの永続性がなぜそれほど重要なのでしょうか?消費者が乗車料金を支払ったというメッセージなど、システム内には失われることのできないメッセージが存在するためです。つまり、使用するメッセージング システムはロスレスでなければなりません。つまり、すべてのメッセージは 1 回だけ配信される必要があります。しかし、各メッセージが 1 回だけ配信されるシステムを構築することと、各メッセージが少なくとも 1 回は配信されるシステムを構築することとの間には複雑さの点で違いがあります。私たちは、少なくとも 1 回の配信を備えた永続的なメッセージング システムを実装することを決定し、それを構築するメッセージ バスを選択しました (最終的に Kafka を選択し、このユース ケース用にロスレス クラスターを構成しました)。

冪等性

分散システムでは、接続の中断や要求のタイムアウトなどのエラーが発生する可能性がしばしばあります。通常、クライアントはこれらのリクエストを再試行します。べき等システムでは、特定のリクエストが何回実行されても、そのリクエストの実際の実行は 1 回だけ行われます。良い例は支払いです。クライアントが支払いをリクエストし、リクエストは成功してもクライアントがタイムアウトすると、クライアントは同じリクエストを再試行する可能性があります。べき等システムの場合、支払者は二重に請求されることはありませんが、非べき等システムの場合は 2 回の控除が発生します。

べき等分散システムを設計するには、何らかの分散ロック戦略が必要です。ここで、初期の分散システムの概念が役立ちます。同時更新を回避するために楽観的ロックを通じてべき等性を実現しようとしているとします。楽観的ロックを実現するには、システムが強力な一貫性を備え、操作を実行するときに、何らかのバージョン管理を使用して、別の操作がすでに進行中かどうかを確認できるようにする必要があります。

システムの制約と操作の種類に応じて、べき等性を実現する方法は複数あります。べき等メソッドの設計は良い挑戦であり、Ben Nadel は分散ロックやデータベース制約など、彼が使用するさまざまな戦略について記事で説明しています。分散システムを設計する場合、おそらく最も見落とされがちな側面の 1 つがべき等性です。特定の重要な操作の正しいべき等性を確保しなかったためにチームが苦しんだシナリオに遭遇したことがあります。

大規模な決済システムを構築するときに冪等性が重要なのはなぜですか?最も重要なのは、二重請求や二重払い戻しを避けることです。私たちのメッセージング システムには少なくとも 1 回のロスレス配信があるため、すべてのメッセージが複数回配信される可能性があると想定する必要がありますが、システムはべき等性を確保する必要があります。私たちはこの問題をバージョン管理と楽観的ロックを通じて処理することを選択しました。これにより、べき等動作を実装するシステムが、強力に一貫性のあるストレージをデータ ソースとして使用できるようになります。

シャーディングとクォーロム

分散システムでは、多くの場合、単一のノードで保存できるデータよりも多くのデータを保存する必要があります。では、大量のデータを一定数のマシンに保存するにはどうすればよいでしょうか?最も一般的な手法はシャーディングを使用することです。データは、何らかのハッシュ アルゴリズムを使用して水平に分割され、パーティションに割り当てられます。多くの分散データベースではすでに最下位レベルでシャーディングが実装されていますが、シャーディングは、特に再シャーディングに関して、さらに学ぶ価値のある興味深い領域です。 Foursquare は、シャーディングのエッジ ケースが発生したため、2010 年に 17 時間のダウンタイムが発生しましたが、根本原因については適切な分析が行われています。

多くの分散システムでは、データや計算が複数のノードに複製されます。これらの操作が一貫した方法で実行されるようにするために、操作が成功するためには一定数のノードが同じ結果に達する必要がある投票ベースの方法 (クォーラム) が定義されています。

Uber の支払いシステムを構築する際に、クォーラムとシャーディングが重要なのはなぜですか?どちらも非常に一般的で基本的な概念です。 Cassandra レプリカを構成する方法を調べているときに、この概念に出会いました。 Cassandra (およびその他の分散システム) は、クラスター全体の一貫性を確保するためにクォーラムとローカル クォーラムを使用します。興味深い副作用として、私たちの会議のいくつかでは、十分な人数が部屋に集まると、誰かが「始めてもいいですか？定足数に達していますか？」と尋ねます。

俳優モデル

変数、インターフェース、呼び出しメソッドなど、プログラミング手法を記述するために使用される一般的な語彙はすべて、単一マシン システムを想定しています。分散システムについて議論するときは、異なるアプローチを使用する必要があります。これらのシステムを説明する一般的な方法は、通信の観点からコードを考えるアクター モデルに従うことです。このモデルは、たとえば組織内で人々がどのようにコミュニケーションするかを説明するために私たちが考えるメンタルモデルと一致するため、人気があります。分散システムを説明するもう 1 つの一般的な方法は、CSP (Communicating Sequential Processes) です。

アクター モデルは、アクターが互いにメッセージを送信し、それに応答することに基づいています。各アクターは、他のアクターを作成したり、他のアクターにメッセージを送信したり、次のメッセージで何を行うか決定したりするなど、限られた一連の操作を実行できます。複雑な分散システムは、いくつかの単純なルールで適切に記述でき、これらのシステムはアクターがクラッシュした後も自己修復できます。簡単にまとめると、Brian Storti 氏の記事「10 分でアクター モデルを理解する」をお勧めします。多くのプログラミング言語では、アクター ライブラリまたはフレームワークが実装されています。たとえば、Uber では一部のシステムで Akka ツールキットを使用しています。

大規模な分散システムを構築するときにアクター モデルが重要なのはなぜですか?当社にはシステムに取り組んでいるエンジニアが多数おり、その多くは分散システムの経験を持っています。私たちは、車輪の再発明につながる可能性のある配布モデルのコンセプトを自分たちで考え出すのではなく、標準的な配布モデルに従うことにしました。

レスポンシブアーキテクチャ

大規模な分散システムを構築する場合、多くの場合、弾力的なスケーラビリティが目標となります。おそらくそれは支払いシステムか、あるいは別の高負荷システムですが、パターンはおそらく同様です。業界では、このような状況でうまく機能するベストプラクティスを発見して共有しており、レスポンシブ アーキテクチャはこの分野で人気があり、広く使用されているパターンです。

Reactive Architecture を始める前に、Reactive Manifesto を読んで、このトピックに関する 12 分間のビデオを視聴することをお勧めします。

大規模な決済システムを構築するときに、リアクティブ アーキテクチャが重要なのはなぜですか?新しい支払いシステムのほとんどを構築するために使用するツールキットである Akka は、リアクティブ アーキテクチャの影響を強く受けています。このシステムに取り組んでいる当社のエンジニアの多くは、レスポンシブのベストプラクティスにも精通しています。リアクティブ原則に従うこと、つまり、応答性が高く、回復力のある、メッセージ駆動型のシステムを構築することは、私たちにとって非常に自然なことでした。信頼できるモデルがあり、進捗が正しい方向に進んでいるかどうかを確認できることは有益だと考えており、今後もこのモデルを使用してシステムを構築していきます。

要約する

私は幸運にも、Uber の支払いシステムのような、拡張性が高く、分散化された、ミッションクリティカルなシステムの再構築に携わることができました。この環境で作業することで、これまで使用したことのない多くの分散概念を学びました。この記事の要約を通じて、分散システムの学習を始めたり継続したりする他の人の役に立つことを願っています。

この記事では、これらのシステムの設計とアーキテクチャに焦点を当てていますが、高負荷システムの構築、展開、システム間の移行、およびそれらを確実に運用することについては、さらに多くのことが説明されています。しかし、それはすべて別の記事のテーマです。

翻訳者について: Gu Haoxin、「Android Advanced」および「Android Advanced (Source Code Analysis)」の著者。