클라우드 아키텍처 NGINX Plus를 사용한 3가지 사례
클라우드 아키텍처 로 전환하면 여러 가지 이점과 함께 몇 가지 단점이 있습니다. 일부 기업의 경우 회사 방화벽 외부에서 데이터를 호스팅 하는 것은 거래를 방해하는 요소입니다. 그러나 대부분의 경우 자신의 하드웨어를 관리할 필요가 없다는 이점이 절대적인 통제력 상실과 같은 단점보다 훨씬 큽니다. 최근 연구에 따르면 이것이 IT 책임자들에게 점점 더 분명해지고 있으며, 향후 2년 동안 IT 기업의 지출 1/3이 클라우드에 사용될 것으로 예상됩니다.
클라우드로의 전환을 고려 중이거나 그렇지 않더라도 지금이 애플리케이션 아키텍처에 대해 생각해 볼 좋은 시기입니다. 잘 알려진 문제와 함께 애플리케이션을 맹목적으로 클라우드로 마이그레이션하는 대신 이 새로운 유형의 환경에서 보다 유연하게 작동하도록 애플리케이션 스택을 업데이트하는 것이 어떻습니까? 애플리케이션 제공 전략은 재평가 프로세스를 시작하는 데 매우 유용합니다.
On Premise에서 애플리케이션을 호스팅 하는 경우 하드웨어 Application Delivery Controller(ADC)를 사용하고 있을 가능성이 큽니다. 하드웨어 ADC는 On Premise 배포 내에서 잘 작동할 수 있지만 하드웨어를 클라우드로 가져올 수는 없습니다. 대부분의 레거시 하드웨어 ADC 공급업체는 제품의 가상 버전을 보유하고 있지만 클라우드로 전환하는 경우 클라우드를 염두에 두고 작성된 최신 ADC를 사용해 보십시오.
NGINX Plus는 최신 웹에서 탄생한 엔터프라이즈급 소프트웨어 로드 밸런서입니다. NGINX Plus는 절대 사용하지 않을 기능에 대해 비용을 지불하지 않고도 애플리케이션을 완벽하게 제공하는 데 필요한 모든 기능을 갖춘 가벼운 제품입니다. NGINX Plus는 대역폭이나 SSL 제한 없이 하드웨어 ADC 비용의 일부만으로 사용할 수 있습니다.
클라우드 컴퓨팅에 대한 조사를 시작하는 데 도움이 되도록 다음은 NGINX Plus의 기능을 활용하는 몇 가지 클라우드 아키텍처 입니다.
목차
1. 클라우드 아키텍처 – Simple Cloud Bursting
2. 클라우드 아키텍처 – Local Load Balancing
3. 클라우드 아키텍처 – Global Load Balancing
4. 클라우드 아키텍처 – 결론
1. 클라우드 아키텍처 – Simple Cloud Bursting
모든 것을 한 번에 클라우드로 마이그레이션하는 것이 너무 위험하다고 생각되는 경우, 하이브리드 구축을 운영 중단이 적은 접근 방식으로 고려하십시오. 이러한 유형의 배포에서는 On-Premise와 클라우드 서비스를 모두 사용하여 애플리케이션을 제공합니다.
NGINX Plus의 최소 시간 Load Balancing 알고리즘을 사용하면 모든 On-Premise 서버가 사용 중일 때 트래픽이 클라우드로 전송되는 “Cloud Bursting” 배포를 생성할 수 있습니다.
NGINX Plus는 로컬 서버가 모두 사용 중일 때 클라우드로 트래픽을 보냅니다.
최소 시간(Least Time) 알고리즘을 사용하여 NGINX Plus는 각 서버에 대한 두 가지 지표(현재 활성 연결 수와 과거 요청에 대한 가중 평균 응답 시간)을 수학적으로 결합하고 값이 가장 낮은 서버로 요청을 보냅니다. 최소 시간(Least Time)은 로컬 서버가 더 빨리 응답하기 때문에 더 많은 요청을 보내는 경향이 있습니다. 로컬 서버가 로드되어 네트워크 지연 시간이 증가하여 클라우드 서버가 더 빨리 응답하면 NGINX Plus는 요청을 클라우드 서버로 전송하기 시작합니다. 로컬 서버의 로드가 다시 줄어들면 NGINX Plus는 대부분의 요청을 다시 로컬 서버로 보냅니다.
2. 클라우드 아키텍처 – Local Load Balancing
많은 퍼블릭 클라우드 공급업체는 전 세계에 걸쳐 지역 데이터 센터를 보유하고 있으며 일부 또는 전체에서 애플리케이션을 호스팅 할 수 있습니다. 예를 들어 Amazon Web Services는 북미, 남미, 유럽 및 아시아에 걸쳐 9개의 데이터 센터를 보유하고 있습니다. 내결함성을 위해 클라우드 공급업체는 각 지역 데이터 센터에 “가용성 영역”을 프로비저닝합니다. 가용 영역에는 별도의 전원, 네트워킹, 냉각 등을 갖춘 물리적으로 격리된 자체 하드웨어 랙이 있습니다. 예를 들어 정전 등으로 하나의 가용 영역에 장애가 발생하면 계속 실행되는 가용 영역이 느슨해질 수 있습니다. 가용성 영역 간에 애플리케이션을 복제하여 애플리케이션을 고가용성으로 만들어 지연을 복구할 수 있습니다.
가용성 영역 간에 애플리케이션을 복제하면 고가용성이 제공됩니다.
위의 클라우드 아키텍처 다이어그램에서 클라우드 공급업체의 기본 Load Balancer(Amazon Web Services의 ELB, Google Cloud Platform의 Load Balancer 또는 Microsoft Azure의 Azure Traffic Manager)는 서로 다른 가용 영역에 트래픽을 분산시킵니다. 각 가용 영역 내에서 NGINX Plus는 애플리케이션 서버에 Load Balancing 합니다. NGINX Plus 이면의 애플리케이션은 Monolith, Microservices 기반 애플리케이션 또는 그 중간일 수 있습니다.
3. 클라우드 아키텍처 – Global Load Balancing
여러 가용 영역에서 애플리케이션을 복제하면 지역 내에서 뛰어난 고가용성을 제공합니다. 다음 단계는 여러 지역에서 애플리케이션을 호스팅 하는 것입니다. 애플리케이션을 사용자에게 더 가깝게 이동하면 네트워크 지연 시간의 영향이 줄어들어 전반적으로 더 나은 사용자 환경을 얻을 수 있습니다. 전 세계적으로 분산된 애플리케이션을 구축하는 방법에는 여러 가지가 있습니다. 한 가지 일반적인 방법은 지리적 위치 기반 DNS(GeoDNS) 솔루션을 사용하는 것입니다. GeoDNS 솔루션을 사용하면 도메인에 대한 권한 있는 DNS 서버가 응답을 구성할 때 클라이언트 위치를 고려하여 클라이언트를 가장 가까운 데이터 센터로 보냅니다.
NGINX Plus는 GeoDNS와 함께 전 세계적으로 분산된 애플리케이션을 생성합니다.
Amazon에서 Route 53과 같은 많은 GeoDNS 솔루션을 사용할 수 있습니다. 이들을 NGINX Plus와 결합하면 전 세계적으로 분산되고 확장 가능한 애플리케이션을 만들 수 있습니다. 위의 다이어그램에서 GeoDNS는 캘리포니아의 사용자를 미국 서부 데이터 센터로 안내하는 반면, 뉴욕의 사용자는 미국 동부 데이터 센터로 안내합니다. 각 데이터 센터 내에서 NGINX Plus는 수신 트래픽을 애플리케이션 서버에 분산시킵니다.
4. 결론
클라우드로의 이전을 고려하고 있다면 애플리케이션 제공 전략도 재고하는 것이 좋습니다. 하드웨어 ADC는 On-Premise 배포에 적합할 수 있지만 클라우드 아키텍처의 일부가 될 수는 없습니다. 대부분의 하드웨어 ADC 공급업체는 어플라이언스의 가상 버전을 제공하지만 불필요하게 비싸기 때문에 클라우드에서 필요하지 않은 기능에 대해 비용을 지불해야 합니다. 또한 가상 버전은 일반적으로 일부 클라우드에서만 지원되는 반면 NGINX Plus는 모든 클라우드에서 실행됩니다.
NGINX Plus는 클라우드에서 실행되도록 설계된 소프트웨어 로드 밸런서입니다. 가상 하드웨어 ADC 비용의 일부로 사용할 수 있지만 실제로 필요한 모든 기능을 갖추고 있습니다.
NGINX Plus를 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.
댓글을 달려면 로그인해야 합니다.