[아키텍처 가이드]CDN과 로드밸런서를 활용한 부하 분산 ­

>

안녕하세요 네이버 클라우드 플랫폼입니다.향후 본 블로그에서는 네이버 클라우드 플랫폼이 제공하는 서비스의 레퍼런스 아키텍처에 대해 사용자 분들께 알기 쉽게 설명해 나갈 예정입니다.■ 공식 홈페이지에서 더 많은 레퍼런스 아키텍처를 알아보세요! \https_s://www.ncloud.com/intro/architecture 이번 포스팅에서는 'CDN과 로드 밸런서를 활용한 부하 분산'을 주제로 레퍼런스 아키텍처를 활용하는 방법에 대해 알아보겠습니다.

"Myservice.com"은 PC 및 모바일 게임을 주제로 하는 웹사이트를 운영하고 있으며, 게임 관련 이미지, 동영상을 업로드, 다운로드하여 주제별로 게시할 수 있는 소규모 Site로 아래와 같은 아키텍처 구조를 유지하고 있습니다.

>

Myservice.com은 접속자 수가 초기에 비해 3배 증가하였으며 사용자의 콘텐츠 업로드가 늘어나면서 대용량 파일 처리 횟수가 증가하였습니다. 또한 규모가 커지면서 행사기간 중 사용자의 집중현상이 심해져 웹사이트 접속불가 및 파일 다운로드 속도가 느려져 고객 불만이 늘고 있습니다. Myservice.com 가 가지고 있던 문제점을 정리하면 다음과 같습니다. - 서버(web, app server) 부하로 인한 장애 발생: 네트워크 트래픽이 특정 서버에 집중되어 트래픽 분산이 필요 - 느린 페이지 로드 속도로 인한 고객 이탈: 첫 페이지 내에 로드해야 하는 고용량 이미지 파일이 많아 웹 페이지의 로드 속도가 느리고 개선 필요 - 대용량 파일 다운로드, 스트리밍 시 느린 속도로 인한 사용자 불만 제기: 동시에 많은 사용자가 동일한 콘텐츠에 접속하고 서버 부하로 인한 속도 저하 현상 발생 Myservice.com 운영을 담당하는 백 대리는 '웹 사이트로의 부하 분산 아키텍처'를 주제로 한 네이버 플랫폼이 제공되게 되었습니다. www.ncloud.com/intro/architecture/4)

>

레퍼런스 아키텍처 중 CDN과 Load Balancer를 활용한 아키텍처에서도 "CDN 서비스에 의한 부하 분산"에 대해 주목하게 되었는데, 그 아키텍처는 다음과 같습니다.​

>

백 대리는 해당 아키텍처를 조사하던 중 Myservice.com이 운용하고 있는 웹 Server와 Application Server, DB 서버로 분리돼 있는 3tier 구조로 동일하지만 로드 밸런서, CDN이라는 두 가지 차이를 발견했습니다.

>

먼저 발견한 점은 Web Server와 App Server 사이에 위치한 로드 밸런서에 의해 서버 부하를 분산하도록 설계되어 있다는 점이었습니다. Web Server 3대, App Server 2대에 인입되는 트래픽을 로드 밸런서를 도입하면 사전에 설정한 로드 밸런서가 분기하는 방식(Round Robin, Least Connection, Source IP Hash)에 따라 분산 처리가 가능합니다. 백 대리는 현재 운용중인 웹 Server와 App Server의 성능 및 Spec이 동일하게 구성되어 있으며, Least Connection 방식의 분산 방식을 선택하여 운영하기로 하였습니다. 로드밸런서가 분기하는 방식은 다음과 같습니다.

즉, 로드 밸런스에 접속된 서버 중 특정 서버에 장애가 발생할 경우 자동으로 다른 서버에 부하를 분산시켜 높은 안정성을 보장하게 됩니다. 아래 그림과 같이 총 3대의 웹 서버가 로드 밸런서를 통해 트래픽을 처리하고 3번째 서버가 장애 발생 시 로드 밸런서는 나머지 정상적인 2대의 서버에 트래픽을 처리함으로써 장애 없는 서비스 구현이 가능합니다.​

