テクノロジー移行戦略に関する完全なガイド: (最終 – ドメインとホスティングの移行)

公開: 2020-12-28

最後になりましたが、ブログシリーズを締めくくるために、サーバー (ドメインとホスティング) の移行について掘り下げます。アプリケーションとデータベースの移行はバックエンドの移行プロセスの重要な要素としてすでに範囲を定めているため、サーバーの移行で終了することだけが理にかなっています。

一般的に言えば、Web サイトをあるホストから別のホストに移行することは、前述の他の移行タイプと比較して簡単かもしれません。実際には、ウェブサイトに新しいアドレスを与えることにたとえることができます。この記事の残りの部分では、この移行垂直方向に関連する重要な側面とベストプラクティスについて詳しく説明します。それでは、さっそく始めましょう。

サーバー移行とは何ですか?

最も基本的な意味でのサーバー移行は、あるサーバーから別のサーバーにデータを配置する移行手法です。基本的には、Web サイトとその構成をコピーして既存のサーバーを置き換えるようにターゲットサーバーを構成し、DNS を変更して訪問者を新しいサーバーに誘導する必要があります。サーバーの移行は、データに依存する多くのビジネスで一般的です。データは機密性が高いため、移行を成功させるには慎重な計画が不可欠です。

サーバー移行の理由

サーバーの移行は、次のようなさまざまな理由で発生する可能性があります。

トラフィックの増加に対処するため。
パフォーマンスの向上と応答時間の短縮が望まれます。
コントロール、管理性、および柔軟性の向上を望む。
カスタマイズ性を高めるために。

一方で、コスト削減のためにローエンドサーバーにダウングレードする人もいます。サーバーの移行には、次の 2 つの重要な側面も含まれます。ドメインの移行とホスティングサーバーの移行。このブログの大部分では、両方のカテゴリについて説明します。たとえば、ホスティングプロバイダーの切り替え (GoDaddy から AWS など) とドメイン名の移行 (example.com から example.info など) の違いです。

ドメイン名の移行とは何ですか?

ドメインの移行とは、簡単に言えば、データセキュリティの損失や障害なしに、Web サイトをあるドメイン名 (example.co) から別のドメイン名 (example.info) に移動することを意味します。原則として、ドメイン名を移管する場合、サーバー間のファイル転送がないため、バックアップは必要ありません。ただし、DNS (ドメインネームシステム) 情報は、変更の記録を保持するための要件として転送する必要があります。プロトコルの変更は、HTTP Web サイトを HTTPS に移行する場合など、非セキュア Web サイトをセキュア Web サイトに移行する場合にも発生する可能性があります。基本的に、ドメイン名を変更する理由はさまざまです。たとえば、 .comなどの一般的なドメインから、 .inや.cn などのより地理的に限定されたドメインに移動するという選択肢が考えられます。

ホスティングサーバーの移行とは何ですか?

ホスティングサーバーの移行とは、基本的に、あるホスティングサービスプロバイダーから別のホスティングサービスプロバイダーに移動することを意味します。移行中は、移行プロセスを開始する前に、デバイス上のデータベースファイルとともに Web サイトの完全なバックアップを作成する必要があります。また、すべてのサーバー側スクリプトを新しいホスティングプラットフォームにインストールできること、および新しいサーバー上で Web サイトがスムーズに動作することを確認してください。あるホストプロバイダーから別のホストプロバイダーに移行する理由は、次のように複数考えられます。

新しい技術スタックまたはより良いサービスを利用したいという欲求
時代遅れのインフラストラクチャを置き換える必要性
高可用性を実現するためにホスティングを拡張および分散する必要があります。
セキュリティ上の懸念など

サーバーホスト移行の種類

関連するオペレーティングシステムとテクノロジに応じて、サーバーの移行は通常、次の要素で構成されます。

クラウドサーバーの移行: これには主に、最新のスケーラブルなクラウドサーバーへのデータの配置が含まれます。

アプリケーションサーバーの移行: これには基本的に、あるサーバー環境から別のサーバー環境へのソフトウェアアプリケーションの移行が伴います。これは基本的に、ファイルがサーバー間で移動されるたびに発生します。

