既存のweb向け課金システムをそのままに、サーガパターンでのアプリ内課金システム構築

既存のWeb向け課⾦システムをそのままに、サーガパターンでのアプリ内課⾦システム構築朝⽇新聞社朝デジ事業センターカスタマーエクスペリエンス部アーキテクト岡本樹

⾃⼰紹介 Copyright © The Asahi Shimbun Company. All rights reserved.
2 Okamoto Tatsuki 岡本樹 2018年に朝⽇新聞社に新卒⼊社以来、朝⽇新聞デジタルの開発にアプリケーションエンジニア・アーキテクトとして従事好きなサービス︓Amazon Kinesis Data Streams 関⼼事︓ソフトウェアアーキテクチャオブザーバビリティ

我々の主たるサービス︓朝⽇新聞デジタル 4 Copyright © The Asahi Shimbun Company. All rights
reserved. •2023年3月9日にAndroid/iOSでアプリ内課金を実装こちらのアプリ

アジェンダ 5 Copyright © The Asahi Shimbun Company. All rights
reserved. • アプリ内課⾦を実装するにあたっての課題 1.異なるデータソースで整合性を担保 • サーガパターンによる分散トランザクション 2.サーバ間通知ペイロードの保存 • サーバ間通知のデータロスト対策 3.仕様の異なるサーバ間通知 • 仕様の異なるサーバ間通知のリクエスト検証 • まとめ

なぜアプリ内課⾦をやるのか︖ 6 Copyright © The Asahi Shimbun Company. All rights
reserved. 従来Web側にしか導線がない状況

朝⽇新聞デジタルでの実現 7 Copyright © The Asahi Shimbun Company. All rights
reserved. Web購読導線の課題 •課⾦完了までの画⾯数が多く途中離脱率が⾼い •課⾦システムの修正が難しく、画⾯を減らすこと⾃体困難アプリ内課⾦で実現したいこと •既存の課⾦システムに⼿を⼊れずに、モバイルアプリからの購読操作を可能にしたい

なぜアプリ内課⾦をやるのか︖ 8 Copyright © The Asahi Shimbun Company. All rights
reserved. 変更コスト︓⼤

課題の背景 10 Copyright © The Asahi Shimbun Company. All rights
reserved. •課⾦システムの制約 •変更コストが⾼く新規テーブル・データベースの追加が不可能 •朝⽇IDという独⾃のIDでしかユーザを表現不可能そのためモバイルアプリ⽤ファサードで、App Store/Google Play のIDを朝⽇IDの仕様に合わせたり、購読の状態を永続化したい課⾦システムとファサード間という異なるデータソースで整合性を担保したい

reserved. •課⾦システムの制約 •変更コストが⾼く新規テーブル・データベースの追加が不可能アプリ内課⾦の全ての購読操作はサーバ間通知で送信されるので、その蓄積がしたいが、課⾦システム側での蓄積が難しいそのためモバイルアプリ⽤ファサードで、サーバ間通知ペイロードは確実に保存したい

reserved. •スコープと期限 •ビジネス上、3⽉リリースは厳守する必要 •ビジネス上、Android/iOSでの同時リリースをする必要期限とスコープに余裕がない App Store/Google Playの仕様の異なるサーバ間通知について処理を簡略化したい

アプリ内課⾦を実現するにあたっての課題 13 Copyright © The Asahi Shimbun Company. All rights
reserved. 異なるデータソースで整合性を担保したいサーバ間通知ペイロードを確実に保存したい仕様の異なるサーバ間通知

異なるデータソースで整合性を担保したい 14 Copyright © The Asahi Shimbun Company. All rights
reserved. •課題の背景課⾦システムの変更コストが⾼く新規テーブル・データベースの追加が不可能 •やりたいこと課⾦システムでの購読の開始・更新・解除といった操作のため、 App Store/Google Play上で表現されるIDを朝⽇IDとして取り扱いたい朝デジ内で朝⽇ID以外の認証・認可の仕組みがない

異なるデータソースで整合性を担保したい 15 Copyright © The Asahi Shimbun Company. All rights
reserved. そのためApp Store/Google Playと課⾦システムの間のシステムで、 ID仕様を課⾦システムに合わせる必要がある

どのように整合性を担保するか 16 Copyright © The Asahi Shimbun Company. All rights
reserved. モバイルアプリ⽤ファサードのデータベースと課⾦システムの間で、各プラットフォームのIDを朝⽇IDの仕様に合わせて、購読状態をアトミックに永続化したいサーガパターンによる分散トランザクションを試みる

サーガパターンによる分散トランザクションサーガパターン1 ローカルトランザクションの順次処理で、1つでも処理が失敗した場合は⼀連の処理に対して補償トランザクションを実⾏してサーガ中の変更を以前の状態に戻す 17 [1] Neal Ford, Mark
Richards, Pramod Sadalage, Zhamak Dehghani 著, 島⽥浩⼆訳, ソフトウェアアーキテクチャ・ハードパーツ,オライリージャパン, 2022 Copyright © The Asahi Shimbun Company. All rights reserved.

