웹사이트 성능 과 관련한 글들을 찾아보다가 도메인 샤딩이라는 단어를 발견하였다.

샤딩은 사실 도메인 샤딩이라는 내용보다는 데이터 베이스 이용 시 성능 향상을 위해서 사용하는 말로 보인다. shard라는 것이 그냥 직역하면 조각인데
하나의 데이터 베이스에서 대량의 데이터를 저장 및 조회 할때 성능을 높이기 위한 방식으로 샤딩~ 이라는 애가 나온것 같다. (파티셔닝같은건가…) 샤딩하는 전략에 따라 데이터를 수평분할 한다고 이해해도 될것 같다. 지금 개발 하는 앱에서도 데이터가 많은 테이블에서 조회를 해서인지 조회 할때 조회기간이 3개월만 넘어가도 버벅되는 현상이 있어서 조회 기간을 3개월을 넘지 못하도록 수정해야 했었다.
여기서 샤딩을 한다면 뭐 이름이나 **번호에 따라 테이블을 다르게 나누고 조회 할 수 있지 않을까 하는 생각이 든다. 데이터의 샤딩에 대한 내용은 원래 목적 한 바가 아니니.. 이쯤에서 넘어가야겠다.

그렇다면 도메인 샤딩이란 무엇일까?

브라우저가 한번에 하나의 도메인에서 내려받을 수 있는 리소스는 유한하다. (참고: http://www.browserscope.org/?category=network&v=top )

한개의 도메인에서 한번에 최대 6 개의 리소스를 받을 수 있다면, 총 30개의 리소스를 받기 위해서는 5번의 요청을 해야 한다.
6개의 리소스를 다운받을때 페이지를 로드하는 시간이 t 인경우 페이지 로딩시간이 그냥 단순하게 계산해서 5t가 되는 것이다. 이런 제한을 해결하기 위해서 개발자는 여러 하위 도메인에 컨텐츠를 분리 할 수 있는데 이걸 도메인 샤딩이라고 한다

하지만 또 너무 많은 도메인을 추가하면 웹 브라우저가 도메인에서 dns 조회를 수행해야 하고 connection을 유지 해야 하므로 추가 로드 시간이 길어지기 때문에 도메인을 적절하게 추가해야 한다. (과유불급이라 하였다~)

하지만 이러한 도메인 샤딩은 오래된 브라우저의 성능 향상을 위해 사용된다.

그 이유는 google에서 SPDY 프로토콜 을 발표 했기 때문이다. (역시.. 갓google)

SPDY 프로토콜은 웹 성능 향상을 위해 세션을 통과하면서 데이터를 일부 수정해서 대역폭 사용을 최적화 한다. (로딩시간이 줄어들고 대역폭 사용량이 감소한다. 이로 인해 고객 만족도는 올라가고 COST는 내려간다.)

SPDY는 아래의 HTTP의 문제점을 해결한다.

1. HTTP는 하나의 연결에 하나만 요청이 가능하다. -> 그렇기 때문에 지연이 발생하고 대역폭을 충분히 활용할 수 없다. SPDY는 동시 다운로드를 허용한다.
2. HTTP를 사용하기 위해서는 클라이언트 가 서버에 콘텐츠를 요청해야 한다.
   -> SPDY를 사용하면 서버가 요청을 기다리지 않고 데이터를 클라이언트에 밀어넣을 수 있다.
3. HTTP의 경우 경우에따라 동일한 헤더가 세션중에 반복 될 수 있다. -> SPDY는 불필요한 헤더를 제거하여 필요한 대역폭의 양을 줄인다.
4. 압축되지 않은 데이터 -> HTTP에서는 데이터 압축이 선택 사항이지만 SPDY의 경우 헤더를 포함한 모든 통신에 압축을 강제한다.

SPDY 프로토콜의 이용으로 속도가 이전에 상당히 향상 되었지만 더 빠른 웹에대한 열망을 잠재우지 못했다.

그래서 나온것이 HTTP/2(현재) 이다. (SPDY는 비표준 프로토콜이지만 HTTP/2는 표준 프로토콜이다. ) (참조: 하이퍼 텍스트 전송 프로토콜 버전 2 https://tools.ietf.org/html/draft-ietf-httpbis-http2-16#section-4 )

HTTP/2의 목표

클라이언트와 서버가 HTTP 1.1, 2.0 또는 잠재적으로 다른 비 HTTP 프로토콜을 사용하도록 선택할 수있는 협상 메커니즘을 만든다
HTTP 1.1과의 높은 수준의 호환성 유지 (예 : 메서드 , 상태 코드 , URI 및 대부분의 헤더 필드 포함 ). 다음 을 고려 하여 대기 시간 을 줄여 웹 브라우저의 페이지로드 속도를 향상

• HTTP 헤더 의 데이터 압축
• HTTP / 2 서버 푸시
• 요청의 파이프 라이닝 (TCP 연결에서 응답을 기다리지 않고 HTTP 요청을 보내는 기술 )
• HTTP 1.x에서 head-of-line 블로킹(한 줄의 패킷 이 첫 번째 패킷에 고정 될 때 발생하는 성능 제한 현상) 문제 수정
• 다중 TCP의 연결 데스크톱 웹 브라우저, 모바일 웹 브라우저, 웹 API, 다양한 규모의 웹 서버 , 프록시 서버 , 역방향 프록시 서버, 방화벽 및 컨텐츠 전달 네트워크 와 같은 HTTP의 공통된 기존 사용 사례를 지원한다.