DynamoDB で決済システムを運用してみた【MIXI TECH CONFERENCE 2023】

MIXI TECH CONFERENCE 2023
にてお話した田岡の資料です。

動画：https://youtu.be/v6Ldqz_SRN4

https://techcon.mixi.co.jp/d3-5

Transcript

1. ©MIXI
   D3-5
   DynamoDB で決済システムを運用してみた
   ~MIXI Mにおける事例の紹介~
   開発本部 MIXI M 事業部 システムグループ
   田岡 文利
   

   View Slide

2. ©MIXI
   おしながき
   ● 私とMIXI Mのご紹介
   ● DynamoDBを選択したのはなぜ？
   ● DynamoDBを使い倒そう
   ○ DynamoDBのおさらい
   ○ データ整合性を守るための方法
   ○ MIXI M での設計方針
   ● DynamoDB Streamsを活用
   ● お困りごと
   ● 運用に関してよかったこと
   ● 決済システムで開発運用した所感
   ● まとめ
   2
   

   View Slide

3. ©MIXI
   私とMIXI Mのご紹介
   3
   

   View Slide

4. ©MIXI
   田岡文利
   2012年4月入社
   → SNS「mixi」 の 自社Framework開発とサービス開発
   →グループ会社の支援 (開発体制、ガツガツ開発、SREぽい事)
   → XFLAG アプリ・XFLAG ID の開発・運用
   → 新サービス開発熟考期 (ビデオ・ライブ配信 / WebRTC / BLE)
   → 決済基盤の開発・運用や、新規決済系サービス「6gram」の開発
   → 6gram 改 MIXI M の開発運用中 (決済やり始めて3年くらい)
   4
   

   View Slide

5. ©MIXI
   認証から決済までをワンストップで提供できる基盤システム & WALLETサービスです。
   ビジネスからエンタメ領域まで様々なサービスの『間（M）』をなんとかすることをサービスコンセ
   プトとして、ID・認証基盤やWALLET（金融システム）をすべて自社開発することでユーザーの
   利用シーンに合わせた柔軟なサービスを展開しています。
   5
   

   View Slide

6. ©MIXI
   MIXI M
   ID
   - 認証認可
   - 個人情報や本人確認の取りまとめ
   - Webポータル
   決済
   - Wallet
   - クレジットカードや銀行口座の管理
   - 残高の管理
   - プリペイドクレジットカード
   - チャージ・オーソリ
   - 決済フローの提供
   - クレジットカードや銀行口座を始めとして様々な決済手段を提供
   6
   

   View Slide

7. ©MIXI
   決済システム
   - Elixirベースの内製コンポーネントがたくさん
   - VISA, JCB FEP
   - 決済アプリケーション(API, Web)
   - カード決済、 銀行決済、 etc…
   - Wallet管理、履歴....
   - Developers Boost 2019: Elixir で決済サービスをつくってみた
   - AWS
   - Fargate, DynamoDB
   - 基本的にフルマネージドなサービスを組み合わせて実装
   - SRE NEXT 2020: グループウォレットアプリ6gramの運用をはじめてみた
   7
   

   View Slide

8. ©MIXI
   Q: DynamoDBを選択したのはなぜ？
   8
   

   View Slide

9. ©MIXI
   A: 運用負荷をさげる！
   9
   

   View Slide

10. ©MIXI
    A: 運用負荷をさげる！ ← テーマ
    本当にさがるのだろうか？？
    結果的に下がった話、元々始めた理由は......
    10
    

    View Slide

11. ©MIXI
    PCIDSSと運用を見越すとDynamoDBが選択肢に
    - RDBは基本user/passwordで接続します...
    - パスワードの要件やアカウント管理これは面倒臭い
    - 無停止運用したいでもセキュリティパッチを当てたりは必須
    - 方法は考えることができるが大変
    ↓
    - クレジットカード情報など全てのデータをDynamoDBに保存、AWSマ
    ネージドなシステムを使っていくことで...
    - IAMをベースとした細かいアクセス制御
    - KMSによるテーブルの暗号化が容易
    - セキュリティパッチなどを自分達で当てる必要がない
    11
    

    View Slide