>

로드 밸런서의 주된 기능은 아래와 같습니다. 1) SSL 인증 설정-CA에서 발급받은 SSL 인증서를 Certificate Manager에 등록하여 적용 가능 2) Load Balancer 모니터링-Concurrent Connection, Connection Per Second, Traffic 등의 모니터링 항목 제공 3) 세션 관리-Connection idle timeout, HTTP Keep-alive 설정 가능 4) 다양한 서버 부하 분산 방식 제공-Round Robin, Leace Con Server의 프로그램에도 대응하여 정상적으로 처리할 수 있습니다.

백 대리는 로드 밸런서의 도입과 함께, CDN에의 도입에 대해서도 도입시에 어떠한 효과가 있는지, 왜 도입이 필요한가 하는 의문이 있었습니다. 여기서 간단하게 CDN이 왜 필요한지 생각해보려고 합니다.

CDN 도입 전에는 사용자가 브라우저를 통해 Http(http_s) 프로토콜에서 사용자의 모든 요청 중 Static Contents에 대해 Web Server를 통해 결과를 리턴하게 됩니다. 요청에 대한 답변은 HTML 파일이라는 텍스트 데이터와 이미지, 동영상 등의 바이너리 데이터로 구성됩니다. 일반적인 3 Tier 구조의 아키텍처에서 Static Contents의 경우 데이터 갱신 빈도가 낮기 때문에 WAS나 DB를 거치지 않고 Web Server가 리턴하도록 동작합니다. 그러나 사용자의 요청이 증가하고 트래픽이 급격히 증가하거나, 컨트ents의 양이 늘어난 경우 웹 Server의 부하가 집중되어 서비스 안정성이 저해되고, 장애가 발생할 수 있습니다. 이때 CDN 도입으로 웹 Server의 부하를 줄일 수 있습니다.

>

CDN란(Content Delivery Network, CDN)으로, 컨텐츠의 신속하고 효율적인 전달을 서포트하는 "컨텐츠 전달 네트워크"를 의미합니다. 분산되어 있는 캐시 서버로 콘텐츠를 옮겨놓고 사용자의 요청이 있을 때 사용자의 가장 가까운 서버에서 해당 콘텐츠를 전달하는 용도로 사용합니다.

>

백 대리가 운영하고 있는 myservice.com의 경우 게임 관련 이미지와 동영상 등의 콘텐츠가 업로드되어 웹사이트 내에 보관되어 있는 Static Contents가 서서히 증가하고 있는 상황입니다. 이러한 Static Contents의 경우 자주 조회, 다운로드, 업로드에 대한 요구가 늘어날 경우 웹 Server에 부하를 가져옵니다. CDN 도입 시 신속한 콘텐츠 제공 속도는 매우 중요합니다. Static Contents에 대해서 웹 Server가 아닌 CDN을 통해서 사용자의 위치에 가까운 곳에 있는 CDN Cache Server에서 데이터를 리턴합니다. 예를 들어, 서울에 있는 사용자는 서울에 있는 Edge 서버에서, 부산의 사용자는 부산 Edge 서버에서 이용하고 사용자가 분산된 서버에서 이용하는 효과가 있습니다. 아래는 CDN 사용 시 속도 비교를 위해 CDN을 통해 이미지 파일을 액세스했을 때와 원본 서버(Object Storage 사용)에 직접 액세스했을 때의 속도를 비교한 데이터입니다. Naver Cloud Platform Global CDN으로 15MB 파일에 대한 3회 접속 시 평균값입니다. CDN 사용 시 원본 서버에 직접 액세스 할 때보다 소요 시간이 1/6로 단축되는 것을 볼 수 있습니다. (사용자의 네트워크 접속 환경이나 통신사 사정에 따라 결과가 달라질 수 있습니다.)

>

