リンク上のボトルネックの特定

「高可用性」の章で説明したように、OceanBaseデータベースのデータリンクはAPPServer <-> OBProxy <-> OBServerです。APPServerはデータベースドライバを介してODPに接続し、リクエストを送信します。OceanBaseデータベースの分散アーキテクチャにより、ユーザーデータは複数のパーティションとレプリカに分割され、複数のOBServerに分散配置されています。ODPはユーザーリクエストを最適なOBServerに転送して実行し、実行結果をユーザーに返します。各OBServerにもルーティング転送機能があり、リクエストが現在のノードで実行できない場合は、正しいOBServerに転送します。

エンドツーエンドのパフォーマンス問題が発生した場合（データベースシナリオでは、エンドツーエンドとはアプリケーションサーバー上でSQLリクエストのRTが非常に高いことを指します）、まずはデータベースアクセスリンク上のどのコンポーネントに問題があるかを特定し、その後でコンポーネント内部の具体的な問題を調査する必要があります。

一般的に、次の2つの調査手法があります：

• ドリルダウン調査法

  データアクセスの順序に従って、リンク上の各コンポーネントを順次調査し、そのコンポーネントが下流コンポーネントを呼び出す所要時間を観測します。そして、時間が明らかに異常（「所要時間ホットスポット」とも呼ばれる）な下流コンポーネントについてさらに調査します。本質的には「図に従って手がかりをたどる」（再帰法）アプローチであり、手がかりに従って段階的に掘り下げていくことで、根本原因となるコンポーネントに迫ります。

• 重点調査法

  過去の経験に基づいて、最も頻繁に異常が発生するコンポーネントを調査し、そのコンポーネントの主要なSLA指標を観測して異常があるかどうかを判断し、次に調査するコンポーネントを決定します。本質的には「除外法」（貪欲法）のアプローチであり、まず最も頻繁に異常が発生するコンポーネントを調査し、徐々に除外していくことで、根本原因となるコンポーネントに迫ります。

上記の図はデータベースアクセスリンクの簡略版です。注目すべき点は、上記の図で2つのコンポーネントがネットワークを介して相互にアクセスする場合、ネットワークもコンポーネントと見なすべきであるということです。2つのコンポーネント間のネットワークに異常が疑われる場合は、ネットワークリンク上の各レベルのスイッチを調査する必要があります。ODPのデプロイ形態によっては、特にVPC間やクラウド間を跨ぐネットワークアクセスにおいて、リンクが長い場合は、高度な注意を払う必要があります。

2つの調査手法に絶対的な優劣はなく、調査員は手持ちのツールの使い勝手と過去の調査経験に基づいて、最も効率的な手法を選択してください：

• 初めて本番環境に導入されるビジネスリンクの場合、例えば一部の企業がハイブリッドクラウドデプロイモードを採用し、一部のビジネスをオンプレミスデータセンターからパブリッククラウドに移行する場合、アクセスリンクがクラウドを跨ぐため、ドリルダウン調査法を選択するのが適しています。

• 成熟したビジネスリンクで、その中の一部のコンポーネントに変更があった場合、例えば大規模なプロモーションイベントやODPのアップグレードの場合、重点調査法を選択するのが適しています。

上記で紹介したシナリオに基づいて調査手法を選択する方法に加えて、エラーメッセージに基づいてボトルネックコンポーネントを正確に特定する方法もあります。この方法は、調査員の経験に大きく依存します。

一般的なエラースタックは上記の図のようになります。スタックは3層に分かれており、OBServerとODPについては詳述を割愛します。ここではアプリケーションサーバー部分について説明します。アプリケーションは通常、データミドルウェアを通じてアクセス認証、接続ウォームアップ、接続プール化といったデータベース接続を管理します。データミドルウェアは通常、パッケージ形式でアプリケーションに導入され、両者の実行ログは通常は分離されています。以下の文章では、アプリケーションとデータミドルウェアを区別せず、統一的にアプリケーション層と呼びます。

各層のコンポーネントのエラーは、自身の実行ログに出力されるだけでなく、上位層にスローされ、上位層のコンポーネントの実行ログにも出力されます。したがって、特定の層でエラーメッセージが発生した場合、まずそのエラーがどの層で発生したものかを分析する必要があります。その層のコンポーネントがスローしたエラーであれば、その層から調査を開始します。下位層のコンポーネントがスローしたエラーであれば、直接対象層で調査を行うことができます。

