クラウドと可用性

可用性（アベイラビリティ）

まず最初に可用性についての復習をしてみましょう。

可用性は英語のavalability（アベイラビリティ）を日本語に訳した言葉で、簡潔に述べると「利用したいときに利用できる能力」という意味です。日本語としては稼働率と呼ばれることもあります。

例えば、あるサービスのウェブサイトが、障害が起きない、あるいは障害が起きてもすぐに復旧していつでも利用できる状態にあるとします。このような状態にあるものを可用性が高いということができます。

それでは、あなたが可用性が高いシステムについて利用を検討したり、お客様に提案したりするとしましょう。このとき、可用性の高さについてどのように評価したり、説明したりすればよいのでしょうか。一つの例として、売り文句として「年間ダウンタイムが50分以内」というのはわかりやすいでしょう。しかし、実際には、可用性を数量化した尺度として、一定期間内において利用できる状態の確率や時間の割合を使います。例えば、先の例と同じく年間ダウンタイムを50分以内と想定した場合は次のように計算して（年間）可用性99.99%と表現することができます。

可用性 = 動作可能時間 / 期間 = (1年 − 50分) / 1年 = 0.9999 = 99.99%

この可用性（アベイラビリティ）の尺度については様々なものがあります。『JIS Z 8115:2019 ディペンダビリティ（総合信頼性）用語』に「アベイラビリティ」の定義がありますので、ご興味のある方はご覧ください。参考までに「アベイラビリティ」は次のように定義されています。

要求どおりに遂行できる状態にあるアイテムの能力。

注記3 ハードウェア及びソフトウェアから構成される製品のアベイラビリティは，運用上の必要事項を考慮して定義される。すなわち，アベイラビリティとは要求された外部資源が用意されたと仮定したとき，アイテムが与えられた条件で，与えられた時点又は期間中に，要求機能を実行できる状態にある能力である。

なお、私たちが指標としての可用性や稼働率を用いる場合はたいていは次の定義の「運用アベイラビリティ」（operational availability）のことを意味しています。

実際の運用及び保全の条件下でのアベイラビリティの実績値。

運用アベイラビリティは次の計算で求められます。

運用アベイラビリティ (Ao) = 平均アップタイム (MUT) / (平均アップタイム (MUT) + 平均ダウンタイム (MDT))

指標としての可用性・稼働率

クラウドのシステムでは、指標としての可用性・稼働率を用いるときには、月間を基準とした月間可用性/月間稼働率で評価することがほとんどです。 月間稼働率と月間ダウンタイムについて表にまとめると次のようになります。

クラウドの可用性

SLAとSLO

クラウド事業者は提供しているサービスに対してそれぞれSLA（Service Level Agreement, サービスレベル契約）やSLO（Service Level Objective, サービスレベル目標）を示しています。

SLOについては次のGoogleのページの説明が参考になると思います。

• SLO の定義 (Google)

SLAはあくまでも契約であって、そこで示された可用性の通りになるというものではありません。しかし、SLAで示された数値がどの程度の可用性を目標にしているかの参考にはなるでしょう。

参考までに、Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP)の仮想マシンインスタンスについてのSLAやSLOをまとめると次のようになります（2021年9月時点）。なお、SLAは時々改定されるため、最新のSLAを確認してください。（2021年9月27日修正: AWSの単一インスタンスのSLAが改訂されましたので修正しました）

※Azureでは単一インスタンスの場合はストレージタイプによりSLAが異なります。ここで示したのはぞれぞれ、Standard HDD, Standard SSD, Premium SSD/Ultra Diskの月間稼働率となります。

ここでいう「ゾーン冗長構成」は2つ以上の可用性ゾーンにそれぞれ仮想マシンインスタンスを配置した構成のことと定義します。

• Amazon Compute Service Level Agreement (AWS)
• SLA for Virtual Machines (Azure)
• Compute Engine Service Level Agreement (SLA) (GCP)

想定される障害と可用性

先に紹介した仮想マシンインスタンスのSLAは原則としてゾーン冗長構成に適応されています。Azureは単一インスタンスについてもSLAを適応されていますが、ゾーン冗長構成よりは低い稼働率が設定されています。これは、単一インスタンスの場合は次のような規模の障害の発生が予め想定されており、高い可用性の目標は設定できないからです。

• 仮想基盤ホストやラック規模の障害
• データセンター規模の障害

このような障害への対策としてゾーン冗長構成にすることにより、可用性を向上させることができます。

情報処理の教科書で出てくるような並列接続したシステムの稼働率計算に当てはめてみるとわかりますが、ゾーン冗長構成にすると可用性は高くなります。

例えば、月間稼働率99.5%（ダウンタイム3時間39分）と仮定した仮想マシンインスタンスを2個の可用性ゾーンにそれぞれ配置した場合には総合的には月間稼働率99.9975%（ダウンタイム1分）になります。

稼働率 = 1 - (1 - 0.995) × (1 - 0.995) = 0.999975 = 99.9975%

このようにゾーン冗長構成にすると可用性が著しく向上することがわかります。

