라이트세일에 꾸역꾸역 오토 스케일링 적용하기
리모트몬스터는 백엔드팀의 역할을 딱 한 단어로 좁혀서 이야기합니다. “비용 절감” (가용성 확보는 기본이고요) 💰💰💰
비용 절감은 여러 가지 경로로 실현 가능한데,
첫째로 자동화를 통한 인건비 절감입니다. 사람이 해야 할 일을 자동화 시켜놓으면 팀이 굴러가기 위한 노동력이 줄어듭니다. 실제로 리모트몬스터의 백엔드팀은 단 두명(혹은 3명)입니다. 자동화 없이 두 명이서 백엔드 자원을 관리 한다고 상상만 해도 끔찍합니다.
둘째로 자동화를 통한 인프라 비용 절감입니다. 보통 On-demand 형태로 요금을 부과하는 클라우드 자원은 적게 쓸수록 돈을 적게 냅니다. 따라서 필요 할때는 서버를 키고 필요 없을때는 서버를 끄는게 가장 싸게 클라우드 자원을 사용하는 방법입니다.
요즘엔 오토 스케일링을 가능케 하는 툴들이 워낙 많기 때문에 쉽게 사용량에 따라 서버를 켰다, 껐다 하면서 서비스를 운용 할 수 있습니다. 하지만 근본적으로 오토 스케일링이 불가능한 환경에서는 어떻게 해야할까요?
가장 대표적인 예시는 AWS Lightsail (이하 라이트세일)입니다. 라이트세일은 EC2 처럼 인스턴스 자원을 생성하고 관리하는 곳입니다. 하지만 가장 큰 차이점은 가격인데요, 동일한 vCPU 개수와 Memory 용량을 가지고 가격을 비교해보면 EC2 가 약 1.5배정도 비쌉니다.
가격 비교
그럼 항상 라이트세일을 사용하지 EC2를 왜 쓸까요? 당연히 라이트세일은 가격이 싼 만큼 단점도 명확합니다.
AWS Auto Scailing Group 적용 불가
Security Group 가 없어 Ip Address Range 적용 불가
Volume 타입 변경 및 용량 조절 불가
AWS CloudWatch 적용 불가
EC2 에 비해 부족한 AWS CLI API
EKS 에서 라이트세일에 자원 생성 불가
…
나열 할게 더 남았지만 라이트세일이 너무 불쌍해서 여기까지만 하겠습니다. 종합적으로 봤을때 가장 큰 단점은 스케일링에 자유롭지 못한걸로 볼 수 있겠죠.
이렇게 보면 라이트세일을 대체 왜 쓰나? 하면서도 가격을 보면 충분히 매력적입니다. 다만 여기서 한 가지 의문이 생기겠죠. 말씀드린대로 스케일링에 제한이 있다면 자동적으로 서버를 껐다, 켰다 가능한 EC2 같은 놈을 쓰는게 더 쌀 수도 있지 않을까?
맞습니다. 라이트세일이 저렴하다고 해서 스케일링 없이 주구장창 켜놓으면 요금 폭탄을 맞을겁니다. 그러면 결국 라이트세일 + 오토 스케일링의 조합이 가장 싸다고 볼 수 있겠죠.
태생적으로 라이트세일은 아마존이 적당히 라이트세일을 사용하다가, EC2로 알아서 넘어가게끔 사용자를 유치하는 건널목으로 만들어졌을겁니다. EC2의 체험판이라고 볼 수 있겠죠. 때문에 비개발자에게 친화적인 UI (EC2에 비해), 고급 기능 제한 등으로 EC2를 사용 할 수밖에 없게끔 만드려는 의도가 보입니다.
이제부터 원가 절감을 위해서 서비스 요청량이 많으면 라이트세일 인스턴스를 늘리고 줄이는 오토 스케일러를 직접 구현한 이야기를 하려합니다.
스케일링의 조건
먼저 어떻게 자원이 늘어나야 하는지 규칙을 정해야합니다. 리모트몬스터의 미디어 서버를 예로 들겠습니다. API 사용 고객이 몰려 순간적으로 방송 송출량이 늘어났을때 추가적인 요청에 대응하기 위해서 언제나 여유분의 미디어 서버를 가동 시켜둬야합니다. 그렇지 않으면 클라이언트는 “방송 시작 불가”와 비슷한 에러 메시지를 받겠죠.
쉽게 말해서 얼마나 많이 여유 자원 개수를 확보 해 둘지 정하고, Idle 상태의 인스턴스 개수가 여유 자원 목표치보다 적으면 새로 인스턴스를 가동시키고, 만약 Idle 상태의 인스턴스가 너무 많다 싶으면 여유 목표치만큼 남도록 줄이는 작업을 해야합니다.
만들어보기
의사 코드 버전 1.0
VAR 여유_서버_목표치 = 10
VAR 노는_서버의_개수 = 헬스체킹() ; every 5 seconds
IF 노는_서버의_개수 < 여유_서버_목표치 AWS_Lightsail_CreateInstance() IF 여유_서버_목표치 < 노는_서버의_개수 AWS_Lightsail_DeleteInstance()
의사코드 버전 1.0 토폴로지
간단하게 1.0 버전을 만들어 보았지만 만족스럽지 못했습니다. 여유_서버_목표치 변수가 하드코딩 되어있어 애플리케이션을 재배포 하지 않는 이상 언제나 10개의 여유 서버를 돌리길 원하겠죠. 만약에 서비스 사용자가 급격히 증가한다면? 여유 서버를 10대로는 턱도 없을 겁니다. 즉, 여유 서버 목표치를 언제나 자유롭게 조절 가능하게 만들어야 합니다. 쉽게 말해 Remote Configuration 이 가능해야죠.
의사 코드 버전 2.0
VAR 여유_서버_목표치 = AWS_EC2_GetTagResource('여유_서버_목표치')VAR 노는_서버의_개수 = 헬스체킹() ; every 5 seconds
IF 노는_서버의_개수 < 여유_서버_목표치 AWS_Lightsail_CreateInstance() IF 여유_서버_목표치 < 노는_서버의_개수 AWS_Lightsail_DeleteInstance()
의사코드 버전 2.0 토폴로지
2.0 버전에도 불만족스러운 부분이 존재합니다. 바로 Tag 값이 사람이 직접 바꿔주야 한다는 건데요, 그렇게되면 비교적 사용량이 적은 새벽 혹은 밤 시간대, 주말에는 남는 자원이 발생합니다. 이를 해소하고자 시간, 요일에 따라 Tag 를 변경하는 Cron으로 스케줄링을 걸어두었습니다.
의사 코드 버전 3.0
Cron() // 시간대에 따라 여유 서버 목표치 태그 Value 조절
VAR 여유_서버_목표치 = AWS_EC2_GetTagResource('여유_서버_목표치')VAR 노는_서버의_개수 = 헬스체킹() ; every 5 seconds
IF 노는_서버의_개수 < 여유_서버_목표치 AWS_Lightsail_CreateInstance() IF 여유_서버_목표치 < 노는_서버의_개수 AWS_Lightsail_DeleteInstance()
의사코드 버전 3.0 토폴로지
이제 조금 만족스럽습니다. 하지만 운영하다보니 문제가 생겼습니다. 바로 API Request Limit 에 저촉되는겁니다! 기본적으로 AWS API 는 Throttling 을 걸어 놓습니다. 어떤식이냐면 일정 간격으로 서서히 회복하는 최대 요청 버킷을 담아두고 호출 할때마다 버킷에 담겨있던 토큰을 소비하는 방식입니다. 토큰 회복 속도보다 빠르게 호출하면 거절한다는 겁니다.
만약 인스턴스를 생성하고 제거하는 API 가 단 한번의 HTTP 호출이라면 문제될게 없습니다. 하나의 트랜잭션이니까요. 실패하면 토큰이 회복될때까지 기다렸다가 다시 시도하면 그만입니다.
그러나 라이트세일에서 사용 가능한 상태의 인스턴스를 생성하는 절차는
라이트세일 자원 생성 요청 시작
인스턴스 이름 지어주기
포트 열어주기
태그 붙여주기 등
…
처럼 하나의 API 호출로 끝나는 작업이 아닙니다. 만약 세번째 단계인 <포트 열어주기>에서 API Request Limit 에 걸려버리면 반쯤 생성된 좀비 같은 인스턴스가 저희 리젼에 떠다니는 겁니다.
이를 해결하려면 재시도 로직을 담아야합니다.
의사 코드 버전 4.0
Cron() // 시간대에 따라 여유 서버 목표치 태그 Value 조절
VAR 여유_서버_목표치 = AWS_EC2_GetTagResource('여유_서버_목표치')RETRY_LOOP:
VAR 노는_서버의_개수 = 헬스체킹() ; every 5 seconds
TRY {IF 노는_서버의_개수 < 여유_서버_목표치
AWS_Lightsail_CreateInstance()
IF 여유_서버_목표치 < 노는_서버의_개수
AWS_Lightsail_DeleteInstance()
} CATCH {
GOTO RETRY_LOOP
Slack()
}RETRY_LOOP:
마치며
지금까지 나름 오토 스케일러를 모방한 리모트몬스터만의 스케일링 툴을 만들어 봤는데요. 하면서 느낀점은 역시 라이트세일은 프로덕션 환경에서 쓰는데는 한계가 있다는 겁니다. 비용 절감도 좋지만 정말로 검증된 툴을 사용해 스케일링 하는것과 비교해보면 분명히 위험성은 존재합니다. 😃
하지만 스케일러를 직접 구현해보면 분명히 배울점은 존재합니다. 이 작은 스케일러를 만드는데도 4.0 버전까지 코드를 수정한것을 보면요. 그런점에서 다시 한 번 쿠버네티스를 리스펙하게 됐습니다.
가입하기