メールサーバーの移行: ここでは、同じまたは異なるホスト内のメールサーバーの移行間でデータが転送されます。

仮想サーバーの移行– この移行ドメインには、仮想サーバー、またはあるサーバーから別のサーバーへの仮想マシンの移動が含まれます。 GoDaddy、AWS、DigitalOcean、Alibaba Cloud など、市場には複数のサーバーオプションがあります。ただし、どれを選択するかはプロジェクトの要件に大きく依存します。すべてのホスティングサーバーの移行に適用される共通のルールが 1 つあります。以前のドメインレジストラーに 60 日以上登録されている場合にのみ、ホスティングサーバーを変更できます。それぞれのホスティングサイトで利用可能な他のルールについて学ぶことができます。

ドメイン名を移行するにはどうすればよいですか?

ドメイン名の移行は、サーバーの移行とは対照的に、より容易に推測できます。ドメイン名を移行する最も一般的な理由として挙げられるのは、ユーザーが長いドメイン名を持っていて、より適切で短いバージョンを望んでいる可能性があることです。ただし、ドメイン名を切り替える前に、主に 2 つの異なるシナリオに留意する必要があります。

他の誰かが既に使用しているドメイン名を購入する: これは、ドメインオークションまたは他の誰かから直接購入した期限切れのドメイン名である可能性があります。
今まで使ったことのない全く新しいドメイン名を購入。

上記の 2 つのシナリオの違いと、それらが不可欠である理由を理解するために、例を挙げてみましょう。以前に登録したドメイン名を購入しようとしている場合、次のいずれかの問題に直面する可能性があります。

それを指すリンクが含まれている場合がありますが、これはサイトにとって良い場合もあれば、場合によっては悪い場合もあります。
あなたとは別の目的で作成されたトピック外のサイトに以前に添付されていた可能性があります。
検索エンジンによっては、罰せられるか、禁止される場合があります。
サイトがソーシャルメディアサイトで禁止されている可能性があります。
以前はスパム活動にも使用されていた可能性があります。

ドメイン名の移行プロセス

