Webアプリケーションの100％アップタイム

今日、クライアントから興味深い「要件」を受け取りました。

Webアプリケーションのオフサイトフェールオーバーで100％の稼働時間を望んでいます。Webアプリケーションの観点からは、これは問題ではありません。複数のデータベースサーバーなどでスケールアウトできるように設計されました。

しかし、ネットワークの問題から、それを機能させる方法がわからないようです。

簡単に言うと、アプリケーションはクライアントのネットワーク内のサーバー上に存在します。内部および外部の両方の人がアクセスします。彼らは私たちにシステムのオフサイトコピーを維持してほしいと思っています。それは彼らの施設で重大な障害が発生した場合にすぐに取り上げて引き継ぐでしょう。

現在、社内の人々（伝書鳩？）に対してそれを解決する方法はまったくありませんが、外部のユーザーに気付かないようにしたいと考えています。

率直に言って、私はこれがどのように可能性があるのか​​について、最も霧のかかった考えを持っていません。インターネット接続が失われた場合、外部のマシンにトラフィックを転送するためにDNSの変更を行う必要があるようです...もちろん、時間がかかります。

アイデア？

更新

今日、私はクライアントと話し合い、その問題について明確にしました。

彼らは100％の数字で立ち往生し、洪水の場合でもアプリケーションはアクティブなままでなければならないと言いました。ただし、その要件は、それらをホストする場合にのみ有効です。彼らは、アプリケーションが完全にサーバー上にある場合、稼働時間の要件を処理すると述べました。私の反応を推測できます。

以下は、ウィキペディアのナインの追跡に関する便利なチャートです。

興味深いことに、上位20のWebサイトのうち3つだけが、2007年に神話上の5ナインまたは99.999％の稼働率を達成できました。それらはYahoo、AOL、Comcastでした。2008年の最初の4か月間、最も人気のあるソーシャルネットワークの一部は、それに近づきさえしませんでした。

グラフから、アップタイム100％の追求がどれほどばかげているのかが明らかであるはずです...

100％を定義するように依頼し、どの期間でどのように測定されるかを尋ねます。彼らはおそらく、余裕がある限り100％に近いことを意味します。それらに原価計算を与えます。

詳しく説明します。私は長年にわたって、おそらくばかげた要求でクライアントと議論してきました。すべての場合において、彼らは実際には、正確でない十分な言語を使用していました。

多くの場合、100％のような絶対的な方法で物事を組み立てますが、実際には、より詳細な調査では、リスク軽減データにコスト計算を提示するときに必要なコスト/利益分析を実行するのに十分合理的です。可用性をどのように測定するかを尋ねることは重要な問題です。彼らがこれを知らないなら、あなたは彼らにこれを最初に定義する必要があることを彼らに提案しなければならない立場にいます。

次のような状況でサイトがダウンした場合、ビジネスへの影響/コストに関して何が起こるかをクライアントに定義してもらいます。

• 忙しい時間にx時間
• 少なくとも忙しい時間にx時間

また、これをどのように測定するか。

この方法で、あなたは彼らと協力して「100％」の正しいレベルを決定することができます。これらの種類の質問をすることで、他の要件の優先順位をより適切に判断できると思います。たとえば、特定のレベルのSLAを支払い、これを達成するために他の機能を妥協したい場合があります。

あなたのクライアントは夢中です。100％のアップタイムは、いくらお金を使っても不可能です。プレーンでシンプル-不可能。グーグル、アマゾンなどを見てください。彼らはインフラに投じるお金がほぼ無限にありますが、それでもダウンタイムを抱えています。あなたはそのメッセージを彼らに届ける必要があり、彼らが合理的な要求を提供することを主張し続けるなら。ある程度のダウンタイムが避けられないことを彼らが認識しない場合、それらを捨てます。

