Level 1：AWSへの初期移行

Level 0：既存オンプレミスCRMで見た通り、Nortia CRMのCRM・SFAは、EOS済みのWindows Server 2012 R2上で動く.NET Frameworkアプリケーションと、単一構成のSQL Server 2014という構成でした。ここでは、アプリケーションを大きく作り変えずに、まず安全にAWSへ移行します。

今回の企業・業務状況

社員300人、CRM利用者80人（営業・管理者）、開発・運用担当3〜5人という体制は変わりません。この段階の目的は、機能追加ではなく「同じ機能を、より安全な基盤の上で動かす」ことです。

現在のアーキテクチャ（移行前）

物理サーバー上のIIS＋.NET Framework 4.5、単一構成のSQL Server 2014、NASファイルサーバー、テープバックアップというLevel 0の構成のままです。OSはWindows Server 2012 R2で、既にメーカーサポートが終了しています。

発生した課題

移行の直接の引き金は、OSのサポート終了（EOS） です。脆弱性が公表されても修正パッチが提供されないため、対応の先送りができません。あわせて、社外アクセス不可・属人化した運用・検証環境の不在といったLevel 0の課題も、この機会にまとめて解消を図ります。

新しい要件

移行プロジェクトの開始にあたり、情報システム部門が経営層・営業部門と合意した非機能要件です。

設計候補（移行方式の検討）

AWSへの移行方式を、いわゆる6Rの観点で評価しました。

Rehostを軸としつつ、EOS対応という移行動機そのものを満たすため、OSとDBエンジンのバージョンアップだけは同時に行う「Rehost + 最小限のReplatform」を採用しました。

採用したAWS構成

Route 53 → ALB → EC2（Windows Server 2022 / IIS） → RDS for SQL Server（Single-AZ）という経路です。添付ファイルはS3、秘密情報はSecrets Manager、監視はCloudWatch、バックアップはAWS Backupでそれぞれ管理します。

移行前後のマッピング

ネットワーク設計

EC2は現時点でAZ-aの1台のみですが、サブネットは最初から2AZ分作成します。RDSのサブネットグループは2つ以上のAZを要求するため必須である一方、AZ-c側のAppサブネットは実質的にLevel 2への準備です。移行時に作っておけば、Level 2ではAuto Scaling Groupの設定だけで済みます。

サイジングの考え方

オンプレミスのスペックをそのままAWSへ写すと、ほぼ確実に過剰になります。

• 物理コアとvCPUは同じではない：AWSのvCPUは基本的にスレッド単位で、2 vCPU ≒ 物理1コアに相当します。オンプレの「4コア」を素直に4 vCPUと読み替えると性能不足、8 vCPUと読み替えると過剰になりがちです。
• オンプレのスペックは調達時点の余裕込み：5年以上前にサイジングされた構成には、その時点での見込み増加分が上乗せされています。

そこで、移行判断の前に既存サーバーのリソース使用率を1か月間測定しました。

インスタンスタイプやストレージは、確定値として決め打ちするものではありません。上記はあくまで初期候補であり、負荷試験と移行後の実測に基づいて確定・適正化する前提です。クラウドの利点は、この見積もりを間違えてもインスタンスタイプの変更で後から直せることです。オンプレミスのように5年間付き合う必要はありません。初期は安全側で設定し、CloudWatchで監視しながら適正化していきます。

なぜそのサービスを選んだか

• EC2（Windows）：アプリケーションが.NET Framework 4.5で動作しており、これは.NET Core/.NET 5以降と異なりWindows上でしか動きません。Linuxコンテナ化にはアプリケーションの書き換えが必須になるため、この段階では選択肢になりませんでした。技術的制約が設計を決めた例です。
• RDS for SQL Server：OSレベルのパッチ適用・バックアップ運用から解放されます。Level 0で「ライセンスの都合で使えなかった」高可用機能も、Level 2ではMulti-AZ設定ひとつで利用できるようになります。
• S3：NASの「残容量20%」という制約そのものが消えます。11ナインの耐久性により、テープからのリストアを前提としない設計に移行できます。
• ALB：現時点では単一EC2への振り分けしか行わず、単体では冗長性を生みません。それでも導入するのは、HTTPS終端（ACM証明書）を集約でき、Level 2で複数台構成へ移る際にアプリケーション側の変更が不要になるためです。

