大規模な支払いシステムを構築するときに出会った分散アーキテクチャの概念

2年前、バックエンド開発の経験があるモバイル開発者としてUberに入社しました。 ここで、私はアプリケーションで支払い機能を開発していました-そして、そのプロセスでアプリケーション自体を書き直しました 。 その後、開発管理に移り 、チーム自体を率いました。 このおかげで、支払いを許可するバックエンドシステムの多くを私のチームが担当しているため、バックエンドをより詳しく知ることができました。



Uberで働く前は、分散システムの経験がありませんでした。 コンピューターサイエンスの伝統的な教育を受けた後、10年間フルスタックの開発に携わりました。 したがって、さまざまな図を描き、システムのトレードオフについて話すことはできましたが、その時までに、たとえば一貫性 、 可用性 、べき等性などの配布の概念をよく理解していませんでした。



この投稿では、今日のUberで機能する大規模で高可用性の分散支払いシステムを構築する際に、検討して実践する必要があるいくつかの概念について説明します。 これは、1秒あたり最大数千の要求の負荷があるシステムであり、システムの特定の部分が機能しなくなった場合でも、支払いの重要な機能が正しく機能するはずです。



これは完全なリストですか？ ほとんどありません。 ただし、これらの概念について自分で以前に自分で学んだ場合、これは私の人生をずっと楽にしてくれるでしょう。



それでは、SLA、一貫性、データの寿命、メッセージセキュリティ、べき等性、および新しい仕事で学ぶために必要なその他のことに没頭しましょう。

SLA

1日に数百万のイベントを処理する大規模なシステムでは、定義上、間違いが発生することがあります。 そのため、システム計画に入る前に最も重要なステップは、「健康な」システムとは何かを判断することです。 「健康」の程度は、 実際に測定できるものでなければなりません。 システムの「健全性」を測定する一般に受け入れられている方法は、 SLA （ サービスレベル契約 ）です。 以下は、私が実際に遭遇した最も一般的なタイプのSLAの一部です。

• 可用性 ：サービスが動作している時間の割合。 100％のアクセシビリティを達成する誘惑があったとしても、この結果を達成することは非常に困難な作業であり、さらに非常に高価になる可能性があります。 VISAカード、Gmail、またはインターネットプロバイダーのネットワークのような大規模で重要なシステムでさえ、100％の可用性はありません。ダウンタイムに費やされる時間は、数年、数分、または数時間になります。 多くのシステムでは、4ナインの可用性（99.99％、つまり年間約50分のダウンタイム ）が高可用性と見なされます。 このレベルに到達するには、かなり汗をかかなければなりません。
• 正確性 ：データ損失は許容できるか、または不正確ですか？ もしそうなら、何パーセントが受け入れられますか？ 私が取り組んでいた支払いシステムの場合、データは失われなかったので、この数字は100％だったはずです。
• 容量 ：システムはどの負荷に耐えなければなりませんか？ このメトリックは通常、1秒あたりのクエリで表されます。
• 遅延 ：システムはどのくらい応答する必要がありますか？ リクエストの95％と99％をどのくらいの期間処理する必要がありますか このようなシステムでは、通常、クエリの多くは「ノイズ」であるため、 p95およびp99の遅延は、現実の世界でより実用的なアプリケーションを見つけます。

大規模な支払いシステムを作成するときにSLAが必要なのはなぜですか？ 既存のシステムを置き換える新しいシステムを作成しています。 すべてを正しく実行し、新しいシステムが前のシステムよりも「優れている」ことを確認するために、SLAを使用して、システムからの期待を判断しました。 可用性は最も重要な要件の1つでした。 目標を設定するとすぐに、これらの指標を達成するために、アーキテクチャの妥協点に対処する必要がありました。

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

新しく作成したシステムを使用するビジネスが成長するにつれて、システムへの負荷は増加します。 ある時点で、既存のインストールでは負荷のさらなる増加に耐えることができなくなり、許容される負荷を増やす必要があります。 2つの一般的なスケーリング戦略は、垂直スケーリングまたは水平スケーリングです。



水平スケーリングでは、システムにマシン（またはノード）を追加して容量を増やします。 水平スケーリングは、分散システムをスケーリングする最も一般的な方法です。



垂直スケーリングは、本質的に「より大きな/より強力なマシンを購入する」-より多くのコア、より優れた処理能力、より多くのメモリを備えた（仮想）マシンです。 分散システムの場合、垂直スケーリングは水平スケーリングよりも高価になる可能性があるため、通常はあまり人気がありません。 ただし、Stack Overflowなどの一部の有名な大規模サイトは、負荷に合わせて垂直方向に正常にスケーリングされています。



