現在、クラシックなn層アプリケーションがあります：DB / Webサービス/フロントエンド。他のコンポーネントがありますが、基本的なレイアウトです。

アプリケーションの可用性を改善する主な理由は3つあります。

1. 私たちのホストは時々（すべてのように）停止を経験し、私たちは顧客への影響を最小限にしたいので、たとえば、データセンターAがダウンした場合、彼らはデータセンターBをオンにします。
2. バージョンをアップグレードすると、メンテナンスのためにサイトがシャットダウンされ、通常は数時間かかります（移行スクリプトなど）。ユーザーには、ダウンタイムを最小限に抑えて、よりシームレスな移行を望んでいます（サーバーAのアップグレード中にサーバーBを使用します）。
3. オプションとして、私たちの顧客は世界中にあり、私たちは彼らの接続が不安定である可能性があるにもかかわらず、可能な限り最高の体験をしてもらいたいと思っています（インドの開発者と一緒に働いた人は誰でも私が何を言っているか知っているはずです）。理想的には、私たちは彼らのオフィスにサーバーを接続できるようにしたい（または彼らの都市の近くのデータセンターを使用できる）ようにしたい、そしてそれは私たちのアーキテクチャにシームレスに統合するだろう。

リモートで99％の可用性を必要とせず、95％も必要としません。ドキュメント管理アプリです。誰も気にしない。ただし、移行には時間がかかる場合があり、世界中にお客様がいるため、お客様が1日のほとんどの時間にわたって仕事をすることができない場合があります。

SQLの部分については、「適切な」DBAがいない場合でも、SQLの可能性（レプリケーション、ミラーリングなど）について知っています。DB側では、このためのリソースを見つけるのは非常に簡単です。セッションやコードの保存など、他のすべてが難しいのは何ですか。Webサービスサーバーがダウンした場合、UIはそれを切り替える必要があることをどのように認識しますか？セッションはどのようにサーバー間で保持されますか？

残念ながら、私たちの誰もこの分野での経験がなく、どこから探し始めればよいかさえわかりません。このためのベストプラクティスはありますか？デザインパターン？ライブラリー（お金がないため、無料で使用できます）？

ASP.NetとSQL Serverを使用しており、中央にWCF Webサービスがあります。Windowsサービスはたくさんありますが、ミッションクリティカルではありません。Webサイトを処理する方法がサービスに適用できると思います。

ほとんどのクラウドプラットフォームがこのための組み込みシステムを提供していることを理解していますが、私たちのシステム管理者はすべてを自分で管理し、誰にも依存しないことを望んでいるため、クラウドホスティングは不可能です。

どのような高可用性を求めているのかを明確にする必要があります。私が実行する可用性の高いアプリケーションには、95％の時間を必要とするものがあります。99％で実行する必要がある他のものがあります。100％の稼働時間を必要とする生死のシナリオを考えることができます。これら3つだけでは、アプローチとコストが大幅に異なります。

ニーズと95〜99％の稼働時間SLAに基づいて推測するだけです。

