안녕하세요
오늘은 프로젝트 서버가 실행되고 있는 EC2의 인스턴스를 스케일 업 한 경험과 Redis 서버 인스턴스를 생성하고 연결한 경험을 공유해 드리겠습니다.
사실 그렇게 어려운 내용은 없어 편하게 보시면 될 것 같습니다.
적용한 과정, 조심할 부분과 한 두가지의 오류 사항정도 보시면 도움이 될 것 같습니다.
스케일 업이 왜 필요했나?
스케일 업 전에는 Memory가 1GB 이고 volumn은 30GIB인 t2.micro EC2를 사용하고 있었습니다.
EC2에 도커를 이용해 Spring boot 서버를 띄워놓았습니다.
이전 포스팅에도 몇 번 언급했지만 테스터를 제외하면 아직 사용자가 없기 때문에, 평소에는 큰 문제가 없었습니다.
하지만 작업을 하여 새로운 버전을 배포할 때, 무중단 배포를 위해 도커 컨테이너가 순간적으로 2개 활성되는데 이 상황에서 서버가 죽는 상황이 종종 발생했습니다.
아무래도 인스턴스의 Memory가 1GB로 매우 적은 편이고 서버만 띄웠을 때에도 Memory 사용량이 65% 이상 되었기에 어느정도 이유가 예상되었지만, 정확한 원인과 필요한 인스턴스 스팩을 알아보고 싶어 CloudWatch를 붙여 모니터링을 하고 있었습니다.
몇 주간 모니터링 한 결과 배포를 할 때 Memory 사용량이 증가하여 70% 이상 사용되는 것이 관찰되었고, 그 외에도 가끔 Memory 사용량을 70% 넘겨 설정해놓은 알림이 오는 경우가 있었습니다.
이를 토대로 인스턴스의 Memory를 늘려야한다고 생각했습니다.
또한 곧 본격적으로 서비스를 시작할 것이기 때문에 현재 인스턴스로는 정상적으로 서비스하는 것이 어렵다고 판단해 스케일 업을 진행했습니다.
스케일 업을 진행해보자
실제 서비스하고 있는 환경에서 사용자의 일시적인 증가로 인해 스케일 업이 필요하면, AWS의 Auto scaling 기능을 활용할 수 있습니다.
그러나 인스턴스의 영구적인 스케일 업이 필요하다면 새로운 인스턴스를 생성하고 같은 환경을 구성해야 합니다.
서버의 종료없이 스케일 업을 진행하기 위해 기존 서버를 종료하지 않은 상태로 스케일 업을 진행하는 것이 중요합니다.
1. 기존 EC2 인스턴스 이미지 생성
가장 먼저 기존 EC2 인스턴스의 이미지를 생성해야 합니다.
사실 기존 인스턴스의 환경을 새로운 인스턴스에 그대로 구현할 수 있다면 기존 EC2의 인스턴스 이미지를 이용하지 않아도 됩니다.
하지만 기존 EC2 인스턴스 이미지를 활용하면 구축단계에서 실수를 줄이고 불필요한 작업을 줄일 수 있기에 이를 활용했습니다.
이미지를 만드는 방법은 간단합니다.
AWS EC2 콘솔에서 이미지를 생성하고 싶은 인스턴스 콘솔에 들어간 후, 작업 -> 이미지 및 템플릿 -> 이미지 생성을 클릭하면 이미지가 생성됩니다.
2. 이미지로 새로운 인스턴스 생성
이제 생성한 이미지를 이용해 새로운 인스턴스를 생성해야 합니다.
생성된 이미지는 AWS EC2에서 오른쪽 네이게이션 바의 AMI에서 확인 가능합니다.
원하는 이미지를 선택하고 오른쪽 위에 AMI로 인스턴스 시작을 클릭하면 됩니다.
이후 인스턴스 이름을 입력, 기존과 같은 보안 그룹 선택 등 몇가지 작업을 하고 인스턴스를 생성하면 됩니다.
저는 t3.small 인스턴스를 선택했는데요,
아직 많은 요청이 들어오는 단계도 아니기에 안정적으로 배포할 수 있도록 Memory 2GB, CPU 2코어 스팩인 t3.small 인스턴스면 충분하다고 생각했습니다.
추후 사용자가 늘어나거나 서버가 커져 더 높은 스팩이 필요하면 다시 스케일 업 할 생각입니다.
t2와 t3의 비교는 아래 참고에서 잘 정리된 블로그를 보시면 좋을 것 같습니다.
3. IAM 권한 부여 및 경보 생성
2번까지 마치셨다면 스케일 업한 인스턴스 생성은 끝나신 겁니다.
그러나 저의 경우는 기존 인스턴스에서 사용하던 기능 등을 새로운 인스턴스에 연결하는 작업이 필요했습니다.
대표적으로 IAM 권한 설정과 CloudWatch를 연결해 주는 것이었습니다.
IAM 권한 설정은 기존 IAM을 연결시켜 주기만 하면 되고, CloudWatch 연결 또한 인스턴스만 교체해주면 되기에 간단했습니다.
4. 고정 IP 수정 및 로드밸런서 그룹 수정
서비스를 하고 있는 프로젝트라면 보통 고정 IP를 사용하고 있을 것입니다.
그렇지 않다면 프론트나 클라이언트 코드의 요청 IP 주소를 새로 생성된 인스턴스 IP로 교체해줘야 합니다.
저는 고정 IP와 도메인을 연결하고, 도메인과 로드밸런서를 연결해서 사용하고 있기 때문에 이를 수정하는 작업이 필요했습니다.
고정 IP를 재할당 하는 것 역시 인스턴스만을 바꿔주기만 하면 됩니다.
하지만 로드밸런서를 사용하는 분은 로드밸런서에서 타겟 그룹에 새로 생성된 인스턴스를 먼저 추가해주시고, 이후에 고정 IP 재할당 하는 것을 추천드립니다.
그래야 서비스가 끊김없이 작동할 것 입니다.
이제 스케일 업 작업이 모두 끝났습니다.
큰 어려움 없이 스케일 업 작업이 완료되어서 좋군요!
Redis 서버를 생성해보자
EC2 스케일 업을 진행하는 김에 추가적으로 Redis 서버를 생성하고 연결했습니다.
현재 서버에서 Redis를 활용하는 부분은 두 군데 입니다.
먼저 JWT Refresh Token을 Redis에 저장하고 있습니다.
그리고 이전에 포스팅한 내용인 동시성 이슈를 해결하기 위해 Redis를 사용하고 있습니다.
기존에는 Spring server가 있는 EC2에 redis server를 띄우거나 embeddedRedis를 활용하고 있었는데 아무래도 redis가 in memory database이다보니 Memory 따로 할당해주는 것이 좋다고 생각했습니다.
또한 서버가 Spring server와 redis가 같은 인스턴스에서 동작하면 에러가 전파될 가능성이 있다고 판단했습니다.
혹시 서버 인스턴스를 늘리게 될 경우에도 redis를 띄우는 서버가 따로 존재하는 것이 유리하다고 생각하기도 했습니다.
Redis 서버를 생성하는 것 또한 어렵지 않습니다.
인스턴스를 하나 생성하고, Redis를 설치하고, 필요하면 설정을 수정하고 실행시키면 됩니다.
이때 Redis 서버의 IP도 고정하는 것이 좋습니다.
서버와 Redis와 통신할 때 Redis가 설치되어있는 인스턴스의 IP를 이용하기 때문에 IP가 바뀌면 서버를 수정해야 하는 일이 발생하기 때문입니다.
Redis 서버를 설정하면서 마주한 사소한 오류들을 공유하면서 마치겠습니다.
1. Redis restart 오류
redis 설정을 수정하고 restart 하려고 하는데 아래와 같은 오류가 발생했었습니다.
polkit-agent-helper-1: pam_authenticate failed: Authentication failure권한이 없다는 오류인데, sudo를 붙이고 해도 안되더군요..
결국 sudo su 명령어를 통해 root로 접근해서 해결했습니다.
2. Redis username은 뭐지?
Redis 서버를 설정하고 외부에서 정상적으로 접속가능한지 테스트 해보고 싶었습니다.
로컬에서 Datagrip을 통해 연결을 해보려 했는데 redis의 username과 password가 필요했습니다.
저는 redis의 username을 설정한 적이 없어서 굉장히 당황스러웠습니다.
ubuntu, root 등을 입력해봤지만 접근할 수 없었습니다.
엄청난 검색끝에 아무것도 입력하지 않으면 된다는... 것을 발견하고 무사히 접속할 수 있었습니다.
마무리하며...
AWS EC2 스케일 업 및 Redis 서버 구축을 무사히 마쳤습니다.
큰 어려움 없이 마칠 수 있어서 좋았습니다ㅎㅎ
서비스를 시작하고 사용자가 많이 늘어나서 스케일 업을 또 할일이 있으면 좋겠습니다.
참고
