絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ

絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ | LayerX

by mosa

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Confidential © 2022 LayerX Inc. 9 Before バクラク請求書 ✓ 請求書を⾒ながらシステムに⼿⼊⼒が多い。⼊⼒ミスも多い。 ✓ 前⽉の仕訳を確認しながら、仕訳を切っていて⼤変。⼿⼊⼒・ミス回収漏れ ✓ 現場が請求書を上げ忘れる。取引先が請求書を送ってこない。 ✓ 請求書の抜け漏れチェックが⼤変。稟議・統制 ✓ 現場が上げる⽀払依頼が遅い。申請が間違っている。 ✓ 請求書だけ⾒ても、⽀払っていいかわからない。請求書と稟議が紐付いていない。（紙で申請と請求書がまわってくる…）今回、ここにフォーカス当てます

Slide 10

Slide 10 text

Confidential © 2022 LayerX Inc. 10 After バクラク請求書 ✓ AI-OCRで請求書情報を⾃動⼊⼒ ✓ 仕訳の⾃動⼊⼒補完・振込データ⾃動作成 ✓ 回収状況レポートで回収漏れを確認 ✓ 回収催促機能で、請求書をURLで回収可能 ✓ 稟議をOCRで⾃動⼊⼒。現場でミスや負担削減 ✓ 請求書と稟議の紐付けでかんたん確認⼿⼊⼒・ミス回収漏れ稟議・統制今回、ここにフォーカス当てます

Slide 11

Slide 11 text

Confidential © 2022 LayerX Inc. 11 回収稟議・承認仕訳・⽀払・消込保管各プロセスの⾮効率を解消し、⼀気通貫の業務に ✓抜け漏れ確認 ✓請求書催促 ✓AI OCRで申請補助 ✓購買申請で予算統制 ✓slackでラクラク承認 ✓AI OCRで⾃動読取 ✓仕訳データの⾃動作成 ✓⽀払データ⾃動作成 ✓電⼦帳簿保存法対応データを⾃動同期バクラクシリーズで⼀気通貫の業務プロセスのデジタル化が可能

Slide 12

Slide 12 text

Confidential © 2022 LayerX Inc. 12 ここだけおさえておいて欲しいポイント︕ ● 経理に請求書だけ来ても、経理は会社の全てを把握しているわけではないので、払っていいかわからなかったりするよ ○ 上⻑がその⽀払を承認していたか、元の”⽀払申請”（請求書がきたので払ってください申請）を⾒る必要があるよ ● でも承認プロセスと請求書処理業務は普通「分断」されているから、その紐付けが⼤変だよ ○ 例︓承認された⽀払申請の内容を、プリントアウトして経理に渡している ● バクラク申請とバクラク請求書は、そこが連携されているのがポイントだよ ○ ⽀払申請がされると、バクラク請求書側に請求データが作られるよ（単体で便利なプロダクトたちだけど、2つ合わさるとさらに便利なんだよ）

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Confidential © 2022 LayerX Inc. 15 ⽅針 ● SPA + Backend APIの構成 (Nuxt.js + Golang) ● 各プロダクトごとのマイクロサービス ○ 各プロダクトにPublic APIとPrivate APIがあり、裏側ではPrivate APIを利⽤ ● DBはマイクロサービスをまたいで共有しない (ReadもWriteも⼀⼈) ● プロダクト間の循環参照は避ける（重要） ○ デプロイ順が意味不明になるため

Slide 16

Slide 16 text

Confidential © 2022 LayerX Inc. 16 Why Microservices? ● 単体で成⽴するSaaSプロダクトは、ドメイン境界として適切に⾒えた ● 実際、開発チームは分かれていた＆チームをスケールさせる覚悟があった ● 今後どんどんプロダクトを出す可能性があった ● 複数プロダクトを展開するSaaSの先輩たちが、モノリスからマイクロサービスに切り出すのに苦⼼しているのを知っていた

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Confidential © 2022 LayerX Inc. 19 回収稟議・承認仕訳・⽀払・消込保管各プロセスの⾮効率を解消し、⼀気通貫の業務に ✓抜け漏れ確認 ✓請求書催促 ✓AI OCRで申請補助 ✓購買申請で予算統制 ✓slackでラクラク承認 ✓AI OCRで⾃動読取 ✓仕訳データの⾃動作成 ✓⽀払データ⾃動作成 ✓電⼦帳簿保存法対応 (※ 2022年1⽉~対応予定) データを⾃動同期バクラクシリーズで⼀気通貫の業務プロセスのデジタル化が可能

