The Doppler Quarterly (日本語) 春 2016

両方のアプリケーションで、以下の移行手順が使用されました。 1. ディスクレプリケーション製品を使用してクローンされたサーバーを AWS に作成します。Windows サーバーでは、本番環境ネットワーク上での SID、名前、 DNS の問題を避けるために、 AWS 内で隔離されたネットワークを使用し、クローンの作成前に作成された一時的なローカル管理者アカウントで、サーバーへの RDP アクセスのみを許可しました。 2. タイムゾーンの更新や監視ソフトウェアのインストールなど、サーバーの準備に必要となるさまざまな手順を実行します。 3. 移行中にデータベースサーバーのクローンを作成します。 4. アプリケーションごとに、 HAProxy および keepalived ソフトウェアを使用して 2 ノードの Linux ベースのクラスターを展開します。 5. 次のようにアプリケーション構成を更新します。アプリケーション 1 の場合ソフトウェアのクラスター構成を更新して、新しい IP と AWS のローカルドメインコントローラーを反映させます。アプリケーション 2 のサーバーの場合ホスト名と Web サーバー構成を更新して IP アドレスに依存しないようにし、カスタムボンディングされたネットワーク構成を削除します。アプリケーションチームは、クローン済みサーバーで広範なアプリケーションテストを行いました。これには、各エンドポイントのテスト、データベースとの対話操作、ストレージコンテンツの検証、すべてのスクリプトのテストなどが含まれます。 AWS でサーバーの準備ができたら、移行期間に次の手順を実行しました。 1. AWS セキュリティグループを更新して、 Windows サーバーが本番環境ネットワークおよびドメインコントローラーと通信できるようにします。 2. 新しい AWS ベースの NFS サーバーに対して、 NFS データの最終同期を実行します。古い NFS マウントポイントをアンマウントし、新しい AWS ベースの NFS ボリュームをマウントします。この手順は、ロードバランサーのプール構成と連携してダウンタイムを回避するために、各サーバーで段階的に行われました。 3. Citr i x Net sca ler および HAProxy ロードバランサーを AWSの古いサーバーと新しいサーバーの両方で更新し、ロードバランサープール内の各サーバーをテストすることで、古いサーバーから新しいサーバーへの正常なプール更新を行います。 7. グループポリシーを更新して移行前の設定に戻します。 8. すべてのテストを検証した後に、古いサーバーの廃止プロセスを開始します。ゼロダウンタイムを達成するにあたってとなるのは、技術的なアーキテクチャーとアプローチよりも、テストを活用してアプリケーションの動作を検証する徹底的なアプリケーション分析でした。また、本番環境に移行する前に開発環境とステージング環境で移行を実行してみることも、きわめて重要です。最後に、効果的なプロジェクト管理、サードパーティからの積極的関与、一貫したコミュニケーションも不可欠な要素です。最終的に、 AVID 社はゼロダウンタイムで AWS への移行を達成しました。また、クライアントのチームは、広範な分析、テスト、文書化を通じて、アプリケーションに関する深い知見を手に入れることができました。多くの企業にとって、このような分析と新たな知見は、移行そのものと同等の価値があると言えるでしょう。 4. 外部 DNS と内部 DNS を更新します。現在の Citrix Netscaler のロードバランサー構成はそのままの状態であったため、 DNS の変更が反映されている間にアプリケーション要求を処理することができました。 5. 新しいサーバーがアプリケーション要求を正常に処理していることを検証した後、ロードバランサープールから古いサーバーを取り除きます。 6. 古いサーバー上のアプリケーションサービスをシャットダウンします。 2016 年春号 | THE DOPPLER | 11

The Doppler Quarterly (日本語) 春 2016 | Page 13