Redis
 Computer >> コンピューター >  >> プログラミング >> Redis

高可用性アーキテクチャとは?仕組みからベストプラクティスまで徹底解説

高可用性アーキテクチャとは?

高可用性アーキテクチャとは、ピーク時の負荷にかかわらず、複数のコンポーネントやモジュール、サービスが連携して最適なパフォーマンスを維持し続けるシステム構成のことです。

このシステムは、一定期間にわたって障害なくビジネスを継続できるよう設計されています。多くの企業にとって、たった1分のダウンタイムさえ許容できません。データは多くのビジネスの生命線であり、短時間の停止でも多大な損失につながりかねません。

実際の場面では、人命が高可用性データベースに依存することもあります。救急外来に患者が運ばれた際、医療従事者は電子カルテなどの医療記録に即座にアクセスし、最適な治療方針を判断しなければなりません。情報へのアクセスが遅れれば、取り返しのつかない事態になりかねません。

補足: 高可用性は通常、サービスが利用可能な時間の割合(%)で測定されます。Microsoft Network Developer Glossaryによれば、サーバーが「高可用性」とみなされるには、99.999%のネットワーク稼働率を達成する必要があります。

高可用性クラスタとは?

高可用性クラスタとは、ダウンタイムを防ぐために複数のホストを1つのシステムとして統合したものです。クラスタ内のあるサーバーがダウンすると、障害が検出された直後にミッションクリティカルなアプリケーションが別のサーバーへ即座に引き継がれます。

どんなシステムでも障害の可能性をゼロにはできません。高可用性クラスタは、避けられない障害が発生しても最適なパフォーマンスレベルを維持することを保証します。そのため、最重要度の高いアプリケーション、Webサイト、トランザクション処理システムなどで採用される傾向があります。

高可用性クラスタリングの仕組み

高可用性クラスタは、あらかじめ統合された複数のシステムを活用します。あるシステムに障害が発生しても、別のシステムを効率的に利用することで、サービスやアプリケーションの継続性を保てます。

この中でも、ロードバランシングクラスタはシステム障害の防止において重要な役割を担います。ロードバランサーは、同じWebサイトやアプリケーションを提供する複数のWebノード間でトラフィックを分散します。これにより各サーバーへの負荷が軽減され、クラスタ全体がより効率的に動作するとともに、トラフィックは正常なサーバーにのみ送信されます。

高可用性クラスタの主な構成方式

アクティブ/パッシブクラスタ

アクティブ/パッシブクラスタは、少なくとも2つのノードで構成されます。名前のとおり、すべてのノードが稼働するわけではありません。一方のノードがアクティブとして稼働している間、もう一方は読み取り専用のスタンバイ状態になります。パッシブサーバーはバックアップとして機能し、アクティブサーバーに障害が発生した場合に利用されます。

アクティブ/アクティブクラスタ

このタイプのクラスタでは、通常2つ以上のノードが同じサービスを同時に実行します。アクティブ/アクティブクラスタでは、両方のノードがプライマリノードとして動作し、どちらも読み書きを受け付けられます。片方のノードに障害が発生すると、ユーザーは自動的にもう一方のノードに接続され、サービスの継続性が確保されます。障害ノードが復旧・交換されると、ユーザーは再び2つのノードに振り分けられます。

アクティブ/アクティブクラスタの最大のメリットは、ノード間のネットワーク負荷分散を実現できる点です。サーバー障害が検出されると、ロードバランサーがユーザーリクエストを利用可能なサーバーへ送信し、ノード間のネットワーク状況を分析します。そのうえで、トラフィックを処理できるノードへ通信を振り分けることで、高い耐障害性を実現します。

この戦略はラウンドロビンモデルと似た循環プロセスに従い、ユーザーを利用可能なノードにランダムに分散させるか、あるいは割合に基づいて特定のノードを優先する重み付け方式を採用することもあります。

シェアードナッシング型とシェアードディスク型の違い

分散コンピューティングにおける基本原則は、「単一障害点(SPOF)」を何としても避けることです。そのためには、リソースを積極的に複製または置き換え可能にし、サービス全体が停止しても単一の要因で障害が起きないようにする必要があります。

例えば、1つのデータベースに接続された50個の稼働ノードを想像してください。1つのノードが故障しても、稼働中のノード数にかかわらず、他のノードの永続状態には影響しません。

しかし、データベース自体が故障すればクラスタ全体がダウンしてしまい、データベースが単一障害点となります。これがシェアードディスククラスタです。

一方、各ノードがそれぞれ独自のデータベースを保持していれば、1つのノード障害がクラスタ全体に影響を及ぼすことはありません。これがシェアードナッシングクラスタです。

補足: 高可用性クラスタリング技術についてさらに詳しく知りたい方は、ウェビナーをご覧ください。ソフトウェア業界で20年以上の経験を持つGeorge Carbonnel氏が、Redis Enterpriseによるクラスタリング技術が高性能と高可用性をどう両立させるかについて解説します。

高可用性アーキテクチャに求められる要件

耐久性と高可用性を最大化するためには、いくつかの要件を満たす必要があります。主な要件は以下のとおりです。

ロードバランシング

ロードバランシングは、あらゆる高可用性アーキテクチャにとって不可欠です。主な役割は、バックエンドサーバー間でトラフィックを分散し、データ伝送を効率化するとともに、サーバーの過負荷を防ぐことです。ロードバランシングシステムの前提条件として、ノード障害発生時にどのようなフェイルオーバー手順を実行するかを明確にしておく必要があります。