採用しなかった選択肢

特にAuroraへの移行は、コストとマネージド度合いの観点で魅力的に見えます。しかし、SQL Server固有の実装に依存したアプリケーションを異種DBへ移すのは、実質的なアプリケーション再構築です。「安く見えるから」という理由で移行と再構築を同時に始めないことが、この段階では最も重要な判断でした。

データ移行方式

移行対象ごとに手段を使い分けます。

同種DB間（SQL Server → RDS for SQL Server）の移行では、まずネイティブバックアップ／リストアを第一候補とします。DMSは異種DB移行や、停止時間を極小化したい継続レプリケーション（CDC）で真価を発揮しますが、今回は週末8時間のダウンタイムが許容されているため、シンプルな手段で足ります。要件が許すなら、複雑な仕組みを選ぶ理由はありません。

リクエスト・データの流れ

営業担当のブラウザ → Route 53 → ALB（HTTPS終端） → EC2（IIS / .NET アプリケーション） → RDS（顧客・商談データ）。添付資料の閲覧・アップロードは、アプリケーションがAWS SDK経由でS3へアクセスします。

この「S3へのアクセス」が、アプリケーション改修の主要部分です。既存コードはUNCパス（\\fileserver\share\...）でファイルサーバーを直接参照しているため、S3のオブジェクトキーを扱う実装への置き換えが必要になります。逆に言えば、改修はこの1点に集約されます。

障害時の動作

RTO4時間・RPO1時間という要件は、手動対応を前提にすればぎりぎり満たせるという水準です。裏を返せば、担当者が即座に対応できない夜間・休日に障害が起きれば要件を満たせません。この危うさが、Level 2で高可用化に踏み切る直接の動機になります。

セキュリティ

• ネットワーク分離：EC2・RDSはPrivate Subnetに配置し、インターネットから直接到達できないようにします。Security Groupは、ALB→EC2（443）、EC2→RDS（1433）のみを許可します。
• 秘密情報の管理：DB接続文字列をSecrets Managerで管理し、Web.configへの平文記載を廃止します。Level 0では設定ファイルに直書きされていました。
• サーバーへのアクセス：Systems Manager Session Managerを使い、RDP用のポートをインターネットへ開けません。踏み台サーバーも不要です。
• 通信の暗号化：ALBでACM証明書によるHTTPS終端を行います。Level 0では社内ネットワーク前提でHTTPのままの区間が残っていました。
• パッチ適用：Systems Manager Patch Managerで、Windowsの更新プログラム適用を検証環境→本番環境の順に計画実行できるようにします。

監視・運用

CloudWatchでCPU使用率・ディスク・RDS接続数・ALBのレスポンスタイムを監視します。

ここで注意すべきなのは、EC2の標準メトリクスにはメモリ使用率とディスク使用率が含まれない点です。これらはOS内部の情報であり、ハイパーバイザーからは見えません。CloudWatch Agentを導入し、Windowsのパフォーマンスカウンタを送信する設定が必要になります。Level 0でメモリ枯渇による障害を経験している以上、ここを省略はできません。

バックアップはAWS Backupで日次取得し、保持期間は35日とします。復旧試験は移行直後に一度実施し、以降は年1回の実施を運用手順に組み込みます。Level 0の「1年間リストア試験未実施」という状態を繰り返さないための取り決めです。

コストの主な要因

コストの大半をWindowsとSQL Serverのライセンス料金が占めます。これはオンプレミスでも支払っていた費用ですが、AWSではインスタンスを止めれば課金も止まる点が異なります。検証環境を平日夜間・週末に停止するだけで、その費用は実稼働時間分まで圧縮できます。オンプレミスの「買ってしまった資産」とは費用構造が根本的に違います。

一方で、EC2を24時間365日起動し続ける前提であれば、オンプレミスからの劇的なコスト削減は起こりません。この段階での主目的はコスト削減ではなく、EOSリスクの解消と運用負荷の軽減です。ここを取り違えると、後で「クラウドにしたのに安くならない」という評価につながります。

移行・リリース手順

ここからは、実際の本番移行でエンジニアが手順書として使えるレベルまで、移行設計を具体化します。移行期間中は、Site-to-Site VPNでオンプレミスとAWSを接続した「並行構成」で進めます。

1. 移行手順を詳細化する理由