• ほとんどの変更について、データベースの移行はリアルタイムで実行できるはずです。進化的データベース設計の実践。より侵襲的な動作が必要な変更については、いくつかのオプションがあります。1つはダウンタイムを取ることです。可能であれば、サービスを読み取り専用モードで実行すると機能する場合があります。完全な機能を実現するために、しばらくScaleArcを試してみたいと思っていました。これは、SQL Serverの世界でスケーリングと復元力を実現するための非常に洗練されたツールのようです。
• 顧客のサイト内にサーバーを配置することは、世界規模の展開戦略（移行の説明に基づいてまだ行っていない）がない限り、管理不可能な災害のレシピです。パフォーマンスの問題があるため、オンプレミスでクラウドサービスをプッシュしないでください。パフォーマンスの問題を今解決すれば、コストのかかる問題に対処する必要がなくなります。
• 状態サーバーは、何らかのデータベースである必要があります。HAガイドラインに従ってください。SQL Serverは既に使用できるので、SQL Serverを使用できます。
• データベースといえば、レプリケーションはHAを有効にしません。実際、SQLレプリケーションは毎回問題を引き起こします（複数ノードのレプリケーションシナリオの経験から言えば）。ミラーリングは機能しますが、最後に覚えているように、SQLクラスタリングは新しいサーバーにフェイルオーバーするのに1〜5分かかります。AlwaysOnについて良いことは聞いたが、Microsoftの実績を考えると、私はまだ疑わしい。ここでは、ScaleArcのようなものがさらに役立つ場合があります。
• Webサーバーはステートレスである必要があります。3つまたは4つスピンアップし、ロードバランサーの後ろに置きます。それはあなたのアップタイムの心配をそこで解決します。フレデリクが前述したように、ローリングデプロイメントをこの方法で行うこともできます。
• Webサービスはおそらくステートレスでなければなりません。そうでない場合は、ステートレスビットとステートフルビットに分解できるかどうかを確認してください。同じロードバランサーの背後に複数のインスタンスを配置すると、稼働時間の問題が解決され、より関心の高い展開シナリオ（青/緑の展開など）が可能になります。

フレデリクとは異なり、私はあなたのクラウドパラノイアを不当なものとはしません。稼働時間の要件によって異なります。冗長性のために、サービスはさまざまな国のさまざまなプロバイダーが運営する複数のデータセンターで実行する必要があると考えられます。しかし、あなたの現在の状態を考えると、AWS、Azure、または同様のものがおそらくあなたの会社にとって安全な賭けであることに同意します。

Webおよびアプリケーション層である程度のHAを取得する：

1. 理想的には、データベースやメモリ内のセッション状態サーバーなどの共有状態システムに、セッション状態を含むすべての状態を除外します。アプリケーションの設計によっては、追加のレイテンシが大量の状態を取得するため、パフォーマンスの問題が発生する場合があります。

2. Webサイトとアプリケーション層のそれぞれの前に、独立したロードバランサーが必要です。NGINXがトリックを実行しますが、IISもこれを実行できます（ARR）。

3. 単一のデータベースが負荷を処理できない場合は、セッション状態のパーティション分割（またはシャーディングまたは一貫したハッシュ）を利用して、特定のリクエストを特定のデータベースボックスにルーティングします。

状態の抽出が難しい場合は、負荷分散のためのサーバーアフィニティを使用できます（つまり、ユーザーは常に同じボックスにルーティングされ、多くの場合、Cookieベースです）。ボックスの停止はそのボックスのすべてのユーザーと状態に影響を与えるため、ステートレスラウンドロビンアプローチほど高可用性ではありませんが、完全な停止（ユースケースに依存）に勝ります。

アップグレード側：

1. システムの実行中にデータベースのアップグレードを実行できるように、つまり下位互換性を維持するように、データベーススクリプトを設計します。そのために適切に機能するパターンは、「展開してから縮小」->後方互換性のある追加の変更のみを行いますが、削除するフィールド（など）への依存関係を削除します。次に、データベースのすべてのクライアントをv-latestにアップグレードします。次に、別のdb-upgradeを実行して、データベース内の古いフィールド（など）を削除します。大規模なデータベースがあり、システムのパフォーマンスを損なわないように注意する必要がある場合、これは遅いプロセスになる可能性があります。

2. アプリ層のアップグレード：クラウド環境を使用していないため、カナリアデプロイパターンに従うことをお勧めします。ウェブ層と中間層ボックスのローリングアップグレードを実行します。デプロイがうまくいかない場合は、ロードバランサーから箱を取り出します。まるで、失敗したかのようにしてください。

警告の言葉：HA向けに設計されていないシステムを1つに進化させることは、長くてコストのかかるプロセスになる可能性があります。途中でトレードオフを行う必要があります（特定のレベルの可用性に到達するためのコストと労力）

