도도한 개발자
[1% 네트워크] Chap5 Story5. 콘텐츠 배포 서비스 본문
🔔 성공과 실패를 결정하는 1%의 네트워크 원리를 읽고 정리한 글입니다.
🐈⬛ 콘텐츠 배포 서비스를 이용한 부하 분산
🐾 캐시 서버는 어디에 둘까?
서버 측에 두는 경우와 클라이언트측에 두는 경우가 있는데 두 방식에선 이용 효과면에서 차이가 난다.
웹 서버 직전에 둔다면...
웹 서버의 운영자가 캐시 서버를 관리할 수 있지만 트래픽 억제 효과는 없다.
💭 트래픽이 뭘까?
트래픽은 네트워크 내부에 일정 시간 동안 흐르는 데이터의 양이다. 데이터 전송량이라고 말할 수 있다.
즉, 트래픽이 많다는 의미는 데이터 전송량이 많다는 의미와 동일하다.
💭 트래픽 효과가 없다는 건 어떻게 알까?
캐시 서버가 웹 서버 바로 앞에 위치해 있고 이를 웹 서버가 관리하긴 하지만
클라이언트가 혼잡한 인터넷을 통해 전달하는 데이터의 양(트래픽)까지 제어할 방법은 없기 때문이다.
클라이언트측에 둔다면...
트래픽이 줄어들고 패킷의 흐름이 안정되어 대용량 데이터의 경우 효과가 극대화된다.
그러나 웹 서버 운영자가 캐시 서버를 제어할 수 없게 된다.
웹 서버측에 두는 것과 클라이언트측에 두는 것은 너무 대조적으로 보인다. 이를 절충하기 위한 방법으로 인터넷 주위에 캐시 서버를 두는 경우도 생각해볼 수 있다.
인터넷 주위에 둔다면...
프로바이더와 계약하여 웹 서버 운영자가 제어할 수 있는 캐시 서버를 클라이언트측의 프로바이더에 두는 방법이다.
트래픽이 줄어들고 웹 서버의 운영자가 캐시 서버를 관리할 수 있다는 특징이 있다.
💭 그러면 사용자와 가까운 장소에 캐시 서버를 설치하면 되겠네?
비현실적이다. 인터넷에 공개한 서버는 인터넷의 어디에서 액세스 하는지 알 수 없어 위 방법을 실현하려면 프로바이더의 POP 전부에 캐시 서버를 설치해야 하기 때문이다.
이를 해결하기 위한 방법으로 프로바이더에 중점을 두어 캐시 서버의 수를 줄일 수 있다.
이 경우 사용자에 따라 데이터가 캐시 서버에 도착하기까지 먼 길을 지나와야 할 수 도 있지만 웹 서버에 직접 액세스 하는 것보단 낫다.
그럼 해결이 됐나?
아무리 캐시 서버의 수를 줄여도 웹 서버 운영자가 프로바이더와 계약하면서 발생하는 캐시 서버 설치 바용이나 노동력은 간과할 수 없다.
이를 해결하기 위한 방법으로 등장한 것이 콘텐츠 배포 서비스이다.
🐾 콘텐츠 배포 서비스(CDS: Contents Delivery Service)
지리, 물리적으로 떨어져 있는 사용자에게 콘텐츠를 더 빠르게 제공할 수 있는 기술
이 서비스를 제공하는 사업자를 CDSP라고 부르는데, CDSP는 중요한 프로바이더와 계약하고 그곳에 다수의 캐시 서버를 설치한다. 또한 웹 서버 운영지와도 계약한다. 이를 통해 클라이언트가 웹 서버에 액세스할 때 CDSP의 캐시 서버에 액세스 할 수 있게 된다.
🐈⬛ 가장 가까운 캐시 서버의 관점
🐾 CDS의 핵심
CDS를 사용하는 경우 다수가 있는 캐시 서버 중 가장 가까운 캐시 서버를 찾아내고, 클라이언트가 여기에 액세스 하도록 중재하는 구조가 필요하다. 그 방법으로 클라이언트와 캐시 서버의 거리를 판단하여 클라이언트에 가장 가까운 캐시 서버의 IP주소를 회답하도록 한다.
💭 클라이언트와 캐시 서버의 거리는 어떻게 판단하지?
1. 우선, 캐시 서버의 설치 장소에 있는 라우터에서 경로 정보를 모아둔다.
4대의 캐시 서버가 있을 때 라우터도 4개가 되며, 각각의 라우터에서 경로표를 갖고오면 DNS 서버의 곁에 모인다.
2. DNS 조회 메세지 송신처의 DNS 서버에 이르는 경로 정보를 조사한다.
예를 들어, 라우터 A에서 클라이언트측의 DNS 서버까지의 경로 정보를 알 수 있다.
경로 정보에는 '프로바이더 X를 지나고, 프로바이더 Y를 지나 프로바이더 Z에 이른다’는 대략적인 거리 정보가 들어있다.
이는 클라이언트측 DNS 서버와 클라리언트가 같은 장소에 있다는 가정이었지만, 그러지 않아도 어느정도 정확하기도 하다.
🐈⬛ 리피터용 서버로 액세스 대상을 분배한다
가장 가까운 캐시 서버에 액세스 하는 방법은 한 가지 더 있다. HTTP 사양에 존재하는 헤더 중 'Location' 이라는 헤더가 있다. 이는 웹 서버의 데이터를 다른 서버로 옮기는 경우에 사용하는 것으로, '그 데이터는 이쪽의 서버에 있으므로 그쪽으로 다시 액세스하세요.' 라는 의미다. 이렇게 다른 웹 서버에 액세스 하도록 처리하는 것을 리다이렉트(redirect)라고 하며, 이것을사용해 액세스 대상을 가장 가까운 캐시 서버로 돌리는 것 또한 방법이다.
위 방법은 리다이렉트의 HTTP 메시지의 대화가 증가하여 오버헤드가 많다는 단점이 있지만, 클라이언트가 보내는 HTTP 메시지의 송신처 IP 주소를 바탕으로 거리를 판단하기에 정밀도가 높다.
💭 경로 정보 말고 다른 방법은 없나?
리다이렉트용 서버가 클라이언트에 반송하는 것은 Location 헤더가 들어있는 메시지뿐만 아니라 패킷 왕복 시간도 포함되어 있다. 이를 통해 캐시 서버까지의 거리를 계산하여 가장 왕복시간이 짧은 캐시 서버에 리퀘스트를 다시 보낸다는 내용의 리퀘스트 프로그램을 내장해 둔다. 이렇게 하요 클라이언트 스스로 최적의 캐시 서버를 판단하고, 여기에 액세스 할 수 있다.
🐈⬛ 캐시 내용의 갱신 방법에서 성능의 차이가 난다
원래 캐시라 함은 최초의 액세스 후에 두 번째 액세스 시도에서 효과를 볼 수 있는 방법이었다. 다른 관점에서 보면 최초의 액세스 동작엔 도움이 되지 않는다는 뜻으로 볼 수 있다. 게다가 두 번째 액세스부터도 원본 데이터가 갱신되었는지 확인하는 동작이 필요하므로 자칫 혼란을 야기해 응답 시간의 지연이 발생할 수 있다.
이를 해결하려면 원래 데이터에 변화가 생겼을 경우 즉시 캐시 서버에 반영을 해야한다. 항상 최신의 상태를 유지한다면 갱신 여부 확인 절차는 더 이상 필요하지 않을 것이다.
💭 모든 페이지에 적용이 되는건가?
아니다. 리퀘스트를 받고나서 CGI 애플리케이션에서 동적으로 페이지를 만드는 경우도 있기 때문에, 매번 페이지의 내용이 달라지는 부분은 놔두고 변하지 않는 부분만 캐시에 저장하면 된다.