CDN 성능

CDN에서 로드 시간이 개선되는 방식

사실상 모든 인터넷 사용자는 콘텐츠 전송 네트워크(CDN)의 혜택을 누려왔습니다. Google, Apple, Microsoft 등 기술업체의 대다수가 웹 페이지 콘텐츠 로드 시 대기 시간을 줄이려고 CDN을 이용합니다.

CDN은 대개 상이한 네트워크 사이의 익스체인지 포인트에 서버를 둡니다. 이러한 인터넷 익스체인지 포인트(IXP)는 다른 네트워크에서 발생한 트래픽에 대한 상호 액세스를 제공하기 위해 다양한 인터넷 제공자들이 연결하는 주요 위치입니다. CDN은 IXP 외에도 전세계에서 트래픽이 많은 영역 및 전략적 위치에 있는 데이터 센터에 서버를 배치하여 트래픽을 최대한 빠르게 이동시킬 수 있습니다.

CDN의 기본적인 효과는 콘텐츠를 신속하고 효율적으로 전송할 수 있다는 것입니다. CDN의 성능 최적화는 세 가지 범주로 구분할 수 있습니다.

1. 거리 단축 - 클라이언트와 요청 데이터 간의 물리적 거리를 단축합니다.
2. 하드웨어/소프트웨어 최적화 -솔리드 스테이트 하드 드라이브 및 효율적인 로드 밸런싱 등을 통해 서버 측 인프라의 성능을 높입니다.
3. 데이터 전송 감축 - 파일 크기를 줄이는 기술을 채용해 초기 페이지 로드가 신속하게 이뤄집니다.

CDN을 사용할 때의 효과를 이해하기 위해 CDN을 이용하지 않는 일반적인 클라이언트/서버 데이터 전송을 살펴보기로 하겠습니다.

CDN을 사용할 때와 사하지 않을 때의 로드 시간 차이

뉴욕에 있는 누군가가 싱가포르의 한 서버에서 호스팅되는 웹 사이트에 접속해야 한다고 상상해 보겠습니다. 이 두 곳 사이에는 약 9,520마일(14,800km)이라는 막대한 물리적 거리가 놓여져 있습니다.

웹 사이트 컨텐츠를 호스팅하는 서버( 원본 서버)가 싱가포르에 있다면, 웹 페이지 자산에 대한 모든 요청은 뉴욕에서 싱가포르로 갔다가 돌아와야 합니다. 경로 상에 연결편이 많은 해외 항공 여행의 경우처럼 모든 요청은 A 지점에서 B 지점까지의 장거리 여행에서 일련의 라우터를 거쳐야 합니다.

여러분의 컴퓨터가 현재 위치에서 특정 웹 서비스에 도달하기 위해 거쳐야 하는 연결 지점(홉)을 실제로 보려면, 데스크톱 컴퓨터에서 추적 유틸리티를 이용해 보시기 바랍니다.

뉴욕에서 싱가포르에 이르는 요청이 경로 상의 모든 라우터 위치를 통과해야 하기 때문에, 전체 시간(대기 시간)은 전체 거리와 각 라우터가 요청을 처리하는 데 걸리는 시간 만큼 증가합니다. 원본 서버가 요청을 처리하고 요청을 작성한 클라이언트에 응답하면, 유사한 라우터 경로를 통해 뉴욕으로 정보가 돌아갑니다. 통신업계에서는 이러한 총 왕복 여정을 RTT(왕복 시간)으로 측정합니다. 일단 가용한 대역폭 및 네트워크 혼잡 가능성을 무시하고 대기 시간 요인을 살펴보기로 하겠습니다.

예시를 위해, 다음과 같이 가정합니다.

• 뉴욕에서 싱가포르로 가는 요청에 250ms가 걸립니다.
• TCP/IP 연결을 설정하는데 250ms 대기 시간이 3회 추가됩니다.
• 웹페이지는 이미지, 자바스크립트 파일, 웹 페이지 자체로 구성되는 5가지 고유 자산을 필요로 합니다.

이제 이 웹 페이지를 로드하는 데 걸리는 시간을 대략 계산해 보겠습니다.

• 750ms: 뉴욕의 클라이언트와 싱가포르의 원본 서버 사이에 TCP/IP 연결이 설정되는 데 걸리는 시간.
• 250ms: 웹 페이지에 대한 HTTP 요청이 뉴욕에서 싱가포르까지 가는 시간.
• 250ms: 뉴욕의 요청자가 싱가포르에 있는 원본 서버로부터 200 상태 코드와 필요한 추가 자산을 모두 포함하는 응답을 받는 시간.
• 250ms: 뉴욕의 클라이언트가 5개 자산 각각을 요청하는 시간.
• 1500ms: 5가지 자산이 싱가포르의 원본 서버에서 클라이언트에 비동기식으로 전달되는 시간.

