Docker 미드레벨 기술면접
새 면접Q. Docker 컨테이너가 시작될 때 PID 1 프로세스의 역할과 중요성을 설명하고, 좀비 프로세스(zombie process)가 발생하는 원인과 이를 방지하기 위한 init 시스템(tini, dumb-init) 사용 전략을 설명해주세요.
PID 1 프로세스는 컨테이너 내에서 init 프로세스 역할을 하며, 자식 프로세스의 종료 시그널을 수신하고 좀비 프로세스를 정리(reaping)하는 책임을 갖습니다. 일반 애플리케이션이 PID 1로 실행되면 SIGTERM 신호를 제대로 처리하지 못하거나 좀비 프로세스가 누적될 수 있습니다. tini나 dumb-init 같은 경량 init 시스템을 ENTRYPOINT로 사용하면 신호 전달과 프로세스 정리를 올바르게 처리할 수 있습니다. Dockerfile에서 'tini -- your-app' 형태로 사용하거나 Docker의 --init 플래그를 활용할 수 있습니다.
- • PID 1은 컨테이너 내 init 프로세스로 신호 처리와 자식 프로세스 관리 담당
- • 좀비 프로세스는 부모 프로세스가 wait() 호출 없이 종료될 때 발생
- • tini, dumb-init 같은 경량 init 시스템으로 프로세스 reaping 처리
- • docker run --init 플래그로 자동으로 tini 주입 가능
shell form(CMD node app.js)과 exec form(CMD ["node", "app.js"])에서 PID 1 프로세스가 어떻게 다르게 동작하며, 각각의 경우 SIGTERM 신호 처리에 어떤 차이가 있는지 설명해주세요.
Q. Docker 이미지를 레지스트리에 push/pull할 때 사용되는 layer compression 방식과 전송 최적화 메커니즘을 설명하고, 대용량 이미지의 배포 시간을 단축하기 위한 layer 병렬 다운로드, delta sync, image streaming 기술의 동작 원리와 적용 방법을 제시해주세요.
Docker 이미지 레이어는 gzip 압축되어 레지스트리에 저장되며, push/pull 시 각 레이어는 독립적으로 병렬 전송됩니다. Docker는 레이어의 digest(SHA256 해시)를 기반으로 이미 존재하는 레이어는 재전송하지 않는 delta sync를 수행합니다. containerd의 lazy pulling 기능을 활용하면 필요한 레이어만 선택적으로 다운로드하는 image streaming이 가능해 컨테이너 시작 시간을 크게 단축할 수 있습니다. 레이어 크기를 최소화하고, 자주 변경되는 레이어를 상위에 배치하며, 레지스트리에 CDN을 적용하는 것이 효과적입니다.
- • 레이어는 gzip 압축되어 저장되고 digest 기반으로 중복 제거
- • 병렬 레이어 다운로드로 전송 시간 단축
- • 이미 존재하는 레이어는 재전송하지 않는 delta sync 수행
- • containerd lazy pulling으로 필요한 레이어만 선택적 다운로드
- • 레지스트리 미러링과 CDN 적용으로 네트워크 지연 최소화
Google의 Stargz(Seekable tar.gz)나 eStargz 같은 새로운 이미지 포맷이 기존 OCI 이미지 포맷과 어떻게 다르며, 컨테이너 cold start 성능 개선에 어떻게 기여하는지 설명해주세요.
Q. Docker에서 제공하는 seccomp, AppArmor, SELinux 보안 프로파일의 역할과 차이점을 설명하고, 각각이 시스템 콜 필터링, 파일 시스템 접근 제어, 네트워크 격리에서 어떻게 작동하는지 비교해주세요. 또한 프로덕션 환경에서 custom seccomp 프로파일을 작성해야 하는 상황과 방법을 설명해주세요.
seccomp은 시스템 콜 레벨에서 컨테이너가 사용할 수 있는 커널 기능을 제한하는 필터로, Docker의 기본 프로파일은 300개 이상의 시스템 콜 중 위험한 것들을 차단합니다. AppArmor와 SELinux는 MAC(Mandatory Access Control) 시스템으로 파일, 네트워크, 프로세스 간 접근을 제어하며, AppArmor는 경로 기반, SELinux는 레이블 기반으로 동작합니다. custom seccomp 프로파일은 strace로 애플리케이션의 시스템 콜을 분석한 후 필요한 콜만 허용하는 JSON 파일로 작성하며, --security-opt seccomp=profile.json으로 적용합니다. 이를 통해 공격 표면을 최소화하고 제로데이 취약점 위험을 줄일 수 있습니다.
- • seccomp은 시스템 콜 필터링, AppArmor/SELinux는 MAC 기반 접근 제어
- • AppArmor는 경로 기반, SELinux는 레이블 기반 보안 정책
- • strace로 필요한 시스템 콜 분석 후 custom seccomp 프로파일 작성
- • 기본 프로파일보다 엄격한 제한으로 공격 표면 최소화
- • Capabilities와 함께 사용하여 다층 보안 구현
컨테이너에서 privileged 모드와 특정 capabilities만 추가하는 방식의 보안 차이를 설명하고, CAP_NET_ADMIN, CAP_SYS_ADMIN 같은 주요 capabilities의 위험성과 대안을 제시해주세요.
Q. Docker 컨테이너의 실시간 리소스 사용량을 모니터링하고 성능 병목을 식별하는 방법을 설명하고, docker stats, cAdvisor, Prometheus + Grafana를 활용한 모니터링 스택 구성 시 각 도구의 역할과 메트릭 수집 아키텍처를 설명해주세요.
docker stats는 컨테이너의 CPU, 메모리, 네트워크, 블록 I/O를 실시간으로 보여주는 기본 도구로 간단한 모니터링에 적합합니다. cAdvisor는 Google이 개발한 컨테이너 메트릭 수집 도구로 더 상세한 메트릭과 히스토리 데이터를 제공하며, Prometheus의 exporter 역할을 합니다. Prometheus는 cAdvisor나 node-exporter에서 메트릭을 scraping하여 시계열 DB에 저장하고, Grafana는 이를 시각화하여 대시보드를 제공합니다. 이 조합으로 컨테이너별 리소스 사용 추이, 임계값 알림, 용량 계획을 수립할 수 있습니다.
- • docker stats는 실시간 기본 메트릭 제공, 간단한 모니터링용
- • cAdvisor는 상세한 컨테이너 메트릭 수집 및 Prometheus exporter 역할
- • Prometheus는 시계열 메트릭 저장 및 쿼리, 알림 규칙 관리
- • Grafana는 메트릭 시각화 및 대시보드 제공
- • PromQL로 복잡한 메트릭 분석 및 이상 탐지 가능
컨테이너의 메모리 사용량에서 cache와 RSS의 차이를 설명하고, OOM이 발생하기 전에 메모리 압박 상황을 감지하고 대응하는 방법을 제시해주세요.
Q. Docker Compose에서 여러 마이크로서비스를 orchestration할 때 서비스 간 의존성 관리, 롤링 업데이트 전략, 그리고 blue-green 배포를 구현하는 방법을 설명하고, 각 서비스의 버전 관리와 롤백 전략을 제시해주세요.
Docker Compose에서는 depends_on과 healthcheck를 조합하여 서비스 시작 순서를 제어하지만, 실제 준비 상태는 헬스체크로 확인해야 합니다. 롤링 업데이트는 docker-compose up -d --no-deps --scale service=3 형태로 구현하거나, deploy 섹션의 update_config로 병렬성과 지연 시간을 설정할 수 있습니다. blue-green 배포는 두 개의 별도 Compose 파일(docker-compose.blue.yml, docker-compose.green.yml)을 사용하거나, 같은 파일 내에서 서비스 이름을 다르게 하여 구현합니다. 버전은 이미지 태그로 관리하고, 이전 버전의 컨테이너를 유지한 채 트래픽을 전환한 후 검증 완료 시 이전 버전을 제거합니다.
- • depends_on + healthcheck로 서비스 시작 순서 및 준비 상태 관리
- • update_config로 롤링 업데이트 병렬성 및 지연 시간 제어
- • blue-green 배포는 별도 Compose 파일 또는 서비스 이름 분리로 구현
- • 이미지 태그로 버전 관리, 이전 버전 유지하며 트래픽 전환
- • nginx나 Traefik 같은 프록시로 트래픽 라우팅 제어
Docker Compose의 한계로 인해 프로덕션 환경에서 Kubernetes로 전환해야 하는 시점을 판단하는 기준과, Compose 파일을 Kubernetes manifest로 변환하는 도구(kompose)의 사용 방법을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!