モニタリング・ダッシュボードへのアクセス

1. IBM Cloud コンソールで MongoDB デプロイメントに移動します。
2. 左ナビゲーションの 「モニタリング 」をクリックします。
3. Launch Monitoringをクリックして、Sysdigダッシュボードを開きます。

追跡すべき主な指標

• プラットフォームの指標：

  • CPU使用率- 目標：持続75%未満
  • ディスク使用率- 目標：< 80
  • ディスクIOPS- 飽和の監視
  • ネットワークのスループット- 帯域幅の制約を特定する

• MongoDB-specific を測定する：

  • 1秒あたりのオペレーション- ワークロードパターンの追跡
  • アクティブな接続-プランの制限に対する監視
  • レプリケーション・ラグ- ターゲット：1秒未満
  • クエリ実行時間- 時間のかかるクエリを特定
  • キャッシュヒット率- 目標> 95%

アラートのセットアップ

重要な閾値に対するアラートを作成します：

Alert: High CPU Usage
Condition: CPU > 80% for 10 minutes
Action: Notify operations team

Alert: Replication Lag
Condition: Replication lag > 5 seconds
Action: Page on-call engineer

Alert: Disk Space
Condition: Disk usage > 85%
Action: Trigger scaling workflow

カスタム・ダッシュボードの作成

1. Sysdig で、[ ダッシュボード ] > [ ダッシュボードの作成 ] をクリックします。
2. 主要指標のパネルを追加する。
3. フィルタを使用して、 MongoDB 配置に焦点を絞ります。
4. 保存してチームで共有

ダッシュボードのレイアウト例

• 1行目 ：CPU、メモリ、ディスクの使用率
• 行2 ：1秒当たりのオペレーション、アクティブな接続
• 第3行 ：レプリケーション・ラグ、クエリー・パフォーマンス
• 行4 ：キャッシュ統計、ロック競合

歴史的分析

• ヒストリカルデータには時間範囲セレクタを使用
• 現在の指標を基準値と比較する
• トレンドとパターンを特定する
• イベントとパフォーマンスの変化を関連付ける

推奨される行動

• 問題が発生する前にアラートを設定
• ダッシュボードを毎日見直す。
• ベースライン指標を確立する。
• 異常パターンと比較した正常パターンを記録する。
• キャパシティ・プランニングにメトリクスを使用する。

アクセス Activity Tracker

1. コンソールの Observability > に移動する。 Activity TrackerIBM Cloud に移動する。
2. リージョンを選択します。
3. MongoDB インスタンスでイベントをフィルタリングします。

監視すべき主なイベント

• コンフィギュレーションの変更：

  • スケーリング操作（CPU、メモリ、ディスク）
  • バックアップ設定の変更
  • ネットワーク設定の更新
  • ユーザーアクセスの変更

• パフォーマンスに影響する出来事

  • データベースの再起動
  • フェイルオーバー・イベント
  • 保守操作
  • インデックスの作成と削除

イベントとパフォーマンス問題の関連性

1. パフォーマンス低下のタイムスタンプに注意。
2. Activity Tracker、その時間帯のイベントを検索する。
3. コンフィギュレーションの変更または管理上のアクションを探す。
4. モニタリング・メトリクスと関連付ける。

イベント分析例

Event: Database scaled from 2GB to 4GB RAM
Time: 2024-01-15 14:30:00 UTC
Impact: Temporary connection disruption (30 seconds)
Result: Improved performance after scaling

コンプライアンスのための監査証跡

• 誰がいつ変更したかを追跡
• セキュリティポリシーの遵守を維持する
• アクセスパターンの見直し
• 不正な変更を特定する

推奨される行動

• Activity Tracker ログを定期的に見直す。
• 重要なイベントに対するアラートを設定します。
• 変更管理手順を文書化する。
• イベントをパフォーマンス・メトリクスと関連付ける。
• 事故後の分析に使用する。

垂直スケーリング（コンピュートとメモリー）

CPUとメモリのリソースを拡張して、作業負荷の増加に対応。

• IBM Cloud ：

  1. MongoDB 配置に移動します。
  2. 左ナビゲーションの「 リソース 」をクリックします。
  3. メモリと CPUのスライダーを調整する。
  4. コストへの影響を検討する。
  5. **「スケール」**をクリックします。

• IBM Cloud CLIを使う：

  # Scale memory to 8GB and CPU to 4 cores
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --memory 8192 \
    --cpu-allocation 4
  

考慮事項

• スケーリング中に接続が短時間切断される。
• 5～10分のダウンタイムを計画する。
• 飽和する前に積極的に規模を拡大する。
• スケーリング後のメトリクスを監視する。

水平スケーリング（レプリカセットメンバー）

