機能とアーキテクチャ
FPT MongoDB Enterprise は FPT Cloud のクラウドネイティブ基盤上で動作し、運用と保護のコンポーネントが後付けではなく組み込まれています。このページでは、サービスができることと、あとから変更できない唯一のアーキテクチャ上の判断を扱います。
機能一覧
機能は 8 つの領域に分かれます。常時利用できるものもあれば、有効化して初めて保護やレポートが機能するものもあります。本番デプロイを計画しているなら、右端の列が重要です。
| 領域 | 提供される内容 | 既定で有効か |
|---|---|---|
| database の管理と運用 | cluster の provisioning、設定、運用を行う集中 console。provisioning、リソースのスケーリング、parameter 設定、サービス管理までライフサイクルを自動化。 | はい |
| High Availability とスケーラビリティ | Single Node と Replica Set のアーキテクチャ。Replica Set では自動 failover。vCPU、RAM、storage の垂直スケーリング。 | アーキテクチャは provisioning 時に選択 |
| backup と recovery | スケジュールによる自動 backup と point-in-time recovery。 | backup と PITR は作成時に有効。ただし backup job が存在し、少なくとも 1 回実行されるまでデータは保護されません |
| monitoring と alert | FPT Monitoring 経由でリアルタイムのメトリクス（CPU、メモリ、IOPS、接続数）。Grafana dashboard とログ検索を提供。 | いいえ — 有効化には FPT Support への連絡が必要 |
| セキュリティとコンプライアンス | 保存時と転送時の暗号化、RBAC、VPC 統合、IP ベースのアクセス制御。 | はい |
| パフォーマンス最適化 | engine 設定、インデックス戦略、クエリ最適化。 | お客様側で実施 |
| ログと監査 | トラブルシューティングとコンプライアンスのための集中ログと監査証跡。 | はい |
| マネージドサービスとサポート | FPT Cloud による 24 時間運用と、SLA に基づくインシデント対応。 | はい |
対応が必要な 3 つ
上記のほとんどは cluster が動き出した時点で機能します。次の 3 つは違い、いずれも見落とされがちです。
- backup。 cluster 作成時に backup サービスは有効になりますが、それはサービスが利用可能になっただけです。backup job を設定して 1 回完了するまで、リストアポイントは存在しません。Backup & Restore の概要 を参照してください。
- monitoring。 セルフサービスではありません。Monitor タブは FPT Support への連絡を促し、サポートが cluster の収集を有効化します。Monitoring を参照してください。
- Auto Vertical Scaling。 先に Notification サービスを設定し、email または Telegram の宛先を 1 つ以上登録しておく必要があります。alert の送り先がないと、システムはスケーリングの有効化を拒否します。Auto Vertical Scaling を参照してください。
アーキテクチャの選択
これは最も重要な判断です。provisioning 時に固定され、node を失っても cluster が生き残るかどうかを決めるからです。
| Single Node | Replica Set | |
|---|---|---|
| 構成 | database instance 1 台、replication なし | Primary 1 台と複数の Secondary node |
| 自動 failover | なし | あり |
| データ replication | なし | あり |
| バージョンアップグレード時の影響軽減 | なし | あり |
| デプロイ速度 | 速い | 遅い |
| コスト | 低い | 高い |
| 推奨用途 | 開発、テスト、ステージング、小規模ワークロード | 本番、および耐障害性が必要なすべて |
Single Node はデプロイが速く、コストが低く、管理も単純です。その代償は徹底的で、failover がないため node が利用できなくなればサービスは止まります。
Replica Set は複数 node にデータを replicate し、Primary が停止すると Secondary を自動的に昇格させるため、node 障害を越えてサービスが継続します。
Architecture Type は cluster 作成時に設定され、あとから変更できません。Single Node から Replica Set へ移るには、新しい cluster を provisioning してデータを移行する必要があります。本番になる可能性が少しでもあるなら Replica Set を選んでください。
プラットフォームのコンポーネント
database そのものの周囲には、cluster のライフサイクル全体をカバーする集中管理コンポーネントが統合されています。
- Monitoring — FPT Monitoring と Grafana を通じたメトリクスとログ
- Logging — トラブルシューティングと監査のための集中収集
- backup と restore — スケジュール backup と point-in-time recovery
- 自動 alert — backup、リソース、スケーリング、maintenance のイベントを email と Telegram で配信
リソースのスケーリングはオンラインで動作します。vCPU、RAM、storage は VPC の quota 範囲内であれば cluster を停止せずに調整できます。
分離とセキュリティ
アーキテクチャは多層の分離を適用し、次を組み合わせています。
- VPC 配置によるネットワーク分離。cluster はお客様自身のネットワーク境界内に置かれます
- 保存時と転送時のデータ暗号化
- IAM role と Security Group によるアクセス制御
これらにより、データは保存場所でも転送中でも保護されます。
次のステップ
- サポート対象バージョンを確認する Database engine のバージョン
- endpoint、アクセスモデル、Security Group を確認する Floating IP で database に接続する
- アーキテクチャを決めたら 最初の database を作成する