AWS RDS 데이터베이스 생성 완벽 가이드

AWS RDS를 처음 접하는 개발자를 위한 안내서입니다. 데이터베이스 인스턴스 생성부터 서브넷 그룹, 파라미터 그룹 설정까지 실무에 필요한 모든 것을 다룹니다. 초급 개발자도 쉽게 따라할 수 있도록 단계별로 설명합니다.

1. RDS란 무엇인가

김개발 씨는 드디어 첫 프로젝트에서 데이터베이스를 구축하는 임무를 맡았습니다. "EC2에 MySQL을 직접 설치해야 하나요?" 선배 박시니어 씨가 웃으며 대답했습니다.

"요즘은 RDS를 사용하죠. 훨씬 편해요."

RDS(Relational Database Service)는 AWS에서 제공하는 관계형 데이터베이스 관리 서비스입니다. 마치 전문 관리자가 24시간 데이터베이스를 돌봐주는 것과 같습니다.

백업, 패치, 장애 복구 같은 번거로운 작업을 AWS가 자동으로 처리해줍니다.

다음 코드를 살펴봅시다.

import boto3

# RDS 클라이언트 생성
rds_client = boto3.client('rds', region_name='ap-northeast-2')

# RDS 인스턴스 목록 조회
response = rds_client.describe_db_instances()

# 인스턴스 정보 출력
for db in response['DBInstances']:
    print(f"DB 식별자: {db['DBInstanceIdentifier']}")
    print(f"엔진: {db['Engine']}")
    print(f"상태: {db['DBInstanceStatus']}")
    print(f"엔드포인트: {db.get('Endpoint', {}).get('Address', 'N/A')}")
    print("---")

김개발 씨는 개발자로 일한 지 3개월이 되었습니다. 이번 프로젝트에서는 사용자 정보를 저장할 데이터베이스가 필요했습니다.

"MySQL을 EC2 서버에 직접 설치하면 되겠지?" 김개발 씨는 자신감 있게 생각했습니다. 하지만 선배 박시니어 씨의 반응은 달랐습니다.

"요즘은 그렇게 하지 않아요. RDS를 사용하면 훨씬 편합니다." 그렇다면 RDS란 정확히 무엇일까요?

쉽게 비유하자면, RDS는 마치 호텔과 같습니다. 집에서 청소하고 요리하고 수리하는 대신, 호텔에 가면 모든 것을 직원들이 알아서 해줍니다.

RDS도 마찬가지입니다. 데이터베이스를 직접 설치하고 관리하는 대신, AWS가 모든 것을 자동으로 처리해줍니다.

RDS가 없던 시절에는 어땠을까요? 개발자들은 데이터베이스 서버에 MySQL이나 PostgreSQL을 직접 설치해야 했습니다.

보안 패치가 나오면 심야에 서버를 중단하고 업데이트를 진행했습니다. 데이터베이스가 갑자기 다운되면 새벽에도 긴급 출동해야 했습니다.

백업은 또 어떻고요? 매일 새벽 3시에 크론 작업으로 백업 스크립트를 돌렸습니다.

더 큰 문제는 확장성이었습니다. 트래픽이 급증하면 서버 스펙을 높여야 하는데, 이는 서비스 중단을 의미했습니다.

사용자들은 "점검 중입니다"라는 메시지를 보며 기다려야 했습니다. 바로 이런 문제를 해결하기 위해 RDS가 등장했습니다.

RDS를 사용하면 자동 백업이 가능해집니다. 매일 정해진 시간에 자동으로 백업이 생성되고, 필요할 때 언제든 복구할 수 있습니다.

또한 자동 패치도 얻을 수 있습니다. 보안 패치나 버전 업데이트를 AWS가 알아서 처리해줍니다.

무엇보다 고가용성이라는 큰 이점이 있습니다. Multi-AZ 옵션을 선택하면 장애가 발생해도 자동으로 다른 서버로 전환됩니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 boto3 라이브러리로 RDS 클라이언트를 생성합니다.

이것이 AWS RDS와 통신하는 창구입니다. 다음으로 describe_db_instances() 메서드로 현재 계정의 모든 RDS 인스턴스 정보를 가져옵니다.

마지막으로 각 인스턴스의 식별자, 엔진 종류, 상태, 접속 주소를 출력합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다. 주문 정보, 상품 정보, 고객 정보를 저장해야 합니다.

RDS를 사용하면 데이터베이스 관리에 시간을 빼앗기지 않고 비즈니스 로직 개발에 집중할 수 있습니다. 네이버, 쿠팡, 토스 같은 많은 기업에서 RDS를 적극적으로 사용하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 프리티어로 시작했다가 과금 폭탄을 맞는 것입니다.

프리티어 기간이 지나거나 인스턴스 타입을 잘못 선택하면 예상치 못한 비용이 청구될 수 있습니다. 따라서 Billing 알람을 반드시 설정해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다.

"아, 그래서 다들 RDS를 쓰는 거군요!" RDS를 제대로 이해하면 안정적이고 확장 가능한 서비스를 구축할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 프리티어 기간을 확인하고 과금이 시작되는 시점을 파악하세요

Multi-AZ 옵션은 프로덕션 환경에서 필수입니다
CloudWatch 알람을 설정해서 CPU, 메모리 사용량을 모니터링하세요

2. 지원 DB 엔진 종류

RDS 콘솔에 처음 접속한 김개발 씨는 당황했습니다. MySQL, PostgreSQL, MariaDB, Oracle...

엔진이 너무 많았습니다. "어떤 걸 선택해야 하죠?" 박시니어 씨가 친절히 설명을 시작했습니다.

RDS는 총 6가지 데이터베이스 엔진을 지원합니다. MySQL, PostgreSQL, MariaDB는 오픈소스이고 무료입니다.

Oracle과 SQL Server는 상용 라이선스가 필요하며, Aurora는 AWS가 직접 만든 고성능 엔진입니다.

다음 코드를 살펴봅시다.

import boto3

# 사용 가능한 DB 엔진 목록 조회
rds_client = boto3.client('rds', region_name='ap-northeast-2')

# 각 엔진의 버전 정보 조회
engines = ['mysql', 'postgres', 'mariadb', 'oracle-ee', 'sqlserver-ex', 'aurora-mysql']

for engine in engines:
    response = rds_client.describe_db_engine_versions(Engine=engine, MaxRecords=5)
    print(f"\n=== {engine.upper()} ===")
    for version in response['DBEngineVersions']:
        print(f"버전: {version['EngineVersion']}")
        print(f"설명: {version.get('DBEngineDescription', 'N/A')}")

김개발 씨는 RDS 콘솔의 "데이터베이스 생성" 버튼을 클릭했습니다. 그런데 화면에 나타난 선택지가 너무 많았습니다.

MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, 그리고 Aurora까지. "이게 다 뭐지?" 김개발 씨는 혼란스러웠습니다.

선배 박시니어 씨가 옆에서 화면을 보며 설명했습니다. "각 엔진마다 특징이 다르거든요.

프로젝트에 맞는 걸 선택해야 해요." 그렇다면 각 엔진의 차이는 무엇일까요? 쉽게 비유하자면, 데이터베이스 엔진은 마치 자동차 엔진과 같습니다.

가솔린, 디젤, 전기, 하이브리드 엔진이 각각 장단점이 있듯이, 데이터베이스 엔진도 저마다 특징이 있습니다. 어떤 엔진은 빠르고, 어떤 엔진은 안정적이고, 어떤 엔진은 특정 기능에 특화되어 있습니다.

과거에는 어떤 문제가 있었을까요? 예전에는 대부분의 회사가 Oracle이나 MS SQL Server 같은 상용 데이터베이스를 사용했습니다.

하지만 라이선스 비용이 엄청났습니다. 작은 스타트업이 데이터베이스 라이선스에만 수천만 원을 지불하는 경우도 있었습니다.

그렇다고 무료 데이터베이스를 쓰자니 성능이나 기능이 부족하다는 인식이 있었습니다. 하지만 시대가 변했습니다.

MySQL과 PostgreSQL 같은 오픈소스 데이터베이스가 엄청나게 발전했습니다. 페이스북, 인스타그램, 넷플릭스 같은 글로벌 기업들도 오픈소스 데이터베이스를 사용합니다.

더 이상 비싼 라이선스가 필수가 아닌 시대가 된 것입니다. RDS가 지원하는 엔진들을 하나씩 살펴보겠습니다.

MySQL은 가장 인기 있는 오픈소스 데이터베이스입니다. 웹 서비스, 모바일 앱 백엔드에 가장 많이 사용됩니다.

한국의 대부분의 스타트업이 MySQL로 시작합니다. 커뮤니티가 크고 자료가 풍부해서 초보자가 배우기 쉽습니다.

PostgreSQL은 MySQL보다 기능이 풍부합니다. 복잡한 쿼리, JSON 데이터 저장, 전문 검색 기능을 지원합니다.

금융권이나 데이터 분석이 중요한 서비스에서 선호합니다. 최근에는 PostgreSQL의 인기가 급상승하고 있습니다.

MariaDB는 MySQL의 창시자가 만든 데이터베이스입니다. MySQL과 거의 호환되면서도 더 많은 기능을 제공합니다.

위키피디아가 MariaDB를 사용합니다. Oracle은 대기업과 금융권에서 사용하는 상용 데이터베이스입니다.

매우 강력하지만 라이선스 비용이 비쌉니다. 기존에 Oracle을 사용하던 시스템을 클라우드로 이전할 때 선택합니다.

SQL Server는 마이크로소프트의 데이터베이스입니다. .NET 기반 애플리케이션과 궁합이 좋습니다.

Windows 환경에 익숙한 기업에서 선호합니다. Aurora는 AWS가 직접 개발한 클라우드 네이티브 데이터베이스입니다.

MySQL이나 PostgreSQL과 호환되면서도 5배 빠른 성능을 제공합니다. 자동 확장, 자동 백업 등 클라우드 최적화 기능이 많습니다.

가격은 조금 비싸지만 대규모 서비스에서는 충분히 가치가 있습니다. 위의 코드를 살펴보겠습니다.

boto3로 각 엔진의 사용 가능한 버전 목록을 조회합니다. 엔진마다 여러 버전이 있고, 각 버전마다 기능과 성능이 다릅니다.

최신 버전일수록 보안 패치와 성능 개선이 적용되어 있습니다. 실무에서는 어떻게 선택할까요?

신규 프로젝트라면 PostgreSQL을 추천합니다. 기능이 풍부하고 성능도 우수합니다.

MySQL에 익숙하다면 MySQL 8.0도 좋은 선택입니다. 대규모 트래픽이 예상되고 예산이 충분하다면 Aurora를 고려하세요.

