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

2025年8月7日(木)開催、「インフラアーキテクチャ選択のジレンマ」で登壇した、弁護士ドットコム株式会社 クラウドサイン SRE の　上田 璃空が登壇した際の資料です。

インフラアーキテクチャ選択のジレンマ
https://findy-tools.connpass.com/event/362401/

セッションタイトル： 僕たちが「開発しやすさ」を求め 模索し続けたアーキテクチャ

■ 弁護士ドットコム株式会社プロダクト組織について
https://speakerdeck.com/bengo4com/introduction-for-creators

■ 採用情報はこちら
https://hrmos.co/pages/bengo4/jobs

■ テックブログ：弁護士ドットコム Creators’ blog
https://creators.bengo4.com/

■ X(Twitter)：弁護士ドットコム CREATOR'S
https://x.com/bengo4_creators

Transcript

1. 弁護士ドットコム株式会社 開発本部 クラウドサインReliability Engineering部 SREチーム 上田 璃空 僕たちが「開発しやすさ」を求め 模索し続けたアーキテクチャ インフラアーキテクチャ選択のジレンマ　 5社の設計思想と意思決定のリアル 2025年8月7日
2. 会社紹介
3. © 2025 Bengo4.com, inc. 3 VISION まだないやり方で、世界を前へ。 Drive a paradigm shift for the better world. MISSION ｢プロフェッショナル・テック ｣で、 次の常識をつくる。 Be the Professional-Tech Company. プロフェッショナルだからできること。 専門知とテクノロジーで、社会に貢献する。
4. © 2025 Bengo4.com, inc. 4 4 税理士に無料で相談・検索できる日本最大級の 税務相談ポータルサイト 最新の法改正や実務について分かりやすく解説する 日本最大級の企業法務ポータルサイト クラウドサイン は、弁護士ドットコム が運営するサービスです OUR SERVICE AI基盤技術「 LegalBrain 1.0」を組み込んだ リーガル特化型 AIエージェント 契約の締結から管理までデジタルで完結させる 契約マネジメントプラットフォーム 日本最大級の無料法律相談ポータルサイト 時事問題の弁護士解説を中心としたメディア 弁護士事務所、企業法務職向け人材紹介事業
5. © 2025 Bengo4.com, inc. 自己紹介 5 上田璃空 開発本部 クラウドサイン Reliability Engineering部 SREチーム 新卒でインフラエンジニアとしてデプロイの自動化やアプリ ケーションの開発に従事。 2022年10月弁護士ドットコム株 式会社入社。 現在はDWHの運用やStepfunctionsでの開発を担当。 特技は散財。
6. © 2025 Bengo4.com, inc. 理想と現実 6 世間では疎結合やサービス分割が叫ばれるが現実は難しい 。
7. © 2025 Bengo4.com, inc. あらすじ 7 ユーザー価値提供 に集中した結果、 どんな ジレンマ に陥ったか、そのリアルをお話しします。 僕たちの思想はインフラもアプリも、 開発者が 開発・運用しやすいように 作ること。
8. © 2025 Bengo4.com, inc. 結論 8 常に悩み、模索し続けること こそが、 リアルなアーキテクチャ である
9. 10年前の10月19日 クラウドサインローンチ 〜 最小限の機能 〜 〈 第一章 〉
10. © 2025 Bengo4.com, inc. 全てはモノリスから始まった 10 クラウドサイン ローンチ サービス開始時： • EC2 上でモノリシックなアプリケーションだった ◦ インフラは AWSマネージドサービスに任せ、アプリ開発に 集中できる環境を重視 コンテナ化するタイミング： • アプリケーション実行基盤も AWSマネージドサービスを検討 ◦ その際のコンテナオーケストレーションとして ECS を選択
11. © 2025 Bengo4.com, inc. 11 クラウドサイン ローンチ なぜ EKS ではなく ECS だったのか 僕たちのアプリケーション構成： • EC2上のモノリス本体とワーカーやバッチで構成 • それぞれが独立しており、サービス間での通信は不要 だった 検討結果： • K8sが提供するサービスディスカバリ等の 高度なネットワーク機能のメリットが極めて少ないと判断 運用負荷の低い「 ECS on Fargate」を選択 検討： • コンテナオーケストレーションとしてk8sが流行っていた
12. © 2025 Bengo4.com, inc. 当時の我々にとって、 まさに開発者が開発・運用しやすい 大正解な選択だった。 12 クラウドサイン ローンチ • 開発速度が向上 • インフラをあまり意識することなく、 アプリケーション 開発に集中できた 当時は、大正解だった
13. 成長したプロダクト 〜 機能追加の要求が急増 〜 〈 第二章 〉
14. © 2025 Bengo4.com, inc. 14 クラウドサイン ローンチ プロダクトの成長 事業が順調に成長し、 機能追加の要求が急増 たくさんの機能をリリースする必要が出てきた
15. © 2025 Bengo4.com, inc. 15 クラウドサイン ローンチ プロダクトの成長 1. 安定性の確保 状況の変化に応じて、下記の要件の重要性が増した ため、 アーキテクチャの再検討をおこなった 2. 開発スピード サービスの根幹である 書類の送受信（署名）という コア機能には 極力影響を与えない 新機能を 小さく・早く 追加することができる アーキテクチャの再検討
16. © 2025 Bengo4.com, inc. ＜ アーキテクチャ選定における判断軸 ＞ 16 クラウドサイン ローンチ プロダクトの成長 1. 全体の見通しの良さ 開発者がシステム全体を把握できる状態を重視したかった 2. 開発体制 ドメインや機能単位のチームではなく、開発組織全体で単一のロードマップを 持って開発していた 3. 開発スタイルの踏襲しやすさ 既存サービスの作りをテンプレートとして、新しいサービスを素早く開発・ デプロイできるメリットがあった 4. 当時の共通コード 共通コードはDBアクセス等のライブラリ群はあったが、大規模な共通モジュールは 存在しなかった
17. © 2025 Bengo4.com, inc. 17 クラウドサイン ローンチ プロダクトの成長 アーキテクチャを再検討した結果 モノレポ・単一 DBのままで 複数サービスを抱える という アーキテクチャを選んだ
18. さらに成長したプロダクト 〜 サービスの増殖 〜 〈 第三章 〉
19. © 2025 Bengo4.com, inc. 19 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 • 開発のしやすさとは裏腹に 運用管理コストが増大してきた • 「既存のインフラ構成を踏襲する」というスタイルを続けた結果 ECSサービスが増殖 • 結果として、マイクロサービスより小さいサービス （独自のDBを持たず関数程度の規模のサービス）が増加 細かいサービスがどんどん増えてきた
20. © 2025 Bengo4.com, inc. 20 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 ＜ 僕たちのプロダクトの設計手法はどれ？ ＞ 僕たちのアーキテクチャ • データ層： 書類を中心とした単一データベース • サービス層： 機能単位でのRPCによる疎結合 • 通信層： 非同期キューイング中心 の連携 マイクロサービス 各サービスが独自のデータベースを 持った独立したサービス群のアーキ テクチャ モジュラーモノリス 機能をモジュール単位で分離した アーキテクチャ
21. © 2025 Bengo4.com, inc. 21 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 リリース当初： • 見通しの良さがメリット ◦ 多数のサービスを単一リポジトリで管理することで、 全体を把握しやすかった 成長によるサービスの増加： • 副作用が生まれる ◦ 依存関係が複雑化し意図せぬ影響範囲が読みにくくなる ◦ CIが長時間化し開発のフィードバックサイクルが悪化する 諸刃の剣となったモノレポ ジレンマ 1
22. © 2025 Bengo4.com, inc. 22 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 全体把握が困難に なり、かえって開 発体験を損なう懸念 も デメリット リポジトリを分けるべきか このまま モノレポを続けるか 、意を決して 分割するか のジレンマ 諸刃の剣となったモノレポ ジレンマ 1 開発範囲が狭まりCIも高速化。 開発に集中しやすく なる メリット
23. © 2025 Bengo4.com, inc. 23 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 ① 複数バッチを組み合わせたいときに辛い ECS バッチの依存関係を 自分で管理 したり 全体の状況判断が難しい EKS jobリソースやworkflowで 簡単に管理できる ジレンマ 2 ECSの選択は正解だったが ... ECSは確かに便利だが故に融通がきかないこともある
24. © 2025 Bengo4.com, inc. クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 ECS 環境ごとに別々の インフラストラクチャ を 用意する必要があったりする EKS EKSだとnamespaceや 共有コンポーネントで ECSよりは作りやすい ② 環境を複製したい場合にそれなりに作り込みが必要 ECSの理想に沿いたい 一方、 現実の要件から独自の作り込みもしたくなる というジレンマ 24 ジレンマ 2 ECSの選択は正解だったが ... ECSは確かに便利だが故に融通がきかないこともある
25. © 2025 Bengo4.com, inc. とは言っても 悪いことばかりではない
26. © 2025 Bengo4.com, inc. 26 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 • サービス開始時は マイクロサービスがいいかどうかを判断できる状態ではなかった • ビジネスの成長に合わせ、アーキテクチャは 意図せず進化（複雑化）した 僕らの現在地
27. © 2025 Bengo4.com, inc. 27 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 • サービス開始時は マイクロサービスがいいかどうかを判断できる状態ではなかった • ビジネスの成長に合わせ、アーキテクチャは 意図せず進化（複雑化）した 僕らの現在地 理想から設計したのではなく 現実に1つずつ対応した結果が 今である
28. © 2025 Bengo4.com, inc. 28 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 守りの仕組みの重要性 1 . AWS のマネージドサービスを使って巨人の肩に乗る ◦ CodeBuild・CodePipeline など 2 . Terraform での実装 ◦ ECS のサービスの種類ごとにモジュールを実装し提供している 3 . Observability を Datadog に集約する ◦ Datadog を見るだけで ログ・SLO・APM 全てが見れる
29. © 2025 Bengo4.com, inc. 29 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 守りの仕組みの重要性 これらの “守り”の仕組みがなければ 立ち行かなくなっていた 1 . AWS のマネージドサービスを使って巨人の肩に乗る ◦ Codebuild・CodePipeline など 2 . Terraform での実装 ◦ ECS のサービスの種類ごとにモジュールを実装し提供している 3 . Observability を Datadog に集約する ◦ Datadog を見るだけで ログ・SLO・APM 全てが見れる
30. © 2025 Bengo4.com, inc. 30 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 • 増えすぎた小さいサービスを統合する必要がある （かもしれない） ◦ Stepfunctions を導入したりしている • もしかしたら今後 EKS にするかも しれないし、まだないやり方で 課題を解決するかもしれない 常に模索中
31. © 2025 Bengo4.com, inc. 31 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト成 長〜現在 常に模索中 ただ1つ言えることは 開発者が 開発・運用しやすいように模索すること • もしかしたら今後 EKS にするかも しれないし、まだないやり方で 課題を解決するかもしれない • 増えすぎた小さいサービスを統合する必要がある （かもしれない） ◦ Stepfunctions を導入したりしている
32. まとめ
33. © 2025 Bengo4.com, inc. 33 まとめ 「開発しやすさ」 を求めた結果の アーキテクチャのジレンマ について話した 理想を定義して問題に立ち向かう アーキテクチャもあるし 目の前の課題を解決していくことでたどり着く アーキテクチャもある
34. © 2025 Bengo4.com, inc. 34 まとめ 事業フェーズや組織の現実と向き合い、 常に悩み、模索し続けること こそが、 リアルなアーキテクチャ ではないだろうか
35. © 2025 Bengo4.com, inc. 35 We are Hiring
36. © 2025 Bengo4.com, inc. 36