AWSの決済機能構築方法！サーバーレスエキスパートがベストプラクティスを考えてみた😎

こんにちは！

今回は AWS の決済機能について、ベストプラクティスを交えて解説していきたいと思います！よろしくお願いいたします！

想定する読者

• AWS の決済構築に興味があるヒト
• サーバーレスを用いた決済基盤を作りたいヒト
• サーバーレス技術に対して興味があるヒト

はじめに

AWS で決済基盤をサーバーレスで構築する場合、主に利用する AWS サービスとしては、以下のようなものがあげられます。

• AWS Lambda
• Amazon SQS
• Amazon EventBridge

主にこれらを利用して、決済基盤を構築するアプローチをご紹介していきたいと思いいます。

非同期処理の決済

非同期処理の決済の場合は、EventBridge をトリガーに決済処理を行います。それに伴い Lambda を実行し、DynamoDB と SQS に情報を連携、そのあとに別の Lambda で SQS をポーリングして決済処理を行います。

こちらが非同期の一連の流れとなります。

このアーキテクチャのポイントは SQS です。これを利用することで、注文情報の処理を疎結合な状態で行うことが可能です。

この際、何らかの原因で SQS が処理に失敗したとしても、デッドレターキューとしてキューは保持されるため、すべての注文情報について漏れなく対処することができます。決済処理は完全性が求められるかと思いますので、デッドレターキューの機能がある SQS は、非同期処理の選択肢としてはベターとなります。

また多重ログインを禁止するために SQS では FIFO キューを利用し、先入れ先出しを行えるようにします。

全体の動きとしては EventBridge にスケジュールを設定し、指定した時間に実行、SQS に溜まったキューは Lambda でポーリングし処理を行います。DynamoDB は決済情報の保存などに利用します。

そして Lambda のロジックには重複を防ぐため、DynamoDB にフラグを立てる処理を実装しておきます。なおこの処理は、Step Functions を利用して実装することも可能です。

同期処理の決済

同期処理の決済では、Stripe API を利用した例をあげて決済基盤のアーキテクチャをみていきます。

上記のアーキテクチャでは、Stripe API からの決済イベントを API Gateway を通して Lambda で処理します。処理が成功もしくは失敗した場合などには SNS でユーザーに通知を行うようにすることも可能です。

DynamoDB は、非同期処理のときと同じように、決済処理の重複を防ぐためフラグを立てたり、決済情報などを保存したりするのに使います。

また Lambda を利用することで、大量のリクエストがあった場合でも容易にスケーリングを行うことができますので、その点について悩む必要がないというのもメリットです。

こちらのアーキテクチャは同期処理の決済において定番の構成になりますので、Paypal などの決済 API を利用した場合でも、同じアーキテクチャで決済基盤を構築することができます。

関連記事

• これから始めるAWS SQS！メッセージキューと上手に付き合うワンランク上の実装を解説😎
• SNS のデッドレターキューと SQS のデッドレターキューについて解説します😎

まとめ

AWS のサーバーレスサービスは、スケーラビリティの問題やインフラ管理についての悩みを解消してくれます。決済基盤を構築するうえでも、とても頼れる存在ではないかと思いますので、積極的に取り入れていきましょう！

このブログでは、AWS のサーバーレスサービスについての記事をどんどん公開しておりますので、ご興味のある方はほかの記事もご覧いただければと思います。

AWS に関するサーバーレスな設計は、お気軽にお問い合わせください。