Amazon Web Services ブログ

Amazon Finance Technologies が Amazon DynamoDB を使用してイベントドリブンでスケーラブルな送金サービスを構築した方法

Amazon Finance Technologies（FinTech）の payment transmission（支払い送信）チームは、請求書の作成から支払が行われるまでのプロセスにおける、Accounts Payable（AP）チームの製品を管理しています。彼らの一連のサービスは、請求書の作成から決済が終わるまで、受け取り側が確実に支払いを受け取れるよう、支払いプロセスの処理を行います。 Amazon Business は、デジタル作家、アプリケーション開発者、小売業者、電力会社、税理士法人など、非常に多様な支払先に送金を行っています。2022年、FinTech の payment transmission チームは、アメリカで使用されている送金ネットワークの一つである ACH や電信送金などの様々な送金オプションを通じて、150カ国、60通貨以上で4,200万件以上の送金をサポートしました。

このブログでは、Amazon DynamoDB をあらゆるスケールでミリ秒のレイテンシを提供するキーバリュー及びドキュメントデータベースとして使用して、拡張可能で復元力が高いイベント駆動型の送金通知サービスを構築した方法を紹介します。

要件

Amazon での送金の過程にはいくつかのステップがあります。送金先名や金額などの詳細が記載された請求書の作成から始まり、送金先の銀行パートナーを特定し、最終的に金額、国、ビジネスタイプに応じて最適な送金方法を選択します。必要な情報が集まると、送金の指示が銀行パートナーに送信されます。送金が行われたことを銀行パートナーが確認した後、Amazon は送金完了の通知を顧客に送ります。送金完了時にタイムリーに顧客に通知することで、顧客は支払い状況を把握し、カスタマーサービスへの問い合わせを最小限に抑えることができます。決済される量は日によって、また地域によって異なるため、送金完了の通知を正確に行うためには、必要に応じてサービスの拡張ができることが重要でした。

私たちは以下の項目を主要要件をして設定しました。

  • シームレスなスケーラビリティ
  • 確実な処理と送金通知
  • 効率的なエラー処理
  • メンテナンスの容易さ

スケーリング問題の解決策

堅牢な送金サービスを構築するために、私たちは AWS のコンピューティングとデータベースのテクノロジーを使用しました。AWS Lambda はサーバーレスでイベント駆動型のコンピューティングサービスで、DynamoDB とネイティブに統合されています。この記事では、データベースを選択する基準と、その機能をどのように使ってシステムを設計したかに焦点を当てて紹介します。

使用するデータベースサービスを決定するために、私たちは2つの主要な要件を特定しました。まず一つ目は、大量の支払いを処理し、お客様へのタイムリーな通知を維持するために、シームレスにスケールできるデータベースであることです。そして二つ目は、送金先のタイプ、トランザクションのタイプ、国など、支払いに影響を与えるさまざまな要因を考慮したスキーマの柔軟性があることです。急速に変化する財務状況の中で、決められたスキーマを維持することは難しいため、すべてのデータ要素を前もって定義しなければならないような、厳格なスキーマでのシステム構築はしたくありませんでした。こうした点を考慮し、私たちは DynamoDB を選択しました。

DynamoDB は、ハイパフォーマンスなアプリケーションを大規模に実行するために設計された、フルマネージド、サーバーレスの key-value NoSQL データベースです。 DynamoDB は、ビルトインのセキュリティ、継続的なバックアップ、自動化されたマルチリージョンでのレプリケーション、インメモリキャッシング、データのインポートとエクスポートツールを提供します。これらの機能により、ビジネスの差別化には繋がらないデータベースの管理や拡張といった作業は無くなり、私たちは顧客向けの送金アプリケーションの構築に集中することができました。 DynamoDB のオンデマンドキャパシティモードは、キャパシティ予測無しで毎秒何千ものリクエストに対応します。また、使用量に応じた従量課金により、最適なパフォーマンスを維持しながらコストを低く抑えることも可能です。

お客様の支払いを可能にするための処理に必要な情報は、銀行パートナーに送信されます。銀行パートナーが送金処理に成功すると、確認メッセージが送信されます。これらのメッセージには、請求書や支払明細などの追加情報が含まれます。これら2つの処理は異なるシステムで動作するため、2つの異なるサービスに分離し、それぞれが同じ再利用可能なパターン（後ほど説明）に従いながら独自のタスクを実行できるようにしました。処理を分離することで、 FinTech はソリューションをシンプルに保つことができ、また、サービスごとに拡張することができます。

私たちのアプリケーションでは、以下の2つのサービスを使用しています：

エンリッチメント・サービス – このサービスは、送金成功時に銀行パートナーからの通知を受信し、詳細情報を追加する役割を果たします。
通知サービス – このサービスは、詳細情報が追加されたメッセージを受信し、通知を顧客に送信します。

エンリッチメント・サービス

次の図は、エンリッチメント・サービスの流れです。

銀行パートナーからの通知は、Amazon Simple Queue Service（Amazon SQS）の送金イベントキューで受信されます。これらのメッセージは Lambda 関数によって処理され、 DynamoDB のテーブルに格納されます。 DynamoDB の挿入または更新操作は、 Amazon DynamoDB Streams（テーブルアイテムの変更に関する情報の順序付けられたフロー）を介して変更データキャプチャ（ CDC ）イベントのトリガーとなります。 Lambda を使用して特定の CDC イベントを処理し、 AWS Step Functions のワークフローをトリガーします。このワークフローは必要な検証、エンリッチメント、変換を実行します。加工されたメッセージは最終的に Amazon Simple Notification Service ( Amazon SNS ) のトピックにパブリッシュされ、また、DynamoDB テーブルを更新します。この SNS トピックは、通知サービスから、顧客に通知を行うために使用されます。

