Webサイトの高可用性を導入するのに適切なタイミングはいつですか？

Webサイトの高可用性を導入するのに適切なタイミングはいつですか？

高可用性オプションに関する多くの記事があります。ただし、単一サーバーから高可用性構成に切り替えるのに適切なタイミングはいつかということは明らかではありません。

私の状況を考慮してください：
http : //www.postjobfree.comは24時間年中無休のWebサイトであり、大量のトラフィックがあります：http :
//www.similarweb.com/website/postjobfree.com

現在、単一のサーバーで実行しています。IIS7.0 WebサーバーとSQL Server 2008の両方が同じハードウェアボックスで実行されています。

通常、Windows Serverの更新プログラムで必要な再起動が原因で、時折（1か月に1回）〜5分のダウンタイムが発生します。通常、ダウンタイムは予定されており、夜間に発生します。それでも、Google Botと一部のユーザーは夜もアクティブであるため、不快です。

現在のWebサイトの収益は、約8,000ドル/月です。

2サーバー構成（2つのWebサーバーのWebファームと、2つのハードウェアサーバーでホストされる2つのSQL Serverのクラスター）に切り替えることを検討します。

長所：
1）高可用性（理論的にはダウンタイムなし）。サーバーの1つがダウンした場合でも、別のサーバーが引き継ぎます。
2）データの損失なし：SQLクラスターがない場合、ハードウェア障害の場合に最大1日分のデータが失われる可能性があります（毎日バックアップを行います）。

短所：
1）そのような構成をセットアップして維持するためのより多くの努力。
2）ホスティングコストが高い。毎月〜600ドルではなく、毎月約1200ドルです。

あなたの推薦は何ですか？

簡単な答え：ダウンタイムまたはそのリスクにより、高可用性を得るための費用がかかる場合。

それは基本的に経済的な決定です。例として。月額8,000ドルは、2時間の停止に22ドルかかることを意味します。2時間以内にゼロから完全に機能するサイトに移行できるようにシステムを構成できる場合、高可用性ではそれ以上の機能が22ドルしか得られません。

別の言い方をすれば、特定の月に54時間の予防不可能なダウンタイムが発生しない限り、お金を節約できます。

あなたの利害関係者/ビジネスの人々（あなたかもしれません！）

• 許容できる収益の損失
• 結果評判の低下、尊敬など
• 許容可能なデータ損失（目標復旧ポイント）
• 許容可能なダウンタイム（目標復旧時間）

収益の損失は簡単に定量化できます。残りはここでは答えられません。申し訳ありません...

ほとんどのユーザーは、少しの予定されたダウンタイムを処理できると思います。ebayでは金曜日の夜に毎週更新が行われ、その前後の入札は時々機能しないことを考慮してください。私の（主要なオーストラリアの）銀行のオンラインバンキングでは、毎週数時間の停止が予定されています。Twitterは常にオフラインになります。Heroku / EC2は最近数日間ダウンしていました。

私はその観点でそれを維持します、あなたが本当に月に5分しか話していないなら、あなたはシステム管理者として非常に良い仕事をしています。

インデックス作成の要素としてGoogleを既に言及しましたが、レイテンシ/サイトの応答性がSEOに与える影響を考慮する価値があるかもしれません。それはブラックボックスであり、すべてを定量化するのは非常に困難です。しかし、その価値はあるものの、Matt Cuttsはそれが1つの中心であると考えています。他の人が述べたように、私は評判についてもっと心配するでしょう。

HAは、セキュリティと同様に製品ではなく、プロセスであることに注意してください。

たとえば、データベースレプリケーションでは、データベースの各ミラーが単独で継続できるようになるだけですが、障害のあるコンポーネントを交換した後の再同期のための戦略も必要です。

例として注文システムを考えてみましょう。顧客が注文を送信し、処理中に、データベースのローカルコピーに注文情報を保存した後、彼が話していた物理システムが故障します。せっかちなお客様は、もう一度「送信」を押すと、注文を受け入れる別のサーバーに転送されます。反対側で欠落しているINSERTステートメントを再生するだけでデータベースを再同期すると、順序が複製されますが、これは望んでいない場合があります。

@Slartibartfastが示唆したように、それはすべて経済的な決定に帰着しますが、ここで数年先の計画を立てることもお勧めします。適切なHAセットアップが必要な場合は、準備作業のためにリソースを確保するのがよいタイミングです。

これについて考えている間、「クジラの失敗」ページの設定を検討すると思います。

これを行う方法はたくさんありますが、route53とs3のawsコンボは私の小さなサイトでうまく機能します。

障害時にDNSがs3にある静的htmlページにユーザーを送信するように、ヘルスチェックを使用してドメインを設定します。費用はほとんどありません。

私の経験では、あなたのサイトに「申し訳ありませんが壊れていますが、私たちはそれに取り組んでいます」と言うことは、ユーザーに世界を変えます。ユーザーと通信できるTwitterアカウントはさらに優れています。

これは、停止の最も重大な影響となる可能性のある「評判の低下」を緩和するのに長くかかります。

設定のガイドについては、https：//aws.amazon.com/blogs/aws/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting/をご覧ください。

DynDnsのソーシャルフェールオーバーhttp://dyn.com/managed-dns/social-failover/は似たようなものです。

DNSレコードのTTLが低く、プログラムで操作する方法がある場合は、独自にロールしてヘルスチェックを行い、DNSの変更をスクリプト化できます。

EC2のように柔軟に拡張し、短所を無効にするようなものを使用することを検討しましたか？EC2を使用する価値があるかどうかは、最終的には経済的な決定ですが、少なくとも考慮すべきオプションです。

データの損失を防ぐには、クラスターの前にRAID構成を調べる必要があります。DNSの伝播を待たずに災害が発生した場合に、あるサーバーから別のサーバーに切り替えることができるフェールオーバーIPも構成する必要があります。