RDS 연결과 관리 완벽 가이드

AWS RDS를 처음 접하는 개발자를 위한 실전 가이드입니다. 엔드포인트 확인부터 모니터링까지, 실무에서 꼭 알아야 할 RDS 관리 핵심 개념을 이북처럼 술술 읽히는 스토리로 풀어냈습니다. 데이터베이스 연결과 운영의 모든 것을 경험해보세요.

---

목차

1. RDS_엔드포인트_확인
2. DB_클라이언트로_접속
3. 보안_그룹_설정
4. 자동_백업_설정
5. 스냅샷_생성과_복원
6. RDS_모니터링

---

1. RDS 엔드포인트 확인

어느 날 신입 개발자 김개발 씨는 선배로부터 "RDS 연결해서 데이터 좀 가져와봐"라는 업무를 받았습니다. AWS 콘솔에 로그인은 했는데, 도대체 어디에 연결해야 하는 걸까요?

RDS 엔드포인트를 찾지 못해 한참을 헤매던 김개발 씨는 결국 선배에게 다시 물어볼 수밖에 없었습니다.

RDS 엔드포인트는 데이터베이스에 접속하기 위한 주소입니다. 마치 집에 방문하려면 주소를 알아야 하는 것처럼, 데이터베이스에 연결하려면 엔드포인트를 알아야 합니다.

엔드포인트는 호스트명과 포트 번호로 구성되어 있으며, AWS 콘솔에서 쉽게 확인할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK를 사용한 RDS 엔드포인트 확인
const AWS = require('aws-sdk');
const rds = new AWS.RDS({ region: 'ap-northeast-2' });

async function getRDSEndpoint(dbInstanceIdentifier) {
  try {
    // RDS 인스턴스 정보를 가져옵니다
    const params = { DBInstanceIdentifier: dbInstanceIdentifier };
    const data = await rds.describeDBInstances(params).promise();

    // 엔드포인트 정보 추출
    const endpoint = data.DBInstances[0].Endpoint;
    console.log(`호스트: ${endpoint.Address}`);
    console.log(`포트: ${endpoint.Port}`);

    return endpoint;
  } catch (error) {
    console.error('엔드포인트 조회 실패:', error);
  }
}

박시니어 씨가 김개발 씨의 모니터를 보며 웃었습니다. "아, RDS 엔드포인트를 못 찾았구나.

이건 정말 기본 중의 기본인데." 김개발 씨는 조금 민망했지만, 이참에 제대로 배워두기로 마음먹었습니다. "엔드포인트가 정확히 뭔가요?" 엔드포인트란 무엇일까요?

쉽게 말하면 데이터베이스의 주소입니다. 우리가 친구 집에 놀러 가려면 주소를 알아야 하는 것처럼, 애플리케이션이 데이터베이스에 접속하려면 그 위치를 알아야 합니다.

RDS 엔드포인트는 크게 두 가지 정보로 구성됩니다. 하나는 호스트명이고, 다른 하나는 포트 번호입니다.

호스트명은 보통 mydb.abcdefg.ap-northeast-2.rds.amazonaws.com 같은 형태입니다. 길고 복잡해 보이지만, 각 부분마다 의미가 있습니다.

엔드포인트가 없던 시절에는 어땠을까요? 실제로 엔드포인트는 항상 존재했습니다.

다만 초보 개발자들이 이것을 찾는 방법을 몰라서 당황하곤 합니다. AWS 콘솔에서 엔드포인트를 확인하는 방법은 간단합니다.

먼저 RDS 서비스로 이동합니다. 왼쪽 메뉴에서 데이터베이스를 클릭하면, 생성된 RDS 인스턴스 목록이 보입니다.

여기서 원하는 데이터베이스를 클릭하면, 상세 정보 페이지가 나타납니다. 상세 정보 페이지의 연결 섹션을 보면, 엔드포인트와 포트 정보가 명확하게 표시되어 있습니다.

이것을 복사해서 애플리케이션 설정 파일에 붙여넣으면 됩니다. 프로그래밍 방식으로 엔드포인트를 확인할 수도 있습니다.

위의 코드를 보면, AWS SDK의 describeDBInstances 메서드를 사용하고 있습니다. 이 메서드는 지정한 RDS 인스턴스의 모든 정보를 반환합니다.

