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

먼저 containerd-shim 프로세스 수를 확인하고(ps aux | grep containerd-shim | wc -l), 좀비 프로세스 존재 여부를 체크합니다. /proc/sys/kernel/pid_max와 현재 프로세스 수를 비교하여 PID 고갈을 확인하고, ulimit -n으로 파일 디스크립터 제한을 점검합니다. containerd 로그(/var/log/containerd/)에서 'too many open files'나 'resource temporarily unavailable' 메시지를 찾습니다. 근본 원인은 대부분 컨테이너 종료 시 shim 프로세스가 정리되지 않아 누적되는 것으로, containerd의 버그나 비정상 종료된 컨테이너의 cleanup 실패가 원인입니다. 해결책으로는 containerd 버전 업그레이드, systemd의 TasksMax 설정 증가, 정기적인 orphaned shim 프로세스 모니터링 및 정리 스크립트 구축이 필요합니다. 장기적으로는 컨테이너 라이프사이클 관리 프로세스를 개선하고, graceful shutdown을 보장하는 애플리케이션 설계가 필요합니다.

먼저 문제 컨테이너 내부에서 openssl s_client -connect API_HOST:443 -showcerts를 실행하여 실제 받는 인증서 체인을 확인합니다. 컨테이너의 /etc/ssl/certs/ 디렉토리와 호스트의 CA 인증서 저장소를 비교하여 차이를 확인하고, 특정 네트워크 브리지 설정에서 트래픽이 회사 프록시를 경유하는지 확인합니다(docker network inspect). 프록시가 중간에서 SSL을 종료하고 재암호화하는 경우, 프록시의 새 인증서가 컨테이너의 신뢰 저장소에 없어 검증 실패가 발생합니다. 해결책은 갱신된 프록시 CA 인증서를 컨테이너 이미지에 추가하거나(update-ca-certificates), 볼륨 마운트로 호스트의 인증서를 공유하는 것입니다. 장기적으로는 베이스 이미지 빌드 파이프라인에 회사 CA 인증서 자동 주입 프로세스를 구축하고, 인증서 만료 모니터링 시스템을 도입해야 합니다. 또한 네트워크 정책을 명확히 문서화하여 어떤 컨테이너가 프록시를 경유하는지 관리해야 합니다.

먼저 호스트의 파일시스템 상태를 확인하기 위해 fsck를 read-only 모드로 실행하고, Elasticsearch 데이터 디렉토리의 무결성을 체크합니다. Elasticsearch의 elasticsearch-shard tool을 사용해 손상된 샤드를 식별하고 복구 가능 여부를 판단합니다. 복구 불가능한 샤드는 클러스터의 다른 레플리카에서 재동기화하거나, 스냅샷에서 복원합니다. 근본 원인은 비정상 종료 시 write buffer가 플러시되지 않아 발생한 것으로, Elasticsearch의 translog와 파일시스템의 write-back cache 불일치가 주요 원인입니다. 예방책으로는 Docker 볼륨에 sync 마운트 옵션 적용, Elasticsearch의 index.translog.durability를 request로 설정(성능 트레이드오프 고려), 레플리카 수 증가로 데이터 이중화 강화가 필요합니다. 아키텍처 레벨에서는 분산 스토리지(Ceph, GlusterFS) 도입을 검토하고, 정기적인 스냅샷 자동화와 복구 훈련(disaster recovery drill)을 수행해야 합니다. 또한 노드 종료 시 graceful shutdown을 보장하는 orchestration 정책을 수립해야 합니다.