以下では、各層の一般的なエラーについて説明します。なお、各層のエラーはその層で発生するだけでなく、上位層にスローされ、上位層の実行ログにも現れる可能性があることをご留意ください：

• アプリケーションエラー

  • アプリケーションエラー「データベース接続プールがいっぱいです」

    このエラーはアプリケーションシステムで最も一般的なエラーの1つであり、アプリケーションシステムのデータベース接続プールがいっぱいで、新しいリクエストが接続を取得できないことを示しています。アプリケーションコードは通常、トランザクションを使用してデータベースにアクセスします。トランザクションでは、データベースへのアクセス以外に、他の下流システムへの呼び出しも行います。例えば、下流のアプリケーションシステムやキャッシュなどです。トランザクション開始時に接続プールから接続を取得し、トランザクション終了時に接続を接続プールに返却します。接続プールがいっぱいになるのは通常、トランザクションの所要時間が長すぎるためであり、トランザクションが長時間かかる原因を調査する必要があります。これは、データベースリクエストのRTが高いこと以外に、他の下流システムへのアクセス時間が長すぎる、アプリケーションシステム自体に問題があるなどの原因が考えられます。

    • 他の下流システムの所要時間が長すぎる：RPCを介して下流システムを呼び出す時間が長すぎるため、トランザクション全体の時間が長くなります。一方、データベースシステムへのアクセス所要時間は正常です。

    • アプリケーションシステム自体：アプリケーションシステム自体のfullgcやCPUがフル稼働することでシステムがフリーズし、トランザクション全体の時間が長くなります。一方、データシステムへのアクセス所要時間は正常です。

  • アプリケーションエラー「データベースへの接続に失敗しました」

    アプリケーションシステムがOBServerへの接続に失敗したことを示しています。これは、バックエンドのデータベースシステムがリクエストでフル稼働し、接続構築に失敗したことが原因である可能性があります。また、アプリケーションシステム自体の問題（例えば、fullgcが発生した場合、アプリケーションサーバーのNICに異常がある場合、アプリケーション層のデータベース設定が誤っている場合など）、またはアプリケーションサーバーとOBServer間のネットワーク異常などが原因である可能性もあります。

  • アプリケーションエラー「ロック競合」

    アプリケーションシステムが特定のデータベースオブジェクトにロックをかける際にロック競合イベントが発生したことを示しています。アプリケーションシステムは通常、ロックメカニズム（悲観的ロックまたは楽観的ロック）を使用して、同一オブジェクトへの同時アクセスを制御します。ロック競合は強いアプリケーションセマンティクスを持ち、データベースシステムのRTが高くなりすぎてアプリケーションシステムが大量にタイムアウトして再試行することが多いこと以外にも、アプリケーションシステム自体から原因を探る必要があります。例えば、スケジューリングシステムの異常により同一オブジェクトに対して大量の同時操作が行われたり、ある種のハッキング攻撃が行われることが原因である場合です。

• OBProxyエラー

  • OBProxyエラー ERROR 1317 (70100): Query execution was interrupted

    クライアントが積極的にクエリを中断したことを示しており、通常はクライアントが送信したSQLリクエストが想定されたタイムアウト時間内に返されなかった場合、またはユーザーが Ctrl + C を使用して積極的に Kill Query を実行した場合です。本番環境でこのエラーが大量に発生した場合、アプリケーション側面から見たSQLの所要時間がクライアントのタイムアウト時間（Query Timeout）を超えたことを意味しており、クライアントからOBserverまでの各コンポーネントを調査する必要があります。

• OBServerエラー

  • OBServerエラー ERROR 4012 (HY000): Timeout, query has reached the maximum query timeout

    SQLリクエストのOBServer内部処理時間がサーバー側のタイムアウト時間（ob_query_timeout）を超えたことを示しており、OBServer内部に異常があると直接特定できます。

    ob_query_timeout はSQLの最大実行時間を設定するために使用され、単位はマイクロ秒です。この変数の詳細については、ob_query_timeoutを参照してください。