クラウドのパラノイアは不当です-AWSなどのプロバイダーは、あなたの側の優れた実践と組み合わせてほとんどのリスクを制御/軽減できます-コンプライアンスのページを見て、どの規制に準拠しているかを感じてください：https：// aws .amazon.com / compliance /

TL; DR：冗長なモジュール式のビルド。可用性をテストします。よく監視してください。

説明を絞り込もうとすると非常に時間がかかる可能性があることを認識した後、私が行ったすべての観察結果を書き留めます。

前提を問う

クラウドシステムは万能薬です

トップクラウドプロバイダーを使用して完全にクラウドに移行する場合でも、回復力を備えたアプリケーションを設計する必要があります。AWSがVMを置き換える可能性がありますが、計算の途中で残された場合、アプリケーションは再起動できる必要があります。

x / y / zのため、クラウドシステムを使用したくない

あなたが超大規模組織でない限り、あなたはクラウドシステムを使用するほうがよいでしょう。トップ3クラウドシステム（AWS、MSFT、Google）は、何千ものエンジニアを雇用して、約束されたSLAと管理しやすいダッシュボードを提供します。実際には、この社内で10セントを費やす代わりにそれらを使用するのはお買い得です。

スコーピングとデザインの問題

サービスの可用性を定義、定量化し、継続的に測定することは、可用性の問題に対するソリューションを作成するよりも大きな課題です。

「可用性」の定義と測定は予想よりも難しい

複数の利害関係者は可用性について異なる見方をしており、最も高い給与を持つ人が他の定義よりも優先される定義が起こる可能性があります。これは正しい定義である場合がありますが、多くの場合、エコシステムは同じものを測定することを前提に構築されていません。その理想的な定義は測定が非常に難しく、リアルタイムで監視することはできません。リアルタイムで監視できない可用性の定義がある場合は、不気味な類似性を持つ自己実行の類似プロジェクトが何度も見つかるでしょう。理にかなったものと簡単に監視できるものを使います。

人々は常に利用可能なシステムの複雑さを過小評価しています。

部屋の象に対処するために、「マルチコンピュータシステムは100％利用可能ではありません。将来的には、現在のテクノロジーでは利用できなくなる可能性があります」と言いましょう。ここでは、現在のテクノロジーで、光などの速度よりも信号を速く送信できないことを指します。すべてのcomp-sciエンジニアは、分散コンピューティングの制限を知っています。ほとんどのエンジニアは、会議でそれを言及せず、初心者のように見えることを恐れます。分散コンピューティングの制限に触れていないすべての人を補うために、私は言うでしょう、それは複雑ですが常にコンピューターを信頼するわけではありません。

人々は彼ら/彼らのエンジニアの能力を過大評価している

残念ながら、可用性はあなたが何を望んでいるのかは分からないが、何が望ましくないのかを知っているカテゴリーに分類されます。UIなどの「欲しいものを知っている」カテゴリは少しトリッキーです。他人の経験などから学ぶには、少しの経験と多くの読書が必要です。

ゼロから利用可能なシステムを構築する

システム要件としての可用性の適切な優先順位について、すべてのアーキテクチャおよび設計チームに伝道してください。

可用性を支援するシステムの属性

以下のシステム特性は、システムの可用性に貢献していることが示されています。

冗長性

この例としては、VIPの背後にVMが1つしかないことや、データのコピーが1つだけ格納されないことが挙げられます。これらは、優れたIAASによって解決しやすい質問ですが、これらの決定を行う必要があります。

モジュール性

モジュラーRESTは、モノリシックSOAよりも優れています。モジュール式のマイクロサービスでも、通常のHATEOS RESTよりも実際に利用可能です。推論は、次のセクションのYield関連の議論で見つけることができます。バッチ処理を行う場合は、1,000,000のバッチを処理するよりも、10秒の合理的なバッチでバッチ処理を行う方が適切です。