반환된 데이터에서 Endpoint 객체를 추출하면, Address와 Port 속성을 통해 엔드포인트 정보를 얻을 수 있습니다. 이 방식은 특히 자동화 스크립트나 인프라 코드에서 유용합니다.

실무에서는 엔드포인트를 환경 변수로 관리하는 것이 일반적입니다. 개발 환경과 운영 환경의 RDS가 다르기 때문입니다.

.env 파일에 DB_HOST와 DB_PORT를 저장해두고, 코드에서는 이 환경 변수를 참조합니다. 주의할 점이 있습니다.

RDS 엔드포인트는 인스턴스를 삭제하고 다시 만들면 바뀝니다. 따라서 하드코딩하지 말고, 항상 설정 파일이나 환경 변수로 관리해야 합니다.

또한 엔드포인트는 공개 정보가 아니므로, 깃허브 같은 공개 저장소에 올리면 안 됩니다. 박시니어 씨의 설명을 들은 김개발 씨는 이제 자신있게 RDS에 연결할 수 있게 되었습니다.

"생각보다 어렵지 않네요!" 엔드포인트는 RDS 사용의 첫걸음입니다. 정확한 엔드포인트만 있으면, 데이터베이스 연결은 금방입니다.

실전 팁

💡 - 엔드포인트 정보는 환경 변수로 관리하여 보안을 유지하세요

• 프로덕션과 개발 환경의 엔드포인트를 명확히 구분하세요

---

2. DB 클라이언트로 접속

엔드포인트를 확인한 김개발 씨는 이제 실제로 데이터베이스에 접속해보려 합니다. 하지만 어떤 도구를 사용해야 할까요?

터미널에서 직접 접속할 수도 있고, GUI 도구를 사용할 수도 있습니다. 선배는 "일단 MySQL Workbench로 연결해봐"라고 말했지만, 김개발 씨는 Node.js 코드로도 접속하고 싶었습니다.

DB 클라이언트는 데이터베이스에 접속하여 쿼리를 실행하는 도구입니다. 마치 웹 브라우저가 웹사이트를 보여주는 것처럼, DB 클라이언트는 데이터베이스를 다룰 수 있게 해줍니다.

GUI 기반 도구와 프로그래밍 라이브러리 두 가지 방식이 있으며, 상황에 따라 적절한 방법을 선택할 수 있습니다.

다음 코드를 살펴봅시다.

// Node.js에서 MySQL RDS에 연결하기
const mysql = require('mysql2/promise');

async function connectToRDS() {
  try {
    // RDS 연결 설정
    const connection = await mysql.createConnection({
      host: process.env.DB_HOST,
      port: process.env.DB_PORT || 3306,
      user: process.env.DB_USER,
      password: process.env.DB_PASSWORD,
      database: process.env.DB_NAME,
      connectTimeout: 10000 // 10초 타임아웃
    });

    console.log('RDS 연결 성공!');

    // 간단한 쿼리 실행
    const [rows] = await connection.execute('SELECT NOW() as currentTime');
    console.log('현재 시간:', rows[0].currentTime);

    await connection.end();
  } catch (error) {
    console.error('연결 실패:', error.message);
  }
}

김개발 씨는 드디어 실전 단계에 돌입했습니다. 엔드포인트도 알았고, 이제 실제로 연결만 하면 됩니다.

하지만 막상 코드를 작성하려니 막막합니다. "클라이언트 라이브러리가 여러 개인데, 어떤 걸 써야 하죠?" 김개발 씨가 물었습니다.

DB 클라이언트란 무엇일까요? 쉽게 비유하자면, 외국인과 대화할 때 통역사가 필요한 것과 같습니다.

우리 애플리케이션은 한국어를 쓰고, 데이터베이스는 SQL이라는 언어를 씁니다. DB 클라이언트가 바로 이 통역 역할을 합니다.

DB 클라이언트는 크게 두 가지 형태로 나뉩니다. 첫 번째는 MySQL Workbench, DBeaver 같은 GUI 도구입니다.

이런 도구는 사람이 직접 데이터베이스를 관리하고 쿼리를 실행할 때 편리합니다. 시각적으로 테이블 구조를 보고, 클릭 몇 번으로 데이터를 조회할 수 있습니다.

두 번째는 프로그래밍 라이브러리입니다. Node.js에서는 mysql2, pg, sequelize 같은 라이브러리를 사용합니다.

