信頼性とは?知っておくべき信頼性メトリクス

Observability Joseph Nduhiu

絶えず変化する顧客や関係者のニーズに対応し続ける中で、IT環境は複雑さを増しています。その結果、ITシステムを常に安定して稼動させることは、ますます困難になっています。

事実、回答した大企業の82%が、ITの複雑さがデジタルトランスフォーメーションで期待される成果の妨げになっていると考えています(ここで言う成果とは、生産性の向上、イノベーションの促進、コラボレーションの強化、セキュリティの改善、顧客満足度の向上などです)。

どのような状況下でも頼れる信頼性の高いシステムをITチームが確実に提供できるようにするためには、求められる可用性やパフォーマンスを効果的に追跡するための最適なメトリクスを理解しておくことが重要です。

そこでこの記事では、アップタイムとパフォーマンスに関する信頼性の要件に対応するために組織が注目すべき主要なメトリクスについて説明します。

信頼性とは?

NISTでは信頼性を以下のように定義しています。

システムまたはコンポーネントが、一定の期間、一定の条件下で障害を発生させることなく稼動し続ける能力。

信頼性は、設計段階からITシステムの内部に組み込まれている必要があります。これにより、高い稼動率を求め、中断をできるだけ避けたいユーザーの大きな期待に応えることができるのです。

信頼性の高いサービスを提供するために活用できる最適なメトリクス

ここで紹介するメトリクスは、組織が必要なアップタイムとパフォーマンスを確保するために役立ちます。また、信頼性メトリクスとは異なる観点として、ITシステムの一般的な障害メトリクスもご紹介します。

平均故障間隔(MTBF)

障害発生の頻度が低い場合、そのITサービスやインフラは信頼性が高いとみなされます。平均故障間隔(MTBF)は、何らかの障害が発生する頻度を追跡するための可用性メトリクスです。

平均故障間隔

配車サービスのモバイルアプリの例を考えてみましょう。1つの問題発生(配車をリクエストできないなど)から別の問題発生(請求書を作成できないなど)までの平均経過時間はどれくらいでしょうか?問題の根本原因の観点からすれば、それぞれの障害は類似している場合もあればまったく異なる場合もありますが、重要なのは、長期的にどれだけ安定性を維持できるかという点です。

MTBFを、MTRS (平均サービス回復時間)などのメトリクスと組み合わせることで、サービスの信頼性をさらに正確に把握できるようになります。MTBFを高く維持しながらMTRSを低く抑えることが、高可用性サービスを設計する上で不可欠です。

障害発生率(ROCOF)

ITコンポーネントのライフサイクル全体を通じて、障害の発生は避けられません。完璧なシステムは存在しないからです。コンポーネントの老朽化に伴い、修理やバグの修正、部品の交換、その他の復旧作業が実施されますが、これらの対応が将来的な障害発生の頻度に予期せぬ影響を与える可能性があります。

障害発生率(ROCOF)は、修理が可能なシステムでの障害発生の頻度を測定するための信頼性メトリクスです。障害や修復による影響にはさまざまな要因が関わるため、ROCOFはシステムごとに異なる場合があります。

ROCOFは以下の方法で計算します。

  1. 多数の類似システムを対象に、一定期間の累積障害数を観察する。
  2. その期間における障害数の平均値を求める。

このメトリクスによって、障害の発生しやすさの傾向を把握できます。特に保証期間の終了後、大規模な修理の実施後、あるいは多くのメンテナンス作業後のシステムにおける障害発生の頻度の傾向を知るのに役立ちます。ROCOFのデータは、具体的には以下のように活用できます。

オンデマンド障害確率(PFD)

コンポーネントのパフォーマンスと過去の障害に関する十分なデータを収集して分析することで、ITシステムに負荷がかかった際に障害が発生する可能性を予測できるようになります。

オンデマンド障害確率(PFD/PFOD/POFOD)というメトリクスは、システムが特定の機能をオンデマンドで(つまり要求に応じて)実行しようとした際に、その実行に失敗する確率として定義されています。

このメトリクスは、主に車のエアバッグやミサイルのような、1回限りの使用が想定されるシステムに利用されます。ただし、キャパシティが固定されているITシステムや、修理できないITシステムにとっても重要な指標となる場合があります。

ピーク時のパフォーマンスは、ITシステムの信頼性を測る重要な指標です。

PFDを測定することで、ITチームは、システムが要求を効果的に処理し、過負荷状態を回避できる可能性をより正確に予測できるようになります。

エラー率

最後の信頼性メトリクスはエラー率です。これはリクエストが失敗する割合として定義されます。このサービスレベル指標は、サイトリライアビリティエンジニアリング(SRE)の4つのゴールデンシグナルのうちの1つです。これらのシグナルの役割は以下のとおりです。

エラーは、ソフトウェアのバグやハードウェアの障害などの問題を示している可能性があるため、ITの健全性を測る上で重要な指標となります。エラーには次のようなものがあります。

エラーの発生率を測定することで、ITチームは根本的な問題を把握し、それが重大な障害に発展する前に対処できます。

SREではエラーバジェットというメトリクスを使用します。これはエラー率を追跡するためのメトリクスであり、必要に応じて取り組みの焦点をイノベーションからシステムの安定化へと切り替えるための制御メカニズムとして機能します。これは、サービスのあらゆる側面に適用される「エラーに対するユーザーの許容度」と考えることができます。

エラーバジェットは、サービスのSLO (可用性など、サービスレベル目標)の値を1から差し引いて算出されます。例えば、SLOが99.9%のサービスであればエラーバジェットは0.1%であり、これは特定の期間内で100万件のリクエストに対して1,000件のエラーが許容されることを意味します。

(関連記事:SLOとSLIの違い)

信頼性について

複雑なITシステムの信頼性を測定するのは困難な作業です。IT組織は、そのために適切なツールを選び、投資する必要があります。そうすることで、膨大なデータを収集して分析し、ITシステムの安定性と障害発生の可能性に関するインサイトを獲得できるようになります。

しかし、無計画に資金を投じることには、大きなリスクが伴う可能性があります。企業は、自社にとって最も重要な指標の測定に注力し、ツールへの投資から得られる信頼性メトリクスを効果的に活用して行動できるよう、組織体制を整える必要があります。

このブログはこちらの英語ブログの翻訳です。

関連記事

Snowflake DB:クラウド上のSnowflakeをグラフで監視
オブザーバビリティ
4 分程度

Snowflake DB:クラウド上のSnowflakeをグラフで監視

Splunk Observability Cloudのダッシュボードとディテクターで、Snowflakeデータベースの使用状況に関するインサイトを取得できます。
Infrastructure as Codeとは?IaCの概要
オブザーバビリティ
12 分程度

Infrastructure as Codeとは?IaCの概要

このブログ記事では、Infrastructure as Codeの概念、そしてInfrastructure as Codeのアーキテクチャに関するメリットとリスクについて説明します。
.conf25でのSplunk Observabilityに関する発表のまとめ
オブザーバビリティ
20 分程度

.conf25でのSplunk Observabilityに関する発表のまとめ

.conf25でSplunkは、AI時代のデジタルレジリエンスを再定義して、ビジネスクリティカルな問題の検出と調査にさらなる効率化をもたらす数々の新機能を発表しました。