回答:
興味深い質問。
歴史的に、完全に切り替えられたネットワークが出現する前は、ネットワークをサブネットに分割する際の主な考慮事項は、単一のコリジョンドメイン内のノードの数を制限することでした。つまり、ノードが多すぎると、ネットワークのパフォーマンスがピークに達し、過度の衝突による高負荷の下で最終的に崩壊します。展開できるノードの正確な数は多くの要因に依存していましたが、一般的に、利用可能な総帯域幅の50％をはるかに超えてコリジョンドメインを定期的にロードすることはできず、ネットワークは常に安定しています。当時、ネットワーク上の50ノードは多くのノードでした。頻繁に使用するユーザーの場合、サブネット化を開始する前に20または30ノードで突破した可能性があります。
もちろん、完全に切り替えられた全二重サブネットを使用すると、衝突はもう心配されなくなり、一般的なデスクトップタイプのユーザーを想定すると、通常は何の問題もなく単一のサブネットに数百のノードを展開できます。他の回答が示唆しているように、大量のブロードキャストトラフィックがあることは、ネットワークで実行しているプロトコル/アプリケーションによっては懸念事項になる場合があります。ただし、ネットワークをサブネット化しても、ブロードキャストトラフィックの問題が必ずしも解決するわけではないことを理解してください。多くのプロトコルでは、ブロードキャストを使用します。つまり、ネットワーク上のすべてのノードが実際にそのようなトラフィックを確認して、必要なアプリケーションレベル機能を実装する必要がある場合です。ブロードキャストされたパケットが他のサブネットに転送され、再びブロードキャストされる必要がある場合、ネットワークを単にサブネット化しても、実際には何も購入されません。
一般的に言えば、今日、ネットワークをサブネット化する主な理由は、組織、管理、およびセキュリティの境界に関する考慮事項と何よりも関係しています。
元の質問では、サブネット化の考慮事項をトリガーする測定可能なメトリックを求めています。特定の数字の点で何かわからない。これは、関連する「アプリケーション」に大きく依存するため、一般的に適用されるトリガーポイントは実際にはないと思います。
サブネットを計画する際の経験則に関連して：
とはいえ、サブネットを追加すると、ある程度の管理オーバーヘッドが追加され、1つのサブネットのノードアドレスが不足したり、別のプールに多く残ったりすることに関連する問題が発生する可能性があります。ネットワークなどがより複雑になります 確かに、各サブネットには、より洗練された論理トポロジを維持するためのオーバーヘッドを上回る既存の理由が必要です。
単一のサイトの場合、数十以上のシステムがある場合を除き、気にしないでください。それでも、おそらく不要です。
誰もが少なくとも100 Mbpsスイッチ、より頻繁に1 Gbpsを使用している最近では、ネットワークをセグメント化する唯一のパフォーマンス関連の理由は、過剰なブロードキャストトラフィックに苦しんでいる場合です（つまり、2％を超える）
その他の主な理由はセキュリティです。つまり、公共のサーバー用のDMZ、財務用の別のサブネット、またはVoIPシステム用の個別のVLAN /サブネットです。
もう1つの理由は、サービス品質に関連することです。VoIPトラフィックにQoSを簡単に適用できるように、音声VLANとデータVLANを別々に実行します。
ご存知のように、私はこの質問についてもっと考えてきました。異なるネットワーク（パフォーマンス、セキュリティ、QoS、DHCPスコープの制限、ブロードキャストトラフィック（セキュリティとパフォーマンスの両方に関連する可能性がある）の制限）を使用して新しいネットワークを設計する理由はたくさんあります。
しかし、サブネットだけに再設計するためのメトリックを考え、過去に処理しなければならなかったネットワークを考えるとき、私が考えることができるのは「すごい、それは私が完全に再設計するためにネットワークを本当に台無しにしなければならないだろう」サブネット化のためにそれ。帯域幅、インストールされているデバイスのCPU使用率など、他にも多くの理由があります。しかし、純粋なデータネットワーク上でサブネット化するだけでは、通常、大量のパフォーマンスは得られません。
ほとんどの場合、セキュリティと品質（問題のネットワークセグメントが問題のノードをサポートできる限り）。プリンタートラフィック、音声/電話、IT Opsなどの隔離された部門、そしてもちろんサーバーセグメント、インターネットに直接接続するセグメント（今日では「1つのdmzが行う」だけでなく、インターネットに直接接続するサービスごとに1つ）などの個別のネットワークなど。
スケールアップを期待している場合（5台のサーバーだけでなく、ネットワークを構築しているので、それは可能です）、できるだけ早くルーティングを開始します。あまりにも多くのネットワークは、有機的に成長し、レイヤー2のものが多すぎるため、不安定で成長が困難です。
例：
つまり、スパニングツリーが必要だと思われる場所にスケールアップする場合は、代わりにルーティングを検討してください。
個人的には、可能な限りアクセススイッチに近いレイヤー3セグメンテーションを使用するのが好きです。
2つのコアスイッチ/ルーターでは不十分な大規模/広域拡散ネットワークの場合、VRRPなどの通常の冗長性メカニズムには多くの欠点があります（トラフィックがアップリンクを複数回通過するなど）。OSPFにはありません。
use-small-broadcast-domains -approach をサポートする理由はおそらく他にもたくさんあります。
組織の範囲は非常に重要だと思います。ネットワーク上に合計200個以下のホストがあり、何らかの理由でトラフィックをセグメント化する必要がない場合、VLANとサブネットの複雑さを追加する理由は何ですか？ただし、スコープが大きいほど、意味があります。
ただし、通常は必要ないネットワークを分割すると、いくつかのことが簡単になります。たとえば、サーバーに電力を供給するPDUは、サーバーと同じVLANまたはサブネットにあります。つまり、サーバー範囲で使用される脆弱性スキャンシステムは、PDUもスキャンします。大したことではありませんが、PDUをスキャンする必要はありません。また、設定するのが面倒なのでPDUをDHCPするのは良いことですが、それらは現在サーバーと同じVLANにあるので、あまり実現できません。
PDUに別のVLANは必要ありませんが、いくつかのことが簡単になります。そして、これは、これからも続くVLANの議論と全体的なVLANの議論の続きになります。
私、私はちょうどそれが理にかなっているVLANを持っていると思います。たとえば、PDUに独自のVLANを与えた場合、デバイスの小さなグループに独自のVLANを常に与えなければならないという意味ではありません。しかし、むしろこの場合、それは理にかなっているかもしれません。デバイスのグループが独自のVLANを持つ必要がなく、そのための利点がない場合は、そのままにしておくことを検討できます。