大規模システム開発の問題 2 -- 分散システム
システムの構築方法が変わるにつれ、開発の方法も変化します。現代のシステムは、規模の大小を問わず、またユーザ(場合によっては開発者も!)がそれを意識する否かを問わず、ネットワークをまたいでサービスを交換するのが、基本的なスタイルになっています。
こうした分散システムの開発には、そうではないモノリシックなシステムの開発とは異なる注意が必要になります。分散システム上でプログラムを正しく実行させるのは、そうでないシステム上でプログラムを正しく実行させるより、本当は、難しいのです。
先日も、AWSで大規模な障害が起きましたが、ここで取り上げたいのはそうしたことではありません。
クラウド事業者は、基本的には、分散システム設計のプロで、何が設計の肝で、トラブルにどう対応すればいいのかをよく理解していると、僕は信じています。
問題は、一般のユーザー企業も、普通のプログラマーも、そのことを意識するか否かをとわず、事実上の分散システムを作ることが、今では当たり前になっていることです。
こうした分散システムの構築の難しさによるトラブルは、枚挙にいとまがありません。
2002年4月に起きた、みずほ銀行の大規模な障害は、システム内のネットワーク、第一勧業銀行・富士銀行・日本興業銀行間を結ぶネットワークをコントロールする「リレーコンピュータ」のバグが原因でした。
写真は、2015年7月8日のシステム障害で、創設以来223年間、途絶えたことのなかった取引の中止に追い込まれたニューヨーク証券取引所の前でボーッとする人。
単純な例ですが、分散システムでのプログラミングの難しさを示した図があります。https://github.com/…/d…/blob/master/verdi/slides/verdi-2.pdf から。
分散システム上のノードは、故障で死んでるかもしれないし(ノード S2)、メッセージの通信がタイムアウトを起こしてメッセージが伝わっていないかもしれません(ノード S1)、またある瞬間をとれば、メッセージは送り出されているのに、まだ受け手のノードには届いていないかもしれません。
分散システム上で、正しく動くプログラムの設計・開発、なかなか難しいですね。
こうした問題は、k8s でクラスターを組むときにも、必ず付いて回ると僕は思っています。"Kubernetes Failure Stories" に、色々な事例が集められています。https://k8s.af/
コメント
コメントを投稿