狙い

マイクロサービス・アーキテクチャで開発する際、モノリシックなアーキテクチャで開発していた Web の開発者には、基礎的な知識やメンタルモデル・直観のアップデートが必要となる。

例えば、モノリシックなアーキテクチャでは並行性に関する厄介事はデータベースを中心に解決しており、そのための基礎知識がある。事実、『ウェブを支える技術』（2010)では、楽観的並行性制御と悲観的並行性制御がデータベースを前提として取り扱われている。

経験上、マイクロサービス・アーキテクチャにおいても、このようなものに対応する、広く知られるべき基礎的な知識というものが存在するはずである。最終的にはある程度網羅的なものになることを期待しつつ、仕事で「これは知っておいて欲しい」と思ったものをここにまとめていく。

トピックメモ：障害の分離 / ネットワーク・アウェアネス / 同期と非同期 / Message Passing と Shared-State という二つの並行モデル / モノリシック・システムの相対化

失敗は例外ではなく前提となる

システムを構成するコンポーネントは1-3個から、任意の個数に増える。

例えば、コンポーネントの数が30個で、各コンポーネントの可用性が99.9%だったとする。障害の分離が行われていないと、単純計算では、

0.999 * 0.999 * ... * 0.999 = 0.999^30 = 0.97

となり、99.9%の可用性が97%になってしまう。

これは単純なモデル化だが、そのぶん本質は捉えている。

ここから分かることは、 マイクロサービス・アーキテクチャでは障害の分離（fault isolation）はあったら良いもの（nice to have）ではなく必須（must have）である ということである。

これがモノリシックなアーキテクチャだと、構成されるコンポーネントの数も少なく固定的なため、あったら良いものという程度のものだった。

マイクロサービス・アーキテクチャではそうではないので、コンポーネントを依存させるときのハンドリングや、そもそも新しくコンポーネントを切り出すときの責務の検討など、常に失敗を念頭に置いて考える必要があるという意味で、認識のアップデートが必要となる。

これが適切に行われていないと、コンポーネントごとの開発サイクルの高速化などマイクロサービス・アーキテクチャで得たい恩恵が受けられず、むしろ逆の結果を招くことにすらなってしまう。

逆に、これが適切に行われていれば、障害のあったコンポーネントの名前から直ちにアプリケーションへの影響範囲が決まる。これは対応の緊急度を判断したりするのに役立つし、障害の対応もコンポーネントのオーナーや関係者に限定されるため、開発のスケールを助ける。

デフォルトは非同期