네트워크 미드레벨 배포·운영 기술면접
새 면접Q. Blue-Green 배포와 Rolling 배포 방식의 차이점을 설명하고, 각각 어떤 상황에서 적합한지 네트워크 관점에서 설명해주세요.
리소스 사용량, 롤백 속도, 트래픽 라우팅 방식의 차이를 생각해보세요.
Blue-Green 배포는 동일한 환경을 두 개 구성하여 로드밸런서에서 트래픽을 한 번에 전환하는 방식으로, 즉시 롤백이 가능하지만 2배의 리소스가 필요합니다. Rolling 배포는 기존 인스턴스를 순차적으로 교체하며 리소스 효율적이지만 배포 중 버전이 혼재됩니다. Blue-Green은 금융권처럼 빠른 롤백이 중요한 경우, Rolling은 리소스가 제한적이고 점진적 배포가 가능한 경우 적합합니다. 네트워크 관점에서 Blue-Green은 DNS나 L4/L7 스위치에서 단일 전환점을 가지며, Rolling은 헬스체크를 통한 동적 라우팅이 필요합니다.
- • Blue-Green은 전체 트래픽 일괄 전환, Rolling은 순차적 교체
- • 리소스 사용량과 롤백 속도의 트레이드오프
- • 로드밸런서의 트래픽 라우팅 방식 차이
대규모 서비스의 배포 전략 수립 시 트래픽 특성과 인프라 비용을 고려하여 배포 방식을 선택합니다.
Canary 배포를 추가로 고려한다면 네트워크 라우팅을 어떻게 구성하시겠습니까?
Q. Kubernetes 환경에서 Pod 간 통신이 되지 않는 문제가 발생했습니다. CNI(Container Network Interface) 관점에서 어떤 순서로 트러블슈팅하시겠습니까?
네트워크 플러그인 상태, IP 할당, 라우팅 테이블, 네트워크 정책 순서로 점검해보세요.
먼저 CNI 플러그인(Calico, Flannel 등)의 데몬셋 상태를 확인하여 모든 노드에서 정상 동작하는지 점검합니다. 다음으로 Pod에 IP가 정상 할당되었는지 kubectl describe로 확인하고, 같은 노드와 다른 노드 간 통신을 분리하여 테스트합니다. 노드의 라우팅 테이블과 iptables 규칙을 확인하여 CNI가 생성한 규칙이 올바른지 검증합니다. NetworkPolicy가 적용되어 있다면 정책 규칙을 검토하고, 마지막으로 tcpdump로 패킷이 실제로 전달되는지 확인합니다. 이 과정에서 오버레이 네트워크의 VXLAN 터널 상태도 함께 점검합니다.
- • CNI 플러그인 데몬셋 상태 우선 확인
- • IP 할당, 라우팅 테이블, iptables 규칙 순차 검증
- • NetworkPolicy와 오버레이 네트워크 터널 상태 점검
쿠버네티스 클러스터 운영 중 마이크로서비스 간 통신 장애 발생 시 신속한 원인 파악이 필요합니다.
Service ClusterIP로 통신할 때와 Pod IP로 직접 통신할 때의 네트워크 경로 차이를 설명해주세요.
Q. GitOps 기반 배포 파이프라인에서 네트워크 설정(Ingress, Service 등)을 관리할 때 고려해야 할 사항과 베스트 프랙티스를 설명해주세요.
환경별 설정 분리, 시크릿 관리, 변경 이력 추적 관점에서 생각해보세요.
네트워크 설정을 Git 레포지토리에서 선언적으로 관리하며, Kustomize나 Helm을 사용해 환경별(dev, staging, prod) 설정을 오버레이 방식으로 분리합니다. TLS 인증서나 API 키 같은 민감 정보는 Sealed Secrets나 External Secrets Operator를 사용하여 암호화된 상태로 Git에 저장합니다. Ingress 규칙 변경 시 ArgoCD나 Flux가 자동으로 동기화하도록 구성하되, prod 환경은 수동 승인 단계를 추가합니다. 모든 네트워크 설정 변경은 Git 커밋으로 추적 가능하며, 문제 발생 시 이전 커밋으로 롤백할 수 있습니다. 변경 전 dry-run이나 diff 확인을 통해 예상치 못한 네트워크 정책 변경을 방지합니다.
- • 환경별 설정을 Kustomize/Helm으로 분리 관리
- • 민감 정보는 암호화하여 Git에 저장
- • Git 커밋 기반 변경 이력 추적 및 롤백
인프라를 코드로 관리하면서 네트워크 설정의 일관성과 추적성을 확보할 수 있습니다.
Ingress Controller를 업그레이드할 때 무중단으로 진행하려면 어떤 전략을 사용하시겠습니까?
Q. 마이크로서비스 환경에서 특정 API의 응답 시간이 간헐적으로 느려지는 현상이 발생했습니다. 네트워크 레이어에서 원인을 파악하기 위해 어떤 메트릭을 수집하고 분석하시겠습니까?
레이턴시의 P50, P95, P99 분포와 네트워크 홉, 연결 풀, DNS 조회 시간을 고려하세요.
먼저 Prometheus와 Grafana로 응답 시간의 백분위수(P50, P95, P99)를 분석하여 간헐적 지연이 일부 요청에만 발생하는지 확인합니다. 서비스 메시(Istio, Linkerd)의 분산 추적을 통해 각 마이크로서비스 간 네트워크 홉별 레이턴시를 측정하고 병목 구간을 식별합니다. TCP 연결 수립 시간, DNS 조회 시간, TLS 핸드셰이크 시간을 분리하여 측정해 어느 단계에서 지연이 발생하는지 파악합니다. 연결 풀 고갈이나 TIME_WAIT 소켓 누적 여부를 netstat으로 확인하고, 네트워크 대역폭과 패킷 손실률도 함께 모니터링합니다. Jaeger나 Zipkin으로 분산 트레이싱하여 특정 다운스트림 서비스나 외부 API 호출에서 지연이 발생하는지 추적합니다.
- • 백분위수 메트릭으로 간헐적 지연 패턴 분석
- • 분산 추적으로 서비스 간 홉별 레이턴시 측정
- • TCP 연결, DNS, TLS 단계별 시간 분리 측정
프로덕션 환경에서 사용자 경험에 영향을 주는 성능 이슈의 근본 원인을 찾기 위해 필수적입니다.
P99 레이턴시가 높은 원인이 특정 다운스트림 서비스라면 어떻게 격리하거나 개선하시겠습니까?
Q. L4 로드밸런서와 L7 로드밸런서의 차이를 설명하고, 각각의 헬스체크 방식이 배포 중 트래픽 라우팅에 어떤 영향을 미치는지 설명해주세요.
OSI 계층, 세션 유지, 헬스체크 정확도의 차이를 생각해보세요.
L4 로드밸런서는 전송 계층에서 IP와 포트 기반으로 동작하며 TCP/UDP 연결을 분산하고, L7은 애플리케이션 계층에서 HTTP 헤더, URL, 쿠키 등을 기반으로 라우팅합니다. L4 헬스체크는 TCP 포트 연결 가능 여부만 확인하므로 애플리케이션이 실제로 정상 응답하지 못해도 통과할 수 있습니다. L7 헬스체크는 특정 엔드포인트에 HTTP 요청을 보내 응답 코드와 본문을 검증하므로 애플리케이션 수준의 정상 여부를 정확히 판단합니다. 배포 중 새 버전 인스턴스가 기동되면 L7 헬스체크는 애플리케이션이 완전히 준비된 후에만 트래픽을 보내지만, L4는 포트만 열리면 트래픽을 보내 초기 요청 실패가 발생할 수 있습니다. 따라서 무중단 배포에서는 L7 로드밸런서가 더 안전하지만 성능 오버헤드가 있습니다.
- • L4는 IP/포트 기반, L7은 HTTP 콘텐츠 기반 라우팅
- • L7 헬스체크가 애플리케이션 상태를 더 정확히 판단
- • 무중단 배포 시 L7이 안전하지만 성능 트레이드오프 존재
클라우드 환경에서 ELB, ALB 선택 시 헬스체크 정확도와 비용을 고려하여 결정합니다.
Kubernetes Ingress Controller는 L7 로드밸런서인데, 앞단에 L4 로드밸런서를 두는 이유는 무엇입니까?
Q. 프로덕션 배포 후 네트워크 타임아웃 에러가 급증하여 긴급 롤백을 결정했습니다. 롤백 과정에서 네트워크 관점에서 확인해야 할 사항과 안전한 롤백 절차를 설명해주세요.
기존 연결 유지, DNS/캐시 TTL, 데이터베이스 스키마 호환성을 고려하세요.
먼저 현재 활성 연결 수와 커넥션 풀 상태를 확인하여 즉시 중단 시 영향도를 파악합니다. 로드밸런서에서 새 요청을 이전 버전으로 라우팅하되, 기존 연결은 graceful shutdown으로 정상 종료되도록 합니다. DNS 기반 라우팅을 사용한다면 TTL이 짧게 설정되어 있는지 확인하고, CDN 캐시가 있다면 퍼지합니다. 데이터베이스 마이그레이션이 있었다면 이전 버전과 스키마 호환성을 확인하고, 필요시 마이그레이션도 롤백합니다. 롤백 후 헬스체크가 통과하는지 확인하고, 모니터링 대시보드에서 에러율과 레이턴시가 정상화되는지 실시간 관찰합니다. 롤백 완료 후에도 일정 시간 모니터링하며 새 버전의 컨테이너 이미지는 삭제하지 않고 보관합니다.
- • 기존 연결은 graceful shutdown으로 처리
- • DNS TTL, CDN 캐시, 데이터베이스 스키마 호환성 확인
- • 롤백 후 헬스체크와 메트릭 실시간 모니터링
프로덕션 장애 시 빠르고 안전한 롤백으로 서비스 가용성을 최대한 빨리 복구해야 합니다.
롤백 자체도 실패할 가능성에 대비하여 어떤 준비를 하시겠습니까?
Q. Kubernetes에서 Service Mesh(예: Istio)를 도입할 때 기존 네트워크 구성과 비교하여 어떤 이점이 있으며, 도입 시 성능과 복잡도 측면에서 어떤 트레이드오프가 발생하는지 설명해주세요.
사이드카 패턴, mTLS, 트래픽 관리, 레이턴시 오버헤드를 고려하세요.
Service Mesh는 사이드카 프록시 패턴으로 애플리케이션 코드 수정 없이 서비스 간 통신을 제어하며, mTLS로 자동 암호화하여 보안을 강화합니다. 트래픽 분할, 재시도, 타임아웃, 서킷 브레이커 등을 선언적으로 설정할 수 있어 Canary 배포나 A/B 테스트가 용이합니다. 분산 추적과 메트릭이 자동으로 수집되어 관찰성이 크게 향상됩니다. 그러나 모든 트래픽이 사이드카 프록시를 거치면서 네트워크 홉이 증가하여 레이턴시가 1-5ms 추가되고, 메모리와 CPU 오버헤드가 발생합니다. 운영 복잡도도 증가하여 Envoy 프록시 설정, 인증서 관리, 컨트롤 플레인 장애 대응 등 추가 학습이 필요합니다. 따라서 마이크로서비스 규모가 크고 보안과 관찰성이 중요한 경우 도입 효과가 크지만, 소규모 서비스에서는 오버엔지니어링이 될 수 있습니다.
- • mTLS, 트래픽 관리, 관찰성 자동화의 이점
- • 레이턴시 증가와 리소스 오버헤드 발생
- • 운영 복잡도 증가와 규모에 따른 적용 판단 필요
대규모 마이크로서비스 환경에서 네트워크 정책과 보안을 중앙 집중식으로 관리할 때 고려합니다.
Service Mesh 도입 없이 유사한 기능을 구현하려면 어떤 방법들이 있을까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!