아래에서는, 어떻게 ALB를 적용할 수 있게 되었는지 그 적용방법과 문제해결과정을 적으려고 한다.
[ALB + Auto-Scaling 적용과정]
[문제 해결과정]
1. Auto-Scaling의 시작 템플릿 자동변경
[현 상황]
1. github actions + codeDeploy + S3를 이용하여, EC2 1개를 CI/CD하고 있는 상태임 2. 추후 서비스 운영 도중 대규모 트래픽이 발생할 상황을 대비하여 aws Auto-Scaling을 도입할 계획 3. Auto-Scaling이용하여 기존 EC2에 대한 Auto-scaling그룹을 만들었음
4. 동작됨을 확인 완료함
[문제점]
1. 기존 EC2에 대한 변경점이 생길 경우, 기존 EC2를 CI/CD시켜 재배포를 할 예정이나, 다시 생겨나게 될 Auto-Scaling 인스턴스들은 반영된 내용이 자동으로 적용되지 않을 것인데...
Auto-Scaling을 통해서 생성되는 것들은, AMI(Amazon Machine Images)를 이용한 시작템플릿을 이용하여 생성된다.
이 AMI라는 것은 기존EC2의 특정시점을 image화 시켜서 만든 것이다.
그 특정시점을 기준으로 만든 image를 시작템플릿으로 지정함으로써, Auto-Scaling그룹 내에서 서버 부하에 따라 인스턴스가 추가/감소되는 것이다.
그럼으로써 위와 같은 문제가 생겨난다.
EC2의 원본 소스코드를 바꾸게되면, CI/CD는 평소대로 진행이 가능하게끔 할 수 있는데 이미 AMI로 image화 시킨 게 적용된 Auto-Scaling의 시작템플릿은 자동으로 반영이 안 되지 않나??
고민이 된다....
근데 당연히 안되는 게 맞다고 생각한다.
그래서 아래와 같은 해결방안으로 진행하는 게, 별로 남지않은 프로젝트 기한에 합당한 결과물같다.
[해결방안]
1. 애플리케이션을 모두 완성한 뒤, 그 시점을 기준으로 AMI를 생성하여 Auto-Scaling 진행
2. 우선 Auto-Scaling을 진행한 뒤, EC2 원본 소스코드가 바뀌게 되면 AMI를 새로 생성하여 Auto-Scaling의 시작템플릿을 변경
1번과 2번 사항 중 선택하여 해결하는 것이 시간관계상 가장 합리적인 방안으로 생각된다.
(서버 부하를 해소시키는 게 가장 큰 목적임. 부하테스트를 서둘러 해야할 경우 2번이 가장 유력한 선택지)
Beanstalk는 이러한 과정을 한번에 해결할 수 있다는데...
나중에 다른 프로젝트를 맡으면 꼭 Beanstalk를 적용해봐야겠다.
2. EC2 스케일업 도입고려
부하테스트를 빠르게 진행해보기 위하여, 위에 기재한 1번 문제상황 중
해결방안 2번 (우선 Auto-Scaling을 진행한 뒤, EC2 원본 소스코드가 바뀌게 되면 AMI를 새로 생성하여 Auto-Scaling의 시작템플릿을 변경)
을 택하여 진행하였다.
하지만...
또 아래와 같은 이슈로 인하여 의사결정을 해야하는 상황이 도래하였다.
해당 이슈에 대한 해결방안은 아래에 도출하였다.
💡이슈 내용
- AWS기준, ubuntu 20.04버전 t2.micro EC2를 이용하여 ALB(Application-Load Balancer) + Auto Scaling을 진행하였다. 헌데 최소 EC2를 2개로 운영하여도 제이미터 부하테스트로 3초동안 약 7,000개의 요청을 날릴 시에 실패가 되는 사례가 발생하고 있다.
🔎문제 가능성 분석
- EC2의 버전 자체가 너무 낮은 처리능력을 가지고 있는 것이여서
- Auto Scaling으로 인해 새로 생겨나는 EC2의 생성속도가 지연됨에 따라 처리량을 보강하지 못해서
✅작업 계획내용
- 높은 처리량을 가진EC2로 스케일업
- Auto Scaling 세팅옵션 재조정을 통한 생성속도 지연상황 방지
3. EC2 스케일업 도입방향
💡이슈 내용
서버부하테스트 및 개발일정 준수로 인해, 높은 처리량을 가진 EC2로 스케일업하는 것을 목적으로 둠. 이에 따른 추가 작업들은 아래 작업 계획내용에 기재해둠.
✅작업 계획내용
ubuntu r5.8xlarge 모델로 스케일업 (금액 부담으로 인해 on/off 형식으로 운영할 예정)
Timezone 설정
reids 설치
java 11버전 설치
8080포트포워딩 진행
인스턴스 실행 시, jar파일 자동 실행세팅
상품 페이지네이션 지연 현상 해결
일반 상품 주문기능 미구현 현상 해결
4. EC2 스케일업 도입 후, 성능개선 미비
💡이슈 내용
위 내용대로 변경하였음. 내용은 아래와 같음
✅반영 결과 내용
제이미터 활용, 3,000명이 1초간 주문하기 기능을 요청하였을 경우 에러율 58.7% 육박
🔎문제 가정
서버 문제가 맞을려나? 확인이 추가로 필요할듯 why? 이전에 t2.micro EC2로 운영하였을 때와 유사한 실패율을 보이고 있음..
5. EC2 문제가 아닌, DB 병목 현상으로 인한 문제인 것으로 유추
💡이슈 내용
서버 문제가 아닌 것으로 확인됨. DB문제인 것으로 유추되고 있음 (DB커넥션 문제 or DB 자체 스펙미달 문제)
🔎확인 내용 (제이미터를 활용한 부하테스트)
[ubuntu r5.8xlarge 모델 사용]
500명 1초동안 주문하기 기능 요청 시, 에러율 0% 달성
1,000명이 1초동안 주문하기 기능 요청 시, 에러율 35% 달성
[ubuntu t2.micro 모델 사용]
3,000명이 1초동안 주문하기 기능 요청 시, 에러율 56% 달성 CPU 사용률(%)은 약 30%에 불과하여, CPU부하로 인해 그동안 에러가 발생한 게 아니였다는 것이 확인됨
✅추후 작업계획
DB 튜닝을 통해 부하테스트 에러율 0% 달성
6. DB 병목 현상 해결을 위한 트러블 슈팅
💡이슈 내용
DB튜닝을 통해 DB 병목으로 인한 에러현상 해결해야함 (DB max-connections 가 요청트래픽에 비해 부족한 상태여서 지연현상 에러가 발생하는 걸로 유추됨)
현재 시큐리티를 사용하고 있는데, '/' 경로에 대해서는 다 허용하지 않는다고 했기때문이다!
이것 때문에 계속 헬스체크를 통과하지 못한 것이였다.
왜냐하면 헬스체크는 실제 웹 서비스가 정상적을 호출하는 페이지의 URL주소를 넣어줘야 하기 때문이다.
그러한 이유로 현재 테스트 하고 있는 웹 사이트의 메인 경로가 /omg이므로 해당 경로를 헬스체크에 넣어준 결과.
동작이 매우 잘되게 되었다.
💊추후에 위와 유사한 문제를 다루게 된다면 꼭 이렇게 해결해보자!
BeanStalk도입
특징
초기 세팅
기본적으로 필요한 환경을 몇번의 클릭으로 서버 셋팅을 할 수 있다. 예를 들면 원하는 루비 버전과 패신저를 설정하면, 인스턴스에 직접 들어가서 설치하지 않아도 빈스톡이 알아서 환경을 구성해준다. 그런데 최신 버전의 언어를 지원하지 않는 경우도 있다. 이런 경우, 알아서 docker 환경을 만들어서 빈스톡에 등록해두어야한다.
환경 구성
AWS Console에서 서버에 필요한 환경 변수들을 쉽게 변경/관리할 수 있다. 그래서 서버에 직접 들어가서 환경 변수를 확인하거나, 배포스크립트를 확인하지 않아도 된다.
운영
오토 스케일링이 편하다. 빈스톡 설정 값에서 CPU 혹은 메모리가 일정이상을 사용하는 경우, 인스턴스를 늘리도록 설정할 수 있다. 그래서 갑자기 트래픽이 몰려도, 빈스톡이 알아서 스케일업을 해줘서 든든할 때가 있다. 그리고 트래픽이 빠지면, 알아서 스케일인을 해준다.
로그
패신저, 기본 어플리케이션 로그 등의 로그 로테이트를 알아서 해준다. 게다가 알아서 S3에 저장해준다. 그래서 지난 로그를 확인하고 싶은 경우, S3에 들어가서 로그를 확인하면 된다.
