운영체제 시니어 배포·운영 기술면접
새 면접Q. 대규모 트래픽을 처리하는 서비스에서 커널 파라미터 변경이 필요한 상황입니다. net.ipv4.tcp_fin_timeout, somaxconn 등의 커널 파라미터를 운영 중인 시스템에 무중단으로 적용하는 전략과, 컨테이너 환경에서 이러한 커널 파라미터 변경이 갖는 제약사항을 설명해주세요.
sysctl 명령어의 동적 적용 특성과 컨테이너가 호스트 커널을 공유한다는 점을 고려해보세요.
커널 파라미터는 sysctl -w 명령어로 런타임에 동적 적용이 가능하며, 재부팅 없이 즉시 반영됩니다. 다만 일부 파라미터는 변경 시 기존 연결에 영향을 줄 수 있어 Blue-Green 배포 방식으로 새 인스턴스 그룹에 먼저 적용 후 트래픽을 점진적으로 전환하는 것이 안전합니다. 컨테이너 환경에서는 대부분의 커널 파라미터가 호스트 레벨에서만 변경 가능하며, 네임스페이스로 격리되지 않아 모든 컨테이너에 영향을 미칩니다. 따라서 privileged 모드나 호스트 네트워크 모드 사용, 또는 init container를 통한 사전 설정이 필요하며, Kubernetes에서는 DaemonSet으로 노드별 설정을 관리합니다. 변경 전후로 connection 수, latency, packet drop 등의 메트릭을 면밀히 모니터링하여 성능 영향을 검증해야 합니다.
- • sysctl을 통한 런타임 동적 적용 가능
- • 컨테이너는 호스트 커널을 공유하므로 격리되지 않음
- • Blue-Green 방식으로 점진적 적용 및 검증 필요
- • Kubernetes에서는 DaemonSet이나 init container 활용
고트래픽 서비스에서 TIME_WAIT 소켓 고갈이나 connection backlog 부족 문제 해결 시 필수적입니다.
컨테이너별로 다른 네트워크 파라미터를 적용해야 한다면 어떤 방법을 사용하시겠습니까?
Q. 프로덕션 환경에서 컨테이너의 메모리 사용량이 limit에 근접하여 OOMKilled가 빈번히 발생합니다. cgroup의 메모리 서브시스템 관점에서 컨테이너 메모리 accounting 메커니즘을 설명하고, RSS, cache, swap 등을 구분하여 모니터링해야 하는 이유와 실제 메모리 부족을 판단하는 기준을 제시해주세요.
cgroup의 memory.stat 파일에서 제공하는 메트릭들과 페이지 캐시의 회수 가능성을 생각해보세요.
cgroup v1/v2의 메모리 서브시스템은 memory.usage_in_bytes를 통해 총 사용량을 추적하지만, 이는 RSS(실제 프로세스 메모리)와 cache(페이지 캐시)를 합산한 값입니다. 페이지 캐시는 커널이 필요 시 회수 가능한 메모리이므로, 실제 메모리 압박은 RSS(anon memory)와 active_file을 기준으로 판단해야 합니다. memory.stat 파일에서 rss, cache, active_anon, inactive_file 등을 분리하여 모니터링하면 OOM의 진짜 원인이 애플리케이션 메모리 누수인지 캐시 과다 사용인지 구분할 수 있습니다. 또한 memory.pressure나 memory.oom_control을 통해 메모리 회수 압력과 OOM 발생 횟수를 추적하여 limit 조정 또는 애플리케이션 최적화 여부를 결정합니다. swap이 활성화된 경우 memory.memsw.usage_in_bytes로 swap 사용량까지 모니터링하여 I/O 성능 저하를 사전 감지해야 합니다.
- • memory.usage_in_bytes는 RSS와 cache의 합계
- • 페이지 캐시는 회수 가능하므로 RSS 기준으로 실제 압박 판단
- • memory.stat으로 세부 메트릭 분리 모니터링
- • memory.pressure와 OOM 이벤트로 메모리 압력 추적
컨테이너 메모리 limit 설정과 OOM 트러블슈팅 시 정확한 원인 파악에 필수적입니다.
cgroup v1과 v2에서 메모리 관리 방식의 차이점은 무엇인가요?
Q. 멀티 아키텍처(amd64, arm64) 지원이 필요한 컨테이너 이미지를 CI/CD 파이프라인에서 빌드하고 배포하는 전략을 설명해주세요. buildx, manifest list, 그리고 각 아키텍처별 빌드 시간 최적화 방안을 포함해주세요.
Docker buildx의 멀티 플랫폼 빌드 기능과 빌드 캐시 전략을 고려해보세요.
Docker buildx를 활용하여 --platform linux/amd64,linux/arm64 옵션으로 멀티 아키텍처 이미지를 한 번에 빌드하고, manifest list를 생성하여 단일 태그로 푸시합니다. 각 아키텍처별 빌드는 QEMU 에뮬레이션 또는 네이티브 빌더 노드를 사용하며, 네이티브 빌드가 10배 이상 빠르므로 GitHub Actions의 ARM runner나 별도 ARM 빌드 서버를 활용합니다. 빌드 캐시는 --cache-from/--cache-to 옵션으로 레지스트리 캐시를 사용하여 레이어를 재사용하고, 멀티 스테이지 빌드로 의존성 설치 단계를 분리하여 캐시 효율을 높입니다. CI 파이프라인에서는 아키텍처별 병렬 빌드 후 manifest를 병합하는 방식으로 전체 빌드 시간을 단축하며, 각 아키텍처 이미지에 대한 통합 테스트를 분리된 환경에서 수행합니다.
- • buildx로 멀티 플랫폼 빌드 및 manifest list 생성
- • 네이티브 빌더 사용으로 빌드 속도 최적화
- • 레지스트리 캐시와 멀티 스테이지 빌드로 캐시 효율 향상
- • 병렬 빌드와 아키텍처별 테스트 분리
Apple Silicon, AWS Graviton 등 ARM 기반 인프라 확산으로 멀티 아키텍처 지원이 필수가 되었습니다.
ARM 아키텍처에서만 발생하는 특정 버그를 CI 단계에서 어떻게 감지하시겠습니까?
Q. 운영 중인 시스템에서 새 버전 배포 후 파일시스템 레이아웃 변경(디렉토리 구조, 권한, 마운트 포인트 등)으로 인해 단순 이미지 롤백만으로는 복구가 불가능한 상황이 발생했습니다. 이러한 stateful한 변경을 포함한 배포의 안전한 롤백 전략과 사전 예방 방안을 설명해주세요.
인프라 변경을 코드화하고 버전 관리하는 방법과 마이그레이션 스크립트의 양방향성을 고려해보세요.
파일시스템 변경은 init container나 마이그레이션 스크립트로 명시적으로 관리하며, forward/backward 스크립트를 쌍으로 작성하여 양방향 전환을 보장합니다. 배포 전 스냅샷(LVM, EBS snapshot)을 생성하거나 rsync로 백업하여 최악의 경우 파일시스템 레벨 복구를 가능하게 합니다. Kubernetes에서는 StatefulSet의 volumeClaimTemplate과 PV 스냅샷을 활용하고, 배포 시 이전 버전과 호환되는 마이그레이션을 먼저 수행한 후 애플리케이션을 업데이트하는 expand-contract 패턴을 사용합니다. 모든 인프라 변경은 Terraform, Ansible 등으로 코드화하여 버전 관리하고, dry-run 모드로 변경 사항을 사전 검증합니다. Canary 배포 시 파일시스템 변경이 포함된 경우 별도 테스트 볼륨에서 먼저 검증한 후 프로덕션에 적용하며, 롤백 절차를 runbook으로 문서화하여 팀원 누구나 실행 가능하게 합니다.
- • 마이그레이션 스크립트의 양방향(forward/backward) 작성
- • 스냅샷 또는 백업을 통한 파일시스템 레벨 복구 준비
- • expand-contract 패턴으로 호환성 유지
- • 인프라 변경의 코드화 및 dry-run 검증
로그 디렉토리 구조 변경, 설정 파일 위치 이동 등 stateful 변경 시 안전한 롤백 보장에 필수적입니다.
데이터베이스 스키마 변경과 파일시스템 변경이 동시에 필요한 경우 배포 순서를 어떻게 결정하시겠습니까?
Q. 프로덕션 환경에서 노드의 CPU steal time이 지속적으로 높게 측정되고 있습니다. steal time의 의미와 발생 원인, 그리고 이를 해결하기 위한 인프라 레벨과 애플리케이션 레벨의 대응 방안을 설명해주세요.
가상화 환경에서 하이퍼바이저의 CPU 스케줄링과 noisy neighbor 문제를 생각해보세요.
CPU steal time은 가상머신이 CPU를 사용하려 했으나 하이퍼바이저가 다른 VM에 CPU를 할당하여 대기한 시간의 비율로, 물리 호스트의 오버커밋이나 noisy neighbor 문제를 나타냅니다. 클라우드 환경에서는 인스턴스 타입을 CPU 크레딧 제한이 없는 상위 티어로 변경하거나, dedicated host나 베어메탈 인스턴스로 마이그레이션하여 근본적으로 해결합니다. 인프라 레벨에서는 CPU affinity 설정으로 중요 프로세스를 특정 코어에 고정하고, CPU 거버너를 performance 모드로 변경하여 주파수 스케일링 지연을 최소화합니다. 애플리케이션 레벨에서는 CPU-intensive 작업을 비동기 큐로 분리하고, 워커 프로세스 수를 조정하여 컨텍스트 스위칭을 줄이며, 캐싱을 강화하여 CPU 사용량 자체를 낮춥니다. 모니터링에서는 steal time과 함께 load average, context switch rate를 함께 추적하여 성능 저하의 정확한 원인을 파악합니다.
- • steal time은 하이퍼바이저의 CPU 할당 대기 시간
- • 인스턴스 타입 변경 또는 dedicated host 사용
- • CPU affinity와 거버너 설정으로 최적화
- • 애플리케이션 비동기 처리 및 CPU 사용량 감소
클라우드 환경에서 예기치 않은 성능 저하 발생 시 하이퍼바이저 레벨의 리소스 경합을 파악하는 데 중요합니다.
컨테이너 환경에서 CPU throttling과 steal time을 어떻게 구분하여 진단하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!