大規模な支払いシステムを作成するときに、スケーリング戦略が理にかなっているのはなぜですか？ 早い段階で、水平方向に拡張できるシステムを構築することにしました。 場合によっては垂直スケーリングが許容されるという事実にもかかわらず、私たちの支払いシステムはその時までに予測された負荷にすでに達していました。 。 さらに、私たちのチームには、大規模な支払いサービスのプロバイダーで働いていて、その年にお金で買える最も強力なマシンでさえ垂直に拡張しようとする否定的な経験を持った人が含まれていました。

一貫性

システムの可用性は重要です。 分散システムは、個々の可用性がシステム全体の可用性よりも低いマシンから構築されることがよくあります。 99.999％の可用性を持つシステムを構築することを目標にしましょう（ダウンタイムは約5分/年です）。 平均で99.9％の可用性を持つマシン/ノードを使用します（1年あたり約8時間ダウンタイムにあります）。 必要なアクセシビリティインジケーターを実現する直接的な方法は、これらのマシン/ノードをクラスターにさらに追加することです。 一部のノードが「ダウン」していても、他のノードはサービスを継続し、システム全体の可用性は個々のコンポーネントの可用性よりも高くなります。



一貫性は、アクセスしやすいシステムの重要な問題です。 すべてのノードが同じデータを同時に表示して返す場合、システムは一貫しています。 以前のモデルとは異なり、より多くのノードを追加して可用性を高めた場合、システムの一貫性を維持することは簡単ではありません。 各ノードに同じ情報が含まれるようにするには、常に同期するために、お互いにメッセージを送信する必要があります。 ただし、相互に送信するメッセージは配信されない場合があります。メッセージが失われ、一部のノードが利用できない場合があります。



一貫性とは、理解して理解するまでに実現に最も時間がかかった概念です。 一貫性にはいくつかのタイプがあり、分散システムで最も広く使用されているのは、 強い一貫性 、 弱い一貫性、および最終的な 一貫性です。 この記事の各モデルの長所と短所についての実用的な説明を読むことができます。 通常、必要なレベルの一貫性が弱いほど、システムの動作は速くなりますが、最新のデータセットを返さない可能性が高くなります。



大規模な支払いシステムを作成するときに一貫性を考慮する必要があるのはなぜですか？ システム内のデータは一貫している必要があります。 しかし、どのくらい合意されていますか？ システムの一部の部分では、非常に一貫性のあるデータのみが適しています。 たとえば、支払いが開始されたという情報を非常に一貫した形式で保持する必要があります。 システムの他の部分はそれほど重要ではないため、一貫性は最終的に合理的な妥協と見なすことができます。



これは、最近のトランザクションのリストの結論によってよく示されています：最終的な一貫性を使用して実装できます-つまり、最後のトランザクションはシステムの一部にしばらくしてから表示されますが、これにより、リストクエリはより少ない遅延で結果を返します完了するのに必要なリソースが少なくなります。

データの耐久性

耐久性とは、データがデータウェアハウスに正常に追加されると、将来的に利用できるようになることを意味します。 これは、システムのノードがオフラインになったり、障害が発生したり、ノードのデータが破損したりした場合でも当てはまります。



異なる分散データベースには、異なるレベルのデータ寿命があります。 マシン/ノードレベルでデータの耐久性をサポートするものもあれば、クラスターレベルでサポートするものもあり、この機能をすぐに使用できないものもあります。 通常、耐久性を高めるために何らかの形式のレプリケーションが使用されます。データが複数のノードに保存され、ノードの1つが機能しなくなった場合でも、データは利用可能です。 分散システムで長寿命を達成することが重大な課題になる理由を説明する良い記事があります。



支払いシステムを構築するときにデータの耐久性が重要なのはなぜですか？ データが重要な場合（支払いなど）、システムの多くの部分でデータを失うことはできません。 構築した分散データウェアハウスは、クラスターレベルでデータの寿命を維持することになっていたため、インスタンスが「落ちた」としても、完了したトランザクションは保存されます。 現在、Cassandra、MongoDB、HDFS、またはDynamodbなどのほとんどの分散ストレージサービスはすべて、さまざまなレベルで耐久性をサポートしており、すべてクラスターレベルの耐久性を提供するように構成できます。