前掲の「データ移行方式」は移行の方針としては成立していますが、本番移行でそのまま使える手順書としては不十分です。実際の移行では、次のような落とし穴があります。

• バックアップが存在するだけでは、復旧可能とは限らない：取得できていても、復元手順が検証されていなければ「復旧できるバックアップ」ではありません。
• DB、ファイル、サーバー設定では保護方法が異なる：ひとつの手段ですべてを守ることはできません。
• 本番移行には、作業順序・完了条件・責任者・Go／No-Go判断が必要：「誰が・何を確認したら次へ進むのか」が曖昧なまま当日を迎えると、判断が属人化します。
• DNSを戻すだけでは切り戻せない場合がある：AWS側に本番データが書き込まれた後は、DNSを戻すとデータが分岐します。
• 本番データへの書き込み開始が、切り戻し方法を変える境界になる：この境界を意識しない移行計画は、最悪の場合データ欠落を招きます。

2. バックアップ・スナップショットの使い分け

移行対象ごとに、保護方法と目的が異なります。

3. 移行リハーサル

本番移行の2〜4週間前に、400GBのDBと1.6TBの添付ファイルを想定した本番相当のリハーサルを行います。所要時間を実測し、当日手順書へ反映することが目的です。

1. SQL Serverのフルバックアップ取得
2. バックアップファイルのS3転送
3. RDS for SQL Serverへの復元
4. DataSyncによるファイル転送
5. アプリケーション接続確認
6. 主要業務機能の確認
7. 件数・更新日時・集計値・ファイル数の比較
8. RDSスナップショットからの復旧試験
9. 所要時間の記録
10. 当日手順書への実測値反映

所要時間は環境によって大きく変わるため、「DB移行は約2〜3時間」などと断定せず、リハーサルで測った実測値を記入して当日計画へ反映します。

4. 移行前の準備

移行1か月前

• AWS検証環境構築
• Windows Server 2022、IIS、SQL Server 2019相当での動作確認
• 接続文字列、S3参照処理の確認
• 本番相当データを使ったリハーサル
• 性能試験
• 復旧試験

移行1週間前

• EC2への本番アプリケーション配置
• RDSパラメータ設定
• Secrets Manager設定
• S3バージョニング有効化
• DataSync初回同期
• CloudWatchアラーム設定
• SQLログイン・権限・Agentジョブ等の移行スクリプト準備
• 切り戻し手順の確認
• AWS Backup設定確認
• 運用担当者の権限確認

移行3日前

• Route 53のTTL短縮
• AWS・オンプレミス双方の構成変更凍結
• EC2の最終AMI取得
• Terraform planとstateの保存
• 作業責任者・承認者・連絡経路の確認
• 利用部門への停止通知
• Go／No-Go判定表の確認

5. 当日のGo／No-Go確認

切り替え作業を開始する前に、次の項目をすべて確認します。

6. 切り替え当日の詳細手順

Step 1：メンテナンスモードへの切り替え

• 一般利用者からの新規アクセスを停止
• オンプレCRMをメンテナンス画面へ変更
• バッチ処理と外部連携を停止
• DBとNASへの書き込みが止まったことを確認

この時点で、後の検証と突き合わせるための基準値を記録します。

• 書き込み停止時刻
• 顧客件数／商談件数
• 最大ID
• 最新更新日時
• 主要金額の合計
• NASのファイル数／総容量

Step 2：SQL Server最終バックアップ

事前にフルバックアップを取得しておき、当日は差分バックアップと、必要に応じて最終トランザクションログを取得します。

フルバックアップ（事前）
  → S3へ転送
  → RDSへ NORECOVERY で復元
  → 当日差分バックアップ
  → 最終ログバックアップ
  → S3へ転送
  → RDSへ順番に適用
  → rds_finish_restore
  → DBオンライン

確認項目：バックアップ処理の正常終了、CHECKSUM、RESTORE VERIFYONLY、バックアップ取得時刻、バックアップファイルサイズ、S3上のファイル存在、暗号化状態、復元順序、RDSのタスクステータス。

Step 3：NASからS3への最終同期

• CRMからNASへの書き込み停止
• NASスナップショット取得（スナップショット機能がない場合は共有を読み取り専用化）
• DataSyncで最終差分同期
• チェックサム検証
• ファイル数・総容量・サンプルファイルを比較

Step 4：DB固有設定の移行

