바이패스

바이패스는 캐싱대상이 아닌 트래픽을 처리하는 기법이다.

../../../_images/bypass01.png

캐싱엔진이 트래픽에 개입하지 않음을 보장한다.

클라이언트 요청처리를 원본서버에게 위임하는 바이패스는 조건과 동작으로 구분된다.

Note

바이패스는 캐싱정책보다 우선한다. 설계단계에서 캐시가 고려되지 않은 서비스라면 정적리소스와 동적리소스를 정교하게 구분해낼 수 없는 경우가 많다. 이런 경우 모든 클라이언트 요청을 바이패스하도록 구성한 뒤 로그에 기반하여 요청이 많은 콘텐츠만 캐싱하도록 설정한다. 대개의 경우 몇 시간의 로그만으로 원본부하를 극적으로 낮출 수 있다.

바이패스는 아주 빠를뿐만 아니라 HTTP트랜잭션 단위로 동작한다. 아무리 개인화된 사이트라고 해도 대부분은 메인 페이지(.html)만 동적으로 변경될 뿐 나머지 99%는 정적인 리소스로 구성된다. 원본서버 동작에 맞출 수 있도록 HTTP 헤더 의 바이패스 버전이 별도로 존재한다.

See also

No-Cache 요청 바이패스

클라이언트가 no-cache요청을 보냈다면 바이패스한다.

GET / HTTP/1.1
cache-control: no-cache 또는 cache-control:max-age=0
pragma: no-cache

See also

HTTP 메소드 바이패스

바이패스가 GET , POST , PUT 요청의 기본동작이 되도록 설정할 수 있다. 각 메소드별 용도가 다른만큼 기본동작이 다름에 유의한다.

See also

아래 설정이 각 메소드의 기본설정이다.

accessControl 과 동일한 조건을 모두 지원한다.

우선순위는 다음과 같다.

  1. No-Cache 바이패스

  2. matchingList 에 bypass 라고 명시된 경우

  3. matchingList 기본 설정 (= getMethod , postMethod 기본설정)

  4. extraMethods 설정

로그인 세션 정보등을 원본서버에서 유지하는 경우, 반드시 해당 서버와 통신해야 하는 경우가 발생한다.

  1. 같은 서버로 가는 것만 보장하는 것이라면 getMethod 등의 세부 설정인 enableBackendAffinity , enableSticky 를 사용한다.

  2. 1:1로 소켓을 고정하려면 getMethod 등의 세부 설정인 enablePrivate 을 사용한다.

Warning

자칫 너무 많은 요청을 enablePrivate 으로 바이패스하는 경우 클라이언트 수 만큼 원본서버에 연결되어 엄청난 부하를 줄 수 있다. 또한 이렇게 연결된 원본세션은 클라이언트가 소유하게 되므로 악의적인 공격상황에서 위험을 초래할 수도 있다.

instant 모드로 바이패스 효과내기

바이패스되어야 하는 트래픽이지만 HTTP 헤더 또는 콘텐츠 본문을 가공하고 싶은 경우가 있다. 이 때 각 모드는 다음과 같은 한계를 가진다.

  • cache 모드로 캐싱되면 다른 사용자에게 캐싱된 콘텐츠가 노출될 수 있다.

  • bypass 모드로 캐싱을 우회시키면 HTTP 헤더 또는 콘텐츠 편집이 불가하다.

instant 모드는 이 둘의 타협점이다.

See also

instant 모드는 캐싱엔진을 경유하지만 단 1회만 서비스되고 사라진다.

../../../_images/bypass02.png

동일한 사용자가 동일한 요청을 동시에 보낸다하더라도 HIT되지 않는다.

instant 모드로 지정된 트래픽은 캐싱대상과 동등한 기능을 제공받는다. 하지만 다음과 같은 시나리오를 통해 bypass 효과를 얻을 수 있다.

  • 트랜잭션에서만 유효한 ID로 캐싱키는 생성한다. 즉, HIT 되지 않는다.

  • 캐싱엔진을 경유하기 때문에 모든 체인함수 사용이 가능하다.

  • instant 캐싱객체는 트랜잭션 종료와 함께 즉시 사라진다.

instant 모드를 이용하면 개인맞품형 트래픽에 대해서도 안전하게 가공처리가 가능하다.

바이패스 라우팅 이해하기

바이패스 stickiness 는 단일 클라이언트의 요청이 항상 같은 서버로 바이패스되도록 라우팅하는 기법이다. 아래 그림과 같이 A서버에서 로그인된 클라이언트 세션의 요청이 B서버로 라우팅될 경우 요청이 실패할 수 있다.

../../../_images/stickiess01.png

동일한 클라이언트의 멀티 세션은 다양한 경로를 통해 멀티 M2에 도달한다.

각 모드마다 다른 목적과 한계점을 명확히 이해해야 한다.

See also

net_route

net_route 방식은 클라이언트 세션이 최초 바이패스된 서버를 기억하여 항상 같은 서버로 라우팅하는 방식이다.

../../../_images/stickiess02.png

하지만 위 그림처럼 3번 요청이 전송된 M2 #2 에는 바이패스 이력이 없어 어느 서버로 라우팅될지 보장할 수 없다.

net_clientip

net_clientip 방식은 클라이언트 IP를 Hash하는 방식이다. 동일한 클라이언트 IP라면 항상 같은 서버로 라우팅된다.

../../../_images/stickiess03.png

이 방식은 외부환경에 영향을 많이 받는 단점이 있다. 클라이언트와 M2 사이에 Proxy가 존재하여 클라이언트 IP를 특정할 수 없는 경우 부하가 단일 서버에 몰리거나 의도치 않은 서버로 라우팅될 수 있다. 또한 원본서버 IP 구성이 변경(추가, 삭제)되면 라우팅 맵이 변경된다는 한계가 있다.