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

AWS Dev Day 2023 Tokyo
E-4-2
https://aws.amazon.com/jp/events/devday/japan/

Transcript

1. 既存のWeb向け課⾦システムをそのままに、 サーガパターンでのアプリ内課⾦システム構築 朝⽇新聞社 朝デジ事業センター カスタマーエクスペリエンス部 アーキテクト 岡本 樹
2. ⾃⼰紹介 Copyright © The Asahi Shimbun Company. All rights reserved. 2 Okamoto Tatsuki 岡本 樹 2018年に朝⽇新聞社に新卒⼊社 以来、朝⽇新聞デジタルの開発にアプリケーション エンジニア・アーキテクトとして従事 好きなサービス︓Amazon Kinesis Data Streams 関⼼事︓ソフトウェアアーキテクチャ オブザーバビリティ
3. 我々の主たるサービス︓朝⽇新聞デジタル Web App（Android/iOS） •朝⽇新聞社が提供するニュースサービス •Webサイトとモバイルアプリの両⽅を提供 •アプリはAndroid/iOSに対応 3 Copyright © The Asahi Shimbun Company. All rights reserved.
4. 我々の主たるサービス︓朝⽇新聞デジタル 4 Copyright © The Asahi Shimbun Company. All rights reserved. •2023年3月9日にAndroid/iOSでアプリ内課金を実装 こちらのアプリ
5. アジェンダ 5 Copyright © The Asahi Shimbun Company. All rights reserved. • アプリ内課⾦を実装するにあたっての課題 1.異なるデータソースで整合性を担保 • サーガパターンによる分散トランザクション 2.サーバ間通知ペイロードの保存 • サーバ間通知のデータロスト対策 3.仕様の異なるサーバ間通知 • 仕様の異なるサーバ間通知のリクエスト検証 • まとめ
6. なぜアプリ内課⾦をやるのか︖ 6 Copyright © The Asahi Shimbun Company. All rights reserved. 従来Web側にしか導線がない状況
7. 朝⽇新聞デジタルでの実現 7 Copyright © The Asahi Shimbun Company. All rights reserved. Web購読導線の課題 •課⾦完了までの画⾯数が多く途中離脱率が⾼い •課⾦システムの修正が難しく、画⾯を減らすこと⾃体困難 アプリ内課⾦で実現したいこと •既存の課⾦システムに⼿を⼊れずに、モバイルアプリからの 購読操作を可能にしたい
8. なぜアプリ内課⾦をやるのか︖ 8 Copyright © The Asahi Shimbun Company. All rights reserved. 変更コスト︓⼤
9. 話すこと/話さないこと 9 •話すこと✅ •アプリ内課⾦を実現したアーキテクチャの紹介 •話さないこと❌ •詳細な実装について Copyright © The Asahi Shimbun Company. All rights reserved.
10. 課題の背景 10 Copyright © The Asahi Shimbun Company. All rights reserved. •課⾦システムの制約 •変更コストが⾼く新規テーブル・データベースの追加が不可能 •朝⽇IDという独⾃のIDでしかユーザを表現不可能 そのためモバイルアプリ⽤ファサードで、App Store/Google Play のIDを朝⽇IDの仕様に合わせたり、購読の状態を永続化したい 課⾦システムとファサード間という異なるデータソースで整合性を 担保したい
11. 課題の背景 11 Copyright © The Asahi Shimbun Company. All rights reserved. •課⾦システムの制約 •変更コストが⾼く新規テーブル・データベースの追加が不可能 アプリ内課⾦の全ての購読操作はサーバ間通知で送信されるので、 その蓄積がしたいが、課⾦システム側での蓄積が難しい そのためモバイルアプリ⽤ファサードで、サーバ間通知ペイロード は確実に保存したい
12. 課題の背景 12 Copyright © The Asahi Shimbun Company. All rights reserved. •スコープと期限 •ビジネス上、3⽉リリースは厳守する必要 •ビジネス上、Android/iOSでの同時リリースをする必要 期限とスコープに余裕がない App Store/Google Playの仕様の異なるサーバ間通知について処 理を簡略化したい
13. アプリ内課⾦を実現するにあたっての課題 13 Copyright © The Asahi Shimbun Company. All rights reserved. 異なるデータソース で整合性を担保 したい サーバ間通知 ペイロードを確実に 保存したい 仕様の異なる サーバ間通知
14. 異なるデータソースで整合性を担保したい 14 Copyright © The Asahi Shimbun Company. All rights reserved. •課題の背景 課⾦システムの変更コストが⾼く新規テーブル・データベースの追 加が不可能 •やりたいこと 課⾦システムでの購読の開始・更新・解除といった操作のため、 App Store/Google Play上で表現されるIDを朝⽇IDとして 取り扱いたい 朝デジ内で朝⽇ID以外 の認証・認可の仕組み がない
15. 異なるデータソースで整合性を担保したい 15 Copyright © The Asahi Shimbun Company. All rights reserved. そのためApp Store/Google Playと課⾦システムの間のシステムで、 ID仕様を課⾦システムに合わせる必要がある
16. どのように整合性を担保するか 16 Copyright © The Asahi Shimbun Company. All rights reserved. モバイルアプリ⽤ファサードのデータベースと課⾦システムの間で、 各プラットフォームのIDを朝⽇IDの仕様に合わせて、購読状態をア トミックに永続化したい サーガパターンによる分散トランザクションを試みる
17. サーガパターンによる分散トランザクション サーガパターン1 ローカルトランザクションの順次処理で、1つでも処理が失敗した 場合は⼀連の処理に対して補償トランザクションを実⾏してサーガ 中の変更を以前の状態に戻す 17 [1] Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani 著, 島⽥浩⼆ 訳, ソフトウェアアーキテクチャ・ハードパーツ,オライリージャパン, 2022 Copyright © The Asahi Shimbun Company. All rights reserved.
18. 18 Copyright © The Asahi Shimbun Company. All rights reserved. 補償トランザクション 成功後、 最初の購読開始処理は ロールバックされる
19. サーガパターンによる分散トランザクション 19 Copyright © The Asahi Shimbun Company. All rights reserved. 正常系 1.リクエストを受け取ったら 2.App Store/Google Playに検証リクエストを送って 3.成功したら朝⽇IDプラットフォームに購読操作リクエストして 4.成功したらその結果を元に購読情報を保存して 5.基づくレスポンスをユーザ/サーバ間通知に返却する OK😁
20. サーガパターンによる分散トランザクション 20 Copyright © The Asahi Shimbun Company. All rights reserved. 異常系 1.リクエストを受け取ったら 2.App Store/Google Playに検証リクエストを送って 3.成功したら朝⽇IDプラットフォームに購読操作リクエストして 4.成功したらその結果を元に購読情報を保存して 5.基づくレスポンスをユーザ/サーバ間通知に返却する データソースごとにロールバックしたい😢 ここでエラーすると課⾦システムとモバイル アプリ側ファサードで整合性がない状態に
21. サーガパターンによる分散トランザクション 21 Copyright © The Asahi Shimbun Company. All rights reserved. 分散トランザクション の実施
22. サーガパターンによる分散トランザクション 22 Copyright © The Asahi Shimbun Company. All rights reserved. 同期的に呼び出し オーケストレータ ① ② ③
23. サーガパターンによる分散トランザクション 23 Copyright © The Asahi Shimbun Company. All rights reserved. 課⾦システムが停⽌して も、ワークフロー 全体 が停⽌してしまう 課⾦システムが停⽌しても、 ファサードのDBが 停⽌し てもワークフロー 全体が 停⽌してしまう
24. サーガパターンによる分散トランザクション 24 Copyright © The Asahi Shimbun Company. All rights reserved. •モノリシックなシステムを模倣したトランザクション調整が可能 •全てのコンポーネントについてアトミック性を考慮するので、 全て成功するか、全てロールバックされるかとなり、可⽤性が 低くなる
25. アプリ内課⾦を実現するにあたっての課題 25 Copyright © The Asahi Shimbun Company. All rights reserved. 異なるデータソース で整合性を担保 したい サーバ間通知 ペイロードを確実に 保存したい 仕様の異なる サーバ間通知
26. サーバ間通知ペイロードを確実に保存したい 26 Copyright © The Asahi Shimbun Company. All rights reserved. • 課題の背景 課⾦システムの制約でユーザ問い合わせ対応に必要な情報も、モバイルアプリ⽤ ファサードで担保しなければならない • やりたいこと 全ての購読イベントはサーバ間通知で送られる その上解約や返⾦といったイベントは各プラットフォームからのみ送られるので、 問い合わせに対応できるようデータ⽋落を考慮する必要がある そのためサーバ間通知は重要なリクエストで、確実に保存する必要がある
27. サーバ間通知のデータロスト対策 27 Copyright © The Asahi Shimbun Company. All rights reserved. •同期的にAmazon S3に保存したくない •保存失敗を理由にエラーさせるのは機会損失になりかねない •サーバ間通知の受信後、Amazon SQSにキューイング •SQSからは⾮同期にログ保存を⾏い、リトライやDLQを処理から 分離する
28. サーバ間通知のデータロスト対策 28 Copyright © The Asahi Shimbun Company. All rights reserved.
29. 29 Copyright © The Asahi Shimbun Company. All rights reserved. AWS LambdaからペイロードをSQSに キューイング
30. 30 Copyright © The Asahi Shimbun Company. All rights reserved. SQSから⾮同期にS3にペイロードを保存 エラーしたイベントはDLQへ
31. 31 Copyright © The Asahi Shimbun Company. All rights reserved. SQSのイベントサイズが256KBなので ペイロードの仕様変更に注意が必要
32. アプリ内課⾦を実現するにあたっての課題 32 Copyright © The Asahi Shimbun Company. All rights reserved. 異なるデータソース で整合性を担保 したい ペイロードを確実に 保存したい 仕様の異なる サーバ間通知
33. 仕様の異なるサーバ間通知 33 Copyright © The Asahi Shimbun Company. All rights reserved. •課題の背景 App Store/Google Playから送られる仕様の異なる署名リクエスト の検証をしなければならない •やりたいこと サーバ間通知の処理をできるだけ簡略化したい リクエスト元が正しく App Store/Google Playか検証
34. 仕様の異なるサーバ間通知 34 Copyright © The Asahi Shimbun Company. All rights reserved. Google Playはヘッダに署名検証⽤JWTがあるため検証処理が⾏いや すい⼀⽅、 App Storeは独⾃の仕組み 署名検証処理の実装に時間をかけたくない App Store/Google Playの仕様変更に逐次対応する必要があるので 保守性も担保したい
35. 仕様の異なるサーバ間通知のリクエスト検証 35 Copyright © The Asahi Shimbun Company. All rights reserved. 腐敗防⽌層をプラットフォームの数だけ分離 •App Store側 •独⾃の仕組みなので頑張ってLambdaに検証処理を実装しました💪 •Google Play側 •Amazon API Gatewayを採⽤ •HTTP APIを選択することで、署名検証をAPI Gatewayで実施、 実装コストの削減に成功した
36. 仕様の異なるサーバ間通知のリクエスト検証 36 Copyright © The Asahi Shimbun Company. All rights reserved. API Gatewayで 署名検証
37. まとめ︓アプリ内課⾦を実装するにあたっての課題 37 Copyright © The Asahi Shimbun Company. All rights reserved. 異なるデータソース で整合性を担保 したい サーバ間通知 ペイロードを確実に 保存したい 仕様の異なる サーバ間通知 サーガパターンによる 分散トランザクション SQS + Lambda + S3で 非同期に保存 API Gatewayでの 署名検証
38. まとめ① 38 Copyright © The Asahi Shimbun Company. All rights reserved. •課題 •異なるデータソースで整合性を担保したい •解決策 •サーガパターンによる分散トランザクション •同期的にかつアトミックにデータ永続化を⾏うパターンでの 実装を⾏うことで課⾦システムとモバイルアプリ⽤ファサー ド間で整合性が担保できた
39. まとめ② 39 Copyright © The Asahi Shimbun Company. All rights reserved. •課題 •サーバ間通知ペイロードを確実に保存したい •解決策 •SQS + Lambda + S3の構成で⾮同期にペイロードを保存 できる
40. まとめ③ 40 Copyright © The Asahi Shimbun Company. All rights reserved. •課題 •仕様の異なるサーバ間通知のリクエスト検証 •解決策 •プラットフォームごとに通知を受信する腐敗防止層を分離 することで、関心の分離を徹底できた •また、API Gatewayで署名検証を実施することで実装コストを削 減できた
41. We are hiring 41 Copyright © The Asahi Shimbun Company. All rights reserved. 朝日新聞デジタルは 「みえるを広げる。みらいを照らす。」 をミッションに、 世の中の出来事を伝えるだけではなく「多様性」、 その⽣き⽅や考え⽅の“違い”を⼤切にして、 多くの⼈へ伝えていきます。 一緒に最高のメディアを作りませんか？ 採用情報：https://www.asahishimbun-saiyou.com/techmedia/ 採⽤情報QRコード