データスケーラビリティ

データベースやディスクストレージを拡張できるかどうかは、すべての高可用性アーキテクチャで考慮すべき要素です。スケーラビリティを実現する方法は主に2つあります。

  • アーキテクチャのメインデータベースを活用し、レプリケーションやパーティショニングによって高可用性を実現する
  • 個々のアプリケーションインスタンスが独自のデータストレージを保持できるようにする

地理的な分散

今日の高速化するデジタル世界では、高可用性クラスタを世界各地に分散させることが必須となっています。これにより、ある地域で自然災害が発生しても、サービス提供能力への影響を最小限に抑えられます。

バックアップと復旧(ディザスタリカバリ)

どれほど堅牢な高可用性アーキテクチャでも、何らかの不具合によってサービスが中断される可能性は常にあります。そのため、サービスが停止した場合に備え、システム全体をできるだけ早く復旧させるための戦略を用意しておくことが不可欠です。

これは一般に「ディザスタリカバリ(災害対策)」と呼ばれ、障害発生時にサービスを完全な機能状態へ戻すための一連の方針と手順を指します。

高可用性の測定方法

高可用性は通常、サービスが利用可能だった時間の割合(%)で測定されます。具体的には、総稼働時間を対象期間で割り、100を掛けて百分率で表します。Microsoft Network Developer Glossaryによれば、サーバーが「高可用性」とみなされるには、99.999%のネットワーク稼働率を達成する必要があります。

可用性の割合は、数字に含まれる「9」の個数で呼ばれることもよくあります。例えば「フォーナイン」なら99.99%です。

補足: 99.99%の可用性は業界標準とされています。

高可用性を実現するためのベストプラクティス

高可用性を最大化するために実践できる対策は多数あります。コンポーネントの監視から障害サーバーの交換まで、以下のプラクティスを参考にしてください。

地理的冗長性の実現

ジオ冗長化は、自然災害によるサービス障害に対する重要な防御策です。複数の地理的に離れた場所にサーバーを配置することでリスクを分散し、ある地域で災害が発生しても別のサーバーへ切り替えられる体制を整えます。

補足: アクティブ/アクティブの地理分散(Active-Active Geo-Distribution)に対応したデータベースを使えば、これを簡単に実現できます。

フェイルオーバー対策の導入

高可用性アーキテクチャには通常、フェイルオーバー機能を備えた疎結合の複数サーバーが含まれます。フェイルオーバーとは、プライマリシステムの機能が停止した際に自動的に切り替わるバックアップ運用モードのことです。

ロードバランサーの導入

前述のとおり、ロードバランサーは受信トラフィックを複数のサーバーに分散することで、ダウンタイムのリスクを低減します。このソリューションを最大限に活かすためには、自社のニーズに合ったアルゴリズムを選択してロードバランサーを設定しましょう。

目標復旧時点(RPO)を満たすデータ同期の実現

RPO(Recovery Point Objective)とは、組織に損害を与えずに済む最大のデータ損失量を示す指標です。これはビジネス全体のデータ損失許容度を表し、一般的に1分、1日といった時間単位で測定されます。

RPOを60秒以下に設定することで、最大限の可用性を維持できます。こうすることで、プライマリソースに障害が発生しても、失われるデータは最大60秒分に抑えられます。

Redisが高可用性アーキテクチャで果たす役割

Redis Enterpriseは、最大限の可用性を目指す大規模企業にとって強力なソリューションです。リアルタイムデータプラットフォームとして、ハードウェア障害やクラウド停止のリスクを軽減しながら、5ナイン(99.999%)の可用性と高度な自動データベース耐障害性を提供します。

Redis Enterpriseは、最もミッションクリティカルなエンタープライズアプリケーションの高可用性要件を満たします。アクティブ/アクティブ地理分散、自動フェイルオーバー、インテリジェントクラスタリング、シェアードナッシングアーキテクチャ、グローバル分散といった業界最先端の機能により、99.999%の可用性を実現します。

高可用性の実現方法について詳しく知りたい方は、ぜひ関連資料をご確認ください。

  1. 誕生から13年――Redisには新しいアーキテクチャが必要なのか?

    Redisはインメモリデータストアの基盤となる技術であり、だからこそ、代替アーキテクチャが検討されることも少なくありません。数年前にはKeyDBがその話題を提起し、最近では新プロジェクト「Dragonfly」が「最速のRedis互換インメモリデータストア」であると主張しました。こうしたプロジェクトがもたらす興味深い技術やアイデアは、議論する価値があると私たちは考えています。Redis社としても、この種の挑戦は歓迎です。なぜなら、Redisが当初から掲げてきたアーキテクチャ設計原則(Salvatore Sanfilippo氏、通称antirezへの敬意を込めて)を再確認する機会になるからです。

  2. OELでの高可用性のためにOracleFormsandReportsをインストールおよび構成します

    このブログでは、Oracle®FormsandReportsバージョン12.2.1.3.0をOracle Enterprise Linux(OEL)バージョン7.2サーバーにインストールして構成し、高可用性を確保する方法を紹介します。 次の図は、高可用性モデルを示しています。 この高可用性モデルを使用するには、次のタスクを実行する必要があります。このブログで詳しく説明しています。 アプリケーションノード(node1およびnode2)にWebLogic®Serverバージョン12.2.1.3をインストールする準備をします。 JDK®1.8をインストールします。 WebLogicServ