Webアプリケーションの100％の稼働時間
今日、クライアントから興味深い「要件」を受け取りました。
Webアプリケーションでoff-siteフェイルオーバーを使用して100％の稼働時間を求めています。 Webアプリケーションの観点からは、これは問題ではありません。複数のデータベースサーバー間でスケールアウトできるように設計されています。
しかし、ネットワーキングの問題から、それを機能させる方法を理解できないようです。
簡単に言うと、アプリケーションはクライアントのネットワーク内のサーバー上に存在します。内部と外部の両方の人々がアクセスします。彼らは、敷地内で重大な障害が発生した場合に即座に取り上げて引き継ぐシステムのオフサイトコピーを維持することを望んでいます。
これで、内部の人々（保因者の鳩？）に対してそれを解決する方法は絶対にないことがわかりましたが、外部のユーザーに気付かれることさえ望まないのです。
率直に言って、私はこれがどのようにして可能になるのかについての最も曖昧な考えを持っていません。インターネット接続が失われると、外部マシンにトラフィックを転送するためにDNSを変更する必要があるようです...もちろん、これには時間がかかります。
アイデア？
[〜＃〜]更新[〜＃〜]
今日、私はクライアントと話し合いをしました、そして彼らは問題について明らかにしました。
彼らは100％の数値で立ち往生し、洪水が発生した場合でもアプリケーションはアクティブなままである必要があると述べました。ただし、その要件は、ホストする場合にのみ有効になります。彼らは、アプリケーションが完全にサーバー上にある場合、稼働時間の要件を処理すると述べた。私の反応を推測できます。
こちらが Wikipedia のナインの追跡の便利なチャートです。
興味深いことに、2007年に 上位20のWebサイトのうち3つ だけが神秘的なファイブナインまたは99.999％のアップタイムを達成できました。それらはYahoo、AOL、およびComcastでした。 2008年の最初の4か月で、ほとんどの 人気のソーシャルネットワーク のいくつかはそれに近づくことすらありませんでした。
グラフから、稼働時間100％の追求がいかにばかげているかは明らかです...
100％を定義し、それをどのように測定するかを顧客に尋ねます。彼らはおそらく彼らが余裕がある限り100％に近いことを意味します。それらに原価計算を与えなさい。
詳しく説明します。私は長年にわたって、おそらくばかばかしい要件でクライアントと話し合ってきました。すべての場合において、彼らは実際には正確ではない十分な言語を使用していました。
多くの場合、それらは100％のように絶対的に見える方法で物事を組み立てますが、実際にはより詳細な調査では、リスク軽減データへのコストを提示するときに必要なコスト/利益分析を行うのに十分妥当です。彼らが可用性をどのように測定するかを彼らに尋ねることは重要な質問です。彼らがこれを知らない場合、あなたはこれを最初に定義する必要があることを彼らに提案しなければならない立場にいます。
次の状況でサイトがダウンした場合、ビジネスへの影響/コストに関して何が起こるかをクライアントに定義してもらいます。
- 最繁時のx時間
- X時間の最繁忙時間
そして、彼らがこれをどのように測定するかについても。
このようにして、彼らと協力して「100％」の適切なレベルを決定できます。このような質問をすることで、他の要件の優先順位をより適切に決定できると思います。たとえば、特定のレベルのSLAを支払い、これを実現するために他の機能を危険にさらしたい場合があります。
あなたのクライアントは狂っています。 100％の稼働率は不可能どんなにお金をかけても関係ありません。プレーンでシンプル-不可能。グーグル、アマゾンなどを見てください。彼らは彼らのインフラストラクチャに投入するためにほとんど無限の金額を持っていますが、それでも彼らはダウンタイムをどうにかして管理しています。あなたは彼らにそのメッセージを届ける必要があり、彼らが合理的な要求を提供することを彼らが主張し続けるなら。彼らがsomeダウンタイムの量が避けられないことを認識しない場合、それらを捨てます。
とはいえ、あなたはアプリケーション自体をスケーリング/配布する仕組みを持っているようです。ネットワーキング部分には、異なるISPへの冗長アップリンク、ASNとIPの割り当て、および必要に応じてISP間でIPアドレス空間を移動できるように、BGPと実際のルーティングギアに深く関与する必要があります。
これは非常に簡潔な答えです。この程度の稼働時間を必要とするアプリケーションの経験はありません。したがって、神秘的な100％の稼働時間に近い場所に到達したい場合は、専門家を関与させる必要があります。
まあ、それは間違いなく興味深いものです。契約上100％のアップタイムを義務付けられるかどうかはわかりませんが、必要な場合は次のようになると思います。
ロードバランサーのパブリックIPをネットワークから完全に切り離し、少なくとも2つを構築して、一方が他方にフェイルオーバーできるようにします。 Heatbeartのようなプログラムは、それらの自動フェイルオーバーに役立ちます。
Varnishは主にキャッシングソリューションとして知られていますが、非常に適切なロードバランシングも行います。おそらく、それはロードバランシングを処理するための良い選択でしょう。 1からnのバックエンドをオプションでディレクターにグループ化するように設定でき、ランダムまたはラウンドロビンのいずれかで負荷分散します。 Varnishは、すべてのバックエンドの正常性をチェックし、正常でないバックエンドをオンラインに戻るまでループから外すのに十分なほどスマートにすることができます。バックエンドは同じネットワーク上にある必要はありません。
私は最近、Amazon EC2のElastic IPに恋をしているので、EC2のロードバランサーを異なるリージョンまたは少なくとも同じリージョンの異なるアベイラビリティーゾーンに構築するでしょう。これにより、既存のAレコードIPを新しいボックスに移動する必要がある場合に、新しいロードバランサーを手動で（禁止）スピンアップするオプションが提供されます。
ただし、VarnishはSSLを終了できません。そのため、それが問題になる場合は、代わりにNginxなどを確認することをお勧めします。
ほとんどのバックエンドをクライアントネットワークに配置し、1つ以上をクライアントネットワークの外部に配置できます。 100％確実ではありませんが、バックエンドに優先順位を付けて、クライアントマシンがすべて異常状態になるまでクライアントマシンが優先されるようになると思います。
これが私がこのタスクを持っていて、私が進むにつれて間違いなくそれを洗練するなら、私が始めるところです。
ただし、@ ErikAが述べているように、これはインターネットであり、常にネットワークの一部がユーザーの制御外にあります。あなたの法律があなたの管理下にあるものとあなただけを結びつけることを確実にしたいでしょう。
問題ありません-契約の文言を少し修正しました：
... 100％の稼働時間を保証します（小数点以下ゼロに丸められます）。
FacebookとAmazonでそれができない場合は、できません。それはそれと同じくらい簡単です。
追加するには oconnore's answer Hacker Newsから
問題が何なのかわかりません。クライアントはあなたに災害の計画を立ててほしいと望んでいます、そして彼らは数学志向ではないので、100％の確率を求めることは合理的に聞こえます。エンジニアは、エンジニアがそうする傾向があるので、クライアントがそうでないかもしれないことを考慮せずに、prob＆stat 101の最初の日を思い出しました。彼らがこれを言うとき、彼らは核の冬について考えていません、彼らはフレッドがオフィスサーバーに彼のコーヒーを捨てるか、ディスクがクラッシュするか、またはISPがダウンすることを考えています。さらに、これを実現できます。地理的に区別された独立した自己監視サーバーがあれば、基本的にダウンタイムは発生しません。独立した（1）3つの9信頼性で動作する3台のサーバーと良好なフェイルオーバーモードにより、予想されるダウンタイムは1年あたり1秒未満です（2）。これが一度に発生しても、Web接続ではSLAの範囲内であるため、実際にはダウンタイムは発生しません。クライアントは終末のシナリオに対処する必要がありますが、ゴジラは除外されています、彼は「常に」稼働しているサービスを持っています。
（1）LAのサーバーはボストンのサーバーからかなり独立していますが、そうです、核戦争、中国のハッカーが送電網をクラッシュさせるなど、いくつかの交差点があることを理解しています。クライアントは、この。
（2）DNSフェイルオーバーにより、数秒かかる場合があります。クライアントは1年に1回リクエストを再試行する必要があるシナリオにまだあります。これも、妥当なSLAの範囲内であり、通常は「ダウンタイム」と同じレベルでは考慮されません。障害時に利用可能なノードに自動的に再ルーティングするアプリケーションでは、これは気付かない場合があります。
あなたは何か不可能なことを求められています。
ここで他の回答を確認し、クライアントと一緒に座り、説明します[〜＃〜]理由[〜＃〜]不可能であり、それらの応答を測定します。
それでも100％の稼働率を要求する場合は、実行できないことを丁寧に伝え、契約を拒否します。あなたは彼らの要求を決して満たすことはありません、そして契約が完全にうまくいかなければあなたはペナルティで串刺しにされます。
価格に応じて、SLAを過ぎたダウンタイムは支払ったレートで返金されることを契約に明記します。
私の最後の仕事のISPはそれをしました。稼働率99.9％で月額40ドルの「通常の」DSL回線、または稼働率99.99％でT1の結合トリオを月額$ 1100 /で選択することができました。月に10時間以上の頻繁な停止があり、稼働時間は月額$ 40 DSLをはるかに下回っていましたが、払い戻しされたのは約$ 15時間程度でした。彼らは契約から盗賊のようになりました。
100％の稼働時間に対して月額$ 450,000を請求し、99.999％に達した場合、$ 324を払い戻す必要があります。完全に分散したコロス、複数のティア1アップリンク、ファンシーパンツハードウェアなどを想定すると、99.999％に達するインフラストラクチャコストは月額45,000ドル程度です。
100％の稼働率を求める人には2つのタイプがあります。
- コンピューター、コンピューターシステム、またはインターネットについてまったく知識がない人。*
- 意図的にお尻を作っている人、いいえと言う能力をテストする（Google "オレンジジューステスト"）、または何らかの契約を得ようとしているSLA後であなたを支払うことから抜け出しなさい。
私のアドバイスは、多くの場合これらのタイプのクライアントの両方に苦しんでいるので、このクライアントを受け入れないことです。彼らが他の誰かを狂気に追い込ませる。
*同じ人物でも、光速よりも速い旅行、永久運動、常温核融合などについて、恥ずかしくない質問があるかもしれません。
専門家が 99.999％の可用性は[実用的または経済的に実行可能な可能性]であるか であるかどうか疑問に思う場合、99.9999％の可用性はさらに可能性が低く、実用的ではありません。 100％はもちろんです。
長期間、100％の可用性の目標を達成することはできません。あなたは一週間または一年間それを逃れるかもしれませんが、それから何かが起こり、あなたは責任を負います。アウトフォールは、評判の低下（約束した、配達しなかった）から契約上の罰金による破産までさまざまです。
私はクライアントと連絡を取り、100％の稼働率とは何を意味するのかをクライアントと確立します。 99％の稼働率と100％の稼働率の違いを実際に認識していない可能性があります。ほとんどの人（つまり、サーバー管理者ではない）にとって、これら2つの数値は同じです。
100％の稼働率？
必要なものは次のとおりです。
複数の（冗長な）DNSサーバー。世界中の複数のサイトを指し、各ISPと適切なSLAを備えています。
TTLが効果的に認識され、DNSサーバーが正しくセットアップされていることを確認してください。
これは簡単。 Amazon EC2 SLAは明確に述べています：
「年間稼働率」は、Amazon EC2が「リージョン利用不可」の状態であったサービス年度中の5分間の割合を100％から差し引いて計算されます。
http://aws.Amazon.com/ec2-sla/
「uptime」をサービスバンドル全体に関連するように定義するだけで、実際に100％の時間稼働を維持でき、問題は発生しません。
また、SLAの全体的なポイントは、あなたの義務が何であるか、そしてあなたがそれらを満たせない場合に何が起こるかを定義することです。クライアントが要求するかどうかは問題ではありません。 3ナインまたは5ナインまたは100万ナイン-問題は、配信できない場合または配信できない場合に何が得られるかということです。明白な答えは、課金する価格の5倍で100％の稼働率のラインアイテムを提供することです。そのターゲットを逃した場合、4倍の払い戻しを受けます。
これは不可能です。
間違いなくクライアントは「100％」を見ることに集中しているので、あなたができる最善のことは100％を約束することです。
DNSの変更は、時間がかかるように構成されている場合にのみ時間がかかります。 TTLレコードの1秒に設定できます-唯一の問題は、DNSクエリにタイムリーな応答を提供し、DNSサーバーがそのレベルのクエリに対応できるようにすることです。 。
これは、GTMがF5 Big IPでどのように機能するかを示しています。DNSTTLはデフォルトで30秒に設定されており、クラスターの1つのメンバーが引き継ぐ必要がある場合、DNSが更新され、新しいIPが最大で30秒の停止ですが、これはエッジの場合であり、平均は15秒です。
正直なところ、ハッキング攻撃に関して少なくとも100％迷うことなく、完全に正気ではありません。あなたの最善の策は、サイトとDBが複数の地理的な場所にある複数のサーバー間で複製される地理的に分散されたホスティングソリューションがあるという点で、GoogleとAmazonが行うことを実行することです。これは、インターネットのバックボーンが地域に切断される（時折発生する）か、ほとんど終末論的な何かなどの大規模な災害以外のあらゆる状況でそれを保証します。
私はそのような場合（DDOS、インターネットバックボーンカッティング、黙示録的なテロ攻撃または大戦争など）については条項を設けます。
それ以外は、Amazon S3またはRackspaceクラウドサービスを調べます。基本的に、クラウドのセットアップは、各ロケーションの冗長性を提供するだけでなく、トラフィックのスケーラビリティと地理的分布を提供し、障害が発生した地理的エリアを迂回する機能も提供します。私の理解は、地理的分布がより多くのお金を要するということですが。
100％の可能性はないと思いますが、Azure（または同様のSLAを持つもの）を可能性として検討することもできます。何が起こっているのですか？
サーバーは仮想マシンです。 1つのサーバーでハードウェアの問題が発生した場合、仮想マシンは新しいマシンに移動されます。ロードバランサーがリダイレクトを処理するため、お客様にはダウンタイムが発生しません（ただし、セッションの状態がどのように影響を受けるかはわかりません）。
そうは言っても、このフェイルオーバーがあっても、99.999と100の違いは狂気にかかっています。
次の要素を完全に制御する必要があります。
-内面と外面の両方の人的要因、悪意と無力の両方。この例は、誰かがサーバーをダウンさせるプロダクションコードに何かをプッシュすることです。さらに悪いことに、妨害行為はどうですか？
-ビジネス上の問題。プロバイダーが忙しくなくなったり、電気料金を支払うのを忘れたり、十分な警告なしにインフラストラクチャのサポートを停止したりする場合はどうなりますか？
-自然。無関係な竜巻が同時にバックアップ容量を圧倒するのに十分なデータセンターを襲った場合はどうなりますか？
-完全にバグのない環境。あなたはシュアそれ自体を明示していませんが、将来もそうすることができるサードパーティまたはコアシステムコントロールのEdgeケースはありませんか？
-上記の要素を完全に制御できたとしても、これを監視しているソフトウェア/人が、システムが稼働しているかどうかを確認するときに、偽陰性を示さないことを確信していますか？
ここで100％は非常識または不可能であると指摘する人もいますが、彼らはどういうわけか本当の意味を逃しました。彼らは、これの理由は最高の会社/サービスでさえそれを達成できないという事実であると主張しました。
まあ、それはそれよりずっと簡単です。 数学的に不可能です。
すべてに確率があります。サーバーを格納するすべての場所で同時に地震が発生し、サーバーがすべて破壊される可能性があります。確かにそれは途方もなく小さい確率ですが、それは0ではありません。すべてのインターネットプロバイダーは同時テロ/サイバー攻撃に直面する可能性があります。繰り返しますが、あまり可能性は高くありませんが、ゼロでもありません。提供するものが何であれ、サービス全体を停止させるゼロ以外の確率のシナリオを取得できます。これにより、稼働時間も100％になることはありません。
可用性を測定する方法を再考し、顧客と協力して意味のある目標を設定します。
大規模なWebサイトを実行している場合、uptimeはまったく役に立ちません。顧客が最も必要とする（トラフィックのピーク）ときにクエリを10分間ドロップすると、日曜日の午前3時に1時間停止するよりも、ビジネスに悪影響を与える可能性があります。
大規模なウェブ企業は、次の指標を使用して可用性または信頼性を測定することがあります。
- サーバー側エラー（HTTP 500s）なしで正常に応答されたクエリの割合。
- 特定のターゲット以下で回答されたクエリの割合待機時間。
- 削除されたクエリは統計にカウントされます（以下を参照）。
可用性はnotをサンプルプローブを使用して測定する必要があります。これは、pingdomやpingabilityなどの外部エンティティがレポートできるものです。それだけに依存しないでください。正しく実行したい場合は、1つのクエリごとに数える必要がありますです。実際に認識された成功を見て、可用性を測定します。
最も効率的な方法は、ロードバランサーからログまたは統計を収集し、上記のメトリックに基づいて可用性を計算することです。
ドロップされたクエリのパーセンテージも統計にカウントされます。サーバー側のエラーと同じバケットで説明できます。ネットワークまたはDNSやロードバランサーなどの別のインフラストラクチャに問題がある場合は、簡単な計算を使用して、失われたクエリの数を見積もることができます。その曜日にXクエリを期待していたがX-1000を取得した場合、おそらく1000クエリをドロップしました。トラフィックを1分（または1秒）あたりのクエリのグラフにプロットします。ギャップが表示された場合は、クエリを削除しました。 基本ジオメトリを使用して、これらのギャップの面積を測定します。これにより、ドロップされたクエリの総数がわかります。
この方法論をお客様と話し合い、その利点を説明してください。現在の可用性を測定してbase-lineを設定します。 100％は不可能な目標であることは彼らに明らかになるでしょう。
次に、ベースラインの改善に基づいて契約に署名できます。たとえば、現在95％の可用性を経験している場合は、98.5％に到達することで状況を改善することを約束できます10倍。
注：可用性を測定するこの方法には欠点があります。まず、既存のツールを使用しない限り、ログの収集、レポートの処理および生成を自分で行うのは簡単なことではありません。次に、アプリケーションのバグは可用性を損なう可能性があります。アプリケーションの品質が低い場合、エラーの数が増えます。これに対する解決策は、アプリケーションからの500ではなく、ロードバランサーによって作成された500のみを考慮することです。
物事はこのように少し複雑になるかもしれませんが、それはあなたのサーバー稼働時間だけを測定することを超えた一歩です。
「それはcan（理論的には）行われる」パーティーに別の声を加えたかっただけです。
彼らが私にどれだけ支払ったかに関係なく、これが指定された契約を結ぶことはありませんが、研究上の問題として、それはいくつかのかなり興味深い解決策を持っています。手順を概説するのに十分なほどネットワークに精通していませんが、ネットワーク関連の構成+電気/ハードウェア配線フェイルオーバー+ソフトウェアフェイルオーバーの組み合わせは、おそらく、いくつかの構成または他の作業で、実際にそれを引き離すことになると想像します。
ほとんどの場合、構成のどこかに単一障害点がありますが、十分に努力すれば、その障害点を「ライブ」で修復できるものにプッシュできます（つまり、ルートDNSがダウンしますが、値は引き続きキャッシュされます）他のすべての場所にいるので、修正する時間があります）。
繰り返しますが、それは実現可能であるとは言いません..私が単一の答えが「そこまでの道」ではないという事実に対処しないのが嫌だっただけです-彼らがそれを熟考した場合、彼らが実際に望むものではありません。
統計的サンプリングを使用した製造品質管理に関する本を入手してください。この本の一般的な議論は、すべてのマネージャーが大学の一般統計学コースで経験したであろう概念であり、1,000分の1から1万分の1から100万分の1に至るまでのコストを示しています。 10億分の1は指数関数的に増加します。基本的に、100％の稼働率を達成する能力は、オブジェクトを光の速度にプッシュするために必要な燃料の量のような、ほぼ無制限の金額のコストがかかります。
パフォーマンスエンジニアリングの観点からは、この表現は真の要件というよりは欲望であるという、テスト不可能な、合理的でないという要件を拒否します。ネットワーキング、名前解決、ルーティング、基盤となるアーキテクチャコンポーネントや開発ツールから発生する欠陥など、アプリケーションの外部に存在するアプリケーションの依存関係により、100％の稼働率を保証することは現実的に不可能です。
お客様が実際に100％のアップタイム、または99.999％のアップタイムを要求しているとは思いません。彼らが説明していることを見ると、流星がオンサイトのデータセンターを取り上げた場合、彼らは彼らが中断したところから再開することを話しているのです。
要件が外部の人々に気付かれない場合でも、それはどれほど徹底的である必要がありますか？ Ajaxリクエストを再試行して、エンドユーザーに30秒間スピナーを表示しても問題ありませんか？
これらは、お客様が気にかけるようなものです。顧客が実際に正確なSLAを考えている場合は、99.99または99.999と表現するのに十分な知識があります。
私の2セント。スーパーボウルの広告を出すフォーチュン5社の非常に人気のあるウェブサイトを担当しました。トラフィックの急増に対処する必要があり、解決方法はAkamaiのようなサービスを使用することでした。私はAkamaiで働いていませんが、彼らのサービスは非常に良いと感じました。彼らは、特定のノード/ホストが高負荷状態にあるかダウンしていて、それに応じてトラフィックをルーティングできることを知っている独自のよりスマートなDNSシステムを持っています。
彼らのサービスの優れた点は、自分のデータセンターのサーバーのコンテンツをデータセンターに複製するために、非常に複雑なことをする必要がまったくなかったことです。さらに、私は彼らと協力して、Apache HTTPサーバーを多用したことを知っています。
100％の稼働時間ではありませんが、コンテンツを世界中に分散させるためのそのようなオプションを検討することができます。私が理解しているように、アカマイには、ミシガンにいる場合はトラフィックの意味をローカライズする機能もあり、ミシガン/シカゴのサーバーからコンテンツを取得し、カリフォルニアにいる場合は、カリフォルニアにあるサーバーからコンテンツを取得したと考えられます。
オフサイトフェイルオーバーの代わりに、内部と外部の2つの場所から同時にアプリケーションを実行するだけです。 2つのデータベースを同期します。内部がダウンしても、内部の人々は引き続き作業でき、外部の人々はアプリケーションを使用できます。内部がオンラインに戻ったら、変更を同期します。 1つのドメイン名またはラウンドロビンを備えたネットワークルーターに対して2つのDNSエントリを持つことができます。
外部でホストされているサイトの場合、100％の稼働率に最も近いのは、GoogleのApp Engineでサイトをホストし、その 高レプリケーションデータストア（HRD） を使用することです。これにより、少なくとも3つのデータにわたってデータが自動的に複製されます。リアルタイムでセンタリングします。同様に、App Engineフロントエンドサーバーは自動的にスケーリング/複製されます。
ただし、Googleのすべてのリソースと世界で最も洗練されたプラットフォームがあっても、 App Engine SLA の稼働時間の保証は、「暦月の時間の99.95％」にすぎません。
シンプルでダイレクト：エニーキャスト
http://en.wikipedia.org/wiki/Anycast
これは、クラウドフレア、グーグル、およびその他の大企業が、冗長で低遅延の大陸間フェイルオーバー/バランシングを行うために使用するものです。
ただし、稼働時間を100％にすることは不可能であり、99.999％から99.9999％に移行するためのコストははるかに大きいことにも注意してください。