次の図は、テーブルの設計を示しています。


新しいレコードは、イベントのアトミック性と高いカーディナリティのため、request ID を主キー、ソートキーは無しで DynamoDB に挿入されます。また、メッセージごとに Step Functions 固有の実行 ARN 名を生成して保存します。事前に ARN を生成することには、主に2つの利点があります。1つ目は、Strep Fcuntions イベントのアップデートを取得する際、ステータスを更新する DynamoDB のレコードを正しく識別するために ARN を参照します。2つ目は、 Step Functions は同じ ARN での実行を許可しないため、偶発的な再実行や重複処理を最小限に抑えることができます。これは arn:aws:states:<region>:<account>:execution:<state machine name>:<Execution Name> という形式です。各メッセージに対してこの一意な実行名を生成するために、request ID と他の値にほとんど静的な値を使用します。Sweeper や通知ワークフローなどの複数のプロセスが、ステータスを更新するために同じレコードにアクセスする可能性があります。楽観的ロックを有効にするために versionId 属性を使用し、バージョン番号を効果的に管理するために DynamoDBVersionAttribute 注釈で便利なソリューションを提供する AWS SDK for DynamoDB for Java を使用しています。

FinTech の要件の1つはエラー処理能力の向上であったため、Step Functions のワークフローによってトリガーされる依存サービスの停止など、いくつかの理由によって引き起こされるワークフローの失敗を処理することを目指しました。これを実現するために、テーブル上のグローバルセカンダリインデックス ( GSI ) に依存する、sweeper パターンと呼ばれる、FinTech の内部設計パターンを導入しました。

送金テーブルについては、対応するステータスにあるジョブを識別するために、3つの GSI キー（ Retry Job GSI、 Failed Job GSI、Running Job GSI ）を作成しました。ワークフローが失敗するたびに、エンリッチメント・サービスは対応するテーブル・ アイテムを更新し、request ID と同じ値で Retry Job 属性を修正します。Sweeper という名前の Lambda 関数は、失敗したメッセージを再実行するために呼び出され、再実行のしきい値に達していない失敗したアイテムを見つけるために、 GSI キーの Retry Job 属性をスキャンします。GSI はスパースなので、それらの属性に値を持つアイテムだけを抽出します。失敗した項目だけが GSI キーの Retry Job 属性に request ID を持ち、正常に処理されたレコードは表示されません。アイテムを特定した後、Lambda 関数は Step Functions の実行 ARN を生成し、ジョブを再度トリガーします。このアプローチは失敗を最小化します。また、この関数は失敗したワークフローを特定するために数時間ごとに実行されるようにスケジュールされているため、GSI をスキャンすることはこのケースでは実現可能です。

通知サービス

通知サービスは、エンリッチメント・サービスと同様の設計とテーブルスキーマを使用し、出力されたメッセージは同様のパターンに従って消費・処理され、送金通知を顧客に送信します。このサービスには、ユーザー特性、目的、または地域に基づいて、正しい通知テンプレートが使用されることを確認するための追加ルールがあります。

次の図は、通知サービスの流れです。

まとめ

Amazon FinTech チームは、DynamoDB データベースを利用して、スケーラブルで信頼性が高く、イベント駆動型の送金サービスを構築しました。彼らは、DynamoDB Streams とスパースな GSI を使ってソリューションをシンプルにし、Sweeper パターン設計を実装しました。さらに、DynamoDB Streams、GSI、スキーマの柔軟性など、DynamoDB ですぐに利用できる機能を使うことで、FinTech チームは、検討した他の選択肢と比較して開発工数を40%削減し、送金および通知サービスを早期に開始することができました。

DynamoDB を使い始めるための詳細については、ドキュメントを参照してください。DynamoDB を使ったイベントドリブンパターンをより深く知りたい方は、Serverless Land をご覧ください。

作者情報

Balaji Kumar GopalakrishnanBalajikumar Gopalakrishnan は Amazon Finance Technology のプリンシパルエンジニア。2013年から Amazon に勤務し、Amazon の顧客の生活に直接影響を与えるテクノロジーを通じて現実世界の課題を解決している。仕事以外の趣味は、ハイキング、絵画、家族と過ごすこと。映画好きでもある！

Picture of Author Pradeep MisraPradeep Misra は AWS のスペシャリスト・ソリューション・アーキテクト。最新の分散アナリティクスと AI/ML ソリューションのアーキテクトと設計に Amazon 全体で取り組んでいる。データ、アナリティクス、AI/ML を用いて顧客の課題を解決することに情熱を注いでいる。仕事以外では、新しい場所を探検したり、新しい料理に挑戦したり、家族とボードゲームをしたりするのが好き。また、娘たちと科学実験をするのも大好きだ。

 

（本記事は 2023/08/22に投稿された How Amazon Finance Technologies built an event-driven and scalable remittance service using Amazon DynamoDB を翻訳したものです。翻訳は Solutions Architect の嶋田朱里が担当しました。）