Upgrade to Pro — share decks privately, control downloads, hide ads and more …

絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ | LayerX

mosa
March 15, 2022

絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ | LayerX

業務フローをなめらかにするために絡み合う複数プロダクトに、マイクロサービスならどう向き合うかの話です。LayerXのバクラクシリーズの話です。

完璧な設計&アプローチとかではなく、現実にあったケーススタディとして、優しく見ていただけると幸いです。

mosa

March 15, 2022
Tweet

Other Decks in Technology

Transcript

  1. Confidential © 2022 LayerX Inc. 1 絡み合うSaaSプロダクトの マイクロサービスアーキテクチャ 2022/03/15 @mosa_siru

    SaaS.tech #1
  2. Confidential © 2022 LayerX Inc. 2 これはなに • 業務フローをなめらかにするために絡み合う複数プロダクトに、 マイクロサービスならどう向き合うかの話です。

    • 完璧な設計&アプローチとかではなく、現実にあったケーススタディと して、優しく⾒ていただけると幸いです。 • めちゃくちゃボリューミーです、すいません…
  3. Confidential © 2022 LayerX Inc. 3 ⾃⼰紹介 榎本 悠介 @mosa_siru

    ・LayerX取締役 SaaS事業部⻑ ・プロダクト/エンジニアチームをリード ・創業時CTO。新規事業、新規プロダクトをひたすらつくるマン ・前線でプロダクト仕様考えまくってコードかきまくってます
  4. Confidential © 2022 LayerX Inc. 4 ⽬次 1. プロダクト紹介 2.

    基本の構成図と考え⽅ 3. マイクロサービスのケーススタディ(循環参照を避ける話) 4. マイクロサービスのケーススタディ(レプリケーション) 5. アーキテクチャ再考 6. まとめ
  5. Confidential © 2022 LayerX Inc. 5 1. プロダクト紹介

  6. Confidential © 2022 LayerX Inc. 6 2021/01から、3つのプロダクトを順次展開(どれも単体で便利︕) 特に今回、 この2つに注⽬

  7. Confidential © 2022 LayerX Inc. 7 AI OCRによる⾃動読取 仕訳の⾃動⼊⼒補完・振込データ⾃動⽣成 会計システムとシームレスに連携

    AI OCRによる稟議の⾃動下書・申請補助 購買申請との紐付けで予算管理 Slack連携でSlackで承認が完結 めちゃくちゃ便利な 請求書処理プロダクト めちゃくちゃ便利な 汎⽤ワークフロー(申請&承認)プロダクト
  8. Confidential © 2022 LayerX Inc. 8 企業A 企業B 売り⼿・受注者 買い⼿・発注者

    請求書を発⾏ 請求書を受け取り 会計・⽀払処理 バクラク請求書とは 受け取った請求書の処理を効率化するサービスです
  9. Confidential © 2022 LayerX Inc. 9 Before バクラク請求書 ✓ 請求書を⾒ながらシステムに⼿⼊⼒が多い。⼊⼒ミスも多い。

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

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

    各プロセスの⾮効率を解消し、⼀気通貫の業務に ✓抜け漏れ確認 ✓請求書催促 ✓AI OCRで申請補助 ✓購買申請で予算統制 ✓slackでラクラク承認 ✓AI OCRで⾃動読取 ✓仕訳データの⾃動作成 ✓⽀払データ⾃動作成 ✓電⼦帳簿保存法対応 データを ⾃動同期 バクラクシリーズで⼀気通貫の業務プロセスのデジタル化が可能
  12. Confidential © 2022 LayerX Inc. 12 ここだけおさえておいて欲しいポイント︕ • 経理に請求書だけ来ても、経理は会社の全てを把握しているわけではないので、払っていい かわからなかったりするよ

    ◦ 上⻑がその⽀払を承認していたか、元の”⽀払申請”(請求書がきたので払ってくださ い申請)を⾒る必要があるよ • でも承認プロセスと請求書処理業務は普通「分断」されているから、その紐付けが⼤変だよ ◦ 例︓承認された⽀払申請の内容を、プリントアウトして経理に渡している • バクラク申請とバクラク請求書は、そこが連携されているのがポイントだよ ◦ ⽀払申請がされると、バクラク請求書側に請求データが作られるよ (単体で便利なプロダクトたちだけど、2つ合わさるとさらに便利なんだよ)
  13. Confidential © 2022 LayerX Inc. 13 2. 基本の構成図と考え⽅

  14. Confidential © 2022 LayerX Inc. 14 構成図(基本形) 各プロダクトのFrontendが裏側の専⽤APIを叩く形式。DBは共有しない。 例︓ユーザー情報については、共通管理基盤(認証基盤)から取りにいく

  15. Confidential © 2022 LayerX Inc. 15 ⽅針 • SPA +

    Backend APIの構成 (Nuxt.js + Golang) • 各プロダクトごとのマイクロサービス ◦ 各プロダクトにPublic APIとPrivate APIがあり、裏側ではPrivate APIを 利⽤ • DBはマイクロサービスをまたいで共有しない (ReadもWriteも⼀⼈) • プロダクト間の循環参照は避ける(重要) ◦ デプロイ順が意味不明になるため
  16. Confidential © 2022 LayerX Inc. 16 Why Microservices? • 単体で成⽴するSaaSプロダクトは、ドメイン境界として適切に⾒えた

    • 実際、開発チームは分かれていた&チームをスケールさせる覚悟があった • 今後どんどんプロダクトを出す可能性があった • 複数プロダクトを展開するSaaSの先輩たちが、モノリスからマイクロサービス に切り出すのに苦⼼しているのを知っていた
  17. Confidential © 2022 LayerX Inc. 17 3. マイクロサービスのケーススタディ (循環参照を避ける話)

  18. Confidential © 2022 LayerX Inc. 18 ここからが本題

  19. Confidential © 2022 LayerX Inc. 19 回収 稟議・承認 仕訳・⽀払・消込 保管

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

    各プロセスの⾮効率を解消し、⼀気通貫の業務に ✓抜け漏れ確認 ✓請求書催促 ✓AI OCRで申請補助 ✓購買申請で予算統制 ✓slackでラクラク承認 ✓AI OCRで⾃動読取 ✓仕訳データの⾃動作成 ✓⽀払データ⾃動作成 ✓電⼦帳簿保存法対応 (※ 2022年1⽉~対応予定) データを ⾃動同期 バクラクシリーズで⼀気通貫の業務プロセスのデジタル化が可能 データを ⾃動同期︕︕
  21. Confidential © 2022 LayerX Inc. 21 要件(1) バクラク申請で⽀払申請(請求書がきたので払ってください申請)がされると、 申請内容を元にしてバクラク請求書で請求書レコードが作られる (Write)

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

  23. Confidential © 2022 LayerX Inc. 23 要件(2) バクラク請求書で請求書を⾒るときは、元になった申請情報も⾒える(Read) (経理がパッと確認するため)

  24. Confidential © 2022 LayerX Inc. 24 要件(2) バクラク請求書で請求書を⾒るときは、元になった申請情報も⾒える(Read) (経理がパッと確認するため)

  25. Confidential © 2022 LayerX Inc. 25 ごく普通の要件感あるが、すでにプロダクト間で循環する・・・・

  26. Confidential © 2022 LayerX Inc. 26 どうするか

  27. Confidential © 2022 LayerX Inc. 27 考えた⽅法 A. BFF /

    Gateway API を利⽤して、循環を避ける B. SPAが他プロダクトのPublic APIを叩くのを許す C. 必要なデータを同期してしまう
  28. Confidential © 2022 LayerX Inc. 28 (A) BFF / Gateway

    API を利⽤して、循環を避ける
  29. Confidential © 2022 LayerX Inc. 29 (A) BFF / Gateway

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

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

  32. Confidential © 2022 LayerX Inc. 32 (B) Frontend が各プロダクトのPublic APIを叩くのを許す

    • よくある、BFFを導⼊する前のパターン。⽐較的シンプルではある • 場合によっては結局依存が発⽣する(次ページ) • 認証・権限まわりがカオスになりがち ◦ 例︓バクラク申請の権限が⾜りず、バクラク請求書側で元になった申請を⾒るこ とができない(あるべき姿かもしれないが、混乱の元になりうる)
  33. Confidential © 2022 LayerX Inc. 33 Frontendが更新制御ロジックを持たないなら、結局依存が発⽣ 両プロダクトの更新処理をFrontendから投げるのは、トランザクション管理を考えるとおすすめ しない。 backend経由にする場合、結局バクラク申請

    => バクラク請求書の依存は発⽣する。(Gateway APIの時と同様) 循環参照を避けるには、更新の起点を統⼀する必要がある。
  34. Confidential © 2022 LayerX Inc. 34 (C) 必要なデータを同期してしまう

  35. Confidential © 2022 LayerX Inc. 35 (C) 必要なデータを同期してしまう • メリット

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

  37. Confidential © 2022 LayerX Inc. 37 よく考えたら出てきた⾟い要件(3) バクラク請求書側の請求書⼀覧の検索にて、元の申請のステータス(承認済等)でフィルタしたい (例︓承認済の請求書だけ処理したい)

  38. Confidential © 2022 LayerX Inc. 38 これはやばい • 請求書⼀覧のフィルタは、請求書の⽇付や⾦額等、あらゆる条件の掛け合わせで⾏わ れる。申請ステータスはその⼀部。

    • これを最適なページング込みで実現するには、同じDBに持つしかない
  39. Confidential © 2022 LayerX Inc. 39 よく考えたら出てきた⾟い要件(4) バクラク請求書側で、元になった申請のデータと合わせて請求書リストをデータ出⼒したい 請求書No 取引先名

    ⾦額 元の申請No 元の申請タイトル #123 mosa産業 10,000 #12 ⽀払申請(mosa産業) #121 ymatsu⽔産 20,000 #9 ⽀払申請(ymatsu⽔ 産) #120 … … .,.. …
  40. Confidential © 2022 LayerX Inc. 40 これもやばい A. Gateway APIパターン︓

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

  42. Confidential © 2022 LayerX Inc. 42 実際は、API経由ではなく⾮同期でデータ同期する API経由だと • 同期処理によりレスポンスが遅くなる

    • 他サービスの障害に影響して、本来の処理(申請作成)⾃体も失敗してしまう。 • トランザクション境界が分かれているため、失敗時にデータ不整合がありうる => Queue経由でリトライ機構を⼊れ、結果整合とする。 Private APIは 微妙…
  43. Confidential © 2022 LayerX Inc. 43 パターン1: Push型 必要な情報をまるっと渡し、⾮同期で更新。必要なコンポーネントも少なく、シンプル。queue のpayloadは太りがち。

    バクラク申請 => バクラク請求書 の依存が発⽣する。
  44. Confidential © 2022 LayerX Inc. 44 パターン2: Pull型 申請IDのみを渡し、実体は取りにこさせる形式。queueのpayloadがシンプルで扱いやすい。 軽微な循環参照だが、今後

    バクラク申請 <= バクラク請求書 の依存(Push型と逆の依存)の⽅ 向が強くなりそうな場合、有⽤。
  45. Confidential © 2022 LayerX Inc. 45 パターン3: 仲介型 複雑だが、専⽤のコンポーネントを仲介することで、直接的な依存を発⽣させない。

  46. Confidential © 2022 LayerX Inc. 46 パターンのまとめ A => B

    の依存 A <= B の依存 コンポーネント数 1. Push型 強 - 少 2. Pull型 弱 強 中 3. 仲介型 弱 - 多 どの依存関係を作りたいかによって、アプローチが異なる。 => 僕らは今後どの依存関係がメインになりそうか︖ 顧客の声をもとに、将来ありそうな要件をベースに考えた。
  47. Confidential © 2022 LayerX Inc. 47 開発を進めるうちに出てきた要件(5) バクラク申請のサービスで、現在バクラク請求書で保持しているマスタデータを⼊⼒したい (例︓申請にて、どの部⾨で使われた費⽤かを⼊⼒・表⽰させたい)

  48. Confidential © 2022 LayerX Inc. 48 おそらくバクラク申請 => バクラク請求書の依存が発⽣しやすいドメインと理解 補⾜︓今回の要件ならGateway

    APIがあれば依存は発⽣しないように⾒えるが、「申請⼀覧を出⼒したい」と⾔われるとやはりアウト
  49. Confidential © 2022 LayerX Inc. 49 【結論】 依存関係の整理の結果、シンプルな「 1. Push型」にした

    A => B の依存 A <= B の依存 コンポーネント数 1. Push型 強 - 少 2. Pull型 弱 強 中 3. 仲介型 弱 - 多
  50. Confidential © 2022 LayerX Inc. 50 補⾜︓データの置き場所 • 依存を発⽣させないために、各プロダクトから参照されやすい マスタデータを、そもそも別サービスに切り出す⼿もある

    • 「どこから更新されるか」「どこから参照したくなるか」 あらゆるユースケースを想像して、「誰の持ち物か」を考え続 ける必要がある ◦ 事前に決めるには、めちゃくちゃドメイン知識がいる。 設計レベルでドメインエキスパートと相談していた。 • 実際、とあるマスタデータは後から最適な場所に移動させた。
  51. Confidential © 2022 LayerX Inc. 51 補⾜︓データ同期の整合性担保 不整合をおこさないために・・・ • 当然リトライする

    • データ同期ジョブについて、当然監視をする • 最終的にデータに不整合がおきていないか、定期的に確認し、アラートを⾶ばしている
  52. Confidential © 2022 LayerX Inc. 52 4. マイクロサービスのケーススタディ (レプリケーション)

  53. Confidential © 2022 LayerX Inc. 53 他にもデータ同期が必要なデータが現れだした • バクラク申請にて、他のRDBとJOINしないと、パフォーマンス的に厳しいクエ リが出てきた(詳細略)

    ◦ (この時点でドメイン境界とは…など⾊々⾔いたいことはある⽅はいそうですが、 まだ抑えてください) • これは「申請をもとに請求書レコードをつくり、さらに申請データも同期する」 等ではなく単純なレプリケーションで良いため、前述と異なる同期パターンが考 えられた
  54. Confidential © 2022 LayerX Inc. 54 同期パターン1 Push型 / パターン2

    Pull型 / パターン3 仲介型 上述と同様。(下図はパターン1)
  55. Confidential © 2022 LayerX Inc. 55 パターン4︓定期Pull型 定期実⾏して、差分のあるレコードを取得し、更新する。

  56. Confidential © 2022 LayerX Inc. 56 パターン4︓定期Pull型 クライアントサイドは「最終更新時刻」を持っておき、「それ以降に更新された レコード⼀覧をくれ︕」と⾔うイメージ。 •

    メリット ◦ パターン1-3と異なり、とりこぼしがなく、データ整合性を保ちやすい • デメリット ◦ リアルタイム性が低い ◦ ⼀括でデータ更新されていると同期量が多い ◦ 物理削除されたことをハンドリングするにはひと⼿間いる
  57. Confidential © 2022 LayerX Inc. 57 パターン5︓DBをまたいでレプリケーションする • 例︓AWS DMS(hostをまたいで特定テーブルのレプリが可能)

    ◦ 1回限りではなく、継続的なレプリケーションが可能
  58. Confidential © 2022 LayerX Inc. 58 パターン5︓DBをまたいでレプリケーションする • AWS DMSを素振りしたところ、問題なくhostをまたいでレプリケーション

    された • ALTERもsyncされることを確認した ◦ ※カラムのデフォルト値, nullability, charset の変更は同期されないので注意 • ⼀⽅、localでの開発環境をどうするかが課題 • (そして同様のユースケースで使っているのを⾒たことがなく、不安)
  59. Confidential © 2022 LayerX Inc. 59 【結論】 • 今回のケースではデメリットを許せたため、「パターン4︓定期Pull型」とした •

    やはりユースケースによって最適な⼿段は変わる
  60. Confidential © 2022 LayerX Inc. 60 5. アーキテクチャ再考

  61. Confidential © 2022 LayerX Inc. 61 そして現在、まだまだ増え続ける連携ニーズ 「バクラク請求書のファイルをバクラク電⼦帳簿保存に連携したい」 「バクラク申請のファイルをバクラク電⼦帳簿保存に連携したい」 「バクラク電⼦帳簿保存にあがったファイルを、バクラク申請に使えないか」

  62. Confidential © 2022 LayerX Inc. 62 俺たちは⼀体何と戦っているんだ︖

  63. Confidential © 2022 LayerX Inc. 63 そもそもドメイン境界間違えてない︖ モノリスじゃだめなの︖

  64. Confidential © 2022 LayerX Inc. 64 実際やってみた

  65. Confidential © 2022 LayerX Inc. 65 モジュラモノリス化のトライ • mosaがマイクロサービスに発狂し、1-2週間集中して取り組んだ。 •

    せっかく分かれているDBは⼤統⼀せずに、モジュラモノリスっぽくやるの を検討した
  66. Confidential © 2022 LayerX Inc. 66 当初考えていたメリット 1. 循環参照問題からの解放 2.

    データ同期と整合性チェック、Txまたぎの必要がなくなる 3. コード共有ができる、無駄なPrivate API開発がなくなる
  67. Confidential © 2022 LayerX Inc. 67 結論︓撤退した

  68. Confidential © 2022 LayerX Inc. 68 撤退の理由 • 循環参照問題からの解放はされなかった。 ◦

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

    仮にモジュラモノリスがうまく⾏くなら、今のマイクロサービスでもうま くいくはず。 • やるならDBも統⼀、循環依存上等な完全なモノリス化だが、今のメリット を完全に捨てることになる。モジュラモノリスでない以上、戻ることも茨 の道。ゼロベースならさておき、今からやるには…。
  70. Confidential © 2022 LayerX Inc. 70 あらためて、今の構成の メリットは何か︖

  71. Confidential © 2022 LayerX Inc. 71 連携の設計は難しいが、マイクロサービスのメリットを享受しているのも事実 • 各位が⾃律して動き、ファクトとして爆速で開発できて おり、運⽤もできている

    ◦ いまも現在進⾏形で新しいプロダクトを開発しよ うとしている • 他にも、OCR基盤/認証基盤/タイムスタンプ機構などプ ロダクトによらないマイクロサービスもあり、効率化の 恩恵を感じている • そもそも単体で成⽴しているプロダクトであり、「⼀部 でもデータ連携(の可能性)があるから分けるべきでな い」というのもどうなのか ◦ 今後新しいプロダクト群も全部モノリスにするの か︖ • 新しいプロダクトでは新しい開発⼿法を試すことができ、 確実にチームに知⾒がたまっている
  72. Confidential © 2022 LayerX Inc. 72 6. まとめ

  73. Confidential © 2022 LayerX Inc. 73 まとめ • 複数プロダクトで業務フローをなめらかにするSaaSは、ドメイン境界の設 定が単純ではない

    ◦ 適切な切り⽅を知るには、深いドメイン知識が必要で、後からわかる ことも多い • 連携部分とデータの置き場所は、設計⼒が極めて問われ、ユースケースに 依存する • 割り切って最初からモノリスにすることは⼗分ありうる。⼀⽅、先輩⽅が 後から切り出すのに苦労しているのも事実 • モジュラモノリスも結局依存関係と戦うことになると実感
  74. Confidential © 2022 LayerX Inc. 74 We are Hiring︕ LayerXでは、顧客と向き合い、最⾼の体験と最適な設計を

    両⽴できるエンジニアを求めています︕ https://jobs.layerx.co.jp/