Webサイトの高可用性を導入する適切な時期はいつですか。
Webサイトの高可用性を導入する適切な時期はいつですか。
高可用性オプションに関する記事はたくさんあります。ただし、単一サーバーから高可用性構成に切り替える適切なタイミングはそれほど明白ではありません。
私の状況を考慮してください：
http://www.postjobfree.com は、トラフィックが多い24時間年中無休のWebサイトです。
http://www.similarweb.com/website/postjobfree.com
現在、私はそれを単一のサーバーで実行しています。IIS 7.0WebサーバーとSQLServer2008の両方が同じハードウェアボックスで実行されています。
通常、一部のWindows Serverの更新に必要な再起動が原因で、場合によっては（1か月に1回）、最大5分のダウンタイムが発生します。通常、ダウンタイムはスケジュールされており、夜間に発生します。それでも、Google Botと一部のユーザーは夜も活動しているため、不快です。
現在のウェブサイトの収益は月額約8000ドルです。
2サーバー構成（2つのWebサーバーのWebファームと2つのハードウェアサーバーでホストされる2つのSQLサーバーのクラスター）への切り替えを検討します。
長所：
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つの中心であると考えています 。他の人が言っているように、私は評判についてもっと心配するでしょう。
あなたがこれについて考える間、私はあなたが「失敗したクジラ」ページをセットアップすることを検討すると思います。
これを行う方法はたくさんありますが、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/ for設定のガイド。
DynDnsのソーシャルフェイルオーバー http://dyn.com/managed-dns/social-failover/ は同様の種類のものです。
DNSレコードのTTLが低く、プログラムでそれらを操作する方法がある場合は、自分でロールしてヘルスチェックを実行し、DNSの変更をスクリプト化することができます。
HAは、セキュリティと同様に、製品ではなくプロセスであることに注意してください。
たとえば、データベースレプリケーションでは、データベースの各ミラーが独自に続行できるようになるだけですが、障害が発生したコンポーネントを交換した後の再同期の戦略も必要になります。
例として注文システムを考えてみましょう。顧客が注文を送信し、処理中に、データベースのローカルコピーに注文情報を保存した後、話していた物理システムに障害が発生しました。せっかちなことに、顧客はもう一度「送信」を押すと、注文を受け入れる別のサーバーに転送されます。欠落しているINSERTステートメントを反対側で再生するだけでデータベースが再同期されると、順序が重複しますが、これは希望どおりでない場合があります。
@Slartibartfastが示唆したように、それはすべて経済的な決定に帰着しますが、ここで数年先の計画も立てることをお勧めします。適切なHAセットアップが必要になると予想される場合は、準備作業のためにリソースを確保する良い機会です。
柔軟にスケーリングでき、短所も打ち消すEC2のようなものを使用することを検討しましたか？ EC2を使用する価値があるかどうかは、最終的には経済的な決定ですが、少なくとも検討するオプションです。