はじめに

システム開発の現場では「止まらないシステムにしてほしい」という要望をよく耳にします。一見シンプルですが、いざ要件として落とし込もうとすると、何をどこまで実現すべきか曖昧になりがちです。

本記事では、非機能要件のひとつである「可用性（Availability）」について、身近なコミュニケーションツールであるSlackを題材にしながら、考え方と要件化のポイントを整理していきます。

目次

非機能要件と「可用性」
稼働率の「9」が持つ意味
「停止時間 × 影響ユーザー割合」という測り方
プラン別の保証と補償の考え方
99.99%を支える「セル化」アーキテクチャ
「止まらないようにしてほしい」をどう要件にするか
ケースで考える可用性の落とし所
まとめ

非機能要件と「可用性」

非機能要件とは、システムが何ができるかではなく、どのように動くかを決める要素のことです。ログインができる、メッセージを送れる、決済が完了するといった機能要件に対して、非機能要件は可用性・性能・保守性・セキュリティといった品質面を扱います。機能が動くことは大前提として、その上で安心して使い続けられるかを左右するのが非機能要件です。

その中でも可用性は、必要な人が、必要なタイミングで、約束した機能を業務に使える状態を保つこと と定義できます。

ここでひとつ注意したいのは、サーバーが起動している＝可用性があるではない、という点です。サーバープロセス自体は動いていても、ログインができない、画面が表示されない、処理がタイムアウトする、といった状態では業務には使えません。一方でユーザーがログイン・検索・登録・更新といった重要操作を期待通りに完了できる状態であれば、そこには可用性があると言えます。

つまり可用性とは、システム目線の稼働ではなく 利用者目線で業務が止まらないか を測る考え方です。

稼働率の「9」が持つ意味

可用性を語るときによく登場するのが 99.9% や 99.99% といった稼働率の表現です。9が1つ増えるたびに、許容できる停止時間はおおむね10分の1に圧縮されます。

稼働率	年間の停止許容時間	想定される用途
99.9%	約8時間45分	社内ツール・ナレッジ共有など
99.99%	約52分	注文受付・動画配信・重要業務など
99.999%	約5分15秒	ATM・通信・社会インフラなど

稼働率が上がるほど運用コストや設計の難易度は跳ね上がります。そのためとにかく高ければ良いではなく、業務の性質に応じて適切なラインを選ぶことが重要になります。

「停止時間 × 影響ユーザー割合」という測り方

Slackの可用性指標は、ユニークな考え方に基づいています。停止時間に加えて、その障害が影響したユーザーの割合まで含めて算出する という方式です。

たとえば全ユーザーの1%だけが利用できなかった障害と、全ユーザーが利用できなかった障害では、同じ30分でもビジネスインパクトはまったく違います。Slackはこの違いを評価に織り込むため、サービス全体の影響規模を加味した独自の計測を行っています。

ではその影響を受けたユーザーをどう特定しているのでしょうか。Slackは個別ユーザーを名指しで追跡しているわけではなく、複数の技術シグナルを組み合わせてサービス品質を計測しています。Slack Engineeringの技術ブログによれば、社内では SDI（Service Delivery Index） という品質指標が運用されており、次のような要素から算出されています。

• API成功率（成功したリクエスト数 ÷ 総リクエスト数）
• エッジ（CDN）でのコンテンツ配信成功率
• 重要なユーザーワークフローの成功率（メッセージ送信、チャンネルの読み込み、ハドルの利用など）

加えて、サーバー側のエラー率、pingテスト、TCPポートテスト、Webサーバー／Webサイトテストといった外形監視シグナルを常時計測しています。これら重要操作のいずれかが事前に定めた閾値を下回った場合、その時間がダウンタイムとしてカウントされる仕組みです。サーバーは生きているがメッセージが送れない状態も、きちんと障害として扱われる設計になっています。

そしてワークスペース単位でどの程度の割合のワークスペースが異常状態に該当していたかを集計し、停止時間と掛け合わせて月次のダウンタイムを算出します。ユーザー個別の体感ではなく、サービス全体の影響規模で評価する というのがSlack方式の特徴です。

プラン別の保証と補償の考え方

Slackの稼働率保証は、プランによって有無が分かれます。

プラン	稼働率保証
Free / Pro	なし
Business+	99.99%
Enterprise+	99.99%

