티스토리 뷰

개요 

나는 데이터 캐시 계층의 위치를 꽤 오랫동안 잘못 알고 있었다.

 

이유는 AWS CloudFront를 직접 도입했던 영향이 컸다. 막연하게 ElastiCache도 동일한 위치에 있겠거니 하고 사용했었다.

 

인프라 관점에서 캐시는 크게 두가지로 나뉜다. 

 

CDN과 데이터 캐시인데, 이 두 가지 캐시는 용도와 네트워크 상의 위치가 완전히 다르다.

 

이번에 ElatCache를 도입하면서 한번 정리해보려고 한다.

 

CDN (Content Delivery Network)

캐시(Cache)와 CDN(Content Delivery Networks) 이전에 쓴 글이 있으나 이글에 짧게 정리한게 더 좋은 거 같다..

 

CDN부터 간단히 정리해보자면, CDN은 은 외부 사용자에게 가장 가까운 네트워크 엣지에서 콘텐츠를 캐싱하는 계층이다. 정적 파일(이미지, CSS, JS), 동적 응답(API 결과) 등을 캐싱하며, 사용자는 물리적으로 가까운 엣지에서 데이터를 받아 지연 시간이 줄어든다.

 

CDN은 결국 외부 사용자와 직접 맞닿는 퍼블릭 캐시다. 서비스의 “앞단”에서 동작한다는 점이 특징이다. AWS에서는 CloudFront가 이 역할을 담당하고 있다. 

 

AWS CloudFront는 특정 서브넷에 위치하지 않는다. 대신 POP(Point of Presence)라는 인터넷 트래픽을 받아주는 거점 노드에 위치한다. POP에 데이터가 캐싱되어 있지 않다면 원본(Origin)에서 가져와 적재해 두고, 이후에는 가까운 POP에서 빠르게 제공한다.

 

이제 그러면 ElastiCache의 위치에 대해 알아보자.

 

ElastiCache와 같은 데이터 캐시

https://renine94.github.io/aws/AWS-ElastiCache-%281%29-Basic/

 

데이터 캐시는 CDN과 달리 외부 사용자와 직접 맞닿지 않는다. 대부분의 경우 데이터 캐시는 애플리케이션 서버와 데이터베이스 사이에 위치해, 자주 조회되는 데이터를 빠르게 제공하는 역할을 한다. VPC 내부, 보통 프라이빗 서브넷에 위치하며, DB 쿼리 결과, 세션 데이터, 자주 쓰는 데이터를 캐싱한다. 이를 통해 데이터베이스 부하 감소, 애플리케이션 응답 속도 향상, 비용 절감 (DB I/O 감소 효과) 등의 효과를 얻을 수 있다.

 

AWS에서는 ElastiCache (Redis/Memcached)가 이 역할을 담당한다.


중요한 점은, ElastiCache는 퍼블릭 IP를 부여할 수 없고, 반드시 VPC 내부에서만 접근해야 한다는 것이다. 


즉, 외부 사용자가 직접 접근하는 것이 아니라 애플리케이션 서버가 내부적으로만 접근하는 캐시라는 점에서 CDN과 완전히 다르다. AWS RDS도 VPC 내부에 존재하지만 퍼블릭 IP를 부여할 수 있는데, 여기서 차이점이 발생한다.

 

왜 ElatiCache는 퍼블릭 IP를 부여할 수 없는가?

AWS RDS는 퍼블릭 접근 옵션을 제공한다.


공식적으로는 퍼블릭 접근을 물론 권장하지는 않는다. 그러나 외부 툴(dBeaver, DataGrip 등)에서 직접 연결하거나, 온프레미스 환경에서 마이그레이션을 할 때 필요한 경우가 있기 때문이다. 즉, 운영과 관리 측면에서 어쩔 수 없이 외부 연결이 필요할 수 있다는 점을 AWS가 고려한 것이다. (링크)

 

반면 ElastiCache는 태생부터 내부 캐시 계층이라는 전제를 가지고 있다.

 

캐시의 용도: 애플리케이션 서버와 가까운 위치에서 DB 부하를 줄이는 것

보안 모델: Redis/Memcached 프로토콜은 HTTP/HTTPS 기반이 아니고, TLS 지원도 늦게 추가되었을 만큼 보안에 취약하다

성능 특성: 인메모리(in-memory) 캐시라서 밀리초 단위 응답이 전제인데, 인터넷 레이턴시가 섞이면 의미가 없다

 

즉, 퍼블릭으로 열 이유가 전혀 없고, 보안적으로도 열면 안 되는 서비스라서 AWS가 서비스 차원에서 아예 퍼블릭 옵션을 제공하지 않는다.

 

정리하면, 외부에서 ElastiCache에 접근하기 위한 최선의 방법은 퍼블릭 IP가 닫혀잇는 RDS에 접근하는 방식과 동일하다.

 

bastion EC2 서버를 두고 AWS SSM을 통해서나, ssh를 이용할 수 밖에 없다. (불편)

 

마치며

사실 이글은 오래 전에 썼어야 하는 글인데, 이번에 ElatiCache를 도입하면서 이 내용들이 기억나서 정리해봤다.

 

이 내용의 대부분은 여기에 있는 내용들이다.

 

정말 오랜만에 글을 쓰는데, 바쁘기도하고 써야할 것들이 많은데 구체화가 잘 안되서 

 

그리고 너무 더워서 집중력도 많이 떨어진 것 같다. 매번 여름이 이런데, 어떻게 해야할지 잘 생각해봐야 할 것 같다.

 

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2025/10   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함