이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 ECS Fargate와 ALB를 이용해 두 개 가용 영역에 걸친 컨테이너 클러스터를 구성한 경험이 있습니다. 가용성을 고려한 핵심 선택은 헬스체크 주기를 10초로 줄이고, 비정상 컨테이너는 자동으로 교체되도록 태스크 재시작 정책을 설정한 것입니다. 구축 과정에서 어려웠던 부분은 스테이트풀 컴포넌트인 세션 데이터 처리였습니다. Fargate는 컨테이너가 교체될 때 로컬 상태가 사라지기 때문에 ElastiCache Redis로 세션을 외부화해서 해결했습니다. 결과는 4주 운영 기간 동안 예상치 못한 컨테이너 다운이 두 번 발생했지만 서비스 중단 없이 자동 복구됐습니다. 성과 측정은 ALB 액세스 로그와 CloudWatch 메트릭으로 5분 단위 가용성을 추적해서 확인했고, 평균 99.6% 수준을 유지했습니다.
고가용성 시스템에서 운영 중 가용성을 떨어뜨리는 주요 원인 중 하나는 배포 자체입니다. 사이드 프로젝트에서 ECS 배포를 처음에는 태스크를 전부 내리고 새 버전을 올리는 방식으로 했는데, 배포 시간 동안 서비스가 완전히 중단되는 것을 경험했습니다. ECS의 롤링 업데이트 설정(minimum healthy percent 100, maximum percent 200)으로 바꾸면 기존 컨테이너가 살아있는 상태에서 새 버전이 올라오고 검증 후 교체되는 방식이 됩니다. 이 설정 변경 하나로 배포 중 다운타임이 0이 됐습니다. 설정을 바꾸기 전에는 배포를 트래픽이 적은 새벽에만 했는데, 이후 낮 시간에도 자유롭게 배포할 수 있게 됐습니다.
가용성은 장애 대응만큼 배포 전략에서도 결정된다는 것이 이 경험에서 배운 핵심입니다.
고가용성 시스템 구축에서 기술적 문제 외에 비용 최적화와 가용성 사이의 판단이 어려웠습니다. Multi-AZ 구성은 가용성을 높이지만 같은 리소스를 두 개 영역에서 실행하기 때문에 비용이 올라갑니다. 사이드 프로젝트라 비용 예산이 있었는데, 처음에는 최소 사양으로 두 영역을 구성했다가 부하가 일정 수준을 넘으면 응답이 느려지는 문제가 있었습니다.
단일 영역을 조금 더 높은 사양으로 쓰는 것과 두 영역을 낮은 사양으로 쓰는 것의 비교를 CloudWatch 지표로 실측했습니다. 같은 비용에서 Multi-AZ 구성이 피크 트래픽 처리에 더 효과적이라는 결과가 나왔고, 이유는 두 영역이 부하를 분산하기 때문이었습니다.
비용과 가용성의 트레이드오프는 이론이 아니라 실측으로 판단하는 것이 맞다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.