スタックオーバーフローチーム（パート1および2 ）へのScott Hanselmanのインタビューを聞いて、彼はSQLサーバーとアプリケーションサーバーを別々のマシンに配置する必要があると断言しました。これは、1つのサーバーが危険にさらされた場合に、両方のシステムにアクセスできないようにするためだけですか？セキュリティ上の懸念は、2台のサーバーの複雑さ（余分なコスト、2台間の専用ネットワーク接続、より多くのメンテナンスなど）を上回りますか？特に、どちらの部分もCPUやメモリを使いすぎていない小さなアプリケーションの場合はそうですか？2台のサーバーがあり、1台のサーバーが危険にさらされている場合でも、攻撃者はデータベースを削除するか、アプリケーションコードをいじることによって、深刻な損害を与える可能性があります。
パフォーマンスが問題にならないのに、なぜこれがそれほど大きな問題になるのでしょうか。
そうは言っても、これらの点が実際には問題にならない合理的なケースを確かに見ることができます。
それは実際には重要ではありません（同じマシン上でWeb /データベースを使用してサイトを非常にうまく実行できます）、それはスケーリングの最も簡単なステップです。
これはまさにStackOverflowが行ったことです。IIS/SQLServerを実行している単一のマシンから始めて、負荷が高くなり始めたときに、2台目のサーバーを購入し、SQLサーバーをその上に移動しました。
パフォーマンスが問題にならない場合は、2台のサーバーの購入/保守にお金を無駄にしないでください。
一方、別のブログを書いている Scott (Telligent の Watermasyck) を参照すると、ほとんどのユーザーは、データベースを Web サイトと同じマシンに置くことで (Telligent の Community Server を使用して) Web サイトを高速化できることがわかりました。ただし、顧客の場合、通常、db と web サーバーがそのマシン上の唯一のアプリケーションであり、web サイトはマシンにそれほど負担をかけていません。次に、ネットワークを介してデータを送信する必要がないという効率が、負担の増加を補いました。
これについてはトムが正しい。他の理由としては、費用対効果が低く、追加のセキュリティ リスクがあることです。
Web サーバーには、データベース サーバーとは異なるハードウェア要件があります。データベース サーバーは大量のメモリと非常に高速なディスク アレイを使用するとうまく機能しますが、Web サーバーはファイルをキャッシュするのに十分なメモリと頻繁な DB 要求 (セットアップによって異なります) しか必要としません。費用対効果に関しては、2 つのサーバーが必ずしも安価であるとは限りませんが、リソースを競合する異なるアプリケーションが必要ないため、パフォーマンスとコストの比率は高くなるはずです。このため、両方に対応し、2 つの特殊化されたサーバーと同等のパフォーマンスを提供する 1 つのサーバーには、おそらくより多くの費用を費やす必要があります。
セキュリティ上の懸念は、1 台のマシンが危険にさらされると、Web サーバーとデータベースの両方が脆弱になることです。2 台のサーバーを使用すると、2 番目のサーバーが (少なくともしばらくの間) 安全であるため、ある程度の余裕があります。
また、多数の異なる Web アプリケーションで使用されるいくつかのデータベース サーバーを維持するだけでよいため、スケーラビリティの利点もいくつかあります。こうすることで、アップグレードやパッチを適用したり、パフォーマンス チューニングを行ったりする作業が少なくなります。ただし、これらのタスクを簡単にするためのサーバー管理ツールがあると思います (単一マシンの場合)。
大きな要因はパフォーマンスだと思います。Webサーバー/アプリコードとSQLServerはどちらも、一般的に要求されるデータをメモリにキャッシュし、同じメモリスペースで実行することでキャッシュパフォーマンスを低下させます。
セキュリティは大きな懸念事項です。理想的には、データベース サーバーは、データ アクセスを実行するために必要なポートのみを開いた状態で、ファイアウォールの内側に配置する必要があります。Web アプリケーションは、アプリケーションが機能するのに十分な権限しか持たない SQL アカウントを使用してデータベース サーバーに接続する必要があります。たとえば、オブジェクトのドロップを許可する権限を削除する必要があります。また、'sa' などのアカウントを使用して接続するべきではありません。
ハイジャックによって Web サーバーを失った場合 (つまり、管理者権限への本格的な権限昇格)、最悪のシナリオは、データベース サーバー全体ではなく、アプリケーションのデータベースが危険にさらされる可能性があることです (データベース サーバーと Web サーバーは同じマシンでした)。データベース接続文字列を暗号化し、ハッカーがそれらを復号化するのに十分な知識を持っていない場合、失われたのは Web サーバーだけです。
まだ言及されていない要因の 1 つは、負荷分散です。Web サーバーとデータベースを別々のマシンと考えることから始めると、ネットワーク ラウンド トリップが少なくなるように最適化され、必要に応じて 2 つ目の Web サーバーまたは 2 つ目のデータベース エンジンを簡単に追加できるようになります。
私はDanielEarwickerに同意します-セキュリティの質問にはかなり欠陥があります。
Webサーバーを使用して単一のボックスをセットアップし、そのWebサーバーのデータベースのみを使用している場合、そのWebサーバーが危険にさらされると、Webサーバーとその特定のアプリケーションのデータベースの両方が失われます。
これは、2サーバー設定でWebサーバーを失った場合に発生することとまったく同じです。Webサーバーが失われ、その特定のアプリケーションのデータベースだけが失われます。
最初のシナリオでは、他のすべてのアプリケーション（存在する場合）に関連する他のすべてのデータベースサーバーも影響を受けないため、2サーバーのセットアップがある場合に「DBサーバーの残りの整合性が維持される」という議論は関係ありません。 -そのまま、他の場所でホストされている。
同様に、Kevが提起した質問に対して、DBサーバー上にある他のすべてのデータベースについてはどうでしょうか。失ったのは1つのデータベースだけです。」
対照的に、攻撃者がWebサーバーにアクセスでき、プロキシによってデータベースサーバーへの権限が制限されている（最良のシナリオでは）2サーバーのセットアップでは、他のすべてのアプリケーションのデータベースを実行することで危険にさらされる可能性があります。低速でメモリを大量に消費するクエリを実行したり、データベースサーバーで使用可能なストレージスペースを最大化したりします。仮想化と非常によく似たように、アプリケーションを独自の懸念事項に分離することで、セキュリティの目的でアプリケーションを積極的に分離することもできます。
直接の経験から、Web サーバーとデータベースを別のマシンに配置することは、多くの場合良い考えであると言えます。リソースを集中的に使用するアプリケーションがある場合、マシンの CPU サイクルが簡単にピークに達し、実質的にマシンが停止する可能性があります。ただし、アプリケーションでデータベースの使用が制限されている場合は、サーバーを共有することはおそらく大したことではありません。
用途や目的によって異なります。高可用性とパフォーマンスが重要でない場合は、DB と Web サーバーを分離しないことも悪くありません。特にパフォーマンスの向上を考慮すると、アプリケーションが大量のデータベース クエリを実行する場合、すべてを同じシステム上に保持し、応答時間を低く保つことで、かなりの量のネットワーク負荷を取り除くことができます。
私はそのポッドキャストを聞いて面白かったのですが、セキュリティの議論は私には意味がありませんでした. サーバー A が侵害され、そのサーバーがサーバー B のデータにアクセスできる場合、サーバー B のデータに即座にアクセスできます。
これは、通常、2 つのマシンを異なる方法で最適化する必要があるためだと思います。それ以外はわかりませんが、すべてのアプリケーションを同じマシン上のサーバーデータベースで実行していますが、公開されていないことを前提としていますが、問題はありませんでした.
Web アプリケーションは通常、データベース内のスキーマではないにしても、少なくともデータにほぼ無制限にアクセスできるため、1 台のマシンが両方で侵害されていることを気にする人が多すぎるとは思えません。
他の人が何を言うかに興味があります。
データベース ライセンスは安価ではなく、CPU ごとに課金されることが多いため、Web サーバーを分離することで、データベース ライセンスのコストを削減できます。
たとえば、8 つの CPU を含む Web とデータベースの両方を実行する 1 つのサーバーがある場合、8 つの CPU ライセンスを支払う必要があります。ただし、それぞれ 4 つの CPU を備えた 2 つのサーバーがあり、データベースを 1 つのサーバーで実行する場合は、4 つの CPU ライセンスに対してのみ支払う必要があります。
もう 1 つの懸念事項は、データベースが使用可能なすべてのメモリを占有し、それを使用する必要がある場合に備えてそれを保持することです。強制的にメモリを制限することはできますが、これによりデータ アクセスが大幅に遅くなる可能性があります。
Web サーバー上でデータベース サーバーを実行することで実際にパフォーマンスが向上するという主張は、間違った議論です。
データベース サーバーはクエリ文字列を取得して結果セットを返すため、データ サーバーから Web サーバーに実際に流れるデータは比較的小さいですが、クエリを処理して結果セットを生成するために必要な処理能力は比較的大きくなります。したがって、データ転送時間に関するパフォーマンスを最適化することは、間違ったことを最適化することです。
セキュリティに関しては、データ サーバーを Web サーバーとは別のボックスに配置することには利点があります。このような設定は、セキュリティのすべてではありませんが、正しい方向への一歩です。
スケーラビリティに関しては、Web サーバーを追加してクラスターに配置し、増加したトラフィックを処理するのは簡単で、比較的安価です。データ サーバーを追加してそれらをクラスター化するのは、それほど簡単でも安価でもありません。また、Web サーバーとデータ サーバーでは必要なハードウェアが異なるため、複数のボックスがスケーラビリティに役立ちます。
小規模に開始し、ボックスが 1 つしかない場合は、仮想マシンを使用することをお勧めします。1 つのホスト上の異なる VM で Web サーバーとデータ サーバーを実行すると、1 つの大きなボックスの価格を犠牲にして、個別のボックスのすべてのメリットが得られます。
オペレーティングシステムは別の考慮事項です。データベースにはより大きなメモリスペースが必要なためUNIXが必要になる場合がありますが、Webサーバー（具体的には2つの層しか言及していないためアプリサーバー）は.Netベースである可能性があるため、Windowsが必要です。
Ok！DBサーバーを別のマシンにインストールし、アプリケーションをWebサーバーにインストールする方が安全です。次に、Web リンクを使用してアプリケーションを DB に接続します。ありがとう。