[セッションレポート] 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（AWS-57） #AWSSummit

AWS Summit Japan 2024

#マイクロサービス

#AWS

いわさ

2024.6.24

いわさです。

本記事は 2024 年 6 月 20 - 21 日の 2 日間開催された AWS Summit Japan 2024 のセッションレポートとなります。
このセッション、個人的に大変興味があったものの当日は GameDay に参加しており現地で聴講することが出来ませんでした。
しかしすぐにオンデマンド配信がされているではありませんか。やったぜ。

オンデマンド配信の動画リンクと資料のダウンロードは以下です。動画の視聴と資料のダウンロードには AWS Summit Japan のマイページのログインが必要です。

概要

6/21(金) 14:50 - 15:30
セッションタイトル：「規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（AWS-57）」

フレームワークを活用した典型的なWeb三層のアプリケーションで開発をスタートし、最初はスピード感のある開発が行えていたのに、徐々に機能が追加されていき、気がつくと様々な機能が密結合になり、単一のデータベースを様々な機能が利用していて、変更の影響がどこにあるか分かり難くなってきます。次第に機能追加に時間がかかるようになり、古いコードを変更することが怖くなり、元のコードを残したまま、コードを追加するようになって益々複雑化していきます。このような状況を改善するためには適切な粒度でサービスを切り出して置き換えていくことが必要です。では、どのようにすれば正しい粒度でサービスを分割ができるでしょうか。本セッションでは DDDをベースとしてEvent Storming を活用した境界づけられたコンテキストの発見による具体的なサービスの分割方法をご紹介します。

スピーカー

福井厚
アマゾンウェブサービスジャパン合同会社プロトタイプ＆カスタマーエンジニアリング本部 Developerスペシャリストソリューションアーキテクト

レベル

Level 400: 上級者向け

アジェンダ

なぜリアーキテクチャが必要になるのか？
どうやってサービスを分割するのか
ドメイン駆動設計とイベントストーミングによる分割
非機能要件を論理アーキテクチャにマッピング
ドメインモデルをインフラストラクチャコードから分離

セッションレポート

ちなみにこのセッションはほとんど AWS の話出てこないです。最後に API Gateway - Lambda - DynamoDB の場合にクリーンアーキテクチャを当てはめるところで例で出てくるくらいでしょうか。
実際にマイクロサービス化を進めるにあたっては AWS サービス云々よりも前段階が非常に難しくそこで失敗することが多いのでは、むしろ非 AWS 領域にフォーカスしたこのセッション内容は多くの方が聞きたいことなのではないでしょうか。

前半

冒頭でまず以下の流れでマイクロサービス化の必要性についておさらいしています。

よくある Web 三層アーキテクチャ・モノリスの強み
- 小規模な開発では、フレームワークの機能によってシンプルに実装が可能
- ー出たベースはトランザクションで一貫性を容易に確保
- ビジネスロジックは単純なCRUDや、フレームワークが提供するORマッパーでの実装が中心
- 少人数での開発に最適
- デプロイメントはモノリスでシンプル
モノリシックアーキテクチャで成長し続けた際に出てくるつらみ
- 異なる機能から共通のデータへアクセス
- パフォーマンスも課題に
- 利用者が増えてくるとスケーラビリティの確保が必要
- モノリスだとスケール単位もモノリスになり、スケールしなくても良いものまでスケールしてしまう
- アプリはスケールアウトして負荷分散しやすいが、データベースに負荷が集中する。また、データベースはスケールアップ戦略を取ることが多いが、上限があることが多い
- ビジネスロジックが他のレイヤーに漏れ出していってしまう
- コードの見通してが悪くなり、機能追加や修正が及ぼす影響が不明に
- 共通ライブラリの修正による影響が大きくなる
- データベーススキーマの変更が他の機能に影響を与える
- デプロイメントが大変になりリリース頻度が低下する
マイクロサービスアーキテクチャ
- 採用理由
- デプロイの影響範囲を小さくする
- 機能的な自律性と単一責任の原則
- 開発速度の向上
- スケーリングの最適化
- コストの最適化
- やめたほうが良いケース
- サービスの分割単位が不明確な場合
  - サービスの境界を間違えるとコストがかかる可能性
  - アンチパターン：細かく分割しすぎる
