마이크로서비스 아키텍처 구축(전면 개정판)

544

2

부

구현

캐시 헤더 코드를 수정해 릴리스하고, 스퀴드 캐시의 관련 영역도 수동으로 삭제했다. 하지만

그것만으로는 충분하지 않았다.

방금 설명한 것처럼 여러 곳에 캐시를 저장할 수 있지만, 캐시가 많으면 작업이 쉬워지기는커

녕 더 어려워지는 경우도 있다. 공용 웹 애플리케이션 사용자에게 콘텐츠를 제공할 때는 여러

분과 고객 사이에 여러 개의 캐시가 존재할 수 있다.

CDN

(콘텐츠 전송 네트워크) 등을 사용

해 웹 사이트에 접할 수 있을 뿐만 아니라 일부

ISP

는 캐시를 사용한다. 이 캐시를 제어할 수

있을까? 그렇다고 해도 끝내 제어할 수 없는 캐시가 하나 있는데, 바로 사용자 브라우저의 캐

시다.

Expires

:

Never

헤더가 포함된 페이지는 많은 사용자의 캐시에 남아 있어 캐시가 가득 차거

나 사용자가 수동으로 지우기 전까지는 절대로 무효화되지 않는다. 따라서 이러한 페이지의

URL

을 변경해 다시 가져오게 하는 것 외에 다른 방법은 없었다.

캐싱은 실제로 매우 강력할 수 있지만, 소스에서 목적지까지 캐싱되는 데이터의 전체 경로를

이해해야 캐싱의 복잡성과 발생하게 될 문제를 제대로 인식할 수 있다.

13.513.5

자동 확장 자동 확장

운이 좋아서 가상 호스트의 프로비저닝과 마이크로서비스 인스턴스 배포를 완전히 자동화할

수 있다면, 마이크로서비스를 자동으로 확장할 수 있는 구성 요소를 갖춘 셈이다.

예를 들어, 이미 알고 있는 추이에 따라 확장이 트리거되도록 할 수 있다. 시스템의 최대 부하

가 오전

9

시에서 오후

5

시 사이라는 ...