そうは言っても、アプリケーション自体をスケーリング/分散するメカニズムを持っているようです。ネットワーキング部分は、異なるISPへの冗長アップリンクを必要とし、ASNとIP割り当てを取得し、必要に応じてIPアドレス空間がISP間を移動できるように、BGPと実際のルーティングギアを深く掘り下げる必要があります。

これは、明らかに、非常に簡潔な答えです。この程度の稼働時間を必要とするアプリケーションの経験はないため、神話上の100％の稼働時間に近い場所を取得したい場合は、専門家を関与させる必要があります。

まあ、それは間違いなく面白いものです。契約上100％の稼働時間を義務付けられるかどうかはわかりませんが、もし必要なら、次のようになります。

ネットワークから完全にロードバランサーのパブリックIPで開始し、少なくとも2つを構築して、一方が他方にフェールオーバーできるようにします。Heatbeartのようなプログラムは、それらの自動フェールオーバーを支援できます。

Varnishは主にキャッシュソリューションとして知られていますが、非常に適切な負荷分散も行います。おそらく、それは負荷分散を処理するための良い選択でしょう。1〜n個のバックエンドをオプションでディレクターにグループ化して、ランダムまたはラウンドロビンのいずれかで負荷分散するように設定できます。Varnishは、すべてのバックエンドの状態をチェックし、異常なバックエンドをオンラインに戻るまでループから除外するのに十分なほどスマートにできます。バックエンドは同じネットワーク上にある必要はありません。

私は最近Amazon EC2のElastic IPが大好きなので、おそらく異なる地域または少なくとも同じ地域の異なる可用性ゾーンにEC2でロードバランサーを構築します。これにより、既存のAレコードIPを新しいボックスに移動する必要がある場合に、新しいロードバランサーを手動で起動することができます。

ただし、ニスはSSLを終了できません。そのため、懸念がある場合は、代わりにNginxのようなものを調べてください。

クライアントネットワークにほとんどのバックエンドを配置し、ネットワークの外部に1つ以上配置することができます。クライアントマシンがすべて正常でなくなるまでクライアントマシンが優先されるように、バックエンドに優先順位を付けることができると確信していますが、100％確信はありません。

このタスクがあった場合、そこから始めて、間違いなく作業を進めながら改善します。

ただし、@ ErikAが述べているように、それはインターネットであり、ネットワークの一部は常に制御不能になります。あなたの法的はあなたのコントロール下にあるものとあなただけを結びつけることを確認したいと思うでしょう。

問題ありませんが、契約文言をわずかに改訂しました：

... 100％の稼働時間を保証します（小数点以下ゼロ位に丸められます）。

FacebookとAmazonができない場合、できません。それはそれと同じくらい簡単です。

Hacker Newsからoconnoreの回答を追加するには

私は問題が何であるか理解していません。クライアントは、あなたが災害に備えて計画することを望んでおり、彼らは数学指向ではないので、100％の確率を求めることは理にかなっています。エンジニアは、エンジニアが行う傾向があるため、prob＆stat 101の最初の日を思い出しましたが、クライアントがそうでないことを考慮していませんでした。彼らがこれを言うとき、彼らは核の冬について考えていない、彼らはフレッドがオフィスサーバーに彼のコーヒーを捨てる、ディスクがクラッシュする、またはISPがダウンすることを考えている。さらに、これを実現できます。地理的に独立した独立した自己監視サーバーを使用すると、基本的にダウンタイムは発生しません。3台のサーバーが独立した（1）3 9信頼性で動作し、適切なフェールオーバーモードを備えているため、予想されるダウンタイムは1年あたり1秒未満です（2）。これが一度に起こっても、あなたはまだウェブ接続のための合理的なSLAの範囲内にあり、したがってダウンタイムは事実上存在しません。クライアントはまだ終末シナリオに対処する必要がありますが、ゴジラは除外し、彼は「常に」サービスを提供します。

（1）LAのサーバーはボストンのサーバーから合理的に独立していますが、はい、核戦争、中国のハッカーが送電網をクラッシュするなどの交差点があることを理解しています。クライアントが動揺することはないと思いますこの。