18 Copyright © The Asahi Shimbun Company. All rights reserved.
補償トランザクション成功後、最初の購読開始処理はロールバックされる

サーガパターンによる分散トランザクション 19 Copyright © The Asahi Shimbun Company. All rights
reserved. 正常系 1.リクエストを受け取ったら 2.App Store/Google Playに検証リクエストを送って 3.成功したら朝⽇IDプラットフォームに購読操作リクエストして 4.成功したらその結果を元に購読情報を保存して 5.基づくレスポンスをユーザ/サーバ間通知に返却する OK😁

reserved. 異常系 1.リクエストを受け取ったら 2.App Store/Google Playに検証リクエストを送って 3.成功したら朝⽇IDプラットフォームに購読操作リクエストして 4.成功したらその結果を元に購読情報を保存して 5.基づくレスポンスをユーザ/サーバ間通知に返却するデータソースごとにロールバックしたい😢 ここでエラーすると課⾦システムとモバイルアプリ側ファサードで整合性がない状態に

reserved. 分散トランザクションの実施

reserved. 同期的に呼び出しオーケストレータ ① ② ③

reserved. 課⾦システムが停⽌しても、ワークフロー全体が停⽌してしまう課⾦システムが停⽌しても、ファサードのDBが停⽌してもワークフロー全体が停⽌してしまう

reserved. •モノリシックなシステムを模倣したトランザクション調整が可能 •全てのコンポーネントについてアトミック性を考慮するので、全て成功するか、全てロールバックされるかとなり、可⽤性が低くなる

reserved. 異なるデータソースで整合性を担保したいサーバ間通知ペイロードを確実に保存したい仕様の異なるサーバ間通知

サーバ間通知ペイロードを確実に保存したい 26 Copyright © The Asahi Shimbun Company. All rights
reserved. • 課題の背景課⾦システムの制約でユーザ問い合わせ対応に必要な情報も、モバイルアプリ⽤ファサードで担保しなければならない • やりたいこと全ての購読イベントはサーバ間通知で送られるその上解約や返⾦といったイベントは各プラットフォームからのみ送られるので、問い合わせに対応できるようデータ⽋落を考慮する必要があるそのためサーバ間通知は重要なリクエストで、確実に保存する必要がある

サーバ間通知のデータロスト対策 27 Copyright © The Asahi Shimbun Company. All rights
reserved. •同期的にAmazon S3に保存したくない •保存失敗を理由にエラーさせるのは機会損失になりかねない •サーバ間通知の受信後、Amazon SQSにキューイング •SQSからは⾮同期にログ保存を⾏い、リトライやDLQを処理から分離する

サーバ間通知のデータロスト対策 28 Copyright © The Asahi Shimbun Company. All rights
reserved.

AWS LambdaからペイロードをSQSにキューイング

SQSから⾮同期にS3にペイロードを保存エラーしたイベントはDLQへ

SQSのイベントサイズが256KBなのでペイロードの仕様変更に注意が必要

reserved. 異なるデータソースで整合性を担保したいペイロードを確実に保存したい仕様の異なるサーバ間通知

仕様の異なるサーバ間通知 34 Copyright © The Asahi Shimbun Company. All rights
reserved. Google Playはヘッダに署名検証⽤JWTがあるため検証処理が⾏いやすい⼀⽅、 App Storeは独⾃の仕組み署名検証処理の実装に時間をかけたくない App Store/Google Playの仕様変更に逐次対応する必要があるので保守性も担保したい

仕様の異なるサーバ間通知のリクエスト検証 35 Copyright © The Asahi Shimbun Company. All rights
reserved. 腐敗防⽌層をプラットフォームの数だけ分離 •App Store側 •独⾃の仕組みなので頑張ってLambdaに検証処理を実装しました💪 •Google Play側 •Amazon API Gatewayを採⽤ •HTTP APIを選択することで、署名検証をAPI Gatewayで実施、実装コストの削減に成功した

まとめ︓アプリ内課⾦を実装するにあたっての課題 37 Copyright © The Asahi Shimbun Company. All rights
reserved. 異なるデータソースで整合性を担保したいサーバ間通知ペイロードを確実に保存したい仕様の異なるサーバ間通知サーガパターンによる分散トランザクション SQS + Lambda + S3で非同期に保存 API Gatewayでの署名検証

We are hiring 41 Copyright © The Asahi Shimbun Company.
All rights reserved. 朝日新聞デジタルは「みえるを広げる。みらいを照らす。」をミッションに、世の中の出来事を伝えるだけではなく「多様性」、その⽣き⽅や考え⽅の“違い”を⼤切にして、多くの⼈へ伝えていきます。一緒に最高のメディアを作りませんか？採用情報：https://www.asahishimbun-saiyou.com/techmedia/ 採⽤情報QRコード

既存のweb向け課金システムをそのままに、サーガパターンでのアプリ内課金システム構築

既存のweb向け課金システムをそのままに、サーガパターンでのアプリ内課金システム構築

Other Decks in Technology

Featured

Transcript