Docker 리드·아키텍트 트러블슈팅 면접

즉각 대응으로는 먼저 정상적으로 pull이 완료된 노드를 확인하고 docker save/load를 활용해 수동 배포하거나, 노드를 그룹으로 나눠 순차 배포로 전환합니다. Registry 로그와 메트릭을 확인해 connection limit, S3 API rate limit, 네트워크 대역폭 중 병목을 식별합니다. 중기적으로는 Registry 앞단에 CDN(CloudFront) 또는 Pull-through Cache를 배치하고, layer별 캐싱을 활용합니다. 장기적으로는 multi-region registry 복제, 이미지 크기 최적화(multi-stage build, 불필요한 layer 제거), 그리고 P2P 기반 이미지 배포 도구(Dragonfly, Kraken) 도입을 검토합니다. 배포 프로세스에는 canary 배포와 rate limiting을 적용해 동시 pull 수를 제어합니다.

1단계로 즉시 적용 가능한 runtime 보안 옵션을 추가합니다(--security-opt=no-new-privileges, --cap-drop=ALL, --read-only root filesystem with tmpfs). 2단계에서 애플리케이션이 실제 필요로 하는 capabilities를 strace와 audit 로그로 분석해 최소 권한만 --cap-add로 부여합니다. 3단계로 init container 패턴을 사용해 root로 필요한 파일 권한 설정 후 non-root user로 전환하거나, gosu/su-exec을 entrypoint에서 활용합니다. 4단계에서 user namespace remapping을 활성화해 컨테이너 내 root를 호스트의 non-privileged user로 매핑합니다. 각 단계마다 staging 환경에서 충분히 테스트하고, AppArmor/SELinux 프로파일을 적용해 추가 보안 레이어를 구성합니다. 모든 변경사항은 canary 배포로 점진 적용하며 런타임 보안 모니터링(Falco 등)을 병행합니다.

즉시 복구 시도로 호스트의 /var/lib/docker/containers 디렉토리에서 컨테이너 ID별 json 로그 파일을 확인하고, docker inspect로 이전 컨테이너 ID를 추적합니다. 로그 rotation 설정을 확인해 .1, .2 백업 파일이 남아있는지 점검하고, 호스트 레벨 syslog나 journald에 일부 로그가 남아있을 수 있습니다. 향후 아키텍처로는 먼저 로그 드라이버를 fluentd나 syslog로 변경해 컨테이너 lifecycle과 독립적으로 로그를 수집합니다. ELK, Loki 등 중앙 로깅 시스템을 구축하고, correlation ID를 HTTP 헤더로 전파해 분산 추적을 가능하게 합니다. 로그 retention 정책을 명확히 정의하고(최소 30일), max-size와 max-file 옵션으로 디스크 풀 방지와 로그 보존을 균형있게 설정합니다. OpenTelemetry를 도입해 로그, 메트릭, 트레이스를 통합 관리하는 것을 권장합니다.

depends_on은 컨테이너 시작 순서만 보장하지 서비스 준비 상태는 보장하지 않으며, healthcheck는 Compose v2에서도 완벽하지 않습니다. 근본 원인은 DB가 포트는 열었지만 초기화(schema 생성, migration)가 완료되지 않은 상태에서 앱이 연결을 시도하기 때문입니다. 해결책으로 첫째, 애플리케이션에 exponential backoff를 포함한 재시도 로직을 구현하거나 wait-for-it, dockerize 같은 wrapper 스크립트를 entrypoint에 추가합니다. 둘째, 데이터베이스 healthcheck를 단순 포트 체크가 아닌 실제 쿼리 실행(SELECT 1)으로 변경하고 interval을 적절히 설정합니다. 셋째, init container 패턴으로 DB 준비를 명시적으로 확인하는 별도 컨테이너를 먼저 실행합니다. 장기적으로는 Kubernetes의 init containers나 readiness probe 같은 더 정교한 오케스트레이션 도구 도입을 고려합니다.

먼저 문제 Pod의 /etc/resolv.conf를 확인해 nameserver 설정과 ndots, timeout 옵션을 점검합니다. tcpdump로 컨테이너 내부와 호스트에서 DNS 쿼리 패킷을 캡처해 쿼리가 CoreDNS까지 도달하는지 확인합니다. conntrack -L로 NAT 테이블을 확인해 conntrack 테이블이 가득 차서 DNS 패킷이 드롭되는지 검토합니다(sysctl net.netfilter.nf_conntrack_max 조정). 애플리케이션이 과도한 병렬 DNS 쿼리를 발생시키는지 확인하고, DNS 캐싱(dnsmasq, local DNS cache)을 컨테이너에 추가합니다. ndots 설정이 높아서(기본값 5) 불필요한 search domain 쿼리가 발생하는지 확인하고 FQDN 사용으로 변경합니다. 또한 단일 쓰레드 DNS resolver 라이브러리 사용 시 타임아웃 문제가 발생할 수 있어 애플리케이션의 DNS resolver 구현을 검토하고, 필요시 happy eyeballs(dual-stack) 지원 라이브러리로 교체합니다.

Docker는 각 레이어를 빌드할 때 명령어와 컨텍스트 파일의 체크섬으로 캐시 유효성을 판단합니다. pom.xml과 소스코드를 함께 COPY하면 소스 변경 시 의존성 레이어도 무효화됩니다. 해결책으로 먼저 pom.xml만 먼저 COPY하고 mvn dependency:go-offline을 실행한 후, 별도 레이어로 소스코드를 COPY하는 순서로 변경합니다. CI 환경에서는 --cache-from 옵션으로 이전 빌드 이미지를 캐시로 사용하거나, BuildKit의 --mount=type=cache로 Maven local repository를 영구 캐시로 마운트합니다. .dockerignore를 적절히 설정해 불필요한 파일(README, .git 등) 변경이 빌드 컨텍스트 체크섬에 영향을 주지 않도록 합니다. 또한 base image의 태그를 latest 대신 특정 버전으로 고정해 예상치 못한 캐시 무효화를 방지합니다. BuildKit의 inline cache를 활성화해 registry에 캐시 메타데이터를 함께 저장하면 CI 환경에서도 효과적입니다.

Docker Swarm은 볼륨을 자동으로 마이그레이션하지 않아 stateful 워크로드에 제한적입니다. 단기 해결책으로 placement constraints를 사용해 각 Redis 노드를 특정 호스트에 고정 배치하고, 노드 장애 시 수동 복구 프로세스를 구축합니다. 중기적으로는 로컬 볼륨 대신 네트워크 스토리지(NFS, GlusterFS) 또는 클라우드 블록 스토리지(EBS)를 사용해 볼륨이 노드 독립적이도록 변경하지만, 성능 오버헤드를 고려해야 합니다. 근본적 해결책은 Kubernetes로 마이그레이션해 StatefulSet과 PersistentVolume을 활용하는 것입니다. StatefulSet은 안정적인 네트워크 ID, 순차적 배포/스케일링, 볼륨과 Pod의 1:1 매핑을 보장합니다. 마이그레이션 전략으로는 먼저 Redis replication을 활용해 Swarm과 Kubernetes 클러스터를 동시 운영하며 점진적으로 트래픽을 이동하고, Velero 같은 도구로 데이터 백업/복원을 자동화합니다. 또는 managed Redis(ElastiCache, GCP Memorystore)로 전환해 오케스트레이션 복잡도를 제거하는 것도 고려합니다.