Kyash TechTalk #2 - Serversideのシステム構成とアーキテクチャ 2022年4月18日 Kohei Omotani (@k_omotani) KyashのMicro Service Architecture

2 01. はじめに 02. System overview 03. つらみ 04. まとめ

3 3 01. はじめに

4 自己紹介 - Omotani Kouhei - Twitter: @k_omotani - 2020年2月入社 - Kyashのサーバーサイドを広く触ってます - 携わった機能 - カテゴリー機能、共有口座機能、他 はじめに

5 関係ないけど宣伝 - 共有口座いいぞ〜！ - 他の人を入れずに 目的別口座的な使い方 もできます！ はじめに

6 話すこと - この後のLTやパネルディスカッションを理解しやすくできるようにKyashのサーバーサ イドのアーキテクチャ全体についてざっと話します - 「こういう試みをしてこんないい感じになったよ」系の話ではないです - 「こういう工夫してるよ/こういう辛みを抱えてるよ」な話です はじめに

7 7 02. System overview

8 システム全体図 - 結構ゴツい - 内部/外部との接続について 分けて話します System overview

pf-api Shared DB pf-lending Mobile app 9 Kyash内部の構成 - “platform-hoge”サービス群 - platform-apiがRest APIを提供し mobileからのアクセスを受け付ける - サービス間の通信は古いものは Rest API、比較的新しく作成したものは gRPCを用いている System overview SQS pf-lending-consumer DB - pf-payout DB pf-notification Push通知 pf-payment pf-payment pf-payment VisaNetなど

10 Kyash内部の構成 - マイクロサービスは業務の関心毎ごとに切り 分けられている - 大体 1 serviceに1 repository - 決済周りの処理を行う platform-payment, 入 出金を管理するplatform-topupなど - Shared DBに繋ぐ部分をライブラリ化 - gRPCのproto定義やpub/subのメッセージ定 義を置いてるplatform-protoとかもある - 2022/04/14 現在で - Org配下に166repo - platformで絞ると75repo System overview

11 Kyash内部の構成（非同期処理周り） - 定期実行ジョブ的なものは ECS scheduled taskを使うことが多い - 秘伝のjobもあるが... - Message Consumer - SQSにキューイングしそれをconsumeすることで非同期に処理している箇所も - この後のLTで話が出るかも？ System overview

12 Kyash外部との接続について - 決済(Visa、QUICPay＋)、銀行入出金、今すぐ入金、カード発行、 eKYC、etc. - 銀行入出金 - この後のLTで話が出ると思います System overview

13 13 03. つらみ

14 Shared DB - これが一番デカいと思う - Kyashでは複数のサーバーから共通 のDBに接続している - 各サービス毎にDBユーザーを割り 振って接続可能なテーブルを管理し てる つらみ Service A Shared DB Service B Service C internal DB internal DB

15 Shared DB これにより起こった問題 - DB接続を伴う残高操作を行う処理をライブラリ化している。そのライブラリに修正を加えて追加 でshared DBのテーブルを見るようになった。権限付与漏れにより関連サービスがぶっ壊れた - 一度イベント関連でカード登録が爆増、 DB負荷が上がり決済にまで影響が出る Incidentに なった つらみ

16 Shared DB - でもこれのお陰で残高変動周りのトランザクション管理が楽に出来ている - 外部システムとの整合性を取るための試み等は既に実績あり - この後のejimaさんの話で聞けます 裏話 - Kyashでは過去にKyash Directという別基盤のシステムを構築 - その時はTry,Confirm,CancelのTCCパターンのメッセージ駆動でトランザクション管理を 行っていた - 登壇資料 - 残高処理周りのDB分割を進めようとしている つらみ

17 履歴データの処理 - 都度履歴のモデルを構築 - 履歴とはいうものの単純なイミュータブルなデータではないのが難しいところ - 決済系であればSDが来るタイミングでポイントが未確定から確定に - メモやカテゴリーなどの更新できるデータ - Cacheやクエリの細かな見直しなどで頑張っている - EventSource/CQRSにしたい(個人的な願望) つらみ

18 18 04. まとめ

19 - 外部との接続が多いところが特徴 - 最近新しく作るサービスはSQSを使ったmessagingで耐障害性上げてるよ - DB分割を少しずつ進めているよ - 新規のマイクロサービスは専用 DBに - やっぱりShared DBは辛いよ - 付随するライブラリ周りで問題発生しがち まとめ

Thank you 20