（2）DNSフェイルオーバーにより数秒かかる場合があります。あなたはまだクライアントが年に一度リクエストを再試行しなければならないシナリオにいます。これはまた、合理的なSLAの範囲内であり、通常「ダウンタイム」と同じ流れではありません。障害時に利用可能なノードに自動的に再ルーティングするアプリケーションでは、これは目立たないことがあります。

不可能なことを求められています。

ここで他の回答を確認し、クライアントと一緒に座って、なぜそれが不可能なのかを説明し、その応答を測定します。

それでも100％のアップタイムを要求する場合は、それができないことを丁寧に伝え、契約を拒否します。あなたは彼らの要求に応えることは決してありませんし、契約が完全に下手でなければ、ペナルティで串刺しになります。

それに応じて価格を設定し、SLAを超えたダウンタイムはすべて、支払ったレートで返金されることを契約で規定します。

私の最後の仕事でISPがそれをしました。毎月40ドルで99.9％の稼働率の「通常の」DSL回線、または毎月1100ドルで99.99％の稼働率のT1の結合トリオを選択しました。1か月あたり10時間以上の停止が頻繁に発生したため、アップタイムはDSLの40ドル/月を大きく下回りましたが、1時間あたりの料金*時間であるため、約15ドル程度しか返金されませんでした。彼らは契約から盗賊のようになった。

100％の稼働率で月額450,000ドルを請求し、99.999％にしか達していない場合、324ドルを返金する必要があります。99.999％を達成するためのインフラストラクチャコストは、完全に分散したコロス、複数のティア1アップリンク、ファンシーパンツハードウェアなどを想定して、1か月あたり45,000ドル程度であると確信しています。

99.999％の可用性が実際的または経済的に実行可能な可能性であるかどうか専門家が疑問を呈した場合、99.9999％の可用性はさらに低い可能性または実用的です。もちろん、100％。

長期間にわたって100％の可用性の目標を達成することはできません。1週間または1年間それで逃げることができますが、それから何かが起こり、責任を負うことになります。アウトプットは、評判の低下（約束したが、配達しなかった）から契約上の罰金による破産にまで及ぶことがあります。

100％の稼働時間を要求する人々には2つのタイプがあります。

1. コンピューター、コンピューターシステム、またはインターネットについてまったく知識がない人。*
2. ノーと言う能力をテストするため（Googleの「オレンジジューステスト」）、または後で支払いから抜け出すために何らかのSLAレバレッジを獲得しようとするために、意図的に自分自身の尻を作っている人。

私のアドバイスは、多くの場合これらのタイプのクライアントの両方に苦しんだので、このクライアントを受け入れないことです。彼らに他の誰かを狂気にさせます。

*この同じ人は、超高速旅行、パーペチュアルモーション、常温核融合などについて恥ずかしがらないかもしれません。

クライアントと通信して、100％の稼働率が何を意味するかをクライアントと確立します。99％の稼働率と100％の稼働率を実際に区別していない可能性があります。ほとんどの人々（つまり、サーバー管理者ではない）にとって、これらの2つの数字は同じです。

100％の稼働時間？

必要なものは次のとおりです。

複数の（および冗長な）DNSサーバー。世界中の複数のサイトを指し、各ISPとの適切なSLAを備えています。

TTLが効果的に認識されるように、DNSサーバーが適切にセットアップされていることを確認してください。

これは簡単です。Amazon EC2 SLAには次のように明記されています。

「年間稼働率」は、Amazon EC2が「Region Unavailable」の状態にあったサービスイヤー中の5分間の割合を100％から差し引くことで計算されます。

http://aws.amazon.com/ec2-sla/

'uptime'をサービスバンドル全体に関連するように定義するだけで、100％の時間を実際に運用し続けることができ、問題はないはずです。

