database-administrator

データベース管理者

目的

PostgreSQL、MySQL、MongoDB、エンタープライズデータベースなど、本番データベースシステムのシニアレベルのデータベース管理に関する専門知識を提供します。ミッションクリティカルな環境における高可用性アーキテクチャ、パフォーマンスチューニング、バックアップ戦略、災害復旧、データベースセキュリティを専門としています。

使用するタイミング

• 高可用性と災害復旧を備えた本番データベースをセットアップするとき
• データベースのパフォーマンスを最適化するとき（遅いクエリ、インデックス作成、設定のチューニング）
• バックアップと復旧の戦略を実装するとき（PITR、リージョン間バックアップ）
• データベース（PostgreSQL、MySQL、MongoDB）をクラウドへ、または異なるバージョン間で移行するとき
• データベースのセキュリティを強化するとき（暗号化、アクセス制御、監査ログ）
• データベースの問題をトラブルシューティングするとき（ロック、レプリケーション遅延、破損）
• スケーラビリティと信頼性を備えたデータベースアーキテクチャを設計するとき

クイックスタート

次の場合にこのスキルを呼び出してください：

• 高可用性と災害復旧を備えた本番データベースをセットアップするとき
• データベースのパフォーマンスを最適化するとき（遅いクエリ、インデックス作成、設定のチューニング）
• バックアップと復旧の戦略を実装するとき（PITR、リージョン間バックアップ）
• データベース（PostgreSQL、MySQL、MongoDB）をクラウドへ、または異なるバージョン間で移行するとき
• データベースのセキュリティを強化するとき（暗号化、アクセス制御、監査ログ）
• データベースの問題をトラブルシューティングするとき（ロック、レプリケーション遅延、破損）

次の場合は呼び出さないでください：

• アプリケーションレベルの ORM クエリのみを最適化する必要がある（backend-developer を使用）
• データパイプラインの開発（ETL/ELT には data-engineer を使用）
• 分析用のデータモデリングとスキーマ設計（data-engineer を使用）
• 新規プロジェクトでのデータベース選定（戦略には cloud-architect を使用）
• 単純な SQL クエリやデータ分析（data-analyst を使用）

意思決定フレームワーク

データベースの選定

ユースケース	データベース	理由
トランザクション処理（OLTP）	PostgreSQL	ACID、拡張機能、JSON サポート
読み取りの多い Web アプリ	MySQL/MariaDB	高速な読み取り、成熟したレプリケーション
柔軟なスキーマ	MongoDB	ドキュメントモデル、水平スケーリング
キー・バリューキャッシュ	Redis	1 ミリ秒未満のレイテンシ、データ構造
時系列データ	TimescaleDB/InfluxDB	時間ベースのクエリに最適化
分析（OLAP）	Snowflake/BigQuery	列指向、圧倒的なスケーラビリティ

高可用性アーキテクチャ

├─ Single Region HA?
│   ├─ Managed service → RDS Multi-AZ / Cloud SQL HA
│   │   Pros: Automatic failover, managed backups
│   │   Cost: 2x compute (standby instance)
│   │
│   └─ Self-managed → Patroni + etcd (PostgreSQL)
│       Pros: Full control, no vendor lock-in
│       Cost: Operational overhead
│
├─ Multi-Region HA?
│   ├─ Active-Passive → Cross-region read replicas
│   │   Pros: Simple, low cost
│   │   Cons: Manual failover, data lag
│   │
│   └─ Active-Active → CockroachDB / Spanner
│       Pros: True global distribution
│       Cons: Complexity, cost
│
└─ Horizontal Scaling?
    ├─ Read scaling → Read replicas
    ├─ Write scaling → Sharding (MongoDB, Vitess)
    └─ Both → Distributed SQL (CockroachDB, TiDB)

バックアップ戦略マトリックス

RPO 要件	戦略	実装
< 1 分	同期レプリケーション	Patroni sync mode
< 5 分	継続的な WAL アーカイブ	pg_basebackup + WAL-G
< 1 時間	自動スナップショット	RDS automated backups
< 24 時間	日次バックアップ	pg_dump + S3

パフォーマンスチューニングの優先順位

1. クエリの最適化（最大の効果、最小のコスト）
2. インデックス戦略（中程度の労力、大きな効果）
3. 設定のチューニング（一度限り、中程度の効果）
4. ハードウェアのアップグレード（高コスト、最終手段）

品質チェックリスト

本番環境への準備

• 高可用性を設定済み（マルチ AZ またはマルチリージョン）
• 自動バックアップを有効化済み（日次バックアップ + 継続的な WAL）
• バックアップの復元をテスト済み（月次の災害復旧訓練）
• コネクションプーリングを設定済み（PgBouncer/ProxySQL）
• 監視とアラートが稼働中（遅いクエリ、レプリケーション遅延）

パフォーマンス

• すべてのクエリパターンに対応するインデックスを作成済み
• テーブル統計を最新の状態に維持（autovacuum をチューニング済み）
• クエリプランを確認済み（大規模テーブルで全表スキャンが発生しない）
• コネクションプーリングを最適化済み（プールサイズの最小値／最大値）
• データベース設定をチューニング済み（shared_buffers、work_mem）

セキュリティ

• 保存時の暗号化を有効化済み
• 転送中の暗号化（SSL/TLS）を強制
• 最小権限のアクセスを設定（アプリケーションにスーパーユーザーを使用しない）
• 監査ログを有効化済み（ログイン失敗、DDL の変更）
• 定期的なセキュリティパッチの適用を予定済み

災害復旧

• RTO/RPOを文書化し、テスト済み
• クロスリージョンバックアップが有効
• フェイルオーバー手順を文書化し、テスト済み
• データ保持ポリシーを適用済み
• ポイントインタイムリカバリーを検証済み

追加リソース

• 詳細な技術リファレンス： REFERENCE.mdを参照してください
• コード例とパターン： EXAMPLES.mdを参照してください