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

© 2025 Bengo4.com, inc. 自己紹介 5 上田璃空 開発本部 クラウドサイン Reliability Engineering部 SREチーム 新卒でインフラエンジニアとしてデプロイの自動化やアプリ ケーションの開発に従事。 2022年10月弁護士ドットコム株 式会社入社。 現在はDWHの運用やStepfunctionsでの開発を担当。 特技は散財。

Slide 6

Slide 6 text

© 2025 Bengo4.com, inc. 理想と現実 6 世間では疎結合やサービス分割が叫ばれるが現実は難しい 。

Slide 7

Slide 7 text

© 2025 Bengo4.com, inc. あらすじ 7 ユーザー価値提供 に集中した結果、 どんな ジレンマ に陥ったか、そのリアルをお話しします。 僕たちの思想はインフラもアプリも、 開発者が 開発・運用しやすいように 作ること。

Slide 8

Slide 8 text

© 2025 Bengo4.com, inc. 結論 8 常に悩み、模索し続けること こそが、 リアルなアーキテクチャ である

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

© 2025 Bengo4.com, inc. 当時の我々にとって、 まさに開発者が開発・運用しやすい 大正解な選択だった。 12 クラウドサイン ローンチ ● 開発速度が向上 ● インフラをあまり意識することなく、 アプリケーション 開発に集中できた 当時は、大正解だった

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

© 2025 Bengo4.com, inc. 14 クラウドサイン ローンチ プロダクトの成長 事業が順調に成長し、 機能追加の要求が急増 たくさんの機能をリリースする必要が出てきた

Slide 15

Slide 15 text

© 2025 Bengo4.com, inc. 15 クラウドサイン ローンチ プロダクトの成長 1. 安定性の確保 状況の変化に応じて、下記の要件の重要性が増した ため、 アーキテクチャの再検討をおこなった 2. 開発スピード サービスの根幹である 書類の送受信(署名)という コア機能には 極力影響を与えない 新機能を 小さく・早く 追加することができる アーキテクチャの再検討

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

© 2025 Bengo4.com, inc. 17 クラウドサイン ローンチ プロダクトの成長 アーキテクチャを再検討した結果 モノレポ・単一 DBのままで 複数サービスを抱える という アーキテクチャを選んだ

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

© 2025 Bengo4.com, inc. 19 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト 成長〜現在 ● 開発のしやすさとは裏腹に 運用管理コストが増大してきた ● 「既存のインフラ構成を踏襲する」というスタイルを続けた結果 ECSサービスが増殖 ● 結果として、マイクロサービスより小さいサービス (独自のDBを持たず関数程度の規模のサービス)が増加 細かいサービスがどんどん増えてきた

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

© 2025 Bengo4.com, inc. 22 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト 成長〜現在 全体把握が困難に なり、かえって開 発体験を損なう懸念 も デメリット リポジトリを分けるべきか このまま モノレポを続けるか 、意を決して 分割するか のジレンマ 諸刃の剣となったモノレポ ジレンマ 1 開発範囲が狭まりCIも高速化。 開発に集中しやすく なる メリット

Slide 23

Slide 23 text

© 2025 Bengo4.com, inc. 23 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト 成長〜現在 ① 複数バッチを組み合わせたいときに辛い ECS バッチの依存関係を 自分で管理 したり 全体の状況判断が難しい EKS jobリソースやworkflowで 簡単に管理できる ジレンマ 2 ECSの選択は正解だったが ... ECSは確かに便利だが故に融通がきかないこともある

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

© 2025 Bengo4.com, inc. とは言っても 悪いことばかりではない

Slide 26

Slide 26 text

© 2025 Bengo4.com, inc. 26 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト 成長〜現在 ● サービス開始時は マイクロサービスがいいかどうかを判断できる状態ではなかった ● ビジネスの成長に合わせ、アーキテクチャは 意図せず進化(複雑化)した 僕らの現在地

Slide 27

Slide 27 text

© 2025 Bengo4.com, inc. 27 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト 成長〜現在 ● サービス開始時は マイクロサービスがいいかどうかを判断できる状態ではなかった ● ビジネスの成長に合わせ、アーキテクチャは 意図せず進化(複雑化)した 僕らの現在地 理想から設計したのではなく 現実に1つずつ対応した結果が 今である

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

© 2025 Bengo4.com, inc. 30 クラウドサイン ローンチ プロダクトの成長 さらにプロダクト 成長〜現在 ● 増えすぎた小さいサービスを統合する必要がある (かもしれない) ○ Stepfunctions を導入したりしている ● もしかしたら今後 EKS にするかも しれないし、まだないやり方で 課題を解決するかもしれない 常に模索中

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

まとめ

Slide 33

Slide 33 text

© 2025 Bengo4.com, inc. 33 まとめ 「開発しやすさ」 を求めた結果の アーキテクチャのジレンマ について話した 理想を定義して問題に立ち向かう アーキテクチャもあるし 目の前の課題を解決していくことでたどり着く アーキテクチャもある

Slide 34

Slide 34 text

© 2025 Bengo4.com, inc. 34 まとめ 事業フェーズや組織の現実と向き合い、 常に悩み、模索し続けること こそが、 リアルなアーキテクチャ ではないだろうか

Slide 35

Slide 35 text

© 2025 Bengo4.com, inc. 35 We are Hiring

Slide 36

Slide 36 text

© 2025 Bengo4.com, inc. 36