Elixir 리드·아키텍트 배포·운영 면접
새 면접Q. 수백만 명의 동시접속자가 있는 Elixir/Phoenix 기반 실시간 채팅 서비스를 운영하고 있습니다. WebSocket 연결이 끊기지 않도록 무중단 배포를 구현해야 하는데, Hot Code Swapping과 Blue-Green 배포 방식을 비교하여 각각의 장단점과 실무 적용 시 고려사항을 설명해주세요. 또한 어떤 상황에서 어떤 방식을 선택하시겠습니까?
Elixir의 OTP 특성과 실시간 연결 유지, 배포 복잡도, 롤백 용이성 측면에서 생각해보세요.
Hot Code Swapping은 Erlang VM의 고유 기능으로 실행 중인 프로세스를 중단하지 않고 코드를 교체할 수 있어 WebSocket 연결이 완전히 유지됩니다. 하지만 릴리즈 패키징이 복잡하고 상태 마이그레이션 코드 작성이 필요하며 롤백 시 리스크가 높습니다. Blue-Green 배포는 새 인스턴스 그룹을 띄우고 로드밸런서에서 트래픽을 전환하는 방식으로 구현이 단순하고 롤백이 즉각적이지만, 연결 재수립 로직과 클라이언트 재연결 처리가 필요합니다. 실무에서는 대부분 Blue-Green 방식에 Connection Draining을 조합하여 구 인스턴스의 연결을 점진적으로 종료하는 방식을 선택합니다. Hot Code Swapping은 텔레콤급 가용성이 필요하거나 클라이언트 재연결이 불가능한 특수 상황에서만 사용하며, 이 경우 Distillery나 Mix Release의 appup 파일을 활용한 철저한 테스트가 필수입니다.
- • Hot Code Swapping은 연결 유지가 완벽하지만 구현 복잡도와 롤백 리스크가 높음
- • Blue-Green 배포는 구현이 단순하고 롤백이 안전하지만 연결 재수립 처리 필요
- • 실무에서는 Blue-Green + Connection Draining 조합이 가장 현실적
- • Hot Code Swapping은 특수한 고가용성 요구사항에서만 선택
실시간 게임, 금융 거래 시스템, 대규모 채팅 서비스에서 사용자 경험을 해치지 않는 배포 전략 수립에 활용됩니다.
Connection Draining 구현 시 타임아웃을 어떻게 설정하시겠으며, 강제 종료되는 연결에 대한 모니터링은 어떻게 구성하시겠습니까?
Q. Elixir 마이크로서비스 아키텍처에서 분산 트레이싱과 텔레메트리 시스템을 구축하려고 합니다. Telemetry 라이브러리를 활용한 메트릭 수집 전략과 OpenTelemetry 통합 방안을 설명하고, BEAM VM 특성을 고려한 핵심 메트릭(프로세스 수, 메모리, 스케줄러 활용률 등)을 어떻게 수집하고 알람을 설정할지 아키텍처 레벨에서 설명해주세요.
Telemetry 이벤트 구조, Phoenix와 Ecto의 기본 instrumentation, BEAM VM 메트릭 추출 방법을 고려하세요.
Telemetry는 Elixir 생태계의 표준 메트릭 라이브러리로 :telemetry.execute/3로 이벤트를 발생시키고 :telemetry.attach/4로 핸들러를 등록하는 구조입니다. Phoenix와 Ecto는 기본적으로 요청 처리 시간, 쿼리 실행 시간 등의 이벤트를 제공하므로 이를 TelemetryMetrics로 집계하고 Prometheus Exporter나 StatsD로 전송합니다. OpenTelemetry 통합은 opentelemetry_telemetry 라이브러리로 Telemetry 이벤트를 OTEL Span으로 변환하여 Jaeger나 Tempo로 전송하며, 분산 추적을 위해 HTTP 헤더로 trace_id와 span_id를 전파합니다. BEAM VM 메트릭은 :erlang.memory(), :erlang.system_info(:process_count), :scheduler.utilization()을 주기적으로 폴링하여 수집하고, 프로세스 수가 임계치 초과 시, 스케줄러 활용률이 80% 이상 지속 시, 메모리 증가율이 비정상적일 때 PagerDuty나 Slack으로 알람을 발송합니다. 아키텍처적으로는 각 노드에서 TelemetryMetricsPrometheus를 실행하고 중앙 Prometheus가 scrape하는 pull 방식과, OTEL Collector로 push하는 방식을 혼용하여 메트릭 유실을 방지합니다.
- • Telemetry 이벤트 기반 아키텍처로 Phoenix/Ecto 기본 메트릭 활용
- • OpenTelemetry 통합으로 분산 트레이싱 구현 및 trace context 전파
- • BEAM VM 고유 메트릭을 Erlang 내장 함수로 수집하고 임계치 기반 알람 설정
- • Pull/Push 혼합 아키텍처로 메트릭 수집 안정성 확보
대규모 분산 시스템에서 병목 지점 식별, 장애 원인 추적, 성능 저하 사전 감지에 필수적인 관찰성 인프라 구축에 사용됩니다.
프로세스 메모리 누수를 탐지하기 위해 어떤 메트릭을 추적하고, 특정 GenServer의 메시지 큐 적체를 어떻게 모니터링하시겠습니까?
Q. 레거시 Ruby on Rails 시스템을 Elixir로 점진적으로 전환하는 프로젝트를 리드하고 있습니다. 두 시스템이 공존하는 기간 동안 CI/CD 파이프라인을 어떻게 설계하시겠습니까? Mix Release 기반 배포 전략, 멀티 스테이지 Docker 빌드 최적화, 데이터베이스 마이그레이션 동기화, 그리고 배포 실패 시 자동 롤백 메커니즘을 포함하여 전체 파이프라인 아키텍처를 설명해주세요.
빌드 캐싱, 환경별 릴리즈 구성, DB 마이그레이션 순서, 헬스체크 기반 롤백을 고려하세요.
CI/CD 파이프라인은 GitHub Actions나 GitLab CI에서 멀티 스테이지 Docker 빌드로 구성하며, 첫 스테이지에서 Elixir 의존성을 설치하고 mix deps.compile 결과를 캐싱하여 빌드 시간을 단축합니다. Mix Release는 MIX_ENV=prod mix release로 self-contained 바이너리를 생성하고, runtime.exs에서 환경변수로 설정을 주입하여 동일 이미지를 dev/staging/prod에서 재사용합니다. 데이터베이스 마이그레이션은 Rails와 Elixir 양쪽 모두 backward-compatible하게 작성하며, 배포 순서는 DB 마이그레이션 먼저 실행 후 Rails와 Elixir를 순차 배포하여 스키마 불일치를 방지합니다. Kubernetes 환경에서는 InitContainer로 mix ecto.migrate를 실행하고, readinessProbe와 livenessProbe로 /health 엔드포인트를 체크하여 연속 3회 실패 시 새 Pod를 종료하고 이전 ReplicaSet으로 자동 롤백합니다. Helm Chart의 rollback hook이나 ArgoCD의 auto-sync 정책을 활용하여 배포 실패를 감지하면 이전 릴리즈로 복원하며, Slack 알림으로 팀에 즉시 통지합니다. 릴리즈 아티팩트는 ECR이나 Docker Hub에 버전 태그와 함께 저장하여 언제든 특정 버전으로 롤백 가능하도록 합니다.
- • 멀티 스테이지 Docker 빌드와 의존성 캐싱으로 빌드 시간 최적화
- • Mix Release의 runtime.exs로 환경별 설정 분리 및 이미지 재사용
- • Backward-compatible 마이그레이션과 배포 순서 제어로 Rails/Elixir 공존 보장
- • Health check 기반 자동 롤백과 릴리즈 아티팩트 버저닝으로 안전한 배포
레거시 시스템 현대화 프로젝트에서 리스크를 최소화하면서 점진적 전환을 가능하게 하는 인프라 전략 수립에 활용됩니다.
Elixir 클러스터링 환경에서 노드 간 코드 버전이 달라지는 상황을 어떻게 방지하고, 배포 중 클러스터 split-brain을 어떻게 처리하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!