Oracle RACの接続設計と負荷分散の仕組み|SCANリスナー・コネクションプール活用法

はじめに

本記事では、Oracle RAC環境でのデータベース接続と負荷分散の仕組みについて解説します。
Oracle RACは複数ノードでデータベースを共有し、高可用性とスケーラビリティを実現する仕組みです。まだ基本的な概念を理解していない方は、こちらの記事からご覧ください。
Oracle RACの仕組みを理解しよう ~ClusterwareおよびASMで実現する機能について~

ローカルリスナーを使用したデータベース接続

Oracle RAC環境での接続を理解する前に、まずはOracle RACを導入していない標準構成におけるデータベース接続の仕組みを確認します。ローカルリスナーは、Oracleインスタンス上で動作するプロセスで、クライアントとデータベース間の接続を仲介する役割を担います。
下図は、Oracle RAC未導入環境におけるデータベース接続の基本的な流れを示しています。

  1. クライアントのユーザプロセス(アプリケーション側の処理)が、データベースサーバ上のローカルリスナーに接続要求を送信します。
  2. ローカルリスナーは要求を受け、対応するサーバプロセスを起動します。
  3. 最終的に、ユーザプロセスとサーバプロセス間で接続が確立され、データベースへの通信が可能になります。

SCANリスナーを使用したデータベース接続

ここでは、Oracle RAC環境でのSCANリスナーを用いたデータベース接続の仕組みについて解説します。SCAN(Single Client Access Name)とは、クライアントからデータベースに接続する際に、単一の名前を指定できる仕組みです。言い換えると、DNSに登録する名前は1つだけで済むという点が特徴です。この仕組みにより、Oracle RACにノードを追加・削除しても、クライアント側の接続設定を変更する必要がありません
下図は、SCANリスナーを使用したクライアントからの接続フローを示しています。

  1. クライアントのユーザプロセス(アプリケーション側の処理)が、データベースサーバ上のSCANリスナーに接続要求を送信します。
  2. SCANリスナーは、負荷が低いノードで動作しているローカルリスナーにリダイレクトします。
  3. ローカルリスナーはサーバプロセスを起動します。
  4. ユーザプロセスとサーバプロセス間で接続が確立されます。

SCANリスナーの主な役割は、接続リクエストをローカルリスナーにリダイレクトすることです。SCANリスナーはリクエストを受け付けると、負荷が低いノードを識別し、そのノードが起動しているローカルリスナーに対してリダイレクトを行います。この仕組みはサーバ側接続ロードバランシングと呼ばれます。
なお、SCANリスナープロセスは最低3つ作成することが推奨されています。そのため、2ノード構成の場合でも、SCANプロセスは3つ作成するのが一般的です。

Oracle RACにおいてSCANリスナーを使用せずにローカルリスナーにリダイレクトも実施させるサーバ側接続ロードバランシングの仕組みもありますが、以下の理由によりSCANを適用することが推奨されています。

  • クラスタ構成変更(ノードの追加・削除)時に、クライアントおよびサーバ側の接続設定を変更する必要がない
  • サーバ側接続ロードバランシングが自動で適用される
  • 接続時のフェイルオーバが自動で適用される

Oracle RACにおけるノード障害時の挙動

Oracle RAC構成では、ノード障害が発生すると、該当ノードのSCANリスナープロセスおよびVIP(Virtual IP)が正常なノードにフェイルオーバします。
フェイルオーバ中はリクエストを受け付けられませんが、透過的アプリケーションフェイルオーバ(TAF)を使用すると、クライアントを自動的に正常なインスタンスに再接続できます。

  1. 障害が発生したノードのSCANリスナープロセスおよびVIPが、正常なノードにフェイルオーバする。
  2. クライアントはTAF機能により、正常なノードに自動的に再接続する。

ランタイム接続ロードバランシングによるノード間負荷の均一化

前述の通り、SCANを使用した接続ロードバランシングにより、クライアントとデータベース間のコネクションは均等に分散されます。
しかし、コネクションが均等に接続されるだけで、そのコネクションを利用したリクエスト(SQL実行数)が均等になるわけではありません。そのため、クライアントの利用状況によっては、ノード間でSQL実行数やリソース使用率に偏りが生じることがあります

多くの場合、コネクションプールを使用して一度確立したコネクションを使いまわすため、明示的にタイムアウト設定をしない限り、一度発生した偏りはメンテナンスや再接続まで継続してしまうことがあります。

こうした偏りを改善するために、「ランタイム接続ロードバランシング(Runtime Connection Load Balancing)」という機能が提供されています。本機能を使うことで、実際のリクエスト量やノード負荷に応じて、接続が動的に調整されます。

