ロードバランシングは、パフォーマンスチューニングにおいて頻繁に注目される情報であり、クラスタ内の物理サーバーのロードバランシングと業務トラフィックのロードバランシングの2つの側面が含まれます。良好なロードバランシング状態は、ソフトウェアおよびハードウェア環境を最大限に活用し、パフォーマンスを最適化することができます。負荷テスト中は、クラスタ内の各OBServerのリソース使用率、すなわちCPU、I/O、Loadなどのパラメータに注目する必要があります。本記事では主に、クラスタのデプロイメントやリソースの分散などの観点から簡潔に説明します。
クラスタのデプロイ
クラスタのデプロイについては、場所、レイテンシ、帯域幅などの情報を収集する必要があります。
場所
場所情報は非常に重要です。IDCやデプロイ方法などの重要な情報は、SQLルーティングの転送、トランザクションモデル、パフォーマンスに影響します。以下の点が含まれます：
デプロイ方法：同一リージョン内の3データセンター、2リージョン3データセンター、3リージョン5データセンター、その他のデプロイ方法。
OBProxyなどのミドルウェアの場所：クライアント側にデプロイするか、Observerと混在させるか？デプロイ方法によって、パフォーマンスに一定の影響があります。
アプリケーションサーバーおよびその他のミドルウェアの場所。
クラスタの各Zoneがどのデータセンターに配置されているか、データセンターがある都市、IDC設定に関するSQLステートメントは以下のとおりです：
obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_ZONES;
クエリ結果は次のとおりです：
+-------+----------------------------+----------------------------+--------+------+----------------+-----------+
| ZONE | CREATE_TIME | MODIFY_TIME | STATUS | IDC | REGION | TYPE |
+-------+----------------------------+----------------------------+--------+------+----------------+-----------+
| zone1 | 2025-12-29 15:43:43.200680 | 2025-12-29 15:43:43.200680 | ACTIVE | | default_region | ReadWrite |
+-------+----------------------------+----------------------------+--------+------+----------------+-----------+
1 row in set
レイテンシ
レイテンシ情報を使用して、単一のSQLのrtが期待通りであるかどうかを評価できます。クラスタ全体の具体的なレイテンシ情報は以下のとおりです：
データセンター間のレイテンシ
Zone間のレイテンシ
OBProxyからOBServerへのレイテンシ
クライアントからOBProxyへのレイテンシ
帯域幅
以下のコンポーネントの帯域幅を確認する必要があります：
OBProxyが配置されているマシンのNIC帯域幅。
アプリケーションサーバーのNIC帯域幅。
OBServerのNICおよびディスクI/O帯域幅。
この情報は、ping、tsar、ethtool xxx、ifconfigなどのコマンドを実行することで取得できます。以下の説明では、同一リージョン内の3データセンター、3レプリカFFFデプロイを例にします。
リソースの分布
テナントのリソース分布を把握し、その後のパフォーマンス診断に備えます。
テナントの基本情報
プライマリゾーン、ローカリティなどが含まれます。関連するSQLは以下のとおりです：
obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_TENANTS LIMIT 1\G
クエリ結果は次のとおりです：
*************************** 1. row ***************************
TENANT_ID: 1
TENANT_NAME: sys
TENANT_TYPE: SYS
CREATE_TIME: 2025-12-29 15:43:42.930290
MODIFY_TIME: 2025-12-29 15:43:42.930290
PRIMARY_ZONE: RANDOM
LOCALITY: FULL{1}@zone1
PREVIOUS_LOCALITY: NULL
COMPATIBILITY_MODE: MYSQL
STATUS: NORMAL
IN_RECYCLEBIN: NO
LOCKED: NO
TENANT_ROLE: PRIMARY
SWITCHOVER_STATUS: NORMAL
SWITCHOVER_EPOCH: 0
SYNC_SCN: NULL
REPLAYABLE_SCN: NULL
READABLE_SCN: NULL
RECOVERY_UNTIL_SCN: NULL
LOG_MODE: NOARCHIVELOG
ARBITRATION_SERVICE_STATUS: DISABLED
UNIT_NUM: 1
ZONE_UNIT_NUM_LIST: zone1:1
COMPATIBLE: 4.4.2.0
MAX_LS_ID: 1001
RESTORE_DATA_MODE: NORMAL
FLASHBACK_LOG_SCN: NULL
COMMENT: system tenant
1 row in set
リソース割り当て情報
関連SQLは以下のとおりです：
obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.GV$OB_UNITS LIMIT 1\G
クエリ結果は次のとおりです：
*************************** 1. row ***************************
SVR_IP: 172.xx.xxx.xxx
SVR_PORT: 2882
UNIT_ID: 1
TENANT_ID: 1
ZONE: zone1
ZONE_TYPE: ReadWrite
REGION: default_region
MAX_CPU: 4
MIN_CPU: 4
MEMORY_SIZE: 5368709120
MAX_IOPS: 9223372036854775807
MIN_IOPS: 9223372036854775807
IOPS_WEIGHT: 4
MAX_NET_BANDWIDTH: 9223372036854775807
NET_BANDWIDTH_WEIGHT: 4
LOG_DISK_SIZE: 9663676416
LOG_DISK_IN_USE: 3497610993
DATA_DISK_SIZE: NULL
DATA_DISK_IN_USE: 216748032
STATUS: NORMAL
CREATE_TIME: 2025-12-29 15:43:38.947558
REPLICA_TYPE: FULL
1 row in set
シングルマシンユーザーパーティションの総数とリーダーの分布
obclient [oceanbase]> SELECT svr_ip,count(1) FROM oceanbase.__all_virtual_ls_meta_table WHERE tenant_id=1002 GROUP BY svr_ip;
クエリ結果は次のとおりです：
+---------------+----------+
| svr_ip | count(1) |
+---------------+----------+
| 10.10.10.1 | 1 |
| 10.10.10.2 | 1 |
| 10.10.10.3 | 1 |
+---------------+----------+
3 rows in set
リーダーの分布状況：
obclient [oceanbase]> SELECT svr_ip,count(1) FROM oceanbase.__all_virtual_ls_meta_table WHERE tenant_id=1001 and role=1 GROUP BY svr_ip;
クエリ結果は次のとおりです：
+---------------+----------+
| svr_ip | count(1) |
+---------------+----------+
| 10.10.10.1 | 5 |
+---------------+----------+
1 row in set
その他
アプリケーションサーバーからOBServerアプリケーションサーバーへのリクエスト経路上にあるすべてのコンポーネントは、注目すべきポイントです。どこか一箇所がボトルネックとなると、パフォーマンスに大きな影響を及ぼす可能性があります。以下の点に注意する必要があります：
物理リソース：中間経路の各コンポーネントのリソースがボトルネックに達していないかどうか。例：JVMメモリ、アプリケーションサーバーおよびOBProxyのCPU使用率、ソフトインタラプト。
リクエストルーティング：OBProxyがSQLリクエストを正しくルーティングできているかどうか、誤った転送が発生していないかどうか。
接続プール：長い接続と短い接続の数、SocketTimeout設定。
トラフィックバランシング：各OBServerで受信・処理されるSQL数に著しい不均衡が生じていないかどうか。