現実世界では、トラフィックの急増から突然の停電に至るまで、さまざまなイベントによってサーバーのパフォーマンスが低下する状況が発生することがあり得ます。 アプリケーションがクラウドまたは物理マシンのどちらでホストされているかに関係なく、さらに悪化して、サーバーが機能しなくなる可能性もあります。 このような事態は避けられません。 しかし、このような事態が起こらないことを願うのではなく、実際にすべきことは、システムが障害に遭遇しないように準備をすることです。 高可用性アーキテクチャとは、高負荷時であっても最適な運用パフォーマンスを保証するシステムのコンポーネント、モジュール、またはサービスの実装を定義するアプローチです。 HA システムの実装に決まったルールはありませんが、最小限のリソースで最大の効果を得られるように、一般的にいくつかの良い実践方法があります。
なぜそれが必要なのですか
先に進む前に、ダウンタイムを定義しておきましょう。 ダウンタイムとは、システム（またはネットワーク）が使用できない、または応答しない期間のことです。 システムが停止すると、すべてのサービスが停止してしまうため、ダウンタイムは企業に莫大な損失をもたらす可能性があります。 2013年8月、アマゾンは15分間ダウンし（ウェブとモバイルの両方のサービス）、結局1分あたり66000ドル以上の損失を出した。 これは、Amazon のような規模の企業であっても、非常に大きな数字です。
ダウンタイムには、予定されていたものと予定されていなかったものの 2 種類があります。 予定されているダウンタイムは、メンテナンスの結果であり、避けられないものです。 これには、パッチの適用、ソフトウェアの更新、あるいはデータベース・スキーマの変更などが含まれます。 一方、予定外のダウンタイムは、ハードウェアやソフトウェアの障害など、何らかの不測の事態によって発生するものです。 これは、停電や部品の故障によって発生することがあります。 高可用性アーキテクチャを実装する主な目的は、システムまたはアプリケーションが最小限のダウンタイムでさまざまな負荷や障害に対処できるように構成されていることを確認することです。
これを達成するために役立つ複数のコンポーネントがありますが、それらについて簡単に説明します。
クラウド インフラストラクチャをフル活用する予定の組織は、24 時間 365 日利用可能という要求を満たす能力も備えている必要があります。
x = (n – y) * 100/n
ここで、n は暦月の合計分数、y は与えられた暦月でサービスが利用できない合計分数です。 高可用性とは、簡単に言えば、望ましいほど長い期間にわたって継続的に動作するコンポーネントやシステムのことである。 製品またはシステムの可用性の基準として広く知られているが、達成することはほとんど不可能であるため、「ファイブ9s」（99.999％）の可用性と呼ばれている。 高可用性は、システム停止によるリスクからビジネスを守ろうとする企業にとって必要不可欠な条件である。 これらのリスクは、何百万ドルもの収益損失につながる可能性があります。
それは本当にお金をかける価値があるのでしょうか
高可用性アーキテクチャを採用することで、高いパフォーマンスが得られることは確かですが、それには大きな代償が伴います。 その決断が財務の観点から正当化されるかどうか、自問自答する必要があります。
余分なアップタイムが、それに費やさなければならない金額に本当に見合っているかどうかを判断する必要があります。 潜在的なダウンタイムが企業にとってどれだけ損害を与えるか、そして、ビジネスを運営する上でサービスがどれだけ重要かを自問自答する必要があります。
さて、決定したところで、それを実行する方法について説明しましょう。 直感に反して、システムに多くのコンポーネントを追加することは、システムをより安定させ、高可用性を達成するのに役立ちません。 コンポーネントを増やせば増やすほど故障の確率が上がるので、実際には逆効果になりかねない。 最新の設計では、ネットワークやクラスターなどの複数のインスタンスにワークロードを分散させることができます。これは、リソースの使用を最適化し、出力を最大化し、応答時間を最小化し、負荷分散として知られるプロセスでシステムの過負荷を回避するために役立ちます。
Use of Multiple Application Servers:
Imagine that you have a single server to render your services and a sudden spike in traffic leads to it failure (or crashes)． このような状況では、サーバーが再起動するまで、それ以上の要求を処理できず、ダウンタイムが発生します。
ここでの明白な解決策は、複数のサーバーにアプリケーションを展開することです。 これらすべての間で負荷を分散する必要があり、どれにも過度の負担がかからず、出力が最適になるようにします。 また、アプリケーションの一部を異なるサーバに配置することもできます。 たとえば、メールを処理するための別のサーバーや、画像などの静的ファイルを処理するための別のサーバー (Content Delivery Network のようなもの) が考えられます。 データベースは、アプリケーション サーバーと同様にサービスにとって重要であることを覚えておく必要があります。 データベースは別のサーバー (Amazon RDS など) で実行され、同様にクラッシュしがちです。 さらに悪いことに、データベースのクラッシュはユーザー データの損失につながり、大きな損失をもたらす可能性があります。
冗長性は、障害検出性を達成し、共通の原因による障害を回避することによって、高いレベルの可用性を持つシステムを作成するプロセスです。 これは、メイン サーバーがクラッシュしたときに介入できるスレーブを維持することで実現できます。 データベースのスケーリングに関するもう一つの興味深い概念は、シャーディングです。 シャードとは、データベース内の水平方向のパーティションで、同じテーブルの行を別のサーバーで実行するものです。
したがって、サーバーを異なる場所に配置することが不可欠です。 最近のほとんどの Web サービスでは、サーバーの地理的な位置を選択できます。 この記事では、高可用性アーキテクチャのアイデアを形成する基本的なアイデアに触れようとしました。 最終的に、単一のシステムですべての問題を解決できるわけではないことは明らかです。 したがって、自分の状況を慎重に判断し、どのような選択肢が最も適しているかを決定する必要があります。
ベスト プラクティスは何ですか
システム障害を抑制し、計画的および計画外のダウンタイムを抑えるために、高可用性 (HA) アーキテクチャの使用は、特にミッション クリティカル アプリケーションに強く推奨されます。 可用性の専門家は、システムが高い可用性を持つためには、その部品がよく設計され、厳格にテストされていなければならないと主張している。 高可用性アーキテクチャの設計とその後の実装は、ソフトウェア、ハードウェア、および導入オプションが多岐にわたるため、困難な場合があります。 しかし、成功するための取り組みは、通常、明確に定義され、包括的に理解されたビジネス要件から始まります。 選択されたアーキテクチャは、セキュリティ、スケーラビリティ、パフォーマンス、および可用性の望ましいレベルを満たすことができなければなりません。 アーキテクチャを適切に設計するだけでなく、企業は高可用性のための推奨ベスト プラクティスを遵守することにより、重要なアプリケーションをオンラインに保つことができます。
- Data Backups, Recovery and Replication
システム障害から保護する優れたデータ保護計画の特徴は、健全なバックアップと回復戦略である。 貴重なデータは、適切なバックアップ、レプリケーション、またはデータを再作成する能力なしでは決して保存されるべきではありません。 すべてのデータセンターは、データの損失や破損を事前に計画する必要があります。 データのエラーは、顧客認証の問題を引き起こし、金融口座やその後のビジネス社会の信用に損害を与える可能性があります。 データの完全性を維持するために推奨される戦略は、プライマリデータベースのフルバックアップを作成し、ソースサーバーのデータ破損を段階的にテストすることです。 完全なバックアップを作成することは、壊滅的なシステム障害から回復するための最重要事項です。
- Clustering
最高品質のソフトウェア工学であっても、すべてのアプリケーション サービスはいつかは障害を起こすものです。 高可用性とは、障害に関係なくアプリケーション サービスを提供することです。 クラスタリングは、障害が発生した場合に、即座にフェイルオーバー アプリケーション サービスを提供できます。 クラスタを意識したアプリケーション・サービスは、複数のサーバーからリソースを呼び出すことができ、メイン・サーバーがオフラインになるとセカンダリー・サーバーにフォールバックします。 高可用性クラスタには、共有データメモリーグリッドを介して情報を共有する複数のノードが含まれます。 つまり、どのノードがネットワークから切断またはシャットダウンされても、少なくとも1つのノードが完全に機能している限り、クラスタの残りの部分は通常通り動作し続けることができる。 各ノードは個別にアップグレードでき、クラスターが動作している間に再接続することができます。 クラスターを実装するためにハードウェアを追加購入する高いコストは、利用可能なハードウェア リソースを活用する仮想化クラスターを設定することで軽減できます。
- Network Load Balancing
Load Balancing は、重要な Web ベース アプリケーションの可用性を高めるための有効な方法です。 サーバー障害インスタンスが検出されると、トラフィックがまだ稼働しているサーバーに自動的に再分配されるため、シームレスに置き換えられます。 ロードバランシングは高可用性を実現するだけでなく、拡張性も高めることができる。 ネットワークのロードバランシングは、「プル」または「プッシュ」モデルによって実現することができる。
- Fail Over Solutions
High availability architecture は、従来、フェイルオーバー機能を持つ疎結合サーバーのセットで構成されていました。 フェイルオーバーとは、基本的にバックアップ運用モードのことで、プライマリ システムが障害または計画的ダウンタイムによってオフラインになった場合に、システム コンポーネントの機能がセカンダリ システムによって引き取られることです。 コールドフェイルオーバー」は、プライマリーサーバーが完全にシャットダウンした後にセカンダリーサーバーを起動させる場合に発生する。 ホットフェイルオーバー」は、すべてのサーバーが同時に稼働し、負荷が常に1つのサーバーに集中する場合に発生する。 どちらのシナリオでも、タスクは自動的にスタンバイシステムコンポーネントにオフロードされるため、エンドユーザーにとって可能な限りシームレスなプロセスが維持されます。
- Geographic Redundancy
Geo-Redundancy は、システム停止を引き起こす自然災害などの壊滅的なイベントにおいて、サービス障害を防止するための唯一の防御線となります。 ジオ・レプリケーションの場合と同様に、複数のサーバーが地理的に異なるサイトに配置されます。 その際、特定の地域に局在するのではなく、グローバルに分散していることが望ましい。 各拠点で独立したアプリケーションスタックを実行し、一方の拠点で障害が発生した場合でも、他方の拠点が稼働し続けることができるようにすることが重要である。 理想的には、これらの場所は互いに完全に独立しているべきです。
- Plan for failure
高可用性のベスト プラクティスを適用することは本質的に失敗に対する計画であるという事実にもかかわらず、ダウンタイムにつながるシステム障害の場合に備えを高めるために組織が取るべき行動はほかにもあります。 組織は、問題の切り分けや傾向の分析に使用できる障害やリソース消費に関するデータを保管しておく必要があります。 このデータは、運用の作業負荷を継続的に監視することによってのみ収集することができる。 リカバリーヘルプデスクを設置し、問題情報を収集し、問題履歴を確立し、直ちに問題解決を開始することができる。 復旧計画は、十分に文書化するだけでなく、定期的にテストして、計画外の中断に対処する際の実用性を確認する必要があります。 アベイラビリティエンジニアリングのトレーニングを受けることで、高可用性アーキテクチャの設計、導入、保守のスキルを向上させることができる。 また、セキュリティ違反によるシステム停止の発生を抑制するために、セキュリティポリシーを導入する必要があります。 FileCloud 高可用性アーキテクチャ
FileCloud サーバーを高可用性に構成して、サービスの信頼性を向上させ、ダウンタイムを削減する方法を説明した図です。 詳しくはこちらをご覧ください。