まず、コネクションプールを使用した処理の概要を示します。
クライアントからリクエストがあるたびに新しくコネクションを作成すると、性能が低下する可能性があります。そこで、一度確立したコネクションをプールして使いまわすのが、オンライン処理で一般的に用いられる仕組みです。

下図は、コネクションプールを適用した場合のリクエストの挙動を示しています。コネクションプール内のコネクションはすべてデータベースと接続済みですが、リクエストが発生した際に一部のコネクションが「Active」状態になり、処理に使用されます。残りのコネクションは待機状態となり、次のリクエストで再利用されます。

接続ロードバランシングにより、コネクション数はノード間で均一化されます。そのため、コネクションプールのコネクションが均等に使用されれば、各ノードで処理されるSQL実行数も均等になります。
しかし、使用されるコネクションに優先順位がある場合は注意が必要です。優先的に使用されるコネクションが特定のノードに偏ると、コネクション数は均等でも、SQL実行数やリソース使用率が偏ってしまう可能性があります。

この問題を解決し、ノード間のSQL実行数やリソース使用率の偏りを抑えるために有効なのが「ランタイム接続ロードバランシング」です。この仕組みでは、RACを構成する各インスタンスが負荷情報を算出し、クライアント側のコネクションプールに提供します。クライアントはこの情報をもとに、負荷の低いインスタンスに接続されているコネクションを優先的に使用することで、負荷の偏りを自動的に調整します。

下図の通り、コネクション数はInstance AとInstance Bで均一に分散されています。しかし、各インスタンスに対する負荷がInstance A 25%、Instance B 75%と偏っている場合を考えます。
このような状況では、「Oracle RACロード・バランシング・アドバイザ(RAC Load Balancing Advisor: LBA)」が各インスタンスの負荷状態を監視し、その情報をコネクションプールに提供します。
情報の連携には、「高速アプリケーション通知(Fast Application Notification: FAN)」という仕組みが用いられ、リアルタイムに負荷情報をクライアント側に伝達します。

クライアント側のコネクションプールが、RACインスタンスから送られた負荷情報を受信すると、負荷を均一化するように使用するコネクションを自動的に選択します。

ランタイム接続ロードバランシングの仕組みの解説は以上です。
この機能を利用するには、RAC対応のOracle純正JDBC Driverを使用する必要がありますので注意してください。

まとめ

本記事では、Oracle RAC環境におけるデータベース接続と負荷分散の仕組みについて解説しました。主なポイントは以下の通りです。

  • ローカルリスナーによる基本接続
    • クライアントの接続要求を受け、サーバプロセスを起動してユーザプロセスと接続を確立します。
  • SCANリスナーによる接続の簡略化とサーバ側ロードバランシング
    • 単一の名前(SCAN)で接続可能になり、ノード追加や削除時のクライアント設定変更が不要になります。
    • SCANリスナーは負荷の低いノードのローカルリスナーにリクエストをリダイレクトすることで、サーバ側ロードバランシングを実現します。
  • ノード障害時のフェイルオーバ
    • ノード障害が発生すると、SCANリスナープロセスやVIPが正常ノードにフェイルオーバします。
    • TAF(透過的アプリケーションフェイルオーバ)により、クライアントは自動的に正常なノードへ再接続されます。
  • ランタイム接続ロードバランシングによる負荷均一化
    • コネクションプールを利用した接続時、SQL実行数やリソース使用率が偏る場合があります。
    • RAC Load Balancing Advisor(LBA)とFANを通じて各ノードの負荷情報をコネクションプールに連携し、負荷の低いインスタンスのコネクションを優先的に使用することで、ノード間の負荷偏りを自動的に調整します。
    • この機能を利用するには、RAC対応のOracle純正JDBC Driverが必要です。

Oracle RACでは、これらの仕組みを組み合わせることで、高可用性を維持しつつ、ノード間の負荷を効率的に分散することが可能になります。

他にもOracle関連の記事をいくつか書いてますので、そちらもぜひご参照ください。
Oracle RACの仕組みを理解しよう ~ClusterwareおよびASMで実現する機能について~
【Oracle】メモリ/ファイルアーキテクチャおよび管理方法についてまとめてみた。

参考文献

Oracle RACについて
https://www.oracle.com/technetwork/jp/ondemand/db-technique/b-3-rac-1484714-ja.pdf

Oracle Net Serviceについて
https://speakerdeck.com/oracle4engineer/oracle-database-oracle-net-services

SCANリスナーについて
https://www.oracle.com/jp/a/tech/docs/database/scan-ja.pdf

ランタイム接続ロードバランシングについて
https://jpn.nec.com/soft/oracle/files/gc_wp-gridlink-gridcenter-nec.pdf

コメント