- 開発メンバーが少数の場合 → 開発メンバーリソースがボトルネックになる
- 単純なCRUDのみの小規模なアプリケーションの場合
  - トランザクションスクリプトパターンですむような処理しかない場合は、分散システムの複雑性が足かせに
- 正当な理由がない場合 → 例）他がやってるから、流行ってるから

必ずしもマイクロサービスを推奨するものではなことと、そのメリット・デメリットについて説明しています。

モノリスについてもデメリットだけではなくメリットについても述べられており、なんというか公平だなと感じました。とても良かったです。
マイクロサービスセッションはモノリスの悪いところを上げてマイクロサービスのメリットを説くようなものが多いのですが、この前半の説明で「うちはモノリスのままでも良いかもな」と判断出来る人もいそうです。

中盤

中盤では、じゃあマイクロサービス化してみるかとなったときにどのようにサービスを分割していくか、実践的な手法について解説されていました。
マイクロサービスやってみるかというチームは多いと思いますが、私の経験上はこのあたりで挫折するか、あるいは間違ったサービス分離を行ってしまっていたパターンが多かったです。

ここでは具体的にはドメイン駆動設計とイベントストーミングについて、以下のような流れで解説されています。

ドメイン駆動設計の簡単な紹介
- 戦略的設計：ビジネスコンテキストを分割し、コンテキストマップを考える
- 戦術的設計：コンテキストの中のドメインモデルを主役やエンティティなどを使って設計する
イベントストーミングの紹介
- 流れの説明
- Bit Picture
  - ドメインエキスパートの意見を聞きながら時系列に並べる
  - ビジネス上後戻り出来ない「Pivotal Event」をマーク（ドメイン境界の候補になったりする）
  - ディスカッションの中でよくわからないやつは「ホットスポット」として後で議論する
  - 並列実行・条件分岐時のスイムレーンによる区分け
  - 関係者や外部システムを洗い出してそれらも張り出す
  - ウォークスルーして参加者全員で共通認識をもつ
- Process Modeling
  - ビジネスイベントを発火するコマンドを洗い出す
  - コマンドを誰が発行するのか、発火にあたって何かデータを参照するのか
  - あるイベントが発火されると別のイベントが発火されるか（ポリシー）
- Software Design
  - コマンドとイベントを抜き出していって、責任をもつものに名前をつけていく
  - 集約の候補が見えてくる
  - 集約が見えてくると責務からコンテキスト境界も見えてくる
- 例を挙げて紹介

ドメイン駆動設計はさらっと概要やポイントが紹介されていました。
スライド内で紹介されていた書籍は以下です。

イベントストーミングについて、その流れから例を交えた使い方までしっかりと紹介されていたのが印象的でした。
マイクロサービス化をお検討するにあたて、コンテキスト境界の導き出し方も参考になりますが、そもそも手つかずで何から整理したら良いのかわからん。みたいなことも多いので、イベントストーミングの特に BigPicture のステップについては広く活用出来そうだなと思いました。

またセッション内では、このイベントストーミングワークショップを提供したお客様自身によるレポート記事が引用されていました。
実際のワークショップ風景とともにかなり詳細まで触れられているレポートとなっておりこちらも是非見ておきたいところです。

後半

後半部分では導き出したドメイン・サービスを実際のアーキテクチャーにマッピングしていく部分です。
以下２点について特に解説されています。

論理アーキテクチャへのマッピング
クリーンアーキテクチャを使ってドメインモデルとインフラストラクチャを分離

いきなり物理アーキテクチャへマッピングするのではなく、まずは抽象的な論理アーキテクチャへ一度マッピングすることが推奨されていました。
論理アーキテクチャを定義する際には、非機能要件（可用性、信頼性、セキュリティなど）を設計し、それに対してどういうサポートサービス（認証、分散トランザクション、キャッシング）になるのかを考えていきます。
あるいは普遍的な課題に対してはパターン（SAGA、CQRSなど）が適用出来る場合もあります。

そのあたりを整理してマッピングし、その後 AWS サービスなど物理的なアーキテクチャにマッピングしていく形となります。
スライド内の以下の表がとてもわかりやすかったです。

また最後には、ドメインを外部と密結合にさせないためのアプローチも紹介されていました。
このセッションではその例としてクリーンアーキテクチャが解説されており、API Gateway - Lambda - DynamoDB というインフラストラクチャ構成の場合にクリーンアーキテクチャを当てはめるとどうなるのかも解説されていました。