Docker 주니어 CS 기초 기술면접
새 면접Q. Docker 컨테이너가 호스트 시스템의 프로세스 목록에는 보이지만, 컨테이너 내부에서는 독립적인 프로세스 트리를 가지는 이유를 설명하고, 이것이 프로세스 격리에 어떤 의미를 갖는지 말씀해주세요.
Docker는 Linux의 PID Namespace를 사용하여 프로세스 격리를 구현합니다. 컨테이너 내부에서는 자체 PID 트리를 가지며 프로세스가 PID 1부터 시작하지만, 호스트 관점에서는 일반 프로세스로 보입니다. 이는 컨테이너가 다른 컨테이너나 호스트의 프로세스를 볼 수 없게 하여 보안과 격리를 제공합니다. 호스트는 모든 프로세스를 관리할 수 있지만, 컨테이너는 자신의 네임스페이스 내 프로세스만 인지합니다.
- • PID Namespace를 통한 프로세스 격리 구현
- • 컨테이너 내부는 독립적인 PID 트리 유지 (PID 1부터 시작)
- • 호스트에서는 일반 프로세스로 보이며 관리 가능
- • 컨테이너 간 프로세스 격리를 통한 보안 강화
컨테이너 내부에서 ps aux 명령어를 실행했을 때와 호스트에서 실행했을 때 출력 결과가 어떻게 다르며, 이를 통해 어떤 보안상의 이점을 얻을 수 있나요?
Q. Docker의 브리지 네트워크에서 ARP(Address Resolution Protocol) 테이블이 어떻게 관리되는지 설명하고, 컨테이너가 같은 네트워크의 다른 컨테이너와 통신할 때 MAC 주소를 찾는 과정을 말씀해주세요.
Docker 브리지 네트워크는 가상 이더넷 브리지로, 각 컨테이너는 가상 네트워크 인터페이스(veth pair)를 통해 연결됩니다. 컨테이너가 다른 컨테이너와 통신할 때 먼저 ARP 요청을 브로드캐스트하여 대상 IP의 MAC 주소를 찾습니다. 브리지는 ARP 테이블을 유지하며 MAC 주소와 포트 매핑 정보를 캐싱합니다. 이후 통신은 Layer 2 스위칭을 통해 이루어지며, 브리지가 MAC 주소 기반으로 프레임을 전달합니다.
- • 가상 이더넷 브리지를 통한 컨테이너 연결
- • ARP 프로토콜로 IP-MAC 주소 매핑 수행
- • 브리지의 MAC 주소 테이블을 통한 Layer 2 스위칭
- • veth pair를 통한 호스트-컨테이너 간 통신
만약 컨테이너가 외부 인터넷의 서버와 통신할 때는 ARP가 어떻게 작동하며, 게이트웨이의 역할은 무엇인가요?
Q. Docker 이미지의 태그 시스템에서 하나의 이미지 ID에 여러 태그를 연결할 수 있는 구조는 어떤 자료구조와 유사하며, 태그를 삭제해도 이미지가 즉시 삭제되지 않는 이유를 설명해주세요.
Docker 이미지 태그 시스템은 해시 테이블이나 심볼 테이블과 유사합니다. 여러 태그(키)가 하나의 이미지 ID(값)를 가리키는 다대일 매핑 구조입니다. 하나의 이미지 ID는 여러 태그로 참조될 수 있으며, 이는 참조 카운팅(Reference Counting) 방식으로 관리됩니다. 태그를 삭제해도 다른 태그가 같은 이미지를 참조하고 있다면 이미지는 삭제되지 않으며, 모든 참조가 제거되어야 실제 이미지가 삭제됩니다.
- • 해시 테이블 구조의 다대일 매핑 (태그 -> 이미지 ID)
- • 참조 카운팅을 통한 이미지 생명주기 관리
- • 모든 참조가 제거되어야 실제 삭제 발생
- • dangling 이미지는 태그가 없는 이미지를 의미
docker image prune 명령어는 어떤 기준으로 이미지를 삭제하며, dangling 이미지와 unused 이미지의 차이는 무엇인가요?
Q. Docker 컨테이너에서 관계형 데이터베이스를 운영할 때 ACID 속성 중 Isolation(격리성)과 관련하여, 여러 컨테이너가 같은 볼륨을 마운트하여 동시에 데이터베이스 파일에 접근할 때 발생할 수 있는 문제점과 이를 방지하는 방법을 설명해주세요.
여러 컨테이너가 같은 데이터베이스 파일에 동시 접근하면 파일 잠금 충돌, 데이터 불일치, 트랜잭션 격리 위반 등의 문제가 발생합니다. 대부분의 RDBMS는 단일 프로세스 또는 마스터-슬레이브 구조로 설계되어 있어 동시 쓰기를 지원하지 않습니다. 이를 방지하려면 데이터베이스 컨테이너는 하나만 실행하고, 애플리케이션 컨테이너들은 네트워크를 통해 데이터베이스에 접근해야 합니다. 스케일링이 필요하면 읽기 전용 레플리카를 구성하거나 데이터베이스 클러스터링을 사용해야 합니다.
- • 동일 볼륨에 여러 DB 인스턴스 접근 시 파일 잠금 충돌 발생
- • 데이터베이스는 단일 인스턴스 또는 마스터-슬레이브 구조로 운영
- • 애플리케이션은 네트워크를 통한 DB 접근 필요
- • 스케일링은 읽기 레플리카나 클러스터링으로 해결
만약 읽기 성능 향상을 위해 여러 컨테이너에서 데이터베이스를 운영하려면 어떤 아키텍처 패턴을 사용해야 하며, 이때 데이터 일관성은 어떻게 보장하나요?
Q. Docker 이미지 빌드 시 레이어 캐시를 활용하는 것은 어떤 알고리즘 최적화 기법과 유사하며, Dockerfile 명령어 순서를 최적화할 때 고려해야 할 메모이제이션(Memoization) 개념을 설명해주세요.
Docker의 레이어 캐시는 동적 프로그래밍의 메모이제이션 기법과 유사합니다. 이전에 계산한 결과를 저장하여 재사용함으로써 중복 연산을 피합니다. 각 Dockerfile 명령어는 해시값으로 식별되며, 명령어와 컨텍스트가 동일하면 이전 결과를 재사용합니다. 변경이 적은 명령어를 앞쪽에 배치하면 캐시 적중률이 높아져 빌드 시간이 단축됩니다. 예를 들어 의존성 설치를 소스 코드 복사보다 먼저 수행하면, 코드 변경 시에도 의존성 레이어는 캐시를 사용할 수 있습니다.
- • 메모이제이션을 통한 중복 연산 제거
- • 명령어와 컨텍스트의 해시값 기반 캐시 판단
- • 변경 빈도가 낮은 명령어를 앞에 배치하여 캐시 효율 극대화
- • 의존성 설치와 소스 코드 복사의 순서 최적화
만약 Dockerfile에서 RUN apt-get update 명령어를 캐시하면 어떤 문제가 발생할 수 있으며, 이를 방지하기 위한 베스트 프랙티스는 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!