기존 시스템 이전이라면 기존에 사용하던 엔진을 그대로 선택합니다. 김개발 씨는 고민 끝에 PostgreSQL을 선택했습니다.

"회사에서 PostgreSQL을 표준으로 사용한다고 하셨잖아요." 박시니어 씨가 미소를 지었습니다. "좋은 선택이에요!" 데이터베이스 엔진 선택은 프로젝트의 방향을 결정하는 중요한 결정입니다.

하지만 너무 걱정하지 마세요. 나중에 필요하면 다른 엔진으로 마이그레이션할 수도 있습니다.

실전 팁

💡 - 신규 프로젝트는 PostgreSQL 또는 MySQL 8.0을 추천합니다

대규모 트래픽이 예상되면 Aurora를 고려하세요
팀의 기술 스택과 기존 경험을 고려해서 선택하세요

3. RDS 인스턴스 생성

드디어 RDS 인스턴스를 생성할 시간입니다. 김개발 씨는 AWS 콘솔에서 "데이터베이스 생성" 버튼을 클릭했습니다.

하지만 설정 항목이 너무 많아서 어디서부터 시작해야 할지 막막했습니다.

RDS 인스턴스 생성은 데이터베이스 서버를 클라우드에 만드는 과정입니다. 엔진 선택, 인스턴스 크기, 스토리지 용량, 네트워크 설정 등을 결정합니다.

마치 새 아파트를 계약할 때 평수, 층, 옵션을 선택하는 것과 비슷합니다.

다음 코드를 살펴봅시다.

import boto3

rds_client = boto3.client('rds', region_name='ap-northeast-2')

# RDS 인스턴스 생성
response = rds_client.create_db_instance(
    DBInstanceIdentifier='my-postgres-db',  # 인스턴스 고유 식별자
    DBInstanceClass='db.t3.micro',  # 인스턴스 크기 (프리티어)
    Engine='postgres',  # PostgreSQL 선택
    EngineVersion='15.4',  # 버전
    MasterUsername='admin',  # 관리자 계정
    MasterUserPassword='MySecurePass123!',  # 비밀번호 (실제로는 시크릿 매니저 사용)
    AllocatedStorage=20,  # 스토리지 20GB
    VpcSecurityGroupIds=['sg-0123456789abcdef0'],  # 보안 그룹
    DBSubnetGroupName='my-db-subnet-group',  # 서브넷 그룹
    BackupRetentionPeriod=7,  # 백업 보관 7일
    PubliclyAccessible=False,  # 외부 접근 차단
    StorageEncrypted=True  # 암호화 활성화
)

print(f"인스턴스 생성 시작: {response['DBInstance']['DBInstanceIdentifier']}")

김개발 씨는 AWS 콘솔 화면을 뚫어지게 바라보고 있었습니다. "데이터베이스 생성" 페이지에는 설정 항목이 수십 개나 되었습니다.

엔진 버전, 템플릿, 인스턴스 클래스, 스토리지, VPC, 서브넷... "이걸 언제 다 채워요?" 김개발 씨는 한숨을 쉬었습니다.

박시니어 씨가 다가와 화면을 보더니 웃었습니다. "복잡해 보이지만 핵심은 간단해요.

중요한 것만 제대로 설정하면 됩니다." RDS 인스턴스 생성은 정확히 무엇을 의미할까요? 쉽게 비유하자면, 인스턴스 생성은 마치 새 아파트를 계약하는 것과 같습니다.

먼저 평수를 선택하고(인스턴스 크기), 층을 고르고(가용 영역), 옵션을 선택합니다(백업, 암호화). 계약이 완료되면 아파트가 준비되고, 입주할 수 있습니다.

RDS도 마찬가지입니다. 설정을 완료하면 AWS가 데이터베이스 서버를 자동으로 구축해줍니다.

과거에 직접 데이터베이스를 구축하던 시절에는 어땠을까요? 먼저 물리 서버를 구매하거나 IDC를 계약해야 했습니다.

서버가 도착하면 랙에 설치하고 네트워크 케이블을 연결했습니다. 운영체제를 설치하고, 데이터베이스 소프트웨어를 설치하고, 방화벽을 설정하고...

이 모든 과정에 며칠이 걸렸습니다. 설정 하나만 잘못해도 보안 사고가 발생할 수 있었습니다.

하지만 RDS는 이 모든 과정을 몇 분으로 단축시켰습니다. 인스턴스 생성 화면에서 가장 먼저 결정할 것은 생성 방법입니다.

"표준 생성"과 "손쉬운 생성" 두 가지가 있습니다. 처음이라면 "손쉬운 생성"을 선택하세요.

AWS가 권장 설정을 자동으로 적용해줍니다. 다음은 엔진 선택입니다.

앞서 배운 대로 PostgreSQL을 선택했다고 가정하겠습니다. 버전은 최신 안정 버전을 선택하세요.

너무 최신 버전은 버그가 있을 수 있고, 너무 오래된 버전은 보안 패치가 없을 수 있습니다. 템플릿에서는 프로덕션, 개발/테스트, 프리티어 중 하나를 선택합니다.

처음 시작한다면 프리티어를 선택하세요. 12개월 동안 무료로 사용할 수 있습니다.

가장 중요한 설정 중 하나는 DB 인스턴스 크기입니다. 프리티어는 db.t3.micro(또는 db.t2.micro)만 사용할 수 있습니다.

이 인스턴스는 CPU 2코어, 메모리 1GB 정도의 성능입니다. 작은 개발 프로젝트에는 충분하지만, 실제 서비스에는 더 큰 인스턴스가 필요할 수 있습니다.

스토리지는 데이터베이스가 사용할 디스크 공간입니다. 프리티어는 최대 20GB까지 무료입니다.

스토리지 타입은 범용 SSD(gp2 또는 gp3)를 선택하세요. 고성능이 필요하면 프로비저닝된 IOPS(io1)를 선택할 수 있지만, 비용이 훨씬 비쌉니다.

연결 설정은 네트워크 관련 설정입니다. VPC, 서브넷 그룹, 퍼블릭 액세스, 보안 그룹을 설정합니다.

보안을 위해 퍼블릭 액세스는 비활성화하는 것이 좋습니다. 외부에서 직접 접근하지 못하게 하고, EC2나 Lambda에서만 접근하도록 합니다.

데이터베이스 인증은 암호 방식을 선택합니다. 일반적으로 암호 인증을 사용하지만, IAM 인증을 활성화하면 더 안전합니다.

추가 구성에서는 백업, 암호화, 로그 내보내기 등을 설정합니다. 자동 백업은 반드시 활성화하세요.

백업 보관 기간은 최소 7일을 권장합니다. 암호화도 활성화하는 것이 좋습니다.

데이터가 디스크에 암호화되어 저장됩니다. 위의 코드를 살펴보겠습니다.

create_db_instance() 메서드로 인스턴스를 생성합니다. DBInstanceIdentifier는 인스턴스의 고유한 이름입니다.

DBInstanceClass는 인스턴스 크기를 결정합니다. MasterUsername과 MasterUserPassword는 관리자 계정 정보입니다.

실제 프로덕션에서는 비밀번호를 코드에 하드코딩하지 말고 AWS Secrets Manager를 사용하세요. 실무에서는 어떻게 생성할까요?

대부분의 회사는 Terraform이나 CloudFormation 같은 Infrastructure as Code 도구를 사용합니다. 코드로 인스턴스를 정의하면 동일한 환경을 반복해서 생성할 수 있습니다.

개발 환경, 스테이징 환경, 프로덕션 환경을 일관되게 구축할 수 있습니다. 인스턴스 생성 버튼을 클릭하면 어떻게 될까요?

AWS가 백그라운드에서 데이터베이스 서버를 프로비저닝합니다. 보통 5~10분 정도 걸립니다.

상태가 "생성 중"에서 "사용 가능"으로 바뀌면 접속할 수 있습니다. 엔드포인트 주소가 생성되는데, 이 주소로 데이터베이스에 접속합니다.

김개발 씨는 조심스럽게 설정을 완료하고 "데이터베이스 생성" 버튼을 눌렀습니다. "이제 기다리면 되나요?" 박시니어 씨가 고개를 끄덕였습니다.

"네, 잠깐 기다리면 데이터베이스가 준비됩니다." RDS 인스턴스 생성은 복잡해 보이지만, 한 번 익숙해지면 간단합니다. 여러분도 직접 해보면서 각 설정의 의미를 이해해 보세요.

실전 팁

💡 - 프리티어는 db.t3.micro와 20GB까지만 무료입니다

퍼블릭 액세스는 비활성화하고 보안 그룹으로 접근을 제어하세요
비밀번호는 Secrets Manager에 저장하고 코드에는 하드코딩하지 마세요

4. 프리티어 옵션 선택

김개발 씨는 프리티어 템플릿을 선택했습니다. "1년 동안 무료라니 좋네요!" 하지만 박시니어 씨가 경고했습니다.

"조심하세요. 프리티어 범위를 벗어나면 과금됩니다."

AWS 프리티어는 신규 가입자에게 12개월 동안 무료로 제공되는 혜택입니다. RDS는 db.t2.micro 또는 db.t3.micro 인스턴스와 20GB 스토리지를 무료로 사용할 수 있습니다.

하지만 범위를 초과하거나 다른 옵션을 선택하면 과금이 시작됩니다.

다음 코드를 살펴봅시다.

import boto3
from datetime import datetime, timedelta

rds_client = boto3.client('rds', region_name='ap-northeast-2')
cloudwatch = boto3.client('cloudwatch', region_name='ap-northeast-2')

# 프리티어 인스턴스 생성
response = rds_client.create_db_instance(
    DBInstanceIdentifier='my-free-tier-db',
    DBInstanceClass='db.t3.micro',  # 프리티어 인스턴스
    Engine='postgres',
    MasterUsername='admin',
    MasterUserPassword='MySecurePass123!',
    AllocatedStorage=20,  # 프리티어 최대 용량
    BackupRetentionPeriod=1,  # 백업은 1일만 (비용 절감)
    StorageEncrypted=False,  # 암호화 비활성화 (프리티어)
    PubliclyAccessible=False
)

# 스토리지 사용량 모니터링
metrics = cloudwatch.get_metric_statistics(
    Namespace='AWS/RDS',
    MetricName='FreeStorageSpace',
    Dimensions=[{'Name': 'DBInstanceIdentifier', 'Value': 'my-free-tier-db'}],
    StartTime=datetime.now() - timedelta(hours=1),
    EndTime=datetime.now(),
    Period=3600,
    Statistics=['Average']
)

print(f"남은 스토리지: {metrics['Datapoints']}")

김개발 씨는 신이 났습니다. "RDS를 1년 동안 공짜로 쓸 수 있다고요?" AWS 프리티어 페이지를 보니 정말 무료라고 쓰여 있었습니다.

