サーバーレスアーキテクチャとの規模での和解に関するレッスン

規模の和解は、あなたの財務記録を信頼することと、複数の当事者の間で不一致を追いかけるために夜を過ごすことの違いです。Lead Bankでは、正確性、監査能力、およびコンプライアンス義務をサポートするために、カードおよび預金プログラムのデータを収集、処理、調和するインフラストラクチャを構築します。 和解は、銀行コア、カードネットワークファイル、発行プロセッサレポート、およびフィンテックプログラムデータ全体で一貫性を検証します。 この投稿では、私たちが複数のパートの和解のために構築したAWSサーバーレスアーキテクチャ、最初に遭遇した2つの生産ボトルネック(ファイル処理制限とAmazon DynamoDBのホットスポットを書く)と、それらを緩和するために使用したパターンについて説明します。 I.規模での和解の背景と技術的制約 Banking-as-a-Service(BaaS)カードプログラムでは、FinTechは通常、銀行識別番号(BIN)のスポンサー、カードネットワークのライセンスを保有し、決済およびプログラムの監督に責任を負うFDIC保険の発行銀行を通じて動作します。プログラムには、通常、4つの役割があります:カードネットワーク(ルーティングおよびルール)、発行銀行(法的な発行者および決済相手方)、FinTechプログラムマネージャ(エンドユーザの経験と操作)、および発行プロセッサ(リアルタイムの認可およびカード口座操作)。 カード購入は、通常 ISO 8583 メッセージで送信される認証要求から始まります、カードネットワークを介して購入者と発行者の間で交換されるリアルタイムのカード取引メッセージのための共通の標準です。 実際の資金決済は、ネットワークがすべての参加者にネットワーク決済ファイルを配布する翌日に行われる。 リアルタイムの承認とバッチ決済のこの分離は、調和がファイル主導的で運用的に重要な主な理由です。 和解は、銀行コア、カードネットワークまたはプロセッサファイル、およびフィンテックプログラムデータを含む内部レコードと外部の真実源の一致性を検証するコントロールです。これらのシステムは識別子、タイミング、調整セマンティクスで異なるため、和解は本質的に複数の当事者と複数のステップです。 このポストでは、エンティティはFinTechプログラムの最終消費者であるアカウントは、エンティティとFinTechプログラムとの関係について多くのメタデータを保有するオブジェクトです。バランスを保有するオブジェクトは、さまざまな通貨で定義された値を保有するオブジェクトです。取引は、購入、支払い、または返金などの金融イベントを記述するオブジェクトです。カードは、取引を実行し、バランスを変更するために使用できるツールの1つです。 実際には、和解は4つの繰り返しのワークフローに分けられ、それぞれに別々の技術的制約があります。 バランスを構成する取引を確認する。 顧客レベルの残高の合計が、銀行のコアのオムニバス・フォー・ベネフィット・オフ(FBO)の残高に等しいことを証明する。 Match posted card activity to network or processor settlement files despite volume, format variability, and mismatched identifiers or timing across parties. ネットワークまたはプロセッサの決算ファイルに投稿されたカードのアクティビティをマッチします。 身元、カードの状態、アカウント認証の参照データを検証し、不一致または不一致な場合に財務対応を無効にする可能性があります。 多くのワークフローは、アプリケーションプログラミングインターフェイス(API)を通じて実行されているが、調和は、監査可能なスナップショットを提供し、決定的な再処理をサポートしているため、終末ファイルが依然として支配している。 Imperfect file delivery and replays: files arrive late, out of order, duplicated, or corrected, so the pipeline must be idempotent and safe to re-run. ファイルが遅く、無秩序に到着し、複製された、または修正されたので、パイプラインは再起動するのに安全でなければなりません。 識別子はきれいに並べ替えられない:同じ取引は各当事者間で異なるIDを持ち込むことができるので、一致するには複合キーと関連論理が必要になることが多い。 Adjustment-heavy settlement semantics: refunds, disputes, fees, and corrections change matching rules over time and increase write amplification. 調整重い決済セマンティクス:返金、紛争、手数料、および修正は、時間の経過とともに一致するルールを変更し、書き込み強化を増やす。 生産の2つのボトルネックが早期に現れる:長期にわたるファイル処理は短期的なコンピューティングの限界を超え、高い書き込みボリュームは、調和データストアで不均衡なアクセスパターンやホットパーティションを作り出すことができます。 この記事では、財務調和の技術的課題、特にバランスのチェックとネットワーク決済の一致、およびこれらの制約を取り巻くAWSサーバーレスパイプラインをどのように設計したかについて説明します。 The Serverless Architecture: Decoupling and Orchestration(サーバーレスアーキテクチャ) これらの制約を念頭に置いて、私たちはサーバーレスファーストアーキテクチャにコミットし、オペレーティングオーバーヘッドを最小限に抑え、可用性を最大限にし、自動スケーリングをサポートしました。このアプローチにより、小規模なチームは迅速にイテレーションし、インフラストラクチャのメンテナンスやパッチングではなく、複雑な金融ビジネス論理にエンジニアリングの努力を集中させ、開発者やインフラストラクチャのコストプロフィールを大幅に削減しました。 そして 記事をシンプルで集中的に保つために、我々は財務ファイルにのみ焦点を当てます。 Amazon Simple Storage Service (Amazon S3), Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS), Amazon DynamoDB, AWS Lambda, Amazon Elastic Container Service (Amazon ECS), AWS Step Functions A. Ingestion and Event Routing (Amazon S3 および Amazon EventBridge) このプロセスは、ファイルの1つ(トランザクション、バランス、またはネットワーク決済)が、S3 バケットと同期されるセキュアファイル転送プロトコル (SFTP) フォルダに落とされるときに始まります。当社の設計では、直接の S3 通知を使用する代わりに EventBridge を通じて S3 オブジェクトによって作成されたイベントをルーティングしました。 持続可能な処理キュー(Amazon SQS) 当社の設計では、EventBridge ルールは、持続可能なバッファリングを提供し、処理からの摂取を切り離すために SQS 標準列をターゲットにします。 Throttling/Load Leveling: 3 つの巨大なファイルが同時に到着すると、列が負荷を吸収し、ダウンストリームのコンピューティングサービスがメッセージを圧倒されるのではなく、安定した持続可能な速度で引っ張ることを保証します。 耐久性: メッセージは、少なくとも1回の配信を保証するために、SQSで処理されるまで続きます。 Dead Letter Queue (DLQ): 各 SQS 列が DLQ で構成されます. 処理 Lambda が繰り返し失敗する場合(例えば、最大リリース数が 5 を超えると)、メッセージはマニュアル検証のために DLQ に移動し、無口に取引が失われないようにします。 C. Compute Layer (AWS Lambda および Amazon ECS) 当社のコンピューティングインフラストラクチャは、コストと期間の両方を最適化するために戦略的に分割されています。 AWS Lambda: メッセージの解析やステップ機能のパラレルマップの起動などの軽量、爆発的、オーケストラ作業を処理します。 AWS ECS Fargate: 高いメモリを必要とするまたは 15 分間の Lambda タイムアウトを超える調和作業(セクション III で詳細に述べた一般的なボトルネック)のために予約されています。 Workflow Orchestration(AWSステップ機能) AWS Step Functions は、個々の計算ステップを調整するためにサーバーレスオーケストラに適しているため、長期にわたる、しばしば複数の日間のワークフローである。 この選択の理由は、建築的必要性に根ざしています: Managed State and Durability: Reconciliation involves dozens of sequential and parallel steps (splitting, normalizing, matching, aggregating). Step Functions inherently manage state between steps when a downstream service fails (e.g., a Lambda error). The State Machine pauses, tracks the exact point of failure, and allows the workflow to be resumed or restarted from that point, which is critical for auditability and recovery. ステップ機能は、下流サービスが失敗したときにステップ間の状態を本質的に管理します。 Massive Parallelism via Map State: 使用例に応じて、パラレル状態を使用して特定のタスクを並行して実行し、同じタスクを異なる入力で繰り返したいときにも同様に、Map state を使用しました。 Visual Debugging and Auditability: コンプライアンスおよび操作のために、ワークフロー全体を視覚化する能力は貴重です。Step Functionsは、その入力、出力、および失敗理由を含む各ステップのグラフィックビューを提供します。 E. Persistence Layer (Amazon DynamoDB) 私たちは、巨大なカードプログラムに不可欠な特徴のために、不変な取引およびバランスの記録を格納するためのコアデータベースとしてDynamoDBを選択しました。 高ボリューム、低遅延: DynamoDB は、金融ワークフローに必要な高ボリュームで予測可能な、1 桁のミリ秒遅延を提供するように設計されています。 サーバーレスおよびマネージド:完全に管理された性質を活用することで、従来のリレーショナルデータベース(MySQL/Postgres)のプロビジョニング、パッチング、およびシェアリングの課題を排除し、パーティションキーの設計などのアプリケーションレベルの課題に完全に焦点を当てることができます。 ストリーム統合:DynamoDB ストリームは重要であり、ダウンストリームのコンプライアンス、分析、およびデータストレージ (Snowflake) システムを引き起こすほぼリアルタイムの変更のストリームを提供します。 私たちのデビットカードフローの簡素化バージョンは、このように見えました。 上半期には、発行プロセッサが、S3に同期されたネットワークファイルを落とします。EventBridge ルールは、新しい S3 イベントに耳を傾け、発行 SQS の列にそれらを送信します。Initiator Lambda は、この列を継続的に調査し、ネットワーク決済ステップ機能を起動し、ネットワーク決済ファイルを解析し、ネットワーク決済 DynamoDB テーブルに解析されたデータを保存します。 下半分では、FinTech フローは、FinTech パートナーが取引およびバランスのファイルを落とすときに始まります. This triggers an event routed through the SQS queue to the Initiator Lambda, which then starts a separate Step Function that validates and reconciles the files against the network settlement data. このプロセスは、ネットワークの和解と呼ばれます. 右側には、FinTechバランスファイルとFBOアカウントの決済額を調和させるFBO調和機能があり、ネットワーク、FinTech、銀行レコードのエンド・トゥー・エンドの正確性をサポートします。 The Scaling Battle: Overcoming Serverless Limits(サーバーレスの限界を克服する) このアーキテクチャは最初はうまく機能しましたが、私たちのボリュームが伸びるにつれて、私たちは2つの重要なボトルボリュームに直面しました:コンピューティングの期間とデータベースのパーティション化、これは私たちのアプローチを進化させました。 A. コンピュータの最適化:Lambda-to-ECS 移行 最速のボトルネックはLambdaの15分間の実行制限であったが、ファイル分割が役に立った一方で、複雑な大小単位の和解論理(たとえば、広い列、固定幅のファイルの20,000のレコード)はまだ時々このウィンドウを超えていた。 私たちのソリューションは、再設計ではなく、単純な建築の切り替えでした。 Unified Codebase: Weined a single core reconciliation worker, a containerized application written in Go, which handled file parsing and processing. Go で書かれたコンテナ化されたアプリケーション。 Dynamic Execution: このコンテナイメージは、Lambda(高速でエフェメラルな実行)とECS Fargate(長時間実行、メモリ集中の作業)の両方に展開しました。 Step Function Choice: The Step Function uses a Choice state early in the process. If the file size is below a certain threshold (e.g., 1GB), it targets the Amazon Lambda function. If the file is large, the Choice state invokes the Step Functions integration for ECS (RunTask) to start a dedicated Fargate task. Step Function Choice: Step Function はプロセスの初めに選択状態を使用します。 このアプローチにより、Lambda のコスト効率とスピードは小さいファイルの 90% で、Fargate のコンピューティングヘッドルームは、大規模で遅いトランザクションとバランスのファイルの 10% で達成されました。 B. High-Throughput Writes 用の DynamoDB マスター DynamoDB は、トランザクションストレージのための高ボリューム、低遅延要件を有するデータベースのための優れた選択です。しかし、そのスケーラビリティは、パーティション間で I/O を均一に配布することを前提としています。 Throttling は、1 つのパーティション キーがその制限を超えるときに発生します(通常、1 秒あたり 1,000 Write Capacity Units (WCU) または 3,000 Read Capacity Units (RCU))。 パーティションキー ProgramID#FileDate (例えば、PROGX#20250101) このデザインは、一日で大規模なプログラムのすべてのトランザクションがランクインしたため失敗しました。 WCUの限界を超え、飲み込む。 特定の日付の特定のプログラムのすべてのトランザクションを見つける 同じ分割 The Global Secondary Index (GSI) Backpressure Lesson: We initially attempted to solve this by moving the high-cardinality primary key to a GSI and querying the GSI instead. However, this provided no relief. Because the GSI receives its data stream from the main table, if the primary table's partition is already throttled, the GSI's ingestion queue will experience GSI backpressure, ultimately limiting the writing throughput of the entire table. We realized the core partition key issue had to be solved at the root table level. GSIは最初に、この問題を解決しようとしました。 最適化されたキーデザイン: Partition Key Sharding: 私たちの修正は、私たちの最大のボリュームの顧客のために書くシャードを導入することでした: PK Sharding: Partition key: ProgramID#FileDate#ShardN に計算された shard 番号を付加しました。 Sharding Logic: We used a lightweight hashing algorithm (e.g., modulo) on the TransactionID to assign it to a shard (e.g., TransactionID % 10 results in a shard number between 0 and 9). 結果:これは1個ではなく10個の物理パーティションに書き込み負荷を配布し、すぐにホットパーティションの問題を軽減し、10倍の速さでデータを摂取することができます。 4.Actionable Lessons Learned このセクションでは、独自の和解パイプラインに適用できるパターンをまとめ、当社の実装の例を参照します。 A.システムデザインのレッスン 以下は、リトラクション、不完全な入力、複数の外部システムを処理するための和解パイプラインを構築する際に適用できる3つのシステム設計レッスンです。 Make retries safe by default (idempotency is the baseline): In an event-driven pipeline, retries are expected, so you should design each step to be safely repeatable. For our use case, we had to pass an idempotency key (for example, a TransactionID or MessageID) through the workflow and use it to guard every side-effecting operation. In practice, that means: Workflow steps: each state transition is protected with conditional writes (for example, in DynamoDB) so the same message cannot advance or mutate state twice. Core banking transactions: postings, transfers, and ledger-affecting actions are executed with explicit dedupe semantics (same idempotency key → same outcome), so a retry results in a no-op or a deterministic “already processed” response rather than a duplicate movement of funds. Webhooks and outbound notifications: These are delivered at least once, so each message includes a stable, recipient-facing idempotency key (event ID) and we maintain an internal delivery ledger (attempts, acknowledgements, and final state). Recipients can safely dedupe replays, and our retries won’t trigger duplicate downstream actions. Always Use a Dead Letter Queue (DLQ): and a redrive policy so that malformed messages are quarantined instead of endlessly retrying and clogging the queue. Configure a SQS DLQ Do not let a service be the only source of truth for its own correctness.: Reconciliation is cross-system by definition, so build checks that validate invariants from the outside. For example, comparing transactions sent by the program against the network and their FBO was very important. SQS DLQの設定 B.Operational Excellenceレッスン これらの操作レッスンは、失敗を可視化し、操作可能にし、チームとパートナーの両方にとって容易に調査できるようにすることによって、検出する時間を短縮し、解決する時間を短縮することです。 内部観察性に焦点を当てた:観察性の文化が継続的なデバッグよりも優れていることを発見しました. 私たちの焦点は、エラーに対応することから、それらを予防することに移り、ボード全体で運用規律を必要としました.このための鍵は、必要なサービスレベルの目標(SLO)を設定することによって、早期にホットスポットを識別することでした(SQS列の深さやDynamoDBのホットリングなどのメトリクスの厳格な警告と限界を設定すること) 外部の可視性に焦点を当てる:お客様は、明確な、自己サービスエラーメッセージとガイドラインを返すことで、顧客に和解の失敗を可能にするべきです。 ツールアップに投資する:調査ツールアップを早期に構築して、ソースファイル、処理実行、および結果として記録を掘り起こすことなく書く不一致を追跡できます。 フィードバックを得るためにスピードに焦点を当てる: 迅速なフィードバックループのために最適化するべきです. サーバーレスで迅速なスタートアップと低い開発コストを有効にしました. このイベント駆動型の和解システムを実行した最初の月の後、クラウドコンピューティングの総請求額はチームのランチ請求額よりも小さい。 C.インターフェイスデザイン:ファイル vs. API 一般的なエラーは、APIがビジネスプロセスにより適した場合にファイルベースのインターフェイスにデフォルト化することでした。 問題のための正しいインターフェイスを使用する: ここに正しい答えはありません; 問題を解決するために正しい抽象を検討する必要があります. 実際のバッチ操作のためにファイルを使用しました. 最終日のスナップショットが要件である場合にのみ (例えば、ネットワーク決済)。 次に、リアルタイムのフィードバックや小規模で分離されたデータ転送が必要な場合に特に、他のすべてのものにAPIを使用しました. 単純なAPI呼び出しよりもはるかに複雑なことを証明したため、ファイルベースのアップロードからHTTP APIにいくつかの内部インターフェイスを書き直す必要がありました. ファイル スケジュールをバージョン 契約のように扱う: ファイル スケジュールをバージョン 契約のように扱うべきです、小さな変更がパッシングを破り、調和結果を静かに歪めることができます。 結論 AWS でスケールアップする和解システムの構築は、サーバーレスコンポーネントを選択するのではなく、故障、再生、および調査のための設計に関するものである。当社の実装において、AWS サーバーレスサービスは、オーケストレーションと持続可能な状態のための強固な基盤を提供しました。