メッセージの永続性と耐久性

分散システムのノードは、計算を実行し、データを保存し、相互にメッセージを送信します。 メッセージ送信の重要な特徴は、これらのメッセージがどれだけ確実に届くかです。 重要なシステムの場合、多くの場合、メッセージが失われないという要件があります。



分散システムの場合、 メッセージングは通常、RabbitMQ、Kafkaなどの分散メッセージングサービスを使用して行われます。 これらのメッセージブローカーは、さまざまなレベルのメッセージ配信の信頼性をサポートできます（またはサポートするように構成されています）。



メッセージの安全性とは、メッセージを処理するノードで障害が発生した場合、問題が解決した後でもメッセージを処理できることを意味します。 メッセージの寿命は通常、 メッセージキューレベルで使用されます。 長いメッセージキューを使用すると、メッセージの送信時にキュー（またはノード）がオフラインになった場合でも、オンラインに戻ったときにメッセージを受信します。 このテーマに関する詳細な記事はこちらから入手できます 。



大規模な支払いシステムの構築において、メッセージの安全性と耐久性が重要なのはなぜですか？ 失うことのできないメッセージがありました。たとえば、旅行代金を支払うために人が支払いを開始したというメッセージです。 これは、使用しなければならなかったメッセージングシステムが損失なく動作することを意味しました。各メッセージは1回配信する必要がありました。 ただし、各メッセージを少なくとも 1回以上正確に配信するシステムの作成は、その難易度が大幅に異なるタスクです。 少なくとも1回配信するメッセージングシステムを実装することを決定し、その上に構築することを決定したメッセージングバスを選択しました（この場合に必要な損失のないクラスターを作成するKafkaを選択しました）。

べき等

分散システムの場合、何かがうまくいかない可能性があります-接続が途中で切れたり、タイムアウトによってリクエストが落ちたりすることがあります。 顧客はしばしばこれらのリクエストを繰り返します。 べき等システムは、何が起こっても、特定のリクエストが何回実行されても、このリクエストの実際の実行は1回だけであることを保証します。 良い例は、支払いをすることです。 クライアントが支払い要求を作成した場合、要求は成功しますが、クライアントがタイムアウトに陥った場合、クライアントは同じ要求を繰り返すことができます。 べき等システムの場合、支払いを行う人からお金が2回差し引かれることはありません。 しかし、非理想的なシステムの場合、これは非常に起こりうることです。



べき等分散システムの設計には、ある種の分散ロック戦略が必要です。 ここで、前に説明した概念が役立ちます。 同時更新を回避するために楽観的ロックを使用してi等性を実現するつもりだとしましょう。 楽観的ロックに頼るには、システムを厳密に調整する必要があります。これにより、操作中に何らかのバージョン管理を使用して別の操作が開始されたかどうかを確認できます。



べき等性を実現するには多くの方法があり、それぞれの特定の選択は、システムの制限と実行される操作の種類に依存します。 べき等のアプローチを設計することは開発者にとって価値のある課題です。BenNadelの投稿を見てください。彼は 、分散ロックやデータベースの制約など、 使用したさまざまな戦略について語ってい ます 。 分散システムを設計するとき、べき等性は、見落としている部分の1つであることが簡単に判明する可能性があります。 私たちの実践では、いくつかの主要な操作に正しいべき等性が存在することを確信していないという事実について、私のチームが「燃え尽きる」場合に直面しました。



大規模な支払いシステムを構築するときに、べき等性が重要なのはなぜですか？ 最も重要なのは、二重請求と二重払い戻しを回避することです。 メッセージングシステムに「少なくとも1回、ロスレス」配信がある場合、すべてのメッセージを複数回配信でき、システムはべき等性を保証する必要があると想定する必要があります。 システムをデータソースとして厳密に一貫したストレージを使用して、べき等の動作を実装するバージョン管理と楽観的ロックでこれを処理することにしました。

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

分散システムは、多くの場合、単一のノードが余裕があるよりもはるかに多くのデータを保存する必要があります。 では、適切な台数のマシンにデータセットを保存するにはどうすればよいでしょうか？ このための最も一般的な手法はシャーディングです。 データは、パーティションに割り当てられたハッシュを使用して水平方向にパーティション分割されます。 今日、多くの分散データベースは内部でシャーディングを実装していますが、それ自体が興味深いトピックであり、特にリシャーディングを検討する価値があります 。 2010年、Foursquareはエッジケースの断片化により17時間のダウンタイムを経験しました。その後、同社は問題の根本を明らかにする興味深い事後分析を共有しました。