하지만 작은 글씨로 적힌 주의사항이 눈에 들어왔습니다. 박시니어 씨가 진지하게 말했습니다.

"프리티어는 좋지만 조심해야 해요. 많은 신입 개발자들이 과금 폭탄을 맞았거든요." AWS 프리티어는 정확히 무엇일까요?

쉽게 비유하자면, 프리티어는 마치 헬스장의 무료 체험권과 같습니다. 한 달 동안 헬스장을 무료로 이용할 수 있지만, 프리미엄 프로그램이나 개인 트레이닝은 추가 비용이 듭니다.

정해진 시간과 기구만 사용해야 무료입니다. AWS도 마찬가지입니다.

정해진 범위 내에서만 무료이고, 범위를 벗어나면 비용이 청구됩니다. 과거에는 클라우드를 시도하기가 두려웠습니다.

"실수로 뭔가 잘못 설정하면 수백만 원이 청구되지 않을까?" 이런 두려움 때문에 많은 개발자들이 클라우드를 시도하지 못했습니다. 실제로 몇 년 전에는 개발자가 EC2 인스턴스를 끄지 않고 방치해서 수천만 원이 청구된 사례도 있었습니다.

AWS는 이런 진입 장벽을 낮추기 위해 프리티어를 제공합니다. RDS 프리티어의 정확한 범위는 이렇습니다.

db.t2.micro 또는 db.t3.micro 인스턴스를 한 달에 750시간 사용할 수 있습니다. 한 달이 30일이면 720시간이므로, 인스턴스 하나를 24시간 내내 켜둘 수 있습니다.

스토리지는 범용 SSD(gp2) 20GB까지 무료입니다. 백업 스토리지도 20GB까지 무료입니다.

하지만 여기에 숨겨진 함정이 있습니다. 첫 번째 함정은 인스턴스를 두 개 생성하는 경우입니다.

인스턴스를 두 개 만들면 한 달에 1500시간이 필요한데, 프리티어는 750시간만 무료입니다. 나머지 750시간은 과금됩니다.

개발용과 테스트용으로 인스턴스를 분리하고 싶다면 둘 중 하나는 꺼두어야 합니다. 두 번째 함정은 스토리지 초과입니다.

20GB를 넘으면 초과분에 대해 과금됩니다. 데이터가 늘어나면 스토리지도 자동으로 늘어나는데, 이때 과금이 시작됩니다.

스토리지 자동 확장 기능을 비활성화하는 것이 안전합니다. 세 번째 함정은 프리티어 대상이 아닌 옵션입니다.

Multi-AZ를 활성화하면 프리티어가 적용되지 않습니다. 프로비저닝된 IOPS를 선택해도 과금됩니다.

암호화를 활성화하는 것 자체는 무료이지만, KMS 키 사용료는 별도입니다. 네 번째 함정은 12개월 제한입니다.

AWS 계정을 생성한 날부터 12개월 동안만 프리티어가 적용됩니다. 13개월째부터는 자동으로 유료로 전환됩니다.

캘린더에 표시해두고 미리 준비하세요. 다섯 번째 함정은 데이터 전송 비용입니다.

RDS에서 인터넷으로 데이터를 전송하면 비용이 청구됩니다. 같은 리전 내의 EC2와 통신하는 것은 무료이지만, 다른 리전이나 인터넷으로 전송하면 GB당 비용이 발생합니다.

위의 코드를 살펴보겠습니다. 프리티어 범위 내에서 인스턴스를 생성하는 예제입니다.

StorageEncrypted를 False로 설정한 이유는 KMS 키 비용을 피하기 위함입니다. BackupRetentionPeriod를 1로 설정해서 백업 스토리지 사용량을 최소화했습니다.

CloudWatch로 스토리지 사용량을 모니터링해서 20GB를 넘지 않도록 관리합니다. 실무에서는 어떻게 활용할까요?

프리티어는 학습용이나 소규모 개발 프로젝트에 적합합니다. 개인 포트폴리오 프로젝트, 사이드 프로젝트, 테스트 환경으로 사용하세요.

하지만 실제 서비스를 운영하려면 프리티어로는 부족합니다. 트래픽이 늘어나면 더 큰 인스턴스가 필요하고, 가용성을 위해 Multi-AZ가 필요합니다.

과금을 방지하는 가장 좋은 방법은 빌링 알람을 설정하는 것입니다. CloudWatch에서 예상 청구 금액이 일정 금액(예: 10달러)을 넘으면 이메일로 알람을 보내도록 설정하세요.

매일 AWS Cost Explorer를 확인하는 습관도 좋습니다. 예상치 못한 비용이 발생하면 즉시 원인을 파악하고 리소스를 종료하세요.

김개발 씨는 박시니어 씨의 조언을 듣고 빌링 알람을 설정했습니다. "이제 안심이에요!" 하지만 박시니어 씨는 마지막 당부를 잊지 않았습니다.

"그래도 주기적으로 확인하는 게 좋아요." 프리티어는 AWS를 배우는 좋은 기회입니다. 하지만 과금 범위를 정확히 이해하고 사용해야 합니다.

여러분도 빌링 알람을 설정하고 안전하게 사용하세요.

실전 팁

💡 - 빌링 알람을 반드시 설정하고 10달러 이상이면 알림을 받으세요

인스턴스는 하나만 생성하고 24시간 실행하세요
12개월 후 자동 과금을 대비해 캘린더에 표시하세요

5. DB 서브넷 그룹

인스턴스 생성 중에 "DB 서브넷 그룹"이라는 설정이 나타났습니다. 김개발 씨는 당황했습니다.

"서브넷 그룹이 뭐죠?" 박시니어 씨가 설명을 시작했습니다.

DB 서브넷 그룹은 RDS 인스턴스가 배치될 수 있는 서브넷의 모음입니다. 최소 2개 이상의 가용 영역에 서브넷을 지정해야 합니다.

이것은 고가용성과 장애 복구를 위한 필수 설정입니다.

다음 코드를 살펴봅시다.

import boto3

ec2_client = boto3.client('ec2', region_name='ap-northeast-2')
rds_client = boto3.client('rds', region_name='ap-northeast-2')

# VPC의 서브넷 조회
vpc_id = 'vpc-0123456789abcdef0'
subnets = ec2_client.describe_subnets(
    Filters=[{'Name': 'vpc-id', 'Values': [vpc_id]}]
)

# 최소 2개의 서로 다른 가용 영역 선택
subnet_ids = [s['SubnetId'] for s in subnets['Subnets'][:2]]

# DB 서브넷 그룹 생성
response = rds_client.create_db_subnet_group(
    DBSubnetGroupName='my-db-subnet-group',
    DBSubnetGroupDescription='Subnet group for RDS instances',
    SubnetIds=subnet_ids,  # 최소 2개의 서브넷
    Tags=[
        {'Key': 'Environment', 'Value': 'Development'},
        {'Key': 'Project', 'Value': 'MyApp'}
    ]
)

print(f"서브넷 그룹 생성: {response['DBSubnetGroup']['DBSubnetGroupName']}")
print(f"포함된 서브넷: {[s['SubnetIdentifier'] for s in response['DBSubnetGroup']['Subnets']]}")

김개발 씨는 RDS 생성 화면에서 "서브넷 그룹"이라는 낯선 용어를 발견했습니다. 드롭다운을 클릭하니 "default"라는 항목이 있었지만, 뭘 선택해야 할지 막막했습니다.

"이게 왜 필요한 건가요?" 박시니어 씨가 화이트보드를 꺼내 그림을 그리기 시작했습니다. "VPC와 서브넷을 이해해야 서브넷 그룹을 이해할 수 있어요." DB 서브넷 그룹은 무엇일까요?

쉽게 비유하자면, 서브넷 그룹은 마치 아파트 단지의 동(棟) 목록과 같습니다. "우리 아파트는 101동, 102동, 103동에 세대가 있습니다"라고 지정하는 것입니다.

RDS가 어느 동에 배치될지 미리 정해두는 것이죠. 만약 101동에 문제가 생기면 자동으로 102동으로 옮겨갈 수 있습니다.

서브넷 그룹이 없던 시절에는 어땠을까요? 초기 클라우드 서비스에서는 데이터베이스를 하나의 서버에만 배치했습니다.

그 서버나 데이터 센터에 문제가 생기면 서비스 전체가 다운되었습니다. 2011년 아마존의 한 데이터 센터에서 장애가 발생했을 때, 수많은 서비스가 몇 시간 동안 중단되었습니다.

넷플릭스, 레딧, 쿼라 같은 유명 서비스들도 영향을 받았습니다. AWS는 이 문제를 해결하기 위해 가용 영역(Availability Zone)이라는 개념을 도입했습니다.

서울 리전(ap-northeast-2)에는 ap-northeast-2a, 2b, 2c, 2d라는 4개의 가용 영역이 있습니다. 각 가용 영역은 물리적으로 분리된 데이터 센터입니다.

하나의 가용 영역에 화재나 정전이 발생해도 다른 가용 영역은 정상적으로 작동합니다. DB 서브넷 그룹은 최소 2개의 가용 영역에 서브넷을 지정해야 합니다.

예를 들어 2a와 2c 가용 영역에 각각 프라이빗 서브넷을 만들고, 이 두 서브넷을 서브넷 그룹으로 묶습니다. RDS는 이 중 하나의 서브넷에 기본 인스턴스를 배치합니다.

Multi-AZ를 활성화하면 다른 가용 영역에 대기 인스턴스를 자동으로 생성합니다. 왜 2개 이상이어야 할까요?

장애 복구 때문입니다. 기본 인스턴스가 있는 가용 영역에 문제가 생기면, RDS가 자동으로 다른 가용 영역의 대기 인스턴스로 전환합니다.

이것을 Failover라고 합니다. 전환 시간은 보통 60~120초 정도입니다.

사용자는 잠깐의 지연만 경험하고 서비스는 계속 작동합니다. 서브넷 그룹을 만들 때 주의할 점이 있습니다.

첫째, 프라이빗 서브넷을 사용하세요. 데이터베이스는 인터넷에 직접 노출되면 안 됩니다.

퍼블릭 서브넷이 아닌 프라이빗 서브넷에 배치해야 합니다. 둘째, 서브넷의 IP 범위를 충분히 확보하세요.

RDS 인스턴스뿐만 아니라 내부 관리용 리소스도 IP를 사용합니다. 서브넷당 최소 /27(32개 IP) 이상을 권장합니다.

셋째, 라우팅 테이블을 확인하세요. 프라이빗 서브넷은 NAT 게이트웨이를 통해 인터넷에 접근할 수 있어야 합니다.

업데이트와 패치를 받기 위해서입니다. 위의 코드를 살펴보겠습니다.

먼저 VPC의 서브넷 목록을 조회합니다. 그중에서 최소 2개를 선택해서 서브넷 그룹을 생성합니다.

