11

質問: Django を使用しているときに、ダウンタイムを 0 (または 0 に限りなく近づける) にするための優れた戦略は何ですか?

私が読んだ答えのほとんどは、「南を使用する」または「生地を使用する」と言っていますが、それらは非常に漠然とした答えです。私は実際に両方を使用していますが、ダウンタイムをできるだけゼロにする方法をまだ考えています。

いくつかの詳細:

私は EC2 でホストしている適切なサイズの Django アプリケーションを持っています。スキーマとデータの移行には Southを使用し、一連のJenkins (継続的インテグレーション サーバー)タスクによってトリガーされる繰り返しの展開/バックアップ タスクを自動化するにはbotoを使用したファブリックを使用します。私が使用するデータベースは、標準の PostgreSQL 9.0 インスタンスです。

私は...

  1. すべての新しいコンテンツを使用してチームによって常に編集され、最新かつ最高のコードと...

  2. ユーザー アカウントとユーザー データで変化し続けるライブ サーバー- すべて PostgreSQL に記録されます。

現在の展開戦略:

新しいコードとコンテンツをデプロイすると、両方のサーバー (ライブとステージング) の 2 つの EC2 スナップショットが作成されます。ライブは「新しいコンテンツを更新中」ページに切り替わります...

ダウンタイムが始まります。

ライブ クローン サーバーは、ステージング サーバーと同じスキーマ バージョンに移行されます (South を使用)。ライブから保存したいテーブルとシーケンスのみのダンプが作成されます (特に、ユーザー アカウントとそのデータ)。これが完了すると、ダンプがステージング クローン サーバーにアップロードされます。ライブから保存されたテーブルは切り捨てられ、データが挿入されます。私のライブサーバーのデータが大きくなるにつれて、この時間は明らかに増加し続けます.

ロードが完了すると、ライブ サーバーのエラスティック IP がステージング クローンに変更されます (したがって、新しいライブ サーバーに昇格されます)。ライブ インスタンスとライブ クローン インスタンスが終了します。

ダウンタイムが終了します。

はい、これは機能しますが、データが大きくなるにつれて、私の「仮想」ゼロ ダウンタイムはどんどん遠ざかっていきます。もちろん、どういうわけかレプリケーションを活用し、PostgreSQL のレプリケーションと「結果整合性」のアプローチを検討し始めることは私の頭をよぎりました。おそらくロードバランサーでできる魔法があることは知っていますが、その間に作成されたアカウントの問題がそれを難し​​くしています。

何を見ることをお勧めしますか？

更新：

典型的な Django 単一ノード アプリケーションがあります。私は、django 固有の問題をより深く掘り下げた解決策を望んでいました。たとえば、レプリケーションと並行してカスタム ルーターを使用して複数のデータベースをサポートする Django を使用するというアイデアは、私の頭をよぎりました。答えが触れられることを願っていることに関連する問題があります。

4

4 に答える 4

4

興味深いのは、カナリア リリースと呼ばれる手法です。昨年、アムステルダムで開催されたソフトウェア カンファレンスで Jez Humble の素晴らしいプレゼンテーションを見ました。リスクの低いリリースに関するものでした。スライドはこちら.

すべてのシステムを一度に切り替えるのではなく、少数のユーザーを新しいバージョンに移行するという考え方です。新しいシステムのすべてのパフォーマンス メトリックが期待どおりである場合にのみ、他のシステムも同様に切り替えられます。この手法は、Facebook などの大きなサイトでも使用されていることを知っています。

于 2012-05-23T06:55:34.990 に答える
2

ライブサーバーは移行されるべきではありません。そのサーバーには、server0とserver1の2つのステージングサーバーからアクセスできる必要があります。最初は、server0が稼働しており、server1に変更が加えられています。ソフトウェアを変更したい場合は、ライブサーバーを切り替えてください。新しいコンテンツに関しては、それはステージングサーバー上にあるべきではありません。それはライブサーバー上にあるはずです。コンテンツテーブルのバージョン番号を使用してテーブルに列を追加し、コンテンツの正しいバージョン番号を使用するようにコードベースを変更します。必要に応じてバージョン番号を更新して、古いバージョンを新しい行にコピーするソフトウェアを開発します。server0とserver1のsettings.pyに現在のバージョン番号を入力して、データを選択するときにソフトウェアが参照する中心的な場所を確保したり、コンテンツの正しいバージョンを取得するために更新できるデータベースアクセスアプリを作成したりします。もちろん、

このアプローチにより、ダウンタイムがなくなります。ソフトウェアの一部を書き直す必要がありますが、変更可能なデータベースアクセス方法など、一般的なアクセス方法を見つけた場合は、それほど手間がかからない場合があります。システムの即時切り替えを具体的にサポートするシステムを作成するための先行投資は、長期的にははるかに少ない作業であり、任意のコンテンツサイズに拡張可能です。

于 2012-05-25T23:10:35.017 に答える
1

私の理解が正しければ、データがスキーマと共に新しいデータベースに復元されている間に、アプリケーションがダウンしていることが問題のようです。

そもそも、なぜ新しいサーバーを作成するのですか? データベースをその場で移行しないのはなぜですか (もちろん、移行を広範囲にテストした後で)、これが完了したら、コードを更新してプロセスを「再起動」します (たとえば、gunicorn は、HUP シグナルを受け入れることができます。キュー内の接続をドロップせずにアプリケーションをリロードします)。

多くの移行では、データベース テーブルをまったくロックする必要がないため、これは安全です。残りについては、それを行う他の方法があります。たとえば、最初に正しいデータを入力する必要がある新しい列を追加する場合は、次の手順でそれを行うことができます (簡単に説明します)。

  1. NULL 値を受け入れる列を追加し、django がその列への書き込みを開始するようにして、新しいエントリに正しいデータが含まれるようにします。
  2. 既存のエントリを入力します。
  3. django も新しい列から読み取りを開始します。
于 2012-05-23T16:30:58.797 に答える
0

ダウンタイム 0 を達成するには、少なくとも 2 台のサーバーとバランサーが必要です。そして、それらを順次更新します。データベースとアプリケーションの両方を更新し、ダウンタイムをゼロにしたい場合は、2 つの db サーバーが必要です。奇跡も特効薬もありません。django を使用しても展開の問題から抜け出すことはできません。

于 2012-06-01T10:02:28.123 に答える