Docker 환경 데이터베이스 아키텍처 리드 면접

즉시 pg_basebackup을 사용해 마스터로부터 새로운 베이스 백업을 받아 슬레이브를 재구성해야 합니다. 이때 슬레이브를 읽기 전용으로 유지하려면 새 컨테이너를 띄우고 로드밸런서에서 점진적으로 전환합니다. 아키텍처 개선으로는 WAL 아카이빙을 S3 같은 외부 스토리지에 설정하고, wal_keep_segments 또는 replication slot을 적절히 구성해야 합니다. 컨테이너 환경에서는 WAL 아카이브 볼륨을 영구 볼륨으로 분리하고, 네트워크 파티션 시나리오를 고려한 모니터링과 자동 복구 메커니즘을 구축해야 합니다. Patroni 같은 HA 솔루션 도입을 검토하여 자동 페일오버와 복제 관리를 체계화하는 것이 바람직합니다.

데이터베이스 레벨에서는 SELECT FOR UPDATE를 사용한 비관적 락으로 재고 조회 시점에 행 락을 획득하거나, 격리 수준을 SERIALIZABLE로 상향 조정할 수 있습니다. 애플리케이션 레벨에서는 버전 컬럼을 추가한 낙관적 락을 구현하거나, Redis 같은 외부 분산 락을 도입할 수 있습니다. 비관적 락은 동시성이 낮아지고 데드락 위험이 있지만 데이터 정합성이 보장되며, 낙관적 락은 충돌 시 재시도 로직이 필요하지만 성능이 우수합니다. 마이크로서비스 환경에서는 Saga 패턴이나 이벤트 소싱을 고려하여 각 서비스의 로컬 트랜잭션과 보상 트랜잭션으로 최종 일관성을 보장하는 것이 확장성 측면에서 유리합니다. 컨테이너 환경에서는 재시작과 스케일링 시나리오를 고려한 락 타임아웃과 모니터링이 필수입니다.

먼저 복합 인덱스의 컬럼 순서를 쿼리 패턴에 맞게 재조정해야 하며, 일반적으로 등호 조건(user_id)을 범위 조건(timestamp)보다 앞에 배치합니다. 시계열 데이터 특성상 TTL 인덱스를 설정하여 오래된 데이터를 자동 삭제하고, 최근 데이터만 hot storage에 유지해야 합니다. 샤딩 키를 timestamp 기반에서 user_id 또는 복합키로 변경하여 쿼리가 특정 샤드로 라우팅되도록 최적화합니다. 컨테이너 환경에서는 메모리 제약이 크므로 인덱스를 최소화하고, 부분 인덱스나 sparse 인덱스를 활용하여 인덱스 크기를 줄여야 합니다. 오래된 데이터는 별도의 아카이브 컬렉션이나 외부 스토리지로 이관하는 파티셔닝 전략을 수립하고, 각 샤드 컨테이너의 리소스를 모니터링하여 동적으로 조정하는 자동화를 구축해야 합니다.

각 애플리케이션의 연결 풀 크기를 줄이는 것이 우선이며, 일반적으로 Pod당 5-10개 연결이면 충분합니다. 총 연결 수는 '애플리케이션 인스턴스 수 × 연결 풀 크기'이므로 전체 설계를 재검토해야 합니다. PgBouncer 같은 연결 풀러를 중간에 배치하여 connection pooling과 transaction pooling을 활용하면, 수천 개의 클라이언트 연결을 수십 개의 데이터베이스 연결로 변환할 수 있습니다. PgBouncer를 사이드카 패턴으로 각 Pod에 배치하거나, 별도의 서비스로 중앙화할 수 있으며, 각 방식의 레이턴시와 관리 복잡도 트레이드오프를 고려해야 합니다. 데이터베이스의 max_connections는 실제 동시 쿼리 수에 맞게 설정하고, 연결 타임아웃과 idle connection 정리 정책을 적절히 구성하여 리소스 낭비를 방지합니다.

먼저 EXPLAIN ANALYZE로 실행 계획을 상세히 분석하여 가장 비용이 높은 부분을 식별합니다. WHERE 절의 필터 조건에 대한 복합 인덱스를 추가하되, 선택도가 높은 컬럼을 우선 배치하고, JOIN 키에도 인덱스가 있는지 확인합니다. Using temporary는 GROUP BY나 DISTINCT에서 발생하므로, 인덱스로 정렬 순서를 맞추거나 쿼리를 분리하여 애플리케이션 레벨에서 집계하는 방안을 검토합니다. JOIN 순서를 최적화하고, 필요하다면 STRAIGHT_JOIN으로 조인 순서를 명시적으로 제어합니다. 성능이 여전히 부족하면 자주 조회되는 집계 데이터를 materialized view나 별도 요약 테이블로 비정규화하여 사전 계산합니다. 컨테이너 환경에서는 tmp_table_size와 sort_buffer_size 같은 메모리 설정을 조정하되, 전체 메모리 제약을 고려해야 하며, 최종적으로는 읽기 전용 복제본으로 대시보드 쿼리를 분리하는 것이 바람직합니다.

별도의 복구용 컨테이너를 띄워 베이스 백업과 WAL을 사용해 PITR을 수행하고, recovery_target_time을 손상 직전 시점으로 설정합니다. 복구된 인스턴스에서 데이터를 검증한 후, 손상된 테이블만 덤프하여 프로덕션 데이터베이스에 선택적으로 복원하거나, 짧은 점검 시간 동안 마스터를 교체하는 방식을 선택합니다. 서비스 중단을 최소화하려면 읽기 복제본을 활용하여 쓰기만 잠시 중단하거나, 애플리케이션 레벨에서 임시로 읽기 전용 모드로 전환합니다. 아키텍처 개선으로는 지속적 WAL 아카이빙과 함께 논리적 복제(logical replication)를 구성하여 테이블 단위 복구를 가능하게 하고, pgBackRest 같은 도구로 증분 백업과 병렬 복구를 활성화해야 합니다. 컨테이너 환경에서는 백업 볼륨을 영구 스토리지에 분리하고, 정기적인 복구 테스트를 자동화하여 RTO/RPO 목표를 검증해야 합니다.

먼저 신규 컨테이너 환경에 목표 스키마의 데이터베이스를 구축하고, Debezium 같은 CDC 도구로 레거시 데이터베이스의 변경사항을 실시간으로 복제합니다. 초기 데이터는 스냅샷으로 마이그레이션하고, 스키마 변경이 필요한 부분은 ETL 파이프라인을 통해 변환합니다. 애플리케이션에서는 이중 쓰기 패턴을 구현하여 레거시와 신규 데이터베이스 모두에 쓰기를 수행하되, 읽기는 먼저 레거시에서만 수행합니다. 데이터 정합성을 주기적으로 검증한 후, 카나리 배포로 일부 트래픽의 읽기를 신규 데이터베이스로 전환하고, 점진적으로 비율을 높입니다. 파티셔닝은 마이그레이션 완료 후 별도 작업으로 진행하여 복잡도를 분리합니다. 각 단계마다 롤백 포인트를 설정하고, 문제 발생 시 즉시 레거시로 복귀할 수 있도록 feature flag와 라우팅 설정을 준비합니다. 컨테이너 환경에서는 블루-그린 배포 패턴을 활용하여 전체 스택을 순간 전환할 수 있도록 구성하고, 마이그레이션 진행 상황을 모니터링하는 대시보드를 구축해야 합니다.