Docker 미드레벨 배포·운영 기술면접
새 면접Q. Docker 컨테이너를 사용하는 웹 애플리케이션에서 무중단 배포를 구현할 때, 새 버전 컨테이너가 준비되기 전에 기존 컨테이너를 종료하면 서비스 중단이 발생합니다. 이를 방지하기 위한 그레이스풀 셧다운(graceful shutdown) 전략을 설명하고, SIGTERM 시그널 처리와 헬스체크를 활용한 무중단 배포 프로세스를 단계별로 제시해주세요.
컨테이너 종료 시 시그널 전달 순서와 애플리케이션의 연결 드레이닝(connection draining) 처리를 고려하세요.
무중단 배포를 위해서는 먼저 새 버전 컨테이너를 시작하고 헬스체크가 통과할 때까지 대기합니다. 로드밸런서가 새 컨테이너로 트래픽을 라우팅하기 시작하면, 기존 컨테이너에 SIGTERM 시그널을 보내 새로운 요청 수락을 중지하고 진행 중인 요청이 완료될 때까지 대기합니다. 애플리케이션은 SIGTERM 핸들러에서 연결 드레이닝 로직을 구현하여 활성 연결을 우아하게 종료해야 합니다. docker stop의 --time 옵션으로 SIGKILL 전송 전 대기 시간을 충분히 설정하고, 이 시간 내에 모든 요청 처리가 완료되도록 해야 합니다. 이 과정에서 헬스체크 엔드포인트는 셧다운 시작 시 unhealthy를 반환하여 로드밸런서가 즉시 트래픽을 차단하도록 해야 합니다.
- • 새 컨테이너 시작 후 헬스체크 통과 확인
- • SIGTERM 시그널 처리로 연결 드레이닝 구현
- • 충분한 그레이스 기간 설정으로 진행 중인 요청 완료 보장
- • 헬스체크를 통한 로드밸런서 트래픽 제어
프로덕션 환경에서 배포 시 사용자 요청이 중단되지 않도록 보장하는 핵심 메커니즘입니다.
애플리케이션이 SIGTERM 시그널을 제대로 처리하지 않고 있는지 확인하는 방법과, 이를 개선하기 위한 코드 레벨 구현 방법을 설명해주세요.
Q. Jenkins 또는 GitLab CI를 사용하여 Docker 이미지 빌드 파이프라인을 구성할 때, 빌드 속도를 최적화하기 위한 전략을 설명해주세요. 특히 Docker layer 캐싱, BuildKit의 인라인 캐시, 멀티 스테이지 빌드 캐싱, 그리고 레지스트리 기반 캐시 공유 방법을 포함하여 CI 환경에서 효율적인 캐시 활용 방안을 제시해주세요.
CI 환경에서는 매번 클린 빌드 환경이 생성되므로, 빌드 간 캐시를 공유하기 위한 외부 저장소 활용이 필요합니다.
CI 환경에서는 빌드 에이전트가 일시적이므로 로컬 캐시를 재사용할 수 없어 레지스트리 기반 캐시 전략이 필요합니다. BuildKit의 --cache-from과 --cache-to 옵션을 사용하여 이전 빌드의 레이어를 레지스트리에서 가져오고, 새 빌드 결과를 다시 레지스트리에 인라인 캐시로 저장합니다. 멀티 스테이지 빌드에서는 각 스테이지별로 캐시 이미지를 별도로 관리하여 의존성 설치 단계와 소스 빌드 단계의 캐시를 독립적으로 활용할 수 있습니다. docker buildx build --cache-from type=registry,ref=myregistry/myapp:cache --cache-to type=inline 형태로 사용하며, 파이프라인에서 이전 빌드의 캐시 이미지를 pull하는 단계를 추가합니다. 또한 의존성 파일(package.json, requirements.txt 등)을 먼저 복사하여 해당 레이어의 캐시 히트율을 극대화하고, 병렬 빌드가 가능한 경우 docker buildx의 멀티 플랫폼 빌드 기능을 활용합니다.
- • 레지스트리 기반 캐시로 빌드 간 캐시 공유
- • BuildKit의 inline cache와 registry cache 활용
- • 멀티 스테이지 빌드의 각 스테이지별 캐시 관리
- • 의존성 레이어 분리로 캐시 히트율 극대화
대규모 마이크로서비스 환경에서 수십 개의 서비스를 빌드할 때 빌드 시간을 수십 분에서 수 분으로 단축할 수 있습니다.
Docker 빌드 캐시가 무효화되는 조건을 정확히 설명하고, Dockerfile 작성 시 캐시 효율을 높이기 위한 레이어 순서 최적화 원칙을 제시해주세요.
Q. 프로덕션 환경에서 새로운 Docker 이미지 버전을 배포한 후 문제가 발견되어 긴급 롤백이 필요한 상황입니다. 이미지 태깅 전략, 배포 이력 관리, 그리고 빠른 롤백을 위한 준비 사항을 설명하고, 롤백 실행 시 데이터 마이그레이션이나 스키마 변경이 있었던 경우의 처리 방법을 제시해주세요.
이미지 버전 관리와 데이터베이스 스키마 변경의 호환성을 함께 고려해야 합니다.
빠른 롤백을 위해서는 시맨틱 버저닝과 함께 git commit SHA를 이미지 태그에 포함하고, latest 태그 의존을 피해야 합니다. 배포 시마다 이전 버전 이미지를 삭제하지 않고 보존하며, 배포 이력을 메타데이터로 관리하여 언제든 특정 버전으로 돌아갈 수 있게 합니다. 롤백은 docker service update --image myapp:v1.2.3 또는 Kubernetes의 kubectl rollout undo 명령으로 수행하며, 이전 버전 이미지가 이미 레지스트리에 있어 즉시 배포 가능합니다. 데이터베이스 스키마 변경이 있는 경우 forward-compatible migration 전략을 사용하여 새 버전과 구 버전이 모두 동작 가능한 스키마를 유지하고, 배포 완료 후 일정 기간 경과 후 최종 정리 마이그레이션을 수행합니다. 롤백 시에는 애플리케이션만 이전 버전으로 되돌리고 스키마는 유지하거나, 별도의 down migration 스크립트를 준비하여 필요시 실행합니다.
- • 시맨틱 버저닝과 commit SHA 기반 이미지 태깅
- • 이전 버전 이미지 보존 및 배포 이력 관리
- • forward-compatible 스키마 마이그레이션 전략
- • 애플리케이션과 데이터베이스 롤백 분리
프로덕션 장애 발생 시 서비스를 빠르게 안정 상태로 복구하는 핵심 운영 프로세스입니다.
카나리 배포와 블루-그린 배포에서 각각 롤백을 수행하는 방법과 장단점을 비교 설명해주세요.
Q. Docker Swarm 모드에서 서비스를 배포할 때 rolling update 전략의 파라미터(update-parallelism, update-delay, update-failure-action)가 배포 프로세스에 미치는 영향을 설명하고, 대규모 트래픽을 처리하는 서비스에서 안전한 롤링 업데이트를 위한 최적의 파라미터 설정 방법을 제시해주세요.
동시 업데이트 수, 업데이트 간격, 실패 처리 정책이 서비스 가용성과 배포 속도에 어떤 영향을 주는지 생각해보세요.
update-parallelism은 동시에 업데이트할 컨테이너 수를 지정하며, 값이 클수록 배포 속도는 빠르지만 문제 발생 시 영향 범위가 넓어집니다. update-delay는 각 배치 업데이트 사이의 대기 시간으로, 새 버전의 안정성을 확인할 시간을 제공하며 헬스체크와 연계하여 설정해야 합니다. update-failure-action은 업데이트 실패 시 pause(일시 중지), continue(계속), rollback(자동 롤백) 중 선택하며, 프로덕션에서는 rollback으로 설정하여 자동 복구를 활성화합니다. 대규모 서비스에서는 전체 레플리카의 10-20% 정도를 parallelism으로 설정하고, delay는 헬스체크 주기의 2-3배로 설정하여 충분한 검증 시간을 확보합니다. 또한 update-monitor 옵션으로 각 태스크의 안정성을 모니터링하는 기간을 설정하고, max-failure-ratio를 통해 허용 가능한 실패 비율을 정의하여 자동 롤백 트리거를 세밀하게 제어할 수 있습니다.
- • parallelism으로 배포 속도와 위험 범위 조절
- • delay로 새 버전 안정성 검증 시간 확보
- • failure-action으로 자동 롤백 활성화
- • monitor와 failure-ratio로 세밀한 배포 제어
수백 개의 컨테이너 인스턴스를 운영하는 환경에서 안전하고 효율적인 배포를 자동화하는 데 필수적입니다.
Kubernetes의 Deployment 롤링 업데이트 전략(maxSurge, maxUnavailable)과 Docker Swarm의 방식을 비교하고, 각각의 장단점을 설명해주세요.
Q. Docker 컨테이너 환경에서 애플리케이션 로그와 시스템 메트릭을 효과적으로 수집하기 위한 로깅 드라이버 선택 전략을 설명하고, json-file, syslog, fluentd, gelf 드라이버의 특징과 사용 사례를 비교해주세요. 또한 로그 볼륨이 큰 환경에서 디스크 공간 관리를 위한 로그 로테이션 설정 방법을 제시해주세요.
각 로깅 드라이버의 성능, 중앙 집중화 가능성, 로그 손실 위험을 고려해야 합니다.
json-file은 Docker의 기본 드라이버로 로컬 파일 시스템에 JSON 형식으로 저장하며, docker logs 명령어로 조회 가능하지만 중앙 집중화가 어렵습니다. syslog는 시스템 로그 서버로 전송하여 중앙 관리가 가능하지만 구조화된 로그 처리가 제한적입니다. fluentd는 다양한 출력 플러그인을 지원하여 Elasticsearch, S3 등으로 유연하게 전송할 수 있으며, 로그 파싱과 필터링 기능이 강력합니다. gelf는 Graylog Extended Log Format으로 구조화된 로그를 Graylog나 Logstash로 전송하는 데 최적화되어 있습니다. 프로덕션 환경에서는 fluentd나 gelf를 사용하여 중앙 로그 시스템으로 전송하되, max-size와 max-file 옵션으로 로컬 로그 로테이션을 설정하여 디스크 공간을 보호해야 합니다. 예를 들어 --log-opt max-size=10m --log-opt max-file=3으로 설정하여 최대 30MB까지만 로컬에 보관합니다.
- • json-file은 간단하지만 중앙 집중화 어려움
- • fluentd는 유연한 로그 파이프라인 구성 가능
- • max-size와 max-file로 로그 로테이션 설정
- • 프로덕션에서는 중앙 로그 시스템 연동 필수
마이크로서비스 환경에서 수십 개의 서비스 로그를 통합 관리하고 장애 추적을 효율화하는 데 필수적입니다.
컨테이너가 예기치 않게 종료되었을 때 로그를 보존하고 분석하기 위한 전략과, stdout/stderr 외에 파일로 기록되는 로그를 수집하는 방법을 설명해주세요.
Q. GitOps 방식으로 Docker 컨테이너 배포를 자동화할 때, 이미지 빌드 파이프라인과 배포 파이프라인을 분리하는 이유와 방법을 설명하고, ArgoCD나 Flux 같은 도구를 사용한 선언적 배포 전략의 장점을 제시해주세요.
소스 코드 변경과 배포 설정 변경을 독립적으로 관리하는 것의 이점을 생각해보세요.
GitOps에서는 애플리케이션 소스 코드 저장소와 배포 매니페스트 저장소를 분리하여, 빌드 파이프라인은 소스 코드를 이미지로 빌드하고 레지스트리에 푸시하며, 배포 파이프라인은 매니페스트 저장소의 변경을 감지하여 클러스터에 적용합니다. 빌드 파이프라인이 완료되면 새 이미지 태그로 매니페스트 저장소의 deployment.yaml을 업데이트하고, ArgoCD가 이 변경을 감지하여 자동으로 배포를 수행합니다. 이 방식은 배포 상태가 Git에 버전 관리되어 감사 추적이 가능하고, 선언적 방식으로 원하는 상태를 정의하면 도구가 자동으로 현재 상태를 맞춰주므로 일관성이 보장됩니다. 또한 배포 실패 시 Git 히스토리를 통해 쉽게 롤백할 수 있고, Pull Request 기반 배포 승인 프로세스를 구축할 수 있습니다. 멀티 클러스터 환경에서도 단일 매니페스트 저장소로 모든 환경을 관리할 수 있어 운영 복잡도가 감소합니다.
- • 빌드와 배포 파이프라인 분리로 관심사 분리
- • Git을 단일 진실 공급원으로 사용
- • 선언적 방식으로 배포 상태 일관성 보장
- • 버전 관리와 감사 추적 자동화
복잡한 마이크로서비스 환경에서 배포 프로세스를 표준화하고 자동화하여 인적 오류를 줄이는 데 효과적입니다.
전통적인 Push 방식 배포와 GitOps의 Pull 방식 배포의 보안 측면에서의 차이점과 장점을 설명해주세요.
Q. 카나리 배포(Canary Deployment)를 Docker 환경에서 구현할 때, 트래픽을 점진적으로 새 버전으로 전환하는 전략을 설명하고, 메트릭 기반 자동 프로모션과 롤백 결정을 위한 판단 기준을 제시해주세요. 또한 A/B 테스트와 카나리 배포의 차이점을 설명해주세요.
트래픽 비율 조정, 성공 메트릭 정의, 자동화된 의사결정 프로세스를 고려하세요.
카나리 배포는 새 버전을 전체 사용자의 일부(예: 5%)에게만 먼저 배포하고, 에러율, 응답 시간, 비즈니스 메트릭을 모니터링하여 문제가 없으면 점진적으로 트래픽 비율을 증가시킵니다. Docker Swarm에서는 서비스 레플리카 비율을 조정하거나, Kubernetes에서는 Ingress 가중치를 조절하여 구현합니다. 자동 프로모션을 위해서는 에러율 임계값(예: 0.5% 이하), p95 응답 시간(예: 200ms 이하), 비즈니스 전환율 등을 성공 기준으로 정의하고, Prometheus와 Grafana로 모니터링합니다. 설정된 관찰 기간(예: 30분) 동안 모든 메트릭이 기준을 충족하면 자동으로 다음 단계(10%, 25%, 50%, 100%)로 진행하고, 하나라도 실패하면 즉시 롤백합니다. A/B 테스트는 기능 차이를 비교하기 위해 장기간 병렬 운영하는 반면, 카나리 배포는 새 버전의 안정성 검증을 위해 단기간 점진적 전환을 목적으로 합니다.
- • 트래픽을 점진적으로 새 버전으로 전환
- • 에러율, 응답 시간 등 메트릭 기반 자동 판단
- • 관찰 기간 동안 성공 기준 충족 시 프로모션
- • A/B 테스트와 목적 및 기간에서 차이
대규모 사용자 서비스에서 새 버전 배포의 위험을 최소화하고, 문제 발생 시 영향 범위를 제한하는 데 사용됩니다.
카나리 배포 중 새 버전에서만 발생하는 버그를 사용자가 보고했을 때, 해당 사용자를 식별하고 문제를 재현하기 위한 방법을 설명해주세요.
Q. Docker 이미지 레지스트리에서 이미지 저장 공간이 급격히 증가하여 비용 문제가 발생했습니다. 사용하지 않는 이미지와 레이어를 정리하기 위한 가비지 컬렉션 전략을 설명하고, 이미지 보존 정책(retention policy)을 설정할 때 고려해야 할 요소들을 제시해주세요.
태그되지 않은 이미지, dangling 레이어, 오래된 버전 이미지의 관리 전략을 생각해보세요.
레지스트리 가비지 컬렉션은 먼저 태그가 없는 매니페스트와 참조되지 않는 레이어 blob을 식별하여 삭제합니다. Harbor나 ECR 같은 레지스트리는 보존 정책을 지원하여 최근 N개 태그만 유지하거나, 특정 기간 이상 경과한 이미지를 자동 삭제할 수 있습니다. 정책 설정 시 프로덕션 이미지는 최소 3-6개월 보존하고, 개발/테스트 이미지는 2-4주로 짧게 설정하며, latest와 시맨틱 버전 태그는 영구 보존합니다. 삭제 전에는 현재 실행 중인 컨테이너가 사용하는 이미지를 확인하여 실수로 삭제하지 않도록 하고, 롤백 가능성을 고려하여 최근 3-5개 버전은 보존합니다. 또한 멀티 스테이지 빌드의 중간 레이어나 빌드 캐시 이미지는 별도 정책으로 관리하고, 정기적인 가비지 컬렉션 스케줄을 설정하여 자동화합니다.
- • 태그 없는 이미지와 dangling 레이어 정리
- • 환경별 차별화된 보존 정책 설정
- • 현재 사용 중인 이미지 보호
- • 정기적 가비지 컬렉션 자동화
CI/CD로 하루에 수백 개의 이미지가 생성되는 환경에서 레지스트리 스토리지 비용을 관리하는 데 필수적입니다.
Docker 레지스트리에서 이미지 삭제 후에도 실제 디스크 공간이 회수되지 않는 이유와, 공간을 실제로 확보하기 위한 추가 작업을 설명해주세요.
Q. Docker 컨테이너의 리소스 사용 패턴을 분석하여 적절한 CPU와 메모리 제한(limits)을 설정하고자 합니다. 과도한 제한으로 인한 성능 저하와 제한 부족으로 인한 노이지 네이버(noisy neighbor) 문제를 모두 방지하기 위한 리소스 프로파일링 방법과 최적 값 산정 전략을 제시해주세요.
실제 사용량 모니터링 데이터를 기반으로 피크 시간대와 평균 사용량을 분석해야 합니다.
리소스 프로파일링은 최소 1-2주간 프로덕션 환경에서 docker stats나 cAdvisor로 실시간 메트릭을 수집하고, Prometheus로 저장하여 시계열 분석을 수행합니다. CPU는 평균 사용량의 1.5-2배, 메모리는 p95 사용량의 1.2-1.5배를 limits로 설정하여 피크 시간대를 처리할 여유를 확보합니다. requests는 평균 사용량으로 설정하여 스케줄러가 적절한 노드를 선택하도록 하고, limits와 requests 사이의 버스터블(burstable) 영역을 활용합니다. CPU throttling 메트릭을 모니터링하여 throttled time이 5% 이상이면 limits를 상향 조정하고, 메모리 OOM Kill 이벤트 발생 시 즉시 분석하여 메모리 누수인지 정상 피크인지 판단합니다. 애플리케이션 특성에 따라 CPU-bound 작업은 CPU limits를 높게, 메모리-intensive 작업은 메모리 limits를 높게 설정하며, 지속적으로 메트릭을 리뷰하여 조정합니다.
- • 1-2주간 실제 사용량 데이터 수집 및 분석
- • 평균과 피크 사용량 기반 limits 산정
- • throttling과 OOM 메트릭 모니터링
- • 애플리케이션 특성에 맞는 차별화된 설정
멀티테넌트 환경에서 컨테이너 간 리소스 경합을 방지하고 안정적인 성능을 보장하는 데 필수적입니다.
Kubernetes 환경에서 QoS 클래스(Guaranteed, Burstable, BestEffort)가 리소스 제한 설정에 따라 어떻게 결정되는지 설명하고, 각 클래스의 스케줄링 및 eviction 우선순위를 설명해주세요.
Q. Docker 이미지에 취약점이 발견되었을 때, 영향받는 모든 환경(개발, 스테이징, 프로덕션)에서 신속하게 패치된 이미지로 교체하기 위한 자동화 프로세스를 설계해주세요. 이미지 스캐닝, 알림, 자동 재빌드, 배포 승인 워크플로우를 포함하여 설명해주세요.
취약점 발견부터 패치 배포까지의 전체 프로세스와 각 단계의 자동화 가능 여부를 고려하세요.
이미지 취약점 관리 프로세스는 먼저 Trivy나 Clair 같은 스캐너를 CI 파이프라인과 레지스트리에 통합하여 빌드 시와 정기적으로 스캔을 수행합니다. 심각도가 높은 취약점(Critical, High)이 발견되면 Slack이나 PagerDuty로 즉시 알림을 보내고, JIRA 티켓을 자동 생성합니다. 베이스 이미지 취약점인 경우 최신 패치 버전으로 Dockerfile을 업데이트하고 자동으로 재빌드를 트리거하며, 애플리케이션 의존성 취약점은 package.json이나 requirements.txt를 업데이트합니다. 재빌드된 이미지는 자동화된 테스트 스위트를 통과해야 하며, 개발 환경에는 자동 배포하고 스테이징에는 승인 후 배포, 프로덕션은 변경 관리 프로세스를 거칩니다. 배포 후에는 모니터링 대시보드에서 에러율과 성능을 확인하고, 문제 없으면 다음 환경으로 프로모션합니다. 전체 프로세스를 GitOps로 관리하여 모든 변경 이력을 추적 가능하게 합니다.
- • CI/CD와 레지스트리에 이미지 스캐너 통합
- • 심각도 기반 자동 알림 및 티켓 생성
- • 자동 재빌드와 테스트 수행
- • 환경별 차등화된 배포 승인 프로세스
보안 컴플라이언스 요구사항을 충족하면서도 빠른 패치 적용으로 공격 표면을 최소화하는 데 중요합니다.
이미지 스캔 결과에서 false positive를 처리하는 방법과, 특정 취약점을 예외 처리(whitelist)해야 할 때의 정책 관리 방법을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!