リードスケーリングと高可用性のためにレプリカセットメンバーを追加する。

• IBM Cloud ：

  1. リソースに移動します。
  2. メンバー スライダーを調整する。
  3. レビューの構成
  4. **「スケール」**をクリックします。

• IBM Cloud CLIを使う：

  # Add a replica set member
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --members 4
  

利点

• 読み取り負荷を2次側に分散
• 耐障害性の向上
• より良い地理的分布
• メンバー追加のためのダウンタイムなし

ストレージのスケーリング

ディスク容量とIOPSを増やしてパフォーマンスを向上。

• IBM Cloud ：

  1. リソースに移動します。
  2. ディスクスライダーを調整する。
  3. IOPSの割り当てを見直す。
  4. **「スケール」**をクリックします。

• IBM Cloud CLIを使う：

  # Scale disk to 100GB
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --disk-allocation 102400
  

重要なお知らせ

• ストレージは増やすだけで、減らすことはできない
• IOPSはディスクサイズによって変化する
• ストレージのスケーリングによるダウンタイムがない
• ディスク使用量の傾向を監視する

スケーリングのベストプラクティス

| ディスクレイテンシ｜ディスクサイズを大きくしてIOPSを増やす | 接続制限｜上位ティアへのスケールアップ | 読み取りの多いワークロード｜レプリカメンバーの追加 | 書込みの多い作業負荷｜CPUとメモリの規模｜メモリとCPUの規模｜メモリとCPUの規模｜メモリとCPUの規模

コストの最適化

• 適切な配備のサイズ
• モニタリングで実際のニーズを把握する。
• トラフィックの少ない時間帯にスケールダウンする（サポートされている場合）。
• 予測可能なワークロードのための予約容量を考慮する。

自動化

# Example: Auto-scale based on CPU threshold
if [ $(ibmcloud cdb deployment-metrics <deployment-id> --metric cpu) -gt 80 ]; then
  ibmcloud cdb deployment-groups-set <deployment-id> member --cpu-allocation 6
fi

IBM Cloud CLI のインストール

# Install IBM Cloud CLI
curl -fsSL https://clis.cloud.ibm.com/install/linux | sh

# Install databases plugin
ibmcloud plugin install cloud-databases

必須診断コマンド

• 配備情報を入手する：

  # List all MongoDB deployments
  ibmcloud cdb deployments --type mongodb
  
  # Get specific deployment details
  ibmcloud cdb deployment <deployment-id>
  

• 配備状況を確認する：

  # Get deployment status
  ibmcloud cdb deployment-status <deployment-id>
  
  # Get connection strings
  ibmcloud cdb deployment-connections <deployment-id>
  

• メトリクスを監視する：

  # Get CPU metrics
  ibmcloud cdb deployment-metrics <deployment-id> --metric cpu
  
  # Get memory metrics
  ibmcloud cdb deployment-metrics <deployment-id> --metric memory
  
  # Get disk metrics
  ibmcloud cdb deployment-metrics <deployment-id> --metric disk
  

• スケーリング作業：

  # Scale memory
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --memory 16384
  
  # Scale CPU
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --cpu-allocation 8
  
  # Scale disk
  ibmcloud cdb deployment-groups-set <deployment-id> member \
    --disk-allocation 204800
  

• バックアップ作業：

  # List backups
  ibmcloud cdb backups <deployment-id>
  
  # Get backup information
  ibmcloud cdb backup <backup-id>
  

IBM Cloud API の使用

• 認証:

  # Get IAM token
  export IAM_TOKEN=$(ibmcloud iam oauth-tokens --output json | jq -r '.iam_token')
  

• API を使用してデプロイメント メトリックを取得します：

  # Get metrics
  curl -X GET \
    "https://api.{region}.databases.cloud.ibm.com/v5/deployments/{deployment-id}/metrics" \
    -H "Authorization: ${IAM_TOKEN}"
  

• APIを使用したスケールデプロイメント：

  # Scale resources
  curl -X PATCH \
    "https://api.{region}.databases.cloud.ibm.com/v5/deployments/{deployment-id}/groups/member" \
    -H "Authorization: ${IAM_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '{
      "memory": {
        "allocation_mb": 16384
      },
      "cpu": {
        "allocation_count": 8
      }
    }'
  

