アプリケーションの可用性は、アプリケーションが稼働している時間です。
この記事を読み終えると、以下のことができるようになります。
関連コンテンツ
是非、Cloudflareが毎月お届けする「theNET」を購読して、インターネットで最も人気のある洞察をまとめた情報を入手してください!
記事のリンクをコピーする
アプリケーションの可用性は、アプリケーションが動作している時間から測定されます。アプリケーションが期待通りに機能し、ユーザーのリクエストに対応している場合に利用可能であると言えます。アプリケーションが機能していないか、エンドユーザーが到達できない場合、アプリケーションは利用不可能ということになります。
Webアプリケーションの開発の重要な部分は、その可用性を最大化することです。アプリケーションの可用性は、バックエンドインフラの最適化、フロントエンドの最適化、攻撃軽減の組み合わせによって改善できます。
ユーザーはWebアプリケーションの可用性に大きな期待を寄せています。ダウンタイムは、収益と評判の両方に大きな影響を与える可能性があります。お店の「営業時間」を考えてみてください。予期せぬ時間帯に店舗を閉めている場合、顧客は他の場所に行ってしまいます。同様に、ソフトウェアアプリケーションから必要なサービスを得られないユーザーは、そのアプリケーションの使用を停止し、結果として顧客が減少し、収益が失われます。
ビジネスツービジネス(B2B)アプリケーションの場合、可用性は通常、サービスレベル契約(SLA)の一部として含まれており、アプリケーションが稼働していると予想される時間の割合で表現されています。そうした場合のアプリケーション開発者は、顧客に特定の可用性レベルを提供する契約上の義務を負います。
「可用性」は、サーバーからアプリ、APIまで、あらゆる種類のシステムやサービスに適用される概念です。割合(%)で測定:毎時36秒ダウンしているアプリケーションは、99%の可用性があります。
信頼性とは、システムやアプリケーションが一定期間にわたって、エラーなく、期待通りにサービスを提供する能力のことです。動作が遅かったり、予期せず不正な結果が出たりする場合、アプリケーションは利用はできますが、信頼性が低いといえます。先ほどの例に戻ると、利用できない店舗は閉じられます。店舗が開いてはいても、信頼性が低い場合、本棚の間違った場所に商品が置かれているかもしれません。
アプリケーションの可用性の測定値は、多くの場合、過去1年間を通じて計算されます。この表は、さまざまな可用性のレベルを持つアプリケーションが、365日の期間のうちにどれだけのダウンタイムを発生させるかを示しています。(ダウンタイムは蓄積され、複数の異なる期間にわたって発生することもあれば、一度に発生することもあります)。
可用性 | 年間の総ダウンタイム |
---|---|
95% | 18日と6時間 |
99% | 3日、15時間、36分 |
99.9% | 8時間、45分、36秒 |
99.99% | 52分と34秒 |
99.999%(「99%」) | 5分と15秒 |
アップタイムとは、アプリケーションが期待通りに実行されている状態を指します。ダウンタイムとは、デバイスやサービスが動作していない状態のことです。多くの文脈では、稼働時間と可用性は同義です。
インターネットは複雑で、さまざまな要因がWebアプリケーションの可用性とパフォーマンスに影響します。アプリケーション開発者が制御できる要因もあれば、そうでないものもあります。しかし、可用性に影響を与える要因を考慮し、軽減するために開発者が講じることのできる対策はいくつかあります。
高可用性は、バックアップと単一障害点を回避することで実現される、エリートレベルの一貫した可用性です。高可用性アーキテクチャでは、1つのサーバーやゲートウェイ、サービスがダウンしても、利用できなくなることはありません。高可用性アーキテクチャは、サイバー攻撃も防止する必要があります。
負荷分散は、計算負荷とネットワークトラフィックをサーバーグループ全体に均等に分散させます。これにより、1つのサーバーやサーバーグループが、効率的に処理できる量を超えるトラフィックに圧倒されることはありません。
負荷分散アルゴリズムには様々なものがあります。どんな状況であれワークロードを均等に分散するロードバランサーもあれば、動的アルゴリズムを用いてリアルタイムのネットワーク状態やサーバーの状態に対応するものもあります。
Webサーバーは必然的に時折ダウンします。ヘルスチェックは、配信元サーバーがオンラインであるかどうかを監視するサービスです。ヘルスチェックにより、ロードバランサーがサーバーのステータスに応答し、オフラインになったサーバーにリクエストが送信されないようになります。
高可用性アプリケーションは、そのアーキテクチャに冗長性を組み込んでいます。このようなアプリケーションは、ランサムウェア攻撃を受けた場合やその他の理由でデータベースが利用できなくなった場合に、アプリケーションのデータのバックアップコピーに戻すことができます。冗長なサービスとサーバープールにより、サーバーや API のクラッシュがアプリケーションの機能への影響を防止します。
Webアプリケーションの静的要素は、基盤となるインフラがクラッシュした場合でも、コンテンツ配信ネットワーク(CDN)で提供できます。Webアプリケーションのキャッシュされたバージョンはすべての機能を備えていない可能性がありますが、完全なサービスが復旧するまで技術的には利用可能です。(CloudflareのAlways Onlineサービスの詳細をご覧ください。)
Domain Name System(DNS)は、ユーザーがネットワーク経由でアプリケーションサーバーに到達するためのものです。DNSがダウンしたり、適切なIPアドレスを見つけることができなくなった場合、ユーザーはアプリケーションを読み込むことができません。グローバルなリーチを持ち、DNSに焦点を当てたDDoS攻撃を阻止する能力を備えた、信頼性の高いDNSプロバイダーを使用することで、DNSが可用性に影響を与えないことが保証されます。
外部のアプリケーションの可用性監視ツールを使用することで、サービスプロバイダーは可用性を追跡し、アプリケーションのダウン時にできるだけ迅速に対応することができます。
継続的可用性とは、アプリケーションやシステムが継続的に運用可能であることを保証するコンピューティングインフラ設計のアプローチのことです。継続的可用性の目標値は100%ですが、現実的に不可能かもしれません。インターネットは、核戦争に耐え得るように設計されましたが、それでもユーザーのインターネットサービスはダウンすることがあります。それでも、継続的な可用性は、ユーザーに可能な限り最高のサービスを提供するのに役立つ目標と言えます。
アプリケーションの可用性が高いほど、サポートに費やす必要のあるリソースも増えます。つまり、99.999%の可用性は高額となるということです。開発者は、自社または顧客が許容するダウンタイムの量を判断し、それに応じて構築する必要があります。
幸い、Cloudflareは、アプリケーション開発者にとって高可用性アーキテクチャをはるかに実現しやすいものにしています。Cloudflareのサービスは、負荷分散、キャッシング、Stream配信、DDoS攻撃緩和、ボット管理がネイティブに組み込まれています。Cloudflareはさらに、新機能やまったく新しいアプリケーションを構築するための開発者向けプラットフォームを、世界330都市に展開するグローバルネットワーク全体で実行できるようにしています。
Cloudflareがアプリケーションの可用性を維持する仕組みをご紹介します。
利用開始
パフォーマンスについて
パフォーマンスとSEO
パフォーマンスの詳細
用語集
ラーニングセンターナビゲーション