이 간단한 예에서 이 웹 페이지를 로드하는 데 걸리는 총 전송 시간은 3000ms입니다.

보는 바와 같이, 요청을 하고 응답이 돌아올 때마다, 뉴욕의 클라이언트와 싱가포르의 원본 사이 전체 경로를 왕복해야 합니다. 웹 사이트가 커지고 필요한 자산이 많아지면, A 지점과 B 지점 사이의 대기 시간은 계속 늘어날 것입니다.

싱가포르에서 호스팅되는 콘텐츠의 예를 다시 살펴봅시다. 이제는 싱가포르 사이트가 CDN 서비스를 이용하고 있으며, 이 서비스는 애틀랜타에 있는 서버에 정적 웹 사이트의 캐시 사본을 보관하고 있다고 하겠습니다.

• 뉴욕에서 애틀랜타로 가는 요청에 50ms가 걸립니다.
• TCP/IP 연결을 설정하는데 50ms 대기 시간이 3회 추가됩니다.
• 웹페이지는 이미지, 자바스크립트 파일, 웹 페이지 자체로 구성되는 5가지 고유 자산을 필요로 합니다.

이제 CDN을 이용하는 이 경우에 웹 페이지 로드 시간이 어떻게 될지 알아보겠습니다.

• 150ms: 뉴욕의 클라이언트와 애틀랜의 에지 서버 사이에 TCP/IP 연결이 설정되는 데 걸리는 시간.
• 50ms: 웹 페이지에 대한 HTTP 요청이 클라이언트에서 에지 서버까지 가는 시간.
• 50ms: 클라이언트가 에지 서버로부터 필요한 추가 자산 목록을 포함하는 웹 페이지를 받는 시간.
• 50ms: 뉴욕의 클라이언트가 5개 자산 각각을 요청하는 시간.
• 800ms: 5가지 자산이 에지 서버에서 클라이언트에 비동기식으로 전달되는 시간.

이 웹 페이지를 로드하는 데 걸리는 총 전송 시간은 1100ms입니다.

이 예에서, 클라이언트와 콘텐츠 사이의 거리가 줄어들었기 때문에 정적 콘텐츠에 대해 대기 시간이 1900ms 개선되었으며, 따라서 로드 시간이 2초 줄어듭니다.

필수 트래픽이 모두 거쳐야 하는 총 거리를 줄임으로써 웹 사이트 사용자가 느끼는 로드 시간이 단축됩니다. 사용자들은 대기 시간이 길어지면 바로 사이트를 떠나므로 (바운스), 이러한 개선의 결과 사용자 경험도 개선되고 사용자가 페이지에 머무는 시간도 길어집니다.

CDN의 콘텐츠 로드 방식 캐싱 소개

앞에서 말한 바와 같이, 일반적으로 클라이언트가 원본 서버에 파일을 요청하면, 요청은 해당 서버까지 왕복해야 합니다. CDN에서는 캐싱이라 불리는 과정을 통해 원본 서버의 정적 콘텐츠 파일을 분산된 CDN 네트워크로 끌어옴으로써 대기 시간을 줄입니다. 일부 CDN에는 동적 콘텐츠의 선택적 캐도 가능한 고급 기능이 제공되는 경우도 있습니다. 일단 데이터가 캐싱되면, CDN은 해당 콘텐츠를 클라이언트와 가장 가까운 CDN 데이터 센터에서 제공합니다.

클라이언트 컴퓨터는 TCP 핸드쉐이크 후에 CDN 네트워크에 대한 HTTP 요청을 작성합니다. 콘텐츠가 아직 캐시되지 않은 경우라면, CDN은 원본 서버와 에지 서버 사이에 추가 요청을 하여 최초로 콘텐츠를 다운로드합니다.

일반적인 CDN 캐싱은 다음의 4단계로 구성됩니다.

1. 사용자가 웹 페이지를 요청하면, 가장 가까운 CDN의 에지 서버로 요청이 라우팅됩니다.
2. 그러면 에지 서버는 사용자가 요청한 콘텐츠에 대해 원본 서버로 요청을 보냅니다.
3. 원본 서버가 에지 서버의 요청에 응답합니다.
4. 마지막으로 에지 서버가 클라이언트에 응답합니다.

원본 서버에 대한 최초 요청이 있게 되면, 이제부터 클라이언트에 대한 CDN의 근접성이 효과를 발휘합니다. 데이터가 원본 서버에서 CDN 네트워크에 캐싱되고 나면, 이제부터 클라이언트의 요청은 가장 가까운 에지 서버까지만 이동하면 됩니다. 즉, 가장 가까운 에지 서버가 원본 서버보다 가깝다면, 대기 시간이 줄어들고 콘텐츠를 제공받는 속도가 빨라진다는 것입니다.

