Docker 미드레벨 CS 기초 기술면접
새 면접Q. Docker 컨테이너에서 localhost:8080으로 바인딩된 애플리케이션이 호스트에서는 접근 가능하지만 다른 컨테이너에서 접근할 수 없는 이유를 네트워크 네임스페이스와 루프백 인터페이스 관점에서 설명하고, 컨테이너 간 통신을 위해 0.0.0.0으로 바인딩해야 하는 이유를 설명해주세요.
각 컨테이너는 독립적인 네트워크 네임스페이스를 가지며, localhost(127.0.0.1)는 해당 네임스페이스 내부의 루프백 인터페이스만을 가리킵니다. 컨테이너 A에서 localhost는 컨테이너 A의 네트워크 스택만 참조하므로 다른 컨테이너에서는 접근할 수 없습니다. 0.0.0.0으로 바인딩하면 모든 네트워크 인터페이스에서 수신 대기하게 되어 브릿지 네트워크를 통한 컨테이너 IP로 접근이 가능해집니다. 호스트에서 localhost로 접근 가능한 것은 포트 포워딩(-p 옵션)을 통해 호스트의 네트워크 네임스페이스에서 컨테이너로 트래픽이 전달되기 때문입니다.
- • 각 컨테이너는 독립적인 네트워크 네임스페이스를 가지며 localhost는 해당 네임스페이스 내부만 참조
- • 0.0.0.0 바인딩은 모든 네트워크 인터페이스에서 수신 대기하여 브릿지 네트워크를 통한 접근 허용
- • 포트 포워딩은 호스트 네임스페이스에서 컨테이너 네임스페이스로 트래픽을 NAT를 통해 전달
Docker의 container 네트워크 모드를 사용하여 두 컨테이너가 동일한 네트워크 네임스페이스를 공유할 때의 동작 방식과 사용 사례를 설명해주세요.
Q. Docker 컨테이너 내부에서 fork() 시스템 콜을 통해 자식 프로세스를 생성하는 멀티 프로세스 애플리케이션을 실행할 때, 호스트 시스템의 PID와 컨테이너 내부의 PID가 어떻게 매핑되는지 설명하고, PID 네임스페이스 계층 구조에서 프로세스 시그널 전달 메커니즘과 제약사항을 설명해주세요.
PID 네임스페이스는 계층적 구조를 가지며, 컨테이너 내부의 PID 1은 호스트에서는 다른 PID로 매핑됩니다. 호스트는 모든 하위 네임스페이스의 프로세스를 볼 수 있지만, 컨테이너는 자신의 네임스페이스 내부 프로세스만 볼 수 있습니다. 시그널은 상위 네임스페이스에서 하위로는 전달 가능하지만, 하위에서 상위로는 불가능합니다. 컨테이너 내부의 PID 1 프로세스는 특별한 시그널 처리 규칙을 가지며, 명시적으로 핸들러가 등록되지 않은 시그널은 무시됩니다. fork()로 생성된 자식 프로세스는 부모와 동일한 네임스페이스에 속하며, 호스트에서는 연속되지 않은 PID를 가질 수 있습니다.
- • PID 네임스페이스는 계층적이며 상위는 하위의 모든 프로세스를 볼 수 있지만 역은 불가능
- • 시그널 전달은 상위에서 하위로만 가능하며 컨테이너 PID 1은 특별한 시그널 처리 규칙 적용
- • fork()로 생성된 프로세스는 동일 네임스페이스에 속하며 호스트 PID와 컨테이너 PID는 독립적으로 할당
docker stop 명령어가 컨테이너를 종료할 때 SIGTERM과 SIGKILL을 순차적으로 전송하는 과정에서, PID 네임스페이스의 init 프로세스가 자식 프로세스들을 정리하는 메커니즘을 설명해주세요.
Q. Docker 볼륨을 사용하는 컨테이너에서 대용량 파일을 다룰 때 inode 고갈 문제가 발생할 수 있는 상황을 설명하고, inode와 data block의 관계, df -i 명령어로 확인할 수 있는 정보, 그리고 inode 고갈을 예방하기 위한 파일시스템 설계 전략을 제시해주세요.
inode는 파일 메타데이터를 저장하는 자료구조로, 파일 크기와 무관하게 파일당 하나씩 할당됩니다. 작은 파일이 수백만 개 생성되면 data block은 충분해도 inode가 고갈되어 새 파일을 생성할 수 없습니다. df -i 명령어로 inode 사용률을 확인할 수 있으며, IUsed와 IFree 값을 모니터링해야 합니다. 로그 파일이나 캐시 파일을 많이 생성하는 애플리케이션에서 주로 발생하며, 파일시스템 생성 시 -i 옵션으로 bytes-per-inode 비율을 조정하거나, 로그 로테이션 정책 개선, 작은 파일들을 아카이브로 통합하는 전략이 필요합니다. tmpfs를 사용하면 메모리 기반이므로 inode 제약이 완화됩니다.
- • inode는 파일 메타데이터를 저장하며 파일 크기와 무관하게 파일당 하나씩 할당되어 작은 파일 대량 생성 시 고갈 가능
- • df -i로 inode 사용률 모니터링 가능하며 data block이 충분해도 inode 부족으로 파일 생성 실패 가능
- • 파일시스템 생성 시 bytes-per-inode 조정, 로그 로테이션, 파일 통합 전략으로 예방
overlay2 스토리지 드라이버를 사용하는 Docker 환경에서 상위 레이어에서 하위 레이어의 파일을 삭제할 때 whiteout 파일이 생성되는 메커니즘과 이것이 inode 사용량에 미치는 영향을 설명해주세요.
Q. Docker의 DNS 기반 서비스 디스커버리에서 컨테이너 이름을 IP 주소로 변환할 때 사용되는 내부 DNS 서버의 동작 원리를 설명하고, 해시 테이블과 TTL(Time To Live) 캐싱 메커니즘이 어떻게 결합되어 빠른 조회 성능을 제공하는지 자료구조 관점에서 분석해주세요.
Docker의 내장 DNS 서버(127.0.0.11)는 컨테이너 이름과 IP 주소를 매핑하는 해시 테이블을 유지하여 O(1) 시간 복잡도로 조회합니다. 컨테이너가 생성되거나 삭제될 때 해시 테이블이 동적으로 업데이트되며, 네트워크 별로 독립적인 DNS 네임스페이스를 관리합니다. DNS 응답에는 짧은 TTL이 설정되어 클라이언트 측 캐싱을 제한하고, 컨테이너 IP 변경 시 빠르게 반영되도록 합니다. 내부적으로는 컨테이너 ID를 키로 하는 해시 테이블과 네트워크 alias를 처리하는 별도의 매핑 테이블이 존재하며, round-robin 방식의 로드 밸런싱을 위해 동일 서비스명에 여러 IP를 배열로 저장합니다.
- • 내장 DNS 서버는 컨테이너 이름-IP 매핑을 해시 테이블로 관리하여 O(1) 조회 성능 제공
- • 짧은 TTL로 클라이언트 캐싱을 제한하여 컨테이너 IP 변경 시 빠른 업데이트 보장
- • 동일 서비스명에 여러 IP를 배열로 저장하여 round-robin 로드 밸런싱 구현
Docker Swarm 모드에서 서비스 VIP(Virtual IP)를 사용한 로드 밸런싱과 DNS round-robin 방식의 차이점을 설명하고, 각각의 장단점과 적합한 사용 사례를 제시해주세요.
Q. Docker 이미지 레지스트리에서 이미지 태그 검색과 필터링을 구현할 때, 대량의 태그 메타데이터를 효율적으로 처리하기 위한 인덱싱 전략을 설명하고, 태그 이름의 prefix 검색, 버전 범위 필터링, 최신순 정렬을 지원하기 위해 적합한 자료구조와 알고리즘을 제시해주세요.
태그 이름의 prefix 검색에는 Trie(접두사 트리) 자료구조가 적합하며, O(m) 시간 복잡도로 길이 m인 prefix에 매칭되는 모든 태그를 찾을 수 있습니다. 버전 범위 필터링(예: 1.5.x ~ 2.0.x)을 위해서는 세그먼트 트리나 B+ 트리를 사용하여 범위 쿼리를 O(log n + k) 시간에 처리할 수 있으며, 여기서 k는 결과 개수입니다. 최신순 정렬을 위해 타임스탬프를 기준으로 한 인덱스를 유지하고, 복합 쿼리 시에는 비트맵 인덱스나 역색인을 활용하여 여러 조건을 교집합 연산으로 처리합니다. 실제 구현에서는 Elasticsearch 같은 검색 엔진이 역색인과 Trie를 결합한 구조를 사용하며, 캐싱 레이어를 추가하여 자주 조회되는 패턴의 성능을 개선합니다.
- • Trie 자료구조로 prefix 검색을 O(m) 시간에 처리하며 자동완성 기능 제공
- • B+ 트리나 세그먼트 트리로 버전 범위 쿼리를 O(log n + k) 시간에 수행
- • 비트맵 인덱스와 역색인을 활용한 복합 쿼리 최적화 및 캐싱 레이어 적용
수천 개의 이미지 태그가 있는 레지스트리에서 semantic versioning 규칙에 따라 latest stable 버전을 찾는 알고리즘을 설계하고, pre-release 버전과 build metadata를 고려한 정렬 로직의 시간 복잡도를 분석해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!