Docker 주니어 CS 기초 면접
새 면접Q. Docker 컨테이너가 DNS 이름 해석을 수행하는 방식을 설명하고, /etc/resolv.conf 파일이 어떻게 관리되는지 말씀해주세요. 또한 사용자 정의 네트워크에서 컨테이너 이름으로 통신이 가능한 이유를 설명해주세요.
Docker는 컨테이너 생성 시 호스트의 /etc/resolv.conf를 복사하여 컨테이너 내부에 마운트합니다. 기본 브리지 네트워크에서는 IP 주소로만 통신이 가능하지만, 사용자 정의 브리지 네트워크는 내장 DNS 서버(127.0.0.11)를 제공하여 컨테이너 이름을 IP로 자동 변환합니다. 이를 통해 컨테이너 간 서비스 디스커버리가 가능하며, IP 변경에도 유연하게 대응할 수 있습니다. Docker의 내장 DNS는 컨테이너 이름을 키로, IP 주소를 값으로 하는 해시 테이블 형태로 관리됩니다.
- • 호스트의 resolv.conf를 컨테이너에 복사하여 DNS 설정 상속
- • 사용자 정의 네트워크는 내장 DNS 서버(127.0.0.11) 제공
- • 컨테이너 이름을 통한 자동 서비스 디스커버리 지원
- • DNS 레코드를 해시 테이블로 관리하여 빠른 이름 해석
Docker Compose에서 서비스 이름으로 통신할 때 내부적으로 어떤 DNS 레코드가 생성되며, 같은 서비스의 여러 컨테이너(replica)가 있을 때 DNS 라운드 로빈은 어떻게 동작하나요?
Q. Docker가 사용하는 cgroups(Control Groups)의 역할과 동작 원리를 설명하고, 컨테이너에 메모리 제한을 설정했을 때 OOM(Out Of Memory) Killer가 어떻게 작동하는지 말씀해주세요.
cgroups는 Linux 커널 기능으로 프로세스 그룹의 리소스(CPU, 메모리, I/O 등) 사용량을 제한하고 모니터링합니다. Docker는 각 컨테이너마다 독립적인 cgroup을 생성하여 리소스를 격리합니다. 컨테이너에 메모리 제한을 설정하면 해당 cgroup의 메모리 사용량이 제한을 초과할 때 OOM Killer가 활성화됩니다. OOM Killer는 cgroup 내부 프로세스의 우선순위를 평가하여 메모리를 가장 많이 사용하는 프로세스를 종료시키며, 호스트의 다른 프로세스에는 영향을 주지 않습니다.
- • cgroups는 프로세스 그룹의 리소스 사용량 제한 및 모니터링
- • 컨테이너마다 독립적인 cgroup 생성으로 리소스 격리
- • 메모리 제한 초과 시 해당 cgroup 내에서만 OOM Killer 작동
- • 호스트 시스템의 다른 프로세스와 격리되어 안정성 보장
Docker에서 --memory와 --memory-swap 옵션의 차이는 무엇이며, 스왑을 제한하지 않으면 어떤 성능 문제가 발생할 수 있나요?
Q. Docker 이미지의 레이어 캐시가 재사용되는 조건을 판단하는 방식은 어떤 자료구조와 유사하며, Dockerfile의 각 명령어가 해시값으로 관리되는 이유를 설명해주세요.
Docker는 각 레이어를 해시값으로 식별하며, 이는 해시 테이블 자료구조의 특성과 유사합니다. Dockerfile의 각 명령어와 그 컨텍스트(파일 내용 등)를 해싱하여 고유한 레이어 ID를 생성합니다. 빌드 시 동일한 명령어와 컨텍스트가 발견되면 해시값을 비교하여 기존 캐시를 재사용합니다. 이를 통해 O(1) 시간 복잡도로 캐시 존재 여부를 빠르게 확인할 수 있으며, 명령어 순서나 내용이 조금이라도 변경되면 해시값이 달라져 캐시가 무효화됩니다.
- • 각 레이어를 해시값으로 식별하는 해시 테이블 방식
- • 명령어와 컨텍스트를 해싱하여 고유한 레이어 ID 생성
- • 해시 비교를 통한 O(1) 캐시 조회
- • 내용 변경 시 해시값 변경으로 캐시 무효화
Dockerfile에서 자주 변경되는 소스 코드 복사 명령을 뒤쪽에 배치하는 것이 빌드 속도에 어떤 영향을 미치며, 이는 어떤 최적화 원칙과 관련이 있나요?
Q. Docker 컨테이너에서 MySQL을 실행할 때 innodb_flush_log_at_trx_commit 설정값이 성능과 데이터 안정성에 미치는 영향을 설명하고, 볼륨을 사용하지 않을 때 발생할 수 있는 데이터 손실 시나리오를 말씀해주세요.
innodb_flush_log_at_trx_commit은 트랜잭션 로그를 디스크에 기록하는 시점을 제어합니다. 값이 1이면 매 트랜잭션마다 디스크에 동기화하여 안정성은 높지만 성능이 저하되고, 0이나 2는 성능은 좋지만 장애 시 데이터 손실 위험이 있습니다. 컨테이너에서 볼륨을 사용하지 않으면 데이터가 컨테이너의 쓰기 가능 레이어에만 저장되므로, 컨테이너 재시작이나 삭제 시 모든 데이터가 손실됩니다. 또한 컨테이너 레이어는 Copy-on-Write를 사용하여 I/O 성능도 볼륨보다 떨어집니다.
- • innodb_flush_log_at_trx_commit은 로그 동기화 시점 제어
- • 설정값에 따라 성능과 데이터 안정성 트레이드오프 발생
- • 볼륨 미사용 시 컨테이너 종료와 함께 데이터 손실
- • 컨테이너 레이어의 COW 방식은 I/O 성능 저하
Docker 볼륨의 백업 전략을 설계할 때 데이터베이스의 일관성을 보장하기 위해 어떤 방법을 사용해야 하며, 핫 백업과 콜드 백업의 차이는 무엇인가요?
Q. Docker의 레이어 공유 메커니즘은 어떤 최적화 기법과 유사하며, 여러 컨테이너가 같은 베이스 이미지를 사용할 때 메모리와 디스크 공간이 절약되는 원리를 설명해주세요. 또한 이것이 시간 복잡도와 공간 복잡도의 트레이드오프와 어떤 관련이 있는지 말씀해주세요.
Docker의 레이어 공유는 동적 프로그래밍의 메모이제이션(Memoization) 기법과 유사합니다. 같은 베이스 이미지를 사용하는 여러 컨테이너는 읽기 전용 레이어를 공유하고, 각자의 변경사항만 독립적인 쓰기 레이어에 저장합니다. 이를 통해 디스크 공간을 O(n)에서 O(1) + O(변경분)으로 줄일 수 있습니다. 읽기 작업은 공유 레이어에서 직접 수행되어 빠르지만, 쓰기 작업은 Copy-on-Write로 인해 약간의 오버헤드가 발생합니다. 이는 공간 효율성을 위해 쓰기 성능을 일부 희생하는 트레이드오프입니다.
- • 레이어 공유는 메모이제이션과 유사한 최적화 기법
- • 읽기 전용 레이어 공유로 디스크 공간 절약
- • 각 컨테이너는 독립적인 쓰기 레이어만 유지
- • 공간 효율성과 쓰기 성능 간의 트레이드오프 존재
Docker 이미지를 빌드할 때 레이어 수를 줄이는 것이 중요한 이유는 무엇이며, 레이어가 너무 많을 때 발생하는 성능 문제를 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!