Migration後のRe-architecture判断

AWSへの移行が完了したことと、ワークロードのアーキテクチャが最適になったことは同じではありません。

特にリホストでは、既存環境の構造を大きく変えずにAWSへ移すため、

手作業の多い運用

単一サーバーへの依存

容量拡張の制約

古いOSやミドルウェアへの依存

プラットフォーム固有の制約

などがAWS上にも残る場合があります。

新しいアーキテクチャを決めるときは、

現在どう動いているか
↓
どこに制約が残っているか
↓
将来何を満たす必要があるか
↓
ターゲットで必要な性質は何か

という順序で考えます。

1. 現行アーキテクチャをAWS上の実態から確認する

移行後に再設計を行う場合、移行前の設計書だけを現在状態として扱いません。

移行によって、

配置

ネットワーク経路

運用手順

監視

依存関係

性能特性

障害時の動作

が変化している可能性があるためです。

確認するのは、現在AWS上で実際に稼働している構成です。

例えば、

どのコンポーネントが存在するか

コンポーネント間にどの依存関係があるか

状態をどこへ保持しているか

どの部分を手動運用しているか

需要増加時にどのように容量を増やすか

どの障害でサービスが停止するか

どのOS・CPU・ランタイム・データ形式へ依存しているか

を整理します。

重要なのは、設計図として存在するアーキテクチャではなく、現在実際に動いているアーキテクチャを基準にすることです。

2. 移行前の情報と移行後の実測値を分けて扱う

移行前には、

CPU使用率

メモリ使用量

アクセス量

障害履歴

運用工数

などを調査していても、AWS移行後に状態が変わる場合があります。

例えば、

オンプレミスではCPU不足が問題だった
↓
AWS移行後はCPUに余裕がある
↓
一方で手動スケーリングの運用は残っている

ということがあります。

逆に、移行前には問題が見えなかった依存関係がAWS上で顕在化することもあります。

そのためターゲット設計では、

移行前の評価
+
移行後の実測

を使います。

古い課題をそのまま引き継ぐのでもなく、移行前の情報をすべて捨てるのでもありません。

3. 技術的負債は「AWSへ移しただけ」では解消しない

技術的負債とは、現在は動作していても、変更・運用・拡張・復旧などを難しくしている構造的な制約です。

例えば、

アプリケーション状態をローカルディスクへ保存している

特定サーバー名へ依存している

OS更新を長期間先送りしている

手動手順に依存している

単一ノードを停止するとサービスも停止する

容量変更のたびに手作業が必要になる

などです。

リホストした場合、

オンプレミスで存在した構造的制約
↓
AWS上でも残る

ことがあります。

したがって、

AWSへ正常に移行できた
=
技術的負債が解消した

とは考えません。

移行後に残った構造的制約を確認し、新しいアーキテクチャで解消すべき設計課題として整理します。

4. すべての技術的負債を同時に解消する必要はない

技術的負債が見つかったからといって、ワークロード全体を直ちに全面再設計する必要はありません。

例えば、

現在の業務へほとんど影響しない制約

近い将来に廃止予定のコンポーネント

変更コストが非常に大きい部分

強い互換性制約がある部分

もあります。

一方で、

需要増加を妨げている

障害時の業務停止につながる

サポート終了が近い

日常運用を大きく増やしている

という制約は、ターゲット設計へ強く影響します。

重要なのは、「古いから変える」ではなく、どの技術的負債が将来要件を阻害するかを見ることです。

5. 運用負荷をターゲットの責任分担へ変換する

運用負荷そのものの計算やコスト評価は既に行っている前提とします。

新しいアーキテクチャを決める段階では、現在どの運用責任を持っており、ターゲットではどの責任を残す必要があるかを整理します。

例えば現在、

OSパッチ

ミドルウェア更新

バックアップ

フェイルオーバー手順

容量変更

監視設定

障害復旧

をすべて自社で行っているとします。

ここで、

運用時間が多い
↓
特定のAWSサービスを即決

とはしません。

まず、

アプリケーション固有で残す必要がある運用

プラットフォーム変更によって削減できる可能性がある運用

強い制御要件のため自社で残す必要がある運用

を分けます。

これによって、ターゲットアーキテクチャで必要な運用責任の範囲を定義できます。

具体的なプラットフォームは、その条件を満たす候補から後で選択します。

6. スケーラビリティは現在の台数ではなく拡張方法を見る

現在10台で動いているか、100台で動いているかだけでは、スケーラビリティを判断できません。

見るべきなのは、

需要増加時にどこが上限になるか

容量追加を自動化できるか

特定の1台を大きくし続ける必要があるか

状態やライセンスが拡張を妨げていないか

将来需要まで拡張できるか

です。

例えば現在の負荷を問題なく処理できても、

需要増加
↓
担当者が手動で容量変更
↓
作業完了まで数時間

という構造なら、将来の需要変動に対する設計条件として記録します。

この段階では具体的なサービスを決めるのではなく、ターゲットでどの程度の拡張性が必要かを定義します。

7. 可用性も現在構成と将来要件の差分を見る

「複数台ある」「バックアップがある」という構成情報だけでは、ターゲットアーキテクチャの可用性要件は決まりません。

確認するのは、

現在どの障害でサービスが停止するか

必須依存関係に単一障害点が残っているか

保守作業で停止が必要か

現在の可用性実績が要求値を満たしているか

