The Doppler Quarterly (日本語) 春 2016

2つのアプリケーションはOSやプラットフォームが異なるため、個別の移行アプローチが必要でした。ションを使用して新しいインスタンスをインストールする際のサポートなどです。さらに重要な点として、既存の本番環境システムを模倣するためにさまざまなコンポーネントを構成する作業の複雑さが挙げられます。私たちは、「リフトアンドシフト」アプローチと似ているサーバーのクローニングが、ゼロからのインストールよりも適していると判断しました。OS やプラットフォームはアプリケーションごとに異なっていたため、移行ごとに異なるアプローチが必要でした。私たちは詳細なポートフォリオ分析を実施して、各アプリケーションのすべてのエンドポイントと依存関係を特定しました。以降では、固有の課題とその対処方法について説明します。ラーはアクセスを許可または拒否します。私たちは、 AWS でサーバーを準備するための時間が事前に必要だったため、グループポリシーを使用してパスワード更新メカニズムを一時的に無効化し、ドメイン信頼の問題を回避しました。テストの結果、 URL リダイレクト、 CNAME の非互換性、 SPN の要件により、 AWS ELB がこのアプリケーションに適していないことも判明しました。そのため、 HAProxy と keepalived による Linux ベースのロードバランサーを使用して、クラスタリングを実現しました。アプリケーション 2 の課題 • ドメインの信頼とコンピューターのパスワード • レガシーアプリケーションと Web サイト • 構成ドキュメントの不足 • ハードコードされた IP アドレス • さまざまなスクリプトに関するドキュメントや知識の不足 Active Directory 環境の Windows サーバーでは、相互認証にさまざまなメカニズムが使用されます。これには、サーバーごとに一意な SID やコンピューターのパスワード更新メカニズムなどが含まれます。パスワードは定期的に更新され、ドメインコントローアプリケーションによって提供されたすべてのコンテンツは、 NFS を使用した Netapp ストレージアプライアンスでホストされていました。コンテンツのサイズは TB 単位であったため、移行に備えて、すべてがシードおよび同期されており、 AWS で利用可能であアプリケーション 1 の課題 10 | THE DOPPLER | 2016 年春号ることを確認する必要がありました。私たちは、 NAS 仮想アプライアンスを AWS の NFS サーバーとして使用し、 rsync を使用してコンテンツをシードして常に同期させました。コンテンツは主に、一度だけ書き込まれてから読み取られるものであったため、最初の同期に要した時間は、移行期間まで定期的に実行された増分同期よりもはるかに長いものでした。また、アプリケーションは、ロードバランサーのレベルで URL リダイレクトを利用していたので、 AWS ELB を使用できませんでした。そのため、アプリケーション 1と同様に、 HAProxy と keepalived による Linux ベースのロードバランサーを使用して、クラスタリングを実現しました。移行のアプローチリフトアンドシフト型の移行のおおまかな手順は、ディスクレプリケーション製品を使用してサーバーを AWS にレプリケートし、データベースをバックアップしてから、 AWS の新規データベースサーバーにそのデータベースをリストアするというものです。移行とカットオーバーの期間中、すべてのアプリケーションのエンドポイントが AWS の新しいサーバーとデータベースを指すように更新されました。

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