배경 이번 글에서 다루는 deregister-targets 등의 개념은 1편에 작성되어 있습니다..ㅎㅎ 1편을 먼저 읽고 이번 글을 읽어주시면 감사하겠습니다. 지난 글에서 통계량을 이용해 deregister-targets 호출 이후 실제 트래픽 중단까지 소요되는 최대 시간을 15초로 잡았었습니다. 지난번에 계산했던 트래픽 중단까지의 시간이 15초를 초과할 확률은 0.000021% 로 극히 미미한 수준이지만, 그럼에도 발생 가능성이 있다는 찝찝함은 있었던 것 같습니다. 그래서.. aws-cli의 elbv2 API 문서를 하나씩 살펴보던 도중 wait이라는 키워드를 발견했는데요, 이번 글에서는 wait을 이용하여 기존의 불확실성을 더 개선하는 방법을 소개하겠습니다. wait API Wait until a particular condition is satisfied. Each subcommand polls an API until the listed requirement is met. 공…

배경 기존 방법은, 의도적으로 헬스체크에 실패하도록 하는 API를 호출하여 ELB(로드 밸런서)의 트래픽 배분을 막는 방법이었습니다. 팀원인 테니가 상황에 맞게 훌륭하게 구현해줬고, 문제될 여지가 거의 없다고는 느껴지지만 아래의 불확실성은 있다는 생각이 들었습니다. 해당 API의 호출 시점, 그리고 서버의 상황에 따라 실제 트래픽 중단까지 최대 10초에 가까운 시간 차이가 발생합니다. 배포 작업이 애플리케이션의 영향을 받습니다. 현재는 API를 호출하여 헬스체크에 사용되는 불리언 필드를 false로 바꿔 실패하도록 하고 있는데, 이걸 다시 true로 바꾸는 기능은 없습니다. 즉 배포 과정에서의 사소한 실수로 불필요하게 해당 API가 호출된다면 Springboot를 다시 배포해야 합니다. 기존 방법에 대한 자세한 내용은 이전 글 을 참고해주세요! 두개의 원인을 보면 결국 API를 다른 무언가로 대체하는 것이 해결 방법인 것 같은데요, 물론 다른 해결 방법도 있겠지만 이번 글에서는 A…

배경 프로젝트 팀원인 테니가 기존의 무중단 배포에서 다운타임이 발생하는 문제를 해결하는 PR을 올렸습니다. 자세한 내용은 해당 PR에서 확인하실 수 있습니다. 문제도 잘 파악했고, 해결까지의 전체 과정을 문서화해서 공유해준 덕분에 전체 과정을 빠르게 이해할 수 있었는데요(테니 감사합니다 😄), 제가 PR에 남겼던 댓글 중 일부를 직접 테스트해본 결과를 바탕으로 기존 방법에서 조금 더 개선이 가능한 부분을 공유하고자 합니다. 기존 배포 과정 개선 방법을 작성하기 전에, 기존의 과정을 순서대로 살펴보며 전체 흐름을 다시 정리하겠습니다. 1. 인스턴스 내부에서 POST /termination 요청을 보내 ELB의 헬스체크에 실패하도록 지정 ELB의 헬스체크에 사용되는 코드를 살펴보겠습니다. 메서드는 필드에 있는 AtomicBoolean 값이 이면 ELB가 로 헬스체크 요청을 보낼 때 을 보내는 코드입니다. ELB에는 헬스체크 정상 응답 코드가 200으로 지정되어 있습니다. 메서드는…

배경 팀원의 코드를 리뷰하고 있었는데, 아래와 같은 코드가 있었습니다. 실제 코드와 다르며 내용 파악을 위해 일부 수정하였습니다. 내용은 중요하지 않긴 하지만.. 간단하게만 말씀드리면 ELB에서의 헬스체크를 의도적으로 실패하도록 하는 API 입니다. 이 코드에서의 핵심은 클라이언트의 IP(=remoteHost)가 로컬호스트인 경우에만 OK 응답을 주겠다는 건데, 여기서 의문이 들었던 것은 “Nginx 설정과 무관하게 getRemoteHost()가 항상 실제 클라이언트의 IP를 반환할 것을 보장하는지?” 였는데요, 의문이 들었던 내용부터 실제 테스트를 하며 확인한 결과를 하나하나 작성해 보겠습니다. 시작하기 전에, 이번 글에서 사용하는 인프라 구조입니다! 질문 이전 문단에 나왔던 코드의 getRemoteHost() 부분에 아래와 같은 질문을 남겼었습니다. 찝찝했던 이유는 이전에 ELB를 사용하기 전 EC2로 직접 요청을 보냈을 때 클라이언트 정보를 읽어오지 못해 문제가 발생했던 …