架构设计
以账号、网络与权限结构（着陆区）和多可用区冗余作为标准设计。
- VPC · Subnet · NAT Gateway
- Sub Account (IAM)
- Load Balancer · Global DNS
- Ncloud Kubernetes Service
Reference architecture
NAVER Cloud 参考架构
以 VPC 公有/私有子网与 ACG 划分边界；Cloud DB 默认采用高可用配置与自动备份。
Sub AccountMFA · least privilege
VPCpublic / private subnet
权限与网络边界
Load BalancerACG
Server · NKSKR-1 / KR-2 zones
应用层 → 数据层
Cloud DBMySQL · PostgreSQL HA
Read replicaread scale
Backupautomated backup · Object Storage
Cloud Insight · Security MonitoringCloud AdvisorTerraform (ncloud)
- 通过 Sub Account 与 MFA 分离控制台与 API 权限
- Cloud DB 部署于私有子网，ACG 最小开放
- 基于 Cloud Insight 指标与事件的告警体系
- 如需公共机构专用（Gov）环境，事先确认可用服务范围
MSP scope
NAVER Cloud MSP 服务范围
各领域使用的代表性服务，根据客户环境与合同范围调整。
上云迁移
从服务器重新托管到托管数据库平台迁移，分阶段实施。
- Database Migration Service
- Object Migration
- Migration Management
- Server image · rsync-based rehost
7x24 监控与运维
采集指标、日志与事件，按故障响应与变更管理流程运维。
- Cloud Insight
- Cloud Log Analytics
- Cloud Activity Tracer
- Auto Scaling
成本优化（FinOps）
持续进行用量可视化、预算告警、规格调整与承诺折扣评估。
- Billing & cost reports (console)
- Cloud Advisor
- Server spec right-sizing
- Scheduled stop / start
安全与合规
默认落实最小权限、加密、审计日志与安全建议检查。
- Sub Account · MFA
- Security Monitoring
- Key Management Service
- ACG · Network ACL
备份与容灾
制定备份策略与恢复目标（RPO/RTO），并通过恢复演练验证。
- Backup
- Object Storage · Archive Storage
- Cloud DB automated backup
- Cross-zone redundancy
托管数据库运维
由数据库专家管理托管数据库的参数、性能与版本生命周期。
- Cloud DB for MySQL
- Cloud DB for PostgreSQL
- Cloud DB for MSSQL · MongoDB · Cache
- MariaDB server image (self-managed)
IaC 与自动化
以代码管理基础设施，并通过流水线自动化部署与巡检。
- Terraform (ncloud provider)
- Ncloud CLI · API
- SourceCommit · SourcePipeline
- Ansible
Managed databases
NAVER Cloud 托管数据库选择
按开源数据库引擎整理该云可用的托管服务与自建（Self-managed）替代方案。
| 引擎 | 托管服务 / 替代方案 | 备注 |
|---|---|---|
| MySQL | Cloud DB for MySQL | 提供托管服务——我们管理参数、性能与升级计划 |
| PostgreSQL | Cloud DB for PostgreSQL | 提供托管服务——我们管理参数、性能与升级计划 |
| MariaDB | MariaDB server image / Marketplace (self-managed) | 无托管服务——在虚拟机/容器上自建运维（衔接开源数据库服务） |
| InfluxDB | Server (self-managed) | 无托管服务——在虚拟机/容器上自建运维（衔接开源数据库服务） |
| Oracle · SQL Server | Cloud DB for MSSQL / Server; → MySQL · PostgreSQL | 通常作为异构迁移的源库——参见数据迁移 |
NAVER Cloud 没有 MariaDB 的托管 Cloud DB 产品（依据 2026 年 10 月官方文档）。MariaDB 可通过服务器镜像或 Marketplace 自建，或评估迁移至 Cloud DB for MySQL。
Migration to cloud
迁移到 NAVER Cloud 的流程
评估
调查服务器与数据库清单、依赖关系、性能基线与许可，确定重新托管、平台迁移或重构方式。
着陆区
先以代码构建账号、网络、权限与日志标准。
迁移实施
服务器优先考虑 Server image · rsync / OS-level replication，数据库优先考虑 NCP Database Migration Service · native replication，模式转换使用 ora2pg · pgloader · mydumper。
验证与切换
验证数据一致性与性能后，按事先约定的标准切换，并保留回退路径。
稳定与优化
保障期内加强监控，之后将成本与性能优化纳入日常运维。
Security & compliance
韩国法规与安全考量
- 区域：NAVER Cloud KR region (KR-1 · KR-2 zones)——记录数据及备份副本的存放位置
- 从《个人信息保护法》与 ISMS-P 角度设计访问控制、加密及访问记录保存
- 公共部门需确认是否适用 CSAP（云安全认证）及所需认证范围
- 将审计日志、变更记录与权限审查结果作为证据留存的运维流程
以上为一般性考量。OpenDB Works 不代办认证，也不保证取得认证；认证要求的解释以客户安全负责人及认证审核机构的判断为准。
FAQ
常见问题
Cloud DB for PostgreSQL 还是自建？
比较扩展（Extension）与参数的自由度和运维负担后决定。如需托管服务不支持的扩展，建议自建服务器。
能否承接公共部门项目？
我们会结合项目要求确认公共机构环境提供的服务与 CSAP 认证范围后再设计。是否符合要求以发包机构的判断为准。
是否为 NAVER Cloud 合作伙伴？
本网站不公示合作伙伴情况，如有需要可在咨询时说明。
从现状开始，一起检查您的云与数据库？
告诉我们您使用的云、数据库版本、架构与困扰，我们将提出评估范围与实施方式。