法律上の注意点
Copyright © 2011, 2012, 2013, 2014, 2015 Oracle and/or its affiliates.All rights reserved.
このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。
ここに記載された情報は予告なしに変更される場合がありますまた、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。
このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.
このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。
OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、他社の商標の可能性があります。
Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。
このソフトウェアまたはハードウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。
5/18/2015
目次
Oracle NoSQL Databaseは、スケーラビリティおよびパフォーマンスに関する非常に大きな利点を提供するデータ・ストレージ製品です。重要なのは、Oracle NoSQL Databaseが優れた可用性メカニズムも提供することです。これらのメカニズムは、ローカライズされたハードウェアやネットワークの障害時に、ストアに含まれるデータへのアクセスをアプリケーションに与えることを目的として設計されています。
このドキュメントでは、データの可用性を確実にするためにOracle NoSQL Databaseで使用されるメカニズムについて説明しています。Oracle NoSQL Databaseによって採用される様々なフェイルオーバー・アルゴリズムが、ここで説明されます。さらに、このドキュメントでは、Oracle NoSQL Databaseの可用性メカニズムを最大限に活用するために使用できるアプリケーション設計パターンについて説明します。データの可用性を高く保つことと、可能な最高のパフォーマンスを達成することの間には、トレードオフが存在する場合もあります。このドキュメントでは、このトレードオフについても述べます。
このドキュメントの対象読者は、Oracle NoSQL Databaseの使用に際してデータ可用性に関する概念および問題を理解する必要があるシステム・アーキテクトまたはエンジニアです。さらに、Oracle NoSQL Databaseストアと対話するコードを作成する責任があるソフトウェア・エンジニアも、このドキュメントを読む必要があります。
このドキュメントの対象読者は、『Oracle NoSQL Database Table APIスタート・ガイド』または『Oracle NoSQL Database Key/Value APIスタート・ガイド』を読んで理解している方を想定しています。これらのマニュアルのいずれもまだお読みになっていない場合は、このドキュメントを続けて読む前にお読みください。特に、次の場所で説明されている概念を理解しておく必要があります。
基本的に、Oracle NoSQL Databaseは、単一マスター・レプリケーション・ストラテジを使用してデータの永続性および可用性を確保しています。つまり、単一マシンを使用して、書込み操作を行い、それらの操作を複数の読取り専用レプリカにブロードキャストします。
『Oracle NoSQL Database概要マニュアル』で説明されているように、シャードは、単一のマスターおよび複数のレプリカを持つレプリケーション・ノードの集まりです。ストアには複数のシャードが含まれ、データは、ストアが使用中のすべてのシャードに均一に分散しています。
ストアで書込み操作を実行すると、その書込み操作は、データを含むシャードが使用しているマスター・レプリケーション・ノードで実行されます。マスターは、そのときに永続性保証がどのように設定されている場合でも、それに応じてこの書込みを実行します。永続性保証を十分に高く設定している場合、マスターが書込みを実行するには、シャード内の一部またはすべてのレプリカの参加が必要とされます。
また、なんらかの理由(ネットワークまたはハードウェアの停止など)でマスターが使用不可になった場合、プライマリ・ゾーンにあるレプリカは、残りのどのノードがマスターを引き継ぐかを決定するために選出を行います。最新のデータを持つノードが選出されます。
選出は、単純過半数票に基づいて決定されます。これは、新しいマスターを選択するためには、プライマリ・ゾーンにあるシャード内の過半数のノードが選出に参加できる必要があることを意味します。
最もささいなフェイルオーバーのケースは、レプリカが実行されているマシンの問題によって、そのレプリカが失われる場合です。この欠落は、ハード・ドライブの障害と同じくらい一般的なことによって引き起こされます。
この場合は、そのレプリカを使用しているシャードのみが影響を受けます。デフォルトでは、シャードへの影響として、読取りスループットのキャパシティが1つ減少します。シャード自体は、通常の操作を続行できます。ただし、1台のレプリケーション・ノードを失ったため、読取りリクエストのサービスのためのキャパシティが、1台のホスト・マシンがストアに提供する読取りスループットの分だけ減少します。この読取りスループット・キャパシティの減少に気が付くかどうかは、シャードの読取り負荷の大きさによります。シャードの読取り負荷が低いために、レプリカの欠落によるパフォーマンス・ヒットにまったく気付かない場合もあります。
前の段落では1台のホスト・マシンにレプリケーション・ノードが1つのみ含まれると仮定していることに注意してください。複数のレプリケーション・ノードが単一マシン上で実行されるようにストアを構成した場合、それに応じてスループット・キャパシティへの影響は倍増します。複数のレプリケーション・ノードを実行するマシンが欠落すると、そのマシン上のすべてのレプリケーション・ノードが同じシャードに属するとは考えにくいため、2つ以上のシャードのスループット・キャパシティに影響を与える可能性があります。また、ストレージ・ノードの欠落による実際のパフォーマンス・ヒットに気が付くかどうかは、影響を受けた個別のシャードの読取り負荷の大きさによります。
このシナリオでは、1つの例外を除いてシャードは書込みリクエストのサービスを続行します。また、書込みスループット・キャパシティの変化なしに、それを行うことができる場合もあります。マスター自体は影響されず、書込みを実行し、シャード内の残りのレプリカにそれらをレプリケートすることを継続できます。ただし、次の場合は書込みスループット・キャパシティが減少する可能性があります:
シャードの読取り負荷が大きすぎるために、1つのレプリカの欠落が残りのレプリカを飽和状態にする場合
マスターが、書込みコミットの終了前に受信確認を要求する場合。
このシナリオでは、マスターがレプリカによるコミットの受信確認を待ち続けているか、マスター自体が読取りリクエストに応答してリソースを消費しているために、書込みパフォーマンス・キャパシティが減少する場合があります。どちらの場合も書込みスループットが低下しますが、その程度は、シャードの実際の読取り/書込み負荷の大きさによって異なります。ここでも、シャードの書込み負荷が小さいために、書込みスループットの実際の減少にまったく気が付かない可能性があります。
さらに、単一の読取り専用レプリカが欠落すると、そのシャードでのすべての書込み操作がDurabilityException例外で失敗する可能性があります。これは、プライマリ・ゾーンにあるシャード内のすべてのレプリカからの受信確認を必要とする永続性保証を使用している場合に発生します。この場合、そのレプリカがオンラインに戻るまで、または使用する永続性保証を低くするまでは、そのシャードでの書込みが失敗します。
プライマリ・ゾーンにあるすべてのレプリカからの受信確認を必要とする永続性保証の場合、(書込みがシャード内のすべてのマシンに確実にレプリケートされるようにすることによって)使用できる最も高いデータ永続性が提供されます。しかし、同時に、ハードウェア単体の障害によって、シャード全体の書込み機能が失われる可能性があります。そのため、可用性要件に対して永続性要件のバランスをとり、それに応じてストアおよび関連コードを構成する必要があります。
シャードのマスターが含まれるホスト・マシンが欠落した場合、一瞬の間(クライアント・コードによって意識されないほどであることがあります)、そのシャードは書込みリクエストに応答できなくなります。マスターが含まれるシャードのみがこの停止によって影響を受け、他のすべてのシャードは通常どおりに実行し続けることに注意してください。
この場合、プライマリ・ゾーンにあるシャードのレプリカは、マスターの欠落をすぐに認識して選出を求めます。一般的に、これはマスターが欠落してから数十ミリ秒以内に行われます。
次に選出が実行され、プライマリ・ゾーンにある最新のデータのセットを持つレプリカがマスターに選出されます。マスターに選出されるには、プライマリ・ゾーンでノードをホストするシャード内の他のマシンの単純過半数票が必要です。(この単純過半数の要件は、ストアから多くのマシンが失われた場合に影響するため、覚えておいてください。)
新しいマスターが選出されると、1台のマシンの分だけ読取りスループット・キャパシティが減少しますが、シャードは操作を続行します。単一のレプリカが欠落した場合と同様に(前述の項を参照)、永続性保証によってプライマリ・ゾーンにあるすべてのレプリカからの受信確認が要求されていないかぎり、すべての書込み操作を続行できます。
新しいマスターが選出され、書込み操作で使用されているタイムアウト値内に書込みリクエストがサービスされた場合、クライアント・コードによってマスターの欠落が認識されないことに注意してください。それでもなお、タイムアウト問題を防ぐように本番コードを作成する必要があります。タイムアウトが発生した場合に行う必要があることとして、コード用のポリシーを決定する必要があります。オプションには、書込み操作をすぐに再試行する、少し待機してから書込み操作を再試行する、または書込み操作を完全に中止することが含まれます。
ネットワーク・パーティションは、ネットワーキング・ギアの1つ(ルーターなど)が失敗したときに、1つのシャードを2つの別々の非通信ネットワークに分割するように発生します。ストアがこのような場合にどのように応答するかは、シャードのレプリケーション・ノードがネットワーク・パーティションによって分割される方法によって異なります。
最も単純なケースでは、単一のレプリケーション・ノードがシャードの残りのものから分離されます。レプリケーション・ノードが読取り専用レプリカである場合、単一マシンの欠落によって引き起こされる読取りスループット・キャパシティの減少はありますが、シャードは通常どおりに操作を続行します。詳細は、「読取り専用レプリカ・ノードの欠落」を参照してください。
単一のレプリケーション・ノードがマスターである場合、シャードは、マスターが欠落した場合と同様にそれを処理します: シャードは、新しいマスターを選択するために選出を行ってから、通常どおりに操作を続行します。詳細は、「読取り/書込みマスターの欠落」を参照してください。
ネットワーク・パーティションがシャードを2つ以上のマシン・グループに分割する場合、複雑になります。このシナリオでは、少なくとも1つの少数ノード・パーティションがあるとします。つまり、シャード内の過半数よりも少ないレプリケーション・ノードを含むパーティションです。また、過半数ノード・パーティション(シャード内のノードの過半数を含むパーティション)も存在する場合がありますが、特にパーティションがレプリケーション・ノードのセットを2つを超えて作成する場合は必ずしも存在しません。
このシナリオでのフェイルオーバーの処理方法は、過半数ノード・パーティションが存在するかどうか、およびマスターがそのパーティションに存在するかどうかによって異なります。パーティションが発生したときに使用されていた永続性および一貫性のポリシーと関係のある問題もあります。
シャードが2つのパーティションに分割されると仮定します。パーティションAには、マスターを含めて、プライマリ・ゾーンにあるレプリケーション・ノードの単純過半数が含まれます。パーティションBには残りのノードが含まれます。
パーティションAは、パーティションBにどれだけ多くのレプリケーション・ノードが含まれる場合でも、その欠落によって引き起こされる読取りスループットの減少はありますが、通常どおりに読取りおよび書込みリクエストのサービスを続行します。プライマリ・ゾーンからのパーティションAに永続性ポリシーを満たす十分なレプリカがない場合に、そのとき使用されていた永続性ポリシーによって書込みが妨げられる可能性があることに注意してください。永続性ポリシーによって単純過半数またはそれ未満のレプリカが要求されているかぎり、シャードは書込みリクエストをサービスできます。
パーティションBは、次第にデータが古くなりますが、読取りリクエストのサービスを通常どおりに続行します。パーティションBは、設定されている一貫性保証に応じて、読取りリクエストのサービスを停止する場合があります。バージョンに基づいた一貫性が使用されている場合、マスターからバージョン・トークンを取得できないために、パーティションが発生するとすぐにパーティションBでConsistencyException例外が発生する可能性があります。同様に、時間に基づいた一貫性ポリシーが使用されている場合、レプリカがマスターよりも遅れすぎる(そこからは書込み更新を受け取らなくなる)とすぐにConsistencyException例外が発生します。デフォルトでは、読取りリクエストにサービスするために一貫性保証は必要でないことに注意してください。そのため、一貫性ポリシーを明示的に作成して使用していないかぎり、パーティションBはネットワーク全体が停止しても読取りリクエストのサービスを続行します。
パーティションBは、新しいマスターを選出しようとしますが、選出を行うのに必要なレプリケーション・ノードの単純過半数が含まれていないため、選出できません。
さらに、クライアント・コードがパーティションAには到達できるがパーティションBには到達できないようなパーティションである場合、読取りキャパシティは減少しますが、シャードは読取りおよび書込みリクエストのサービスを通常どおりに続行します。
ただし、クライアント・コードがパーティションBを読み取れるがパーティションAを読み取れないようなパーティションである場合、シャードは書込みリクエストをまったくサービスできません。これは、パーティションAにマスターが含まれ、パーティションBには新しいマスターの選出に十分な数のレプリケーション・ノードが含まれていないためです。
シャードが2つのパーティションに分割されると仮定します。パーティションAには、プライマリ・ゾーンからのレプリケーション・ノードの単純過半数が含まれていますが、マスターは含まれていません。パーティションBには、マスターを含めて、残りのノードが含まれています。
両方のパーティションが、クライアント・コードによってネットワーク・アクセス可能であると仮定します。
パーティションAは、マスターがないことを認識します。パーティションAにはプライマリ・ゾーンにあるレプリケーション・ノードの少なくとも単純過半数が含まれるため、新しいマスターを選出できます。それはすぐに行われるため、シャードは通常どおりに操作を続行します。
パーティションAが書込みリクエストをサービスできるかどうかは、使用されている永続性ポリシーによって決まります。永続性ポリシーによって単純過半数またはそれ未満のレプリカが要求されているかぎり、シャードは書込みリクエストをサービスできます。
パーティションBは、有効なマスターが含まれていると信じて通常どおりに操作を続行します。しかし、パーティションBが書込みリクエストをサービスできるのは、使用している永続性ポリシーによってシャードのレプリカからの参加が要求されない場合のみです。プライマリ・ゾーンにあるノードの過半数が書込み操作を受信確認する必要がある場合、またはプライマリ・ゾーンにあるすべてのノードが受信確認する必要がある場合、永続性ポリシーを満たすのに十分な数のノードがないためにパーティションは書込みをサービスできません。
永続性の「NONE」が使用されている場合、ネットワーク・パーティションを解決するまでの間、シャードは2つのマスターで動作します。パーティションが解決されると、シャードは問題を認識して修正します。パーティションAが有効な選出を行ったため、そこで実行された書込みは保持されます。パーティションBで実行された書込みは破棄されます。パーティションBの古いマスターは単純なレプリカに降格され、パーティションBのすべてのレプリカが新しいマスターと同期されます。
このシナリオではデータが失われる可能性があるため、永続性の「NONE」を使用しないことを強くお薦めします。書込みスループットを絶対に最大にする必要があり、データの損失をまったく気にしないときのみ、その永続性設定を使用します。
さらに、クライアント・コードがパーティションAには到達できるがパーティションBには到達できないようなパーティションである場合、選出が行われた後のみ、読取りキャパシティは減少しますが、シャードは読取りおよび書込みリクエストのサービスを通常どおりに続行します。
ただし、クライアント・コードがパーティションBを読み取れるがパーティションAを読み取れないようなパーティションである場合、使用できる最も低い永続性ポリシーを使用しないかぎり、シャードは書込みリクエストをまったくサービスできません。これは、使用できる最も低い永続性ポリシー以外を満たすのに十分な数のレプリケーション・ノードがパーティションBに含まれていないためです。
シャード内のレプリケーション・ノードの過半数を含むパーティションがないような複数のパーティションにシャードを分割したと仮定します。この場合、シャードのパーティションは、読取りについて使用中の一貫性ポリシーによってサポートされているかぎり、読取りリクエストをサービスできます。読取りによって要求されるマスターとの一貫性が厳しいものであり、一貫性が満たされることがマスターによって確認できない場合、読取りは失敗します。
マスターを含むパーティションは、使用できる最も低い永続性ポリシー(つまり、レプリカからの受信確認を要求しないポリシー)を使用している場合のみ、書込みリクエストをサービスできます。受信確認が必要な場合は、永続性ポリシーを満たすのに十分な数のレプリカがないため、書込みは発生することができません。
ネットワーク・パーティションが解決されると、シャードは新しいマスターを選出してすべてのレプリカをそれと同期してから、通常どおりに操作を続行します。
ゾーンを使用すると、複数の物理的なインストール場所にまたがってストアを展開させることができます。近くに存在する物理的に別々の建物や、同じ建物内の別のラックまで、様々な場所が考えられます。基本的な考え方は、ストア内のノードを物理的に可能なかぎり離して配置することによって、停電や嵐による被害などの大規模なインフラの中断を防ぐことができるということです。
Oracle NoSQL Databaseでは2種類のゾーンがサポートされています。プライマリ・ゾーンには、マスターまたはレプリカとして機能できるノードが含まれます。デフォルトでは、ゾーンはプライマリ・ゾーンとして作成されます。セカンダリ・ゾーンには、レプリカとしてのみ機能できるノードが含まれます。セカンダリ・ゾーンは、離れた場所で利用可能なデータのコピーを作成するため、またはデータの追加コピーを保持して冗長性または読取りキャパシティを増やすために使用できます。
どちらのゾーンにも、レプリカを最新の状態に保つために必要なレプリケーション・データを送信するための高スループットのネットワーク接続が必要です。十分なネットワーク・キャパシティを提供できないと、接続が不十分なゾーンに含まれるノードはますます遅れます。低スループットのネットワーク接続によって接続された場所は、ゾーンでの使用に適していません。
プライマリ・ゾーンの場合、他のプライマリ・ゾーンとのネットワーク接続で、ネットワークのスループットに加えて、信頼性が高く待機時間が短い通信を提供する必要があります。これらの機能により、マスター選出を実行して迅速なマスター・フェイルオーバーを実現し、書込みリクエストのタイムアウト要件を満たす受信確認を提供できます。したがって、プライマリ・ゾーンは、信頼性の低いまたは低速のWide Area Networkでの使用に適していません。
セカンダリ・ゾーンの場合、セカンダリ・ゾーン内にあるノードはマスターの選出または受信確認に関与しません。そのため、システムでは、セカンダリ・ゾーンとプライマリ・ゾーン間の接続の信頼性低下または待機時間の増加を許容できます。ネットワーク接続では、レプリケーションをサポートするために十分なスループットを引き続き提供する必要があり、一時的な中断によってネットワークのスループットが損なわれることがないように十分な信頼性を提供する必要があります。
複数のゾーンにまたがってストアをデプロイした場合、Oracle NoSQL Databaseでは、各シャードから少なくとも1つのレプリケーション・ノードを各ゾーンに物理的に配置することが試みられます。Oracle NoSQL Databaseでこのようにできるかどうかは、ストア内で使用中のシャードの数、ゾーンの数、レプリケーション・ノードの数、および各ゾーンで使用可能な物理的なマシンの数によります。さらに、Oracle NoSQL Databaseでは、使用可能なゾーンにわたってレプリケーション・ノードを分散させるためのベストエフォートが行われます。そのようにすることによって、ゾーンがなんらかの理由で使用不可になった場合にシャード全体が失われることを防いでいます。
このドキュメントで前述したフェイルオーバーについてのすべての説明が、ゾーンにも適用されます。フェイルオーバーは、すべてのノードが単一のゾーンに含まれている場合と同様に、複数のゾーンにわたって動作します。ゾーンが提供するものは、大規模な停止が発生したときにデータを使用可能なままにできる機能です。ただし、指定されたシャードの読取りおよび書込み能力は、残りのゾーンが過半数ノード・パーティションを構成しているかどうか、およびストア・アクティビティに関する使用中の永続性ポリシーと一貫性ポリシーによって制御されることに変わりありません。
このドキュメント全体にわたって、ハードウェアやネットワークの障害発生時に永続性保証がシャードの書込み可用性に与える影響について説明してきました。要約:
シャードのレプリカからの受信確認を必要としない永続性保証の場合は、停止が発生したときにシャードが書込みリクエストのサービスを続行できる可能性が最も高くなります。ただし、この永続性保証の結果、シャードが2つのマスターで動作する可能性があり、ハードウェアの問題が解決されるとデータが失われることがあります。これは推奨される構成ではありません。
プライマリ・ゾーンの単純過半数のレプリカによる書込み操作の受信確認を必要とする永続性保証は、2つのマスターが同時に動作するという予想外の状況を防ぎます。しかし、これは、ハードウェアの障害によってこれらのレプリカの過半数よりも多くがオフラインになっている場合、シャードが書込みリクエストをサービスできなくなることも意味しています。
プライマリ・ゾーンにあるすべてのレプリカによる書込み操作の受信確認を必要とする永続性保証は、データ損失の可能性を防止します。しかし、これは、これらのレプリカのうち1つでもオフラインになっている場合、シャードが書込みリクエストをサービスできないことを意味します。
ほとんどすべての場合において、基礎にあるハードウェアが機能しているかぎり、レプリカは読取りリクエストのサービスを続行します。デフォルトの構成において、レプリカが壊滅的な障害の後に実行している唯一のノードである場合でも、そのレプリカがこのようにすることを妨げるものはありません。
しかし、使用中の一貫性ポリシーによってバージョン情報が要求される場合や、マスターよりも古いデータが許可されない場合は、ネットワーク障害時にレプリカが読取りリクエストのサービスを停止する可能性があります。このようになるかどうかは、障害の結果としてレプリケーション・ノードがパーティション化された方法、および新しいマスターが確立されるのに要した時間によります。レプリカが読取りリクエストをサービスできる可能性は、そのリクエストに対して使用されている一貫性ポリシーによっても制御されます。読取りによって要求されるマスターとの一貫性が厳しいものであり、一貫性が満たされることがマスターによって確認できない場合、読取りは失敗します。