이 글은 지난 포스팅의 OCI 계정·네트워크 준비 다음 단계입니다.
앞 단계의 계정·네트워크 설정을 확인한 뒤 DB System을 생성하고, 접속 정보와 백업 조건을 점검합니다.
아래 흐름도에서 데이터베이스 구성은 두 번째 단계입니다.
흐름도에 적힌 시간은 진행 순서를 설명하기 위한 예상치입니다. 계정 권한, 가용 용량과 생성 상태에 따라 실제 소요 시간은 달라집니다.
📚 WordPress에서 데이터베이스가 맡는 역할
WordPress는 게시물, 댓글, 사용자 정보와 여러 설정을 데이터베이스에 저장합니다. 접속 오류나 느린 쿼리가 발생하면 사이트 동작에도 영향을 주므로, 연결 상태와 쿼리 성능을 함께 확인해야 합니다.
주요 저장 항목은 다음과 같습니다:
게시물과 페이지의 본문, 발행 상태, 리비전과 관련 메타데이터를 저장합니다.
실제 저장 위치와 조회 방식은 테마·플러그인에 따라 달라질 수 있습니다.
댓글과 작성자 정보, 승인 상태 등을 저장합니다. 개인정보의 수집 범위와 보관 기간은 사이트 정책에 맞게 관리해야 합니다.
사용자 계정과 권한 관련 정보도 관리합니다. 데이터베이스의 접근 권한과 백업 보호를 점검하되, 모든 활동 기록이나 보안 토큰이 기본 WordPress에 저장된다고 가정하지 마세요.
🌟 MySQL DB System과 HeatWave 기능 구분하기
DB System 생성이 끝나면 WordPress가 실행되는 서버에서 연결을 확인해야 합니다. 접속되지 않는다면 분석 기능보다 접속 주소·네트워크 경로·계정 권한부터 점검하세요.
MySQL DB System과 HeatWave 클러스터는 구분해야 합니다. DB System을 생성했다고 해서 분석용 인메모리 쿼리 가속이 자동으로 적용되는 것은 아닙니다. 사용할 기능과 클러스터 구성, 쿼리의 처리 경로를 따로 확인하세요.
워드프레스의 게시물 조회와 댓글 저장은 일반적인 트랜잭션 작업입니다. 응답 시간은 쿼리, 인덱스, 데이터량과 동시 요청에 따라 달라집니다. HeatWave라는 서비스 이름만으로 이 작업의 성능을 보장할 수는 없습니다.
자동 최적화 기능은 지원되는 기능과 적용 대상에 따라 동작합니다. 일반적인 워드프레스 트래픽을 자동으로 학습해 모든 병목을 해결한다고 가정하지 말고, 해당 기능의 지원 조건과 실제 쿼리 실행 결과를 확인하세요.
성능적 특징
HeatWave 클러스터는 인메모리 쿼리 처리 엔진을 제공합니다. 워드프레스의 모든 조회를 단순히 메모리에 캐싱하는 기능으로 설명해서는 안 됩니다. 클러스터에 로드된 데이터와 지원되는 쿼리의 처리 조건을 확인해야 합니다.
자동 최적화 기능을 사용할 때는 선택한 기능의 적용 대상과 지원 버전을 먼저 확인합니다. 쿼리 실행 계획과 인덱스 사용은 실제 워크로드에서 별도로 점검하세요.
DB System과 HeatWave 클러스터의 용량은 각각 검토합니다. 피크 부하에서의 처리량과 응답 시간은 측정 대상이며, 이 글의 구성 예시는 자동 확장이나 안정적인 성능을 보장하지 않습니다.
안정성과 보안
2026-10-03 공식 문서 기준, Always Free MySQL DB System은 자동 백업 보존이 1일로 고정되고 수동 백업과 특정 시점 복원(PITR)을 지원하지 않습니다.
삭제 계획(Deletion Plan)에서 Require final backup을 선택해 생성하는 Always Free 최종 백업은 7일 보존됩니다. 기본 삭제 계획에서는 final backup이 SKIP일 수 있으므로 자동 생성된다고 가정하지 마세요.
유료 DB System의 자동 백업 보존 기본값은 7일이며 1~35일로 설정할 수 있습니다. 수동 백업과 PITR은 해당 유료 시스템의 설정·지원 조건을 확인해야 합니다.
관리형 백업을 사용자 소유 Object Storage 버킷의 백업이라고 가정하지 말고, 별도의 논리 백업·복원 검증 계획도 마련하세요.
이는 현재 정책 설명이며 2025년 당시 정책을 소급 확정하는 내용은 아닙니다.
DB System의 저장 볼륨과 볼륨 백업은 기본적으로 암호화됩니다. 클라이언트 연결에는 TLS를 지원하지만, 실제 암호화 사용과 서버 인증서 검증은 클라이언트·계정 설정을 확인해야 합니다. 프라이빗 IP만으로 암호화가 확인되는 것은 아닙니다.
접속할 클라이언트에 필요한 경로와 보안 목록·NSG 규칙만 허용하도록 검토합니다. 네트워크 규칙, DB 계정 권한과 TLS는 서로 다른 확인 항목입니다.
OCI Free Tier에서 제공되는 스펙
아래 사양 표는 이 글에서 다루는 구성 예시입니다. 현재 제공되는 shape와 한도는 공식 문서와 생성 화면에서 확인해야 합니다. 블로그 운영에 충분한지는 데이터량, 플러그인 쿼리와 피크 부하를 측정해 판단하세요.
다음은 MySQL.Free DB System의 사양 예시입니다. HeatWave 클러스터의 메모리와는 구분합니다:
- CPU: 2개의 ECPU (Elastic Central Processing Unit)
- 처리 능력은 워크로드 측정으로 판단
- 동시 연결과 쿼리 부하 확인 필요
- 메모리: 8GiB RAM
- 메모리 사용량과 버퍼 설정 확인 필요
- 동시 쿼리 처리 성능은 별도 측정
- 저장공간: 50GiB
- 데이터량과 증가율을 기준으로 용량 산정
- 미디어 파일 본체와 DB 메타데이터 저장 위치 구분
- 네트워크: 최대 대역폭 1Gbps
- 실제 전송 성능은 경로와 부하에 따라 달라짐
- 백업 소요 시간과 복원 절차는 별도 검증
🔍 설치 전 확인할 사항
DB System을 만들기 전에 계정 권한, 네트워크 경로, 접속 정보와 백업 조건을 확인합니다. 생성 뒤에 바꾸기 어려운 항목은 미리 검토하세요.
OCI 계정과 컴파트먼트를 준비하고, 사용할 리소스에 필요한 권한이 있는지 확인합니다.
VCN과 서브넷은 데이터베이스의 네트워크 위치를 정합니다. 접속 허용 여부는 경로와 보안 목록·NSG 규칙 등을 함께 확인해야 합니다.
관리자 계정에는 서비스에서 정한 관리 권한이 부여됩니다. MySQL root와 동일한 권한으로 가정하지 말고, 서비스의 기본 권한과 실제 부여된 권한을 확인하세요.
비밀번호 요구사항, 네트워크 규칙과 계정 권한을 각각 점검합니다. 한 항목을 설정했다고 해서 나머지 접근 제어까지 확인된 것은 아닙니다.
필수 준비 사항
- OCI 계정 준비
- 사용할 테넌시·계정과 홈 리전 확인
- 로그인 정보 확인
- 컴파트먼트 확인
- WordPress-Compartment 생성 여부
- 적절한 권한 설정 확인
- 네트워크 구성 확인
- VCN 생성 상태
- 서브넷 구성 확인
- 보안 목록 설정 검토
- 관리자 계정 준비
- 안전한 비밀번호 생성
- 접근을 통제하는 비밀번호 관리자 또는 조직의 비밀정보 저장소
보안 관련 체크리스트
데이터베이스의 보안을 위해 다음 사항들을 반드시 확인하세요:
- 비밀번호 요구사항
- 현재 생성 화면의 길이·허용 문자 요구사항 확인
- 다른 서비스와 구분한 비밀번호 사용
- 비밀번호 관리자에서 생성·보관
- 댓글·화면 캡처·공유 문서에 비밀번호 노출 금지
- 네트워크 보안
- Private 서브넷 사용 확인
- 보안 규칙 설정 검토
🚀 단계별 MySQL HeatWave 설치 가이드
생성 단계마다 계정 권한, 네트워크와 DB System 설정을 확인합니다. 앞 단계에서 선택한 값이 다음 단계의 접속 조건에 영향을 줍니다.
아래 순서대로 생성 화면의 값을 확인하세요. 화면 구성과 지원 옵션은 서비스 변경에 따라 달라질 수 있습니다.
1단계: OCI 콘솔 접속하기
cloud.oracle.com에서 사용할 테넌시와 계정으로 로그인합니다. 리소스를 생성하기 전에 리전과 컴파트먼트가 맞는지 확인하세요.
다음은 일반적인 로그인 흐름입니다. 계정의 ID 도메인과 MFA 설정에 따라 화면이 달라질 수 있습니다:
- 웹 브라우저를 열고 cloud.oracle.com으로 이동합니다.
- 해당 계정의 인증 화면에서 필요한 정보를 입력합니다:
- 테넌시 이름
- 사용자 이름
- 비밀번호
- 계정에서 요구하는 추가 인증을 완료한 뒤 콘솔 화면을 확인합니다.
필요하면 사용자 프로파일의 표시 언어를 한국어로 변경하세요. 아래 이미지는 설정 위치를 설명하는 과거 화면이며, 현재 메뉴와 다를 수 있습니다.
2단계: MySQL HeatWave 서비스 찾기
콘솔 메뉴에서 Databases → MySQL HeatWave → DB Systems로 이동합니다. 이 화면에서 DB System을 생성하고 관리합니다.
아래 이미지는 메뉴 위치를 설명하는 예시입니다:
1. 왼쪽 상단의 햄버거 메뉴(☰)를 클릭합니다.
2. 메뉴에서 다음 순서로 이동합니다:
- ‘Databases’ 클릭
- ‘MySQL HeatWave’ 선택
- ‘DB Systems’ 클릭
3단계: 데이터베이스 시스템 생성
DB System의 이름, 컴파트먼트와 제공 옵션을 확인합니다. 이후 네트워크, 계정과 하드웨어 설정을 검토한 뒤 생성합니다.
WordPress-Compartment를 선택하면 관련 리소스를 같은 컴파트먼트에서 관리할 수 있습니다. 생성 권한과 선택 위치도 확인하세요.
다음 순서로 데이터베이스 시스템을 생성합니다:
1. ‘Create DB System’ 버튼을 클릭합니다.
2. 기본 정보를 입력합니다:
3. 중요: Always Free 구성을 사용할 계획이라면 해당 옵션과 최종 선택값을 확인하세요.
- 무료 대상 리소스와 테넌시 한도·홈 리전 조건을 확인합니다. 다른 리소스의 과금까지 면제되는 것은 아닙니다
- 유료 구성으로 이전할 때는 지원되는 이전·복원 경로, 비용과 중단 시간을 따로 검토합니다
4단계: 관리자 계정 설정하기
생성 화면의 계정명 요구사항과 예약된 사용자 이름 목록을 확인합니다. 예약어 제한을 지키는 것만으로 접근 제어가 완료되는 것은 아닙니다.
데이터베이스 관리자 계정을 설정합니다:
- 관리자 계정명 설정:
- 생성 화면의 계정명 길이와 허용 문자 요구사항 확인
- 서비스의 예약된 사용자 이름 목록 확인
- 애플리케이션용 계정과 관리자 계정의 역할 구분
- 안전한 비밀번호 생성:
- 현재 화면의 비밀번호 길이 요구사항 확인
- 길고 다른 서비스와 구분한 비밀번호 사용
- 비밀번호 관리자로 생성
- 현재 화면의 허용 문자·복잡도 요구사항 충족
- 비밀번호 관리자 또는 조직의 비밀정보 저장소에 보관
5단계: 네트워크 설정하기
WordPress-VCN과 데이터베이스를 배치할 서브넷을 선택합니다. 워드프레스 서버에서 해당 DB System으로 연결할 경로와 접근 규칙을 따로 확인해야 합니다.
프라이빗 서브넷의 리소스에는 공용 IP를 할당하지 않습니다. 같은 VCN이라는 이유만으로 접근이 허용되거나 차단되는 것은 아닙니다. 연결된 네트워크 경로와 보안 목록·NSG 규칙을 함께 검토하세요.
네트워크 설정은 다음 순서로 확인합니다:
- VCN 선택:
- WordPress-VCN 선택
- 이전 단계에서 생성한 VCN인지 확인
- 서브넷 선택:
- Private-Subnet 선택
- 보안을 위해 반드시 프라이빗 서브넷 사용
공용 IP 없이 DB System을 배치하고, 필요한 클라이언트의 접속만 허용하도록 경로와 보안 규칙을 구성하기 위해서입니다. 프라이빗 서브넷 선택만으로 접근 제어가 완료되지는 않습니다.
6단계: 배치 구성
가용성 도메인은 생성 화면에서 허용되는 선택과 서비스 한도를 확인합니다. 화면에 AD가 표시되어도 실제 용량이나 생성 성공을 보장하지 않으므로 작업 요청의 상태와 오류를 확인해야 합니다.
7단계: 하드웨어 구성
shape, 메모리와 구성 유형은 생성 화면에서 확인합니다. Standalone은 고가용성 구성과 구분해야 하며, 블로그의 처리 능력과 장애 복구 조건은 별도로 검토합니다.
저장 공간은 데이터량과 증가율, 지원되는 확장 조건을 기준으로 검토합니다. 초기 용량이 충분하다고 가정하거나 자동 확장 여부를 장점으로 해석하지 말고, 사용량과 한도를 확인하세요.
선택할 하드웨어와 저장 공간을 확인합니다:
1. 기본 설정:
2. 스토리지 설정:
50GiB
비활성화
Always Free: 자동 백업 1일
8단계: 최종 확인 및 생성
생성 전 모든 선택값과 무료 대상 여부를 다시 확인합니다. 무료 옵션 표시는 현재 계정의 사용량이나 다른 리소스의 과금까지 검증한 결과가 아닙니다.
알림을 설정했다면 수신 대상과 제공되는 이벤트 종류를 확인합니다. 주소를 입력한 것만으로 성능·장애 알림이 정상 전달된다고 판단하지 마세요.
1. 설정 검토:
- 모든 항목이 올바르게 설정되었는지 확인
- Free Tier 옵션이 선택되어 있는지 재확인
2. 알림 설정:
- 운영 공지와 예고되지 않은 유지보수 알림을 받을 주소 입력
- 성능·장애 모니터링 경보는 별도 구성·검증 항목으로 구분
3. 생성 버튼 클릭:
- 생성 시간은 가용 용량과 작업 상태에 따라 달라집니다. 10~15분은 보장된 소요 시간이 아닙니다
- 생성 상태와 오류 메시지를 확인하며 기다리세요.
✅ 설치 완료 확인하기
ACTIVE는 DB System이 생성되었음을 나타내는 수명주기 상태입니다. WordPress의 연결, 계정 권한과 쿼리 동작까지 정상이라는 뜻은 아니므로 각각 검증해야 합니다.
DB System 상세 화면에서 Private IP와 포트를 확인합니다. 워드프레스 서버에서의 접속 경로와 인증은 별도 확인 항목입니다.
생성 후에는 다음 항목을 확인하세요:
기본 확인 사항
- 상태 표시:
- ‘ACTIVE’ 상태로 표시되는지 확인
- 색상만 보지 말고 수명주기 상태와 오류 메시지 확인
- 네트워크 정보:
- Private IP 주소가 할당되었는지 확인
- 포트 번호 확인 (기본 3306)
- 연결 검증 계획:
- WordPress 서버에서 DB까지의 연결 경로·접근 규칙 확인
- 애플리케이션 계정의 인증·필요 권한 확인
- 암호화와 복구 확인:
- 클라이언트의 TLS 사용과 서버 인증서 검증 확인
- 지원되는 백업·복원 절차를 별도 환경에서 검증
중요 정보 기록
접속·백업 정보를 기록하되 비밀번호는 일반 문서와 분리해 보관합니다:
- 데이터베이스 접속 정보:
- Private IP 주소
- 포트 번호
- 관리자 계정명
- 비밀번호 관리자의 참조 위치(비밀번호 값은 기재하지 않음)
- 백업 관련 정보:
- 백업 스케줄
- 백업 보관 기간
- 관리형 백업 식별 정보와 별도 논리 백업의 보관 위치 구분
💡 효율적인 관리를 위한 팁
느린 쿼리와 데이터 증가량을 확인한 뒤 정리·인덱스 변경의 필요성을 판단합니다. 테이블 삭제나 인덱스 변경은 백업과 의존 관계, 예상 부하를 검토한 별도 작업으로 진행하세요.
접속 로그와 계정 권한을 검토하고, 사용하는 버전의 보안 패치·업데이트 절차를 확인합니다. 자격 증명 관리와 변경은 조직의 정책에 따릅니다.
운영 중에는 다음 항목을 점검하세요:
성능 관리
정기적으로 다음 사항들을 체크하세요:
- 데이터베이스 정리:
- 테이블 정리 필요성과 의존 관계 검토
- 임시 데이터 정리
- 쿼리 실행 계획과 인덱스 사용 점검
- 백업 관리:
- 정기적인 백업 확인
- 복구 테스트 수행
- 백업 공간 모니터링
보안 관리
보안을 위해 다음 사항들을 주기적으로 점검하세요:
- 접근 제어:
- 조직 정책에 따른 자격 증명 관리
- 접속 로그 검토
- 권한 설정 검토
- 업데이트 관리:
- 보안 패치 적용
- 버전 업데이트 확인
- 설정 최적화
삭제 계획(Deletion Plan)에서 Require final backup을 선택해 생성하는 Always Free 최종 백업은 7일 보존됩니다. 기본 삭제 계획에서는 final backup이 SKIP일 수 있으므로 자동 생성된다고 가정하지 마세요.
유료 DB System의 자동 백업 보존 기본값은 7일이며 1~35일로 설정할 수 있습니다. 수동 백업과 PITR은 해당 유료 시스템의 설정·지원 조건을 확인해야 합니다.
관리형 백업을 사용자 소유 Object Storage 버킷의 백업이라고 가정하지 말고, 별도의 논리 백업·복원 검증 계획도 마련하세요.
이는 현재 정책 설명이며 2025년 당시 정책을 소급 확정하는 내용은 아닙니다.
DB System을 생성한 뒤에는 워드프레스 서버의 연결과 백업·복원 조건을 확인해야 합니다. 다음 글에서 워드프레스 설치와 데이터베이스 연결을 이어서 다룹니다.