Terraform 시니어 데이터베이스 기술면접
새 면접Q. Terraform으로 RDS 인스턴스를 관리하던 중 State 파일에는 존재하지만 실제 AWS에는 삭제된 데이터베이스가 발견되었습니다. 이 상황에서 State 불일치를 해결하고 데이터 손실 없이 재생성하는 전략을 설명해주세요.
State 파일 조작 명령어와 백업 복원 절차를 함께 고려해보세요.
먼저 terraform state list로 State에 있는 리소스를 확인하고, terraform state rm으로 해당 RDS 리소스를 State에서 제거합니다. 실제 DB가 삭제되었으므로 백업에서 복원이 필요한데, AWS RDS 자동 백업이나 스냅샷을 활용해 새 인스턴스를 생성합니다. 복원된 인스턴스를 terraform import 명령어로 State에 다시 등록하여 Terraform 관리 하에 둡니다. 이후 terraform plan으로 설정 차이를 확인하고 필요시 코드를 조정합니다. 마지막으로 State 파일을 원격 백엔드에 저장하고 State 잠금을 활성화하여 향후 불일치를 방지합니다.
- • terraform state rm으로 불일치 리소스를 State에서 제거
- • RDS 스냅샷이나 자동 백업을 활용한 데이터 복원
- • terraform import로 복원된 리소스를 State에 재등록
- • 원격 백엔드와 State 잠금으로 불일치 예방
수동으로 삭제된 리소스나 콘솔에서 직접 수정된 리소스로 인한 State 불일치는 실무에서 자주 발생하는 문제입니다.
State 파일이 완전히 손실되었을 때 전체 인프라를 다시 import하는 전략은 무엇인가요?
Q. Terraform으로 운영 중인 Aurora PostgreSQL 클러스터를 무중단으로 다른 VPC로 마이그레이션해야 합니다. 데이터 정합성과 다운타임 최소화를 위한 Terraform 기반 마이그레이션 전략을 설계해주세요.
리드 레플리카와 Blue-Green 배포 패턴을 활용하는 방법을 생각해보세요.
먼저 새 VPC에 Aurora 클러스터를 별도로 생성하고, DMS(Database Migration Service)를 Terraform으로 프로비저닝하여 CDC 방식으로 실시간 복제를 설정합니다. 복제 지연이 최소화되면 애플리케이션의 읽기 트래픽을 점진적으로 새 클러스터로 전환하고, 쓰기 트래픽은 잠시 중단 후 전환합니다. Route53 가중치 기반 라우팅을 Terraform으로 설정하여 트래픽을 제어하며, 롤백을 위해 기존 클러스터는 일정 기간 유지합니다. 모든 트래픽이 안정화되면 terraform destroy로 기존 클러스터를 제거하고, State 파일을 정리합니다. 전체 과정을 Terraform workspace나 모듈로 분리하여 단계별 적용이 가능하도록 구성합니다.
- • DMS를 활용한 CDC 기반 실시간 데이터 복제
- • Route53 가중치 라우팅으로 점진적 트래픽 전환
- • Terraform workspace로 단계별 마이그레이션 관리
- • 롤백 계획을 위한 기존 리소스 유지 전략
VPC 재설계나 리전 이전 시 운영 중인 데이터베이스를 무중단으로 마이그레이션하는 것은 필수적인 작업입니다.
마이그레이션 중 데이터 정합성을 검증하는 방법은 무엇인가요?
Q. Terraform으로 관리하는 RDS 인스턴스의 파라미터 그룹에서 성능 튜닝을 위해 조정해야 할 주요 파라미터들과 Terraform 코드 구성 방법을 설명해주세요.
연결 풀, 메모리, 쿼리 캐시 관련 파라미터를 고려하세요.
aws_db_parameter_group 리소스를 사용하여 파라미터를 관리하며, max_connections는 인스턴스 메모리에 맞게 조정하고 shared_buffers는 전체 메모리의 25% 정도로 설정합니다. work_mem은 복잡한 쿼리 성능에 영향을 주므로 워크로드에 따라 조정하며, effective_cache_size는 OS 캐시를 포함한 사용 가능한 메모리의 50-75%로 설정합니다. slow_query_log을 활성화하여 성능 문제를 모니터링하고, log_min_duration_statement로 느린 쿼리 기준을 정의합니다. 파라미터 변경은 apply_method를 immediate 또는 pending-reboot로 설정하여 적용 시점을 제어하며, 변수화하여 환경별로 다른 값을 적용할 수 있도록 구성합니다.
- • aws_db_parameter_group으로 파라미터 중앙 관리
- • 메모리 관련 파라미터(shared_buffers, work_mem) 최적화
- • apply_method로 파라미터 적용 시점 제어
- • 환경별 변수화를 통한 유연한 설정 관리
RDS 파라미터 튜닝은 데이터베이스 성능 최적화의 기본이며, Terraform으로 관리하면 버전 관리와 재현성을 확보할 수 있습니다.
파라미터 변경 후 성능 개선을 측정하고 검증하는 방법은 무엇인가요?
Q. Terraform으로 관리하는 멀티 리전 데이터베이스 환경에서 재해 복구(DR) 전략을 구현하려고 합니다. RPO 1시간, RTO 4시간을 만족하는 아키텍처를 Terraform으로 어떻게 구성하겠습니까?
크로스 리전 복제와 자동화된 페일오버 메커니즘을 고려하세요.
Primary 리전에 Aurora Global Database를 Terraform으로 생성하고, Secondary 리전에 읽기 전용 복제본을 자동으로 프로비저닝합니다. aws_rds_global_cluster 리소스로 글로벌 클러스터를 정의하고, 각 리전별로 aws_rds_cluster를 생성하여 연결합니다. RPO 1시간을 위해 자동 백업 보존 기간을 최소 24시간으로 설정하고, 스냅샷을 크로스 리전으로 복사하는 Lambda 함수를 Terraform으로 배포합니다. RTO 4시간을 위해 Secondary 리전의 인프라를 미리 프로비저닝하고, Route53 헬스체크와 페일오버 라우팅 정책을 설정합니다. terraform workspace를 리전별로 분리하고, 재해 발생 시 terraform apply로 Secondary를 Primary로 승격시키는 런북을 작성합니다. 전체 DR 프로세스를 주기적으로 테스트하는 자동화 스크립트도 함께 관리합니다.
- • Aurora Global Database로 크로스 리전 자동 복제 구현
- • 자동 백업과 스냅샷 크로스 리전 복사로 RPO 달성
- • Secondary 리전 사전 프로비저닝과 Route53 페일오버로 RTO 단축
- • Terraform workspace 분리와 자동화된 페일오버 런북 구성
금융, 의료 등 미션 크리티컬한 서비스에서는 엄격한 RPO/RTO 요구사항을 만족하는 DR 전략이 필수입니다.
페일오버 후 Primary 리전으로 다시 전환하는 페일백 전략은 어떻게 구성하나요?
Q. Terraform으로 RDS 데이터베이스의 보안을 강화하려고 합니다. 암호화, 접근 제어, 감사 로깅을 포함한 보안 구성 전략을 설명해주세요.
저장 데이터 암호화, 전송 중 암호화, IAM 인증, 네트워크 격리를 모두 고려하세요.
storage_encrypted를 true로 설정하고 KMS 키를 지정하여 저장 데이터를 암호화하며, kms_key_id를 aws_kms_key 리소스로 관리합니다. iam_database_authentication_enabled를 활성화하여 비밀번호 대신 IAM 역할 기반 인증을 사용하고, 데이터베이스 자격증명은 AWS Secrets Manager에 저장하여 Terraform data source로 참조합니다. VPC 내 프라이빗 서브넷에 배치하고 security_group으로 특정 소스만 접근 가능하도록 제한하며, publicly_accessible을 false로 설정합니다. enabled_cloudwatch_logs_exports로 감사 로그, 에러 로그, 슬로우 쿼리 로그를 CloudWatch로 전송하고, deletion_protection을 true로 설정하여 실수로 인한 삭제를 방지합니다. SSL/TLS 연결을 강제하도록 파라미터 그룹에서 rds.force_ssl을 1로 설정합니다.
- • KMS 기반 저장 데이터 암호화와 IAM 데이터베이스 인증
- • Secrets Manager로 자격증명 관리 및 순환
- • VPC 프라이빗 서브넷 배치와 보안 그룹 제한
- • CloudWatch 로그 전송과 SSL/TLS 연결 강제
컴플라이언스 요구사항과 보안 감사를 통과하기 위해서는 데이터베이스 보안 설정을 코드로 명확히 관리해야 합니다.
데이터베이스 자격증명을 자동으로 순환(rotation)하는 방법은 무엇인가요?
Q. Terraform으로 인프라를 관리하면서 데이터베이스 스키마 변경도 함께 관리해야 할 때, 어떤 접근 방식과 도구를 사용하겠습니까?
Terraform의 역할 범위와 스키마 마이그레이션 전용 도구의 조합을 고려하세요.
Terraform은 데이터베이스 인스턴스와 인프라 관리에 집중하고, 스키마 마이그레이션은 Flyway나 Liquibase 같은 전용 도구를 사용하는 것이 바람직합니다. Terraform의 null_resource와 local-exec provisioner를 활용하여 RDS 생성 후 마이그레이션 스크립트를 실행하거나, Lambda 함수를 배포하여 스키마 변경을 관리합니다. 또는 terraform-provider-postgresql이나 terraform-provider-mysql 같은 커뮤니티 프로바이더를 사용하여 기본적인 스키마 객체를 관리할 수도 있습니다. CI/CD 파이프라인에서 Terraform apply 후 별도 단계로 스키마 마이그레이션을 실행하며, 마이그레이션 버전을 Git으로 관리하고 롤백 스크립트도 함께 준비합니다. 중요한 것은 인프라 변경과 스키마 변경을 분리하여 각각의 롤백 전략을 수립하는 것입니다.
- • Terraform은 인프라 관리, Flyway/Liquibase는 스키마 마이그레이션으로 역할 분리
- • null_resource와 local-exec로 마이그레이션 스크립트 실행
- • CI/CD 파이프라인에서 단계 분리와 독립적 롤백 전략
- • 스키마 버전을 Git으로 관리하여 추적 가능성 확보
인프라 코드와 스키마 변경을 함께 관리하면서도 각각의 라이프사이클을 독립적으로 유지하는 것이 실무의 핵심입니다.
스키마 변경으로 인한 다운타임을 최소화하는 무중단 마이그레이션 패턴은 무엇인가요?
Q. 트래픽 패턴이 시간대별로 크게 변하는 서비스에서 Terraform으로 관리하는 Aurora 클러스터의 Auto Scaling을 구성하려고 합니다. 읽기 레플리카 자동 확장 전략을 설계해주세요.
Aurora Auto Scaling 정책과 CloudWatch 메트릭 기반 트리거를 고려하세요.
aws_appautoscaling_target 리소스로 Aurora 클러스터의 읽기 레플리카를 Auto Scaling 대상으로 등록하고, 최소 1개에서 최대 5개까지 확장 가능하도록 설정합니다. aws_appautoscaling_policy로 타겟 추적 스케일링 정책을 생성하며, DatabaseConnections나 CPUUtilization 같은 CloudWatch 메트릭을 기준으로 70% 임계값을 설정합니다. 예측 가능한 트래픽 패턴이라면 aws_appautoscaling_scheduled_action으로 스케줄 기반 스케일링을 추가하여 피크 시간 전에 미리 확장합니다. scale_in_cooldown과 scale_out_cooldown을 적절히 설정하여 과도한 스케일링을 방지하고, 각 레플리카의 프로모션 우선순위를 tier 값으로 관리합니다. 스케일링 이벤트를 CloudWatch 알람과 SNS로 모니터링하며, 비용 최적화를 위해 야간 시간대에는 최소 용량으로 축소되도록 구성합니다.
- • aws_appautoscaling_target과 policy로 메트릭 기반 Auto Scaling 구성
- • 타겟 추적과 스케줄 기반 스케일링 정책 조합
- • cooldown 기간 설정으로 스케일링 안정성 확보
- • CloudWatch 알람으로 스케일링 이벤트 모니터링
이커머스나 미디어 서비스처럼 시간대별 트래픽 변동이 큰 환경에서는 Auto Scaling으로 비용과 성능을 동시에 최적화할 수 있습니다.
Auto Scaling으로 인한 연결 재분배 시 애플리케이션 레이어에서 고려해야 할 사항은 무엇인가요?
Q. Terraform으로 관리하는 데이터베이스 환경에서 성능 저하와 장애를 조기에 감지하기 위한 모니터링과 알람 체계를 어떻게 구성하겠습니까?
CloudWatch 메트릭, Performance Insights, Enhanced Monitoring을 활용하세요.
aws_cloudwatch_metric_alarm 리소스로 핵심 메트릭에 대한 알람을 생성하는데, CPUUtilization 80% 이상, FreeableMemory 1GB 이하, DatabaseConnections 최대치의 90% 이상, ReadLatency와 WriteLatency 임계값 초과를 모니터링합니다. enabled_cloudwatch_logs_exports로 슬로우 쿼리 로그를 수집하고, CloudWatch Logs Insights로 분석 쿼리를 작성합니다. Performance Insights를 활성화하여 쿼리 레벨 성능 분석을 가능하게 하고, performance_insights_retention_period를 적절히 설정합니다. Enhanced Monitoring을 켜서 OS 레벨 메트릭을 수집하며, monitoring_interval을 60초로 설정합니다. 알람 발생 시 SNS 토픽으로 알림을 전송하고, 심각도에 따라 PagerDuty나 Slack 같은 외부 시스템과 통합합니다. CloudWatch Dashboard를 Terraform으로 생성하여 주요 메트릭을 시각화합니다.
- • 핵심 메트릭(CPU, 메모리, 연결, 지연시간)에 대한 CloudWatch 알람 설정
- • Performance Insights와 Enhanced Monitoring으로 심층 분석
- • 슬로우 쿼리 로그 수집 및 CloudWatch Logs Insights 분석
- • SNS 통합으로 다양한 알림 채널 구성
데이터베이스 장애는 전체 서비스 중단으로 이어지므로, 선제적 모니터링과 신속한 알람이 필수적입니다.
알람 피로도를 줄이면서도 중요한 이슈를 놓치지 않는 알람 설계 원칙은 무엇인가요?
Q. Terraform으로 관리하는 데이터베이스 인프라의 비용을 최적화하기 위한 전략과 Terraform 코드 구성 방법을 설명해주세요.
인스턴스 타입, 예약 인스턴스, 스토리지 최적화, 백업 정책을 고려하세요.
개발/스테이징 환경은 variables와 terraform workspace를 활용하여 프로덕션보다 작은 인스턴스 타입을 사용하고, 업무 시간 외에는 중지하도록 Lambda 스케줄러를 구성합니다. 프로덕션은 Reserved Instance를 구매하여 장기 할인을 받되, Terraform 주석이나 외부 문서로 RI 정보를 기록합니다. storage_type을 gp3로 설정하고 IOPS와 처리량을 워크로드에 맞게 최적화하며, 불필요한 스냅샷은 lifecycle 정책으로 자동 삭제합니다. backup_retention_period를 법적 요구사항에 맞는 최소값으로 설정하고, 장기 보관이 필요한 백업은 S3 Glacier로 이동합니다. Multi-AZ가 필요 없는 환경은 single-AZ로 구성하고, 읽기 레플리카는 Auto Scaling으로 필요한 만큼만 유지합니다. AWS Cost Explorer API를 활용하여 데이터베이스 비용을 태그별로 추적하고, 정기적으로 리뷰합니다.
- • 환경별 인스턴스 타입 차별화와 개발 환경 자동 중지
- • gp3 스토리지와 IOPS 최적화, 스냅샷 lifecycle 관리
- • backup_retention_period 최소화와 장기 백업 Glacier 이동
- • 태그 기반 비용 추적과 정기적 최적화 리뷰
데이터베이스는 인프라 비용의 큰 부분을 차지하므로, 성능을 유지하면서 비용을 최적화하는 것이 중요합니다.
Savings Plans과 Reserved Instance 중 어떤 것을 선택하는 것이 유리한가요?
Q. 여러 팀이 사용할 수 있는 재사용 가능한 RDS Terraform 모듈을 설계한다면, 어떤 구조와 인터페이스로 만들겠습니까?
입력 변수의 유연성, 기본값 설정, 출력값 정의, 모범 사례 강제를 고려하세요.
모듈은 필수 변수(엔진, 버전, 인스턴스 클래스, VPC ID)와 선택적 변수(백업 설정, 파라미터 그룹, 모니터링 옵션)를 명확히 구분하여 정의합니다. 보안 모범 사례를 기본값으로 강제하되, storage_encrypted는 true, publicly_accessible은 false, deletion_protection은 환경 변수로 제어합니다. 변수 검증(validation block)을 사용하여 잘못된 설정을 사전에 방지하고, 엔진 버전이나 인스턴스 타입의 유효성을 검사합니다. 출력값으로 엔드포인트, 포트, ARN, 보안 그룹 ID 등을 제공하여 다른 모듈과 조합 가능하게 만듭니다. 서브 모듈로 파라미터 그룹, 옵션 그룹, 서브넷 그룹을 분리하여 재사용성을 높이고, 각 서브 모듈은 독립적으로 테스트 가능하도록 구성합니다. README에 사용 예제와 변수 설명을 상세히 작성하고, Semantic Versioning으로 버전을 관리하며, Terraform Registry에 퍼블리시합니다.
- • 필수/선택 변수 구분과 보안 모범 사례를 기본값으로 강제
- • validation block으로 잘못된 설정 사전 방지
- • 명확한 출력값 정의로 다른 모듈과 조합 가능성 확보
- • 서브 모듈 분리, 상세한 문서화, Semantic Versioning
대규모 조직에서는 표준화된 모듈을 통해 일관성을 유지하고, 팀 간 중복 작업을 줄이며, 보안 정책을 강제할 수 있습니다.
모듈의 하위 호환성을 유지하면서 새로운 기능을 추가하는 전략은 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!