12. ©MIXI
    DynamoDBを採択できる？
    - PCI, HIPAA など 金融や医療でのコンプライアンスもとれているマネー
    ジドサービス
    - 金融システム採用事例もある
    - せっかく採用するならうまく使いたい
    - AWSの公式ドキュメントでも金融システムでの利用例はある
    - Amazon DynamoDB の変更データキャプチャ
    - ドキュメントもいい感じにメンテナンスされてる
    - ベストプラクティスでAmazonが考える利用ケースも理解できそう
    12
    

    View Slide

13. ©MIXI
    DynamoDBの概要をザックリ(1)
    - フルマネージドなNoSQLデータベース
    - パーティションキー(以後PK) もしくは, PK + ソートキー(以後SK) でアイ
    テムのプライマリーキーが構成される
    - プライマリーキーで直接取得もしくは PKを指定してクエリ
    - PKで分散がかかる, その中でSortKey でデータが並ぶ
    - SortKeyでは 前方マッチなどのmatch等少し頭のいい検索が効く
    13
    

    View Slide

14. ©MIXI
    DynamoDB の概要をザックリ(2)
    - 任意のフィールドでインデックスを作ることができる
    - スパースインデックス
    - フィールドが未定義の場合はインデックスが作成されない
    - 大きく2種類の課金体系
    - オンデマンドキャパシティ(リクエスト課金/マネージドなオートスケール)
    - プロビジョニング済みキャパシティ(時間課金/手動/ルールベーススケール)
    - キャパシティが不足するとリクエストが詰まることになる
    - インデックスは自動生成されるため、インデックス側で詰まる場合にはもとテーブルも
    影響を受ける
    - TTLでデータの有効期限を指定できる
    14
    

    View Slide

15. ©MIXI
    データ整合性を守るための方法
    - Transactions を利用する
    - 複数のItemへの操作を一度にできる話
    - 条件付き(ConditionExpression)書き込みを利用する
    結果整合なので、条件付きの処理が活躍する場面が非常に多い
    id: xxxxxxxxxx
    amount: 1,000
    lock_version: 11
    id: xxxxxxxxxx
    amount: 5,000
    lock_version: 10
    先に
    update
    id: xxxxxxxxxx
    amount: 0
    lock_version: 11
    同時にUpdate
    5,000円 を使ったことを記録
    - lock_versionでの制御
    - lock_version == 10
    - amount: 0
    - amountによる制御
    - amount > 5000
    - amountを 5,000 引く
    - lock_version: +1
    15
    

    View Slide

16. ©MIXI
    設計方針
    - DynamoDB を使用した設計とアーキテクチャの設計に関するベスト
    プラクティスに沿って開発する
    - テーブルはできるだけ少なくする
    - アクセスパターンやデータの種類に合わせる
    - 同じテーブルで複数のモデルを扱えるようにする
    - テーブルの基本ルールは PK,SKを汎用な文字列型にする
    - “pk”(string), “sk”(string)
    - モデル間で共通利用できるindexを推奨
    - 時系列データを表示するための
    index を作るなど
    - オンデマンドキャパシティを利用する
    - リクエスト課金でコストメリットが高い
    - スケールイン・スケールアウトを考えなくて済む
    16
    

    View Slide

17. ©MIXI
    ベストプラクティスでは
    DynamoDB Streamもお勧めされている
    17
    

    View Slide

