システムは必ず故障する。毎年とんでもない額を投資しているAWS(Amazonのクラウドサービス)でも100%中断しないサービスは提供できていない。
※AWS2019年投資額、約130億ドルみたいですね。
為替レートは計算しやすく1ドル＝100円なら、1.3兆円ですか・・・
とんでもない。
また、ライバルのAzureやGCPも相当な投資額ですが、同じく100%保証はしておりません。となれば、2020年の現代では100%中断しないサービスを提供することは困難であると言える。
なぜ、中断や故障等が発生してしまうのか、この本が一番わかりやすく読み直しました。
■備忘メモ
システム中断・故障の要因は大きく４つに分けられる。
●ソフト不具合
ーテストが膨大な量であり事実上やりきれず、必ずバグが含まれている。
それが、レアな条件の時に顕著化して不具合を引き起こす。
ーパッチ適用した際のOS/ミドルのバージョン相性問題
※これは上のテスト困難と被る部分もありますが・・・
●ハード/ソフトの性能や容量不足
ー急なアクセス増加などで過負荷になる。
昨今のクラウド環境でハードのリソース増強は比較的しやすくても、ソフトのパフォーマスは相当考えて設計していないと負荷分散できず、過負荷となりサービス中断となる。
●設定・操作ミス
ー手順になれていないため、コマンド間違えたなど。
ー勘違いして開発環境ではなく、本番環境に影響してしまった
●偶発的な事象
ーハード故障
ー被災
ー他社システム故障
■現実的な対策
上にある様々な要因はお金と時間をかけてもゼロにする事はできない。できるだけ、サービス提供に影響しないようにするのは冗長化の考えがポイントとなる。また異常時に、ある一つのシステムに依存しない代替手段を用意しておく事。
※また、システム中断が生命にかかわらないならば、コスト見合いでシステムダウンを許容する事が現実的。
●冗長化
－ハード（サーバ/RT/SW等)を複数用意し、本番用や予備用に分けておく。
（※高価なハードは１個のハード内でもパーツ冗長化させる事も）
－更に信頼性高めるなら2系統化
ソフトは同一条件では同一バグを引き起こす事になるので、単純に予備用を準備してて効果は薄い。そこで違うメーカのソフト(OS/ミドル/アプリ等)による予備用を用意しておく事で、同一のバグでシステム全体が止まる事を避ける。
※開発コストは2倍以上かかりそう・・・
●ビジネスとしての代替手段の確保
－例えばECサイトが落ちたら、電話注文で耐えらえるようにコールセンタのオペレータを臨時で追加するなど、ビジネス上の代替手段を用意し、1つのシステム中断でビジネスが止まらないようにする事が大事。
■Tips
クラウドは家畜の群れであり、ペットのようにかわいがるな。
参考)https://blogs.itmedia.co.jp/narisako/2014/07/post-047f.html
クラウドは、壊れる前提で多数でカバーする考えなので、1つ故障したらまた新しいサーバ用意して移行すればよい。群れとして複数のサーバで構成し、調子がわるいサーバがいれば、それを直すのでは新しいサーバ用意して移行させればよい。
システムとしての信頼性を上げればよいので、その手段である1つ1つの要素は使い捨て？みたいな考えですかね、確かにシステム信頼性を高めるのが目的なので、サーバ単体の信頼性ばかり囚われると、目的と手段が混合しちゃいますね。
ハード単体の信頼性を高い事に越した事はないですが、それは投資コストを見つつ、上の言葉のように最終的なビジネスとしての信頼性を高めるにはどうすればよいのか、それに気をつけたいと思います。
