로드밸런서, 분산보다 상태 검사가 먼저입니다

분산 알고리즘보다 상태 검사가 먼저 작동합니다

로드밸런서를 붙이는 목적은 트래픽을 나누는 것이지만, 실제로 장애를 막아 주는 기능은 상태 검사입니다. 상태 검사가 잘못 설정되면 죽은 서버로 계속 요청이 가거나, 멀쩡한 서버가 빠져 버립니다. 그래서 설계 순서는 1단계 상태 검사 경로 정의, 2단계 판정 조건 설정, 3단계 분산 방식 선택입니다. 상태 검사 경로는 단순히 응답만 돌려주는 주소가 아니라, 서비스가 실제로 일할 수 있는지 보는 주소여야 합니다. 데이터베이스 연결이 끊겨도 통과하는 경로를 쓰면 상태 검사는 늘 성공하고, 사용자만 오류를 봅니다.

판정 조건 네 값을 서비스 기동 시간에 맞춥니다

판정 조건은 네 값으로 이뤄집니다. 검사 주기, 응답 제한 시간, 연속 실패 횟수, 연속 성공 횟수입니다. 이 값들의 곱이 '장애를 인지하는 시간'과 '복구를 인지하는 시간'을 결정합니다. 예를 들어 주기 10초에 연속 실패 3회면 장애 인지까지 최대 30초가 걸립니다. 서비스 기동에 40초가 걸리는 애플리케이션이라면 새 서버가 투입된 직후 연속 실패로 판정돼 빠질 수 있으므로, 투입 후 유예 시간을 따로 둬야 합니다. 그래서 설정 전에 기동 시간을 실제로 재서 적습니다. 재지 않고 기본값을 쓰면 배포할 때마다 서버가 들어왔다 나가는 현상이 생깁니다.

서버 한 대가 빠질 때의 여유를 계산합니다

학습용 가정으로 계산합니다. 가정값은 서버 4대가 각각 초당 100건을 처리하고 평시 트래픽이 초당 240건이라고 두겠습니다. 총 처리 능력은 400건이고 사용률은 60퍼센트입니다. 1대가 빠지면 능력은 300건으로 줄고 사용률은 80퍼센트가 됩니다. 여기까지가 중간 계산값입니다. 최종 판단은 2대가 동시에 빠지는 경우까지 봐야 합니다. 2대가 빠지면 능력 200건으로 트래픽 240건을 받지 못해 초당 40건이 대기하거나 실패합니다. 따라서 이 가정에서 안전한 최소 대수는 4대가 아니라 5대입니다. 5대면 2대가 빠져도 300건으로 240건을 처리할 수 있습니다.

세션을 서버에 들고 있으면 분산이 깨집니다

결론을 뒤집는 조건은 서버에 상태를 보관하는 구조입니다. 로그인 세션을 서버 메모리에 두면 같은 사용자를 같은 서버로 계속 보내야 하고, 그러면 분산이 고르지 않게 되며 서버가 빠질 때 그 사용자들은 로그아웃됩니다. 해결 순서는 세션을 공유 저장소로 옮기고, 고정 연결 설정을 끄고, 그다음에 분산 방식을 고르는 것입니다. 두 번째 조건은 긴 연결입니다. 파일 업로드나 실시간 연결이 길게 유지되면 서버를 뺄 때 연결 종료 대기 시간을 넉넉히 둬야 합니다. 이 값을 0에 가깝게 두면 배포할 때마다 업로드가 끊어집니다.

클라우드 비교 실행 전 점검표

• 상태 검사 경로가 실제 작업 가능 여부를 보는지 확인했다
• 서비스 기동 시간을 재고 투입 유예 시간을 설정했다
• 2대가 동시에 빠지는 경우까지 최소 대수를 계산했다
• 세션을 공유 저장소로 옮기고 연결 종료 대기를 설정했다