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

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

新規事業でもマイクロサービスに挑戦する / 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/

13d936e697fe0f4fa96f926d0a712f6c?s=128

Sansan
PRO

May 28, 2021
Tweet

Transcript

  1. None
  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!
  26. None