2

分散 Python アプリケーションの耐久性のあるアーキテクチャについて知りたい。 私が以前に尋ねたこの質問は、それがどのような種類のアプリケーションであるかについての少しのガイダンスを提供するはずです. 私たちは、複数のコード サーバーと複数のデータベース サーバーを使用できるようにしたいと考えています。また、理想的には、管理しやすく、あまり負担にならない展開方法が必要です。

私が言及した質問は私が好きな答えを提供しますが、どうすれば耐久性を高めることができるのでしょうか、それには他の技術を使用する必要があるのでしょうか. 特に：

フロントエンド エンドポイントを WSGI にして (既に記述されているため)、メッセージ経由で配布されるバックエンドを記述します。次に、Celery キューからメッセージを取り出して必要な作業を完了するバックエンド ノードのプールを作成します。次のようになります。

Apache -> WSGI Containers -> Celery Message Queue -> Celery Workers。

Apache ノードは、ある種のロード バランサーの背後にあります。これは、スケーリングが非常に単純なアーキテクチャであり、正しく実行されれば、かなり信頼性があります。このようなシステムでの障害のコードであり、問​​題ありません。

永続的なアプリケーションを作成するための最良の方法は何ですか? 「失敗に備えてコーディングする」方法や、必ずしもそうする必要がないように別の方法で設計する方法についての提案はありますか? Python がこれに適していないと思われる場合、それも有効な解決策です。

4

1 に答える 1

3

私が与えた前の答えを続けます。

私のプロジェクトでは、ホスティングのニーズの多くに AWS を使用しているため、失敗に備えてコーディングしています。

データベース、リージョンにアクセスできることを確認するデータベース バックエンドを実装しました。そうでない場合は、指定されたリストから別のリージョンを選択します。これは、そのノードの残りのシステムに対して透過的に行われます。そのため、east-1a リージョンがダウンした場合、西海岸など、フェールオーバーする他のいくつかのリージョンもホストしています。現在進行中のデータベース トランザクションを追跡し、それらを西海岸に送信してファイルにダンプし、古いデータベース リージョンが利用可能になったらインポートできるようにします。

私のフロント エンド サーバーは、複数のリージョンに分散されたエラスティック ロード バランサーの背後にあり、これにより、リージョンに障害が発生した場合の永続的な復旧が可能になります。しかし、頼りにならないので、HAProxy を実行して、ELB がダウンした場合に DNS を切り替えるなどの解決策を検討しています。これは進行中の作業であり、私自身の解決策について具体的に説明することはできません.

データ処理を耐久性のあるものにするには、Celery を調べ、データを分散型 mongo サーバーに保存して、結果を安全に保ちます。耐久性のあるデータ ストアを使用して結果を保持することで、ノードがクラッシュした場合に結果を取り戻すことができます。ある程度のパフォーマンスが犠牲になりますが、ソフト リアルタイムの制約のみに依存している場合は、それほどひどいものではありません。

http://www.mnxsolutions.com/amazon/designing-for-failure-with-amazon-web-services.html

上記の記事では主に AWS について説明していますが、その考え方は、高可用性とシステムの耐久性を維持する必要があるすべてのシステムに当てはまります。ユーザーのサブセットに対してダウンタイムを最小限に抑える限り、ダウンタイムは問題ないことを覚えておいてください.

于 2012-11-06T17:03:35.383 に答える