SQL Serverのバックアップ／復元では移らない、サーバーレベルの設定を別途移行・確認します。

• SQLログイン、DBユーザーとのSID
• SQL Server Agentジョブ
• リンクサーバー
• 権限
• ストアドプロシージャ、CLR依存
• 外部ファイル参照
• 照合順序、タイムゾーン
• 接続文字列
• メール送信処理

7. 移行後のデータ検証

件数の一致だけでは不十分です。件数が同じでも、途中のレコードが欠けて別のレコードで埋まっていれば件数は一致します。最大ID・最新更新日時・金額合計・NULL件数などを併せて比較することで、「件数は合っているが中身が違う」という移行事故を検出できます。

8. アプリケーション確認

主要業務フローを、実際の画面から確認します。

• ログイン／ログアウト
• 顧客検索／顧客登録／顧客更新
• 商談登録／商談更新
• 添付ファイルのアップロード／ダウンロード
• 権限制御
• 帳票出力
• メール送信
• CloudWatchへのログ出力
• ALBアクセスログ
• RDS接続
• Secrets Managerからの接続情報取得

確認用に投入するテストデータには MIGRATION_TEST 等の識別子を付け、確認後に確実に削除できるようにします。本番データに紛れ込ませないための運用ルールです。

9. 本番開放前の復旧ポイント作成

利用者へ開放する直前に、「この時点まで戻せる」という復旧ポイントを取得します。

• EC2の最終AMI
• RDSの手動スナップショット
• S3バージョニング有効状態の確認
• Terraform stateの保存
• AWS設定値の記録
• 検証結果と承認者の記録

スナップショット名は、後から「いつ・何のために取ったか」が分かる命名にします。

rds-nortia-pre-cutover-YYYYMMDD-HHMM
ami-nortia-web-pre-cutover-YYYYMMDD-HHMM

10. Route 53切り替えと段階開放

DNSをALBへ切り替えた後、全利用者を一斉に入れるのではなく、段階的に開放します。

1. 移行担当者
2. 情報システム部門
3. 営業部門の代表者
4. 全利用者

一斉開放を避けるのは、問題が起きたときの影響範囲を制御するためです。担当者だけの段階で異常に気づければ、業務全体を巻き込む前に切り戻せます。各段階で次を確認します。

• DNS名前解決／ACM証明書
• ALBヘルスチェック／EC2への到達
• RDS接続／S3への読み書き
• CloudWatchアラーム
• レスポンスタイム／エラーログ

11. 切り戻し可能な境界

移行計画で最も重要な境界が、「AWS側で本番データの書き込みが始まったかどうか」です。ここを境に、切り戻しの方法が根本的に変わります。

AWSアプリ停止
  → Route 53をオンプレミスへ戻す
  → オンプレCRMを再開
  → 業務部門へ連絡

12. 移行後の監視（2週間の重点監視）

移行後2週間は、通常の監視に加えて次の項目を重点的に監視します。

技術メトリクスだけでなく業務問い合わせ件数を監視対象に入れる点が重要です。メトリクスが正常でも、利用者が「使いづらい・遅い」と感じていれば、それは移行後の課題として拾う必要があります。

13. 最終的な移行フェーズ表

ここまでの流れを、フェーズ・時期・完了条件で一覧にまとめます。

なお、切り戻しの判断基準（データ不整合の発見、業務継続が困難なレベルの性能劣化など）は、この設計段階で文書化し、関係者間で合意しておきます。「なんとなく不安だから戻す」という判断を当日にさせないためです。

この構成の限界

• EC2・RDSともに単一構成：インスタンス障害やAZ障害が発生すると、手動復旧が完了するまで業務が停止します
• スケーリング手段がない：月初の負荷集中に対して、インスタンスタイプの変更（＝再起動を伴う）以外の対処法がありません
• セッションがEC2内に保持されている：.NET標準のインプロセスセッションのままのため、EC2を複数台にした瞬間にログイン状態が壊れます
• 夜間・休日の障害対応が属人的：自動フェイルオーバーがないため、結局は担当者の即応性に依存しています

次のLevelで改善する点

Level 2：高可用化・安定運用では、Auto ScalingとRDS Multi-AZにより単一障害点をなくします。あわせて、上記のセッション管理の問題も解決する必要があります。「EC2を2台に増やす」だけでは動かない、という点がこのLevelの主題です。