Existing ApplicationからModernization Patternを選択する

既存アプリケーションをModernizeするとき、システム全体へ1つのパターンを割り当てようとすると判断を誤ることがあります。

1つの業務システムでも、内部には異なる責任があります。

業務システム
│
├─ ファイル検証処理
│   └─ イベント時だけ短時間実行
│
├─ Java業務サービス
│   └─ 長時間稼働・独自ランタイム
│
├─ 画像変換
│   └─ 受付処理とは独立して実行可能
│
├─ 承認処理
│   └─ 順序・待機・状態管理が必要
│
├─ セッションデータ
│   └─ 独立したKey-value Access Pattern
│
└─ 配布ファイル
    └─ コンピューティングごとに複製

この場合、システム全体へ1つのModernization Patternを選ぶのではなく、責任ごとの問題へ適切なModernization Patternを対応付けます。

1. Modernization Selectionは「サービス」ではなく「変更する責任」から始める

これまで確認した各パターンは、同じ問題を解決する代替案ではありません。

Serverless
→ 実行基盤・容量管理の責任

Container
→ ランタイム・依存関係・配置の責任

Decoupling
→ コンポーネント間の待機・障害波及・拡張境界

Event-driven
→ イベント発行元と反応側の責任

Workflow
→ 順序・状態・待機・再試行などの進行管理

Purpose-built Database
→ データAccess Patternとデータストア責任

Managed Storage
→ ストレージ基盤・容量・複製などの責任

Modernization Selectionでは、使いたいAWSサービスから始めるのではなく、現在どの責任が変更・運用・拡張を妨げているかから始めます。

2. まず責任をアーキテクチャの層へ分ける

例えば、環境ごとにライブラリが違う問題と、下流処理の遅延で利用者向けAPIまで停止する問題は、同じアプリケーション内で発生していても責任が異なります。前者は実行・配置、後者はコンポーネント間の結合の問題です。

3. ServerlessとContainerをアプリケーション全体の二者択一にしない

同じシステム内でも、処理特性が異なれば実行方式を分けられます。

短時間・イベント単位・ステートレス
→ Serverless候補

長時間稼働・独自ランタイム・依存関係を固定
→ Container候補

システム全体をServerlessまたはContainerへ統一する必要はありません。現在同じアプリケーションに含まれていることを、同じ実行方式を選ぶ理由にしないことが重要です。

4. Container化しても他のModernizationが完了するわけではない

Container化によってランタイム、ライブラリ、配置方法を改善できても、同期呼び出しによる障害波及、独自Workflow制御、単一RDBへのAccess Pattern混在、ホストごとのファイル複製が自動的に解決するわけではありません。

Container化
+
Decoupling
+
Purpose-built Database
+
Managed Storage

のように、異なる層のModernizationを組み合わせることができます。

5. Decouplingは「処理を独立させる必要があるか」を見る

上流処理
↓
下流処理の完了を待つ
↓
下流の遅延・障害が
上流へ波及

している場合は、まずこの2つの処理が同じタイミングで完了する必要があるのかを確認します。独立して進められる処理であれば、Decouplingによって障害範囲、処理速度、Scalabilityを分離できる可能性があります。

6. Event-drivenは「起きた事実へ独立して反応する処理」を探す

注文確定という出来事に対して、通知、分析、監査などが互いに独立して反応できる場合があります。

何が起きたかを知らせる
↓
必要な処理が独立して反応する

このような責任はEvent-drivenとして扱えます。次に必ず何を実行するかを中央で管理する責任とは分けて考えます。

7. Workflowは「処理の進行そのものが業務責任」の場合に使う

在庫確保
↓
決済確認
↓
承認待ち
↓
出荷登録

のように、順序、現在状態、待機、条件分岐、再試行を管理する必要がある処理があります。

同じ注文処理でも、独立した通知・分析はEvent-driven、順序付きの出荷処理はWorkflowとして扱えます。Event-drivenとWorkflowをアプリケーション全体の二者択一にはしません。

8. Purpose-built Databaseは実行方式とは別に評価する

アプリケーションをServerless化またはContainer化しても、1つのリレーショナルデータベースへ異なるAccess Patternが混在している状態は残る場合があります。

注文
→ Relational

セッション
→ 独立Key-value

反復読み取り
→ Cache候補

が同じデータベースに残っているなら、Purpose-built Databaseの機会を別の責任として評価します。Container化済みだからデータベースModernizationも完了したとは判断しません。

9. Managed Storageもコンピューティングとは別の判断

実行基盤を変更しても、各ホストへ同じ画像を複製したり、自前NFSの容量を手動拡張したりしている場合があります。

Container化されたアプリケーション
↓
各コンテナホストへ
同じファイルを複製

しているなら、Containerを使っているかではなく、ストレージがコンピューティングへ依存していないかを確認します。Managed StorageはServerlessやContainerの代替ではなく、別の責任を改善するパターンです。

10. 1つのコンポーネントに複数のパターンが関係することもある

Modernization Patternは、必ず1コンポーネントにつき1種類とは限りません。

画像処理ワーカー

EC2上で常時待機
+
受付APIから同期呼び出し
+
画像をローカル保存

↓

実行方式
→ Serverless候補

受付との依存
→ Decoupling候補

画像保存
→ Managed Storage候補

重要なのは、どのパターンが唯一の正解かではなく、どの責任にどのパターンを対応させるかです。

11. Modernization Pattern同士を連鎖条件にしない

あるパターンを採用したからといって、別のパターンが自動的に必要になるわけではありません。

Container化した
↓
必ずマイクロサービス化
↓
必ずEvent-driven化
↓
必ずPurpose-built Database化

とは判断しません。それぞれについて、現在その責任に改善すべき問題があるかを確認します。逆に、同じシステムで複数の問題が見つかれば、必要なパターンを組み合わせます。

12. Modernization Selectionでは「責任 → 根拠 → パターン」を対応付ける

症状から機械的にサービスを選ぶのではなく、現在の責任、何を変更したいか、その責任へ適用できるModernization Patternという順序で判断します。

13. 統合例

注文API
→ 長時間稼働・ランタイム差異

画像検証
→ イベント時のみ実行・ステートレス

注文API
→ 画像検証完了を同期待機

注文確定
→ 通知 / 分析が独立して必要

出荷
→ 在庫 / 決済 / 承認 / 出荷の順序管理

データベース
→ 注文 + セッションが同居

画像
→ 各アプリケーションホストへ複製

このシステムでは、

注文API
→ Container

画像検証
→ Serverless

注文APIと画像検証
→ Decoupling

注文確定後の通知 / 分析
→ Event-driven

出荷処理
→ Workflow

セッションデータ
→ Purpose-built Database候補

画像保存
→ Managed Storage候補

のように、責任ごとに異なるパターンを選択できます。1つのアプリケーションだから1つのModernization Patternだけを選ぶ必要はありません。

14. 判断表

15. 判断フロー

既存アプリケーションを
コンポーネントと責任へ分解
        ↓
各責任について
何が変更を妨げているか確認
        ↓
実行方式の問題か
        ├─ Serverless
        └─ Container
        ↓
コンポーネント間の依存か
        ├─ Decoupling
        └─ Event-driven
        ↓
処理進行の管理か
        └─ Workflow
        ↓
データAccess Patternの問題か
        └─ Purpose-built Database
        ↓
ストレージ基盤運用の問題か
        └─ Managed Storage
        ↓
責任ごとの選択を
1つの目標アーキテクチャとして統合

最終的なModernization Selectionでは、アプリケーション名にパターンを割り当てるのではなく、責任、現在の制約、変えたい運用・構造にパターンを対応付けます。