부하 분산에 대해 운영진이 알아야 할 3가지
부하 분산. 그것이 필요하고, 그것에 의지하고, 그것을 매일 사용하여 애플리케이션을 확장(그리고 바람직하게는 축소)한다는 것은 일반적으로 인정되는 사실입니다. 이는 수요를 충족하기 위한 확장뿐만 아니라 생산성과 수익을 위해 기업이 의존하는 애플리케이션과 서비스의 지속적인 가용성을 보장하는 데 책임이 있는 중요한 인프라가 되었습니다.
그래서 우리는 이 문제를 다시 살펴봐야 합니다. 로드 밸런싱은 운영 담당자가 점점 더 자주 다루는 전술적인 것이 아니어야 합니다. 운영 담당자는 이제 이러한 마법 같은 서비스를 프로비저닝, 구성 및 배포해야 합니다. 전략적으로 살펴보면 부하 분산을 통해 성능을 향상시키고, 위험을 줄이며, 애플리케이션을 제공하는 데 필요한 리소스를 보다 효율적으로 사용하는 데 도움이 될 수 있습니다. 그들은 종종 강요받는 "배관공"이라는 별명보다 더 똑똑하며, 몇 가지 핵심 사항을 이해하면 운영진이 로드 밸런싱을 사용하여 애플리케이션을 지원하는 방법에 대해 더 많이 생각하는 데 도움이 됩니다.
그럼 더 이상 미루지 말고, 로드 밸런싱에 대해 운영자가 꼭 알아야 할 세 가지 사항을 소개해드리겠습니다.
1. 알고리즘은 상대적입니다
라운드 로빈은 언급해야 할 마지막 알고리즘이라는 점부터 말씀드리고 싶습니다. 하지만 여러분은 이미 알고 계시죠? 그러니 그 부분은 건너뛰고 최소 연결 및 가장 빠른 응답 시간과 같은 더 지능적인 알고리즘을 다루겠습니다. 물론, 이는 성능과 리소스의 효율적인 사용 간의 균형을 맞추는 방법에 대한 전략을 세울 때 훨씬 더 나은 선택입니다. 각 단계는 다음 요청을 받을 애플리케이션 인스턴스(또는 선호하는 경우 컨테이너)에 대한 결정을 내리는 데 중요한 애플리케이션 특성(또는 최소한 애플리케이션을 제공하는 플랫폼의 특성)을 고려합니다. 최소 연결은 인스턴스의 연결이 적을수록 용량이 더 많아지고 지금 당장 요청을 더 잘 처리할 수 있다는 것을 의미합니다. 성능보다 용량 효율성을 선택하는 것입니다.
반면에 가장 빠른 응답 시간은 성능에 따라 요청을 보내는 것입니다. 인스턴스가 빠를수록 더 자주 선택됩니다. 운영상의 공리(부하가 증가하면 성능이 감소)에 따르면 결국에는 부담이 적은 서버가 더 빨리 응답하고, 따라서 선택되게 됩니다. 이는 용량 효율성에 대한 고개 끄덕임을 의미하지만, 이 알고리즘은 언제나 용량보다 성능을 선택합니다.
하지만 이제 알고리즘의 이름을 주목하세요. 가장 적고 가장 빠름 . 이제 두 마리의 거북이가 보도를 따라 경주하고 있다고 생각해 보세요. 둘 다 우리 모두가 "느린" 속도로 달리고 있음에도 불구하고 한 마리 가 더 빠릅니다 . 최소 연결에도 마찬가지입니다. 99와 100 중에서 선택하라고 하면, 99는 확실히 둘 중에서 가장 작은 숫자 입니다.
왜 중요한가
부하 분산이 요청을 관리하는 방식은 성능과 가용성에 직접적이고 즉각적인 영향을 미칩니다. 둘 다 궁극적으로 고객 참여와 직원 생산성에 영향을 미치는 중요한 특성입니다. 부하 분산을 포함한 아키텍처를 최적화하면 더 높은 생산성과 수익 목표를 실현하여 비즈니스 성공을 보장하는 데 도움이 됩니다.
더 자세히 알아보기:
2. 즉시 실패한다는 것은 (종종) 신화입니다
클라우드와 소프트웨어 정의 데이터 센터가 부상한 이래로, 탄력성은 애플리케이션을 확장하는 방법으로 자리 잡았습니다. 탄력성은 리소스(및 예산) 사용을 최적화하는 수단으로 수요에 따른 확장 및 축소를 필요로 합니다. 수요에 따라 확장할 수 있는데 왜 과도하게 공급해야 합니까? 마찬가지로 중복성 원칙에 의존하는 고가용성(HA) 아키텍처는 거의 시대에 뒤떨어졌습니다. (가능성은 낮지만) 기본 앱 인스턴스가 실패하는 경우 대기 모드에서 유휴 리소스를 요구하는 이유는 무엇입니까? 이는 자본과 운영 예산의 낭비입니다! 나가, 나가, 젠장 대기!
주문형 실패와 확장은 아름다운 이론이지만 실제로는 그렇게 간단하지 않습니다. 현실적으로 가상 서버(또는 클라우드 서버, 또는 어떤 용어를 사용하든)를 출시하는 데는 시간이 걸립니다. 귀하(또는 자동화 시스템)가 기본 서버에 장애가 발생하거나 용량이 가득 찰 때까지 다른 서버를 시작하기를 기다린다면 이미 너무 늦은 것입니다. 클라우드 환경에서의 용량 계획은 기존 환경에서 적용되었던 것과 동일한 수학적 방법을 기반으로 할 수 없습니다. 이제 용량 임계값은 수요에 따라 원활하게 확장되기 위해 소비율과 새로운 서버를 시작하는 데 걸리는 시간을 방정식에 반영해야 합니다.
장애 조치에도 마찬가지입니다. 기본이 실패하면 대체품을 출시하는 데 시간이 걸립니다. 사람들이 연결이 끊어지고, 타임아웃이 되거나, 경쟁자나 최신 고양이 비디오 때문에 당신을 버리는 시간입니다. 필요할 때 사용하지 않는 예비 타이어는 낭비처럼 느껴질 수 있지만(보험처럼) 있으면 기쁠 것입니다. 특히 해당 앱이 고객 참여나 수익에 기여하는 경우 몇 분간의 다운타임(및 그에 따른 비용)이 발생할 위험이 있지만, 예비 앱을 준비하는 데 드는 비용보다 훨씬 더 클 수 있습니다.
흥미로운 점은 컨테이너가 놀라울 정도로 빠른 출시 시간을 통해 이러한 문제를 잠재적으로 해결할 수 있다는 것입니다. 가용성, 성능, 비용이 모두 똑같이 중요하다면, 이 세 가지를 모두 균형 있게 조화시키는 측면에서 컨테이너가 가져올 수 있는 가치를 살펴볼 때가 되었을 수도 있습니다.
왜 중요한가
가동 중지 시간은 비용이 많이 듭니다. 가동 중단의 원인은 가동 중단을 피하는 것만큼 중요하지 않습니다. 장애 발생 시에도 올바른 아키텍처와 장애 조치 계획이 실행되어 있는지 확인하는 것은 비즈니스 성공에 중요한 지속적인 가용성을 유지하는 데 필수적입니다.
더 자세히 알아보기:
3. 클라이언트 IP는 실제 클라이언트 IP가 아닙니다.
앱이 개발 단계에서 프로덕션 단계로 넘어갈 때 발생하는 모든 문제 중에서 이 문제는 아마도 가장 흔하고 쉽게 피할 수 있는 문제일 것입니다. 아시다시피 대부분의 로드 밸런싱 서비스(좋은 서비스라면 다 그렇죠)는 프록시 입니다. 즉, 클라이언트는 프록시에 연결하고 프록시는 앱에 연결합니다. 둘 다 TCP를 사용하여 HTTP를 전송하므로 네트워킹 법칙을 따라야 합니다. 소스 IP(클라이언트 IP라고 생각되는 것)는 실제로 프록시의 IP 주소입니다. IP 주소를 기반으로 보안, 인증 또는 측정을 수행하는 경우 이는 심각한 문제를 야기합니다. HTTP 헤더에서 추출한 값이 원하는 값이 아닙니다.
업계에서는 HTTP 사용자 정의 헤더를 활용해 이 문제를 처리하는 방식을 표준화했습니다. X-Forwarded-For 헤더가 여러분이 정말 찾고 있는 것이겠죠. 여기는 프록시가 요청을 전달할 때 실제 클라이언트 IP 주소를 넣는 곳입니다. 안타깝게도 이것은 표준이 아니라 사실상 "우리 모두가 어느 정도 동의한" 표준이므로 확인이 필요합니다.
문제는 당신이 찾고 있는 클라이언트 IP 주소가 당신이 생각하는 주소가 아니라는 것입니다. 따라서 개발자는 해당 정보가 필요한 앱이 프로덕션 환경으로 옮겨가 갑자기 작동을 멈추기 전에 이를 고려해야 합니다.
이것이 비즈니스에 중요한 이유
운영 환경에서 문제를 해결하는 데는 개발 또는 테스트 환경에서 문제를 해결하는 데 비해 비용이 훨씬 많이 듭니다. 문제를 찾아 해결하는 데 걸리는 시간은 프로젝트 일정에 부정적인 영향을 미치고, 애플리케이션 분야에서 경쟁 우위와 비즈니스 성공에 매우 중요한 제품 출시 시간을 방해합니다. 이러한 일반적인 문제를 인식하고 개발 또는 테스트 단계에서 해결하면 보다 빠르고 원활하게 프로덕션과 시장 출시가 보장됩니다.
더 자세히 알아보기: