アプリケーションのセットアップ：最適なサーバー構成の選び方とは？

はじめに

テクノロジーとインターネットは、私たちの日常生活、学術生活、そして職業生活において中心的な存在となっています。そのため、非常に多くのウェブサイトやアプリケーションが同時に存在していることも驚きではありません。企業であれば、関連するウェブプラットフォームを持ちたいと思うでしょう。アプリケーションを利用することで、ターゲットとなる顧客に対して自社のサービスを容易にマーケティングし、提供することができます。

どのような理由でウェブアプリケーションを作成するにしても、それをどのように構築するかを決定する必要があります。選択肢は数多くあります、最適なサーバー構成を選択する際には。選択したサーバーアーキテクチャによって、環境内のすべてをどのように実行し管理するかが決まります。そのため、この決定は慎重に検討した上で行う必要があります。

最適なサーバー構成の選び方

では、自分のアプリケーションに「適した」アーキテクチャをどのように決定すればよいでしょうか？そのためには、まずウェブアプリケーションの要件が何であるかを考える必要があります。特定のユースケースで効率的に動作させるために、組み込まなければならない特定の機能があるはずです。例えば、拡張（スケール）しやすいアプリケーションを目指しているかもしれません。あるいは、モバイルデバイスだけでなくブラウザ上でもスムーズに動作するアプリケーションが必要かもしれません。同時に、予算が最大の関心事である場合もあるでしょう。

要件が何であれ、アプリケーションに合わせてカスタムソリューションを作成できることを知っておくべきです。このチュートリアルでは、多くの人がウェブアプリケーションで一般的に使用しているさまざまな種類のサーバーについて探っていきます。さまざまなユースケースと、特定の構成がどのような場合に最適であるかについて説明します。それが自分に適しているかどうかを判断しやすくするために、各サーバーアーキテクチャのメリットとデメリットも紹介します。

1. すべてを1台のサーバーに集約

名前が示すように、環境全体を1台の単一サーバーにロードします。この環境には、ウェブサーバー、アプリケーションサーバー、およびデータベースサーバーが含まれます。例えば、これはLinux, Apache, MySQL、およびPHP（LAMP）スタック構成で動作します。UbuntuサーバーにLAMPスタックをインストールする方法や、CentOSにLAMPスタックをインストールする方法については、当社のチュートリアルを参照してください。UbuntuサーバーにLAMPスタックをインストールする方法およびCentOSにLAMPスタックをインストールする方法.

使用すべきケース：

このタイプの配置は、時間がない場合に最適です。セットアップがシンプルで迅速に行えます。そのため、シンプルなウェブアプリケーションに適しています。

メリット：

• シンプルで、理解しやすく、実装も容易です。
• 全体をセットアップするのにほとんど時間がかかりません。

デメリット：

• 水平方向のスケール（拡張）ができません。
• コンポーネントの分離という点では、ほとんどメリットがありません。
• アプリケーションとデータベースが単一のサーバー上にあるため、本質的に同じリソースを奪い合うことになります。
• その結果、パフォーマンスが低下する可能性があります。

2. データベースサーバーの分離

単一のサーバーを使用する場合の主な問題は、限られたリソースの奪い合いです。この構成はその問題の解決を目指しています。ここでは、データベース管理システム（DBMS）をアプリケーションサーバーから分離して保持します。データベースサーバーはプライベートネットワーク内に配置され、独自のリソースを持ちます。これにより、パフォーマンスが向上し、セキュリティが強化されます。

使用すべきケース：

これも、迅速なセットアップを展開したい場合、構成は非常にシンプルです。データベースとアプリケーションが同じリソースを奪い合うことを懸念している場合には、理想的なソリューションです。

メリット：

• アプリケーションとデータベースのそれぞれに、CPU、メモリ、I/Oなどの専用のシステムリソースが個別に割り当てられます。
• アプリケーション層またはデータベース層のいずれにおいても、拡張（スケール）の可能性が高まります。
• 必要に応じてリソースを追加または削除できます。
• データベースを公開インターネットから排除することで、セキュリティを大幅に強化することもできます。

デメリット：

• 単一サーバーのセットアップよりも少し複雑になります。
• 2台のサーバー間のネットワーク接続の帯域幅が狭かったり、遅延（レイテンシ）が大きかったりすると、パフォーマンスの問題が発生する可能性があります。

3. リバースプロキシまたはロードバランサー

ここで登場するのがロードバランサー が登場します。ロードバランサーは通常、パフォーマンスと信頼性を向上させるためにサーバー環境で使用されます。これは「負荷を分散する」、つまり一連のサーバー群にワークロードを分散させることによって行われます。

いつ使用するか：

ロードバランサーは、水平スケーリングを行う必要がある場合に非常に便利です。水平スケーリングとは、基本的に環境にサーバーを追加することを意味します。また、アプリケーション層のリバースプロキシを使用して、1つのドメインとポートで複数のアプリケーションを同時に提供することもできます。 HAProxy, Nginx、および Varnish は、リバースプロキシによるロードバランシングを可能にするソフトウェアの例です。

メリット：

• 構成内の1台のサーバーが停止した場合でも、他のサーバーがワークロードを分散することでその機能を補います。
• 水平スケーリングを実行して、環境の容量を増減させることができます。
• また、クライアントの接続数を制限するため、DDoS攻撃に対する保護にもなります。

デメリット：

• システムリソースが不足している場合、ロードバランサーがアプリケーションのパフォーマンスを制限してしまう可能性があります。
• 適切なパフォーマンスを確保するには、適切な設定が必要です。
• 単一サーバーや個別サーバーの構成よりも大幅に複雑になります。
• SSL終端や、スティッキーセッションを必要とするアプリケーションなどの要因を考慮する必要があります。
• ロードバランサーを使用する上での最大の懸念点は、それが単一障害点（SPOF）になることです。つまり、ロードバランサーが機能しなくなると、サービス全体が停止してしまいます。

4. HTTPアクセラレーターまたはキャッシュリバースプロキシ

これは、アプリケーションのユーザーにコンテンツを配信する速度を向上させるために使用できる構成です。この時間を短縮するために、さまざまな技術が採用されています。最も重要なのは、アプリケーションサーバーからのレスポンスをキャッシュすることです。アクセラレーターは、ユーザーが最初にコンテンツをリクエストしたときに、そのコンテンツをメモリに保存します。そのため、将来同様のリクエストがあった場合、アプリケーションサーバーとやり取りすることなく、コンテンツを迅速に提供します。Nginx、Varnish、および Squid は、HTTPアクセラレーション.

いつ使用するか：

当然のことながら、この構成はユーザーが非常に頻繁にリクエストするファイルやコンテンツに最も適しています。また、コンテンツ量の多い動的なウェブアプリケーションでも非常にうまく機能します。

メリット：

• キャッシュと圧縮により、アプリケーションの速度とリクエスト処理能力が大幅に向上します。
• CPUへの負荷が軽減されるため、サイトのパフォーマンスも向上します。
• これをリバースプロキシロードバランサーとして使用することもできます。

デメリット：

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

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

プライマリ・レプリカ型のデータベースレプリケーション構成は、通常、書き込みよりも読み取りが多いシステムで非常に役立ちます。例えば、コンテンツ管理システム（CMS）などは、このようなアーキテクチャを大いに活用できます。レプリケーションには、1つのプライマリノードと1つ以上のレプリカノードが必要です。読み取りはすべてのノードに分散されます。更新はプライマリノードにのみ送信されます。

いつ使用するか：

前述のように、レプリケーションベースのデータベース構成はシステムの読み取りパフォーマンスの向上に役立ちます。CMSのようなアプリケーションに使用できます。

メリット：

• 読み取り処理をレプリカ全体に分散させるため、データベースの読み取りパフォーマンスが向上します。
• プライマリノードを更新処理専用にすれば、書き込みパフォーマンスを向上させることもできます。

デメリット：

• データベースにアクセスしようとするアプリケーションは、更新リクエストと読み取りリクエストをどのノードに送信するかを判断できなければなりません。
• プライマリレプリカが故障した場合、更新は停止します。更新を再開するには、問題を解決する必要があります。
• プライマリノードの潜在的な障害に対応するためのフェイルオーバーメカニズムはありません。

サーバー構成の組み合わせ

幸いなことに、さまざまな手法を組み合わせて望ましい結果を得ることも可能です。つまり、単一の環境でアプリケーションサーバーとキャッシュサーバーの負荷分散を行い、データベースをレプリケートすることができます。これにより、両方のサーバーの機能を最大限に活用できます。しかし、それによってセットアップが複雑になったり面倒になったりすることはありません。

例：

例を挙げて、このような環境について理解を深めていきましょう：

このような環境では、ロードバランサーは静的リクエストをキャッシュサーバーに送信します。静的コンテンツ には、CSS、画像、Javascriptなどが含まれます。それ以外の種類のコンテンツリクエストは、代わりにアプリケーションサーバーに転送されます。

ユーザーが環境から何らかの静的コンテンツをリクエストしているとします。その場合、以下のような処理が行われます：

• ロードバランサーはまず、コンテンツがキャッシュヒットかキャッシュミスかを判断します。キャッシュヒットしたコンテンツはキャッシュ内に存在しますが、キャッシュミスしたコンテンツは存在しません。これは、キャッシュバックエンドに確認することで行われます。
• キャッシュヒットの場合、ロードバランサーはコンテンツをユーザーに送信します。
• キャッシュミスの場合、キャッシュサーバーはリクエストをアプリケーションのバックエンドに転送します。
• アプリケーションバックエンドは、データベースからコンテンツを検索して送信します。
• キャッシュバックエンドはロードバランサーからコンテンツを受信します。また、このコンテンツをロードバランサーに返す前にキャッシュします。
• その後、後者（ロードバランサー）がレスポンスをユーザーに転送します。

一方、ユーザーが動的コンテンツをリクエストした場合は、以下のようになります：

• リクエストはユーザーからロードバランサーに届きます。
• このリクエストはアプリケーションバックエンドに送られます。
• アプリケーションバックエンドはリクエストされたコンテンツを特定し、ロードバランサーに返します。
• ユーザーがコンテンツを受信します。

このような複合環境の主なメリットの1つは、信頼性が向上することです。それだけでなく、優れたパフォーマンス機能も備えています。ただし、ロードバランサーとプライマリデータベースサーバーという2つの単一障害点が依然として存在します。

結論

各サーバーのセットアップは、環境内で単独で使用できます。一方で、それらのいくつかを組み合わせて、パーソナライズされたソリューションを作成することもできます。「正解」はありません。すべては、アーキテクチャからどのような機能を引き出したいかによって決まります。

各サーバーセットアップの仕組みに関する基礎レベルの知識を持つことは、独自のアプリケーションに関する決定を下すのに役立ちます。最善の方法は、小さくシンプルに始めることです。経験を積むにつれて、セットアップの複雑さを徐々に増していくことができます。

ハッピーコンピューティング！