AWS歴６年のSaaS企業が直面する低凝集マイクロサービスの課題とその解決アプローチ

2024/9/27に以下のイベントで登壇
AWS SaaS Builders Forum - Tech Leaders Meetup
https://aws-startup-lofts.com/apj/loft/tokyo/event/780ebde9-d212-43fa-a2d5-56fb453e91c9

Transcript

1. AWS歴6年のSaaS企業が直⾯する低凝集マイクロサービスの課題とその解決アプローチ 2024/9/27 エムオーテックス株式会社 桑名 翔
2. 2 ⾃⼰紹介 名前︓桑名 翔 (くわな しょう) 現在︓エムオーテックス株式会社 2018年⼊社 LANSCOPE エンドポイントマネージャー クラウド版 開発チーム AWS歴︓約6年
3. 3 会社紹介 私たちは企業の資産である「情報」を守り IT環境における安全･⽣産性を追求することで 社会の進歩発展に貢献します。 ⼤阪に本社を置く、ソフトウェアメーカーです︕
4. 4 プロダクト紹介
5. 5 アーキテクチャの概略図 • ざっくりと、図のような形でマイクロサービス群が構成されています。フロントエンドがひとつ、数⼗の バックエンドサービスが基本的にサーバーレスアーキテクチャで稼働しています。 フロントエンド TypeScript Scala バックエンド クライアントアプリ Android (Java & Kotlin) iOS (Swift) macOS (Swift) Windows (Delphi & C#) Scala Node.js Scala Scala C# Scala Python • バックエンドはドメインごとに独⽴したサービスが構築されています。各サービス間の情報連携はイベン トバスを挟むことによって⾮同期的に⾏われています。 マイクロサービス マイクロサービス ※メインは Scala、⼀部 C# や Python または Node.js があります。
6. 6 アーキテクチャの概略図 • API Gateway + Lambda + DynamoDB の構成が基本で、要件によって他サービスを採⽤し構成が複雑 になります。フロント向け API サーバーとして EC2 を利⽤しているサービスなどもあります。 • サービス間の情報連携はイベントバス (pub-sub モデル) 経由で⾮同期的に連携しています。 • 他のサービスが持つ情報が欲しい場合は、イベントバス経由で連携された情報を永続化する⽅法（コピー を持つ⽅法）と、直接データベースにアクセスする⽅法などがあります。 バックエンド eventbus eventbus サービスA サービスB サービスC eventbus サービスD 直接 DB 参照 Lambda to Lambda で情報取得 サービスB からイベントバス経由で連携さ れた情報を永続化する(コピーを持つ) ⾮同期で情報連携 コスト削減のため、サービスA,B の情報も格納していることも
7. 7 課題に⾄った背景 • チーム体制の変化 • オンプレミス版のPC管理機能を統合し、プロダクト価値を拡⼤するために新規メ ンバーが多数参画 • 特定のコンテキストを担当するチーム体制から管理対象のOS単位のチーム体制へ • 知識不⾜ • 新規参画者のDDDやマイクロサービスに関する知識が不⾜ 資産チーム クライアント チーム 設定チーム Android チーム iOSチーム PCチーム ...etc ...etc
8. 8 低凝集なマイクロサービスにおける課題 • サービスの過剰な分割と密結合 • 変更容易性の低下 • 開発チームの担当領域の重複 • 各OS単位の新機能追加時に担当する領域が重複し、予期せぬ結果を招く可能性 • 管理対象のOS単位に分散した処理と⼀貫性のないユーザー体験 • 各OS向けの機能が分散しており、ユーザー体験が⼀貫していない LANSCOPE 管理画⾯ お客様 資産情報取得設定 位置情報取得設定 MDM操作ログ取得設定 PC操作ログ取得設定 同じ操作ログ取得の 設定なのにOSによって 動線が異なる
9. 9 どうアクションしてけばいいかわからない 全体的なリアーキテクチャに関しては、アクションが必要という雰囲気をみんな感じてはいるものの、 以下のような理由から、中々⼿をつけられずにいた。 ・かかる⼯数が⾒えない ・⼤規模なリファクタをするしかないと考えると莫⼤な⼯数がかかりそうという不安感 ・⾃分たちだけで適切なサービス分割をする⾃信がない ・1stアクションの掛け⽅がわからない ... etc AWSさん 良かったら相談乗りましょうか︖
10. 10 AWSさんに相談 AWSのSAさんも交えて、我々の感じている課題感を聞いてもらったところ、現状整理のためにも 業務分析をしてコンテキストマップを作り直してみるのはどうかと助⾔をいただいた 1stアクションとしてイベントストーミングを実施してみることに
11. 11 イベントストーミングを実施 3⽇間かけて20⼈くらいで⽸詰状態で実施
12. 12 イベントストーミングを経て • イベントストーミングの進め⽅を理解した • 今回は⼀部機能について実施したので、今後残りの部分についても⾃分たちで実施できる状態になった • ユビキタス⾔語を整理できた • 今回実施した範囲において、管理対象OSごとの処理をクライアント側に集約できる可能性が⾒つかった • PoCチームを1つ作り、⾒つかったドメインモデルへの置き換え可能性の検証を開始 PoCチームで ここを作って みることに
13. 13 • 原理原則を⽬指すことの難しさ • PoCでは、出来るだけDDDの原理原則に基づいて設計・実装を進めていたが、学習コストの⾼さが想 定以上に⼤きかった • ⼯数が膨⼤になりそうなことがわかった • 設定の項⽬数が多すぎる • 新しく⾒つかったドメインモデルで既存の機能を実現するのが難しい • 運⽤ができない • 必要な⼈数の確保が難しい • 今後実現したい価値とのギャップ • ビジネスサイドとの認識のずれ • 求められることは⽣産性の向上 • 費⽤対効果の観点 PoCチームで2ヶ⽉間⾛ってみて デバイス設定 資産情報 デバイス制御 ...etc OS単位の 差異はない Android クライアント iOS クライアント Windows クライアント macOS クライアント ⽬指してた姿
14. 14 • ビジネスサイドとも会話をしながら、まずは少し先の未来をよくするためにやるべきことを考え直した • ⽣産性の向上 • 機能開発時の担当領域の重複排除 • 変更容易性の向上 PoCチームで2ヶ⽉間⾛ってみて MDMチーム ・MDM関連機能 基盤機能チーム ・認証機能 ・資産機能 ...etc PCチーム ・PC関連機能 現在はそれぞれについて ⼩さく始めて効果の検証中 • 責任範囲の明確化 • 明確に各チームで持ち物を分担することで、開発時の担当領域の重複を排除 • 担当領域を明確にすることで認知不可を低減 • チーム内でのコンテキストの再定義とサービスの統合 • 過剰に分割されたサービスを統合することで変更容易性を向上 まずは責任範囲を 明確に