また、SLAの重要なポイントは、義務が何であり、それを満たせなかった場合にどうなるかを定義することです。クライアントが3ナイン、5ナイン、100万ナインのいずれを要求するかは問題ではありません。問題は、配信できない場合/配信できない場合です。明白な答えは、請求したい価格の5倍で100％の稼働時間の広告申込情報を提供し、その目標を見逃した場合、4倍の払い戻しを受けることです。得点するかもしれません！

DNSの変更は、時間がかかるように構成されている場合にのみ時間がかかります。レコードのTTLを1秒に設定できます。唯一の問題は、DNSクエリにタイムリーな応答を提供し、DNSサーバーがそのレベルのクエリに対応できるようにすることです。

これは、G5がF5ビッグIPでどのように機能するかとまったく同じです。DNSTTLはデフォルトで30秒に設定されており、クラスターの1つのメンバーが引き継ぐ必要がある場合、DNSが更新され、新しいIPがすぐに引き継がれます。最大30秒の停止がありますが、これはエッジケースであり、平均は15秒です。

あなたはこれが不可能であることを知っています。

間違いなくクライアントは「100％」を見ることに集中しているので、あなたができる最善のことは100％を約束することです。

100％は可能だとは思いませんが、可能性としてAzure（または同様のSLAを備えた何か）を検討することをお勧めします。何が起こっている：

サーバーは仮想マシンです。1つのサーバーでハードウェアの問題が発生した場合、仮想マシンは新しいマシンに移動されます。ロードバランサーがリダイレクトを処理するため、ダウンタイムは発生しません（ただし、セッションの状態がどのように影響を受けるかはわかりません）。

とはいえ、このフェイルオーバーでも、99.999と100の狂気の境界線との差はあります。

次の要素を完全に制御する必要があります。
-内的および外的な人的要因、悪意およびインポテンスの両方。この例は、サーバーをダウンさせる本番コードに何かをプッシュする人です。さらに悪いことに、妨害行為はどうですか？
-ビジネス上の問題。プロバイダーが業務を停止したり、電気料金の支払いを忘れたり、十分な警告なしにインフラストラクチャのサポートを停止したりするとどうなりますか？
-自然。無関係な竜巻が同時にバックアップ容量を圧倒するのに十分なデータセンターにヒットしたらどうなるでしょうか？
-完全にバグのない環境。サードパーティまたはコアシステムのコントロールには、それ自体は明示されていないが将来もそうなる可能性のあるエッジケースはないと確信していますか？
-上記の要因を完全に制御できたとしても、システムを起動しているかどうかを確認する際に、これを監視するソフトウェア/人が誤検知を起こさないと確信していますか？

正直なところ、ハッキング攻撃に関して少なくとも揺らぐことなく、100％は完全に狂っています。最善の策は、地理的に分散したホスティングソリューションを使用して、GoogleとAmazonが行うことを実行することです。このソリューションでは、サイトとDBが複数の地理的な場所にある複数のサーバーに複製されます。これにより、インターネットのバックボーンが地域に切断される（時々起こる）または終末論的な何かなどの大災害以外の何でも保証されます。

そのような場合（DDOS、インターネットバックボーンの切断、終末論的なテロ攻撃、または大規模な戦争など）にのみ条項を付けます。

それ以外は、Amazon S3またはRackspaceクラウドサービスを調べます。基本的に、クラウドのセットアップは、各場所の冗長性を提供するだけでなく、障害のある地理的領域をリダイレクトする機能とともに、トラフィックのスケーラビリティと地理的分布も提供します。私の理解では、地理的分布にはもっとお金がかかるということです。

「理論的には」できるパーティーに別の声を加えたかっただけです。

私は彼らがいくら払ってもこれを指定した契約を引き受けるつもりはありませんが、研究の問題として、いくつかのかなり興味深い解決策があります。手順の概要を説明するためにネットワークに精通していませんが、ネットワーク関連の構成+電気/ハードウェアワイヤリングフェイルオーバー+ソフトウェアフェイルオーバーの組み合わせは、おそらく、何らかの構成または他の作業で実際にそれを実行することを想像します。

