ITシステムの可用性と損失を考える

ITシステム関連は昔から現在まで、たびたび各所でサービス提供停止に至るまでの現象が起きていて、いつも他人事ではないと戦々恐々するわけでです。

そのパターンも様々だし、コストをかければ確実に解決するというわけでもないのですが、コストを含めて可用性について雑に考えてみたいと思いました。

事件例

2024年度に入って立て続けに大規模なサービスの停止が発生しており、ITシステムを扱う者ならば、その状況を追わずにはいられないのではないでしょうか。

ニコニコへのサイバー攻撃

最も記憶に新しい、というか現在進行中の事件です。多種あるサービス停止の原因の中では、トップクラスに厳しいと思われるランサムウェアによるもので、中の人には頑張ってほしいし、どう決着するのか非常に関心の強いところです。

グリコのシステム移行

これは収拾の目処が立ちそうにあるものの、外部要因ではなく内部的なシステム移行の失敗による商品の供給停止です。多くは電子データやモノの流通を扱うインターネット系と違って、物理商品の生産に関わるところにまた全く異なる性質の厳しさがありますが、原因としては人災に近い部類です。

みずほ銀行のシステム移行

他に数年前だと、みずほ銀行が長年の厳しいシステム移行からの障害多発が続いた時期がありました。金融系かつ大手ということもあり、世間の注目も高かった印象です。

情報漏洩

システムとしての可用性とはあまり関係ないとはいえ、情報漏洩も度を過ぎればサービスの停止に至るかもですし、なにより信頼に関わるため、どういった経緯で発生するのかに着目するのは重要です。

停止要因

可用性の低下に関わる要因は、外部 or 内部から、天災 or 人災系、軽症から致命傷まで様々あります。サラッと思い浮かぶものとしては、

サイバー攻撃によるサービス停止
情報漏洩によるサービス停止や損害賠償
重要基盤の障害（Network,DNS,CDN,Cloudなど）
システム移行失敗による巻き戻し・停止・終了へ
無効なバックアップによるサービス終了
サーバーリソース不足によるレスポンス異常
アプリケーションの低パフォーマンスによるサービス・機能のリリース停止
サービスの運用ミスによる緊急修正

……あたりでしょうか。セキュリティがバッチリで、インフラ管理もシッカリしていて、アプリケーションも高品質かつ運用ミスがなく、さらに強い悪意に狙われることもなければ、そのシステムは役目を終えるまで平和に稼働し続けることができるかもしれません。

しかし、全ての要素において 100% 安全であるコトはない、という前提でシステムと向き合う必要があります。どれだけセキュリティに強くともゼロデイ攻撃は存在するし、大手クラウドでも大規模な障害は発生しますし、なんなら工事によるネットワーク・ケーブルの断線なんてのも実際にあります。アプリケーションの構成や運用も複雑になってきており、最初から全くミスなくってのも経験と仕組みが整っていても難しいものです。

多岐にわたり難しいとはいえ、対策に取り組まなければサービス死の確率が高まる一方なので、十分なシステムコストと十分な人材の両面でお金をかける必要があります。

このコストで難しいところが、何も起きなければ掛け捨てに見えるし、何か起きれば投入コスト不足とも言えるし、だからといってコストを多く掛ければ必ずしも高確度で解決するわけでもない、という性質です。

悲しい言い方をすれば、悪い意味での結果論しかなく、良い意味での結果は何も起きずに正常であること、なので、コストを掛けるにしてもその量に明確な正解はないところが悩ましく、いくら投資すれば良いかというよりは、採用するシステムの品質やそれを取り扱う人材をベースにいくら必要か、と考える方が目的の達成をし易いかもしれません。

可用性

ここで復習ですが、何かが起きてシステムの利用が不可になった、その時間的な度合いを『可用性』として表します。AWS も説明してくれていますし、自分もブログ初期に学んでいました、偉いですね。

一応ここにもそれっぽい数値のところまでまとめておくと、

稼働率		1年365日当たりの停止時間
99.9999%	six nine	31秒
99.999%	five nine	5分
99.99%	four nine	52分
99.9%	three nine	8時間45分
99%	two nine	3日15.6時間
90%	ninety	36日12時間
80%	eighty	73日

意図的なメンテナンスも含めたとすると、１年間で Three Nine を守るのも結構難しいことがわかります。Two Nine となると、一時的かつ大きめな障害が発生したり、環境の移行などを行ったりしつつも、なんとか守れるだろう条件です。

さきほど出した事例や、移行失敗・リリース即死などでは、それを突き破って１ヶ月２ヶ月という単位になることがあり、外から見ていると復活できずにそのまま終了するのではないか、と心配するレベルになります。

