データベースとWebサーバーを同じマシン上に配置することが推奨されないのはなぜですか？
スタックオーバーフローチーム（ part 1 および 2 ）へのScott Hanselmanのインタビューを聞いて、彼はSQLサーバーとアプリケーションサーバーを別々のマシンに置くことを固く断念しました。これは、1台のサーバーが侵害された場合に、両方のシステムにアクセスできないようにするためだけですか？セキュリティ上の懸念は、2つのサーバーの複雑さ（余分なコスト、2つのサーバー間の専用ネットワーク接続、メンテナンスの増加など）を上回りますか？ 2台のサーバーがあり、1台のサーバーが侵害された場合でも、攻撃者はデータベースを削除したり、アプリケーションコードをいじったりすることにより、深刻な損害を与える可能性があります。
パフォーマンスが問題にならないのに、なぜこれほど大きな問題になるのでしょうか？
- セキュリティ。 WebサーバーはDMZにあり、パブリックインターネットにアクセスでき、匿名ユーザーから信頼できない入力を受け取ります。 Webサーバーが危険にさらされ、DBに接続する際に最小限の特権ルールに従っている場合、最大の露出は、アプリがデータベースAPIを介して実行できることです。間にビジネス層がある場合、攻撃者とデータの間にもう1つのステップがあります。一方、データベースが同じサーバー上にある場合、攻撃者はデータとサーバーへのルートアクセス権を持っています。
- スケーラビリティ。 Webサーバーをステートレスに保つことで、Webサーバーを非常に簡単に水平に拡張できます。 非常にデータベースサーバーの水平スケーリングは困難です。
- パフォーマンス。 2ボックス= CPUの2倍、RAMの2倍、ディスクアクセス用のスピンドルの2倍。
そうは言っても、これらの点のどれも本当に重要ではないという合理的なケースを確かに見ることができます。
本当に問題ではありません（同じマシンでWeb /データベースを使用してサイトを非常に快適に実行できます）。これはスケーリングの最も簡単なステップです。
それはまさにStackOverflowがやったことです。IIS/ SQL Serverを実行している単一のマシンから始めて、負荷が大きくなり始めたら、2台目のサーバーを購入し、SQLサーバーをその上に移動しました。
パフォーマンスが問題にならない場合は、2台のサーバーの購入/維持にお金を無駄にしないでください。
一方、別のブログScott（TelligentのWatermasyck）を参照すると、ほとんどのユーザーは、データベースをWebサイトと同じマシンに配置することで、Webサイトを高速化できます（Telligentのコミュニティサーバーを使用）。ただし、顧客の場合、通常、そのマシン上のアプリケーションはデータベースとWebサーバーのみであり、Webサイトはマシンにそれほど負担をかけていません。次に、ネットワークを介してデータを送信する必要がないことの効率が、増加した負荷を補います。
トムはこれについて正しいです。他のいくつかの理由は、費用対効果が高くないことと、追加のセキュリティリスクがあることです。
Webサーバーには、データベースサーバーとは異なるハードウェア要件があります。データベースサーバーは、多くのメモリと非常に高速なディスクアレイでより良く機能しますが、Webサーバーは、ファイルと頻繁なDBリクエストをキャッシュするのに十分なメモリしか必要としません（設定によって異なります）。費用対効果に関しては、2つのサーバーが必ずしも安価であるとは限りませんが、リソースを競合する異なるアプリケーションを使用する必要がないため、パフォーマンス/コスト比は高くなります。このため、おそらく両方に対応し、2つの特殊なサーバーと同等のパフォーマンスを提供する1つのサーバーにより多くの時間を費やす必要があります。
セキュリティ上の懸念は、単一のマシンが侵害された場合、ウェブサーバーとデータベースの両方が脆弱であるということです。 2台のサーバーでは、2番目のサーバーが（少なくともしばらくの間）安全であるため、ある程度の余裕があります。
また、多数の異なるWebアプリケーションで使用される少数のデータベースサーバーのみを維持する必要があるため、スケーラビリティの利点がいくつかあります。これにより、アップグレードやパッチの適用やパフォーマンスチューニングの作業が少なくなります。ただし、これらのタスクを簡単にするためのサーバー管理ツールがあると考えています（単一マシンの場合）。
大きな要因はパフォーマンスだと思います。 Webサーバー/アプリコードとSQL Serverの両方が、一般的に要求されるデータをメモリにキャッシュします。同じメモリスペースで実行すると、キャッシュパフォーマンスが低下します。
セキュリティは大きな関心事です。理想的には、データベースサーバーは、データアクセスを実行するために必要なポートのみを開いた状態でファイアウォールの背後に配置する必要があります。 Webアプリケーションは、アプリケーションが機能するのに十分な権限しか持たないSQLアカウントでデータベースサーバーに接続している必要があります。たとえば、オブジェクトの削除を許可する権限を削除する必要があり、「sa」などのアカウントを使用して接続することは絶対に避けてください。
ハイジャックによりWebサーバーが失われた場合（つまり、管理者権限への完全な特権エスカレーション）、最悪のシナリオは、アプリケーションのデータベースが危険にさらされる可能性がありますが、データベースサーバー全体ではありません（データベースサーバーとWebサーバーは同じマシンでした）。データベース接続文字列を暗号化していて、ハッカーがそれらを解読するのに十分な知識がない場合、失われるのはWebサーバーだけです。
まだ言及されていない1つの要因は、負荷分散です。 Webサーバーとデータベースを別々のマシンと見なすことから始めると、ネットワークラウンドトリップが少なくなるように最適化されます。また、ニーズの増加に応じて、2番目のWebサーバーまたは2番目のデータベースエンジンを追加しやすくなります。
Webサーバーとデータベースを別のマシンに配置することは、多くの場合、良いアイデアであると、直接の経験から話すことができます。リソースを大量に消費するアプリケーションがある場合、マシンのCPUサイクルが簡単にピークに達し、本質的にマシンが停止する可能性があります。ただし、アプリケーションでデータベースの使用が制限されている場合、サーバーを共有することは大した問題ではないでしょう。
うわー、実際にSQLサーバーを5kドルで購入した場合、それをWebアプリケーション以外にも使用したいという事実を誰も思い付きません。あなたがエクスプレスを使用している場合、多分あなたは気にしません。 SQLサーバーは20〜30個のアプリケーションに対してデータベースを実行するので、Webサーバーに配置するのは賢明ではありません。
第二に、サーバーの対象者によって異なります。私は金融会社と政府のために働いています。そのため、sprocのみを使用し、WebサーバーからSQLへのポートを制限するという、お尻のアプローチに非常に苦労します。そのため、Webアプリがハッキングされた場合。ハッカーができることは、ウェブサーバー上のユーザーアカウントがロックダウンされているため、sprocsを呼び出すだけです。したがって、ハッカーはDBにアクセスする方法を理解する必要があります。 Webサーバー上にある場合、その種類に簡単にアクセスできます。
私はダニエル・アーウィッカーに同意します-セキュリティの質問にはかなり欠陥があります。
WebサーバーとそのWebサーバーのデータベースのみを備えた単一のボックスセットアップがある場合、そのWebサーバーが危険にさらされると、その特定のアプリケーションのWebサーバーとデータベースのみの両方が失われます。
これは、2サーバー構成でWebサーバーを失った場合とまったく同じです。 Webサーバーが失われ、その特定のアプリケーションのデータベースだけが失われます。
最初のシナリオでは、他のすべてのアプリケーション（存在する場合）に関連する他のすべてのデータベースサーバーも影響を受けないため、2台のサーバーを設定している場合の「残りのDBサーバーの整合性は維持される」という議論は無関係です-他の場所でホストされていること。
同様に、Kevによって提起された質問に対して、「DBサーバーに存在する他のすべてのデータベースはどうですか？失ったのは1つのデータベースだけです。」
- 1つのサーバーでアプリケーションとデータベースをホストしている場合は、そのアプリケーションに関連するデータベースのみをそのサーバーでホストします。したがって、複数サーバーのセットアップと比較して、単一サーバーのセットアップで追加のデータベースを失うことはありません。
対照的に、2サーバーのセットアップでは、攻撃者がWebサーバーにアクセスし、プロキシによってデータベースサーバーに対する制限された権限（最良の場合）を持ち、他のすべてのアプリケーションのデータベースを持ち運ぶことでリスクにさらされる可能性があります。低速でメモリ集約型のクエリを実行するか、データベースサーバーで使用可能なストレージスペースを最大化します。仮想化と同様に、アプリケーションをそれぞれの関心事に分離することにより、セキュリティ目的で積極的にアプリケーションを分離することもできます。
それはアプリケーションと目的に依存します。高可用性とパフォーマンスが重要でない場合、DBサーバーとWebサーバーを分離しないことは悪くありません。特にパフォーマンスの向上を考慮すると、アプリケーションが大量のデータベースクエリを実行する場合、すべてを同じシステムに保持して応答時間を短くすることで、かなりの量のネットワーク負荷を取り除くことができます。
通常、2台のマシンを異なる方法で最適化する必要があるためです。それ以外はわからないが、すべてのアプリケーションをサーバーデータベースで同じマシン上で実行します（公開されていないことを前提にしています）が、問題はありませんでした。
Webアプリケーションは通常、データベース内のスキーマではなくとも少なくともデータへのほぼ無制限のアクセス権を持っているため、1台のマシンが両方に対して侵害されることを気にする人が多すぎるとは想像できません。
他の人の言うことに興味がある。
私はそのポッドキャストを聞いたが、面白かったが、セキュリティの議論は私には無意味だった。サーバーAを侵害し、そのサーバーがサーバーBのデータにアクセスできる場合、サーバーBのデータに即座にアクセスできます。
データベースライセンスは安くなく、多くの場合CPUごとに課金されます。したがって、Webサーバーを分離することにより、データベースライセンスのコストを削減できます。
たとえば、1つのサーバーで8つのCPUを含むWebとデータベースの両方を実行している場合、8 CPUライセンスの支払いが必要になります。ただし、それぞれ4つのCPUを搭載した2つのサーバーがあり、1つのサーバーでデータベースを実行する場合は、4 CPUライセンスのみを支払う必要があります。
さらに懸念されるのは、データベースが利用可能なすべてのメモリを使用し、使用したいときに備えて確保することです。メモリを制限するように強制できますが、これによりデータアクセスが大幅に遅くなる可能性があります。