開発者ドキュメント

Webアプリケーションの5つの一般的なサーバー設定

序章

環境に使用するサーバーアーキテクチャを決定する際には、パフォーマンス、スケーラビリティ、可用性、信頼性、コスト、管理のしやすさなど、考慮すべき多くの要素があります。

これは、一般的に使用されるサーバーセットアップのリストであり、それぞれの長所と短所を含む簡単な説明があります。 ここで説明するすべての概念は、互いにさまざまな組み合わせで使用でき、環境ごとに要件が異なるため、単一の正しい構成は存在しないことに注意してください。

1. 1台のサーバー上のすべて

環境全体が単一のサーバー上にあります。 一般的なWebアプリケーションの場合、これにはWebサーバー、アプリケーションサーバー、およびデータベースサーバーが含まれます。 このセットアップの一般的なバリエーションは、単一サーバー上のLinux、Apache、MySQL、およびPHPを表すLAMPスタックです。

ユースケース:可能な限り最も簡単なセットアップであるため、アプリケーションをすばやくセットアップするのに適していますが、スケーラビリティとコンポーネントの分離の点でほとんど提供されません。

長所

短所

関連チュートリアル

2. 別のデータベースサーバー

データベース管理システム(DBMS)を他の環境から分離して、アプリケーションとデータベース間のリソース競合を排除し、データベースをDMZまたはパブリックインターネットから削除することでセキュリティを強化できます。

ユースケース:アプリケーションをすばやくセットアップするのに適していますが、アプリケーションとデータベースが同じシステムリソースをめぐって争うのを防ぎます。

長所

短所

関連チュートリアル

3. ロードバランサー(リバースプロキシ)

ロードバランサーをサーバー環境に追加して、ワークロードを複数のサーバーに分散することにより、パフォーマンスと信頼性を向上させることができます。 負荷分散されたサーバーの1つに障害が発生した場合、障害が発生したサーバーが再び正常になるまで、他のサーバーが着信トラフィックを処理します。 また、レイヤー7(アプリケーションレイヤー)リバースプロキシを使用して、同じドメインとポートを介して複数のアプリケーションにサービスを提供するために使用することもできます。

リバースプロキシの負荷分散が可能なソフトウェアの例:HAProxy、Nginx、Varnish。

ユースケース:サーバーを追加してスケーリングする必要がある環境で役立ちます。これは水平スケーリングとも呼ばれます。

長所

短所

関連チュートリアル

4. HTTPアクセラレータ(リバースプロキシのキャッシュ)

HTTPアクセラレータまたはキャッシングHTTPリバースプロキシを使用すると、さまざまな手法でユーザーにコンテンツを提供するのにかかる時間を短縮できます。 HTTPアクセラレータで採用されている主な手法は、Webまたはアプリケーションサーバーからの応答をメモリにキャッシュすることです。これにより、同じコンテンツに対する将来の要求を迅速に処理でき、Webサーバーまたはアプリケーションサーバーとの不要なやり取りが少なくなります。

HTTPアクセラレーションが可能なソフトウェアの例:Varnish、Squid、Nginx。

ユースケース:コンテンツの多い動的Webアプリケーション、または一般的にアクセスされるファイルが多数ある環境で役立ちます。

長所

短所

関連チュートリアル

5. プライマリレプリカデータベースレプリケーション

CMSなどの書き込みと比較して多くの読み取りを実行するデータベースシステムのパフォーマンスを向上させる1つの方法は、プライマリレプリカデータベースレプリケーションを使用することです。 レプリケーションには、1つのプライマリノードと1つ以上のレプリカノードが必要です。 この設定では、すべての更新がプライマリノードに送信され、読み取りをすべてのノードに分散できます。

ユースケース:アプリケーションのデータベース層の読み取りパフォーマンスを向上させるのに適しています。

次に、単一のレプリカノードを使用したプライマリレプリカレプリケーションのセットアップの例を示します。

長所

短所

関連チュートリアル

例:概念の組み合わせ

アプリケーションサーバーに加えて、キャッシングサーバーの負荷を分散し、単一の環境でデータベースレプリケーションを使用することができます。 これらの手法を組み合わせる目的は、あまり多くの問題や複雑さを導入することなく、それぞれのメリットを享受することです。 サーバー環境がどのように見えるかの図の例を次に示します。

ロードバランサーが静的リクエスト(画像、css、javascriptなど)を認識し、それらのリクエストをキャッシュサーバーに直接送信し、他のリクエストをアプリケーションサーバーに送信するように構成されていると仮定します。

ユーザーがリクエストの動的コンテンツを送信するとどうなるかについての説明は次のとおりです。

  1. The user requests dynamic content from _http://example.com/_ (load balancer)
  2. ロードバランサーはアプリバックエンドにリクエストを送信します
  3. app-backendはデータベースから読み取り、要求されたコンテンツをロードバランサーに返します
  4. ロードバランサーは、要求されたデータをユーザーに返します

ユーザーが静的コンテンツを要求した場合:

  1. ロードバランサーは、キャッシュバックエンドをチェックして、要求されたコンテンツがキャッシュされているか(cache-hit)、キャッシュされていないか(cache-miss)を確認します。
  2. cache-hit の場合:要求されたコンテンツをロードバランサーに返し、ステップ7にジャンプします。 cache-miss の場合:キャッシュサーバーは、ロードバランサーを介してリクエストをアプリバックエンドに転送します
  3. ロードバランサーはリクエストをアプリバックエンドに転送します
  4. app-backendはデータベースから読み取り、要求されたコンテンツをロードバランサーに返します
  5. ロードバランサーは応答をキャッシュバックエンドに転送します
  6. cache-backend はコンテンツをキャッシュし、それをロードバランサーに返します
  7. ロードバランサーは、要求されたデータをユーザーに返します

この環境には、依然として2つの単一障害点(ロードバランサーとプライマリデータベースサーバー)がありますが、上記の各セクションで説明した他のすべての信頼性とパフォーマンスの利点があります。

結論

これで、いくつかの基本的なサーバーセットアップに精通したので、自分のアプリケーションにどのようなセットアップを使用するかについての良いアイデアが得られるはずです。 独自の環境の改善に取り組んでいる場合は、あまりにも多くの複雑さをすぐに導入しないように、反復プロセスが最善であることを忘れないでください。

以下のコメントで、推奨するセットアップや詳細を知りたいセットアップをお知らせください。

モバイルバージョンを終了