Python에서는 pymysql, psycopg2를, Java에서는 JDBC를 사용합니다. 이런 라이브러리는 애플리케이션 코드에서 데이터베이스를 다룰 때 필요합니다.

클라이언트 라이브러리가 없던 시절에는 어땠을까요? 사실 불가능했습니다.

데이터베이스는 특정 프로토콜로 통신하기 때문에, 이를 이해하는 라이브러리 없이는 접근할 수 없습니다. 위의 코드를 살펴보겠습니다.

먼저 mysql2/promise 라이브러리를 불러옵니다. 이 라이브러리는 MySQL과 호환되는 데이터베이스에 연결할 수 있게 해줍니다.

RDS MySQL도 표준 MySQL 프로토콜을 사용하므로 문제없이 작동합니다. createConnection 메서드에는 여러 옵션을 전달합니다.

host는 앞서 확인한 엔드포인트 주소입니다. port는 보통 3306이지만, RDS 설정에 따라 다를 수 있습니다.

user와 password는 RDS 인스턴스 생성 시 설정한 마스터 계정 정보입니다. 중요한 옵션 하나는 connectTimeout입니다.

네트워크 문제로 연결이 안 될 때 무한정 기다리지 않도록, 제한 시간을 설정합니다. 보통 10초면 충분합니다.

연결이 성공하면, execute 메서드로 쿼리를 실행할 수 있습니다. 예제에서는 SELECT NOW()를 실행하여 데이터베이스의 현재 시간을 가져옵니다.

간단한 쿼리지만, 연결이 제대로 되었는지 확인하는 좋은 방법입니다. 실무에서는 연결 풀을 사용하는 것이 일반적입니다.

매번 새로운 연결을 만들고 닫는 것은 비효율적이기 때문입니다. mysql2의 createPool 메서드를 사용하면, 연결을 재사용할 수 있어 성능이 크게 향상됩니다.

주의할 점이 있습니다. 비밀번호는 절대 코드에 하드코딩하면 안 됩니다.

위 예제처럼 환경 변수로 관리해야 합니다. 또한 사용이 끝난 연결은 반드시 end() 메서드로 닫아야 합니다.

그렇지 않으면 연결이 누적되어 RDS의 최대 연결 수를 초과할 수 있습니다. 김개발 씨는 코드를 실행해보았습니다.

"RDS 연결 성공!"이라는 메시지가 출력되었습니다. 드디어 클라우드 데이터베이스와 소통할 수 있게 된 것입니다.

DB 클라이언트를 제대로 사용하면, 로컬 데이터베이스든 클라우드 데이터베이스든 동일한 방식으로 다룰 수 있습니다.

실전 팁

💡 - 연결 풀을 사용하여 성능을 최적화하세요

• 연결 정보는 환경 변수로 관리하고, 사용 후 반드시 연결을 닫으세요

---

3. 보안 그룹 설정

김개발 씨가 로컬 환경에서 RDS 연결을 시도했는데, 타임아웃 에러가 발생했습니다. 코드는 분명히 맞는데 왜 연결이 안 될까요?

박시니어 씨가 한마디 했습니다. "보안 그룹 확인해봤어?" 김개발 씨는 보안 그룹이 뭔지도 몰랐습니다.

AWS의 방화벽 설정이 문제였던 것입니다.

'개발자 로컬 환경' }] }] }; // 인바운드 규칙 추가 await ec2.authorizeSecurityGroupIngress(params).promise(); console.log('보안 그룹 규칙 추가 완료!'); } catch (error) { console.error('규칙 추가 실패:', error.message); } }

다음 코드를 살펴봅시다.

// AWS SDK로 보안 그룹 인바운드 규칙 추가
const AWS = require('aws-sdk');
const ec2 = new AWS.EC2({ region: 'ap-northeast-2' });

