나이가 많으시다면 (걱정하지 마세요. 손을 들라고 하지는 않겠습니다) 토요일 아침 만화, 특히 "School House Rock"을 기억하실 수도 있을 겁니다.
이것을 기억한다면, 우리 중 많은 사람이 기관사가 "접합체, 접합체, 너의 기능은 뭐니?"라고 노래하면서 접속사에 대해 배웠거나(또는 수업을 강화했음) 것을 기억할 것입니다.
계속해서 노래해 보세요. 당신은 당신이 원한다는 것을 알고 있죠.
이제, 향수의 골목길로의 이 작은 여행에는 앱 서비스, 특히 로드 밸런싱이 데이터 센터의 결합이라는 것을 설명하는 목적이 있습니다. 하지만 "단어"와 "구문"을 연결하는 대신 "사용자"와 "앱"을 연결합니다.
"and", "but", "nor"라는 단어를 사용하여 문장에서 두 개의 구나 절을 연결하는 것과 같은 방식으로 앱 서비스를 사용하여 사용자(사물이든 사람이든)를 앱(클라우드나 온프레미스에 있든)에 연결합니다.
이에 대한 가장 좋은 예가 부하 분산입니다. 이는 두 가지 관련된 것 사이의 "그리고"와 같은 역할을 하는 "앱 서비스"의 전형적인 예입니다. 사과와 오렌지. 야구와 핫도그. 맥주와 브라트. 부하 분산 프록시는 사용자와 앱 사이에 연결 고리를 제공하여 둘이 연결되도록 보장하고, 이를 통해 비즈니스가 원활하게 운영되도록 합니다. 사용자 Bob을 앱 인스턴스 3에 연결합니다. 그리고 사용자 Alice는 앱 인스턴스 2에 있습니다. 그리고 1에서 4까지. API 버전 2에서 API 백엔드 3으로.
이제 이는 POLB(Plain Old Load Balancing) 에 해당합니다. POLB는 요청을 프록시하고 알고리즘 결정에 따라 올바른 앱 인스턴스를 선택합니다. 또한 URI, 호스트 또는 HTTP 헤더의 값과 같은 애플리케이션 계층 정보를 사용하여 사용자와 앱을 "연결"하는 방법을 결정하는 L7 Load Balancing에도 해당합니다. 이는 데이터 센터에서 중요한 기능이며 최신 애플리케이션을 지원하는 데 필요한 규모(및 가용성)를 달성하는 수단입니다.
이러한 결합 기능은 다양한 DevOps 배포 패턴을 구현하는 데 점점 더 중요해지고 있습니다. A/B 테스트, 블루-그린 배포 , 카나리아 배포 , API 측정 및 API 버전 관리 등 은 모두 특정 시점에 존재하는 특정 비즈니스 및 운영적 요구 사항에 따라 사용자 와 앱을 연결하여 애플리케이션을 지원하는 운영적 배포 패턴의 좋은 예입니다( 참고로 이것이 컨텍스트입니다 ).
최신의 프로그래밍 가능 프록시를 통한 로드 밸런싱이 확장성이나 가용성 그 이상의 의미를 갖는다는 것을 깨닫게 되면 애플리케이션 아키텍처 자체의 일부로서 그 잠재력을 인식하게 됩니다. 즉, 성능을 개선하고, 비즈니스 가치를 추가하고 , 표준화하여 더 낮은 운영 비용과 반복 가능한 배포 프로세스의 이점을 얻을 수 있는 플랫폼을 제공하는 수단으로 활용할 수 있습니다.