Existing WorkloadからTarget Architectureを決定する

1. 個別に適切なサービスを選んだだけではアーキテクチャは完成しない

既存ワークロードを再設計するとき、コンピューティング、コンテナ、ストレージ、データベースについて、それぞれ適切な候補を選んでも、それだけではターゲットアーキテクチャは完成しません。

例えば、

コンテナ実行
→ Amazon ECS on AWS Fargate

共有ファイル
→ Amazon EFS

リレーショナルデータベース
→ Amazon RDS

という個別判断が妥当でも、

アプリケーション
↓
コンテナ
↓
ストレージ
↓
データベース

を接続したときに、互換性・運用・性能を含めてワークロード全体が成立する必要があります。

各サービスが単独で要件を満たすことと、組み合わせたアーキテクチャがワークロード要件を満たすことは別の確認です。

2. 既存ワークロードを実行時の役割へ分解する

ターゲットアーキテクチャを決めるときは、既存サーバー台数をそのままAWSサービスへ置き換えるのではなく、ワークロードを実行時の役割へ分解します。

例えば既存の3層Webシステムが、

Web / API処理
+
共有ファイル
+
PostgreSQL

で構成されているとします。

ターゲット側では、

Web / API実行
→ コンピューティング / コンテナ

共有ファイル
→ ストレージ

トランザクションデータ
→ データベース

として役割を分けます。

重要なのは、既存サーバーとAWSサービスの1対1変換ではなく、既存ワークロードが必要とする役割を、各役割を満たすAWS上の構成要素へ変換することです。

3. 候補を1つの依存関係として接続する

各構成要素の候補を選んだら、次に接続関係を確認します。

利用者
   │
   ▼
アプリケーション
   │
   ▼
Amazon ECS
   │
   ▼
AWS Fargate
   │
   ├────────→ Amazon EFS
   │
   └────────→ Amazon RDS for PostgreSQL

この時点では、Fargate、EFS、RDSを個別に選べるかを再検討するのではありません。

この組み合わせで既存ワークロードが必要とする処理を最後まで実行できるかを確認します。

4. 構成要素の適合とアーキテクチャ全体の適合を区別する

候補サービスがそれぞれ単独で利用可能でも、組み合わせ方が成立しない場合があります。

例えばAmazon ECS on AWS Fargateがアプリケーションの実行先として適切でも、アプリケーションが、

複数の実行単位から
同じファイルを共有
+
実行単位が置き換わっても
ファイルを保持

する必要があるなら、タスク内部の一時領域だけでは要件を完成できません。

一時的な処理データ
→ タスクの一時領域

永続的な共有データ
→ Amazon EFSなどの永続ストレージ

のように、データのライフサイクルとコンピューティングのライフサイクルを合わせて確認します。

5. ComputeとStorageの境界を確認する

コンピューティング方式を変えると、既存ストレージの前提が成立しなくなる場合があります。

既存サーバーでは1台のサーバーとローカルファイルで問題がなくても、ターゲット側で複数タスク、タスク置換、水平スケーリングを行うなら、そのデータは実行単位と一緒に消えてよいのかを確認します。

一時ファイルなら、実行単位のライフサイクルに結び付いた領域を利用できます。

一方、利用者がアップロードしたファイル、複数タスクから共有するファイル、タスク置換後も必要なファイルは、実行単位とは別の永続ストレージへ配置する必要があります。

6. ContainerとStorageは対応条件まで確認する

サービス名の組み合わせだけではなく、実際にその組み合わせがサポートされる条件も確認します。

Amazon ECS on AWS FargateでAmazon EFSを利用するLinuxタスクでは、Fargateプラットフォームバージョン1.4.0以降が必要です。

したがって、Amazon ECS、AWS Fargate、Amazon EFSというサービス名だけを見て組み合わせ可能と判断するのではありません。

OS、プラットフォームバージョン、必要なストレージ機能まで含めて、候補アーキテクチャとして成立するか確認します。

7. Database Compatibilityは全体構成の入力条件として扱う

データベースエンジン、バージョン、拡張機能、認証方式などの互換性は、データベース候補を選択する段階で確認します。

ターゲットアーキテクチャを統合する段階では、その確認を最初からやり直すのではありません。

Database Compatibility
確認済み
        │
        ▼
アプリケーションから
接続して利用できる候補
        │
        ▼
他の構成要素と接続

成立確認済みのデータベース候補を全体アーキテクチャの入力として使用します。

