Webサイトを適切にアップグレードするための好ましい方法はありますか？完全に新しいコードベースをサイトに配置する準備ができていますが、更新には数時間かかります。「アップグレードして、すぐに戻ってきて！」と言ってサイトがずっとダウンしてほしくない。メッセージが表示されますが、新しいサイトが配置されている間は、現在のサイトをそのままにしておくこともできません。
正常なアップグレードが可能になると私が考える唯一の方法は、2台のサーバーを使用することですが、これはより高価になります。
7 に答える
10
「Webサイトを適切にアップグレードする」計画は、展開の準備ができても開始されません。これは、アプリケーションの設計の非常に早い段階から始まります。つまり、適切にアップグレードできるアプリケーションを構築し、そのアップグレードをサポートするインフラストラクチャを整備する必要があります。
あなたはいくつかの詳細を提供し、インターネット上のランダムな人々から漠然とした、しかし重要な質問をしています。これにより、「優雅にアップグレードする」ことが直前の懸念事項であると私は信じています（23分前のように）。
あなたの質問、「ウェブサイトを優雅にアップグレードするための好ましい方法はありますか？」「はい、でも私はあなたとは違うやり方でやっています」としか答えられません。
于 2009-10-08T15:41:10.603 に答える
1
アップグレードにコミットする時間/リソースに応じて、使用できる戦術がいくつかあります。
移行の実行方法によっては、ダウンタイムをまったくゼロにしてこれを実行できる場合があります。
アプリケーション/サイトが複雑になるほど、ダウンタイムを望まない場合の移行戦略は複雑になる可能性があります。
次の方法で、ダウンタイムの移行をゼロにしました。
- 新しいバージョンのサイトとデータベースを使用して新しいサーバーをセットアップします。
- ロードバランサーを変更して、トラフィックをnew-appとold-appの2つのプールに分割します。
- ロードバランサーを構成して、新しいアプリサーバーへのトラフィックの送信を開始しますが、古いアプリサーバーで既存のセッションを維持します
- new-appの新しいセッションでは、顧客データが移行されているかどうかを確認し、移行されていない場合はすぐに移行します。
- 負荷が低下したときに「古いアプリ」サーバーを段階的にシャットダウンし、新しいアプリにアップグレードして、新しいアプリのロードバランサープールに追加します。
- セッションが終了すると、顧客データが新しいデータベースに移行されます。
- ロードが許す限り、非アクティブな顧客データを新しいデータベースに移行します。
もちろん、これはもっと複雑です。2つの環境で顧客データへのアクセスを維持し、段階的に移行する必要があるためです。
ただし、何らかの問題に気付いた場合は、変更をロールバックすることができます。たとえば、新しいアプリサーバーの1つでCPUやメモリを過剰に使用している場合などです。
追加のサーバーの予算がない小規模なサイトの場合、複数のIPアドレス、または何らかの形式の内部負荷分散ソフトウェアを使用して古いサイトまたは新しいサイトにリクエストをルーティングするだけで、これを実現できる場合があります。これは問題をさらに複雑にする可能性があります。
古いアプリと新しいアプリを同じデータストア（バックエンドWebサービス、データベースなど）から実行できない場合、アプリは古いものと新しいものの間でデータを同期する必要があることを認識する必要があります。顧客データの保存/更新中に、書き込みは両方の場所で発生する必要があります。
于 2009-10-08T15:48:04.957 に答える
1
数時間かかります。データベースに多くの変換がある場合は、最初にデータベースのコピーを取り、変換を完了し、新しいサイトをセットアップし（ただし、少し古いデータベースを使用）、取得してから何が変わったかを確認します。コピーし、それも変換して（多くの変更がない場合は、大きなダンプよりも高速であるはずです）、新しいデータベースに挿入します。
バックアップすることを忘れないでください！
于 2009-10-08T16:09:23.650 に答える
0
アップグレードするデータベースのみの場合は、新しいデータベースを作成し、準備ができたらすぐに元に戻します。コードのアップロードについて話している場合は、コードを別のディレクトリにアップロードし、mv準備ができたらアップロードします。開発環境で同様の設定をしている場合は、問題にはなりません。
また、月額20ユーロ（キムスフィなど）のような非常に安価なサーバーをレンタルして、アップグレードを行うこともできます。
于 2009-10-08T15:18:44.203 に答える
0
いずれにせよ、ウェブホスティングとドメインネームプロバイダーの全面的な協力が絶対に必要だと思います。
大まかな手順は次のとおりです。
- 新しいサイトを展開する場所となる別のIPアドレスで新しいサーバーをレンタルします。または、可能であれば、一般にアクセスできないサイト内にテストサブドメインを作成します。
- 新しいサーバー/サブドメインにサイトをデプロイします。最初にIPまたはサブドメインを使用して、新しいサイトで必要なすべてのテストを実行します。
- すべてが問題ないことを確認したら、最初に新しいサーバー/サブドメインへのリダイレクトを発行します。
- DNSを新しいIPアドレスにリダイレクトするか、メインドメインがサブドメインの元の場所を指すように修正します。
理想的には、サイトがダウンしていることに誰も気付かないでしょう。または、ダウンタイムがある場合は、数分しか持続しません。
于 2009-10-08T15:22:16.240 に答える
0
ケーキを食べて食べたいようですね。
アップグレードが数時間かかる手動のジョブである場合は、ジョブのスクリプトを作成してアップグレードを高速化してみませんか。
于 2009-10-08T15:23:01.280 に答える
0
これはおそらく、現在のリリースにすでに「設計」されている必要があるものです。
一部のパーツ（カタログなど）は利用可能ですが、他のパーツ（購入など）はアップグレードされるようにセグメント化できますか？
キャッシュを使用して読み取り専用バージョンを作成できますか？
または、サービスの停止が許容される時間帯は確かにありますか？日曜日の夜に働きますか？非常に主要なWebサイトでさえ、機能の一部が利用できないメンテナンスウィンドウがいくつかあります。
于 2009-10-08T15:27:53.033 に答える