インフラストラクチャアーキテクチャを設計する場合、通常、複雑さとフォールトトレランスのどちらかを選択できます。 ただし、これは単なる逆の関係ではありません。 それは曲線です。 可用性の目標を達成するために、可能な限り複雑さを最小限に抑える必要があります。 また、可用性の目標を下げて複雑さを軽減することもできます（これにより、可用性が向上します）。
採用するルールは 自分（またはスタッフ）にとって単純に思えるほど十分に理解していない場合は、障害モードであっても、それがない方がよいでしょう。
昔、 賢い人 ほとんどのWebサイトは、DB、Webアプリケーション、すべてを単一のサーバーで実行することにより、最高の可用性を実現することを提案しました。 これは最も単純な構成であり、最も理解しやすいものでした。
複雑さを伴わずに（たとえば、XNUMXつのスイッチ、XNUMXつのロードバランサー、XNUMXつのWebサーバー、XNUMXつのデータベース）、障害はゼロに耐えることができますが、障害が発生したことを簡単に知ることができます。
すべてのうち2つを正しく接続すると、XNUMXつの障害で実行を継続できますが、障害に気付かない場合があります。
では、接続を追加して、複数の障害に耐えられるように計画するのは良い考えですか？ 通常ではありません。 たとえば、ロードバランサーの冗長ペアを使用すると、XNUMXつのロードバランサーをXNUMXつのスイッチに接続し、もうXNUMXつのロードバランサーを別のスイッチに接続できます。 ロードバランサーに障害が発生した場合、存続しているロードバランサーが自動的に引き継ぎ、すべてが正常に機能します。 スイッチに障害が発生した場合は、アクティブなロードバランサーが接続されているスイッチである可能性があります。これにより、ロードバランサーのフェイルオーバーもトリガーされ、すべてが正常に実行されます。 各ロードバランサーを各スイッチに接続して、スイッチの障害がロードバランサーに影響を与えないようにすることは可能ですが、それだけの価値はありますか？
これにより、サイトは4つの無関係な障害（4つのスイッチと2つのロードバランサー）に耐えることができますが、複数のトラフィックパスのエンジニアリングがさらに複雑になるため、XNUMXつの可能な状態のいずれかで問題が発生する可能性が高くなります。 現在、XNUMXつではなくXNUMXつの可能なトラフィックパスがあります。したがって、より多くのテストが必要であり、変更に対してより多くのメンテナンスが必要です。
「複雑に思えたら所属しない」という同じ考え方をソフトウェアにも当てはめることができます。 Citrixなどのアプライアンス経由かどうかに関係なく、負荷分散 ネットスケーラー、またはha_proxyなどのソフトウェアは、最近のほとんどの人にとって十分に単純です。 同じことは、クラスター化されたファイルシステム（DRDB）には一般的に当てはまりません。 これらのテクノロジーが本当に必要な場合は、それらを完全に理解し、時間をかけてすべての障害モードを作成し、障害に対処するのが複雑にならないようにスタッフをトレーニングする必要があります。
コンサルタントが来てBGPルーティングを設定しても、NOCまたはコールスタッフの誰もBGPで何もする方法を知らない場合は、サイトの運用上の可用性が大幅に低下します。
「複雑さフィルター」は、監視システムにも適用できます。 監視システムが停止し、サービスプロセスの再起動のトラブルシューティングに対応できるスタッフがすぐにいない場合。 または、スタッフの大多数がモニタリングを簡単に解釈したり、新しいチェックを作成したり、それを使用して時間の経過に伴う傾向を確認したりすることができません。モニタリングは運用稼働時間に貢献していません。 代わりにそれはリソースシンクであり、あなたがそれを最も期待しないときにあなたを噛む可能性があります。 データセンターの監視、データセンター内のすべてのものと同様に、可能な限り自動化されたシンプルなものにする必要があります。
複雑に見える場合–壊れます。 それが複雑でなくなるまでそれを学ぶか、それなしでやってください。