ドメイン名の移行プロセスは非常に簡単です。簡単な手順に従うだけで、すぐに完了します。
まず、Google 検索コンソールで各サイトのすべてのバージョン (http://、http://www、https://、または https://www) を確認する必要があります。また、サブドメインがある場合はすべて特定します。
サイト全体をクロールします。この目的のために、オンラインで入手できるさまざまなツールを使用できます。これは、考えられるすべての URL を特定し、それらのリストを作成するのに役立ちます。後で必要になります。
301 Permanent Redirects を使用して、古いドメイン名から新しいドメイン名にリダイレクトします。
リダイレクトをテストして、複数回リダイレクトしていないことを確認します。ユーザーを混乱させる可能性があります。
Google Change of Address Tool を使用して、新しいドメインに移動することを Google に通知します。これにより、リダイレクトが正しく設定されているかどうかを確認できます。
新しいドメイン名を指すように Google アナリティクスの設定を更新することを忘れないでください。古いデータを Google アナリティクスに残しておきたい場合は、Google アナリティクスの設定を編集できます。
作成した URL のリストを使用してサイトを再度クロールし、すべての古い URL が新しい URL に適切にリダイレクトされていることを確認します。

あるサービスプロバイダーから別のサービスプロバイダーに移行するにはどうすればよいですか?

前に示唆したように、サーバーの移行は非常に簡単です。移行プロセスがどれほど綿密に計画されていても、Web サイトは通常、サーバー移行プロセス中にダウンタイムに直面します。そのため、移行プロセスを実行する前に、移行計画を事前に準備する必要があります。

通常、サーバーのトラフィックが最も少ないときに移行プロセスを実行する必要があります。そうしないと、ホスティングサーバーの移行プロセスが失敗する可能性が高くなります。

ホスティングプロバイダーを選択したら、プランを購入し、Web サイトを新しいホストに移行する準備をします。ウェブサイトが完全に新しいドメインレジストラーに移行されるまで、古いドメインレジストラーのプランがキャンセルされないようにしてください。
古いドメインレジストラーからすべてのデータベースと Web サイトファイルのバックアップを取るなど、移行を進める前に注意する必要があるいくつかの予防措置があります。
PHPAdmin またはその他のサードパーティソフトウェアを使用して、データベースをインポートできます。次に、Web サイトのファイルとデータベースをドメインレジストラーの新しいサーバーにアップロードします。
データベースをアップロードする前に、まず新しいサーバーに Web アプリをインストールしてから、データをバックアップする PHPAdmin またはその他のサードパーティソフトウェアからデータベースをエクスポートしてください。
DNS を切り替える前に、すべてのメールアカウントを新しいサーバーに追加することを忘れないでください。また、「キャッチオール」アドレスを作成して、メールアドレスを追加し忘れた場合にメールが返送されないようにすることもできます。
ベストプラクティスとして、メールアドレスごとに 2 つのアカウントを作成し、POP 設定でドメイン名の代わりに各メールサーバーの IP アドレスを使用することができます。このプラクティスの助けを借りて、DNS 伝播方法中に電子メールを見逃すことはありません.
すべての Web サイトファイルを新しいホスティングサーバーに配置したら、一連のテストを実行して、すべての画像、テキスト、およびリンクが新しいサーバー上で適切な場所に配置され、適切に機能することを確認する必要があります。
DNS レコードを変更する場合は、ドメインレジストラーを使用してコントロールパネルから DNS レコードを変更する必要があります。基本的に、ドメインネームサーバーを、新しいホストから送信されたウェルカムメールに記載されているものに変更する必要があります。 2 ～ 4 日以内に、移行プロセスが正常に完了します。
最後に、古いホスティングサービスプロバイダーからホスティングアカウントをキャンセルすることを忘れないでください。

シームレスなホスティングサーバー移行を実現するために考慮すべき予備的な指針。

計画フェーズ

ソースサーバー上のホスティングプラットフォームが移行に対応していることを確認します。
適切なターゲットサーバーとターゲットサーバーのハードウェアを慎重に選択してください。アプリケーションには違いがあります。たとえば、ある専用サーバーから別の専用サーバーにデータを転送するかどうかです。または、新しいサーバー構造が、いくつかの異なるシステムを含むクラスターに基づいているかどうか。
移行先サーバーでサポートされているオペレーティングシステムを選択してください
移行後に移行先サーバーでドメインをオンラインにするための実行可能な方法を選択します (たとえば、新しい IP アドレスへの移行と、移行後にドメインの DNS レコードを更新してそれらを指すようにするなど)。ソースサーバーが過負荷であるか、リソースが不足している場合は、可能であれば営業時間外に移行ジョブを計画することをお勧めします。

サーバーの準備

ソースサーバーで使用されている使用可能なすべてのコンポーネントがターゲットサーバーにもインストールされ、構成されていることを確認します。
移行元サーバーと移行先サーバーに十分なディスク容量があることを確認してください
移行先サーバーに必要な数の IP アドレスを追加します (ベストプラクティスは、移行のために両方のサーバーで同じ量の共有 IP と専用 IP を使用することです)。

テスト段階の考慮事項

潜在的なリスクを測定するために、エンドツーエンドのパフォーマンステストをお勧めします。この間に、リスクの低いアプリケーションをいくつか試用し、いくつかの開発テストを実行してから、リスクの高いアプリケーションに取り組みます。このような漸進的なプロセスにより、より大規模で複雑なアプリケーションをテストしながら、プロセスに対する信頼を徐々に築くことができます。
とはいえ、展開後も同様に重要であり、サーバーは移行後もかなり「集中治療」状態を維持する必要があります。

リスクの軽減

リスクはサーバー移行作業と同義であり、できるだけ多くのリスクを軽減することがベストプラクティスの一部です。いくつかのリスクシナリオの例を次に示します。

アプリケーションが移行後に期待どおりに機能しない可能性があるという包括的なリスク。
プログラムまたは機能が正しく機能しないリスク
データ侵害とデータ損失。
不正なインスタンスのスポーン
断続的に利用できなくなるリスク。これは常に事業運営に問題を引き起こし、問題を修正するためだけに強制的なダウンタイムが発生する可能性があります。

本質的に、このようなリスクを軽減する最も効果的な方法は、アプローチの移行を完全に計画することです。これには、重要なアプリケーションとデータストアを慎重に把握すること、および重要なアプリケーションの信頼できるバックアップを作成するなどの不測の事態を想定することが含まれます。たとえば、一部の企業は、高度な移行で発生する可能性がある他の潜在的な問題を特定するために、(クラウドシミュレーションツールを使用して) 移行シミュレーションを行います。

バックアップ方法の選択

壊れたレコードのように聞こえなくても、バックアップの重要性を強調しきれません! 本質的に、最適なバックアップ方法は、ディスクのイメージバックアップを作成することです。通常、イメージバックアップは、レジストリキー、ライセンスキー、設定、アプリケーション固有のデータなどの重要な情報を詳細にキャプチャします。
さらに、イメージバックアップを使用すると、物理サーバーのバックアップを仮想マシン (VM) に変換できます。本質的に、この変換により元のマシンのコピーが保持され、古いシステムデータにアクセスする必要が生じた場合にいつでも起動できます。そうは言っても、イメージバックアップは移行プロセスに重要なセーフティネットを提供します。
一方、ファイルベースのバックアップアプローチも実行可能な代替手段です。ただし、オペレーティングシステム全体または仮想マシンをバックアップする必要がある場合、ファイルベースのバックアップはファイルシステムのレベルで動作するため、ファイルベースのバックアップでは不十分な場合があります。

このプロセスは新しいサーバーによって完了するため、このプロセス中にダウンロードしたバックアップファイルを解凍しないでください。

ロールバック計画を立てる

ロールバック戦略は、何かがひどくうまくいかない場合、または圧倒的に複数の問題がある場合のフェイルセーフです。基本的に、変更を元に戻し、サーバーを移行前の元の状態に戻すことができます。
サーバープロバイダーがそのような対策を講じていることを確認してください。

サーバー移行チェックリスト

本日詳しく説明した内容に基づいて、サーバーの移行を開始または検討する際に尋ねる最も重要な質問をまとめましょう。
新しいサーバーにはどのアーキテクチャを使用する必要がありますか? また、プロジェクトのアーキテクチャはニーズに合っていますか?
移行作業とその後のサーバー構成に利用できる十分な財源と専門家はいますか?
選択したハードウェアは、プロジェクトの将来の開発に十分な柔軟性がありますか?
システムがまだ稼働している間に移行プロセスを実行する必要がありますか?それとも、プロセスの間、すべてのアクティビティを中断する必要がありますか?
運用を維持できる可能性は、リソースの可用性と移行の複雑さの増加に比例していますか?
もしそうなら、ダウンタイムをできるだけ短く保つためにどのような手段を講じることができますか?
データベースエントリの整合性とそれらが最新であることをどのように保証しますか?
新しいサーバーの機能はどのようにテストされますか?
データの移行が完了した後、特定のアプリケーションが動作しない場合はどうなりますか? どのような不測の事態または回避策を講じることができますか?

結論

このブログが包括的なアイデアを提供し、ドメインの移行とホスティングサーバーの移行の違いを詳しく説明してくれることを願っています。移行はより広いトピックですが、移行の旅を開始する際に決定を下すのに役立つすべての重要な側面をカバーしようとしました.

この一連のブログは、基本的に、移行の範囲を定義し、スコープクリープを回避し、テクノロジースタックを賢く選択し、テクノロジーの移行、データベースの移行、ドメインとホスティングサーバーの移行など、さまざまな種類の移行の背後にある複雑さを理解するのに役立ちます。このブログシリーズの目的は、移行やその他の移行の詳細を知るために、読者が Google で散在する Web サイトを検索して移行する必要がないようにすることでした。このブログシリーズがお役に立てば幸いです。簡単な移行を実現する方法についてご不明な点がございましたら、クレオールスタジオまでお問い合わせください。