18. ©MIXI
    DynamoDB Streams を活用(1)
    履歴データや利用状況データの作成
    ● APPは残高の状態を書き換える
    ● DynamoDB Streamにデータが流れる
    ● Lambdaで履歴データなどを作成
    APP DynamoDB
    DynamoDB
    Stream
    Lambda
    user: 1, amount: 2000
    event: {amount: -1000, 決済方法: card_1}
    updated_at: 2023/03/03 10:00:00
    user1利用履歴
    created_at: 10:00:00
    amount: -1000
    card_1利用履歴
    created_at: 10:00:00
    amount: -1000
    複数種類作ってみたり
    Streamには変更前と変更後のデータが流
    れてくる
    同じレコードに複数の書き込みがあっても順
    番に処理できる
    18
    

    View Slide

19. ©MIXI
    DynamoDB Streams を活用(2)
    長いスパンの遅延処理
    ● TTLでのデータ削除がDynamoDB Streamに流れる
    ● Lambda で処理
    ○ ALBを通してAPPでも処理できる
    ● ※TTLで削除発火はバラつきあり
    Internal ALB APP DynamoDB
    DynamoDB
    Stream
    Lambda
    acition: データ処理
    params: hogehoge
    TTL: 2023/03/03 (unixtime)
    19
    

    View Slide

20. ©MIXI
    お困りごと
    - 単体で解析ぽいお仕事は非常に苦手
    - あらかじめ決めたtopicに関するカウンタくらいはすぐ作れる
    - 解析に関してはDynamoDBのPointTimeRecoveryデータをS3に出力して
    AWS Glueを通してAthenaで検索したりしている (リアルタイムではない)
    - 全くスキャンができない訳ではない
    - 時間かかるので別の方法をとった方が無難、必要なデータはすぐに引けるように設
    計
    - リアルタイムな解析以外はなんとか対応、リアルタイム解析はこれから
    - 結果整合性による問題
    - Replication遅延みたいなものだけどはまる時はある
    - GSIに関しては強整合性の取得ができない
    - どちらもメインテーブルへの強整合性
    GetItemでなんとかなっている
    20
    

    View Slide

21. ©MIXI
    運用に関してよかったこと
    楽なことが多い♪
    - ソフトウェアのバージョン更新に関して考える必要がない
    - そもそもダウンタイムを気にしないで済む
    - メンテナンスwindow、 コネクション管理、 バージョン間の違い...
    - failoverしたらどうなるんだっけ....
    - なんなら機能が増えて嬉しいことの方が多い
    - トランザクション制限の増加(25 -> 100 item)
    - パフォーマンスに関しての運用
    - スケールアップを考えないでほぼなんとかなってる
    - スケールアウトはもうされている
    - 設計に関しては先にコストを払っている
    21
    

    View Slide

22. ©MIXI
    決済システムで開発運用した所感
    - RDBMS的に制約をもってデータ管理しないと不整合が起きない？トラ
    ンザクション必要では？
    - 結果不整合はほぼ起きていない
    - 決済システムにおいては、結局他のシステムとのデータ整合性を取る仕組み
    が必要になるので DB だけがそれを行えてもしょうがない
    - 結果トランザクションを使ってるところは少ない
    - 新規メンバーの学習って大変じゃない？
    - 機能が少ないので使うまでは容易い、新規設計は慣れが必要
    - 新規のテーブルを使うことがあまりないので、既存のデータのアクセス方法を
    確認しながら設計を把握してもらっています
    - 非正規化する^q^、制約多くない？
    - cacheを運用していたり、DBのmemory上のindexだけでどうにかなるように
    したり、シャーディングをしていたことを考えるとあんまり変わらない気持ち
    22
    

    View Slide

23. ©MIXI
    まとめ
    - 決済システムをDynamoDBで作って運用することはアリだった
    - オンデマンドキャパシティを使うことでスケールイン、スケールアウトに
    関して気にせずにパフォーマンス最適
    - RDBにありがちなメンテナンスが不要
    - ダウンタイムを考えなくて良いのは大きい
    - RDBのめんどくさいところを回避できる
    設計は公式ベストプラクティスを参考にすれば大丈夫
    23
    

    View Slide

24. ©MIXI
    

    View Slide