POLB(Plain Old Load Balancing)를 넘어서다
확장성은 비즈니스와 애플리케이션 모두에 중요한 역량입니다. 비즈니스 측면에서 운영 확장은 새로운 앱 경제와 끊임없이 이어지는 열광적인 배포 상태를 실현하는 데 중요합니다. 애플리케이션 측면에서 확장성은 소비자와 기업 인구 모두의 성장을 지원하는 방법으로, 두 집단 모두에게 최고의 성능과 가용성을 보장합니다.
확장성의 핵심은 부하 분산입니다. 1990년대 중반부터 로드 밸런싱은 점점 더 커지는 서버, 네트워크, 애플리케이션 및 서비스 팜에 작업 부하를 분산시켜 애플리케이션을 확장하는 방법이 되었습니다.
예전에는 로드 밸런싱이 네트워크에 관한 것이었습니다. 네트워크를 확장하는 기존 기술과 프로토콜을 기반으로, 로드 밸런싱은 작업 부하를 분산하는 데 사용할 수 있는 클라이언트-서버 통신 측면에 초점을 맞췄습니다. 플레인 올드 로드 밸런싱(POLB)이 탄생했습니다.
효과가 있었고, 잘 작동했습니다. POLB가 없었다면 우리가 아는 웹이 탄생했을지 아는 것은 거의 불가능할 것입니다. 오늘날의 기업과 소비자 집단을 지원하는 데 있어서도, 그리고 내일을 지원하는 데 있어서도 여전히 중요했습니다.
2000년대 초반에 로드 밸런서의 전략적 위치로 인해 다른 애플리케이션 경험을 향상시키는 기능으로 확장할 수 있는 완벽한 플랫폼이 되었습니다. 결국 애플리케이션 가속, 최적화, 캐싱 및 압축이 추가되었습니다. 보안 역시 이 플랫폼으로 자리를 잡을 것이며, 네트워크 내에서 그 위치가 너무나 완벽해서 무시할 수 없을 것입니다. 애플리케이션의 게이트키퍼로서, 애플리케이션 트래픽을 검사, 추출, 수정, 변환하는 기능을 통해 보안과 성능 모두에 적용되는 고유한 통찰력을 제공합니다.
2000년대 초반에 우리는 POLB를 넘어 다른 분야로 진출했습니다. 로드 밸런서는 POLB로 앱을 확장하던 것만큼 안전하고 빠르며 가용성이 높은 앱을 제공하는 데 능숙한 애플리케이션 제공 플랫폼이 되었습니다.
ADC(애플리케이션 전송 컨트롤러)로 알려진 이러한 최신 플랫폼은 POLB 기능뿐 아니라 오늘날 앱을 배포하고 전송해야 하는 사람들에게 매우 귀중한 기능을 제공합니다.
네트워크 팀이 아닌 설계자와 운영자가 이러한 역할을 맡는 경우가 점차 늘고 있습니다.
그러한 변화는 지난 10년 동안 등장한 여러 기술에 의해 주도되었습니다. 애자일에서 클라우드, DevOps, 모바일에 이르기까지 오늘날의 모범 사례는 일부 애플리케이션 서비스를 네트워크에서 애플리케이션 영역으로 옮기고 있습니다.
그리고 확장성에 대한 책임이 네트워크에서 아키텍트와 운영으로 옮겨가는 동안 ADC는 마치 1990년대에 갇힌 것처럼 배포되고 있습니다. POLB로 취급될 경우 성능과 보안을 개선하여 설계자와 운영자에게 제공하는 가치의 대부분은 무시됩니다(더 정확히 말하면 랙에 올려두는 것이 좋습니다).
이는 일반적으로 현재 애플리케이션 확장을 담당하는 아키텍트와 운영 팀이 ADC가 자신들을 위해 무엇을 할 수 있는지, 더 중요하게는 앱과 아키텍처에 대해 잘 알지 못하기 때문입니다. 이제 우리가 그것을 바꾸고 POLB를 넘어서야 할 때입니다.
POLB 너머: L7 LB 프록시
POLB의 목표는 간단했습니다. 바로 가용성이었습니다. 중복성을 기반으로 HA(고가용성) 아키텍처를 구현하든 N+1 확장 아키텍처를 사용하든 목표는 동일했습니다. 무슨 일이 있어도 웹사이트(또는 앱)를 계속 작동시키고 사용 가능하게 유지하는 것입니다.
오늘날 목표는 여전히 가용성이지만 효율성과 민첩성이 결합되었습니다. 이 세 가지 모두 현대 비즈니스의 핵심 특징이며, 이를 위한 중요한 애플리케이션을 지원하는 아키텍처입니다. 하지만 이를 달성하려면 POLB를 넘어 애플리케이션 라우팅과 부하 분산의 세계로 나아가야 합니다. 이를 통해 앱 아키텍처와 인프라 모두에서 중요한 효율성을 실현할 수 있습니다. 이러한 기능은 네트워크 스택의 7계층(애플리케이션 계층)을 기반으로 하며, 최신 아키텍처에서는 이는 HTTP를 의미합니다.
L7 LB 프록시는 연결 부하, 응답 시간, 애플리케이션 상태와 같은 애플리케이션 변수에 따라 부하를 분산할 수 있을 뿐만 아니라 URL, HTTP 헤더, 심지어 HTTP 메시지 내의 데이터에 따라 디스패치(라우팅)할 수도 있습니다.
다양한 유형의 애플리케이션 계층 데이터를 구문 분석, 추출 및 처리할 수 있는 L7 로드 밸런서는 오늘날 다음을 포함한 다양한 방식으로 애플리케이션 및 마이크로서비스 아키텍처에 참여하고 이를 증강할 수 있습니다.
- 데이터 분할(샤딩) 아키텍처
- 복잡한 URL 전송
- 응답 헤더 조작
- 백엔드 데이터 기반 동적 라우팅
- 기능 분해에 의한 스케일링
- API 측정 및 액세스 제어
POLB 너머: 보안
L7 LB는 서비스를 제공하는 애플리케이션보다 논리적으로 상류에 위치하므로 모든 요청과 응답을 볼 수 있습니다. 즉, 원하는 애플리케이션으로 진행하기 전에 요청에 대한 다양한 확인 및 균형 조정을 수행할 수 있다는 의미입니다. 이러한 견제와 균형은 악성 트래픽을 감지하고 거부하고, 이로 인해 백엔드 애플리케이션의 안정성, 가용성 및 무결성에 부정적인 영향이 미치지 않도록 하는 데 필수적입니다.
하지만 이는 단순히 나쁜 트래픽이 서버에 도달하는 것을 막는 것 이상의 의미가 있습니다. 즉, 나쁜 행위자를 막는 것입니다. 즉, 유효한 자격증이 없는 사람뿐만 아니라 원래 자신에게 속하지 않은 자격증을 사용하는 사람까지 식별할 수 있어야 한다는 의미입니다. 도난된 자격 증명으로 인한 침해 사례가 증가함에 따라 액세스 제어의 역할이 커지고 있습니다. 클라우드 역시 SaaS 기반 애플리케이션에 저장된 기업 데이터에 대한 액세스 권한을 부여하는 버려진 계정과 테스트 계정으로 인한 잠재적 위험을 줄이기 위해 애플리케이션 전반에서 자격 증명을 글로벌하게 관리해야 하는 시급성을 다시 불러왔습니다. ID 연합은 단순한 생산성 향상 전략이 아니라 전체 기업 보안 전략의 핵심 전략이 되었습니다.
L7 LB에 추가할 수 있는 기능에는 클라이언트의 동작 및 ID를 분석하는 기능과 클라이언트와 백엔드 서비스 간에 교환되는 메시지의 실제 내용을 분석하는 기능이 모두 포함됩니다. 이를 통해 L7 LB는 다음을 포함한 기능을 수행할 수 있습니다.
- 7계층(앱) DDoS 보호
- 웹 앱 방화벽
- OWASP 상위 10개
- 앱 접근 제어
- 연방 ID
POLB 너머: 최적화
성능은 애플리케이션 성공, 나아가 비즈니스 성공에 중요한 요소입니다. 초기에는 기업들이 애플리케이션 앞에 여러 애플리케이션 가속 솔루션을 배포하여 전달 프로세스를 가속화했습니다. ADC는 이러한 동일한 솔루션을 선택적(추가) 구성 요소로 통합했지만 결국 이러한 기능을 핵심 부하 분산 기능의 일부로 직접 통합했습니다. 이는 애플리케이션과 서비스 제공에 중점을 두면서 성능이 얼마나 중요한지를 반영합니다.
즉, L7 LB는 성능 향상에 초점을 맞춘 다양한 기능과 특징을 갖추고 있습니다. 이러한 기능 중 일부(특히 클라이언트에게 전송되는 앱 응답에 따라 작동하는 기능)는 콘텐츠에 초점을 맞춥니다. 이 중 대부분은 콘텐츠를 더 작게 만드는 데 사용되는 핵심 개발자 기술이고, 다른 일부는 클라이언트와 서버 간에 필요한 왕복 횟수를 줄이는 데 중점을 두고 있습니다.
또한, L7 프록시는 콘텐츠 최적화에만 초점을 맞추는 것이 아니라 데이터베이스 부하 분산 기술과 메모리 내 캐시(예: memcached) 통합을 포함한 성능 중심 아키텍처의 핵심 지원 요소로, 전반적인 애플리케이션 성능을 개선한다는 점도 중요합니다. 이러한 아키텍처를 구현하는 데 적합한 L7 프록시는 일반적으로 분산 및 라우팅을 맞춤화할 수 있는 기능을 제공하는 데이터 경로 스크립팅 언어 를 통해 활성화됩니다.
다른 기능은 성능을 개선하기 위한 방법으로 백엔드 서버의 오버헤드를 줄이는 데 중점을 두고 있으며, 성능 임계값에 따라 부하를 분산할 수 있습니다.
L7 LB의 기능과 성능을 최적화하는 것은 다음과 같습니다.
클라이언트 측(응답 최적화) |
백엔드 서버 측 |
• 최소화 • HTTP 압축 • 버퍼링 • 스크립트 집계 • SSL 오프로드 |
• TCP 멀티플렉싱 • 캐싱 • 성능 기반 부하 분배 • 자동 확장성 |
POLB 너머: 관리하다
인프라를 애플리케이션 아키텍처에 보다 통합하려면 반드시 CI/CD 파이프라인에 통합할 수 있어야 합니다. 즉, 자동화된 릴리스 및 제공 전략을 실행할 수 있는 최신 DevOps 및 Agile 관련 방법론과 툴셋을 지원한다는 의미입니다.
이러한 목표를 달성하기 위해 L7 LB는 관리할 수 있는 API뿐만 아니라 오늘날의 까다로운 일정과 예산을 충족시키기 위해 지속적인 피드백과 전달을 보장하기 위해 모니터링하고 배포할 수 있는 수단도 제공해야 합니다.
F5는 다음을 포함하여 L7 LB 인프라의 프로비저닝, 배포, 관리 및 모니터링을 위한 다양한 프로그래밍 옵션을 지원합니다.
POLB 너머: 시간이다
POLB 및 L7 LB와 같은 애플리케이션 인프라에 대한 책임이 네트워크 팀에서 애플리케이션 및 운영 팀으로 이전되는 데에는 다양한 이유가 있습니다. 더 짧은 제공 일정으로 더 많은 앱을 요구하는 비즈니스 요구에 대한 대응책으로 Agile 또는 DevOps를 도입하든, 그 어느 때보다 빠르게 확장해야 하는 필요성이든, POLB를 넘어서면 최신 CI/CD 파이프라인에 맞는 단일의 관리 가능하고 프로그래밍 가능한 플랫폼에서 최신 앱과 제공 아키텍처를 지원하는 데 필요한 보안, 성능 및 가용성에 대한 더 다양한 옵션이 제공됩니다.
이제 POLB를 넘어서서 귀하의 도메인에 점점 더 많이 포함되는 인프라를 활용할 때입니다.