ほとんどの場合、構成のどこかに単一障害点がありますが、十分な努力をすれば、その障害点を「ライブ」で修復できるものにプッシュできます（つまり、ルートDNSがダウンしますが、値はキャッシュされます）他のすべての場所で修正する時間があります）。

繰り返しますが、それが実現可能であるとは言いません。単一の答えが、「そこから抜け出す」ことではないという事実に対処する方法が好きではありませんでした。

可用性を測定する方法論を再考し、顧客と協力して有意義な目標を設定します。

大規模なWebサイトを運営している場合、稼働時間はまったく役に立ちません。顧客が最も必要としている（トラフィックのピーク）ときにクエリを10分間中断すると、日曜日の午前3時に1時間停止するよりもビジネスに損害を与える可能性があります。

大規模なWeb企業では、次の指標を使用して可用性または信頼性を測定する場合があります。

1. サーバー側エラー（HTTP 500）なしで正常に回答されたクエリの割合。
2. 特定のターゲット遅延以下で回答されたクエリの割合。
3. ドロップされたクエリは、統計情報にカウントされます（以下を参照）。

可用性は、PingdomやPingabilityなどの外部エンティティが報告できるサンプルプローブを使用して測定しないでください。それだけに頼らないでください。正しく実行したい場合は、すべてのクエリをカウントする必要があります。認知された実際の成功を確認して、可用性を測定します。

最も効率的な方法は、ロードバランサーからログまたは統計を収集し、上記のメトリックに基づいて可用性を計算することです。

割合落としクエリはまた、あなたの統計に対してカウントすべきです。サーバー側のエラーと同じバケットで説明できます。ネットワークまたはDNSやロードバランサーなどの別のインフラストラクチャに問題がある場合は、単純な計算を使用して、失われたクエリの数を推定できます。その曜日のXクエリを期待しているのにX-1000を取得した場合、おそらく1000クエリを削除しました。トラフィックを1分あたりのクエリ（または秒）グラフにプロットします。ギャップが表示される場合、クエリを削除しました。基本的なジオメトリを使用して、これらのギャップの面積を測定します。これにより、ドロップされたクエリの総数がわかります。

この方法論を顧客と話し合い、その利点を説明してください。現在の可用性を測定してベースラインを設定します。彼らにとって、100％は不可能な目標であることが明らかになるでしょう。

その後、ベースラインの改善に基づいて契約に署名できます。彼らは現在入手の95％を経験している場合は、あなたが状況改善を約束することができ、言う10倍に 98.5％まで取得すること。

注：可用性を測定するこの方法には欠点があります。まず、既存のツールを使用してログを収集しない限り、ログの収集、レポートの処理および生成は簡単ではありません。第二に、アプリケーションのバグが可用性を損なう可能性があります。アプリケーションの品質が低い場合、エラーが多くなります。これに対する解決策は、アプリケーションからのものではなく、ロードバランサーによって作成された500のみを考慮することです。

この方法は少し複雑になるかもしれませんが、サーバーの稼働時間だけを測定する以上の一歩です。

一部の人々は100％であることを、ここで注意しながら、非常識または不可能な、彼らは何とか本当のポイントを逃しました。彼らは、この理由は最高の企業/サービスでさえそれを達成できないという事実であると主張しました。

まあ、それはそれよりずっと簡単です。それはだ数学的に不可能。

すべてに確率があります。サーバーを保管しているすべての場所で同時に地震が発生し、それらすべてが破壊される可能性があります。当然ながら、これはとてつもなく小さな確率ですが、0ではありません。すべてのインターネットプロバイダーが同時のテロリスト/サイバー攻撃に直面する可能性があります。繰り返しますが、あまり可能性はありませんが、ゼロでもありません。提供するものは何でも、サービス全体をダウンさせる非ゼロの確率シナリオを得ることができます。そのため、稼働時間を100％にすることはできません。