async function addSecurityGroupRule(groupId, myIP) {
  try {
    const params = {
      GroupId: groupId,
      IpPermissions: [{
        IpProtocol: 'tcp',
        FromPort: 3306,
        ToPort: 3306,
        IpRanges: [{
          CidrIp: `${myIP}/32`,

김개발 씨는 당황했습니다. 코드도 맞고, 엔드포인트도 맞는데 왜 연결이 안 되는 걸까요?

에러 메시지는 Connection timed out이었습니다. 박시니어 씨가 AWS 콘솔을 열어보라고 했습니다.

"RDS 인스턴스의 보안 그룹을 확인해봐." 보안 그룹이란 무엇일까요? 쉽게 비유하자면, 아파트 경비실과 같습니다.

아무나 아파트에 들어갈 수 없듯이, 아무 IP 주소에서나 RDS에 접속할 수 없습니다. 경비실에서 방문 목적과 방문자 신원을 확인하는 것처럼, 보안 그룹은 접속 시도를 검사합니다.

보안 그룹은 인바운드 규칙과 아웃바운드 규칙으로 구성됩니다. 인바운드 규칙은 들어오는 트래픽을 제어하고, 아웃바운드 규칙은 나가는 트래픽을 제어합니다.

RDS의 경우 주로 인바운드 규칙이 중요합니다. 보안 그룹이 없던 시절에는 어땠을까요?

사실 클라우드 이전 시대에는 물리적 방화벽 장비를 사용했습니다. 하지만 설정이 복잡하고 비용도 많이 들었습니다.

AWS는 이를 소프트웨어로 구현하여, 클릭 몇 번으로 방화벽을 설정할 수 있게 만들었습니다. 기본적으로 RDS는 모든 접속을 차단합니다.

명시적으로 허용하지 않으면, 아무도 접속할 수 없습니다. 이것이 바로 김개발 씨가 연결할 수 없었던 이유입니다.

AWS 콘솔에서 보안 그룹을 설정하는 방법을 알아봅시다. RDS 인스턴스 상세 페이지의 연결 섹션을 보면, 보안 그룹 링크가 있습니다.

이것을 클릭하면 EC2 보안 그룹 페이지로 이동합니다. 인바운드 규칙 탭을 보면, 현재 허용된 IP 주소 목록이 나옵니다.

만약 비어있다면, 아무도 접속할 수 없는 상태입니다. 규칙 편집 버튼을 클릭하여 새 규칙을 추가합니다.

규칙 추가 시 세 가지 정보를 입력합니다. 첫째, 프로토콜 타입은 MySQL/Aurora를 선택합니다.

이렇게 하면 포트가 자동으로 3306으로 설정됩니다. 둘째, 소스는 내 IP를 선택하면 현재 내 공인 IP 주소가 자동으로 입력됩니다.

셋째, 설명을 입력하여 나중에 이 규칙이 무엇인지 알 수 있게 합니다. 위의 코드는 프로그래밍 방식으로 보안 그룹 규칙을 추가하는 예제입니다.

authorizeSecurityGroupIngress 메서드를 사용하면, 수동으로 콘솔을 조작하지 않고도 규칙을 추가할 수 있습니다. 인프라 자동화에 유용합니다.

실무에서는 보안을 위해 특정 IP 주소만 허용하는 것이 좋습니다. 0.0.0.0/0으로 설정하면 전 세계 모든 IP에서 접속할 수 있게 되어 위험합니다.

회사 사무실 IP나, EC2 인스턴스가 속한 보안 그룹만 허용하는 것이 안전합니다. 주의할 점이 있습니다.

개발자 개인 PC의 IP는 자주 바뀝니다. 특히 카페나 집에서 작업할 때마다 IP가 달라지므로, 매번 보안 그룹을 업데이트해야 할 수 있습니다.

이것이 번거롭다면, VPN을 사용하거나 EC2 배스천 호스트를 통해 접속하는 방법도 있습니다. 김개발 씨는 자신의 IP 주소를 보안 그룹에 추가했습니다.

다시 연결을 시도하니, 이번에는 성공했습니다. "드디어 되네요!" 보안 그룹은 RDS 보안의 첫 번째 방어선입니다.

올바르게 설정하면, 데이터베이스를 안전하게 보호할 수 있습니다.

실전 팁

💡 - 특정 IP만 허용하고, 0.0.0.0/0은 절대 사용하지 마세요

• 규칙에 설명을 추가하여 나중에 관리하기 쉽게 만드세요

---

4. 자동 백업 설정

어느 날 김개발 씨가 실수로 중요한 데이터를 삭제했습니다. 당황한 김개발 씨는 박시니어 씨에게 달려갔습니다.

다행히 박시니어 씨는 침착하게 말했습니다. "걱정 마.

자동 백업이 있으니까 복원하면 돼." RDS의 자동 백업 덕분에 데이터를 모두 복구할 수 있었습니다. 백업이 얼마나 중요한지 깨달은 순간이었습니다.

자동 백업은 RDS가 정기적으로 데이터베이스 전체를 백업하는 기능입니다. 마치 컴퓨터 파일을 외장 하드에 백업하는 것처럼, RDS는 설정한 시간에 자동으로 백업을 수행합니다.

백업 보관 기간을 설정할 수 있으며, 필요할 때 특정 시점으로 복원할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK로 RDS 자동 백업 설정 수정
const AWS = require('aws-sdk');
const rds = new AWS.RDS({ region: 'ap-northeast-2' });

async function modifyBackupSettings(dbInstanceIdentifier) {
  try {
    const params = {
      DBInstanceIdentifier: dbInstanceIdentifier,
      BackupRetentionPeriod: 7, // 7일간 백업 보관
      PreferredBackupWindow: '03:00-04:00', // 새벽 3-4시에 백업
      ApplyImmediately: false // 다음 유지 관리 기간에 적용
    };

    // 백업 설정 수정
    const result = await rds.modifyDBInstance(params).promise();
    console.log('백업 설정 변경 완료!');
    console.log(`보관 기간: ${params.BackupRetentionPeriod}일`);
    console.log(`백업 시간: ${params.PreferredBackupWindow}`);

    return result;
  } catch (error) {
    console.error('설정 변경 실패:', error.message);
  }
}

김개발 씨의 얼굴은 새하얗게 질렸습니다. 실수로 DELETE 쿼리를 WHERE 절 없이 실행해버린 것입니다.

테이블의 모든 데이터가 사라졌습니다. "선배님, 큰일 났어요!" 김개발 씨가 다급하게 외쳤습니다.

자동 백업이란 무엇일까요? 쉽게 비유하자면, 타임머신과 같습니다.

과거의 특정 시점으로 돌아갈 수 있는 기능입니다. RDS는 매일 자동으로 데이터베이스의 스냅샷을 찍어둡니다.

RDS의 자동 백업은 두 가지 방식으로 작동합니다. 첫째, 매일 지정된 시간에 전체 스냅샷을 생성합니다.

둘째, 트랜잭션 로그를 계속 백업합니다. 이 두 가지를 조합하면, 보관 기간 내의 어느 시점으로든 복원할 수 있습니다.

자동 백업이 없던 시절에는 어땠을까요? DBA가 수동으로 백업 스크립트를 작성하고, cron으로 스케줄링했습니다.

백업이 실패해도 알림이 없어서, 나중에야 문제를 발견하곤 했습니다. RDS는 이 모든 과정을 자동화했습니다.

백업 보관 기간은 0일부터 35일까지 설정할 수 있습니다. 0일로 설정하면 자동 백업이 비활성화됩니다.

하지만 이것은 절대 권장하지 않습니다. 최소 7일은 설정하는 것이 좋습니다.

백업 윈도우는 백업이 실행되는 시간대입니다. 서비스 트래픽이 적은 시간대를 선택해야 합니다.

백업 중에는 I/O 성능이 일시적으로 저하될 수 있기 때문입니다. 보통 새벽 시간을 선택합니다.

위의 코드를 살펴보겠습니다. modifyDBInstance 메서드로 RDS 인스턴스의 설정을 변경할 수 있습니다.

BackupRetentionPeriod는 백업을 얼마나 오래 보관할지 결정합니다. 7일로 설정하면, 최근 7일 동안의 어느 시점으로든 복원할 수 있습니다.

PreferredBackupWindow는 백업 시간대를 지정합니다. UTC 기준으로 입력하므로, 한국 시간(KST)에서 9시간을 빼야 합니다.

예를 들어 한국 시간 오전 3시는 UTC 오후 6시입니다. 그러니 18:00-19:00으로 설정해야 합니다.

아니면 코드처럼 03:00-04:00으로 설정하면, UTC 기준 새벽 3-4시에 백업됩니다. ApplyImmediately 옵션은 변경 사항을 즉시 적용할지 결정합니다.

false로 설정하면, 다음 유지 관리 기간에 적용됩니다. 백업 설정 변경은 보통 즉시 적용할 필요가 없으므로, false가 안전합니다.

실무에서는 백업 모니터링도 중요합니다. CloudWatch를 통해 백업 성공 여부를 확인하고, 실패 시 알림을 받도록 설정해야 합니다.

백업은 있는데 복원이 안 된다면 의미가 없기 때문에, 주기적으로 백업 복원 테스트를 수행하는 것도 좋은 습관입니다. 주의할 점이 있습니다.

자동 백업은 인스턴스를 삭제하면 함께 삭제됩니다. 인스턴스를 삭제하기 전에 최종 스냅샷을 생성하는 옵션을 반드시 선택해야 합니다.

그렇지 않으면 데이터를 영구적으로 잃게 됩니다. 박시니어 씨는 AWS 콘솔에서 자동 백업을 이용해 30분 전 시점으로 복원했습니다.

김개발 씨가 삭제한 데이터가 모두 돌아왔습니다. "휴, 다행이다..." 자동 백업은 재해 복구의 핵심입니다.

제대로 설정해두면, 어떤 실수에도 대응할 수 있습니다.

실전 팁

💡 - 백업 보관 기간은 최소 7일 이상으로 설정하세요

• 트래픽이 적은 새벽 시간을 백업 윈도우로 지정하세요

---

5. 스냅샷 생성과 복원

자동 백업으로 위기를 넘긴 김개발 씨는 궁금증이 생겼습니다. "선배님, 자동 백업 말고 수동으로 백업하는 방법도 있나요?" 박시니어 씨가 고개를 끄덕였습니다.

"그게 바로 스냅샷이야. 중요한 작업 전에는 수동으로 스냅샷을 찍어두는 게 좋아." 대규모 마이그레이션이나 스키마 변경 전에는 스냅샷이 필수라고 합니다.

스냅샷은 특정 시점의 데이터베이스 상태를 저장하는 수동 백업입니다. 마치 사진을 찍듯이, 현재 데이터베이스의 모습을 그대로 보존합니다.

자동 백업과 달리 수동으로 생성하고, 명시적으로 삭제하기 전까지 영구적으로 보관됩니다. 스냅샷을 이용하면 새로운 RDS 인스턴스를 생성하거나 기존 인스턴스를 복원할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK로 RDS 스냅샷 생성 및 복원
const AWS = require('aws-sdk');
const rds = new AWS.RDS({ region: 'ap-northeast-2' });

async function createAndRestoreSnapshot(dbInstanceId) {
  try {
    // 스냅샷 생성
    const snapshotId = `${dbInstanceId}-snapshot-${Date.now()}`;
    const createParams = {
      DBInstanceIdentifier: dbInstanceId,
      DBSnapshotIdentifier: snapshotId
    };

    console.log('스냅샷 생성 중...');
    await rds.createDBSnapshot(createParams).promise();
    console.log(`스냅샷 생성 완료: ${snapshotId}`);

    // 스냅샷에서 새 인스턴스 복원
    const restoreParams = {
      DBInstanceIdentifier: `${dbInstanceId}-restored`,
      DBSnapshotIdentifier: snapshotId
    };

    console.log('스냅샷에서 복원 중...');
    await rds.restoreDBInstanceFromDBSnapshot(restoreParams).promise();
    console.log('복원 완료!');
  } catch (error) {
    console.error('작업 실패:', error.message);
  }
}

김개발 씨는 다음 주에 큰 데이터베이스 마이그레이션이 예정되어 있었습니다. 박시니어 씨는 작업 전에 스냅샷을 찍으라고 조언했습니다.

"스냅샷과 자동 백업은 뭐가 다른가요?" 김개발 씨가 물었습니다. 스냅샷이란 무엇일까요?

쉽게 비유하자면, 중요한 순간을 기념사진으로 남기는 것과 같습니다. 자동 백업이 매일 찍는 일상 사진이라면, 스냅샷은 특별한 날을 위해 찍는 기념사진입니다.

자동 백업과 스냅샷의 가장 큰 차이는 보관 기간입니다. 자동 백업은 설정한 보관 기간이 지나면 자동으로 삭제됩니다.

하지만 스냅샷은 수동으로 삭제하기 전까지 영구적으로 보관됩니다. 또 다른 차이는 생성 시점입니다.

자동 백업은 RDS가 정해진 시간에 자동으로 수행합니다. 반면 스냅샷은 개발자가 필요할 때 직접 생성합니다.

중요한 배포나 마이그레이션 직전에 스냅샷을 찍어두는 것이 일반적입니다. 스냅샷이 없던 시절에는 어땠을까요?

수동 백업을 위해 mysqldump 같은 도구를 사용했습니다. 하지만 대용량 데이터베이스는 덤프하는 데 몇 시간씩 걸렸고, 서비스를 중단해야 하는 경우도 많았습니다.

AWS 콘솔에서 스냅샷을 생성하는 방법은 간단합니다. RDS 인스턴스를 선택하고, 작업 메뉴에서 스냅샷 생성을 클릭합니다.

스냅샷 이름을 입력하면, RDS가 백그라운드에서 스냅샷을 생성합니다. 스냅샷 생성은 보통 몇 분에서 수십 분 정도 걸립니다.

데이터베이스 크기에 따라 시간이 달라집니다. 중요한 점은, 스냅샷 생성 중에도 데이터베이스는 정상적으로 작동한다는 것입니다.

다운타임이 없습니다. 위의 코드를 살펴보겠습니다.

createDBSnapshot 메서드로 스냅샷을 생성합니다. 스냅샷 ID는 고유해야 하므로, 타임스탬프를 붙여서 중복을 방지합니다.

스냅샷 생성은 비동기로 처리되므로, 완료까지 시간이 걸립니다. restoreDBInstanceFromDBSnapshot 메서드로 스냅샷에서 새 인스턴스를 생성합니다.

주의할 점은, 기존 인스턴스를 덮어쓰는 것이 아니라 새 인스턴스를 만든다는 것입니다. 새 인스턴스의 ID는 기존과 달라야 합니다.

실무에서는 스냅샷을 다른 리전으로 복사하는 것도 중요합니다. 재해 복구 계획의 일환으로, 주 리전이 장애가 나도 다른 리전에서 서비스를 복구할 수 있도록 준비해둡니다.

주의할 점이 있습니다. 스냅샷은 저장 비용이 발생합니다.

S3에 저장되므로, 크기에 따라 비용이 청구됩니다. 오래된 스냅샷은 주기적으로 삭제하여 비용을 관리해야 합니다.

김개발 씨는 마이그레이션 전에 스냅샷을 생성했습니다. 다행히 마이그레이션은 성공적이었지만, 스냅샷이 있다는 사실만으로도 마음이 편했습니다.

"백업이 있으니까 든든하네요." 스냅샷은 데이터 보호의 마지막 안전망입니다. 중요한 작업 전에는 반드시 스냅샷을 생성하세요.

실전 팁

💡 - 중요한 배포나 마이그레이션 전에는 반드시 스냅샷을 생성하세요

• 오래된 스냅샷은 정기적으로 삭제하여 비용을 절감하세요

---

6. RDS 모니터링

며칠 후, 김개발 씨는 갑자기 느려진 서비스를 마주했습니다. 사용자들의 불만이 쏟아졌고, 원인을 찾아야 했습니다.

박시니어 씨가 CloudWatch를 열어 보더니 말했습니다. "CPU 사용률이 100%네.

슬로우 쿼리 로그 확인해봐." RDS 모니터링을 제대로 했다면 문제를 미리 예방할 수 있었을 것입니다.

RDS 모니터링은 데이터베이스의 성능과 상태를 실시간으로 추적하는 기능입니다. 마치 자동차 계기판이 속도와 연료를 보여주는 것처럼, CloudWatch는 CPU, 메모리, 디스크 I/O 등의 지표를 시각화합니다.

이를 통해 성능 저하를 조기에 발견하고, 문제를 해결할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK로 RDS CloudWatch 메트릭 조회
const AWS = require('aws-sdk');
const cloudwatch = new AWS.CloudWatch({ region: 'ap-northeast-2' });

async function getRDSMetrics(dbInstanceId) {
  try {
    const endTime = new Date();
    const startTime = new Date(endTime - 3600000); // 1시간 전

    const params = {
      Namespace: 'AWS/RDS',
      MetricName: 'CPUUtilization',
      Dimensions: [{
        Name: 'DBInstanceIdentifier',
        Value: dbInstanceId
      }],
      StartTime: startTime,
      EndTime: endTime,
      Period: 300, // 5분 단위
      Statistics: ['Average', 'Maximum']
    };

    // CPU 사용률 조회
    const data = await cloudwatch.getMetricStatistics(params).promise();

    console.log('최근 1시간 CPU 사용률:');
    data.Datapoints.forEach(point => {
      console.log(`시간: ${point.Timestamp}, 평균: ${point.Average.toFixed(2)}%, 최대: ${point.Maximum.toFixed(2)}%`);
    });
  } catch (error) {
    console.error('메트릭 조회 실패:', error.message);
  }
}

김개발 씨는 황급히 AWS 콘솔을 열었습니다. RDS 인스턴스의 모니터링 탭을 클릭하니, 여러 그래프가 나타났습니다.

그런데 무엇을 봐야 할지 몰랐습니다. "선배님, 이 그래프들이 다 뭐죠?" 김개발 씨가 물었습니다.

RDS 모니터링이란 무엇일까요? 쉽게 비유하자면, 건강 검진과 같습니다.

정기적으로 혈압, 혈당, 콜레스테롤을 체크하듯이, RDS도 주요 지표를 계속 측정합니다. 이상 징후가 발견되면, 큰 문제가 되기 전에 조치를 취할 수 있습니다.

RDS는 기본적으로 CloudWatch와 통합되어 있습니다. CloudWatch는 AWS의 모니터링 서비스로, 다양한 메트릭을 수집하고 시각화합니다.

별도 설정 없이도 기본 메트릭이 자동으로 수집됩니다. 가장 중요한 메트릭은 CPU 사용률입니다.

CPU가 지속적으로 80% 이상이면, 인스턴스 크기를 늘리거나 쿼리를 최적화해야 합니다. 일시적인 스파이크는 괜찮지만, 장시간 유지되면 문제입니다.

두 번째로 중요한 메트릭은 데이터베이스 연결 수입니다. RDS는 인스턴스 타입에 따라 최대 연결 수가 정해져 있습니다.

최대치에 도달하면, 새로운 연결 요청이 거부됩니다. 연결 풀을 적절히 설정하여 관리해야 합니다.

세 번째는 읽기/쓰기 지연 시간입니다. 디스크 I/O 성능을 나타내는 지표로, 지연 시간이 길면 쿼리 응답이 느려집니다.

프로비저닝된 IOPS를 늘리거나, 더 빠른 스토리지 타입으로 변경하는 것을 고려해야 합니다. 네 번째는 여유 스토리지 공간입니다.

디스크가 가득 차면 데이터베이스가 멈출 수 있습니다. 자동 스토리지 확장 기능을 활성화하면, 여유 공간이 부족할 때 자동으로 용량을 늘려줍니다.

위의 코드를 살펴보겠습니다. getMetricStatistics 메서드로 CloudWatch 메트릭을 조회합니다.

최근 1시간 동안의 CPU 사용률을 5분 단위로 가져옵니다. 평균과 최댓값을 함께 조회하여, 순간 스파이크도 파악할 수 있습니다.

실무에서는 CloudWatch 알람을 설정하는 것이 필수입니다. 예를 들어 CPU 사용률이 80%를 5분간 초과하면 이메일이나 슬랙으로 알림을 받도록 설정합니다.

이렇게 하면 장애가 발생하기 전에 대응할 수 있습니다. Enhanced Monitoring을 활성화하면, 더 상세한 OS 레벨 메트릭을 볼 수 있습니다.

프로세스별 CPU 사용률, 메모리 사용 패턴 등을 1초 단위로 수집합니다. 심층 분석이 필요할 때 유용합니다.

Performance Insights는 쿼리 수준의 성능 분석 도구입니다. 어떤 쿼리가 가장 많은 리소스를 사용하는지, 어떤 대기 이벤트가 발생하는지 보여줍니다.

슬로우 쿼리를 찾아 최적화할 때 매우 유용합니다. 주의할 점이 있습니다.

모니터링 데이터는 과거 기록을 보는 것도 중요하지만, 트렌드를 파악하는 것이 더 중요합니다. 점진적으로 증가하는 CPU 사용률은, 곧 용량 한계에 도달할 것을 예고합니다.

김개발 씨는 Performance Insights에서 문제 쿼리를 찾아냈습니다. 인덱스가 없는 컬럼으로 조인하는 쿼리가 범인이었습니다.

인덱스를 추가하니, CPU 사용률이 정상으로 돌아왔습니다. "모니터링을 진작 봤어야 했는데..." RDS 모니터링은 안정적인 서비스 운영의 핵심입니다.

지표를 주기적으로 확인하고, 알람을 설정하여 문제를 예방하세요.

실전 팁

💡 - CloudWatch 알람을 설정하여 임계치 초과 시 즉시 알림을 받으세요

• Performance Insights로 슬로우 쿼리를 찾아 최적화하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!