이렇게 웹스ite 운영자의 입장에서는 웹 Server에만 집중되어 있던 Static Contents에 대한 부하를 분산하여 안정된 시스템을 유지할 수 있습니다. 또한 Web Site 방문자 입장에서는 Static Contents에 대한 다운로드에 대해 가까운 Edge Server를 통해 서비스되므로 더 빠른 속도로 이용할 수 있습니다. 예를 들어 첫 번째 사용자의 경우 아직 복사된 내역이 에디트 서버에 없는 Origin인 Object Storage에서 이루어지며, 총 100ms의 속도가 걸리면(Cache Miss), 두 번째 사용자부터는 CDN에 복사된 내역에서 복사할 수 있는 90ms를 절감한 10ms의 속도로 서비스 이용이 가능합니다. (Cache hit)

>

CDN은 HTML, CSS, 자바스크립트, 이미지, 게임 설치 파일, 매뉴얼 등의 Static Contents에 대한 웹 캐싱과 다운로드 서비스를 제공합니다. 또한미디어콘텐츠의끊임없는스트리밍서비스등여러분야에서활용하고있습니다.

>

Myservice.com의 경우 홈페이지 구성요소에 대해 살펴본 결과, Image가 약 67%를 차지하고 있어 이미지에 대한 빠른 로드가 필요한 상황이었기 때문에 페이지 내에서 사용되는 고용량의 이미지에 대해 CDN을 이용하여 페이지의 로드속도를 개선하고 느린 웹페이지 접속으로 인한 사용자의 이탈을 방지할 수 있었습니다.

>

본 레퍼런스 아키텍처에서는 Object Storage를 Origin으로 구성하고 버킷 및 파일 단위로 권한 관리가 가능하기 때문에 지정한 사람에게 버킷 또는 파일을 공유할 수 있습니다. Object Storage는 비용 효율이 좋고, 사용량을 예측할 수 없는 경우, 스토리지를 GB~PB 단위로 사업 규모에 의해서 확장할 수 있어 확장성이 좋습니다. 이처럼 무한대의 저장 공간과 높은 가용성을 가진 스토리지를 이용하여 서비스를 제공하면 높은 안정성을 가진 서비스를 제공할 수 있으며 원본에서 Object Storage를 활용하면 CDN+<-> Object Storage 간에 발생하는 네트워크 전송 요금은 무과금 처리됩니다.또한 별도로 Origin 서버를 관리하고 있는 경우에는 Custom Origin 지정이 가능하고 도메인 단위로 지정하는 것이 좋습니다.

>

