개발을 할 동안에는 로컬에서 Redis를 설치하여 사용하였지만,

Prod 단계에선 레디스 인스턴스에 부하가 많이 주어질 예정이기 때문에

레디스의 클러스터링, 샤딩을 설정해줘야한다. 하지만 이 작업들을 전부 수작업으로 하기엔 작업 소요가 크기 때문에 AWS에서 제공해주는 ElastiCache를 사용하기로 했다.

1. ElastiCache란?

Amazon ElastiCache는 클라우드에서 인-메모리 데이터 저장소 및 캐시 서비스를 제공하는 Amazon Web Services의 관리형 서비스이다. ElastiCache는 두 가지 인기 있는 오픈 소스 인-메모리 데이터 저장소인 Redis와 Memcached를 지원한다. 이 서비스는 고성능, 확장성, 간편한 관리를 제공하여 웹 애플리케이션의 속도를 높이고 데이터베이스의 부하를 줄이는 데 사용된다.

1-1. 주요 특징

1. 성능 향상: 데이터를 메모리에 저장하여 데이터베이스에 대한 조회 수를 줄이고, 애플리케이션의 응답 시간을 개선해준다.

2. 확장성: 클러스터의 노드 수를 쉽게 조정하여 용량을 확장하거나 축소할 수 있다.

3. 고가용성과 내구성: 다중 AZ 복제 및 자동 장애 조치 기능을 통해 높은 가용성을 보장한다.

4. 보안: VPC 내에서 실행되며, SSL/TLS를 통한 데이터 전송, 암호화된 REST 엔드포인트를 제공한다.

5. 관리의 용이성: AWS Management Console, AWS CLI, AWS SDK를 통해 쉽게 관리할 수 있으며, 백업 및 복구, 모니터링, 알림 등의 기능을 지원한다.

2. 문제 상황

ElastiCache를 사용하는데에 문제가 되는 점은 주요특징의 4번의 보안이었다.

ElastiCache는 VPC내에서만 접근이 가능하기 때문에 서울 리전의 IP에서만 접근이 가능하다.

172.31.4.33의 EC2(서울)에선 서울리전의 VPC안에있는 ElastiCache에 접근이 가능하지만

172.31.35.148의 EC2(버지니아 북부)에선 버지니아 북부의 Default VPC를 사용하기 때문에 서울리전의 ElastiCache에 접근이 불가능했다.

라이브 서버의 아키텍처의 구조상 버지니아 북부, 캘리포니아, 프랑크푸르트 리전에서 ElasitCache에 접근해야하기 때문에 VPC간 연결이 필요했다.

여기에서 VPC간 연결을 도와주는 친구가 VPC 피어링이다.

2-1. VPC Peering이란?

VPC 피어링은 두 개 이상의 VPC 간에 네트워크 연결을 설정하여 서로의 리소스를 안전하게 공유할 수 있게 하는 AWS의 네트워킹 솔루션이다. VPC 피어링을 통해 각 VPC의 인스턴스들이 마치 같은 네트워크에 있는 것처럼 서로 통신할 수 있다.

2-2. VPC 피어링의 주요 특징

1. 프라이빗 네트워킹: VPC 피어링은 퍼블릭 인터넷을 사용하지 않고 AWS의 프라이빗 네트워크를 통해 이루어진다. 이는 보안 및 성능 측면에서 이점을 제공한다.

2. 리전 간 피어링: AWS는 동일 리전 내의 VPC끼리는 물론, 다른 리전에 있는 VPC 간의 피어링도 지원한다(인터-리전 VPC 피어링).

3. 트랜지티브 연결 불가: VPC 피어링은 트랜지티브하지 않다. 즉, VPC A가 VPC B와 피어링되어 있고, VPC B가 VPC C와 피어링되어 있더라도, VPC A와 VPC C는 서로 통신할 수 없다.

4. IP 주소 중복 불가: 피어링하려는 두 VPC는 서로 겹치지 않는 CIDR 블록을 가져야 한다. IP 주소 범위가 중복되면 피어링을 설정할 수 없다.

5. 루트 테이블 업데이트 필요: VPC 피어링을 설정한 후에는 각 VPC의 라우팅 테이블을 업데이트하여 피어링된 VPC로의 경로를 추가해야 한다.

3. 다른 리전 간 VPC 피어링 연결하기

3-1. VPC피어링 연결 생성하기

• AWS콘솔에서 VPC -> 피어링 연결 탭을 들어가서 '피어링 연결 생성' 버튼을 누른다.
  
• 피어링 연결 설정에서 어떤 VPC에 연결할지 선택한 후 연결할 VPC ID를 입력해준다.
  
• 연결 요청을 보낸 모습
  

3-2. VPC피어링 연결 상태 확인하기

• Failed due to incorrect VPC-ID, Account ID, or overlaping CIDR range
  
  서울에서 보낸 VPC피어링 연결이 실패한 모습이다. 이는 2-2의 4번 항목에서 언급했던 내용으로
  두 VPC가 모두 172.31.0.0/16의 블록을 사용하고 있어 블록이 겹치기 때문이다.
  따라서, 버지니아 북부에 172.32.0.0/16 블록을 사용하는 VPC를 만들어 새로 연결을 요청했다.
  
• 정상적으로 요청이 보내진 모습
  
• 요청 수락을 누른다.
  
• VPC 피어링이 맺어진 모습
  

3-3. 라우팅 테이블에 VPC피어링 등록하기

이 부분은 2-2의 5번 항목에서 언급한 내용이다. VPC의 피어링을 맺은 후엔 라우팅 테이블에 서로의 VPC를 등록해줘야 한다.

• 등록할 라우팅 테이블에 들어간다(서울)
  

• 라우팅 편집을 누른다.
  

• 라우팅 편집에서 버지니아 북부에 생성했던 172.32.0.0/16 VPC를 등록해준다.
  

• 정상적으로 버지니아 북부리전의 VPC가 서울 리전의 라우팅 테이블에 등록된 모습
  

• 등록할 라우팅 테이블에 들어간다(버지니아 북부)
  

• 라우팅 편집을 누른다.
  

• 라우팅 편집에서 서울리전의 172.31.0.0/16 VPC를 등록해준다.
  

• 정상적으로 서울 리전의 VPC가 버지니아 북부의 라우팅 테이블에 등록된 모습
  

3-4. 보안의 인바운드 규칙에서 상대방의 VPC 허용해주기

• VPC피어링을 했더라도 VPC간 EC2 요청이 필요하다면 다음과 같이 보안그룹 만들어야 한다.
  
  

4. VPC 피어링 확인하기

아까는 버지니아 북부리전에서 서울 리전의 ElastiCache에 접근이 불가능했지만 (2. 문제상황),
이번엔 잘 연결된 모습을 확인할 수 있었다.

오늘은 라이브서버 세팅에 필요한 기능을 알아볼 수 있었다.

지금 진행하고 있는 프로젝트는 회사의 두번째 프로젝트인데, 첫번째 프로젝트에선 VPC 문제 때문에 ElastiCache를 사용하지 못했다고 한다.

이번 프로젝트가 끝나면 첫번째 프로젝트에 ElastiCache를 적용해야 한다.

따라서 관련 내용을 정리해두면 ElastiCache 뿐만 아니라 서로 다른 VPC간 연결이 필요할 경우 참고할 수 있을 것 같아 정리했고, 내가 문서화 해놓은 자료들이 나중에 회사의 다른 분들에게 도움이 됐으면 좋겠다는 마음에서 꼼꼼히 정리했다.