Application Load Balancer, 어디로 보낼지와 언제 뺄지

은행 창구의 안내원이 하는 일은 둘로 나뉘어요. 들어온 손님을 비어 있는 창구로 보내는 일과, 직원이 자리를 뜰 때 이미 상담 중인 손님을 어떻게 할지 정하는 일이에요. 앞의 것은 쉽고 뒤의 것이 어려워요. 상담을 끊고 보낼 수는 없으니까.

ALB(Application Load Balancer)는 웹 요청을 여러 실행 대상으로 나누는 장치예요. 어느 대상으로 보낼지 고르고, 교체 중인 대상에는 새 요청을 보내지 않도록 도와요. 이 글에서는 요청이 가는 길을 따라가면서 ‘건강한 대상’이라는 판정이 실제로 무엇을 바꾸는지 살펴볼게요.

요청이 대상에 닿기까지

경로는 네 단계예요. 먼저 리스너가 정해진 포트에서 요청을 받아요. 그다음 규칙이 주소의 경로나 호스트 이름을 보고 어느 묶음으로 보낼지 갈라요. 그 묶음이 대상 그룹이고, 그 안에 실제로 처리하는 대상들이 등록돼 있어요.

세 번째 단계가 이 장치의 성격을 정해요. 경로나 호스트 이름을 본다는 것은 요청의 내용을 열어 본다는 뜻이고, 그래서 같은 주소 하나로 여러 서비스를 나눌 수 있어요. 반면 내용을 보지 않고 연결만 옮기는 종류도 따로 있는데, 그쪽은 더 빠르고 더 단순한 대신 경로로 가를 수 없어요. 무엇을 기준으로 나눌 것인지가 어느 종류를 쓸지 정해요.

건강하다는 판정이 실제로 하는 일

ALB는 주기적으로 대상에 요청을 보내 건강 상태를 확인해요. 보통 건강한 대상으로 요청을 보내지만 중요한 예외가 있어요. 대상 그룹에 등록된 대상이 모두 비정상이면 그 대상들에게 다시 요청을 보내는 페일 오픈(fail-open) 동작을 해요. ‘검사에 실패한 대상은 절대로 요청을 받지 않는다’고 외우면 틀려요.

예를 들어 모든 대상이 같은 데이터베이스에 연결한다고 해 볼게요. 건강 검사에 데이터베이스 조회를 넣으면 데이터베이스가 느려질 때 모두 함께 실패할 수 있어요. 각 대상의 고장과 공유 의존성의 고장을 같은 신호로 표현한 거예요. 그 신호로 대상을 빼거나 교체하면 남은 용량과 재시도에 어떤 영향이 생기는지도 봐야 해요.

그래서 검사 항목은 그 판정 뒤에 할 행동과 맞춰야 해요. 이 대상 하나를 빼면 나아지는 고장인가요? 앱이 절대 처리할 수 없는 상태를 정상으로 표시해서도 안 되지만, 모든 의존성을 한 번에 검사하는 것이 늘 더 안전하지도 않아요. 개별 대상의 준비 상태와 서비스 전체의 장애 신호를 나눠 두면 판단이 더 분명해져요.

한 대상 그룹에 등록된 서버 두 대의 상태를 바꿔 보세요.

서버 A

정상

요청 대상

서버 B

정상

요청 대상

하나가 비정상이면 정상 대상만 고르지만, 등록 대상이 전부 비정상이면 ALB는 그 대상들에도 요청을 보내요.

두 서버 모두 정상이에요. 로드밸런서가 둘 사이에서 요청 대상을 골라요.

정상인 서버 A만 요청 대상이 돼요.

정상 대상이 하나도 없으면 비정상 대상에도 요청을 시도해요. 성공 응답을 보장하지는 않아요.

모든 가용 영역의 등록 대상이 비정상인 fail-open 예시예요. 빈 대상 그룹이나 다른 라우팅 설정은 다루지 않아요.

뺄 때가 더 어렵다

대상을 빼는 일은 즉시 끊는 것이 아니에요. 그 대상이 지금 처리 중인 요청이 있기 때문이에요.

대상 그룹에는 등록 해제 대기라는 설정이 있고, 빠지는 대상의 상태를 사용 안 함으로 바꾸기 전까지 진행 중인 트래픽이 끝나도록 기다려요. 새 요청은 더 이상 가지 않지만 이미 들어간 요청은 마무리돼요.

대기 시간이 진행 중인 요청보다 짧으면 요청이 끊길 수 있어요. 반대로 길게 주어도 앱 프로세스가 먼저 종료되면 끝까지 처리하지 못해요. 로드밸런서가 기다리는 시간과 앱이 종료 신호를 받은 뒤 기다리는 시간을 함께 맞춰야 해요. 실제 교체 시간은 요청 길이와 동시에 교체하는 대상 수에도 달려 있어요.

선택	얻는 것	놓치기 쉬운 조건
대기 시간을 짧게	교체를 빨리 마칠 여지	오래 걸리는 요청이 끊길 수 있음
대기 시간을 넉넉하게	진행 중인 요청을 마칠 여지	앱도 종료 전에 기다려야 함
여러 대를 겹쳐 교체	전체 교체 시간 단축	남아 있는 처리 용량 필요

세 번째 줄이 자주 잊혀요. 이 값은 배포할 때만이 아니라 문제가 생겨 되돌릴 때도 똑같이 적용돼요. 안전을 위해 길게 잡아 둔 값이 급할 때 발목을 잡는 구조예요.

저는 왜 앞에 두지 않았나

제가 만드는 앱의 AI 응답 서버 앞에는 이 장치가 없어요. 나눌 대상이 하나뿐이라 분배할 것이 없고, 공개 주소로 열지도 않았기 때문이에요. 앞 시리즈에서 다룬 대로 그 서버는 관리 통로를 지나야만 닿아요.

대신 대가를 치렀어요. 로드밸런서를 두지 않으면 건강을 확인하는 일도 제가 해야 해요. 그래서 앱 쪽에 주기적으로 그 서버가 응답하는지, 그리고 기대한 모델이 올라가 있는지까지 확인하는 감시를 따로 두었어요. 연결이 살아 있다는 것과 쓸 수 있는 상태라는 것이 다르다는 걸 여기서 배웠어요. 포트가 열려 있어도 엉뚱한 것이 올라가 있으면 요청은 실패해요.

돌아보면 로드밸런서가 파는 것은 분배가 아니라 판정이었어요. 대상이 여럿일 때는 그 판정을 대신해 주고, 하나뿐이면 그 일이 그대로 제게 남아요.