将来要求される障害耐性と差があるか

です。

既存の信頼性設計を再講義するのではなく、

現行アーキテクチャ
↓
現在残っている可用性上の制約
↓
ターゲットで必要な可用性

という差分を、新しいアーキテクチャの入力にします。

8. 互換性はターゲットアーキテクチャの制約になる

運用負荷や拡張性を改善できる候補であっても、ワークロードが動作しなければ採用できません。

確認する代表例は、

CPUアーキテクチャ

OS

ランタイム

フレームワーク

データベース機能

ファイルシステムの動作

ネットワークプロトコル

商用製品の認定環境

ライセンス条件

などです。

例えば、必須の商用ライブラリがx86_64のみを正式サポートしている場合、ターゲット候補がその条件を満たすか、またはライブラリを変更できるかを確認します。

運用負荷を減らせる
+
高いスケーラビリティを得られる

だけで互換性制約を無視してはいけません。

互換性は、ターゲット候補を絞り込むための設計制約として扱います。

9. 設計資料と移行後の実態が食い違う場合は差異を解消する

移行後の現行アーキテクチャを確認すると、移行前の設計書、CMDB、構成管理資料、担当者への聞き取り、AWS上の実測で内容が一致しないことがあります。

例えば、

設計書
→ 旧APIサーバーへの依存は廃止済み

AWS上の通信記録
→ 現在も旧APIサーバーへの接続が発生

という場合です。

この状態で、「設計書では廃止済みだから依存関係はない」としてターゲット設計を進めると、実際には必要な依存先を削除してしまう可能性があります。

逆に、一度通信が観測されたからといって、それだけで恒久的な必須依存関係と決めるのも適切ではありません。

必要なのは、

観測された通信の用途

発生頻度

どの機能から利用されているか

業務上必要か

廃止可能か

を確認して、現行アーキテクチャの認識を更新することです。

したがって、資料と実測が矛盾する場合は、矛盾を未解決のままターゲット設計へ持ち込まないことが重要です。

10. 現行アーキテクチャの確度を上げてからターゲット設計へ進む

ターゲットアーキテクチャの判断は、「現在何が存在しているか」という前提に依存します。

そのため、重要なコンポーネントや依存関係について、資料で確認済み、実測で確認済み、担当者へ確認済み、まだ確認できていない、といった状態を区別しておくと、設計判断の確度を把握しやすくなります。

例えば、

依存関係A
→ 資料と実測が一致

依存関係B
→ 資料にはないが実測あり
→ 調査が必要

依存関係C
→ 資料にはあるが実測なし
→ 廃止済みか確認

という整理です。

特に、

廃止する予定の接続

移行前から残っている暫定構成

利用実態が不明な共有サービス

などは、ターゲット設計前に確認します。

ここで完成させるのは具体的なAWSサービス選択ではなく、ターゲットアーキテクチャを判断するために信頼できる現行構成です。

11. 互換性制約が残る場合は段階的なターゲット状態を設計する

ターゲットアーキテクチャで改善したい項目が複数あっても、互換性制約によって一度に変更できない場合があります。

例えば、

運用負荷を減らしたい

可用性を高めたい

スケーラビリティを改善したい

という要求がある一方で、

必須の商用ライブラリが現在のOSやCPUアーキテクチャに強く依存し、ベンダーの新版が半年後まで提供されない

という場合です。

このとき選択肢は、「互換性を無視して最終構成へ一気に変更する」または「半年間すべての改善を止める」の二択ではありません。

例えば、

現在
↓
互換性が必要な部分を維持しつつ、
独立して変更できる部分を改善
↓
ベンダー新版の提供・検証
↓
互換性制約を外す
↓
次のターゲット状態へ移行

という段階的な設計が可能です。

ここで重要なのは、最終的なターゲット状態だけでなく、そこへ安全に到達する途中状態も成立させることです。

各段階では、

どの制約をまだ維持するか

どの改善を先に実施できるか

次の段階へ進む条件は何か

を明確にします。

これにより、互換性を壊さずに、可能な改善から順番に進められます。

12. Task 4.3とモダナイゼーションを混同しない

この段階では、既存ワークロードに対して、

どのコンピューティング基盤が適するか

コンテナ基盤が適するか

どのストレージ方式が適するか

どのデータベース基盤が適するか

を判断するための条件を作ります。

一方、

アプリケーションコンポーネントの大規模な疎結合化

新しいサーバーレス処理の導入

新しい機能を追加するための全面的なアプリケーション変更

などは、別のモダナイゼーション判断です。

ここでの目的は、既存ワークロードの現行構成を評価し、新しいAWSアーキテクチャを選ぶための設計条件を完成させることです。

13. 判断フロー

移行後のワークロードを再設計するときは、次の順序で考えます。

現在AWS上で動いている構成を確認
↓
資料と実測の差異を確認
↓
実際の依存関係・運用・性能・障害特性を確定
↓
移行後も残った技術的負債を特定
↓
残存する運用責任を整理
↓
スケーラビリティの差分を確認
↓
可用性の差分を確認
↓
互換性制約を確認
↓
必要なら段階的なターゲット状態を定義
↓
具体的なAWSプラットフォーム選択へ進む

重要なのは、AWSサービスから考え始めるのではなく、移行後の現行アーキテクチャを正確に把握し、残っている制約からターゲットアーキテクチャの条件を作ることです。