【58】3 つから 2 つだけを選ぶ覚悟を決めよ

　制約を受け入れたり、性質の 1 つに見切りを付けたりすると、かえって構築、実行が楽でコストもかからない優れたアーキテクチャーになることがあります。バスと同じように、いいなと思う性質は 3 つ固まってやってきますが、これら 3 つをサポートすることを意図して定義、構築したシステムは、どれについても思わしい成果を残せないものになってしまうのです。

　そのよい例がブリュワーの予測、あるいは CAP 定理です。分散システムで望ましいとされている性質は、データ整合性（Consistency）、システム可用性（Availability）、ネットワークの分断（Partition）の 3 つですが、3 つ全部を同時に達成することは難しいというのです。3 つをすべて満足させようとすると、途端にコストが上がり、複雑になるにもかかわらず、ビジネス上の目標や望ましい効果は得られません。

　たとえば、データを分散化して可用性を高めようとしたシステムにおいて、さらに整合性も求めようとすると、コストが跳ね上がり、結局整合性は得られなくなります。同様に、システムに分散化と整合性が必要な場合、整合性を確保しようとすると、最初のうちは遅延やパフォーマンス上の問題が起きます。その後も、整合性を保つためにシステムを公開するわけにいかなくなり、結局可用性は得られません。

　アーキテクチャーを設計するときには、どうしても譲れない性質が 1 つ、あるいはいくつか出てくることがよくあります。データを重複して持つことはできない、書き込みはかならずトランザクションによって行わなければならない、100% の可用性がなければならない、呼び出しは非同期的でなければならない、単一障害点があってはならない、すべての部分に拡張性がなければならない、といったものです。

　だまされやすい素朴な考え方はやめて、これらの題目を迷信と思えば、目の前の問題に振り回されることはなくなります。原則に基づいた設計にしがみつくのではなく、アーキテクチャーにわざと偏りを与えることを考えるのです。教条主義と管理をはき違えてはなりません。なぜ、その性質が必要なのかを、本気で考えなければなりません。その性質があるとどのようなメリットがあるのか、その性質が欲しくなるのはどのようなときか、より良い結果を得るためにシステムをどのように分割するか。アーキテクチャーにドグマが紛れ込むと、結局システムを損ねることになりますので、あらゆることを疑わなければなりません。

　このようなトレードオフが避けられないという事実を受け入れるのは、アーキテクトに限らず、デベロッパーやその他の利害関係者にとっても、ソフトウェア開発においてもっとも難しいことの 1 つです。しかし、必要なものを選ぶことは大切です。その方が、無限の選択肢を残しておくよりもはるかによい結果が得られます。トレードオフを受け入れれば、創意に満ちたすばらしいシステムを手に入れられる場合もよくあります。