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

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

©MIXI 私とMIXI Mのご紹介 3

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

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

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

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

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

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

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

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

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

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

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

©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

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

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

©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

©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

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

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

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

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

©MIXI