Slide 20

Slide 20 text

Confidential © 2022 LayerX Inc. 20 回収稟議・承認仕訳・⽀払・消込保管各プロセスの⾮効率を解消し、⼀気通貫の業務に ✓抜け漏れ確認 ✓請求書催促 ✓AI OCRで申請補助 ✓購買申請で予算統制 ✓slackでラクラク承認 ✓AI OCRで⾃動読取 ✓仕訳データの⾃動作成 ✓⽀払データ⾃動作成 ✓電⼦帳簿保存法対応 (※ 2022年1⽉~対応予定) データを⾃動同期バクラクシリーズで⼀気通貫の業務プロセスのデジタル化が可能データを⾃動同期︕︕

Slide 21

Slide 21 text

Confidential © 2022 LayerX Inc. 21 要件(1) バクラク申請で⽀払申請（請求書がきたので払ってください申請）がされると、申請内容を元にしてバクラク請求書で請求書レコードが作られる (Write) 申請すると、申請内容を元に請求書レコード作成請求書No. 111 ⽀払⾦額: 660,000 ⽀払期⽇: 2020-10-31 取引先︓株式会社⽇本（添付ファイル付）申請作成画⾯

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Confidential © 2022 LayerX Inc. 29 (A) BFF / Gateway API を利⽤して、循環を避ける ● メリット ○ シンプルである ● デメリット ○ 今は存在しないGateway APIが登場する ■ ※そもそもあるべきという説も濃厚であるが、各種事情で今からつくるのが簡単ではない ○ Gatewayがロジックを持たないなら、結局依存関係が発⽣（次ページ）

Slide 30

Slide 30 text

Confidential © 2022 LayerX Inc. 30 Gatewayが更新制御ロジックを持たないなら、結局依存関係が発⽣ Gateway API には 2つのマイクロサービスをまたいだ更新制御ロジックを持たせたくない。（ロールバック処理等をGatewayに持たせたくないため。）その場合、バクラク申請 => バクラク請求書の依存が発⽣する。この理屈だと、更新処理の起点がバラバラだと、結局循環参照が起きる可能性がある。

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Confidential © 2022 LayerX Inc. 32 (B) Frontend が各プロダクトのPublic APIを叩くのを許す ● よくある、BFFを導⼊する前のパターン。⽐較的シンプルではある ● 場合によっては結局依存が発⽣する（次ページ） ● 認証・権限まわりがカオスになりがち ○ 例︓バクラク申請の権限が⾜りず、バクラク請求書側で元になった申請を⾒ることができない（あるべき姿かもしれないが、混乱の元になりうる）

Slide 33

Slide 33 text

Confidential © 2022 LayerX Inc. 33 Frontendが更新制御ロジックを持たないなら、結局依存が発⽣両プロダクトの更新処理をFrontendから投げるのは、トランザクション管理を考えるとおすすめしない。 backend経由にする場合、結局バクラク申請 => バクラク請求書の依存は発⽣する。(Gateway APIの時と同様) 循環参照を避けるには、更新の起点を統⼀する必要がある。

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Confidential © 2022 LayerX Inc. 35 (C) 必要なデータを同期してしまう ● メリット ○ バクラク請求書ユーザーは、申請側の権限に依らず申請情報を⾒ることができる ● デメリット ○ データ同期の複雑性 ○ データ不整合の危険 ○ DBスキーマ変更時に⼤変これやるくらいなら、DB直参照を許した⽅が良いのではという気分にならなくもない。（Writeは1⼈の責任、Readは最悪複数⼈を許す）

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Confidential © 2022 LayerX Inc. 39 よく考えたら出てきた⾟い要件(4) バクラク請求書側で、元になった申請のデータと合わせて請求書リストをデータ出⼒したい請求書No 取引先名⾦額元の申請No 元の申請タイトル #123 mosa産業 10,000 #12 ⽀払申請(mosa産業) #121 ymatsu⽔産 20,000 #9 ⽀払申請(ymatsu⽔産) #120 … … .,.. …

Slide 40

Slide 40 text

