僕たちが「開発しやすさ」を求め模索し続けたアーキテクチャ #アーキテクチャ勉強会_findy

Slide 1

Slide 1 text

弁護士ドットコム株式会社開発本部クラウドサインReliability Engineering部 SREチーム上田璃空僕たちが「開発しやすさ」を求め模索し続けたアーキテクチャインフラアーキテクチャ選択のジレンマ　 5社の設計思想と意思決定のリアル 2025年8月7日

Slide 2

Slide 2 text

会社紹介

Slide 3

Slide 3 text

© 2025 Bengo4.com, inc. 3 VISION まだないやり方で、世界を前へ。 Drive a paradigm shift for the better world. MISSION ｢プロフェッショナル・テック｣で、次の常識をつくる。 Be the Professional-Tech Company. プロフェッショナルだからできること。専門知とテクノロジーで、社会に貢献する。

Slide 4

Slide 4 text

© 2025 Bengo4.com, inc. 4 4 税理士に無料で相談・検索できる日本最大級の税務相談ポータルサイト最新の法改正や実務について分かりやすく解説する日本最大級の企業法務ポータルサイトクラウドサインは、弁護士ドットコムが運営するサービスです OUR SERVICE AI基盤技術「 LegalBrain 1.0」を組み込んだリーガル特化型 AIエージェント契約の締結から管理までデジタルで完結させる契約マネジメントプラットフォーム日本最大級の無料法律相談ポータルサイト時事問題の弁護士解説を中心としたメディア弁護士事務所、企業法務職向け人材紹介事業

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

10年前の10月19日クラウドサインローンチ〜最小限の機能〜〈第一章〉

Slide 10

Slide 10 text

© 2025 Bengo4.com, inc. 全てはモノリスから始まった 10 クラウドサインローンチサービス開始時： ● EC2 上でモノリシックなアプリケーションだった ○ インフラは AWSマネージドサービスに任せ、アプリ開発に集中できる環境を重視コンテナ化するタイミング： ● アプリケーション実行基盤も AWSマネージドサービスを検討 ○ その際のコンテナオーケストレーションとして ECS を選択

Slide 11

Slide 11 text

© 2025 Bengo4.com, inc. 11 クラウドサインローンチなぜ EKS ではなく ECS だったのか僕たちのアプリケーション構成： ● EC2上のモノリス本体とワーカーやバッチで構成 ● それぞれが独立しており、サービス間での通信は不要だった検討結果： ● K8sが提供するサービスディスカバリ等の高度なネットワーク機能のメリットが極めて少ないと判断運用負荷の低い「 ECS on Fargate」を選択検討： ● コンテナオーケストレーションとしてk8sが流行っていた

Slide 12

Slide 12 text

Slide 13

Slide 13 text

成長したプロダクト〜機能追加の要求が急増〜〈第二章〉

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© 2025 Bengo4.com, inc. ＜アーキテクチャ選定における判断軸＞ 16 クラウドサインローンチプロダクトの成長 1. 全体の見通しの良さ開発者がシステム全体を把握できる状態を重視したかった 2. 開発体制ドメインや機能単位のチームではなく、開発組織全体で単一のロードマップを持って開発していた 3. 開発スタイルの踏襲しやすさ既存サービスの作りをテンプレートとして、新しいサービスを素早く開発・デプロイできるメリットがあった 4. 当時の共通コード共通コードはDBアクセス等のライブラリ群はあったが、大規模な共通モジュールは存在しなかった

Slide 17

Slide 17 text

Slide 18

Slide 18 text

さらに成長したプロダクト〜サービスの増殖〜〈第三章〉

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 2025 Bengo4.com, inc. 20 クラウドサインローンチプロダクトの成長さらにプロダクト成長〜現在＜僕たちのプロダクトの設計手法はどれ？＞僕たちのアーキテクチャ ● データ層：書類を中心とした単一データベース ● サービス層：機能単位でのRPCによる疎結合 ● 通信層：非同期キューイング中心の連携マイクロサービス各サービスが独自のデータベースを持った独立したサービス群のアーキテクチャモジュラーモノリス機能をモジュール単位で分離したアーキテクチャ

Slide 21

Slide 21 text

© 2025 Bengo4.com, inc. 21 クラウドサインローンチプロダクトの成長さらにプロダクト成長〜現在リリース当初： ● 見通しの良さがメリット ○ 多数のサービスを単一リポジトリで管理することで、全体を把握しやすかった成長によるサービスの増加： ● 副作用が生まれる ○ 依存関係が複雑化し意図せぬ影響範囲が読みにくくなる ○ CIが長時間化し開発のフィードバックサイクルが悪化する諸刃の剣となったモノレポジレンマ 1

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 2025 Bengo4.com, inc. クラウドサインローンチプロダクトの成長さらにプロダクト成長〜現在 ECS 環境ごとに別々のインフラストラクチャを用意する必要があったりする EKS EKSだとnamespaceや共有コンポーネントで ECSよりは作りやすい ② 環境を複製したい場合にそれなりに作り込みが必要 ECSの理想に沿いたい一方、現実の要件から独自の作り込みもしたくなるというジレンマ 24 ジレンマ 2 ECSの選択は正解だったが ... ECSは確かに便利だが故に融通がきかないこともある

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 2025 Bengo4.com, inc. 28 クラウドサインローンチプロダクトの成長さらにプロダクト成長〜現在守りの仕組みの重要性 1 . AWS のマネージドサービスを使って巨人の肩に乗る ○ CodeBuild・CodePipeline など 2 . Terraform での実装 ○ ECS のサービスの種類ごとにモジュールを実装し提供している 3 . Observability を Datadog に集約する ○ Datadog を見るだけでログ・SLO・APM 全てが見れる

Slide 29

Slide 29 text

© 2025 Bengo4.com, inc. 29 クラウドサインローンチプロダクトの成長さらにプロダクト成長〜現在守りの仕組みの重要性これらの “守り”の仕組みがなければ立ち行かなくなっていた 1 . AWS のマネージドサービスを使って巨人の肩に乗る ○ CodeBuild・CodePipeline など 2 . Terraform での実装 ○ ECS のサービスの種類ごとにモジュールを実装し提供している 3 . Observability を Datadog に集約する ○ Datadog を見るだけでログ・SLO・APM 全てが見れる

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 2025 Bengo4.com, inc. 31 クラウドサインローンチプロダクトの成長さらにプロダクト成長〜現在常に模索中ただ1つ言えることは開発者が開発・運用しやすいように模索すること ● もしかしたら今後 EKS にするかもしれないし、まだないやり方で課題を解決するかもしれない ● 増えすぎた小さいサービスを統合する必要がある（かもしれない） ○ Stepfunctions を導入したりしている