統計的サンプリングを使用した製造品質管理に関する本を入手してください。この本の一般的な議論は、大学の一般的な統計コースでマネージャーがさらされる概念であり、1000分の1の抜粋から1万分の1から100万分の1までのコストを決定します。 10億人に1人が指数関数的に上昇しています。基本的に、100％の稼働時間を達成する能力は、オブジェクトを光の速度に押し上げるのに必要な燃料の量のような、ほぼ無制限の量の資金を必要とします。

パフォーマンスエンジニアリングの観点から、この表現は真の要件というよりも欲望であるという、テスト不可能かつ不合理な要件であるという要件を拒否します。ネットワーキング、名前解決、ルーティング、基盤となるアーキテクチャコンポーネントまたは開発ツールから生じた欠陥など、アプリケーションの外部に存在するアプリケーションの依存関係により、100％のアップタイムを保証することは実際上不可能になります。

顧客が実際に100％の稼働時間、または99.999％の稼働時間を要求しているとは思わない。彼らが何を説明しているのかを見ると、彼らは流星がオンサイトのデータセンターを取り出した場合に中断した場所を取り上げることについて話している。

要件が外部の人々でさえ気付かない場合、それはどれほど抜本的でなければなりませんか？Ajaxリクエストを再試行して、エンドユーザーに30秒間スピナーを表示しても問題ありませんか？

これらは、顧客が気にする種類のものです。顧客が正確なSLAを実際に考えている場合、99.99または99.999として表現するのに十分な知識があります。

私の2セント。スーパーボウルの広告を出すフォーチュン5企業の非常に人気のあるWebサイトを担当しました。トラフィックの急増に対処する必要があり、それを解決する方法はアカマイのようなサービスを使用することでした。私はアカマイで働いていませんが、彼らのサービスは非常に優れていると感じました。特定のノード/ホストが高負荷であるかダウンしていることを認識し、トラフィックを適切にルーティングできる独自のスマートなDNSシステムを持っています。

彼らのサービスのすてきなところは、自分のデータセンターのサーバー上のコンテンツをデータセンターに複製するために、非常に複雑なことをする必要がまったくなかったことです。さらに、私は彼らと協力して、Apache HTTPサーバーを多用したことを知っています。

100％の稼働時間ではありませんが、コンテンツを世界中に分散させるためのこのようなオプションを検討することができます。私が物事を理解したように、アカマイには、ミシガン州にいる場合、ミシガン州/シカゴのサーバーからコンテンツを取得し、カリフォルニアにいる場合、おそらくカリフォルニアに拠点を置くサーバーからコンテンツを取得した場合、トラフィックの意味をローカライズする機能もありました。

オフサイトフェールオーバーの代わりに、内部と外部の2つの場所から同時にアプリケーションを実行するだけです。そして、2つのデータベースを同期します...そして、内部がダウンしても、内部の人は引き続き作業でき、外部の人はアプリケーションを使用できます。内部がオンラインに戻ったら、変更を同期します。1つのドメイン名に対して2つのDNSエントリ、またはラウンドロビン付きのネットワークルーターを使用できます。

外部でホストされているサイトの場合、100％の稼働率に最も近いのは、GoogleのApp Engineでサイトをホストし、リアルタイムで少なくとも3つのデータセンターにデータを自動的に複製する高レプリケーションデータストア（HRD）を使用することです。同様に、App Engineフロントエンドサーバーは自動的にスケーリング/複製されます。

ただし、Googleのすべてのリソースと世界で最も洗練されたプラットフォームでさえ、App Engine SLAの稼働時間の保証は「暦月の99.95％の時間」にすぎません。

シンプルで直接：エニーキャスト

http://en.wikipedia.org/wiki/Anycast

これは、cloudflare、google、およびその他の大企業が、冗長で低遅延の大陸間フェール​​オーバー/バランシングを行うために使用するものです。

ただし、100％の稼働時間を確保することは不可能であり、99.999％から99.9999％に移行するためのコストははるかに大きいことにも留意してください。