Confidential © 2022 LayerX Inc. 40 これもやばい A. Gateway APIパターン︓ Gateway APIでCSV組み⽴てるの・・・︖ B. Frontend パターン︓Frontでデータの組み⽴てをすることは現実的ではない。結局、バクラク請求書 => バクラク申請の依存が発⽣する（下図）これにより循環参照となる。 C. データ同期して、同じDBに持つのがベストではという結論

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Confidential © 2022 LayerX Inc. 42 実際は、API経由ではなく⾮同期でデータ同期する API経由だと ● 同期処理によりレスポンスが遅くなる ● 他サービスの障害に影響して、本来の処理（申請作成）⾃体も失敗してしまう。 ● トランザクション境界が分かれているため、失敗時にデータ不整合がありうる => Queue経由でリトライ機構を⼊れ、結果整合とする。 Private APIは微妙…

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Confidential © 2022 LayerX Inc. 50 補⾜︓データの置き場所 ● 依存を発⽣させないために、各プロダクトから参照されやすいマスタデータを、そもそも別サービスに切り出す⼿もある ● 「どこから更新されるか」「どこから参照したくなるか」あらゆるユースケースを想像して、「誰の持ち物か」を考え続ける必要がある ○ 事前に決めるには、めちゃくちゃドメイン知識がいる。設計レベルでドメインエキスパートと相談していた。 ● 実際、とあるマスタデータは後から最適な場所に移動させた。

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Confidential © 2022 LayerX Inc. 53 他にもデータ同期が必要なデータが現れだした ● バクラク申請にて、他のRDBとJOINしないと、パフォーマンス的に厳しいクエリが出てきた（詳細略） ○ （この時点でドメイン境界とは…など⾊々⾔いたいことはある⽅はいそうですが、まだ抑えてください） ● これは「申請をもとに請求書レコードをつくり、さらに申請データも同期する」等ではなく単純なレプリケーションで良いため、前述と異なる同期パターンが考えられた

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Confidential © 2022 LayerX Inc. 56 パターン4︓定期Pull型クライアントサイドは「最終更新時刻」を持っておき、「それ以降に更新されたレコード⼀覧をくれ︕」と⾔うイメージ。 ● メリット ○ パターン1-3と異なり、とりこぼしがなく、データ整合性を保ちやすい ● デメリット ○ リアルタイム性が低い ○ ⼀括でデータ更新されていると同期量が多い ○ 物理削除されたことをハンドリングするにはひと⼿間いる

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Confidential © 2022 LayerX Inc. 58 パターン5︓DBをまたいでレプリケーションする ● AWS DMSを素振りしたところ、問題なくhostをまたいでレプリケーションされた ● ALTERもsyncされることを確認した ○ ※カラムのデフォルト値, nullability, charset の変更は同期されないので注意 ● ⼀⽅、localでの開発環境をどうするかが課題 ● （そして同様のユースケースで使っているのを⾒たことがなく、不安）

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Confidential © 2022 LayerX Inc. 68 撤退の理由 ● 循環参照問題からの解放はされなかった。 ○ モジュラモノリス内で循環依存を避けるために、結局同じことを考える必要があった ○ 例︓申請情報をembedする請求書struct があると、package依存が発⽣ ○ コンポーネント間の複雑さを、そのままコード間の複雑さにおしこめた印象だった。 ● DBが分かれている時点で、Txまたぎと不整合リスクは残った ● 組織のスケールという流れに逆⾏している ● 思ったより共有されるロジックはなかった ● コードの⾒通しが悪くなった。書いていて楽しくなくなった(フィーリング)

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Confidential © 2022 LayerX Inc. 71 連携の設計は難しいが、マイクロサービスのメリットを享受しているのも事実 ● 各位が⾃律して動き、ファクトとして爆速で開発できており、運⽤もできている ○ いまも現在進⾏形で新しいプロダクトを開発しようとしている ● 他にも、OCR基盤/認証基盤/タイムスタンプ機構などプロダクトによらないマイクロサービスもあり、効率化の恩恵を感じている ● そもそも単体で成⽴しているプロダクトであり、「⼀部でもデータ連携(の可能性)があるから分けるべきでない」というのもどうなのか ○ 今後新しいプロダクト群も全部モノリスにするのか︖ ● 新しいプロダクトでは新しい開発⼿法を試すことができ、確実にチームに知⾒がたまっている

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Confidential © 2022 LayerX Inc. 73 まとめ ● 複数プロダクトで業務フローをなめらかにするSaaSは、ドメイン境界の設定が単純ではない ○ 適切な切り⽅を知るには、深いドメイン知識が必要で、後からわかることも多い ● 連携部分とデータの置き場所は、設計⼒が極めて問われ、ユースケースに依存する ● 割り切って最初からモノリスにすることは⼗分ありうる。⼀⽅、先輩⽅が後から切り出すのに苦労しているのも事実 ● モジュラモノリスも結局依存関係と戦うことになると実感

Slide 74

Slide 74 text