原作者: アダム・チャーノック
元のリンク: PHP 負荷分散のヒッチハイク ガイド
翻訳: Koda は、
大規模な Web アプリケーションを実行するときに、大規模な Web サーバーを実行することを意味していました。アプリケーションには多数のユーザーが集まるため、サーバーにメモリとプロセッサを追加する必要があります。
現在、「大規模サーバー」モデルは廃止され、さまざまな負荷分散技術を使用した多数の小規模サーバーに置き換えられています。これは、ハードウェアのコストを最小限に抑える、より実現可能なアプローチです。
過去の「大規模サーバー」モデルに対する「小規模サーバーの増加」の利点は 2 つの側面に反映されています。
サーバーがダウンした場合、負荷分散システムはダウンしたサーバーへのリクエストを停止し、代わりに正常に実行されている他のサーバーに負荷を分散します。 。 優れた。
サーバーの拡張が簡単になります。必要なのは、負荷分散システムに新しいサーバーを追加することだけです。アプリケーションを中断する必要はありません。
したがって、この機会を活用してください :) もちろん、その代償として、アプリケーション開発がもう少し複雑になる必要があります。それがこの記事の内容です。
この時点で、「でも、ロード バランシングを使用していることをどうやって確認すればよいでしょうか?」と思っているかもしれません。 '。この質問をしている場合の最も正直な答えは、おそらく負荷分散システムを使用していないし、システムは負荷分散システムを考慮する必要がない、というものです。ほとんどの場合、アプリケーションが十分に大きくなると、負荷分散を明示的に提案して設定する必要があります。ただし、Web ホスティング会社が顧客のアプリケーションに対してこの負荷分散を実行しているか、以下で説明するように自社で実行しているのを時々見かけます。
以下に進む前に、この記事では主に PHP の負荷分散について説明していることを指摘しておきます。将来、データの負荷分散について書くかもしれませんが、今は待ってください。
Web サイトではなく「Web アプリケーション」と繰り返し言及していることに注意してください。これは、「Web アプリケーション」が、単純な静的コンテンツのみを表示する Web サイトではなく、サーバー側のプログラミングやデータベースを含む複雑なサイトであることを区別するためです。
1. PHP ファイル 最初の質問は、小規模サーバーが多数ある場合、どのようにして PHP ファイルをすべてのサーバーにアップロードするかということです。参考までに、
すべてのファイルを各サーバーに個別にアップロードする方法があります。この方法の問題点は、サーバーが 20 台あるとすると、アップロード プロセス中にエラーが発生しやすく、更新時間が非常に長くなってしまうことです。異なるサーバー上に異なるバージョンのファイルを置くことが可能です。
「rsync」（または同様のソフトウェア）を使用すると、ローカル ディレクトリ上のファイルと複数のリモート ホスト上のディレクトリを同期できます。
バージョン管理ソフトウェア (Subversion など) を使用します。これは私のお気に入りの方法です。これにより、コードを非常に適切に保守できるようになり、アプリケーションを公開するときに、各サーバーで svn update コマンドを実行してアプリケーションを同期できます。このアプローチにより、サーバーを以前のバージョンのコードに切り替えることも簡単になります。
ファイル サーバーを使用します (これには NFS が適しています) このアプローチは、ファイル サーバーを使用して Web アプリケーションをホストすることです。当然、ファイル サーバーがダウンすると、すべてのサイトが使用できなくなります。この時点で、復旧するにはさらに多くのお金が必要になります。
どの方法を選択するかは、ニーズと持っているスキルによって異なります。バージョン管理システムを使用している場合は、更新コマンドを同時に実行して、すべてのサーバー上のコードを更新する方法を計画するとよいでしょう。ただし、ファイル サーバーを使用する場合は、サーバーがダウンした場合にリクエストの失敗を防ぐために、何らかの障害回復メカニズムを実装する必要があります。
2. ファイルのアップロード サーバーが 1 台だけの場合、ファイルのアップロードは問題ありません。しかし、複数のサーバーがある場合、アップロードされたファイルはどのように保存されるべきでしょうか?ファイルのアップロードの問題は、クロスサーバー PHP ファイル ストレージに似ています。考えられる解決策は次のとおりです。
ファイルをデータベースに保存します。ほとんどのデータではバイナリ データを保存できます。ファイルのダウンロードを要求すると、アクセス データはバイナリ データと、対応するファイル名と種類をユーザーに出力します。このソリューションを使用する前に、データベースがファイルをどのように保存するかを検討する必要があります。この方法の問題は、データベース サーバーがダウンするとファイルが使用できなくなることです。
アップロードされたファイルをファイル サーバーに保存します。前の説明と同様に、すべての Web サーバーで共有されるようにファイル サーバーをインストールする必要があります。アップロード後、すべての Web サーバーがそれを使用できるようになります。ただし、ファイルサーバーがダウンしている場合、画像ファイルのダウンロードが中断される場合があります。
ファイルを各サーバーに転送するための独自のアップロード メカニズムを設計します。このアプローチには、単一のファイル サーバーまたはデータベース ソリューションの欠点はありませんが、コードが複雑になります。たとえば、複数のサーバーにアップロード中にサーバーがダウンしたらどうしますか?
データベースを使用してアップロードされたファイルを保存することもできますが、ファイル キャッシュ メカニズムを設計することは良い解決策です。サーバーはファイルのダウンロード要求を受信すると、まずファイルがキャッシュ システムに存在するかどうかを確認し、存在しない場合はデータベースからファイルを読み取り、ファイル システムにキャッシュします。
3. セッション
PHP のセッション処理に精通している場合は、デフォルトでセッション データがサーバー上の一時ファイルに保存されることをご存じでしょう。さらに、このファイルはリクエストしたサーバー上にのみ存在しますが、後続のリクエストは別のサーバーによって処理される可能性があり、その結果、他のサーバー上に新しいセッションが生成されます。これにより、ログインしたユーザーが常に再ログインを求められるなど、セッションが頻繁に認識されなくなります。
私が推奨する解決策は、PHP の組み込みセッション処理メカニズムを再確立してセッション データをデータベースに保存するか、独自のメカニズムを実装してユーザーのリクエストが確実に同じサーバーに送信されるようにすることです。
4. 構成
このトピックは PHP とは特に関係ありませんが、言及する必要があると感じます。クラスター化されたサーバーを実行する場合、サーバー間で構成ファイルの同期を保つ何らかの方法を用意することをお勧めします。構成ファイルに一貫性がない場合、非常に奇妙な断続的な動作が発生し、トラブルシューティングが困難になる可能性があります。
バージョン管理システムを使用して個別に管理することをお勧めします。この方法により、プロジェクトのインストールごとに異なる php 設定ファイルを保存し、すべてのサーバー設定ファイルの同期を保つことができます。
5. ロギング
設定の問題と同様、ロギングは PHP だけに関連するものではありません。ただし、サーバーを健全な状態に維持することは依然として非常に重要です。適切なログ システムがなければ、PHP コードでエラーが生成され始めたかどうかをどうやって知ることができるでしょうか (システムが稼動しているときは、常に display_errors 設定をオフにしますよね?)
ログ
を実装するには、いくつかの方法があります。
サーバ。 これが最も簡単な方法です。各マシンは 1 つのファイルのみを記録します。利点は、シンプルで構成がほとんど必要ないことです。ただし、サーバーの数が増えると、各サーバー上のログ ファイルを監視することが非常に困難になります。
共有へのログ記録 この方法でも各サーバーにログ ファイルが存在しますが、ログ ファイルは共有メカニズムを介して中央のファイル サーバーに保存されるため、ログの監視が容易になります。このソリューションの問題は、ファイル サーバーが利用できない場合、単純なログ書き込みの問題により、最終的にアプリケーション全体がクラッシュすることです。
ログ サーバーへのログ記録 syslog などのログ ソフトウェアを使用して、すべてのログを中央サーバーに書き込むことができます。この方法ではさらに多くの構成が必要になりますが、最も堅牢なソリューションも提供されます。
phpv の追加: もう 1 つの重要な点はデータベース管理ですが、これには多くの内容が含まれる可能性があるため、作成者はそれを記述しませんでした。