NoSQLサーバーの役割と特性

NoSQL（MongoDB / DynamoDB / Cassandra）はスケールアウトを前提に設計されているが、単一ノードのスペックがパーティション内の処理速度を決定するため、スケールアップも有効だ。MongoDB のシャードなし構成や、DynamoDB のホットパーティションが問題になるケースでは、まずノードスペックの見直しを検討する。

ボトルネックになるリソース

NoSQL 種主なボトルネック確認方法
MongoDBWiredTiger キャッシュ（メモリ）・IOPSdb.serverStatus().wiredTiger.cache
DynamoDBパーティションあたり RCU/WCU 上限（3,000 RCU / 1,000 WCU）CloudWatch ThrottledRequests
Cassandraメモリ（Memtable）・ディスク I/O（SSTable Compaction）nodetool tablehistograms

スケールアップの内容と効果

① MongoDB：WiredTiger キャッシュ拡張

YAML — mongod.conf
storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 20   # 物理メモリ 32GB なら 20GB が目安（デフォルト: RAM/2 - 1GB）
# 確認: db.serverStatus().wiredTiger.cache["bytes currently in the cache"]

② DynamoDB：RCU/WCU 増強

■ DynamoDB 必要 RCU 試算
必要 RCU = 読み取り req/s × アイテムサイズ(KB) ÷ 4KB（結果整合性: ÷ 2）
例：1,000 req/s、2KB アイテム、強整合性 → 1000 × (2÷4) = 500 RCU

⚠️ ホットパーティション問題

RCU/WCU を増やしても特定パーティションキーへの集中アクセスはスロットリングを解消しません。パーティションキーの設計見直しが根本対処です。

③ Cassandra：JVM ヒープとオフヒープ

YAML — cassandra.yaml
memtable_allocation_type: offheap_objects
memtable_offheap_space_in_mb: 4096
# JVM: MAX_HEAP_SIZE="8G"（小さく保つ → GC 抑制）
compaction_throughput_mb_per_sec: 64   # SSD なら 64〜128

スケールダウンの考え方

条件スケールダウン可否
WiredTiger キャッシュヒット率 > 99% が余裕メモリ削減を検討可
DynamoDB ThrottledRequests = 0 かつ WCU/RCU が 40% 未満プロビジョニング削減可

スケールアップ vs スケールアウト

状況推奨
1ノードのメモリ・I/O が限界スケールアップ
書き込みが分散できる設計スケールアウト（シャード追加）
DynamoDB ホットパーティションパーティションキー再設計 → DAX 追加

判断指標（監視メトリクス）

メトリクス確認方法目安
MongoDB キャッシュ使用率db.serverStatus().wiredTiger.cache空き < 20% が継続
DynamoDB ThrottledRequestsCloudWatch> 0 が継続
IOPS %utiliostat -x≥ 70%

まとめ

項目要点
MongoDBWiredTiger キャッシュを物理メモリの 60% まで拡張。I/O が激減する。
DynamoDBRCU/WCU 増強 or オンデマンドモード。ホットパーティションはキー設計で解決。
CassandraJVM ヒープは小さく維持。オフヒープ Memtable を大きく取る。
スケールアウト優先書き込みが分散できる設計ならシャード追加を先に検討。