이제는 자산을 다운로드하고 요청 및 응답을 처리하는 데 필요한 시간이 필요하지 않으므로, 이 두 지점 간에 정보를 전송하는 데 필요한 전송 시간만 계산하면 됩니다. 다음으로 알아볼 중요한 대기 시간 감소 요인은 데이터 감축, 하드 디스크 속도, 네트워크 혼잡도 등입니다.

CDN이 파일 크기를 줄여 속도를 높이는 방법

CDN은 페이지 로드 시간을 개선하기 위해 CDN의 캐시 서버와 클라이언트 사이의 전체 데이터 전송 양을 줄입니다. 전송되는 데이터 양의 줄어들면, 대기 시간과 대역폭이 모두 줄어듭니다. 따라서, 페이지 로드는 빨라지고 대역폭 비용은 줄어듭니다. 이러한 절감에는 두 가지 핵심 요소가 있습니다.

최소화 - 최소화는 코드 블록에서 사람의 이해를 돕는 구성 요소를 제거함으로써 코드 크기를 줄이는 과정을 말합니다. 엔지니어가 코드 블록을 읽고 유지 보수하려면, 변수 이름, 공간, 주석 등으로 개념을 분리하는 것이 좋지만, 컴퓨터는 이러한 요소가 없어도 코드를 잘 실행할 수 있습니다.

최소화 전후의 코드 블록 예입니다.

최소화 전: 코드 8줄

최소화 후: 코드가 1줄로 줄어듦

코드 스니펫이 8줄에서 1줄로 줄어들었고, 파일 크기도 줄어들었습니다. 따라서, 파일 전송 시간이 줄어들고, 결과적으로 대기 시간이 짧아지고 콘텐츠는 빠르게 로드됩니다.

파일 압축 - 인터넷을 통해 데이터를 전송할 때 필요한 대기 시간 및 대역폭 소비를 줄이는 데는 파일 압축이 중요합니다. 압축 방법 중 GZip이 널리 쓰이며, 웹 페이지 전송의 모범 사례로 간주됩니다. 많은 CDN 제공자가 기본적으로 GZip을 제공합니다. GZip 압축의 효과는 얼마나 될까요? 일반적으로 압축 파일은 초기 파일의 약 50%에서 70%까지 크기가 줄어듭니다.

CDN이 속도를 향상시키기 위해 사용할 수 있는 하드웨어

CDN의 하드웨어 최적화에 대해 말씀드리면, 전통적인 하드 디스크 드라이브(HDD) 대신 솔리드 스테이트 하드 드라이브(SSD)를 사용하여 큰 효과를 볼 수 있습니다. SSD는 HDD보다 최대 30% 빠르게 파일을 열 수 있으며 회복력이 좋고 안정성이 높습니다.

전통적인 HDD는 턴테이블과 유사하게 회전하는 금속 원반으로 되어 있는데, 그 위에 데이터를 저장하는 자기 코팅이 더해져 있습니다. 디스크가 회전하면 암의 읽기/쓰기 헤드 아래에서 정보에 액세스합니다. 이는 기계적인 과정으로 디스크의 회전 속도에 따라 영향을 받습니다. HDD는 아직도 생산되고 널리 쓰이고 있지만, SSD가 등장하면서부터 사용 빈도가 줄어들었습니다.

SSD도 역시 지속적인 스토리지의 형태이지만, USB 썸 드라이브나 디지털 카메라 등 장치에 널리 쓰이는 메모리 카드처럼 작동하며, 움직이는 부품이 없습니다. 보통의 HDD가 회전 중에 움직이게 되면, 뛰어넘는 부분이 생기고 읽기/쓰기 오류가 발생하여 작동 중지가 발생할 가능성도 있습니다. SSD는 분편화된 파일에 액세스할 때도 효과가 큽니다. 파일 분편화란 하나의 파일이 디스크의 여러 위치에 있어, HDD 드라이브에 대한 액세스 속도가 느려지는 상황을 말합니다. SSD는 인접하지 않은 메모리 위치에 대한 액세스가 효율적이므로, 분편화로 인해 성능에 문제가 생기지 않습니다.

최초의 CDN에서는 데이터가 HDD에 저장되었습니다. 이제 에지측 캐싱이 모두 SSD에서 일어나는 CDN이 있습니다. SSD의 단점은 비용으로, SSD는 전통적인 매체보다 5배까지 비싸기도 합니다. 이러한 이유로, SSD 사용을 피하고 과거 기술에 의존하는 CDN 서비스도 있습니다. Cloudflare CDN은 SSD만을 사용합니다.