Monitoring_AWS_Instance_Costs(2)

장준영·2024년 4월 7일

개요

AWS 결제 방식 saving plans를 진행하기 이전 먼저 AWS의 요금을 최소화 하고자 t2->t3(a)로 업그레이드를 실행하려고 한다.

t.인스턴스 살펴보기

현재 사용하고 있는 t계열의 인스턴스들은 기본 성능을 제공하다가, 유저들이 몰리거나 하는 등 기준이상의 성능이 필요할 경우 버스트 기능이 동작한다. 버스트기능은 평소 CPU성능이 저조하다가 특정 시간대에 높은 사용률을 사용해야 할 경우 효율적이다.(크레딧을 통해 사용을 할 수 있는데, Cloudwatch에서 확인 할 수 있다.)
t2 인스턴스는 무제한 모드가 꺼져있지만, t3인스턴스는 무제한모드가 켜져있다.
또한 네트워크의 성능이 조금더 좋아진다.
CPU적인 차이로는 t3-> Skylake 6세대 CPU, t2->Haswell 4세대 CPU t3a->EPYC 7000
CPU의 세대 변화와 개수가 증가(small 기준1->2개)하여 성능적으로도 좋아졌다.
t3계열은 인텔의 t3, 라이젠의 t3a가 있는데, t3a가 조금더 저렴하다.(t3같은 경우 스카이레이크/케스케이드레이크 랜덤으로 걸릴수도 있다.)

t2.small에서 t3a.small로 이관시 온디맨드 기준 시간당 0.0054의 비용을 아낄수 있는 셈이다.
결국 기존 t2->t3a로 이관시, 네트워크성능/비용/CPU개수 등의 이득을 볼 수 있다.

물론 arm기반의 t4g도 훌륭한 대안이 될 수 있지만, x86과의 차이로 인해 AMI를 활용한 이관의 문제가 어렵다는 문제가 있다. 현재는 도커를 사용할수 없는 환경이기에(버전낮음) AMI를 적극 활용해야 하므로 무리가 있다고 생각한다.

현재 코인의 프로덕션과 스테이지 서버는 모두 t2.small 서버를 사용하고 있다.
Production: t2.small-> t3a.small
Stage:t2.small->t3a.small로 이관을 하려고 한다.
총 세대의 서버를 이관하면 한달에 11.664$ 의 비용을 줄일 수 있는데, 이는 200$ 의 서버비중 5%에 해당하는 비용을 줄인 셈이다.

진행방식

진행방식은 전형적인 Blue/Green방식으로 진행을 하였다.
1. AMI(Amazon Machine image)를 딴다.
2. AMI를 바탕으로 새로운 서버를 켜둔다.
3. 새로운 서버의 재부팅을 실시한다.
4. 재부팅이 완료되면 elb의 연결을 다시한다.(스테이지의 경우 DNS를 확인해야 한다.)
5. 서버 작동이 잘되는 것을 확인하면 기존의 서버를 종료한다.

진행시 유의사항

AMI를 따는 것은 서버의 메모리 문제를 초래할 수 있으므로 메모리 사용량이 적은 시간에 AMI를 따온다.
이전 Stage서버를 만들기 위해 AMI를 만들다 Koin Production이 Down된적이 있기에 고려를 해봐야 한다.
다만 AMI를 재부팅 없이 만들 경우 무결성에 대해 보장 할 수 없는 문제가 있다.
인스턴스 중지없이 AMI생성법

프로덕션 재시작시, Redis BGSave의 문제도 주의해야 한다.
저번 프로덕션 다운때 재부팅시 Redis의 BGsave가 작동하는데, 데이터가 깨져서 나와 이 옵션을 꺼야 한다.