- Elastic Cache
서버 아키텍쳐 중 Redis 를 Elastic Cache 서버리스를 이용하기로 했다.
서버리스를 이용하니 정말 설정할 것이 없었다.
근데 문제는 EC2 에 올라간 서버에서 Elastic Cache 에 접근이 안된다는 점..
이유를 찾아 4시간을 삽질했는데, 그 이유는 tls 설정이 되어있어야 한다는 것이다.
EC2 운영체제 이미지로 Amazon Linux 2023 를 사용할 경우 꼭 redis-cli6을 사용하시길..
https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/red-ug/in-transit-encryption.html
https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/red-ug/nodes-connecting.html
-
VPC 피어링
RDS 로 Aurora MySQL 을 사용하고, Elastic Cache 를 사용하는데 두 서비스 모두 서울 리전에만 존재한다. 우리는 EU, US-East, US-West 까지 총 4개의 리전에서 서버를 가동할 예정이다. 각 리전에서 서울 리전에서 구동되는 RDS, Redis 에 접근하기 위해 VPC 간 피어링을 설정했다. VPC 피어링은 VPC 간 1대1 연결을 맺어준다. 피어링 전이는 되지 않으니 꼭 1대1 피어링을 맺어야한다. 주의해야 할 점은 VPC 의 CIDR 대역이 중첩되면 안된다는 점 이다. 기존의 리전에 생성된 VPC CIDR 이 동일해 새로운 VPC 를 생성했고 1대1로 연결을 맺어줬다. 서울 <> EU, 서울 <> US-E, 서울 <> US-W 만 맺어주면 되기 때문에 Transit Gateway 는 고려하지 않았다.
사실 RDS, Redis 가 서울 리전에 존재해 타 리전에서 Latency 가 상당하지 않을까 하는 생각이 들긴 하는데 해당 부분은 더 고민해봐야 할 내용인 것 같다. -
AMI/ELB/Auto Scaling
서울 리전에서 탬플릿을 위해 EC2를 생성했다. EC2를 띄우고 서버를 설치하고, 서비스에 등록해 리부트가 되어도 자동으로 서비스가 뜰 수 있도록 설정했다. 해당 EC2를 AMI 이미지로 뜨고 다른 리전의 VPC 에 시작 템플릿으로 등록했다. 오토 스케일링 그룹을 생성해 EC2 를 띄운다. 로드 밸런서와 오토 스케일링을 위해 대상그룹을 만들고 로드 밸런서의 리스너로 443, 대상그룹으로 오토 스케일링 그룹을 통해 생성된 EC2 와 해당 서비스의 포트를 넣어준다. 오토 스케일링 그룹의 로드 밸런서 영역에 대상그룹을 추가해준다!