また、ユーザーへのサービス供給が途絶えるという点では、数時間・数日単位なら復活おめでとうとなるものが、数週間・数ヶ月となると心が離れたり代替品が流通するなどで、急激に元の利用量へ戻すことが難しくなる可能性が出てきます。

システムはある程度は止まるものと認識しつつも、これ以上の期間を止めることは許容できない、という可用性の下限は確実に存在します。それがどれくらいであり、高確度で許容内に収めるにはどこにどれくらいの手間・コストをかけるべきか、と考える必要があるわけですが、

最終的には『人事を尽くして天災が降りかからないことを祈る』ことになる側面があるところが、なんとも歯がゆいジャンルです;-(

売上への影響

可用性 100% における年間の売上が 100億円として、それぞれの可用性における機会損失がどのくらいになるかをザックリと出してみます。ここでは停止時間帯が日中か深夜かなどは考慮しないこととします。

稼働率	停止時間／年	機会損失額
99.9999%	31秒	1万円
99.999%	5分	10万円
99.99%	52分	100万円
99.9%	8時間45分	1000万円
99%	3日15.6時間	1億円
90%	36日12時間	10億円
80%	73日	20億円

数値上はこうなるものの、意図的な短期的メンテナンスや、意図しない障害でも１回あたりの期間が短ければ、その期間に積まれるはずだった売上は、その復帰後に売り上がる場合も多いでしょう。その辺りは、ユーザーの信頼を損なわない方法や運用を心がけることで、十分に埋められる可能性を含む性質です。

しかしこれが、あまりに高頻度であったり長期間になると、その復帰後に停止期間分を含めた売り上げにならず、そのまま機会損失となる可能性が高まります。いわゆるユーザー離れというやつです。その損失だけで済めばまだマシで、普通に考えればその後に想定していた売上も減少し続け、元に戻すには相応の時間と労力を伴うでしょうから、数値以上の痛手となるはずです。

こう考えていくと、運用関係者が健全であれば、無理に100％の可用性を目指さず少なくとも合計99％以上となる停止猶予を持たせた運用とし、数日を跨ぐような連続した長期間の停止だけは避ければ良しとする。くらいの運用感覚になるのではないでしょうか。

適正なシステム・コスト

ではシステムはどれくらいのコストを掛けられるべきかってのを考えていきます。

ITインフラ費用としては、売上に対してどれくらいの割合かの例を見てみると、

これだと３～８％という風に見えますが、この中身の多くはトラフィックやスループットといった流量に対して増加する性質が強いでしょう。特にコンテンツ配信系ではそれが顕著になりますが、可用性の一部の要因を守るという意味では重要な要素です。

また、それら重い部分を除いた土台的な部分だけでいえば、もっと少ない割合になるとは思います。土台のシステムにもお金はかかりますが、どちらかというとそれを構築・運用するエンジニアの人件費が重要になるのではないでしょうか。

少なくともそのITシステムの土台と運用に対して、障害・事件によって許容できない日数が連続して停止することで発生する最小損失を１億円とした場合、１億円を投資することは雑ですが理にかなっていると言えるかもしれません。

実際には純利益率のことも考えなくてはだし、さきほども書いた通り額面ベースというよりは必要とするモノと人材ベースでの試算になるとは思いますが、最も避けたい選択としては『安かろう悪かったろう』という結末です。

何も起きなかったのでそれが最安値だった、という結果論には価値はありません。オンプレにしたら安く済ませられたとしても、その難しさから脆弱さを見逃すかもしれませんし、マイナーなクラウドが安かったとしても事例・経験の少なさやセキュリティ対策の遅さが重くのしかかるかもしれませんし、安い人件費ではどれだけ環境の選択が良くとも適切に扱えないかもしれません。

大規模な事件がニュースになると、注目され否応なしに感想が乱舞し、想像で開発費やセキュリティ対策をケチってそう、といった類の嘲笑が含まれたりします。

まぁ本当にケチる企業もあるかもですが、実際にはケチるというよりは、組織的にそのジャンルに強い関心がないとか、アサインしているエンジニアが力不足もしくは関心が高くも気付けない穴があった、というニュアンスの方が現実的そうです。もしくは、原因があまりに想定外とか、攻撃手法が上手過ぎた、という方向もありえるでしょう。

しかしながら、仮に事前に数億円をセキュリティや可用性に対して投資するとして、実際に原因となっただろう何かしらのピンポイントの脆弱性を防げたかと言うと、そこまで確度が高まるほどではないように思います。

優秀なエンジニアを雇うとか、第三者の診断サービスを利用するとか、で強固になる可能性はもちろんありますが、もし常識外のポイントなら投資額が万単位だろうと億単位だろうと結果的に防げなかったとなる可能性は残るわけで、

どちらかというと、大元の環境選択とか、初期の設計や計画、攻撃のターゲットになりえるのか対策は継続しているのか、といった根本的な要因の方が可用性との関係性が強く、それはやはり人材による人的判断の積み重ねと──最終的には運ということで、極端な投資額が解決するわけではないように思います。

適切なシステムと人材

ではどういったシステム環境なら可用性を高められるのか、も考えてみます。

身も蓋もない前提としては、小規模なら数人以上、大規模なら十数人以上の優秀なエンジニアがいる、ということになりそうです。この『優秀』とは、十分な知識と特に経験をもって、目の前の条件や環境に対して適切な判断を下せるということです。経験量が重要なのは、事象の認識と対処精度に大きく関わるためです。

そういった人物を軸に、日々正常であることを守るための取り組みを周囲に広げ、おそらく専任というよりは複数人での兼務という形に落ち着くと思われます。こういう地味だけど重要な取り組みは、文化や習慣のような形に残るべきで、１人などに頼り偏らせて人事や退職の影響を受けることは避けたいところです。

また、経験量が重要なのは個人だけではなく組織にも当てはまります。

別に AWS を推すわけではないですが、やはり AWS くらい大手だと外的要因による事象やセキュリティ関連に対して、強い仕組みや敏感な告知が十分に成されている印象が強いです。これはそういうビジネスである面に加えて、多くの企業による要望やサポートケースによって改善が継続的に進行しているはずで、大手ならではの強みはそのまま可用性に直結すると思われます。

利用者視点としては、クラウドには責任分界点が明確に存在します。これにより、そこまで広く高い技術力がなくとも、重要かつ難しいインフラ部のレイヤーを任せることができ、カスタマー部のレイヤーに注力できる強いメリットとなります。

オンプレミスでもデータセンター方面の企業との契約次第で責任分界点を設けたり、全てを自分たちで面倒見るといった選択ができます。それにより自由度と安価を実現できるかもですが、その分は広範囲の技術力と人材・運用コストが発生するため、どうしても品質として足りないというか穴が発生しやすくなると思うので、今の時代にやり切ろうとする判断はかなり重いものとなるでしょう。

私自身、過去から現在までかなり幅広い構築を手掛けてきましたが、特にオンプレにおいては「全ての箇所が漏れなく安全安定だよ」なんて口が裂けても言える自信はありません。最近だと JAXA で VPN機器自体をターゲットにされた事例もありました。

安全と思われるネットワーク機とVPNプロトコルを用いて、可能な限り最小条件での開放などを心がけて、結果的に今まで無事故で運用できていますというだけかもしれません。明日以降もそうとは限らないし、VPNに限らず自信のないパーツを埋めるよう人材を集めたら大丈夫かというと、それでも 100％にはなりません。

それは大手クラウドの各種マネージドサービスでも同じことですが、それでも元々の品質に加えて、対策のキャッチアップの早さや検知もろもろを考慮すると、割高であるだけの価値はあると捉え余さず享受すれば、やはり大手クラウドの活用に優位性があるように思えます。──これは私の自信の足りなさゆえの感想であり、強固な環境と人材でやりきる組織もあるかもですが、大半の組織には当てはまる気はしています。

おわりに

営利企業である以上は、第一に重宝されるのは売上をあげる部署や人材で、それを守る立場や役割が注目されづらいのは宿命です。守ってばかりいても利益になりませんので。

そして機会損失という項目も非常に可視化しづらく、数字を見る立場の人と、現場のエンジニアとでは感覚が剥離するのもある程度は仕方のないことです。

ベンチャー企業など規模が小さいほど、そういった課題をかかえ──というか認識すらしていなかったり、技術的経験値が浅くも、規模の小ささゆえに助かっているという側面もあるでしょう。しかし成長の過程で必ずどこかで可用性と損失については襟を正すタイミングがやってきます。

その時に、ただ安いからとか、なんとなく使いたいからとか、ではなく具体的で現実的な機会損失額や、技術的選定での実績や信頼度を元に、論理的にこうすべきであると主張できるようになれると、将来的にシステムだけでなく組織文化的にもそうなっていって、高い可用性に繋がっていくのではないかと信じたいところです。

また大規模になるほど、技術や文化に関わる見直しや方向転換が効きづらくなっていきます。システム的にも複雑さが増していくので、各所で可用性を高く保つということが難しくなっていき、どこかに脆弱さが残っていても不思議ではなく、たまたまそれまで無事だっただけかもしれません。となると、もう良いオチすら思いつきません。

なので日々の研鑽と対応を怠らず、かつ運が悪くならないよう日々徳を積んでおくことで、0.01% くらいは可用性を高めるのが人間の限界かもしれません:-)