실무에서는 프라이빗 서브넷만 필터링해서 선택해야 합니다. 태그를 달아서 어떤 용도인지 명확히 표시하는 것도 좋은 습관입니다.

실무에서는 어떻게 구성할까요? 보통 VPC를 생성할 때 미리 서브넷 구조를 설계합니다.

퍼블릭 서브넷 2개(웹 서버용), 프라이빗 서브넷 2개(애플리케이션 서버용), 프라이빗 서브넷 2개(데이터베이스용)를 만듭니다. 데이터베이스용 서브넷 2개로 서브넷 그룹을 만듭니다.

이렇게 하면 웹 서버, 애플리케이션 서버, 데이터베이스가 각각 별도의 네트워크 계층에 분리됩니다. 보안 그룹으로 계층 간 통신만 허용하면 보안이 크게 향상됩니다.

서브넷 그룹을 한번 만들어두면 여러 RDS 인스턴스에서 재사용할 수 있습니다. 개발용 데이터베이스, 스테이징용 데이터베이스, 프로덕션용 데이터베이스 모두 같은 서브넷 그룹을 사용할 수 있습니다.

단, 프로덕션용은 별도의 서브넷 그룹을 만들어서 네트워크를 분리하는 것이 더 안전합니다. 김개발 씨는 고개를 끄덕였습니다.

"그래서 서브넷 그룹이 필요한 거군요. 장애가 나도 서비스가 계속 돌아가게 하려고요." 박시니어 씨가 미소를 지었습니다.

"맞아요. 클라우드의 핵심은 바로 이런 고가용성입니다." 서브넷 그룹은 처음에는 복잡해 보이지만, 고가용성의 기본입니다.

여러분도 프로젝트를 시작할 때 VPC와 서브넷을 제대로 설계하세요.

실전 팁

💡 - 프라이빗 서브넷 2개 이상을 서로 다른 가용 영역에 배치하세요

서브넷 IP 범위는 /27 이상으로 충분히 확보하세요
프로덕션용은 별도 서브넷 그룹으로 네트워크를 분리하세요

6. 파라미터 그룹

인스턴스가 생성되고 며칠 뒤, 김개발 씨는 문제를 발견했습니다. 데이터베이스 타임존이 UTC로 설정되어 있었습니다.

"한국 시간으로 바꾸려면 어떻게 하죠?" 박시니어 씨가 "파라미터 그룹을 수정하면 됩니다"라고 답했습니다.

파라미터 그룹은 데이터베이스 엔진의 설정을 관리하는 템플릿입니다. 타임존, 문자셋, 메모리 설정, 연결 제한 등을 조정할 수 있습니다.

마치 애플리케이션의 config 파일과 같은 역할을 합니다.

다음 코드를 살펴봅시다.

import boto3

rds_client = boto3.client('rds', region_name='ap-northeast-2')

# 파라미터 그룹 생성
response = rds_client.create_db_parameter_group(
    DBParameterGroupName='my-postgres-params',
    DBParameterGroupFamily='postgres15',  # PostgreSQL 15 패밀리
    Description='Custom parameter group for PostgreSQL 15'
)

# 파라미터 수정 (타임존을 Asia/Seoul로 설정)
rds_client.modify_db_parameter_group(
    DBParameterGroupName='my-postgres-params',
    Parameters=[
        {
            'ParameterName': 'timezone',
            'ParameterValue': 'Asia/Seoul',
            'ApplyMethod': 'pending-reboot'  # 재시작 필요
        },
        {
            'ParameterName': 'max_connections',
            'ParameterValue': '200',
            'ApplyMethod': 'immediate'  # 즉시 적용
        },
        {
            'ParameterName': 'shared_buffers',
            'ParameterValue': '256MB',
            'ApplyMethod': 'pending-reboot'
        }
    ]
)

# 인스턴스에 파라미터 그룹 적용
rds_client.modify_db_instance(
    DBInstanceIdentifier='my-postgres-db',
    DBParameterGroupName='my-postgres-params',
    ApplyImmediately=False  # 다음 유지보수 기간에 적용
)

print("파라미터 그룹 생성 및 적용 완료")

김개발 씨는 데이터베이스에 저장된 시간이 이상하다는 것을 발견했습니다. 오후 3시에 저장한 데이터인데 시간이 6시로 표시되었습니다.

"왜 이렇게 나오는 거죠?" 로그를 확인해보니 데이터베이스 타임존이 UTC로 설정되어 있었습니다. 박시니어 씨가 설명했습니다.

"RDS는 기본적으로 UTC를 사용해요. 한국 시간으로 바꾸려면 파라미터 그룹을 수정해야 합니다." 파라미터 그룹은 정확히 무엇일까요?

쉽게 비유하자면, 파라미터 그룹은 마치 자동차의 설정과 같습니다. 실내 온도, 시트 위치, 사이드미러 각도, 핸들 무게감 등을 조정하는 것입니다.

공장 출하 시에는 기본 설정이 되어 있지만, 운전자의 취향에 맞게 바꿀 수 있습니다. 데이터베이스도 마찬가지입니다.

기본 설정이 있지만, 프로젝트에 맞게 커스터마이징해야 합니다. 파라미터 그룹이 없던 시절에는 어땠을까요?

과거에 직접 MySQL이나 PostgreSQL을 설치했을 때는 설정 파일을 직접 수정했습니다. /etc/mysql/my.cnf나 /etc/postgresql/postgresql.conf 같은 파일을 vi 에디터로 열어서 한 줄씩 고쳤습니다.

오타를 내면 데이터베이스가 시작되지 않았습니다. 설정을 백업하지 않으면 나중에 어떤 값을 바꿨는지 기억하지 못했습니다.

RDS는 이 문제를 파라미터 그룹으로 해결했습니다. 파라미터 그룹은 설정의 템플릿입니다.

한번 만들어두면 여러 인스턴스에 적용할 수 있습니다. 개발 환경, 스테이징 환경, 프로덕션 환경에 각각 다른 파라미터 그룹을 적용할 수도 있습니다.

변경 이력이 자동으로 기록되므로 문제가 생기면 이전 설정으로 되돌릴 수 있습니다. 파라미터 그룹에는 수백 개의 파라미터가 있습니다.

모든 파라미터를 이해할 필요는 없습니다. 실무에서 자주 조정하는 파라미터만 알아두면 됩니다.

timezone은 데이터베이스의 시간대를 설정합니다. 한국에서 서비스한다면 'Asia/Seoul'로 설정하세요.

이렇게 하면 NOW() 함수가 한국 시간을 반환합니다. character_set_server(MySQL) 또는 client_encoding(PostgreSQL)은 문자 인코딩을 설정합니다.

한글을 사용한다면 utf8mb4(MySQL) 또는 UTF8(PostgreSQL)로 설정해야 합니다. max_connections는 동시 접속 가능한 클라이언트 수를 제한합니다.

기본값은 인스턴스 크기에 따라 다릅니다. t3.micro는 약 80개, t3.small은 약 150개입니다.

접속이 많은 서비스는 이 값을 높여야 하지만, 너무 높이면 메모리 부족이 발생할 수 있습니다. shared_buffers(PostgreSQL) 또는 innodb_buffer_pool_size(MySQL)는 데이터베이스가 메모리에 캐시하는 데이터 크기입니다.

이 값이 클수록 디스크 I/O가 줄어들어 성능이 향상됩니다. 보통 인스턴스 메모리의 25~40%를 할당합니다.

log_statement(PostgreSQL)는 로그에 기록할 쿼리를 설정합니다. 'all'로 설정하면 모든 쿼리가 로깅되는데, 개발 환경에서는 유용하지만 프로덕션에서는 성능 저하와 스토리지 낭비가 발생합니다.

파라미터에는 두 가지 적용 방식이 있습니다. immediate는 즉시 적용됩니다.

데이터베이스를 재시작하지 않아도 바로 효과가 나타납니다. max_connections 같은 파라미터가 여기에 해당합니다.

pending-reboot는 데이터베이스를 재시작해야 적용됩니다. shared_buffers처럼 메모리 관련 설정은 재시작이 필요합니다.

재시작하면 잠깐 동안 데이터베이스 접속이 불가능하므로, 유지보수 시간에 계획적으로 진행해야 합니다. 위의 코드를 살펴보겠습니다.

먼저 새로운 파라미터 그룹을 생성합니다. DBParameterGroupFamily는 데이터베이스 엔진과 버전에 맞게 설정해야 합니다.

PostgreSQL 15를 사용한다면 'postgres15'를 지정합니다. 그다음 필요한 파라미터를 수정합니다.

마지막으로 인스턴스에 파라미터 그룹을 적용합니다. 실무에서는 어떻게 관리할까요?

보통 환경별로 파라미터 그룹을 분리합니다. 'dev-postgres-params', 'staging-postgres-params', 'prod-postgres-params'처럼 이름을 붙입니다.

개발 환경에서는 쿼리 로깅을 활성화하고, 프로덕션에서는 성능 최적화 설정을 적용합니다. 파라미터를 수정할 때는 반드시 백업과 테스트를 거쳐야 합니다.

잘못된 파라미터 설정은 데이터베이스 성능을 오히려 저하시키거나, 심한 경우 데이터베이스가 시작되지 않을 수도 있습니다. 먼저 개발 환경에서 테스트하고, 문제가 없으면 스테이징 환경을 거쳐 프로덕션에 적용합니다.

김개발 씨는 파라미터 그룹에서 타임존을 'Asia/Seoul'로 변경하고 인스턴스를 재시작했습니다. 이제 시간이 정확하게 표시되었습니다.

"드디어 해결했어요!" 박시니어 씨가 웃으며 말했습니다. "이제 RDS의 기본은 마스터했네요." 파라미터 그룹은 데이터베이스를 프로젝트에 맞게 최적화하는 핵심 도구입니다.

여러분도 프로젝트를 시작할 때 파라미터 그룹을 제대로 설정하세요.

실전 팁

💡 - 타임존은 'Asia/Seoul'로 설정하고 문자셋은 UTF8로 설정하세요

환경별로 파라미터 그룹을 분리해서 관리하세요
파라미터 수정 전에 백업을 만들고 개발 환경에서 먼저 테스트하세요

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

#AWS#RDS#Database#PostgreSQL#MySQL

AWS RDS 데이터베이스 생성 완벽 가이드

