非分散アーキテクチャの原則は正しいか？

一般にスケーラビリティを得るためには、分散させないことがアーキテクチャの原則です。
プロセス間通信のマーシャリングコストはインプロセスのローカルコールに対して桁違いのオーバーヘッドになるからです。また、分散トランザクションのロックもこの状況を悪化させます。それにもかかわらず、GoogleやAmazonなど大規模サイトは分散アプローチをとり、スケーラビリティを確保しています。この事実は非分散アーキテクチャの原則を否定しているともいえます。

企業システムや大規模Webアプリケーションを想定する場合、非分散のアーキテクチャの原則は有効でしょうか。分散させない原則は企業システムではなかなか現実的に実行は困難です。性能面だけでなく、管理コスト面で分散システムには不利益がありますが、本当でしょうか？性能面と管理面の2つを考えてみましょう。

• 性能面
  分散システムのスケーラビリティを考えるとき、マスターデータをどう扱うかが最も大きな問題と考えます。冗長性を排除した論理的に統合されたデータ定義の原則、"one fact in one place" はシステムが分散か集中化によらず有効な原則です。問題は、論理的に統合されたデータ定義を物理的にどう配置するかです。これには2つの考え方があります。いずれもスケーラビリティの観点から、shared nothingを原則とします。

1つはドメインモデル（論理データモデル）に対してユースケースで決定されるトランザクションスコープを単位としていく考え方。トランザクションスコープが分散しないように、独立したサービス、権限の範囲を単位とした配置とします。たとえば、注文に対して、製品出荷、決済に関する部分は別トランザクションとして切り離します。もう１つはマスターデータのパーティショニングを単位とする考え方です。たとえば、Web 2.0系のアプリケーションではユーザ単位に配置を決定します。この2つの考え方を物理的な配置の設計モデルとします。

性能的に最も重要なのは書き込みの帯域幅です。物理的にマスターデータを統合すると、書き込みに対する一貫性を確保しつつ、読み取りに対してはレプリケーションを使った性能改善ができます。しかし、これは誤ったアーキテクチャです。レプリケーションはバッチ型でそれ自体のオーバーヘッドが大きく、書き込みに対するスケーラビリティの改善となりません。書き込みの帯域幅を上げるには、マスターデータの物理的なパーティショニングを行い、それぞれパーティションを処理するホストに対して書き込み処理を並列に実行することが重要です。また、各ホストが処理すべきデータ量は統合ホストに比べて減るのでキャッシュのヒット率が上がります。ここで、ホストが書き込み処理に対して並列な動作をするためには、ホスト間にまたがるデータ操作ができるだけ減るようなデータ設計をユースケースから考える必要があります。たとえば、あるユーザへの別ユーザのコメントの追加などのデータ処理をどうするかです。これと類似の問題に、特定のパーティションに対する負荷が大きくなり、パーティションの切り直しが必要になる場合の対応があります。この対応ができるだけ少ないという前提での設計を考えるべきです。物理パーティショニングでは、これらが満たされる制約条件があるので、万能というわけではありません。

以上の考慮から、分散トランザクション処理と物理パーティニングは相反する要求であることがわかります。物理的に分割すれば一貫性に対するトランザクション処理が必要となり、分散させないために集約すれば、負荷が集中するからです。この相反では物理パーティショニングを優先します。スケーラビリティに対して、線形的な拡張が期待できるからで、また、安価なサーバハードウェアによる構築、耐障害性の利点があるからです。また、レプリケーションとパーティショニングも相反します。ここでは上記の説明のとおり、パーティショニングをとります。

• 管理面
  サーバ集約がもてはやされているように、システムが分散することによる管理コストの上昇があります。しかし、一方では、集約による障害対応のコスト高が伴います。集約によるデータ量の増大もバックアップコストを上げます。分散による管理コストの上昇はあるのですが、物理分割以前にデータの論理的な統合に伴うコスト削減効果が高いので、論理と物理をいっしょに考えるべきではありません。特に現状の企業システムでは、論理的に統合されていない、データのサイロが多数あることによる管理コストの負担が大きいからです。