序章

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

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

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

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

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

長所：

  • 単純

短所：

  • アプリケーションとデータベースは同じサーバーリソース（CPU、メモリ、I / Oなど）をめぐって競合します。これは、パフォーマンスの低下の可能性は別として、パフォーマンスの低下の原因（アプリケーションまたはデータベース）の特定を困難にする可能性があります。
  • 水平方向にスケーラブルではない

関連チュートリアル：

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

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

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

長所：

  • アプリケーション層とデータベース層は、同じサーバーリソース（CPU、メモリ、I / Oなど）をめぐって競合しません。
  • 容量を増やす必要があるサーバーにリソースを追加することで、各層を個別に垂直方向にスケーリングできます。
  • 設定によっては、データベースをDMZから削除することでセキュリティを強化できる場合があります

短所：

  • 単一サーバーよりも少し複雑なセットアップ
  • 2つのサーバー間のネットワーク接続の待ち時間が長い場合（つまり、パフォーマンスの問題が発生する可能性があります） サーバーが地理的に離れている）、または転送されるデータの量に対して帯域幅が低すぎる

関連チュートリアル：

3. ロードバランサー（リバースプロキシ）

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

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

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

長所：

  • 水平スケーリングを有効にします。 サーバーを追加することで、環境容量を拡張できます
  • クライアント接続を適切な量と頻度に制限することにより、DDOS攻撃から保護できます

短所：

  • ロードバランサーは、十分なリソースがない場合、または構成が不十分な場合、パフォーマンスのボトルネックになる可能性があります。
  • SSLターミネーションを実行する場所や、スティッキーセッションを必要とするアプリケーションの処理方法など、追加の考慮が必要な複雑さをもたらす可能性があります
  • ロードバランサーは単一障害点です。 ダウンすると、サービス全体がダウンする可能性があります。 高可用性（HA）セットアップは、単一障害点のないインフラストラクチャです。 HAセットアップの実装方法については、予約済みIPの使用方法のこのセクションをお読みください。

関連チュートリアル：

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

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

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

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

長所：

  • キャッシュと圧縮により、WebサーバーのCPU負荷を軽減し、ユーザー容量を増やすことで、サイトのパフォーマンスを向上させます
  • リバースプロキシロードバランサーとして使用できます
  • 一部のキャッシングソフトウェアは、DDOS攻撃から保護できます

短所：

  • 最高のパフォーマンスを引き出すにはチューニングが必要です
  • キャッシュヒット率が低いと、パフォーマンスが低下する可能性があります

関連チュートリアル：

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つの単一障害点（ロードバランサーとプライマリデータベースサーバー）がありますが、上記の各セクションで説明した他のすべての信頼性とパフォーマンスの利点があります。

結論

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

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