# インスタンス固有のパフォーマンスとリソースのモニタリング
<a name="limitless-instance-monitoring"></a>

インスタンスレベルでのモニタリングは、接続スキュー、ワークロードスキュー、データスキュー、およびルーターや分割シャードを追加して、レイテンシーを保持しながらスループットを向上させるタイミングを理解する上で重要です。

## 概要
<a name="limitless-instance-monitoring-overview"></a>

アプリケーションがクエリを発行すると、そのリクエストは結果を返す前に高度な分散システムをトラバースします。一見シンプルな `SELECT` ステートメントは、複数のデータベースインスタンスに影響を与える可能性があり、それぞれがリクエストの処理で異なる役割を果たします。このジャーニーとその基盤となるインスタンスを理解することで、アプリケーションの設計方法、モニタリングデータの解釈方法、パフォーマンスの問題の診断方法が変わります。

このガイドでは、インスタンスアーキテクチャに関する詳細な技術的インサイトを提供します。
+ Limitless Architecture のリフレッシャー、ルーター、シャード
+ パフォーマンスと容量の要件を満たすように各インスタンスタイプをスケールするタイミングと方法
+ インスタンスレベルのパフォーマンスをモニタリング、トラブルシューティング、最適化する方法
+ 分散アーキテクチャを効果的に活用するアプリケーション設計のベストプラクティス

## インスタンスアーキテクチャの基礎
<a name="limitless-instance-monitoring-architecture"></a>

 次の 2 つの特殊なインスタンスタイプ間の機能分離を通じて水平方向のスケーラビリティを実現します。
+ **ルーターインスタンス**は、オーケストレーションレイヤーを提供します。クライアント接続の受け入れ、クエリの分析、分散オペレーションの調整、結果の集計を行います。ルーターはステートレスで、データを保存せず、データ移行なしで追加または削除できます。
+ **シャードインスタンス**は、データとコンピューティングレイヤーを提供します。テーブルデータの保存、ローカルデータに対するクエリの実行、トランザクションの処理を行います。シャードはステートフルで、それぞれが一貫したハッシュによって決定されるデータの特定のサブセットを所有しています。

この分離により、ワークロードの特性に基づいて接続処理、クエリ調整、データストレージを個別にスケーリングできます。

### ルーターとシャードの比較
<a name="limitless-instance-monitoring-comparison"></a>


| 特性 | ルーターインスタンス | シャードインスタンス | 
| --- | --- | --- | 
| プライマリロール | クエリの調整と配布 | データストレージとクエリの実行 | 
| State | ステートレス (データストレージなし) | ステートフル (データを所有) | 
| スケーラビリティ | すぐに追加/削除する | データの再分散が必要 | 
| リソースフォーカス | 調整用の CPU、中程度のメモリ | クエリ用の CPU、キャッシュ用のハイメモリ | 
| スケーリングトリガー | 高い接続数、分散 txn レート | CPU、データ量、クエリスループットが高い | 

## インスタンスパフォーマンスの監視
<a name="limitless-instance-monitoring-performance"></a>

インスタンスレベルのパフォーマンスを理解することは、効果的な運用に不可欠です。インスタンス固有のモニタリングにより、接続スキュー、ワークロードスキュー、データスキューなど、パフォーマンスに影響する分散パターンが明らかになります。

### スキューの検出
<a name="limitless-instance-monitoring-skew"></a>

理想的なデプロイでは、ワークロードとリソースはインスタンス間で均等に分散されます。実際には、アプリケーションは多くの場合、特定のインスタンスに負荷を集中させる分散の不均等な偏りを経験します。

モニタリングする 3 種類のスキュー
+ **接続スキュー**: ルーター間のクライアント接続の不均等な分散
+ **ワークロードスキュー**: ホットシャードキーによるシャード間のクエリ負荷の不均等
+ **データスキュー**: シャードキーの頻度によるシャード間でのデータ量の不均等

### Database Insights の負荷分散
<a name="limitless-instance-monitoring-insights"></a>

インスタンスレベルのヘルスを評価する最も手軽な方法は、Database Insights の負荷分散ビューです。これにより、インスタンス間でアクティブセッションがどのように分散されるかをすぐに確認できます。

負荷分散にアクセスするには

1. RDS コンソール → Limitless クラスターに移動する

1. 「Performance Insights」タブを選択する

1. 「負荷分散」セクションをクリックします。

**正常なパターン:** インスタンス間で比較的均等に負荷が分散されている
+ ルーターはシャードよりもわずかに高い AAS を示す場合があります (調整オーバーヘッド)
+ 互いに 20% 以内のシャード AAS 値はバランスが良いことを示します

**懸念されるパターン:** 特定のインスタンスにかなり集中している
+ ルーター負荷が > 70% のルーターが 1 つ→ 接続スキュー
+ シャード負荷が > 50% のシャードが 1 つ → ワークロードまたはデータスキュー
+ シャード間の大きなばらつき → シャードキー分散を調査

