Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

4年で17倍に成長したエンジニア組織を支えるアーキテクチャの過去と未来

SansanTech
November 25, 2024

 4年で17倍に成長したエンジニア組織を支えるアーキテクチャの過去と未来

■ イベント
アーキテクチャConference 2024
https://architecture-con.findy-tools.io/

■ 発表者
技術本部 Bill One Engineering Unit
加藤 耕太 / 柳浦 豊

■ Bill Oneエンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

■ Sansan Tech Blog
https://buildersbox.corp-sansan.com/

SansanTech

November 25, 2024
Tweet

More Decks by SansanTech

Other Decks in Technology

Transcript

  1. 写真が入ります 加藤 耕太(Kota Kato) Sansan株式会社 技術本部 Bill One Engineering Unit@関⻄⽀店

    Sansan株式会社所属のソフトウェアエンジニア。 インボイス管理サービス「Bill One」のアーキテク トとして、技術選定から⽴ち上げに関わり、現在に ⾄るまで開発および技術マネジメントに従事。 趣味: 散歩、ゲーム、美術館
  2. 4年間でのエンジニア組織の成⻑ 83 名 5 名 20 チーム 1 チーム 2020年9⽉

    2024年9⽉ 海外拠点 Sansan Global Development Center, Inc. (フィリピン) 約 50 名
  3. アーキテクチャ Email Cloud Load Balancing Backend Cloud Run Database Cloud

    SQL Static Files Cloud Storage Cloud Tasks API Gateway Cloud Load Balancing API Client User Logging Error Reporting Cloud Build Bill One Entry Management / Developer Tools Cloud Functions Monitoring Authentication Auth0 Login Screen Frontend / BFF Cloud Run Pub/Sub
  4. - 主要マイクロサービスは業務ドメインで分割する - 細かい機能単位のマイクロサービスもある - マイクロサービスごとにデータベースを分ける - 主要マイクロサービスはなるべく同期的なAPI呼び出しを避け、 ⾮同期通信での連携を基本とする -

    フロントエンドからは、BFF (API Gatewayのようなもの) を経由して アクセスする - サービスごとの独⾃性と全体としての統⼀感のバランスをとる マイクロサービスの⽅針
  5. - Kotlin - 主要なマイクロサービス - Go - 起動速度が重要なマイクロサービス - Go周辺で発達したエコシステムを活⽤したいマイクロサービス

    - 細かい機能単位のマイクロサービス - (TypeScript) - フロントエンド、BFF - Node.js周辺で発達したエコシステムを活⽤したいマイクロサービス マイクロサービスの言語
  6. 複数のサービスのソースコードを1リポジトリで管理するMonorepo構成を採⽤している Monorepoのメリット - CI/CDの仕組みを統⼀して管理しやすい - 複数のマイクロサービスにまたがる変更が容易 MonorepoのCI/CD - GitHub Actionsの

    dorny/paths-filter を使って、差分があるサービスのみ CI/CD を実⾏ - ディレクトリに配置された特定のファイルでマイクロサービスを発⾒し、filter を⾃動⽣成する - 差分がなくても再実⾏できるよう、manual triggerを組み合わせると便利 Monorepo
  7. 当初 - 共通ライブラリを作らず、サービス間でのコピペを許容する⽅針だった - 不要な結合を排除し、サービスごとの独⽴性を重視するため 現在 - 1年前に共通ライブラリを導⼊ - データベース周り、Webフレームワーク周り、その他ユーティリティなど、共通で

    使いたいものが固まってきたので - ソースコードレベルでは結合せず、Gradleなどのライブラリとして利⽤ - ライブラリの変更を受け⼊れるタイミングをサービス側で制御できるように 共通ライブラリ
  8. トラフィック増加への対応 - ⼀番の主要機能である請求書 受領を担当するマイクロ サービスへのアクセスが多い - 当該マイクロサービスの データベースインスタンスの スケールアップが限界に近づ いている

    - クエリのパフォーマンスチ ューニングなど、負荷を減 らすための改善は実施 している - 今後は、より抜本的な改善 施策が必要 現状 対応
  9. 写真が入ります 柳浦 豊 Sansan 株式会社 技術本部 Bill One Engineering Unit

    Core Business AR グループ アーキテクト 2022年に Sansanに中途⼊社し、⼊社以来 Webアプリケ ーション開発エンジニアとして Bill Oneの開発に従事して います。 マイクロサービスや CI/CDに興味・関⼼があります。 キーボード沼にハマりつつあります。 29
  10. - 潜在市場規模としては⼤きな余地がある - 現在の有料契約件数は3000件超 - 請求書受領を⾜がかりにして契約件数をさらに伸ばしていく ビジネスの状況 「Bill One」潜在市場規模 (1)「令和3年経済センサス活動調査」総務省統計局

    (2) 有料契約件数+無料件数+有料・無料ユーザーに対して請求書を送付する企業数 「Bill One」 有料契約件数 インボイスネットワーク参画企業数 (2) 請求書発行企業 / 「Bill One」 ユーザー企業 3,033 約 200万 「Bill One」潜在市場規模 (日本国内の企業数 (1)) 約 19.3万
  11. - ⽇本国内 - Bill Oneエンジニア:約80名 - 海外拠点 - 2023年、フィリピン・セブ島にSGDC (Sansan

    Global Development Center, Inc) を設⽴ - Bill Oneエンジニア:約50名 - 国内・海外ともに採⽤活動を積極的に展 開中 - 今後もエンジニアは継続的に増やしてい きたい 開発組織の状況:規模をさらに拡⼤しグローバルな組織へ SGDCのオフィス
  12. これまでのアーキテクチャを振り返る ビジネス 組織 技術 Good 受領を中⼼に契約を伸ばして いる。受領だけでなく、発⾏、 経費精算の業務領域にも広げ られている 国内外合わせた130名体制まで

    はスケールし、⾃律したチーム を形成できている マイクロサービスアーキテクチャ を採⽤することで、ビジネス規模 と領域の拡⼤に適応できている More 業務領域それぞれで今以上に 顧客獲得するために、顧客価 値提供を加速していく必要が ある 開発メンバーとチームが増える 中で、保守性を維持するための 設計⽅針・設計ガイドが浸透し にくくなっている サービス品質とサービス肥⼤化と いう2つの課題を切り⼝に、アーキ テクチャを⾒直したい
  13. - 「予測しない=受け⾝」ではない - 変化に反応し続けるだけでは、つぎはぎされた複雑な設計となり、 開発速度は緩やかに劣化していく - 変化そのものは予測できなくとも、「変化をどう受け⼊れるか」は 意図的に制御できるのではないか - 意図=何を柔軟にして何を不変にするか

    - システムの将来の「形」は柔軟に変えていきたいが、重要なシステムの「性質」 は維持し続けたい - KotlinやCloud Runという「形」は、重要な「品質特性」を満たす限りは 柔軟に変えてもよい 変化を受け⼊れ適応するためのアーキテクチャ設計 システムが継続的に満たすべき品質特性をアーキテクチャに組み込む
  14. - 進化的アーキテクチャ - ビジネスや技術の絶え間ない変化に応じられるよう、変化を⽀える仕組みを 組み込んだアーキテクチャ - 「漸進的な変更」「適応度関数」「適切な結合」の3つの側⾯ - アーキテクチャ適応度関数 -

    対象システムが「望ましい特性」をどの程度満たしているかを客観的 あるいは主観的に評価する - アーキテクチャの品質特性 - さまざまな特性ʼ-ilitiesʼがアーキテクチャには求められる - 例: modifiability,observability, agility, accessibility, … - 特性の多くはトレードオフの関係にあり、すべてを最⼤化することは難しい 進化的アーキテクチャと適応度関数
  15. Bill One アーキテクチャ システムの 変更 Pull Request - システムのデプロイメントパイプラインに適応度関数を組み込む -

    -ilityを劣化させる「望ましくない変化」からシステムを保護できる - 適応度関数を通じて、システムの変化の⽅向性に アーキテクトの意図を持たせることができる 適応度関数をデプロイメントパイプラインに組み込む -ilities 適応度関数
  16. - Being(どうあり続けたいか) - ビジネス要求に迅速に応えられるアーキテクチャであり続けたい - サイクルタイムに影響する品質特性を重視する - 保守性 - 劣化すると変更が困難になり、開発速度が低下する

    - テスト容易性 - 劣化するとリファクタリングが困難になり、保守性が劣化する - 疎結合性 - 劣化すると変更の影響範囲が広がることで複数チームでの調整が必要になり、 開発速度が低下する ⽬指すBeingとアーキテクチャの品質特性
  17. - 現状 - コントローラ/アプリケーション/ドメイン/インフラの4層における責務 と依存の⽅向性を開発⽅針として定義することで、保守性を担保している - 課題 - 開発初期は⽅針が浸透していたことで遵守できていたが、開発者組織の規模 拡⼤に伴い、守れていないケースが増えてきた

    - ⽅針の浸透不⾜により、保守性が劣化しつつある - 適応度関数 - 依存関係チェックをビルドプロセスに統合し、違反をビルド時に検出 - Kotlinの静的解析ツール Detektのカスタムルールで独⾃のimportルールを チェックするプラグインを実装 事例1: レイヤ依存のルールがすべてのサービスで維持されるようにする
  18. - 現状 - 統合テストを重視し、モックを極⼒使わず すべてのレイヤを結合し、より多くの プロダクションコードをテストしている - 統合テストと単体テストのコード⾏数の⽐率は2 : 1

    - 課題 - 統合テストに偏り過ぎており、 テストコードの実装と保守が⾼コスト化 - 適応度関数 - レイヤごとに異なるテストカバレッジ基準値を適⽤ - コントローラレイヤ:統合テスト中⼼。ハッピー パスを通す程度のカバレッジ基準値 - ドメインレイヤ:単体テストで⾼いカバレッジ 基準値 事例2: テストピラミッドの⽐重を最適化する 統合テスト 単体テスト ハッピーパス中⼼に広 く結合するテスト E2E 統合テスト 単体テスト ドメインロジックや 複雑なロジックをテスト E2E 参考:Vladimir Khorikov, 須⽥智之『単体テストの考え⽅/使い⽅』, マイナビ出版
  19. - ゆらぎ - 機能追加と技術的負債返済の適切なバランスは、事業領域の状況によって 異なってよい。すべてのマイクロサービスが同じバランスである必要はない - ゆだね - マイクロサービスチームが⾃律的に意思決定できるよう技術⽅針を定めつつも、⽅ 針外の意思決定はチームに任せている

    - 周りに相談しつつも最後は⾃分で決める組織⽂化がある - ゆとり - ⽇々の開発の過程での学びをみんなと共有するラーニングセッション - ⾃分で改善したいことを決めて取り組むエンハンスウィーク Bill Oneにとって、マイクロサービスアーキテクチャはチームが オーナーシップを持って⾃律的に活動するためにこれからも重要 Bill Oneにおける、ゆらぎ・ゆだね・ゆとり
  20. - Bill Oneアーキテクチャのこれまで - ビジネスが成⻑している - 開発組織も成⻑している - マイクロサービスの取り組みによって開発速度を維持してきた -

    しかし技術的課題はある - Bill Oneアーキテクチャのこれから - ⽬指すのはビジネスの変化に対して継続的に素早く適応できるアーキテクチャ - 変化を柔軟に受け⼊れつつも、望ましい状態を維持できる仕組みをアーキテク チャに組み込んでいく まとめ