# AWS RDS 데이터베이스 생성 완벽 가이드 AWS RDS를 처음 접하는 개발자를 위한 안내서입니다. 데이터베이스 인스턴스 생성부터 서브넷 그룹, 파라미터 그룹 설정까지 실무에 필요한 모든 것을 다룹니다. 초급 개발자도 쉽게 따라할 수 있도록 단계별로 설명합니다. --- ## 목차 1. [RDS란_무엇인가](#rds란-무엇인가) 2. [지원_DB_엔진_종류](#지원-db-엔진-종류) 3. [RDS_인스턴스_생성](#rds-인스턴스-생성) 4. [프리티어_옵션_선택](#프리티어-옵션-선택) 5. [DB_서브넷_그룹](#db-서브넷-그룹) 6. [파라미터_그룹](#파라미터-그룹) --- ## 1. RDS란_무엇인가 김개발 씨는 드디어 첫 프로젝트에서 데이터베이스를 구축하는 임무를 맡았습니다. "EC2에 MySQL을 직접 설치해야 하나요?" 선배 박시니어 씨가 웃으며 대답했습니다. "요즘은 RDS를 사용하죠. 훨씬 편해요." **RDS**(Relational Database Service)는 AWS에서 제공하는 관계형 데이터베이스 관리 서비스입니다. 마치 전문 관리자가 24시간 데이터베이스를 돌봐주는 것과 같습니다. 백업, 패치, 장애 복구 같은 번거로운 작업을 AWS가 자동으로 처리해줍니다. 다음 코드를 살펴봅시다. ```python import boto3 # RDS 클라이언트 생성 rds_client = boto3.client('rds', region_name='ap-northeast-2') # RDS 인스턴스 목록 조회 response = rds_client.describe_db_instances() # 인스턴스 정보 출력 for db in response['DBInstances']: print(f"DB 식별자: {db['DBInstanceIdentifier']}") print(f"엔진: {db['Engine']}") print(f"상태: {db['DBInstanceStatus']}") print(f"엔드포인트: {db.get('Endpoint', {}).get('Address', 'N/A')}") print("---") ``` 김개발 씨는 개발자로 일한 지 3개월이 되었습니다. 이번 프로젝트에서는 사용자 정보를 저장할 데이터베이스가 필요했습니다. "MySQL을 EC2 서버에 직접 설치하면 되겠지?" 김개발 씨는 자신감 있게 생각했습니다. 하지만 선배 박시니어 씨의 반응은 달랐습니다. "요즘은 그렇게 하지 않아요. RDS를 사용하면 훨씬 편합니다." 그렇다면 **RDS**란 정확히 무엇일까요? 쉽게 비유하자면, RDS는 마치 호텔과 같습니다. 집에서 청소하고 요리하고 수리하는 대신, 호텔에 가면 모든 것을 직원들이 알아서 해줍니다. RDS도 마찬가지입니다. 데이터베이스를 직접 설치하고 관리하는 대신, AWS가 모든 것을 자동으로 처리해줍니다. RDS가 없던 시절에는 어땠을까요? 개발자들은 데이터베이스 서버에 MySQL이나 PostgreSQL을 직접 설치해야 했습니다. 보안 패치가 나오면 심야에 서버를 중단하고 업데이트를 진행했습니다. 데이터베이스가 갑자기 다운되면 새벽에도 긴급 출동해야 했습니다. 백업은 또 어떻고요? 매일 새벽 3시에 크론 작업으로 백업 스크립트를 돌렸습니다. 더 큰 문제는 확장성이었습니다. 트래픽이 급증하면 서버 스펙을 높여야 하는데, 이는 서비스 중단을 의미했습니다. 사용자들은 "점검 중입니다"라는 메시지를 보며 기다려야 했습니다. 바로 이런 문제를 해결하기 위해 **RDS**가 등장했습니다. RDS를 사용하면 **자동 백업**이 가능해집니다. 매일 정해진 시간에 자동으로 백업이 생성되고, 필요할 때 언제든 복구할 수 있습니다. 또한 **자동 패치**도 얻을 수 있습니다. 보안 패치나 버전 업데이트를 AWS가 알아서 처리해줍니다. 무엇보다 **고가용성**이라는 큰 이점이 있습니다. Multi-AZ 옵션을 선택하면 장애가 발생해도 자동으로 다른 서버로 전환됩니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 boto3 라이브러리로 RDS 클라이언트를 생성합니다. 이것이 AWS RDS와 통신하는 창구입니다. 다음으로 `describe_db_instances()` 메서드로 현재 계정의 모든 RDS 인스턴스 정보를 가져옵니다. 마지막으로 각 인스턴스의 식별자, 엔진 종류, 상태, 접속 주소를 출력합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다. 주문 정보, 상품 정보, 고객 정보를 저장해야 합니다. RDS를 사용하면 데이터베이스 관리에 시간을 빼앗기지 않고 비즈니스 로직 개발에 집중할 수 있습니다. 네이버, 쿠팡, 토스 같은 많은 기업에서 RDS를 적극적으로 사용하고 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **프리티어로 시작했다가 과금 폭탄을 맞는 것**입니다. 프리티어 기간이 지나거나 인스턴스 타입을 잘못 선택하면 예상치 못한 비용이 청구될 수 있습니다. 따라서 **Billing 알람을 반드시 설정**해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 다들 RDS를 쓰는 거군요!" RDS를 제대로 이해하면 안정적이고 확장 가능한 서비스를 구축할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - **프리티어 기간을 확인**하고 과금이 시작되는 시점을 파악하세요 - **Multi-AZ 옵션**은 프로덕션 환경에서 필수입니다 - **CloudWatch 알람**을 설정해서 CPU, 메모리 사용량을 모니터링하세요 --- ## 2. 지원_DB_엔진_종류 RDS 콘솔에 처음 접속한 김개발 씨는 당황했습니다. MySQL, PostgreSQL, MariaDB, Oracle... 엔진이 너무 많았습니다. "어떤 걸 선택해야 하죠?" 박시니어 씨가 친절히 설명을 시작했습니다. RDS는 총 **6가지 데이터베이스 엔진**을 지원합니다. MySQL, PostgreSQL, MariaDB는 오픈소스이고 무료입니다. Oracle과 SQL Server는 상용 라이선스가 필요하며, Aurora는 AWS가 직접 만든 고성능 엔진입니다. 다음 코드를 살펴봅시다. ```python import boto3 # 사용 가능한 DB 엔진 목록 조회 rds_client = boto3.client('rds', region_name='ap-northeast-2') # 각 엔진의 버전 정보 조회 engines = ['mysql', 'postgres', 'mariadb', 'oracle-ee', 'sqlserver-ex', 'aurora-mysql'] for engine in engines: response = rds_client.describe_db_engine_versions(Engine=engine, MaxRecords=5) print(f"\n=== {engine.upper()} ===") for version in response['DBEngineVersions']: print(f"버전: {version['EngineVersion']}") print(f"설명: {version.get('DBEngineDescription', 'N/A')}") ``` 김개발 씨는 RDS 콘솔의 "데이터베이스 생성" 버튼을 클릭했습니다. 그런데 화면에 나타난 선택지가 너무 많았습니다. MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, 그리고 Aurora까지. "이게 다 뭐지?" 김개발 씨는 혼란스러웠습니다. 선배 박시니어 씨가 옆에서 화면을 보며 설명했습니다. "각 엔진마다 특징이 다르거든요. 프로젝트에 맞는 걸 선택해야 해요." 그렇다면 각 엔진의 차이는 무엇일까요? 쉽게 비유하자면, 데이터베이스 엔진은 마치 자동차 엔진과 같습니다. 가솔린, 디젤, 전기, 하이브리드 엔진이 각각 장단점이 있듯이, 데이터베이스 엔진도 저마다 특징이 있습니다. 어떤 엔진은 빠르고, 어떤 엔진은 안정적이고, 어떤 엔진은 특정 기능에 특화되어 있습니다. 과거에는 어떤 문제가 있었을까요? 예전에는 대부분의 회사가 Oracle이나 MS SQL Server 같은 상용 데이터베이스를 사용했습니다. 하지만 라이선스 비용이 엄청났습니다. 작은 스타트업이 데이터베이스 라이선스에만 수천만 원을 지불하는 경우도 있었습니다. 그렇다고 무료 데이터베이스를 쓰자니 성능이나 기능이 부족하다는 인식이 있었습니다. 하지만 시대가 변했습니다. **MySQL과 PostgreSQL** 같은 오픈소스 데이터베이스가 엄청나게 발전했습니다. 페이스북, 인스타그램, 넷플릭스 같은 글로벌 기업들도 오픈소스 데이터베이스를 사용합니다. 더 이상 비싼 라이선스가 필수가 아닌 시대가 된 것입니다. RDS가 지원하는 엔진들을 하나씩 살펴보겠습니다. **MySQL**은 가장 인기 있는 오픈소스 데이터베이스입니다. 웹 서비스, 모바일 앱 백엔드에 가장 많이 사용됩니다. 한국의 대부분의 스타트업이 MySQL로 시작합니다. 커뮤니티가 크고 자료가 풍부해서 초보자가 배우기 쉽습니다. **PostgreSQL**은 MySQL보다 기능이 풍부합니다. 복잡한 쿼리, JSON 데이터 저장, 전문 검색 기능을 지원합니다. 금융권이나 데이터 분석이 중요한 서비스에서 선호합니다. 최근에는 PostgreSQL의 인기가 급상승하고 있습니다. **MariaDB**는 MySQL의 창시자가 만든 데이터베이스입니다. MySQL과 거의 호환되면서도 더 많은 기능을 제공합니다. 위키피디아가 MariaDB를 사용합니다. **Oracle**은 대기업과 금융권에서 사용하는 상용 데이터베이스입니다. 매우 강력하지만 라이선스 비용이 비쌉니다. 기존에 Oracle을 사용하던 시스템을 클라우드로 이전할 때 선택합니다. **SQL Server**는 마이크로소프트의 데이터베이스입니다. .NET 기반 애플리케이션과 궁합이 좋습니다. Windows 환경에 익숙한 기업에서 선호합니다. **Aurora**는 AWS가 직접 개발한 클라우드 네이티브 데이터베이스입니다. MySQL이나 PostgreSQL과 호환되면서도 5배 빠른 성능을 제공합니다. 자동 확장, 자동 백업 등 클라우드 최적화 기능이 많습니다. 가격은 조금 비싸지만 대규모 서비스에서는 충분히 가치가 있습니다. 위의 코드를 살펴보겠습니다. boto3로 각 엔진의 사용 가능한 버전 목록을 조회합니다. 엔진마다 여러 버전이 있고, 각 버전마다 기능과 성능이 다릅니다. 최신 버전일수록 보안 패치와 성능 개선이 적용되어 있습니다. 실무에서는 어떻게 선택할까요? 신규 프로젝트라면 **PostgreSQL**을 추천합니다. 기능이 풍부하고 성능도 우수합니다. MySQL에 익숙하다면 **MySQL 8.0**도 좋은 선택입니다. 대규모 트래픽이 예상되고 예산이 충분하다면 **Aurora**를 고려하세요. 기존 시스템 이전이라면 기존에 사용하던 엔진을 그대로 선택합니다. 김개발 씨는 고민 끝에 PostgreSQL을 선택했습니다. "회사에서 PostgreSQL을 표준으로 사용한다고 하셨잖아요." 박시니어 씨가 미소를 지었습니다. "좋은 선택이에요!" 데이터베이스 엔진 선택은 프로젝트의 방향을 결정하는 중요한 결정입니다. 하지만 너무 걱정하지 마세요. 나중에 필요하면 다른 엔진으로 마이그레이션할 수도 있습니다. **실전 팁** 💡 - **신규 프로젝트는 PostgreSQL 또는 MySQL 8.0**을 추천합니다 - **대규모 트래픽이 예상되면 Aurora**를 고려하세요 - **팀의 기술 스택**과 **기존 경험**을 고려해서 선택하세요 --- ## 3. RDS_인스턴스_생성 드디어 RDS 인스턴스를 생성할 시간입니다. 김개발 씨는 AWS 콘솔에서 "데이터베이스 생성" 버튼을 클릭했습니다. 하지만 설정 항목이 너무 많아서 어디서부터 시작해야 할지 막막했습니다. **RDS 인스턴스 생성**은 데이터베이스 서버를 클라우드에 만드는 과정입니다. 엔진 선택, 인스턴스 크기, 스토리지 용량, 네트워크 설정 등을 결정합니다. 마치 새 아파트를 계약할 때 평수, 층, 옵션을 선택하는 것과 비슷합니다. 다음 코드를 살펴봅시다. ```python import boto3 rds_client = boto3.client('rds', region_name='ap-northeast-2') # RDS 인스턴스 생성 response = rds_client.create_db_instance( DBInstanceIdentifier='my-postgres-db', # 인스턴스 고유 식별자 DBInstanceClass='db.t3.micro', # 인스턴스 크기 (프리티어) Engine='postgres', # PostgreSQL 선택 EngineVersion='15.4', # 버전 MasterUsername='admin', # 관리자 계정 MasterUserPassword='MySecurePass123!', # 비밀번호 (실제로는 시크릿 매니저 사용) AllocatedStorage=20, # 스토리지 20GB VpcSecurityGroupIds=['sg-0123456789abcdef0'], # 보안 그룹 DBSubnetGroupName='my-db-subnet-group', # 서브넷 그룹 BackupRetentionPeriod=7, # 백업 보관 7일 PubliclyAccessible=False, # 외부 접근 차단 StorageEncrypted=True # 암호화 활성화 ) print(f"인스턴스 생성 시작: {response['DBInstance']['DBInstanceIdentifier']}") ``` 김개발 씨는 AWS 콘솔 화면을 뚫어지게 바라보고 있었습니다. "데이터베이스 생성" 페이지에는 설정 항목이 수십 개나 되었습니다. 엔진 버전, 템플릿, 인스턴스 클래스, 스토리지, VPC, 서브넷... "이걸 언제 다 채워요?" 김개발 씨는 한숨을 쉬었습니다. 박시니어 씨가 다가와 화면을 보더니 웃었습니다. "복잡해 보이지만 핵심은 간단해요. 중요한 것만 제대로 설정하면 됩니다." RDS 인스턴스 생성은 정확히 무엇을 의미할까요? 쉽게 비유하자면, 인스턴스 생성은 마치 새 아파트를 계약하는 것과 같습니다. 먼저 평수를 선택하고(인스턴스 크기), 층을 고르고(가용 영역), 옵션을 선택합니다(백업, 암호화). 계약이 완료되면 아파트가 준비되고, 입주할 수 있습니다. RDS도 마찬가지입니다. 설정을 완료하면 AWS가 데이터베이스 서버를 자동으로 구축해줍니다. 과거에 직접 데이터베이스를 구축하던 시절에는 어땠을까요? 먼저 물리 서버를 구매하거나 IDC를 계약해야 했습니다. 서버가 도착하면 랙에 설치하고 네트워크 케이블을 연결했습니다. 운영체제를 설치하고, 데이터베이스 소프트웨어를 설치하고, 방화벽을 설정하고... 이 모든 과정에 며칠이 걸렸습니다. 설정 하나만 잘못해도 보안 사고가 발생할 수 있었습니다. 하지만 RDS는 이 모든 과정을 몇 분으로 단축시켰습니다. 인스턴스 생성 화면에서 가장 먼저 결정할 것은 **생성 방법**입니다. "표준 생성"과 "손쉬운 생성" 두 가지가 있습니다. 처음이라면 "손쉬운 생성"을 선택하세요. AWS가 권장 설정을 자동으로 적용해줍니다. 다음은 **엔진 선택**입니다. 앞서 배운 대로 PostgreSQL을 선택했다고 가정하겠습니다. 버전은 최신 안정 버전을 선택하세요. 너무 최신 버전은 버그가 있을 수 있고, 너무 오래된 버전은 보안 패치가 없을 수 있습니다. **템플릿**에서는 프로덕션, 개발/테스트, 프리티어 중 하나를 선택합니다. 처음 시작한다면 프리티어를 선택하세요. 12개월 동안 무료로 사용할 수 있습니다. 가장 중요한 설정 중 하나는 **DB 인스턴스 크기**입니다. 프리티어는 db.t3.micro(또는 db.t2.micro)만 사용할 수 있습니다. 이 인스턴스는 CPU 2코어, 메모리 1GB 정도의 성능입니다. 작은 개발 프로젝트에는 충분하지만, 실제 서비스에는 더 큰 인스턴스가 필요할 수 있습니다. **스토리지**는 데이터베이스가 사용할 디스크 공간입니다. 프리티어는 최대 20GB까지 무료입니다. 스토리지 타입은 범용 SSD(gp2 또는 gp3)를 선택하세요. 고성능이 필요하면 프로비저닝된 IOPS(io1)를 선택할 수 있지만, 비용이 훨씬 비쌉니다. **연결 설정**은 네트워크 관련 설정입니다. VPC, 서브넷 그룹, 퍼블릭 액세스, 보안 그룹을 설정합니다. 보안을 위해 **퍼블릭 액세스는 비활성화**하는 것이 좋습니다. 외부에서 직접 접근하지 못하게 하고, EC2나 Lambda에서만 접근하도록 합니다. **데이터베이스 인증**은 암호 방식을 선택합니다. 일반적으로 암호 인증을 사용하지만, IAM 인증을 활성화하면 더 안전합니다. **추가 구성**에서는 백업, 암호화, 로그 내보내기 등을 설정합니다. **자동 백업**은 반드시 활성화하세요. 백업 보관 기간은 최소 7일을 권장합니다. **암호화**도 활성화하는 것이 좋습니다. 데이터가 디스크에 암호화되어 저장됩니다. 위의 코드를 살펴보겠습니다. `create_db_instance()` 메서드로 인스턴스를 생성합니다. DBInstanceIdentifier는 인스턴스의 고유한 이름입니다. DBInstanceClass는 인스턴스 크기를 결정합니다. MasterUsername과 MasterUserPassword는 관리자 계정 정보입니다. 실제 프로덕션에서는 비밀번호를 코드에 하드코딩하지 말고 AWS Secrets Manager를 사용하세요. 실무에서는 어떻게 생성할까요? 대부분의 회사는 Terraform이나 CloudFormation 같은 Infrastructure as Code 도구를 사용합니다. 코드로 인스턴스를 정의하면 동일한 환경을 반복해서 생성할 수 있습니다. 개발 환경, 스테이징 환경, 프로덕션 환경을 일관되게 구축할 수 있습니다. 인스턴스 생성 버튼을 클릭하면 어떻게 될까요? AWS가 백그라운드에서 데이터베이스 서버를 프로비저닝합니다. 보통 5~10분 정도 걸립니다. 상태가 "생성 중"에서 "사용 가능"으로 바뀌면 접속할 수 있습니다. 엔드포인트 주소가 생성되는데, 이 주소로 데이터베이스에 접속합니다. 김개발 씨는 조심스럽게 설정을 완료하고 "데이터베이스 생성" 버튼을 눌렀습니다. "이제 기다리면 되나요?" 박시니어 씨가 고개를 끄덕였습니다. "네, 잠깐 기다리면 데이터베이스가 준비됩니다." RDS 인스턴스 생성은 복잡해 보이지만, 한 번 익숙해지면 간단합니다. 여러분도 직접 해보면서 각 설정의 의미를 이해해 보세요. **실전 팁** 💡 - **프리티어는 db.t3.micro와 20GB**까지만 무료입니다 - **퍼블릭 액세스는 비활성화**하고 보안 그룹으로 접근을 제어하세요 - **비밀번호는 Secrets Manager**에 저장하고 코드에는 하드코딩하지 마세요 --- ## 4. 프리티어_옵션_선택 김개발 씨는 프리티어 템플릿을 선택했습니다. "1년 동안 무료라니 좋네요!" 하지만 박시니어 씨가 경고했습니다. "조심하세요. 프리티어 범위를 벗어나면 과금됩니다." **AWS 프리티어**는 신규 가입자에게 12개월 동안 무료로 제공되는 혜택입니다. RDS는 db.t2.micro 또는 db.t3.micro 인스턴스와 20GB 스토리지를 무료로 사용할 수 있습니다. 하지만 범위를 초과하거나 다른 옵션을 선택하면 과금이 시작됩니다. 다음 코드를 살펴봅시다. ```python import boto3 from datetime import datetime, timedelta rds_client = boto3.client('rds', region_name='ap-northeast-2') cloudwatch = boto3.client('cloudwatch', region_name='ap-northeast-2') # 프리티어 인스턴스 생성 response = rds_client.create_db_instance( DBInstanceIdentifier='my-free-tier-db', DBInstanceClass='db.t3.micro', # 프리티어 인스턴스 Engine='postgres', MasterUsername='admin', MasterUserPassword='MySecurePass123!', AllocatedStorage=20, # 프리티어 최대 용량 BackupRetentionPeriod=1, # 백업은 1일만 (비용 절감) StorageEncrypted=False, # 암호화 비활성화 (프리티어) PubliclyAccessible=False ) # 스토리지 사용량 모니터링 metrics = cloudwatch.get_metric_statistics( Namespace='AWS/RDS', MetricName='FreeStorageSpace', Dimensions=[{'Name': 'DBInstanceIdentifier', 'Value': 'my-free-tier-db'}], StartTime=datetime.now() - timedelta(hours=1), EndTime=datetime.now(), Period=3600, Statistics=['Average'] ) print(f"남은 스토리지: {metrics['Datapoints']}") ``` 김개발 씨는 신이 났습니다. "RDS를 1년 동안 공짜로 쓸 수 있다고요?" AWS 프리티어 페이지를 보니 정말 무료라고 쓰여 있었습니다. 하지만 작은 글씨로 적힌 주의사항이 눈에 들어왔습니다. 박시니어 씨가 진지하게 말했습니다. "프리티어는 좋지만 조심해야 해요. 많은 신입 개발자들이 과금 폭탄을 맞았거든요." AWS 프리티어는 정확히 무엇일까요? 쉽게 비유하자면, 프리티어는 마치 헬스장의 무료 체험권과 같습니다. 한 달 동안 헬스장을 무료로 이용할 수 있지만, 프리미엄 프로그램이나 개인 트레이닝은 추가 비용이 듭니다. 정해진 시간과 기구만 사용해야 무료입니다. AWS도 마찬가지입니다. 정해진 범위 내에서만 무료이고, 범위를 벗어나면 비용이 청구됩니다. 과거에는 클라우드를 시도하기가 두려웠습니다. "실수로 뭔가 잘못 설정하면 수백만 원이 청구되지 않을까?" 이런 두려움 때문에 많은 개발자들이 클라우드를 시도하지 못했습니다. 실제로 몇 년 전에는 개발자가 EC2 인스턴스를 끄지 않고 방치해서 수천만 원이 청구된 사례도 있었습니다. AWS는 이런 진입 장벽을 낮추기 위해 프리티어를 제공합니다. **RDS 프리티어**의 정확한 범위는 이렇습니다. db.t2.micro 또는 db.t3.micro 인스턴스를 한 달에 750시간 사용할 수 있습니다. 한 달이 30일이면 720시간이므로, 인스턴스 하나를 24시간 내내 켜둘 수 있습니다. 스토리지는 범용 SSD(gp2) 20GB까지 무료입니다. 백업 스토리지도 20GB까지 무료입니다. 하지만 여기에 숨겨진 함정이 있습니다. 첫 번째 함정은 **인스턴스를 두 개 생성하는 경우**입니다. 인스턴스를 두 개 만들면 한 달에 1500시간이 필요한데, 프리티어는 750시간만 무료입니다. 나머지 750시간은 과금됩니다. 개발용과 테스트용으로 인스턴스를 분리하고 싶다면 둘 중 하나는 꺼두어야 합니다. 두 번째 함정은 **스토리지 초과**입니다. 20GB를 넘으면 초과분에 대해 과금됩니다. 데이터가 늘어나면 스토리지도 자동으로 늘어나는데, 이때 과금이 시작됩니다. 스토리지 자동 확장 기능을 비활성화하는 것이 안전합니다. 세 번째 함정은 **프리티어 대상이 아닌 옵션**입니다. Multi-AZ를 활성화하면 프리티어가 적용되지 않습니다. 프로비저닝된 IOPS를 선택해도 과금됩니다. 암호화를 활성화하는 것 자체는 무료이지만, KMS 키 사용료는 별도입니다. 네 번째 함정은 **12개월 제한**입니다. AWS 계정을 생성한 날부터 12개월 동안만 프리티어가 적용됩니다. 13개월째부터는 자동으로 유료로 전환됩니다. 캘린더에 표시해두고 미리 준비하세요. 다섯 번째 함정은 **데이터 전송 비용**입니다. RDS에서 인터넷으로 데이터를 전송하면 비용이 청구됩니다. 같은 리전 내의 EC2와 통신하는 것은 무료이지만, 다른 리전이나 인터넷으로 전송하면 GB당 비용이 발생합니다. 위의 코드를 살펴보겠습니다. 프리티어 범위 내에서 인스턴스를 생성하는 예제입니다. StorageEncrypted를 False로 설정한 이유는 KMS 키 비용을 피하기 위함입니다. BackupRetentionPeriod를 1로 설정해서 백업 스토리지 사용량을 최소화했습니다. CloudWatch로 스토리지 사용량을 모니터링해서 20GB를 넘지 않도록 관리합니다. 실무에서는 어떻게 활용할까요? 프리티어는 학습용이나 소규모 개발 프로젝트에 적합합니다. 개인 포트폴리오 프로젝트, 사이드 프로젝트, 테스트 환경으로 사용하세요. 하지만 실제 서비스를 운영하려면 프리티어로는 부족합니다. 트래픽이 늘어나면 더 큰 인스턴스가 필요하고, 가용성을 위해 Multi-AZ가 필요합니다. 과금을 방지하는 가장 좋은 방법은 **빌링 알람**을 설정하는 것입니다. CloudWatch에서 예상 청구 금액이 일정 금액(예: 10달러)을 넘으면 이메일로 알람을 보내도록 설정하세요. 매일 AWS Cost Explorer를 확인하는 습관도 좋습니다. 예상치 못한 비용이 발생하면 즉시 원인을 파악하고 리소스를 종료하세요. 김개발 씨는 박시니어 씨의 조언을 듣고 빌링 알람을 설정했습니다. "이제 안심이에요!" 하지만 박시니어 씨는 마지막 당부를 잊지 않았습니다. "그래도 주기적으로 확인하는 게 좋아요." 프리티어는 AWS를 배우는 좋은 기회입니다. 하지만 과금 범위를 정확히 이해하고 사용해야 합니다. 여러분도 빌링 알람을 설정하고 안전하게 사용하세요. **실전 팁** 💡 - **빌링 알람을 반드시 설정**하고 10달러 이상이면 알림을 받으세요 - **인스턴스는 하나만 생성**하고 24시간 실행하세요 - **12개월 후 자동 과금**을 대비해 캘린더에 표시하세요 --- ## 5. DB_서브넷_그룹 인스턴스 생성 중에 "DB 서브넷 그룹"이라는 설정이 나타났습니다. 김개발 씨는 당황했습니다. "서브넷 그룹이 뭐죠?" 박시니어 씨가 설명을 시작했습니다. **DB 서브넷 그룹**은 RDS 인스턴스가 배치될 수 있는 서브넷의 모음입니다. 최소 2개 이상의 가용 영역에 서브넷을 지정해야 합니다. 이것은 고가용성과 장애 복구를 위한 필수 설정입니다. 다음 코드를 살펴봅시다. ```python import boto3 ec2_client = boto3.client('ec2', region_name='ap-northeast-2') rds_client = boto3.client('rds', region_name='ap-northeast-2') # VPC의 서브넷 조회 vpc_id = 'vpc-0123456789abcdef0' subnets = ec2_client.describe_subnets( Filters=[{'Name': 'vpc-id', 'Values': [vpc_id]}] ) # 최소 2개의 서로 다른 가용 영역 선택 subnet_ids = [s['SubnetId'] for s in subnets['Subnets'][:2]] # DB 서브넷 그룹 생성 response = rds_client.create_db_subnet_group( DBSubnetGroupName='my-db-subnet-group', DBSubnetGroupDescription='Subnet group for RDS instances', SubnetIds=subnet_ids, # 최소 2개의 서브넷 Tags=[ {'Key': 'Environment', 'Value': 'Development'}, {'Key': 'Project', 'Value': 'MyApp'} ] ) print(f"서브넷 그룹 생성: {response['DBSubnetGroup']['DBSubnetGroupName']}") print(f"포함된 서브넷: {[s['SubnetIdentifier'] for s in response['DBSubnetGroup']['Subnets']]}") ``` 김개발 씨는 RDS 생성 화면에서 "서브넷 그룹"이라는 낯선 용어를 발견했습니다. 드롭다운을 클릭하니 "default"라는 항목이 있었지만, 뭘 선택해야 할지 막막했습니다. "이게 왜 필요한 건가요?" 박시니어 씨가 화이트보드를 꺼내 그림을 그리기 시작했습니다. "VPC와 서브넷을 이해해야 서브넷 그룹을 이해할 수 있어요." DB 서브넷 그룹은 무엇일까요? 쉽게 비유하자면, 서브넷 그룹은 마치 아파트 단지의 동(棟) 목록과 같습니다. "우리 아파트는 101동, 102동, 103동에 세대가 있습니다"라고 지정하는 것입니다. RDS가 어느 동에 배치될지 미리 정해두는 것이죠. 만약 101동에 문제가 생기면 자동으로 102동으로 옮겨갈 수 있습니다. 서브넷 그룹이 없던 시절에는 어땠을까요? 초기 클라우드 서비스에서는 데이터베이스를 하나의 서버에만 배치했습니다. 그 서버나 데이터 센터에 문제가 생기면 서비스 전체가 다운되었습니다. 2011년 아마존의 한 데이터 센터에서 장애가 발생했을 때, 수많은 서비스가 몇 시간 동안 중단되었습니다. 넷플릭스, 레딧, 쿼라 같은 유명 서비스들도 영향을 받았습니다. AWS는 이 문제를 해결하기 위해 **가용 영역**(Availability Zone)이라는 개념을 도입했습니다. 서울 리전(ap-northeast-2)에는 ap-northeast-2a, 2b, 2c, 2d라는 4개의 가용 영역이 있습니다. 각 가용 영역은 물리적으로 분리된 데이터 센터입니다. 하나의 가용 영역에 화재나 정전이 발생해도 다른 가용 영역은 정상적으로 작동합니다. DB 서브넷 그룹은 최소 2개의 가용 영역에 서브넷을 지정해야 합니다. 예를 들어 2a와 2c 가용 영역에 각각 프라이빗 서브넷을 만들고, 이 두 서브넷을 서브넷 그룹으로 묶습니다. RDS는 이 중 하나의 서브넷에 기본 인스턴스를 배치합니다. Multi-AZ를 활성화하면 다른 가용 영역에 대기 인스턴스를 자동으로 생성합니다. 왜 2개 이상이어야 할까요? 장애 복구 때문입니다. 기본 인스턴스가 있는 가용 영역에 문제가 생기면, RDS가 자동으로 다른 가용 영역의 대기 인스턴스로 전환합니다. 이것을 **Failover**라고 합니다. 전환 시간은 보통 60~120초 정도입니다. 사용자는 잠깐의 지연만 경험하고 서비스는 계속 작동합니다. 서브넷 그룹을 만들 때 주의할 점이 있습니다. 첫째, **프라이빗 서브넷**을 사용하세요. 데이터베이스는 인터넷에 직접 노출되면 안 됩니다. 퍼블릭 서브넷이 아닌 프라이빗 서브넷에 배치해야 합니다. 둘째, **서브넷의 IP 범위**를 충분히 확보하세요. RDS 인스턴스뿐만 아니라 내부 관리용 리소스도 IP를 사용합니다. 서브넷당 최소 /27(32개 IP) 이상을 권장합니다. 셋째, **라우팅 테이블**을 확인하세요. 프라이빗 서브넷은 NAT 게이트웨이를 통해 인터넷에 접근할 수 있어야 합니다. 업데이트와 패치를 받기 위해서입니다. 위의 코드를 살펴보겠습니다. 먼저 VPC의 서브넷 목록을 조회합니다. 그중에서 최소 2개를 선택해서 서브넷 그룹을 생성합니다. 실무에서는 프라이빗 서브넷만 필터링해서 선택해야 합니다. 태그를 달아서 어떤 용도인지 명확히 표시하는 것도 좋은 습관입니다. 실무에서는 어떻게 구성할까요? 보통 VPC를 생성할 때 미리 서브넷 구조를 설계합니다. 퍼블릭 서브넷 2개(웹 서버용), 프라이빗 서브넷 2개(애플리케이션 서버용), 프라이빗 서브넷 2개(데이터베이스용)를 만듭니다. 데이터베이스용 서브넷 2개로 서브넷 그룹을 만듭니다. 이렇게 하면 웹 서버, 애플리케이션 서버, 데이터베이스가 각각 별도의 네트워크 계층에 분리됩니다. 보안 그룹으로 계층 간 통신만 허용하면 보안이 크게 향상됩니다. 서브넷 그룹을 한번 만들어두면 여러 RDS 인스턴스에서 재사용할 수 있습니다. 개발용 데이터베이스, 스테이징용 데이터베이스, 프로덕션용 데이터베이스 모두 같은 서브넷 그룹을 사용할 수 있습니다. 단, 프로덕션용은 별도의 서브넷 그룹을 만들어서 네트워크를 분리하는 것이 더 안전합니다. 김개발 씨는 고개를 끄덕였습니다. "그래서 서브넷 그룹이 필요한 거군요. 장애가 나도 서비스가 계속 돌아가게 하려고요." 박시니어 씨가 미소를 지었습니다. "맞아요. 클라우드의 핵심은 바로 이런 고가용성입니다." 서브넷 그룹은 처음에는 복잡해 보이지만, 고가용성의 기본입니다. 여러분도 프로젝트를 시작할 때 VPC와 서브넷을 제대로 설계하세요. **실전 팁** 💡 - **프라이빗 서브넷 2개 이상**을 서로 다른 가용 영역에 배치하세요 - **서브넷 IP 범위는 /27 이상**으로 충분히 확보하세요 - **프로덕션용은 별도 서브넷 그룹**으로 네트워크를 분리하세요 --- ## 6. 파라미터_그룹 인스턴스가 생성되고 며칠 뒤, 김개발 씨는 문제를 발견했습니다. 데이터베이스 타임존이 UTC로 설정되어 있었습니다. "한국 시간으로 바꾸려면 어떻게 하죠?" 박시니어 씨가 "파라미터 그룹을 수정하면 됩니다"라고 답했습니다. **파라미터 그룹**은 데이터베이스 엔진의 설정을 관리하는 템플릿입니다. 타임존, 문자셋, 메모리 설정, 연결 제한 등을 조정할 수 있습니다. 마치 애플리케이션의 config 파일과 같은 역할을 합니다. 다음 코드를 살펴봅시다. ```python import boto3 rds_client = boto3.client('rds', region_name='ap-northeast-2') # 파라미터 그룹 생성 response = rds_client.create_db_parameter_group( DBParameterGroupName='my-postgres-params', DBParameterGroupFamily='postgres15', # PostgreSQL 15 패밀리 Description='Custom parameter group for PostgreSQL 15' ) # 파라미터 수정 (타임존을 Asia/Seoul로 설정) rds_client.modify_db_parameter_group( DBParameterGroupName='my-postgres-params', Parameters=[ { 'ParameterName': 'timezone', 'ParameterValue': 'Asia/Seoul', 'ApplyMethod': 'pending-reboot' # 재시작 필요 }, { 'ParameterName': 'max_connections', 'ParameterValue': '200', 'ApplyMethod': 'immediate' # 즉시 적용 }, { 'ParameterName': 'shared_buffers', 'ParameterValue': '256MB', 'ApplyMethod': 'pending-reboot' } ] ) # 인스턴스에 파라미터 그룹 적용 rds_client.modify_db_instance( DBInstanceIdentifier='my-postgres-db', DBParameterGroupName='my-postgres-params', ApplyImmediately=False # 다음 유지보수 기간에 적용 ) print("파라미터 그룹 생성 및 적용 완료") ``` 김개발 씨는 데이터베이스에 저장된 시간이 이상하다는 것을 발견했습니다. 오후 3시에 저장한 데이터인데 시간이 6시로 표시되었습니다. "왜 이렇게 나오는 거죠?" 로그를 확인해보니 데이터베이스 타임존이 UTC로 설정되어 있었습니다. 박시니어 씨가 설명했습니다. "RDS는 기본적으로 UTC를 사용해요. 한국 시간으로 바꾸려면 파라미터 그룹을 수정해야 합니다." 파라미터 그룹은 정확히 무엇일까요? 쉽게 비유하자면, 파라미터 그룹은 마치 자동차의 설정과 같습니다. 실내 온도, 시트 위치, 사이드미러 각도, 핸들 무게감 등을 조정하는 것입니다. 공장 출하 시에는 기본 설정이 되어 있지만, 운전자의 취향에 맞게 바꿀 수 있습니다. 데이터베이스도 마찬가지입니다. 기본 설정이 있지만, 프로젝트에 맞게 커스터마이징해야 합니다. 파라미터 그룹이 없던 시절에는 어땠을까요? 과거에 직접 MySQL이나 PostgreSQL을 설치했을 때는 설정 파일을 직접 수정했습니다. `/etc/mysql/my.cnf`나 `/etc/postgresql/postgresql.conf` 같은 파일을 vi 에디터로 열어서 한 줄씩 고쳤습니다. 오타를 내면 데이터베이스가 시작되지 않았습니다. 설정을 백업하지 않으면 나중에 어떤 값을 바꿨는지 기억하지 못했습니다. RDS는 이 문제를 파라미터 그룹으로 해결했습니다. 파라미터 그룹은 설정의 템플릿입니다. 한번 만들어두면 여러 인스턴스에 적용할 수 있습니다. 개발 환경, 스테이징 환경, 프로덕션 환경에 각각 다른 파라미터 그룹을 적용할 수도 있습니다. 변경 이력이 자동으로 기록되므로 문제가 생기면 이전 설정으로 되돌릴 수 있습니다. 파라미터 그룹에는 수백 개의 파라미터가 있습니다. 모든 파라미터를 이해할 필요는 없습니다. 실무에서 자주 조정하는 파라미터만 알아두면 됩니다. **timezone**은 데이터베이스의 시간대를 설정합니다. 한국에서 서비스한다면 'Asia/Seoul'로 설정하세요. 이렇게 하면 NOW() 함수가 한국 시간을 반환합니다. **character_set_server**(MySQL) 또는 **client_encoding**(PostgreSQL)은 문자 인코딩을 설정합니다. 한글을 사용한다면 utf8mb4(MySQL) 또는 UTF8(PostgreSQL)로 설정해야 합니다. **max_connections**는 동시 접속 가능한 클라이언트 수를 제한합니다. 기본값은 인스턴스 크기에 따라 다릅니다. t3.micro는 약 80개, t3.small은 약 150개입니다. 접속이 많은 서비스는 이 값을 높여야 하지만, 너무 높이면 메모리 부족이 발생할 수 있습니다. **shared_buffers**(PostgreSQL) 또는 **innodb_buffer_pool_size**(MySQL)는 데이터베이스가 메모리에 캐시하는 데이터 크기입니다. 이 값이 클수록 디스크 I/O가 줄어들어 성능이 향상됩니다. 보통 인스턴스 메모리의 25~40%를 할당합니다. **log_statement**(PostgreSQL)는 로그에 기록할 쿼리를 설정합니다. 'all'로 설정하면 모든 쿼리가 로깅되는데, 개발 환경에서는 유용하지만 프로덕션에서는 성능 저하와 스토리지 낭비가 발생합니다. 파라미터에는 두 가지 적용 방식이 있습니다. **immediate**는 즉시 적용됩니다. 데이터베이스를 재시작하지 않아도 바로 효과가 나타납니다. max_connections 같은 파라미터가 여기에 해당합니다. **pending-reboot**는 데이터베이스를 재시작해야 적용됩니다. shared_buffers처럼 메모리 관련 설정은 재시작이 필요합니다. 재시작하면 잠깐 동안 데이터베이스 접속이 불가능하므로, 유지보수 시간에 계획적으로 진행해야 합니다. 위의 코드를 살펴보겠습니다. 먼저 새로운 파라미터 그룹을 생성합니다. DBParameterGroupFamily는 데이터베이스 엔진과 버전에 맞게 설정해야 합니다. PostgreSQL 15를 사용한다면 'postgres15'를 지정합니다. 그다음 필요한 파라미터를 수정합니다. 마지막으로 인스턴스에 파라미터 그룹을 적용합니다. 실무에서는 어떻게 관리할까요? 보통 환경별로 파라미터 그룹을 분리합니다. 'dev-postgres-params', 'staging-postgres-params', 'prod-postgres-params'처럼 이름을 붙입니다. 개발 환경에서는 쿼리 로깅을 활성화하고, 프로덕션에서는 성능 최적화 설정을 적용합니다. 파라미터를 수정할 때는 반드시 **백업과 테스트**를 거쳐야 합니다. 잘못된 파라미터 설정은 데이터베이스 성능을 오히려 저하시키거나, 심한 경우 데이터베이스가 시작되지 않을 수도 있습니다. 먼저 개발 환경에서 테스트하고, 문제가 없으면 스테이징 환경을 거쳐 프로덕션에 적용합니다. 김개발 씨는 파라미터 그룹에서 타임존을 'Asia/Seoul'로 변경하고 인스턴스를 재시작했습니다. 이제 시간이 정확하게 표시되었습니다. "드디어 해결했어요!" 박시니어 씨가 웃으며 말했습니다. "이제 RDS의 기본은 마스터했네요." 파라미터 그룹은 데이터베이스를 프로젝트에 맞게 최적화하는 핵심 도구입니다. 여러분도 프로젝트를 시작할 때 파라미터 그룹을 제대로 설정하세요. **실전 팁** 💡 - **타임존은 'Asia/Seoul'로 설정**하고 문자셋은 UTF8로 설정하세요 - **환경별로 파라미터 그룹을 분리**해서 관리하세요 - **파라미터 수정 전에 백업**을 만들고 개발 환경에서 먼저 테스트하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: Python

태그: AWS, RDS, Database, PostgreSQL, MySQL

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS RDS 데이터베이스 생성 완벽 가이드

목차

1. RDS란 무엇인가

2. 지원 DB 엔진 종류

3. RDS 인스턴스 생성

4. 프리티어 옵션 선택

5. DB 서브넷 그룹

6. 파라미터 그룹

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS Organizations 완벽 가이드

AWS KMS 암호화 완벽 가이드

AWS Secrets Manager 완벽 가이드