マイクロサービスアーキテクチャ

11章大規模なマイクロサービス

書籍で扱うような、問題のない小さな例を対象とする場合は、すべてが単純に見えます。しかし、実世界はもっと複雑です。マイクロサービスアーキテクチャが単純で質素な初期段階からもっと複雑な段階に拡張したら、どうなるでしょうか。独立した複数のサービスの障害に対処しなければならない場合や、何百ものサービスを管理しなければならない場合にはどうなるでしょうか。メンバー数以上のマイクロサービスがあるときの対処パターンはどのようなものでしょうか。調べてみましょう。

11.1　障害はどこにでもある

私たちは、何事も失敗する可能性があることを理解しています。ハードディスクは故障する場合があります。ソフトウェアもクラッシュする場合があります。分散コンピューティングの誤謬（分散コンピューティングの落とし穴、fallacies of distributed computing、http://bit.ly/1En0t51、日本語ページhttps://ja.wikipedia.org/wiki/分散コンピューティングの落とし穴）を読んだことのある人ならわかるように、私たちはネットワークが信頼できないことを知っています。障害の原因を抑えるように最善を尽くすことができますが、障害はある程度避けられません。例えば、現在のハードドライブはかつてないほど信頼できますが、結局は壊れます。ハードドライブの数が多いほど、個々のユニットが故障する可能性が高くなります。大規模システムでは、故障は統計的に必然です。

超大規模を考えていなくても、障害の可能性を受け入れられれば楽になります。例えば、サービスの障害にグレースフルに対処できるなら、計画停止には計画外停止より簡単に対処できるので、結果としてサービスをインプレースアップグレードすることもできます。 ...