2022年5月25日(水)・26日(木)に、日本最大級の AWS を学ぶイベント「AWS Summit Online 2022」がオンラインにて開催されました。
また、6月30日までは、各セッションがオンデマンドで配信されています。
アイレットのセッションでは、第一開発事業部 副事業部長の塚本 哲夫が登壇しました。
KDDI 株式会社様のスマートフォン決済サービス「au PAY」において、マネージドサービスを活用したクラウドネイティブの実装により、CX の向上と監視運用の省力化という２つの課題をどのように解決したのか、詳しく解説しましたのでポイントをまとめていきます！
2030年問題×コロナ禍
はじめに、「2030年問題」と「コロナ禍」についてです。
少子化、高齢化、人口の減少、年金問題など、さまざまな要因が積み重なり、労働人口が減少していくといった問題が2030年問題の一つと言われています。コロナ禍においても、これらの課題を解決するニーズが増してきています。
2030年問題の一つ「労働人口減少」と、コロナ禍での「人との接触を避けること」が大きな要因となり、よりキャッシュレスが求められるようになりました。
総務省の行なったデジタル活用に関する調査では、「コロナ収束後もデジタル化が進展することで利用が進むと考えられているサービスは？」という質問に7割以上の方がキャッシュレス決済と回答したという調査結果が出ており、キャッシュレス決済はコロナ収束後も大きな伸びが期待されている分野だということになります。
一方でITシステムの現場では、運用保守業務に課題を持っているお客様が多いです。
その理由には、運用保守業務が属人化していること、省力化を進めるための工数が確保しづらいこと、運用保守に関する手順が標準化されていないこと、があげられます。
今回、KDDI 株式会社様のスマートフォン決済サービス「au PAY」において、キャッシュレス決済処理における完了通知機能のサーバーレス実装において、これら課題の解決に取り組みました。
お客様の課題
本案件において、お客様は以下三つの課題を抱えていました。
完了通知の成功率を改善したい
スマホ決済の通知を送る部分の成功率に課題がありました。この通知処理の改善がお客様の最も大きな課題です。
リクエスト数が大きく増えても、成功率、応答速度に影響しない
キャッシュレス決済の利用者はますます増えていく見込みです。そのため、リクエスト数が増加してもパフォーマンスに影響しないシステムの開発が求められました。
現行システムとは別に、もう1系統の同じシステムを用意してほしい
全く同じ通知の仕組み、インターフェースでスマホ決済とは別のシステムがもう1系統必要でした。
３つのうち、まずは完了通知の成功率改善がアイレットに求められている課題でした。
提案したソリューション
PoC環境の構築
性能面に大きな課題があったため、最初に PoC（概念実証）の環境を構築しました。
開発期間は約4週間で、コアの部分をまず作り上げ、足りない部分や細かい部分は性能試験を進めながら進めていきました。
各試験を実施
PoC 環境完成後は、性能試験・負荷試験と並行して統合テストなども進めました。
期間を長く設けているのは、ゴールデンウィークの時期を跨いだためです。
リリースと本番稼働
全てのテストをクリアしたら、リリース、本番稼働です。
スマホアプリ側の改修も入るので、アイレットが担当するバックエンドはアプリ改修と並行し、先行してリリースするスケジュールとなっていました。
システム構成
システムは、かなりシンプルな構成となりました。
スマホアプリが接続する WebSocket は Amazon API Gateway の WebSocket を使っています。その背後に WebSocket の接続の管理やアプリからの情報を処理する AWS Lambda があります。
決済完了の情報を受け取る口は REST API で用意しています。
データのストレージは Amazon DynamoDB です。通知送信が完了、または決済が途中で中断された場合の不要な情報は Amazon DynamoDB の TTL の機能を使って消していきます。
通知部分は、DynamoDB Streams を AWS Lambda に繋いで処理しています。
処理の流れ
まず初めに、アプリが Amazon API Gateway のWebSocket に接続すると、Amazon API Gateway が接続ID を発行します。アプリから決済の処理ごとにユニークな決済コードが送られてくるので、これらの接続ID と決済コードをAmazon DynamoDBのテーブルに格納します。
アプリで決済が行なわれると決済処理システムへ情報が流れるので、決済処理システムから決済完了情報がREST API側に送られてきます。決済完了情報には決済コードが含まれているので、それらを抽出して決済コードと決済完了情報をAmazon DynamoDBに格納します。
Dynamo DB Streams によりテーブルのデータ追加・変更・削除のイベントがリアルタイムで通知を処理する AWS Lambda に送られます。Amazon DynamoDB のテーブルは決済コードをキーとして作成し、アプリからの格納も決済システムからの格納もアップデートアイテムでデータを格納しているので、仮にアプリのデータより決済処理システムのデータ格納が先に来た場合でも、問題なく処理できるように設計しています。
通知部分は、Dynamo DB Streams から送られるイベントの中から通知条件を満たすものがあれば通知処理を WebSocket に投げ、それ以外は捨てるという処理を AWS Lambda の中で実行しています。
性能試験
今回は artillery、serverless- artillery という OSS を利用して2パターンの性能試験を実施しました。
まず現行システムと同程度のリクエスト数の負荷をかける性能試験で、通知の成功率が改善されているかどうかを確認します。
次に、将来的な需給予測に基づいたリクエスト数の負荷をかける性能試験で、将来リクエストが増えてもシステムのパフォーマンスが落ちないこと（可用性）を確認します。
試験結果ですが、通知の成功率は目標をクリアできました。通知の処理時間の平均は500ms 以下ということで、2つの性能試験とも問題なくパスすることができました。
ポイント
完了通知の成功率を改善したい
Amazon DynamoDB のReadをしなくてもよい設計とすることで、Readにかかる時間、コストを考慮する必要がなくなりました。
また、Dynamo DB Streams の採用により、通知条件が満たされたら即通知可能となりました。耐障害性の高い構成にしたことで、エラー発生頻度も低下しました。
リクエスト数が大きく増えても、成功率、応答速度に影響しない
可用性の高いサーバーレス構成により、運用管理の負荷も軽減しました。システムが止まるような障害は基本起こらないので、その点で運用コスト、管理コストは格段に抑えることができました。
現行システムとは別に、もう1系統の同じシステムを用意してほしい
API は SAM、その他のリソースもほぼ全て AWS CloudFormation で作成し、システムのコピーを用意しました。
API の CI/CD は AWS CodePipeline で構成し、安全で自動化されたデプロイを実現しました。
成果
CX（カスタマーエクスペリエンス）の向上
完了通知の成功率を大幅に改善し、通知にかかる時間も短縮しました。
運用監視の省力化
需要増にも運用負荷を上げることなく対応が可能です。エラー発生頻度が下がることで、監視コストを削減しました。
また、AWS リソースのコード化により、インフラ管理のコストも削減しました。そして CI/CD の自動化により、機能改修の施策もやりやすくなりました。
このように運用コストを抑えつつ、高信頼性・高パフォーマンスな通知システムを実現することができました。これはお客様の要件がクラウドネイティブに非常にマッチしていたというのも1つの要因だと思います。
通知部分だけ独立して外部と密接に結合していない、1つの機能でシンプルに構成できるシステムというのは、クラウドネイティブと非常に相性が良いです。設計から開発、テスト、運用までとても良いパフォーマンスを出せるソリューションをご提供できました。
セッションでは、本事例のさらに細かいところまでお話ししています！
6/30(木)までオンデマンド配信にて視聴可能ですのでぜひチェックしてみてください！
