新規事業でもマイクロサービスに挑戦する / Challenging Microservices in new businesses

■イベント

【Sansan Technical View】Sansanの技術的「挑戦」
https://sansan.connpass.com/event/208003/

■登壇概要

タイトル：新規事業でもマイクロサービスに挑戦する

登壇者：Bill One事業部 加藤 耕太

▼Sansan Builders Blog

https://buildersbox.corp-sansan.com/

Transcript

2. 加藤 耕太（Kota Kato） 2011年 4⽉〜 SIerで社内技術推進を担当 2018年 9⽉〜 Sansan株式会社に⼊社し、Sansanのサーバーサイド開発を担当 2019年 6⽉〜 アーキテクトとしてBill Oneの⽴ち上げに関わる 著書：Pythonクローリング&スクレイピング データ収集・解析のための実践開発ガイド Sansan株式会社 Bill One事業部＠関⻄⽀店 ソフトウェアエンジニア
3. - チェックイン - Bill Oneにおけるマイクロサービス化 - Bill Oneでの実装⽅針 - まとめ アジェンダ
4. チェックイン
5. https://bill-one.com/
6. あらゆる請求書をオンラインで受け取る
7. マイクロサービス（英語：microservices）とは、ソフトウェア開発の技 法の1つであり、1つのアプリケーションを、ビジネス機能に沿った複数 の⼩さいサービスの疎に結合された集合体として構成するサービス指向 アーキテクチャ（service-oriented architecture; SOA）の1種である。 マイクロサービス “ 出典: フリー百科事典『ウィキペディア（Wikipedia）』 https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9
8. Bill Oneのアーキテクチャ ※BFF: Backend For Frontend
9. Bill Oneにおけるマイクロサービス化
10. Bill Oneの初期のフェーズ 2018年12⽉〜 Djangoで素早く作って社内トライアル （モノリス） 2019年7⽉〜 Kotlinで追加機能を開発 （モノリス + DBを共有するサービス + マイクロサービス） 2020年1⽉〜 ピボットして1から作り直す （マイクロサービス）
11. 新規サービスをどう作ろうか？ モノリス モジュラ モノリス マイクロ サービス メンバーの得意なスキルで 良さそうな構成が⾒当たら なかった モジュール同⼠の境界を 維持し続けられるのか ⾃信がない サービス間の分離を強制 された⽅が良いのでは ないか
12. Bill Oneのサービス分割 network invoice tenant
13. - 新機能を素早くリリースしていける - リリース時の影響範囲を減らせる - 各サービスのコードベースが⼩さく保たれるので保守しやすい - 「まず1つのサービスで試す」が容易 - 障害発⽣時の影響範囲を局所化できる - 仮に受領側で障害が発⽣しても、請求書の受領は継続できる Bill Oneにおけるマイクロサービス化の効果
14. Bill Oneでの実装⽅針
15. - サービスの独⽴性を重視する - サービスごとにデータベースを持つ - キューによる⾮同期のデータ連携 - 共有ライブラリは作らず重複を許容する - なるべく開発・運⽤効率を落とさない - Trace Contextを使ったサービス横断でのログ閲覧 - モノレポ化 実装⽅針
16. network サービスごとにデータベースを持つ App Engine BFF ユーザー Cloud Run Cloud SQL invoice Cloud Run Cloud SQL tenant Cloud Run Cloud SQL 各サービスが独⽴して稼働でき、 他のサービスの影響を受けにくい
17. - サービス間の同期的な呼び出しは避け、必要なデータは事前に連携しておく キューによる⾮同期のデータ連携 network Cloud Run Cloud SQL invoice Cloud Run Cloud SQL Cloud Tasks 送付ユーザー 受領ユーザー 請求書送付 請求書受領 送付ユーザーの 請求書 受領ユーザーの 請求書 他のサービスの影響を受けにくい
18. - 複数サービスから利⽤する共有ライブラリの作成・保守は難しい - サービスごとに要求が少しだけ異なる場合がある - 変更すると複数のサービスに影響がある - 共有ライブラリのバージョニングやアップデートで悩みたくない - コードの重複を許容した - 例: > invoice/util/Mail.kt > network/util/Mail.kt > tenant/util/Mail.kt 共有ライブラリは作らず重複を許容する 他のサービスから独⽴して変更できる
19. Trace Contextを使ったサービス横断でのログ閲覧 Cloud LoggingでTrace ID (xxxxxx) を検索すると、サービス横断でログを閲覧できる フロントエンド BFF network Cloud Tasks invoice X-Cloud-Trace-Context: xxxxxx/0;o=1 X-Cloud-Trace-Context: xxxxxx/aaa X-Cloud-Trace-Context: xxxxxx/bbb X-Cloud-Trace-Context: xxxxxx/bbb
20. - 1つのリポジトリに複数サービスを含めるモノレポに変更 モノレポ化 invoice network tenant /invoice /network /tenant monorepo ※CI/CDが遅くなるのを避けるため、Cloud Buildのトリガーで「含まれるファイル」を指定し、 差分があったサービスのみをビルド・デプロイしているが、完璧ではない。 参考: https://orangain.hatenablog.com/entry/monorepo-ci-cd 全サービスをまとめて変更しやすい
21. まとめ
22. - サービス分割⽅針 - ある程度プロダクトの⽅向性が決まってきてから分割する - データの時系列が異なるところで分割する - ⼩さく分割しすぎない - サービスの独⽴性を重視する - なるべく開発・運⽤効率を落とさない 良かったこと
23. - 複数サービスに影響する機能を「運⽤でカバー」としてしまうと、運⽤が ⼤変 - invoice も肥⼤化しつつあるので、分割しても良かったかもしれない - 整合性が重要な機能ではサービス間で同期的な呼び出しを⾏なっており、 パフォーマンスや障害発⽣時の影響の⾯で考慮が必要 今後の課題
24. - 実践ドメイン駆動設計（ヴォーン・ヴァーノン 髙⽊ 正弘）｜翔泳社の本 https://www.shoeisha.co.jp/book/detail/9784798131610 - O'Reilly Japan - マイクロサービスアーキテクチャ https://www.oreilly.co.jp/books/9784873117607/ - マイクロサービスパターン 実践的システムデザインのためのコード解説 - イン プレスブックス https://book.impress.co.jp/books/1118101063 - Microservices architecture よろず本 その⼀＆その⼆ - ota42y – BOOTH https://booth.pm/ja/items/1316130 - O'Reilly Japan - 進化的アーキテクチャ https://www.oreilly.co.jp/books/9784873118567/ 参考⽂献
25. - 【東京】新プロダクト「Bill One」サービス開発エンジニア https://hrmos.co/pages/sansan/jobs/1000623 - 【関⻄】新プロダクト「Bill One」サービス開発エンジニア https://hrmos.co/pages/sansan/jobs/1000621 - 【福岡】新プロダクト「Bill One」サービス開発エンジニア https://hrmos.co/pages/sansan/jobs/1000632 We are hiring!