システム障害は無くて当たり前？
弥生の募集要項を眺めていると、募集要項の主な取り組みに「障害が無いのが当たり前」と書いてあったので、これについて考えてみます。ちなみに本当にたまたま目に入っただけで弥生とは一ミリも関わりはありません。
結論として「障害がないのが当たり前」という考え方自体を完全に否定します。「障害はあって当たり前」と考えるべきです。障害の考え方を説明し、最後は、何故そのようにすべきかをまとめます。
障害が無いとは
システムが継続して稼働する能力の事を可用性(Availability)と表現し、その定量的な指標として稼働率を用います。障害が無いというのは、つまりこの稼働率が100%の状態を意味します。求め方は以下のようにシステムの稼働と停止していた時間の内、稼働していた割合を求めます。
稼働率 = 稼働した時間 / ( 稼働した時間 + 停止した時間 )
例えば、稼働した時間が95時間、停止した時間が5時間の場合における稼働率は、95/(95+5) = 0.95 (95%)となります。 1年間における停止日数は、365 * 0.05=18.25日となります。
稼働率100%は存在するか
過去の実績として100%は存在します。本日から過去3週間にかけて全く停止しなければ、それば稼働率100%と言えます。しかし、本日から未来にかけて稼働率100%を「保証」できるかと言われればそれは不可能です。 システムはコンピュータ上で動きます。クラウドだろうが何だろうが、コンピュータは物理的な機械であって、その機械はこの世界の中のどこかのデータセンターに存在します。2020年現在において人間は、地震や津波や台風などの自然災害をコントロールできません、つまりこれらのシステムはいつでも停止するリスクが存在します。停止する可能性が0にならないので稼働率を保証する事はできません。
クラウドサービスの稼働率とSLA
例えばAmazonのAWSでは提供されているサービス毎に利用契約によって保証する稼働率をSLA(Service Level Agreement)として定義しています。現在の保証内容と、代表的なサービスのSLAは以下の通りです。
99.0％以上SLA未満 10%返還
95.0％以上99.0％未満 25%返還
95.0%未満 100%返還
AWS S3 : 99.9%
AWS EC2 : 99.99%
AWS Dynamo : 99.999%
AWS Route53 : 100%
各サービスのSLAはこちらから
Route53はDNSのサービスですが、100%だからと言って絶対に停止しないという事を保証している訳では無くあくまでもSLAとしてこれが守れなかった場合にクレジットを返還しますという意味です。稼働率99%は、年間だと3日と15時間程度停止する水準です。
CloudHormonyでは、稼働率の実績が直近の30日間まで確認できます。自分が確認したタイミングではAmazon EC2のus-east-2リージョンでダウンタイムが発生していました。
障害はあって当たり前だと考えるべき理由
1) リスクヘッジの機会を奪う
「障害はなくて当たり前」というのが前提だとすると、例えば「このシステムでは障害が起こらないようになっているので、障害が起こった時の事なんて考える必要は無い」のように考えることもできます。それまでは100％の稼働率であったものが明日からもそうとは限りません。想定外のインシデントが発生した時に、被害を最小化するためには事前に対策する必要がありますが、考えるきっかけを奪ってしまってはそれができません
2) システムが稼働している事が評価されない
Amazon AWS, Google GCPでさえダウンタイムが発生しています。それだけミッションクリティカル(24時間365日落としてはならない)なシステムは難しいという事ですが、それを理解せずにシステム障害は無くて当たり前だと思っているのが会社の上司だったらどうでしょうか。例え難易度が高かったとしても、そこに苦労があったとしても何も評価してもらえないでは無いでしょうか。それどころか、障害が発生したら理由が何であれ作った人が悪いと決めつけ責め立てるかもしれません。
いや、めっちゃこのプロジェクトしんどかったんだけどそこまで給料あがんないなーみたいなことがありました。当時は自分も動いていて当然だと思っていたので何も不満は無かったですが、今では全くもって割りに合わない仕事だと思うようになりました。
3) ソフトウェアにバグが無い事は証明できない
障害の原因は様々ありますが、例えばソフトウェアのバグだとします。以下ソフトウェアテストの7原則では、「テストは欠陥があることは示せるが、欠陥がないことは示せない」としています。バグが無いことの証明ができないなら障害が無い事も証明できません。ならば、障害はあって当たり前だと考えるしかありません。
藁人形論法ですが、バグをソフトウェアの仕様としてしまえば、そのソフトウェアは仕様通りに動くので、障害は無いと言えるかもしれません。
マネージャーがバグが多い事でエンジニアを責めました。そのエンジニアは、責められた事でヤケになっていてループの1から100まで全てをテストするような仕様書を作っていました。実質的にはそれらのテスト項目は1つで良く他は不要です。 そもそもバグが無い事を証明できない事を理解していれば、こんな不毛な時間を過ごさなくても良かったんじゃ無いでしょうか
4) データはいつでも誤る
インターネットでやりとりされるデータは、チェックサムを使って伝送誤りが無いかどうかをチェックしています。しかしながらチェックサムは絶対に間違っている事を保証できないので、例えデータに損失があってもすり抜ける可能性があります。HTTPSなどSSLを通しているアプリケーションプロトコルを使っていれば、複合した文字列は改竄されていないことが保証されているので安心でしょうか？ そんな事はありません、サーバーに送ったデータはSDRAMに展開したり、その先はHDDやSSDに保存するかもしれません。ここではECCなどの誤り検出、誤り補正が使われますが、100%を保証するものではありません。当然エラーになればOSやミドルウェアで再読み込みしたり書き込みを行いますが、その後データが欠損しないとは限りません。RAIDを組んでいても、同じタイミングでディスクが壊れたら復旧できません。そもそも可用性を決めるファクターが100%を満たさないのに稼働率が100%とかあり得ません。
大規模な基盤システムを運用していました。当時mysqlを使っていましたが、レプリケーションを貼ったスレーブがディスク不良を起こして障害を起こしたことがありました。買ったばかりのSSDでしたが、不良セクタが修復できず、レプリのインスタンスを新しく作るという作業で対応しました。その間システム自体は落ちては無かったですが、全体のレイテンシに影響が出ました。 今はmysqlでGTIDができてレプリ運用が楽になっていますね。checksum機能もつきましたし。
まとめ
障害はあって当たり前だという前提に立ち、起きてしまったらどうするかを考えることが重要
この記事が気に入ったらサポートをしてみませんか？