ここでは仮想マシンインスタンスの例を示しましたが、マネージドサービスの場合も同様にゾーン冗長構成にすると可用性を向上できます。

なお、実際の障害原因は上述のようなハードウェア寄りの想定できる原因だけではなく、後述するソフトウェアのバグのような想定外の原因もあるため、単純にこのような計算通りの可用性向上が図れるわけでもないです。

また、低レイテンシーが要求される場合には、一つの可用性ゾーン内にすべてを配置せざるを得ないケースも存在します。可用性ゾーン間のネットワークレイテンシーは1〜2ミリ秒あるため、それが許容できない場合です。このような場合はゾーン規模の障害が起きないことを祈りましょう。あるいは、システム構成を見直して、部分的にネットワークレイテンシーを許容できるようにして、ゾーン冗長構成にするかです。

複数のマネージドサービスを連携する場合の可用性

複数のマネージドサービスのコンポーネントを連携する場合は、情報処理の教科書で出てくるような直列接続したシステムの稼働率計算を当てはめてみるとわかりますが、可用性は低下します。

例えば、月間稼働率99.99%（ダウンタイム4分23秒）と仮定したゾーン冗長構成のマネージドサービスのコンポーネントを3個連携する場合は総合的には月間稼働率99.97%（ダウンタイム13分）になります。

稼働率 = 0.9999 × 0.9999 × 0.9999 = 0.9997 = 99.97%

月間稼働率99.5%（ダウンタイム3時間39分）と仮定した冗長構成でないマネージドサービスのコンポーネントを3個連携する場合は総合的には月間稼働率98.5%（ダウンタイム11時間）になります。

稼働率 = 0.995 × 0.995 × 0.995 = 0.985 = 98.5%

稼働率の高いコンポーネントを組み合わせた場合は稼働率はあまり低下しないことがわかります。しかし、稼働率の高くないコンポーネントを組み合わせると稼働率が大きく低下することがわかります。

ゾーン冗長構成で対応できない障害

ゾーン冗長構成でも対応できない障害が発生することがあります。

David Mytton氏の記事『What are the common causes of cloud outages?』によると、クラウドの障害の主な原因としてソフトウェアのバグが挙げられています。その他にも、設定の誤りやヒューマンエラーやリソース枯渇なども挙げられています。

これらを原因とする障害がリージョン共通のリソースやグローバル共通のリソースで生じた場合は、ゾーン冗長構成では回避できないこともあります。ここら辺になるとクラウド事業者側としても想定外でしょう。

過去のクラウド事業者のグローバルあるいはリージョン規模の障害事例を考えると、ダウンタイム2,3時間を想定した方が安全でしょう。

リージョンリソースやグローバルリソースの障害への対策としては、ぞれぞれマルチリージョン構成やマルチクラウド構成にすることです。 しかし、このような構成はコストが倍増しますし、システム構成もネットワークレイテンシーや可用性を考慮したものにする必要があります。例えば、分散データベースや分散データストアを活用したり、拠点間のコンポーネントの疎結合を徹底したりします。 さらに、マルチクラウド構成にする場合には複数のクラウド事業者のサービスを理解しているエンジニアの確保が必要ですし、マネージドサービスを利用しづらかったりもします。

そのため、想定外レベルの障害への対策としてマルチリージョン構成やマルチクラウド構成を検討する場合は、そこまでの可用性が本当に必要かどうかをまず検討する必要があるでしょう。障害時の機会損失が大きすぎる場合とか、事業継続計画として必要な場合とか。

ハートビーツの事例

最後に、弊社ハートビーツでの事例を紹介します。

ハートビーツが提供している監視一次対応サービスやマネージドサービスでは、お客様のシステムの障害対応を行う業務があります。社内システム基盤として利用しているクラウド事業者のサービスに障害が発生しても障害対応を継続させる必要があります。そのため、社内システム基盤の月間稼働率を99.995%（ダウンタイム2分11秒）を担保するように設計しており、そのためにマルチクラウド構成にしています。 そのマルチクラウド構成に関する事例の一部を以下のブログエントリーとして書いています。

• OctoDNSとGitLab CI/CDを利用した複数DNSプロバイダー構成の運用 - 前編:OctoDNSの紹介
• OctoDNSとGitLab CI/CDを利用した複数DNSプロバイダー構成の運用 - 後編:GitLab CI/CDの利用
• WireGuardによるマルチクラウド構成VPNの事例紹介
• マルチクラウド構成におけるMySQL Group Replicationの利用事例紹介

この社内システム基盤上に、リモートアクセス環境や監視・一次対応業務で利用するアプリケーションの冗長化などを行っており、アラート発生から10分以内に一次対応作業に着手するというSLOを実践しています。

まとめ

• 原則としては、ゾーン冗長構成にすることで可用性は向上する。
• クラウド事業者側のソフトウェアのバグやヒューマンエラーなどが原因の障害ではゾーン冗長構成でも回避できない場合がある。
• マルチリージョン構成やマルチクラウド構成は本当にそのレベルの可用性が必要かどうかを検討する。

参考資料

• SLO の定義 (Google)
• What are the common causes of cloud outages? (David Mytton)