### CloudWatch メトリクス
<a name="limitless-instance-monitoring-cloudwatch"></a>

Database Insights 以外の詳細な分析のために、CloudWatch はリソース使用率パターンを明らかにするインスタンス固有のメトリクスを提供します。

ディメンション `DBShardGroupInstance` を持つ `ServerlessDatabaseCapacity` メトリクスは、インスタンスあたりの ACU 消費量を示し、リソース使用率の最も直接的なビューを提供します。

**調査のタイミング:**
+ ルーター ACU 分散 > 30% → 接続スキューまたはクロスシャードワークロードの集中
+ シャード ACU 分散 > 40% → データまたはワークロードのスキュー
+ すべてのインスタンスが一貫して最大 ACU → 容量の制約

## ルーターのモニタリングとトラブルシューティング
<a name="limitless-instance-monitoring-router"></a>

ルーターには、接続分散の不均等とクロスシャードワークロードの集中という 2 つの主な原因によるパフォーマンスの問題が発生する可能性があります。

### 不均等に分散されたセッション
<a name="limitless-instance-monitoring-router-connections"></a>

**症状:** 1 つのルーターが接続の不均衡な共有を処理する

**根本原因:** DNS キャッシュにより、複数の接続リクエストが同じルーターエンドポイントに解決されている。

**最も一般的なタイミング:**
+ pgbench などのツールを使用したベンチマーク
+ 接続プールの初期化 (多くの接続が迅速に確立されている)
+ アプリケーションサーバーの再起動

**対処法:**
+ コンソールで指定された Limitless エンドポイントを使用してください。
+ 手動バランシング: ルーターエンドポイントを抽出し、異なるアプリケーションを異なるルーターに接続する
+ libpq アプリケーションの場合、機能 `LOADBALANCEHOSTS` を使用します。
+ JDBC アプリケーションの場合、Limitless 接続プラグインを使用します。
+ NLB を使用してセッションとディストリビューションを管理する

## シャードのモニタリングとトラブルシューティング
<a name="limitless-instance-monitoring-shard"></a>

シャードには、リソースの制約、データスキュー、ワークロードスキューという 3 つの主な原因によるパフォーマンスの問題があります。

### シャードリソースの使用率
<a name="limitless-instance-monitoring-shard-utilization"></a>

一般的なシャードキーを持つシャードは、データがより多くなり、ワークロードが増加します。これはリソース使用率として表されます。つまり、インスタンスはより多くの ACU を消費します。

**修復戦略:**

1. **シャードキーの選択を再評価する:** シャードキーのカーディナリティとアクセスパターンを確認します。より良い分散のために複合シャードキーを検討してください。

1. **シャードを分割する:** より多くのシャードインスタンスに負荷を分散する

**シャードを分割する場合:**
+ 最大 ACU が一貫して > 80% の単一シャード
+ 単一のシャード容量によって制限されているクエリスループット

### シャードデータボリューム
<a name="limitless-instance-monitoring-shard-data"></a>

SQL 関数を使用してデータボリュームをクエリします。

```
SELECT subcluster_id, subcluster_type, pg_size_pretty(db_size) 
FROM rds_aurora.limitless_stat_database_size('postgres_limitless') 
ORDER BY 1;
```

テーブルごとおよびシャードごとのデータを表示するには

```
SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public', 'table_name');
```

### 不均等な使用率の解決
<a name="limitless-instance-monitoring-shard-split"></a>

ワークロードまたはデータスキューが特定のシャードに集中する場合、シャードを分割すると、より多くのインスタンスに負荷が再分散されます。

重要な考慮事項:
+ 移動するシャードキーを制御できない
+ 分割前に作成された手動スナップショットに復元せずに分割を元に戻す方法はありません
+ 新しいシャードを含むすべてのインスタンスは、アイドル時にインスタンスの最小 ACU を消費します。

シャードを分割するとさらなるスケーリングが可能になり、連続するシャード分割は、低レイテンシーを維持しながら、より高いスループットとさらなるスケーリングへの方法です。

## 制限事項
<a name="limitless-instance-monitoring-limitations"></a>

次の運用上の制約に注意してください。

**ルーターの制限事項**
+ **ルーターは削除できません** - 追加すると、ルーターはクラスターに残ります
+ 不要なベースラインコストを避けるためにルーターの追加は慎重に計画します

**シャードの制限**
+ **シャードをマージできません** - シャードの分割は一方向の操作です
+ 復旧オプションのみ: 分割前に取得したスナップショットからの復元

**緩和戦略:**
+ 有効な最小インスタンス数から開始する
+ 必要に応じて容量を段階的に追加する
+ 主要なトポロジが変更される前にスナップショットを作成する
+ クラスターの増加に応じてベースラインコストをモニタリングする