多くの分散システムには、複数のノード間で複製されるデータまたは計算があります。 操作が調整された方法で実行されることを確認するために、操作を成功したと認識するために、特定の数のノードが同じ結果を受け取ることが必要な投票アプローチが決定されます。 このプロセスはクォーラムと呼ばれます。



Uberで大規模な支払いシステムを構築する場合、クォーラムとシャーディングが理にかなっているのはなぜですか？ これらの概念はどちらもシンプルであり、ほぼ普遍的に使用されています。 Cassandraでレプリケーションをセットアップしたときに彼らに会いました。 Cassandra（およびその他の分散システム） は、クォーラムとローカルクォーラムを使用して、クラスター間の一貫性を確保します。

俳優モデル

プログラミングの慣習（変数、インターフェイス、メソッド呼び出しなど）を説明するために使用するおなじみの語彙には、同じマシンのシステムが含まれます。 分散システムについて話すときは、他のアプローチを使用する必要があります。 そのようなシステムを記述する一般的な方法は、アクターモデルです。 このモデルでは、通信の観点からコードが表示されます。 このモデルは、たとえば組織内の人々の相互作用など、私たちがどのように想像するかの精神モデルと一致するという事実のために人気があります。 分散システムを記述するもう1つの一般的な方法は、 順次プロセスと対話する CSP です 。



アクターモデルは、互いにメッセージを送信し、それらに応答するアクターに基づいています。 各アクターは、限られた一連のことを実行できます-他のアクターの作成、他のアクターへのメッセージの送信、または次のメッセージの処理方法の決定。 いくつかの簡単なルールを使用して、アクターが「落ちた」ときに自身を回復できる複雑な分散システムをかなりよく説明できます。 このアプローチに慣れていない場合は、 Brian Stortyの記事「 10分で俳優をモデル化する」をお勧めします。 多くの言語には、アクターモデルを実装するライブラリまたはフレームワークがあります 。 たとえば、Uberでは、一部のシステムにAkkaを使用しています。



なぜアクターモデルを大規模な支払いシステムに適用するのが理にかなっていますか？ 多くのエンジニアがシステムの開発に参加しましたが、そのほとんどはすでに分散システムの操作経験があります。 「自転車」に従事し、独自の分散原則を発明する代わりに、標準の分散モデルに従うことにしました。

リアクティブアーキテクチャ

大規模な分散システムを構築するときの目標は、通常、フォールトトレラントで柔軟かつスケーラブルにすることです。 支払いシステムであっても、他の負荷の高いシステムであっても、目的を達成するためのパターンは同じです。 このようなシステムに携わる人々は、それらを構築するためのベストプラクティスを定期的に発見し、広めています。また、リアクティブアーキテクチャも同様に人気があり、広く使用されているパターンです。



リアクティブアーキテクチャに慣れるために、 ジェットマニフェスト （ ロシア語 ）を読んで、12分間のビデオリンクを見ることをお勧めします。



大規模な支払いシステムを作成しているのに、なぜリアクティブアーキテクチャが理にかなっているのですか？ 新しい支払いシステムのほとんどを構築するために使用したライブラリであるAkkaは、リアクティブアーキテクチャの影響を強く受けています。 このシステムを構築していたエンジニアの多くは、リアクティブプログラミングのベストプラクティスにすでに精通していました。 事後対応の原則-メッセージに基づいて応答性があり、フォールトトレラントで柔軟なシステムを作成する（ メッセージ駆動型 ）ので、自然にこの結論に達しました。 信頼できるモデルを作成し、開発の進行状況とその方向を評価できるモデルを作成する機能は非常に有用でした。今後、新しいシステムを作成するときにこのモデルに依存します。

おわりに

大規模で分散した重要なシステムの再構築に参加できたのは幸運でした。Uberで支払いを処理できるシステムです。 この環境で働いて、私はこれまで使用したことのない多くの分散概念に精通しました。 私は、分散システムの研究を開始したり、自分自身のために新しいことを学んだりするのに、残りの人が私のストーリーを役に立つと期待してここに集めました。



この投稿は、そのようなシステムの計画とアーキテクチャに専念しました。 伝える価値のあるさまざまな微妙な点があります-負荷の高いシステムの構築、展開、および移行について-また、信頼性の高い操作についてです。 これらすべてのトピックについては、後続の投稿で取り上げます。