醫웹사이트의 콘텐츠가 가까운 데이터센터에서 제공되기 때문에 페이지의 로드속도가 향상된 국내 모든 통신네트워크를 기반으로 CDN Edge 서버가 구축되어 있어 특정 회선문제 발생 시 우회 가능한 안정적인 서비스입니다.3대 용량 트래픽에 대해 고객에게 안정적이고 빠른 전달 가능 트래픽에 대한 제한 없이 100GPS 이상 사용 시 사전에 고객센터를 통해 예상되는 트래픽량에 대해 사전 요청을 주시면 대용량 트래픽을 수용할 수 있도록 사전 증설을 실시하고 모니터링을 통해 안정적인 트래픽을 빠르게 전달할 수 있도록 지원합니다.醫 분산된 CDN 서버의 사용으로 단일 중앙 서버에 집중할 수 있는 대역폭 분산 Static Contents의 요청에 대해 CDN에 분기하여 웹 서버의 부하를 분산합니다.3콘텐츠의 글로벌 가용성 향상 웹 서비스의 글로벌 확장 시 GCDN 상품을 활용하면 전 세계에 분산된 글로벌 Edge 서버로 해외 사용자에게 빠르게 콘텐츠를 전달합니다.1 콘텐츠 보안 기능(HTTPS 발송 및 SSL 인증서 설정, Secure-Token 기반 보안 URL 사용) HTTPS 발송을 위해 SSL 인증서를 등록하면 원본 서버와도 HTTPS로 통신하며 콘텐츠 전송경로로 보안이 강화됩니다. 또한 Secure-Token을 통해 인가된 접근에만 콘텐츠를 전달하도록 설정할 수 있습니다. 1 대시보드에 의한 사이트 트래픽, 대역폭 사용량 등 상세한 사용량 분석 대시보드를 통하여 CDN 운영 및 모니터링에 필요한 다양한 지표(사이트 트래픽, 대역폭 사용량, 요청수, 요청비 Cachehit, 응답코드(2xx, 3xx, 4xx, 5xx)별 건수, 원본 서버 응답코드(2xx, 3xx, 5xx)별 건수를 확인하여 CDN 활용률을 높일 수 있습니다. ​

원본 서버에서 Query String에 관계없이 동일한 콘텐츠를 응답할 경우 "사용"에 선택해서 URL에 포함된 Get 파라미터를 제거하여 캐싱 효율을 높이고 원본 요청과 부하를 줄일 수 있습니다. Get 파라미터마다 다르게 응답하는 경우에는 "사용하지 않음"을 선택해야 합니다.덧붙여서 네이버 클라우드 플랫폼의 CDNZ에서는 기본 사용하지 않는 것으로 세팅되어 있습니다.

>

예를 들어, cdn.example.ntruss.com/file.png?query=12345 로 파일명 뒤에 위치한다?Query=12345에 대해서, 관계없이 동일한 컨텐츠를 회답하는 경우, "사용"이라고 선택해 주세요.

인가받지 않은 액세스에 대해서는, 컨텐츠를 전달하지 않게 설정할 수 있는 기능으로, 불필요한 액세스에 대해서는 액세스 제어를 실시할 수 있습니다. Secure Token은 Java/Python 등 각 언어별 폴더로 사용 언어 코드에 따라 선택하여 생성할 수 있습니다. 또한 Token 활성 시작, 만료 시간, 경로 조건에 따라 활용 및 작성 가능하며, 기간별 접근 관리가 가능합니다.

>

콘텐츠가 지정된 도메인에게만 제공되도록 하여 다른 사이트에서 참조되는 것을 방지하는 기능입니다. 레펠러가 없는 요구에 대해 접근통제를 설정할 수 있는 기능으로 등록된 레펠러에만 허용하도록 "허락하지 않는다"로 선택하여 불필요한 접근을 통제할 수 있습니다.

>

>

Gzip 파일 압축은 파일이 서버에서 전송되기 전에 파일 크기를 줄여 파일 전송 속도를 개선하고 페이지 로드 성능을 높이는 간단하고 효과적인 방법입니다. 파일 압축으로 대역폭 비용을 절감하고 응답속도를 개선하여 사용자에게 반응이 빠른 환경을 제공할 수 있습니다.

클라우드 환경에서 소규모로 구축하던 웹 서비스 접속자 수가 늘어나고 트래픽 양이 늘어나면서 웹 서버에 점점 부하가 걸리고, 이를 어떻게 개선해야 할지 고민하게 됩니다. Myservice.com을 운영하는 백 대리는 안정적인 서비스를 유지하고 트래픽을 원활하게 처리하기 위해 아래 두 가지를 통해 개선함으로써 웹 서비스의 품질도 개선하고 사용자 만족도도 높일 수 있었습니다. 1) 로드 밸런서를 통한 웹 서버의 부하 분산 2) 정적인 Resources를 CDN 서비스를 통해 빠른 콘텐츠의 속도 제공 및 웹 서비스가 받는 부하 분산

>

Myservice.com을 운영하던 대리가 레퍼런스 아키텍처에 의한 시스템을 개선한 것처럼 NAVER클라우드 플랫폼의 다양한 상품을 활용하고 효율적인 인프라 구성을 할 수 있습니다!여기까지 장문을 읽어 주셔서 감사합니다[참고 자료]| 로드 균형자 사용자 설명서| s://docs.ncloud.com/ko/networking/networking-3-1-v2.html| CDN| 사용자 설명서| s:/docs.ncloud.com/ko/networking/networking-8-1.html

​

​​

>

>

​