システム障害に備えよう
はじめに
システム障害は必ず起きますが、システム障害が起きる確率を下げる仕組みをつくることはできます。システム障害に強いシステムの設計には、知識が必要です。備えあれば患いなしということで、設計の指針を勉強しておきましょう。
年あたりの稼働率計算
システム障害が発生した場合の許容される停止時間(=可用性)をSLA(Service Level Agreement)として定義します。可用性は1年間の停止時間[1]からパーセンテージで表されることが一般的です。
可用性 | 通称 | 1年当たりの停止時間 |
---|---|---|
90% | one nine | 36.53日 |
95% | one and a half nines | 18.26日 |
97% | 10.96日 | |
98% | 7.31日 | |
99% | two nines | 3.65日 |
99.5% | two and a half nines | 1.83日 |
99.8% | 17.53時間 | |
99.9% | three nines | 8.77時間 |
99.95% | three and a half nines | 4.38時間 |
99.99% | four nines | 52.60分 |
99.995% | four and a half nines | 26.30分 |
99.999% | five nines | 5.26分 |
99.9999% | six nines | 31.56秒 |
99.99999% | seven nines | 3.16秒 |
99.999999% | eight nines | 315.58ミリ秒 |
99.9999999% | nine nines | 31.56ミリ秒 |
AWSが定義する目指すべき可用性
世界的に有名なクラウドサービスであるAWSでもWell-Architected Frameworkの中で「可用性 = 正常稼働時間/合計時間」と定めています。また、可用性の数字を見ただけではイメージがつきづらいですが、
可用性 | 最大中断時間(1年あたり) | 代表的なワークロード |
---|---|---|
99% | 3日と5時間 | バッチ処理、データ抽出、転送、ロードジョブ |
99.90% | 8時間45分 | ナレッジ管理、プロジェクト追跡などの社内ツール |
99.95% | 4時間22分 | オンラインコマース、POS |
99.99% | 52分 | 動画配信、ブロードキャストシステム |
100.00% | 5分 | ATM処理、通信システム |
参考:Well-Architected for Startups -信頼性の柱- 導入編 | AWS Startup ブログ
対障害用語の分類
対障害用語はその性質上3つに分類可能です。
- fault(システム障害)に備える
- fail(異常)に備える
- fool(バカ)に備える
1. fault(システム障害)に備える仕組み
1つ目は「fault(システム障害)」に備える仕組みです。「耐える(tolerance)」、「回避する(avoidance)」、「隠蔽する(masking)」という3つの戦略がとられます。
1.1. フォールトトレランス
項目 | 説明 |
---|---|
英語表記 | fault tolerance |
別名 | フォールトトレラント(fault tolerant) |
思想 | システム障害が起きてもこれまで通りにしよう |
障害発生時の動作 | 機能縮小せずに処理を継続する |
具体例 | 停電しても自家発電で給電を継続する、RAIDを組むことでディスクが壊れても他のディスクで処理を継続する |
1.2. フォールトアボイダンス
項目 | 説明 |
---|---|
英語表記 | faulr avoidance |
思想 | そもそもシステム障害が起こらないようにしよう |
障害発生時の動作 | 事前対策によりシステム障害を回避する |
具体例 | 高品質な部品を使って障害発生可能性を極力低くする、徹底的にテストを行って障害発生可能性を極力低くする |
1.3. フォールトマスキング
項目 | 説明 |
---|---|
英語表記 | fault masking |
思想 | システム障害が起きても他に影響しないようにしよう |
障害発生時の動作 | 正しい処理結果のみ採用する |
具体例 | 複数のCPUで同じ処理を行い異なる結果(少数派)は排除する |
2. fail(異常)に備える
2つ目は「fail(異常)」に備える仕組みです。「安全(safe)」、「柔軟さ(soft)」、「切替え(over)」、「切戻し(back)」という4つの戦略がとられます。
2.1. フェールセーフ
項目 | 説明 |
---|---|
英語表記 | fail safe |
思想 | 異常が起きたら停止しよう |
障害発生時の動作 | 異常を検知したら停止する |
具体例 | 異常な入力に対して警告を表示し処理を停止する |
2.2. フェールソフト
項目 | 説明 |
---|---|
英語表記 | fail soft |
思想 | 異常が起きても柔軟に対処しよう |
障害発生時の動作 | 異常を検知したら縮退運転する |
具体例 | 2台のサーバで賄っていた処理を1台で継続する |
2.3. フェールオーバー
項目 | 説明 |
---|---|
英語表記 | failover |
思想 | 異常が起きた時のために予備を持っておこう |
障害発生時の動作 | 異常を検知したら待機系に切り替える |
具体例 | 主系のサーバがダウンしても副系のサーバでサービス継続する |
2.4. フェールバック
項目 | 説明 |
---|---|
英語表記 | failback |
思想 | 異常が復旧したら主系に引き継ごう |
障害発生時の動作 | 復旧したら主系に切り替える |
具体例 | 主系が復旧したら副系から主系に処理を戻す |
2.5. フォールバック
「fail(異常)」に備える仕組みとは少し語感が変わってきますが、「fall(崩壊)」に備える仕組みもあります。、
項目 | 説明 |
---|---|
英語表記 | fallback |
思想 | 異常が起きる前に対処しよう |
障害発生時の動作 | 異常が発生する前に縮退運転に切り替える |
具体例 | 回線速度に応じてYouTubeの画質を落とす |
3. バカに備える
最後は「fool(バカ)」に備える仕組みです。「証明(proof)」という言葉と組み合わせて foolproof
と呼ばれる仕組みは直訳すると「バカの証明」です。つまりは、「こんな使い方するやつおらんやろ!」という使い方を想定されても問題ないようにしておき、ほんとにそんな使い方をするやつのことを「バカ」といえるようにしておく仕組みのことです。
3.1. フールプルーフ
項目 | 説明 |
---|---|
英語表記 | foolproof |
思想 | 想定外の使い方に対処しよう |
障害発生時の動作 | 想定外が発生しないようにする |
具体例 | 電話番号入力フォームには数字しか入力できないようにする(バリデーション) |
まとめ
似たようなことばが並んで覚えにくいなっとなるかもですが、分類してみると少し糸口が見えたのではないでしょうか。しっかり理解して、使いこなしましょう!
以上
-
うるう年を考慮する形で365.25日をベースに計算しています。 ↩︎
Discussion