• 診断スクリプトのサンプル：

  #!/bin/bash
  # MongoDB Performance Check Script
  
  DEPLOYMENT_ID="your-deployment-id"
  
  echo "=== MongoDB Performance Diagnostics ==="
  echo ""
  
  # Check CPU
  CPU=$(ibmcloud cdb deployment-metrics $DEPLOYMENT_ID --metric cpu --output json | jq -r '.metrics[0].value')
  echo "CPU Usage: ${CPU}%"
  if [ $(echo "$CPU > 80" | bc) -eq 1 ]; then
    echo "⚠️  WARNING: High CPU usage detected"
  fi
  
  # Check Memory
  MEMORY=$(ibmcloud cdb deployment-metrics $DEPLOYMENT_ID --metric memory --output json | jq -r '.metrics[0].value')
  echo "Memory Usage: ${MEMORY}%"
  if [ $(echo "$MEMORY > 80" | bc) -eq 1 ]; then
    echo "⚠️  WARNING: High memory usage detected"
  fi
  
  # Check Disk
  DISK=$(ibmcloud cdb deployment-metrics $DEPLOYMENT_ID --metric disk --output json | jq -r '.metrics[0].value')
  echo "Disk Usage: ${DISK}%"
  if [ $(echo "$DISK > 80" | bc) -eq 1 ]; then
    echo "⚠️  WARNING: High disk usage detected"
  fi
  
  # Check Status
  STATUS=$(ibmcloud cdb deployment-status $DEPLOYMENT_ID --output json | jq -r '.status')
  echo "Deployment Status: ${STATUS}"
  
  echo ""
  echo "=== Diagnostics Complete ==="
  

• オートメーションに関する推奨事項

  • 定期的な健康チェックを予定する。
  • モニタリングシステムとの統合
  • しきい値に基づくスケーリングの自動化。
  • 重要なメトリクスに対するアラートを作成します。
  • 監査証跡のためにすべての操作をログに記録する。

プライベート・エンドポイント（推奨）

メリット：

• 低遅延
• 強化されたセキュリティー
• インターネット接続料無料
• IBM Cloud ワークロードのパフォーマンスが向上

セットアップ

1. 設定 > エンドポイントに移動します。
2. プライベートエンドポイントを有効にする。
3. アプリケーションの接続文字列を更新する。

接続文字列の例：

mongodb://user:pass@host.private.databases.appdomain.cloud:port/database?authSource=admin&replicaSet=replset

パブリック・エンドポイント

ユース・ケース:

• 外部アプリケーション
• 開発とテスト
• ハイブリッド・クラウドのシナリオ

セキュリティー上の考慮事項:

• IP許可リストを使用する。
• TLS / SSL を施行する。
• クレデンシャルを定期的にローテーションする。

サービス・エンドポイント

IBM Cloud サービス・エンドポイントは、 IBM Cloud 内で最適化された接続性を提供する。

利点

• 待ち時間の短縮
• 公共のインターネットを経由しない
• セキュリティ態勢の改善
• 帯域幅のコスト削減

構成

# Enable service endpoint
ibmcloud cdb deployment-service-endpoint-enable <deployment-id>

マルチゾーン展開の考慮点

Databases for MongoDB は複数のアベイラビリティ・ゾーンにまたがることができる。

ベスト・プラクティス

• 同じ地域にアプリケーションを展開する。
• レイテンシを最小化するために、読み取り設定を使用する。
• nearest マルチゾーンアプリの優先読み込みを検討する。
• ゾーン間のレプリケーションラグを監視する。

ネットワーク遅延のトラブルシューティング

• アプリケーションからの待ち時間の測定

  # Test connection latency
  time mongo "mongodb://host:port/database" --eval "db.runCommand({ping: 1})"
  

• IBM Cloud シェルからのチェック

  # Ping test (if ICMP allowed)
  ping -c 10 your-mongodb-host.databases.appdomain.cloud
  
  # TCP connection test
  nc -zv your-mongodb-host.databases.appdomain.cloud 27017
  

MongoDB 接続診断

// Check network latency
db.runCommand({ ping: 1 })

// Check connection pool stats
db.serverStatus().connections

地理的分布

グローバルに分散したアプリケーション

戦略

• 単一リージョン ：低レイテンシー、単一障害点
• リードレプリカによるマルチリージョンリードスケーリング、最終的な一貫性
• クロスリージョンレプリケーション ：ディザスタリカバリ、高レイテンシ

推奨事項

• データベースを主要ユーザーの近くに置く。
• 静的コンテンツにはCDNを使う。
• アプリケーションレベルのキャッシュを実装する。
• データレジデンシーの要件を検討する。

帯域幅の最適化

• プロジェクションを使ってデータ転送を制限する。
• 大きな結果セットのためにページネーションを実装する。
• アプリケーションレベルでデータを圧縮する。
• ラウンド・トリップを減らすため、バルク・オペレーションを利用する。

接続プーリングのベストプラクティス

// Node.js example
const client = new MongoClient(uri, {
  maxPoolSize: 50,
  minPoolSize: 10,
  maxIdleTimeMS: 30000,
  serverSelectionTimeoutMS: 5000,
  socketTimeoutMS: 45000
});