ここで確認するのは個別のデータベース機能ではなく、選択済みのデータベースがアプリケーション、ストレージ、コンピューティングを含むターゲット構成の中で成立するかです。

8. 個別の運用責任を1つの運用モデルへ統合する

各AWSサービスについて利用者側に残る運用責任を確認しただけでは、ワークロード全体の運用設計は完成しません。

アプリケーション実行
→ 担当チームA

共有ストレージ
→ 担当チームB

データベース
→ 担当チームC

と個別担当が決まっていても、アプリケーションからDBへ接続できない、共有ファイルを読み込めない、デプロイ後に性能が劣化した、といった事象は複数の構成要素をまたぐことがあります。

個別サービスの運用責任
        │
        ▼
障害の検知
        │
        ▼
最初の切り分け
        │
        ▼
担当へのエスカレーション
        │
        ▼
復旧確認

重要なのは「誰がOSを管理するか」を再確認することではなく、複数の構成要素にまたがるワークロードを誰がどの順序で運用するかを完成させることです。

9. Performanceは構成要素の最大性能ではなくワークロード要件で評価する

ターゲットアーキテクチャでは、各サービスの公称性能が高いことだけでは選択を確定しません。

ピーク
2,000リクエスト/秒

p95レイテンシー
300ミリ秒以下

という業務要件があるなら、その条件を候補アーキテクチャが満たすことが必要です。

候補を比較するときは、アプリケーション、ストレージ、データベース、構成要素間の通信を含めた結果を判断材料にします。

ここで性能検証の方法そのものを改めて学習するのではなく、既に得られた性能測定結果をターゲット選択の入力として使うことが重要です。

10. 候補は構成要素を接続した状態で評価する

個々の構成要素がそれぞれ要件を満たしていても、それらを接続した候補アーキテクチャが同じ結果になるとは限りません。

コンテナ実行
→ 要件を満たす

共有ストレージ
→ 要件を満たす

データベース
→ 要件を満たす

という状態でも、アプリケーション、共有ストレージ、データベースまで接続した代表ワークロードで性能要件や運用要件を満たせなければ、その候補をそのまま最終構成にはできません。

個別の構成要素の成立
        ↓
接続した候補アーキテクチャを構成
        ↓
Compatibility
Operations
Performance
を全体で確認

という順序で評価します。

11. アーキテクチャ判断マトリクスで候補全体を比較する

複数の候補を比較するときは、サービス単位ではなく候補アーキテクチャ単位で整理します。

この表で重要なのは、サービス単体の優劣を決めることではありません。

ワークロード全体として構成要素を接続できるか、運用モデルを成立させられるか、要求された性能を満たせるかを候補単位で確認します。

12. ターゲットアーキテクチャには判断根拠を残す

最終的な構成図だけを残すと、なぜFargateなのか、なぜEFSなのか、なぜRDSなのか、どの互換性を確認したのか、どの性能要件を満たしたのか、どの運用責任が残るのかが分からなくなります。

そのため、ターゲットアーキテクチャでは少なくとも、

構成要素
↓
担当する役割
↓
満たす要件
↓
確認した互換性
↓
運用モデル
↓
性能上の根拠

を対応付けます。

Amazon ECS on AWS Fargate
→ Web / API実行
→ コンテナ化済みアプリケーション

Amazon EFS
→ 永続共有ファイル
→ 複数タスクから同じファイルを利用

Amazon RDS for PostgreSQL
→ トランザクションデータ
→ 確認済みのPostgreSQL互換性

という構成だけでなく、どの要件を、どの構成要素が、どの証拠によって満たしたかまで追跡できる状態にします。

13. 最終判断フロー

既存ワークロード
        │
        ▼
実行時の役割へ分解
        │
        ├─ Compute / Container
        ├─ Storage
        └─ Database
        │
        ▼
各役割の候補を接続
        │
        ▼
構成要素間のCompatibility確認
        │
        ▼
Operationsを統合
        │
        ▼
Performance要件の成立確認
        │
        ▼
候補アーキテクチャ全体を比較
        │
        ▼
判断根拠を記録
        │
        ▼
Target Architectureを決定

この判断では、最も新しいAWSサービスや、単体で最も性能が高いサービスを選ぶことが目的ではありません。

既存ワークロードに必要な互換性を維持しながら、構成要素を接続した状態で運用と性能まで成立するターゲットアーキテクチャを選択することが目的です。