メインコンテンツまでスキップ

機能とアーキテクチャ

FPT MongoDB Enterprise は FPT Cloud のクラウドネイティブ基盤上で動作し、運用と保護のコンポーネントが後付けではなく組み込まれています。このページでは、サービスができることと、あとから変更できない唯一のアーキテクチャ上の判断を扱います。

機能一覧​

機能は 8 つの領域に分かれます。常時利用できるものもあれば、有効化して初めて保護やレポートが機能するものもあります。本番デプロイを計画しているなら、右端の列が重要です。

領域提供される内容既定で有効か
database の管理と運用cluster の provisioning、設定、運用を行う集中 console。provisioning、リソースのスケーリング、parameter 設定、サービス管理までライフサイクルを自動化。はい
High Availability とスケーラビリティStandalone、Replica Set、Sharded Cluster のアーキテクチャ。Replica Set と各 shard 内で自動 failover。shard をまたいだ水平スケールアウト。アーキテクチャは provisioning 時に選択
backup と recoveryスケジュールによる自動 backup と point-in-time recovery。backup と PITR は作成時に有効。ただし backup job が存在し、少なくとも 1 回実行されるまでデータは保護されません
monitoring と alertFPT Monitoring 経由でリアルタイムのメトリクス（CPU、メモリ、IOPS、接続数）。Grafana dashboard とログ検索を提供。いいえ — 有効化には FPT Support への連絡が必要
セキュリティとコンプライアンス保存時と転送時の暗号化、RBAC、VPC 統合、IP ベースのアクセス制御。はい
パフォーマンス最適化engine 設定、インデックス戦略、クエリ最適化。お客様側で実施
ログと監査トラブルシューティングとコンプライアンスのための集中ログと監査証跡。はい
マネージドサービスとサポートFPT Cloud による 24 時間運用と、SLA に基づくインシデント対応。はい

対応が必要な 2 つ​

上記のほとんどは cluster が動き出した時点で機能します。次の 2 つは違い、いずれも見落とされがちです。

  • backup。 cluster 作成時に backup サービスは有効になりますが、それはサービスが利用可能になっただけです。backup job を設定して 1 回完了するまで、リストアポイントは存在しません。Backup & Restore の概要 を参照してください。
  • monitoring。 セルフサービスではありません。Monitor タブは FPT Support への連絡を促し、サポートが cluster の収集を有効化します。Monitor & alert を参照してください。

アーキテクチャの選択​

これは最も重要な判断です。provisioning 時に固定され、node を失っても cluster が生き残るか、そして 1 台のマシンの容量を超えて拡張できるかを決めるからです。

StandaloneReplica SetSharded Cluster
構成database instance 1 台、replication なしPrimary 1 台と複数の Secondary node複数の shard（各 shard は 3 node の replica set）を mongos router と 3 node の config server が支える構成
自動 failoverなしありあり（shard ごと）
データ replicationなしありあり（shard ごと）
容量の増やし方node を大きくするのみnode を大きくする、または node を増やすnode を大きくする、mongos router を増やす、または shard を増やす
バージョンアップグレード時の影響軽減なしありあり
デプロイ速度最も速い遅い最も遅い
最小構成1 node3 node11 node
推奨用途開発、テスト、ステージング、小規模ワークロード本番、および耐障害性が必要なすべてreplica set 1 組では支えきれないデータ量や書き込みスループット

Standalone はデプロイが速く、コストが低く、管理も単純です。その代償は徹底的で、failover がないため node が利用できなくなればサービスは止まります。

Replica Set は複数 node にデータを replicate し、Primary が停止すると Secondary を自動的に昇格させるため、node 障害を越えてサービスが継続します。ただし各 node が全データを保持するため、購入できる最大の node が上限になります。

Sharded Cluster はその上限を取り払います。データは shard key によって shard へ分割され、各 shard は自分の担当分だけを保持するため、容量と書き込みスループットは node のサイズではなく shard の数に応じて伸びます。その代わり node 数と運用の複雑さが増えます。コンソールが構築できる最小の cluster は 11 node で、クエリ性能は負荷を均等に分散する shard key を選べるかどうかに左右されます。

Sharded Cluster の構成要素​

3 つの node ロールがあり、provisioning 時にそれぞれ個別にサイジングします。

ロール役割node 数
Mongosquery router。client は shard ではなくここに接続します。cluster のメタデータを読み、各操作を該当データを持つ shard へ転送します。ステートレスで、自身はデータを保持しません。2〜32（任意）
Shardデータの一部を保持します。各 shard は 3 node の replica set としてデプロイされるため、shard 単体で node 障害に耐えます。2〜32 shard（任意）＝ 6〜96 data node
ConfigServercluster のメタデータ（shard key 範囲のどの chunk がどの shard にあるか）を保持します。replica set としてデプロイされます。3 で固定

したがって 2 shard の cluster は、mongos 2 + shard node（2 × 3）+ config server 3 = 11 node になります。

shard 数は作成時に固定されるわけではありません。cluster の Overview タブから、mongos router の数と併せてあとから増やせます。config server はどちらの場合も 3 のままです。database cluster をスケールアウトする を参照してください。

注記

とはいえ shard の追加は、設定を切り替えるだけの作業ではなく計画が必要な操作です。MongoDB が新しい shard 構成へデータを再配置し、その間は性能が落ちます。見込まれるデータ量に合わせて概算で決めておくと、後のリバランスを避けられます。

警告

Architecture Type は cluster 作成時に設定され、あとから変更できません。Standalone、Replica Set、Sharded Cluster の間で移るには、新しい cluster を provisioning してデータを移行する必要があります。本番になる可能性が少しでもあるなら Replica Set を、replica set 1 組ではデータを保持しきれないと確信できる場合にのみ Sharded Cluster を選んでください。

プラットフォームのコンポーネント​

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 によるアクセス制御

これらにより、データは保存場所でも転送中でも保護されます。

次のステップ​