헬스체크

로드밸런서는 어떻게 알까

앞 강의에서 "로드밸런서가 죽은 서버를 자동으로 뺀다"고 했습니다. 편리해 보였습니다. 그런데 어떻게 아는 걸까요?

서버가 죽을 때 "저 이제 죽습니다"라고 인사하고 죽으면 좋겠지만, 그런 일은 없습니다. 전원이 나가면 그냥 사라집니다. 아무 말도 없이요.

그래서 로드밸런서는 주기적으로 물어봅니다.

로드밸런서 → 서버 1: "살아 있나요?"  → "네"
로드밸런서 → 서버 2: "살아 있나요?"  → "네"
로드밸런서 → 서버 3: "살아 있나요?"  → (무응답)

이 질문이 헬스체크입니다. 야간 순찰과 같습니다. 순찰을 돌아야 사고를 발견합니다. 순찰을 안 돌면 사고가 나도 모릅니다.

사고와 발견 사이에는 시간이 있다

여기가 핵심입니다. 순찰 사이에는 공백이 있습니다.

10분마다 순찰을 돈다면, 사고가 난 직후에 순찰이 지나갔을 경우 발견까지 최대 10분이 걸립니다. 그동안 아무도 모릅니다.

로드밸런서도 똑같습니다. 설정이 이렇다고 합시다.

점검 주기      : 5초에 한 번 물어본다
판정 횟수      : 3번 연속 대답이 없으면 죽은 것으로 본다

서버가 죽으면 언제 빠질까요?

0초   서버 사망
5초   1번째 질문 → 무응답 (1회)
10초  2번째 질문 → 무응답 (2회)
15초  3번째 질문 → 무응답 (3회) → 이제 뺀다

15초입니다. 서버가 죽은 순간부터 15초 동안, 로드밸런서는 죽은 서버에 계속 요청을 보냅니다. 서버가 세 대라면 그 15초 동안 사용자의 3분의 1이 오류 화면을 봅니다.

이것이 실무에서 가장 자주 오해받는 지점입니다. "로드밸런서를 붙였으니 장애는 사용자에게 안 보인다"가 아닙니다. "장애가 15초 동안만 보인다" 입니다. 그리고 그 15초는 여러분이 설정한 숫자입니다. 우연이 아닙니다.

그러면 숫자를 줄이면 되는 것 아닌가

1초마다 묻고, 1번 실패하면 바로 빼면? 노출 시간이 1초가 됩니다. 완벽해 보입니다.

여기서 함정에 빠집니다.

너무 민감하면 더 위험하다

네트워크는 가끔 딸꾹질을 합니다. 서버가 순간적으로 바빠서 응답이 0.1초 늦을 수도 있습니다. 이건 고장이 아닙니다. 잠깐 그런 겁니다.

그런데 "1번 실패 = 사망"이면 이 딸꾹질에 멀쩡한 서버가 빠집니다. 그리고 이때 진짜 무서운 일이 시작됩니다.

1. 서버 A가 잠깐 느려짐 → 헬스체크 실패 → 빠짐
2. A가 받던 트래픽이 B와 C로 몰림
3. B가 부하를 못 견디고 느려짐 → 헬스체크 실패 → 빠짐
4. 이제 모든 트래픽이 C로 → C도 즉사
5. 전멸

아무도 진짜로 고장 나지 않았는데 서비스 전체가 죽었습니다. 헬스체크가 죽였습니다. 이걸 연쇄 실패(cascading failure)라고 합니다. 예민한 경보기가 오히려 화재를 만든 셈입니다.

그래서 균형점을 찾는다

실무에서 흔히 쓰는 값은 2~5초 주기에 2~3회 연속 실패입니다. 대략 5~15초의 노출을 감수하는 대신 딸꾹질에는 넘어가지 않는 지점입니다.

마법의 숫자는 없습니다. 이건 트레이드오프를 고르는 일이지 정답을 찾는 일이 아닙니다.

무엇을 물어볼 것인가

마지막으로 중요한 구분이 있습니다. "살아 있나요?"에도 두 가지 뜻이 있습니다.

이 둘은 다릅니다. 서버가 막 켜져서 아직 준비 중이라면, 살아는 있지만 일은 못 합니다. 이때 요청을 보내면 실패합니다. 재시작해도 소용없습니다. 잠깐 트래픽만 빼주면 됩니다.

반대로 서버가 데이터베이스 연결이 끊겨 아무 일도 못 하는데 프로세스만 떠 있다면, "프로세스 살아 있나요?"에는 "네"라고 대답합니다. 로드밸런서는 계속 요청을 보내고, 사용자는 계속 오류를 봅니다. 헬스체크가 있는데도 장애가 안 걷힙니다.

그래서 헬스체크는 "떠 있나"가 아니라 "일할 수 있나"를 물어야 합니다. 좋은 헬스체크는 서버가 실제로 필요한 것들(데이터베이스 연결 등)을 확인하고 답합니다.

직접 해보세요

아래 과제의 로드밸런서는 헬스체크가 꺼져 있습니다. 서버 한 대가 도중에 죽습니다. 먼저 그대로 실행해서, 로드밸런서가 죽은 서버에 계속 요청을 보내는 것을 확인하세요. 그 다음 헬스체크를 켜고 다시 보세요.