弾力性

"I am always angry"
                    - Hulk

回復力のあるシステムは、いつでも回復する準備ができています。この回復力は、RAIDディスクへの書き込み後にのみ、場合によっては少なくとも2つのデータセンターで書き込みのACKを確認するなどのインスタンスに適用されます。もう1つの最新の傾向は、競合のないデータ構造を使用することです。2つの異なるバージョンが提示された場合、データ構造が競合を解決する責任を負います。システムは後付けとして弾力性を持たせることはできず、予測して組み込む必要があります。故障は長期にわたって保証されているため、常に復旧計画を立てておく必要があります。

ログトレイル

これは技術的にはレジリエンスのサブタイプですが、すべての機能をキャッチできるため、非常に特別なタイプです。最善の努力にもかかわらず、利用不可のパターンを予測できない場合があります。可能であれば、システムイベントを再生できるように、システムアクティビティの十分なログトレイルを維持してください。これにより、手作業で多大なコストをかけて、予期しない状況から回復することができます。

可用性の属性

「可用性」の網羅的ではないtop-of-mind属性リスト：議論のために、ユーザーの質問が「ショッピングカートにはいくつの商品がありますか？」

正しさ

あなたは、くださいしなければならない最も正確な可能な答えを生み出すか、それは大丈夫メイクのミスでしょうか？参考までに、ATMからお金を引き出す場合、正確であるとは限りません。銀行が間違いを発見した場合、取引を取り消す可能性があります。あなたのシステムが素数を生成しているなら、私は推測するでしょう、あなたはいつも正しい答えが欲しいかもしれません。

産出

前のトピックの質問に対して常に正しい回答をした場合は、このポイントをスキップしてください。時々、質問に対する答えは正確である必要はありません。例えば、現在Facebookに何人の友達がいますか？しかし、答えは常にボールパーク+/- 1にあると予想されます。期待どおりの結果が得られる場合、利回りは100です。

一貫性

ある時点ではあなたの答えは正しいかもしれませんが、光が画面から出て観察者の網膜に入るまでには、状況が変わっていた可能性があります。それはあなたの答えを間違っていますか？いいえ、それは単にそれを矛盾させます。ほとんどのアプリケーションは結果的に整合性がありますが、秘訣は、アプリケーションが提供する整合性モデルの種類を定義することです。たまたま、アプリケーションを1台のコンピューターで実行できる場合は、CAPの定理に関するこの読みやすさをスキップできます。

費用

多くは、短期的な影響（収益の損失）と長期的な影響（悪い評判、顧客維持）の全体的な影響に依存します。顧客のタイプ（有料/無料、繰り返し/一意、キャプティブ）とリソースの可用性に応じて、さまざまなレベルの可用性保証を組み込む必要があります。

既存システムの可用性の向上に向けて

個々のマシンとネットワークの運用管理は非常に複雑であるため、クラウドプロバイダーに任せているか、自分が何をしているのかを十分に理解していると思います。空室状況の下で他のトピックに触れます。長期的な戦略の場合、Define-Measure-Analyze-Controlは天国での一致であり、私自身が見たものです。

1. ステークホルダーにとっての「可用性」とは何かを定義する
2. 定義したものをどのように測定しますか
3. ボトルネックを特定する根本原因分析
4. 改善のためのタスク
5. システムの継続的な監視（制御）

利用できない原因

物理的なインフラストラクチャ管理をカバーする運用管理は専門家によって行われるべきであることに同意したので、完全を期すために、利用できない他の原因に触れます。IMOの可用性には、期待される動作の欠如も含まれる必要があります。つまり、ユーザーに期待されるエクスペリエンスが表示されない場合、何かが利用できません。その広い定義を念頭に置いて、次のものは利用できなくなる可能性があります。-コードのバグ-セキュリティの問題-パフォーマンスの問題