ソフトウェアアーキテクチャの基礎 ――エンジニアリングに基づく体系的アプローチ読書メモ
「アーキテクトは1つの真の設計を見つけることに執着してはならない。むしろ、設計上の決定ごとのトレードオフを客観的に評価し、最も悪くないトレードオフとなるものを選ぶようにしよう」
本書の中で何回も繰り返される全てはトレードオフという原則から導かれる。最良のものを選ぶという発想はトレードオフの原則に反しているため結局は悪いといえないトレードオフを選ぶことがバランスの取れたトレードオフとなる。
「分散アーキテクチャでは、開発チームとその優先順位に基づいて、各サービスが独自のリリースサイクルとエンジニアリングプラクティスを持つような、より細かいデプロイモデルを採用出来る」
問題はその各サービスが独自のリリースサイクルのエンジニアリングプラクティスを必要な成熟度に達しているかというところをどのようにして判断出来るのかというところと、また本当に独自のサイクルやプラクティスを必要するかというところな気はするがこの本ではそれに対する解はなさそう
「(アーキテクチャ)コンポーネントごとに異なるアーキテクチャ特性に対応するには、分散アーキテクチャが必要になる
」
必要とされる信頼性や可用性などがコンポーネントごとに異なる場合、例えばオークションの入札者と出品者のようなアクターがいるとしてそれぞれが使うコンポーネントで必要とされる特性が異なる場合など
実際は必要とされるアーキテクチャ特性が異なっていたとしてもモノリシック上ではある特性の要求レベルが高い場合、必要としていない方をカバー出来ることも多いので必ずしも分散する必要もないとは思う
15章 スペースベースアーキテクチャ
スペースベースアーキテクチャの名前の由来はタプルスペースの概念に由来する。高いスケーラビリティ、高い弾力性、高いパフォーマンスは、システムの同期制約である中央データベースを取り除き、代わりにレプリケーとされたインメモリデータグリッドを活用することで実現される。アプリケーションデータはメモリ内に保持され、全てのアクティブな処理ユニット間でレプリケーとされる。処理ユニットは、データを更新すると、通常は永続的なキューを持つメッセージングを介して、非同期にそのデータをデータベースに送信する。
Hazelcast, Apache Ignite, Oracle Coherenceといった製品でインメモリデータグリッドとレプリケーションエンジンが実現される。