機能
database でできることは、選ぶデプロイモデル、アプリケーションからの到達方法、そして選ぶ engine の 3 つで決まります。いずれも後から変更するのは容易ではないためプロビジョニング前に 3 つとも確認し、engine の一覧は 製品紹介 を参照してください。
engine と機能の提供状況はサービスの開発に伴って変わります。このページは記録された時点の状態であり、最新の状態は Console Portal で確認してください。
デプロイモデル
個々の機能より先に、全体を左右する選択があります。すべての database は 2 つのモデルのいずれかでデプロイされ、可用性、パフォーマンス、コストの要件に応じてプロビジョニング時に決まります。
| Single Node | High Availability (HA / Cluster) | |
|---|---|---|
| node 数 | database instance 1 台、standby なし | primary 1 台と standby または replica 1 台以上 |
| 配置 | 単一 node | 同一または異なる Availability Zone |
| Failover | なし | 自動。継続的に監視し、primary の障害時に standby へ failover します |
| ダウンタイム | node 障害時とメンテナンス時に発生 | failover により最小化 |
| 適した用途 | 開発・テスト環境、低〜中程度の負荷、シンプルで低コストな構成を優先する場合 | 本番システムおよび業務上重要なシステム |
Single Node の database は vCPU、RAM、storage のすべてを 1 台の node で使います。backup は設定したスケジュールどおりに動作するため、保護されていないわけではありません。欠けているのは standby であり、可用性はその 1 台の健全性に依存します。
High Availability はダウンタイムの削減以外に 3 つの利点をもたらします。信頼性と復旧能力の向上、設定した場合の replica による読み取りスケール、そして接続のルーティングのために前段へ Database proxy を置けることです。
選べるモデルと HA が実際に提供する内容は engine によって異なります。詳細は以下の表を参照してください。
ネットワーク接続
アプリケーションが node を直接指定することはありません。接続は database endpoint を経由し、その endpoint の背後にあるものは上で選んだデプロイモデルによって決まります。
| デプロイモデル | endpoint が指す先 |
|---|---|
| Single Node | database instance |
| High availability | cluster を代表する DB Proxy |
endpoint を経由することでアプリケーションのロジックと cluster の構成が切り離されるため、トポロジの変更や failover が起きても接続設定を変更する必要はありません。
private アクセスと public アクセス
アクセスモデルは 2 種類あり、この選択はネットワークの判断であると同時にセキュリティの判断でもあります。
| アクセスモデル | 内容 | 用途 |
|---|---|---|
| private アクセス | database にはプライベートネットワーク (VPC) の内部からのみ到達できます | 本番、および露出を最小限に保つ必要があるすべての環境 |
| public アクセス | database がインターネットから到達できる public endpoint を公開します。追加のセキュリティ制御が前提です | 外部システム、一時的な管理アクセス、テストおよび統合環境 |
Security Group と Floating IP
この 2 つの仕組みによって public アクセスは実用に耐える安全性を得ます。片方だけではなく、組み合わせて使うことを前提としています。
Security Group は、IP アドレスまたは CIDR、ポート、プロトコルによって受信と送信のトラフィックを許可または拒否する、ステートフルなファイアウォールルールの集合です。同一 VPC 内のアプリケーションや承認済みの踏み台ホストなど、正当な送信元だけに絞ることで least privilege を実現します。ルールの変更は即座に反映され、database の再起動は不要です。
Floating IP は、必要に応じて database instance に付け外しできる public IP アドレスで、インターネットからの到達性を有効にするものです。許可する送信元の範囲を制限し、3306、5432、1433 など実際に必要な database のポートだけを開く Security Group と組み合わせて使ってください。
Floating IP は本当に必要な間だけ有効にし、本番では private アクセスを優先してください。緩い Security Group と組み合わせた Floating IP は、database をインターネットに公開することと同じです。
両方の操作手順は Floating IP で database に接続する にあります。
特定の engine でのみ使える機能
| 機能 | 対応 engine | 注意点 |
|---|---|---|
| database バージョンのアップグレード | MariaDB | 経路は MariaDB から MariaDB 10.9 の 1 つだけです。他の engine ではアップグレードの操作自体が表示されません。アップグレードはロールバックできません。他のすべての engine では、メジャーバージョン間の移行は バージョンポリシー に沿った手動のデータ移行になります。 |
| Database proxy | MySQL, PostgreSQL, MariaDB | High Availability の database のみです。両方の条件を満たさない限り DB Proxy タブは表示されません。 |
| Kafka user と ACL | Kafka | producer、consumer、Kafka Connect のための SASL 認証です。 |
| Point-in-time recovery | PostgreSQL, MySQL, MariaDB | 保護が始まるのは有効化した時点ではなく、次の full backup が完了してからです。 |
| Differential backup job、backup スケジュールの設定 内 | PostgreSQL, MySQL, MariaDB, SQL Server | リレーショナル engine のみです。full backup job にはこの制限はありません。 |
| backup データを S3 に転送する | PostgreSQL, MySQL, MariaDB, SQL Server, Redis, MongoDB, TimescaleDB | |
| High Availability、database の作成 内 | Cassandra 以外のすべての engine | Cassandra では代わりに Number Of Nodes で node 数を指定します。ClickHouse では、これに依存する前に後述の replication に関する注意を確認してください。 |
一部の engine でのみ表示される設定項目
database 作成フォームは選んだ engine によって変わるため、ガイドで説明されている項目が表示されないことがあります。
| 項目 | 表示される engine |
|---|---|
| Edition (Enterprise、Standard、Web) | SQL Server のみ |
| Database Name | Redis と Kafka 以外のすべて |
| VHost Name | RabbitMQ のみ |
| Number Of Nodes | Cassandra のみ |
| High Availability | Cassandra 以外のすべて |
engine によって異なる動作
同じ機能でも、動作している engine によって挙動が変わるケースです。いずれも想定外の事態を招いた実績があり、事前に織り込む価値があります。
| Engine | 差異 |
|---|---|
| PostgreSQL, OpenSearch, ClickHouse | vCPU または RAM の変更は、自分で database を再起動するまで反映されません。それまでは旧構成のまま動作し、一覧に警告アイコンが表示されます。リソースの変更 と auto scaling の両方に該当します。 |
| 2026 年 3 月 13 日より前に作成された PostgreSQL HA の database | PITR を有効にすると database が自動的に再起動し、短時間サービスが中断します。負荷の低い時間帯に実施してください。 |
| Kafka | backup の実行によりサービスが中断することがあるため、Kafka の backup は負荷の低い時間帯に設定してください。SASL/PLAIN で user を作成または更新すると database が再起動します。 |
| High Availability を有効にした ClickHouse | replica は shard ごとに作成されますが、テーブルが replicate されるのは MergeTree ファミリの replicated engine で作成した場合だけです。通常の MergeTree テーブルは書き込みを受けた node に残ります。FAQ の ClickHouse - High Availability を参照してください。 |
| Cassandra | High Availability の選択肢はありません。プロビジョニング時に Number Of Nodes で cluster のサイズを指定します。 |
ClickHouse では High Availability を有効にするだけでは不十分です。replicate されない MergeTree テーブルは、そのテーブルを保持する node が障害を起こすとデータを失うため、依存しているすべてのテーブルの table engine を確認してください。
すべての engine で同じように動作する機能
上記の engine 固有の挙動を除き、どの engine でも設定方法は同じです。
- database の作成、database 一覧の表示、database 詳細の表示
- database の停止・起動・再起動
- Backup サービスの管理 と full backup job
- backup からの restore。対応するすべての engine で動作します
- database リソース構成の変更 と database のパラメータ
- maintenance window の変更。通知はメールのみです
- FMON による database の監視、Action Log、レポート
次のステップ
- Database Engine のバージョン。使っている engine のバージョンとサポート終了時期を確認できます
- 製品紹介。engine の一覧と責任分界点を確認できます
- 最初の database を作成する。最初の cluster をプロビジョニングします
- database の作成。フォームの全項目を確認できます