Business+以上のプランで99.99%を下回った場合、ダウンタイムに該当する時間分の料金の100倍 がサービスクレジットとして返金されます。

※ 稼働率保証（SLA）とは、稼働率を契約で約束し、守れなければ補償する仕組みのことです。

99.99%を支える「セル化」アーキテクチャ

ではSlackはどのようにして高い可用性を実現しているのでしょうか。その鍵となるのがセル化と呼ばれるアーキテクチャです。

Slackにおけるセル化とは、AZ（アベイラビリティゾーン）ごとに通信を完結させ、障害を局所化する設計思想です。複数のAZ内でそれぞれ処理が完結するように構成されており、仮にあるAZで障害が発生しても、その影響はAZ内に閉じ込められ、他のAZには波及しません。故障したAZを切り離すことで、サービス全体への影響を最小限に抑える仕組みです。

※ AZ（アベイラビリティゾーン）とは、クラウド上の同じ地域内にある、物理的に分かれたデータセンターを指します。

「止まらないようにしてほしい」をどう要件にするか

冒頭で触れたように、止まらないシステムにしてほしいという要望は、そのままでは要件になりません。可用性を要件に変換するには、いくつかの観点から 業務影響を具体化していく 必要があります。

最初に考えたいのは誰が困るのかです。社内利用者だけが困るのか、それとも顧客にまで影響が及ぶのかによって、求められる水準はまったく違ってきます。次に何が止まると困るのかを切り分けます。すべての機能が同等に重要というケースは稀で、多くの場合は決済処理や注文受付など一部のクリティカルな機能が業務継続の鍵を握っています。

時間軸の観点も外せません。平日昼間だけ動いていれば十分なのか、24時間365日の稼働が必要なのか。さらに何分までなら止まっても許容できるのかを整理することで、復旧時間の目標（RTO）が見えてきます。

そして見落とされがちなのが、代替手段の有無 です。電話やメール、手作業で業務を継続できるのであれば、システム側に求める可用性は下げられます。逆に代替がきかない業務であれば、その分だけ高い水準が必要になります。

最後はコストです。冗長化・監視・待機体制には相応の費用がかかります。その投資に見合う効果があるかを判断するには、ここまでの観点で整理した影響の大きさと突き合わせる必要があります。

これらの観点を順に検討することで、止まらないシステムという曖昧な要望が、設計判断ができる粒度の要件へと落ちていきます。

ケースで考える可用性の落とし所

実際の検討イメージとして、性質の異なる2つのシステムを比較してみます。

ひとつ目は 社内ナレッジ共有ツール のケースです。利用は平日日中が中心で、夜間や休日に停止しても業務影響は軽微。このようなシステムでは目標可用性を99.9%（月間約43分以内の停止を許容）に置き、シングルAZ＋バックアップといったコスト重視の冗長構成を選ぶ判断が現実的です。業界標準ラインに乗せつつ、運用コストを抑えるバランスが取れます。

一方、顧客向け注文受付システム はまったく性質が異なります。24時間365日稼働が前提で、深夜や休日にも注文が発生するため、停止は即座に売上機会の損失につながります。このケースでは目標可用性を99.99%（月間約4分以内）まで引き上げ、マルチAZ＋自動フェイルオーバー＋常時監視といった可用性最優先の構成を選ぶ判断が妥当になります。コストはかかりますが、売上と顧客信頼に直結する以上、その投資には十分な意味があります。

同じ可用性という言葉でも、システムの性質によって目指す水準と設計判断はここまで変わります。重要なのは、最初から数字を決めにいくのではなく、業務影響から逆算してその数字に辿り着く ことです。

まとめ

可用性はサーバーが稼働しているかではなく、業務に使えるかという利用者目線で見るべき指標です。そして可用性レベルは抽象的に「目指すもの」ではなく、業務影響とコストから現実的に決めるものだと言えます。

設計に入る前に、「どの業務が、何分止まると、誰にどの程度の影響が出るのか」を整理しておくこと。これが、現実的で納得感のある可用性設計につながる第一歩になります。

身近なツールであるSlackも、独自の測定方法とセル化アーキテクチャの積み重ねによって99.99%という水準を実現しています。自分たちのシステムにとってのちょうどよい可用性を見つけるヒントとして、本記事が参考になれば幸いです。