Cloud Modernization 12
온디맨드, Savings Plans, 스팟 인스턴스로 EC2 비용 전략 세우기
싼 옵션을 고르면 된다고 생각하면 안정성, 약정, 중단 가능성 같은 조건을 놓치기 쉽다.
근거 · 교안 p45-p48
1장: 가장 싼 EC2 옵션이 최고? 가격 뒤에 숨겨진 진실
1. 가장 싼 EC2 옵션이 최고? 가격 뒤에 숨겨진 진실
솔라의 손가락이 노트북 트랙패드 위에서 경쾌하게 멈췄다. 화면에는 여러 그래프와 숫자가 어지럽게 펼쳐져 있었지만, 솔라의 시선은 단 한 곳, 유독 눈에 띄는 할인율에 고정되어 있었다. ‘최대 90% 할인.’ 그 옆에는 ‘스팟 인스턴스’라는 이름이 붙어 있었다.
“찾았다.”
솔라는 나지막이 읊조리며 의자 등받이에 몸을 기댔다. 복잡하게만 보였던 EC2 비용 최적화 문제의 해답을 발견한 탐정이라도 된 기분이었다. 왜 다들 이렇게 간단한 걸 어렵게 설명하는지 모를 일이었다. 비용을 줄이는 가장 확실한 방법은 당연히 가장 싼 걸 쓰는 것 아닌가? 90%라니, 이건 거의 공짜나 다름없었다.
“언니, 이것 좀 봐. EC2 비용, 그냥 전부 스팟 인스턴스로 바꾸면 되는 거 아니었어?”
솔라가 노트북 화면을 거실 소파에 앉아 있던 루나에게 돌리며 말했다. 루나는 읽고 있던 책에서 눈을 들어 화면을 물끄러미 바라보았다. 솔라의 목소리에는 명쾌한 해답을 찾았다는 자신감이 가득했다.
“스팟 인스턴스가 온디맨드 요금보다 훨씬 저렴하니까, 이걸로 모든 서버를 운영하면 비용이 엄청나게 줄어들 거라는 거지?”
“당연하지! 최대 90% 할인인데. 이 숫자 앞에서 다른 옵션을 고민하는 것 자체가 시간 낭비 아닐까? ‘워크로드 특성에 따라 조합한다’는 말이 있긴 한데, 결국은 비용 문제잖아.”
솔라는 마치 정답을 알고 있다는 듯 어깨를 으쓱했다. 루나는 잠시 생각에 잠기는 듯하더니, 손에 들고 있던 책을 조용히 내려놓았다.
“음, 솔라. 우리 지금부터 딱 5분 동안, 아주 중요한 온라인 콘서트 티켓 예매 사이트를 운영한다고 상상해 보자. 서버는 딱 한 대만 쓸 수 있고.”
“갑자기? 좋아. 재밌겠네.”
솔라는 루나의 뜬금없는 제안에 흥미를 보였다.
“그리고 그 서버, 네가 방금 찾은 스팟 인스턴스로 운영하는 거야. 비용을 아껴야 하니까.”
루나가 차분하게 상황을 설정했다. 솔라는 고개를 끄덕였다. 당연한 선택이었다.
“자, 이제 예매 시작. 1초 만에 동시 접속자 만 명이 몰려들고 있어. 서버는 터질 듯이 바쁘게 돌아가고, 실시간으로 예매 성공 알림이 뜨기 시작해. 매출이 쑥쑥 오르는 게 눈에 보여.”
루나의 말에 솔라는 자기도 모르게 신이 나서 손뼉을 쳤다. “좋았어! 역시 내 선택이 옳았어. 서버 비용은 90%나 아끼면서 돈은 벌고 있잖아.”
그때였다. 루나가 솔라의 노트북을 향해 손을 뻗더니, 화면을 ‘탁’ 소리 나게 덮어버렸다.
“어…?”
순간 솔라의 얼굴에서 웃음기가 사라졌다.
“서버가 중단됐어.”
루나의 한마디에 방 안의 공기가 차갑게 식었다.
“뭐? 왜? 갑자기?”
“스팟 인스턴스는 원래 그래. AWS에 여유 컴퓨팅 자원이 있을 때 싸게 빌려주는 거라, 그 자원이 다른 곳에 필요해지면 언제든 회수해 갈 수 있거든. 2분 전에 미리 알려주긴 하지만, 막을 방법은 없어.”
솔라는 닫힌 노트북 화면을 멍하니 바라보았다. 만 명의 사용자가 동시에 튕겨져 나가는 모습, 결제 창에서 오류가 나는 화면, 소셜 미디어에 쏟아지는 불만과 환불 요구가 머릿속을 스쳐 지나갔다. ‘서버 터짐’, ‘예매 실패’ 같은 단어들이 실시간 검색어에 오를지도 모른다.
“우리가 아낀 서버 비용이 얼마였지? 그리고 지금부터 우리가 감당해야 할 손해는 얼마일까? 고객 불만 처리, 브랜드 이미지 실추, 환불 사태 수습 비용….”
루나는 덮었던 노트북 화면을 다시 열어주며 조용히 물었다. 화면 속 ‘최대 90% 할인’이라는 글자가 아까와는 전혀 다르게 보였다. 그 빛나던 숫자는 이제 함정처럼 느껴졌다. 비용 절감이라는 달콤함 뒤에 숨어 있던 ‘중단될 수 있다’는 위험의 무게가 비로소 현실적으로 다가왔다.
솔라는 잠시 입을 다물고 있었다. 할인율이라는 숫자 하나에만 갇혀 있던 시야가 그제야 넓어지는 기분이었다. 비용은 단순히 지출되는 돈의 액수가 아니었다. 안정적으로 서비스를 운영하지 못했을 때 발생하는 모든 유무형의 손실까지 포함하는 개념이었다.
“…90% 할인이 그냥 공짜가 아니었구나.”
솔라는 혼잣말처럼 중얼거렸다. 루나의 말이 맞았다. 가장 저렴한 선택이 항상 가장 경제적인 선택은 아니었다. 가격표 뒤에 붙어 있는 ‘조건’을 함께 보아야 했다.
“그럼, 스팟 인스턴스는 아예 쓰면 안 되는 거네? 이렇게 위험하다면 도대체 어디에 쓰는 거지?”
이제 솔라의 머릿속에는 새로운 질문이 떠올랐다. 방금 전까지만 해도 최고의 선택지였던 스팟 인스턴스가, 이제는 쓸모없는 옵션처럼 보였다. 가격과 안정성이라는 저울의 한쪽으로 완전히 기울어져 버린 것이다.
2장: 스팟 인스턴스, 중단돼도 괜찮아? 워크로드 특성 파악하기
솔라는 포스트잇 한 뭉치를 들고 서재의 화이트보드 앞에 서 있었다. 화이트보드에는 검은색 마커로 그은 선 하나가 세로로 길게 뻗어 있었다. 왼쪽에는 ‘절대 중단 불가’라고 쓰여 있었다. 방금 전 온라인 콘서트 예매 서버가 터져버리는 끔찍한 상상을 한 뒤, 솔라는 자사의 모든 서비스를 목록으로 만들어 보았다. 그리고는 하나씩 포스트잇에 적어 그 선 왼쪽에 모조리 붙여버렸다.
‘실시간 채팅 서버’, ‘메인 웹사이트’, ‘사용자 데이터베이스’, ‘결제 게이트웨이’… 포스트잇들은 마치 중력을 거부하듯 ‘절대 중단 불가’ 영역에 빽빽하게 달라붙어 있었다. 오른쪽 영역은 텅 비어 있었다. 솔라의 생각에 ‘중단되어도 괜찮은’ 워크로드는 존재하지 않았다.
“이것 봐, 언니. 우리 서비스 중에 중단되어도 괜찮은 건 하나도 없어. 결국 스팟 인스턴스는 그림의 떡이었던 거야. 위험하기만 하고 쓸모는 없는.”
솔라는 화이트보드를 가리키며 단호하게 말했다. 그녀의 목소리에는 실망감과 함께, 이 위험한 옵션을 완전히 배제하기로 결정했다는 후련함이 섞여 있었다. 소파에서 이 모습을 지켜보던 루나는 조용히 일어나 솔라의 곁으로 다가왔다. 루나는 ‘절대 중단 불가’ 영역을 가득 채운 포스트잇들을 잠시 훑어보았다.
“음, 솔라. 내일 아침까지 중요한 보고서를 제출해야 한다고 생각해 봐. 지금 너는 마지막 결론을 작성하는 중이야. 한 문장만 더 쓰면 완성돼. 그때 누군가 와서 컴퓨터 전원을 꺼버리면 어떨 것 같아?”
“당연히 안 되지! 마감이 코앞인데. 그건 재앙이야.”
솔라는 미간을 찌푸리며 대답했다. 루나의 질문은 당연해 보였다.
“맞아. 그건 ‘절대 중단 불가’ 작업이지.”
루나는 솔라의 화이트보드를 손가락으로 가리켰다.
“그런데, 그 보고서를 쓰기 위해 어젯밤부터 10시간짜리 데이터 분석 스크립트를 돌리고 있었다면 어떨까? 스크립트가 8시간쯤 돌았을 때 잠시 중단됐지만, 10분 뒤에 다시 실행해서 8시간 지점부터 이어서 분석을 재개할 수 있어. 최종 마감 시간은 아직 한참 남았고.”
솔라는 잠시 생각에 잠겼다. 보고서 결론 작성과 데이터 분석 스크립트. 둘 다 보고서를 완성하기 위한 중요한 과정이었지만, 성격이 완전히 달랐다. 하나는 중단되는 순간 모든 것이 어그러지는 작업이었고, 다른 하나는 잠시 멈췄다 다시 시작해도 최종 결과물에 아무런 영향을 주지 않는 작업이었다.
“…그건 괜찮을 것 같아. 조금 늦어지긴 하겠지만, 결과가 달라지는 건 아니니까.”
“바로 그거야.”
루나가 말했다. 솔라의 시선이 다시 화이트보드로 향했다. ‘절대 중단 불가’라는 단 하나의 기준으로 모든 것을 재단했던 자신의 생각이 흔들리기 시작했다. 그녀는 포스트잇 더미 속에서 ‘대규모 데이터 분석’이라고 적힌 것을 찾아 떼어냈다.
“이 분석 작업… 이건 마감 직전의 보고서 작성이라기보단, 밤새 돌리는 데이터 분석 스크립트에 가깝네.”
솔라는 중얼거리며 그 포스트잇을 들고 잠시 망설였다. 그리고는 화이트보드 오른쪽의 텅 빈 공간에 조심스럽게 붙였다. 이어서 ‘주기적인 이미지 렌더링’이라고 적힌 포스트잇도 떼어 오른쪽으로 옮겼다. 렌더링 작업이 중간에 실패하면 처음부터 다시 시작해야 하는 경우도 있지만, 보통은 자동으로 재시도하도록 설정해두니 괜찮을 것 같았다.
화이트보드 위에는 새로운 질서가 생겨나고 있었다. 왼쪽에는 사용자와 직접 상호작용하며 상태를 유지해야 하는 ‘상태 저장(Stateful)’ 워크로드들이 남았다. 오른쪽에는 중단되더라도 처음부터 다시 시작하거나 특정 지점부터 이어갈 수 있는 ‘무상태(Stateless)’ 혹은 ‘내결함성(Fault-tolerant)’ 워크로드들이 모였다. AWS 문서에서 무심코 지나쳤던 ‘내결함성, 유연성, 무상태 워크로드’라는 단어가 이제야 구체적인 모습으로 다가왔다.
“아하! 중요한 건 ‘중단 가능성’ 자체가 아니라, 우리 워크로드의 ‘중단 허용도’였구나.”
솔라는 유레카를 외치듯 말했다. 그녀는 이제 자신만의 ‘중단 허용도 판별기’를 갖게 된 셈이었다. 가격표와 안정성 사이에서 극단적으로 오가던 시선이, 이제는 워크로드의 ‘특성’이라는 새로운 기준점을 찾았다.
스팟 인스턴스는 더 이상 쓸모없는 옵션이 아니었다. ‘중단 허용도’가 높은 특정 작업들에 한해서는 여전히 매력적인, 아니 가장 압도적인 비용 절감 카드였다. 솔라는 오른쪽으로 옮겨진 포스트잇들을 보며 만족스러운 미소를 지었다.
하지만 그 미소는 오래가지 않았다. 그녀의 시선이 다시 화이트보드 왼쪽에 남겨진, 여전히 더 많은 수의 포스트잇들로 향했다.
“좋아. 분석이나 렌더링 작업은 스팟 인스턴스로 비용을 아낄 수 있겠어. 그런데… 정말 중요한 이 핵심 서비스들은 어떡하지? 웹사이트, 데이터베이스처럼 절대 중단되면 안 되는 것들 말이야. 이것들은 결국 비싼 온디맨드를 계속 쓸 수밖에 없는 걸까? 안정적으로 운영하면서 비용을 줄일 방법은 정말 없는 거야?”
3장: 안정적이지만 저렴하게? Savings Plans의 약정 효과
솔라는 화이트보드 앞에 꼼짝 않고 서 있었다. 시선은 ‘절대 중단 불가’라고 적힌 왼편 영역에 가득한 포스트잇들에 고정되어 있었다. ‘메인 웹사이트’, ‘사용자 데이터베이스’, ‘실시간 채팅 서버’… 중단되는 순간 서비스 전체가 마비될, 회사의 심장과도 같은 워크로드들이었다. 스팟 인스턴스라는 강력한 할인 카드를 손에 쥐었지만, 정작 가장 중요한 이곳에는 쓸 수 없었다.
그녀는 노트북을 열어 온디맨드 인스턴스의 시간당 요금을 다시 확인했다. 숫자를 볼수록 한숨이 나왔다. 안정성을 지키기 위해 치러야 할 대가가 너무 비쌌다. 화이트보드 오른편, 스팟 인스턴스로 비용을 절감할 수 있게 된 몇몇 워크로드의 성과가 초라해 보일 정도였다. 결국 핵심 서비스의 막대한 비용은 그대로 끌어안고 가야 하는 걸까? 안정성과 비용 절감은 정말 양립할 수 없는 걸까. 솔라는 답답한 마음에 마커펜 뚜껑을 열었다 닫았다 반복했다.
“그렇게 뚫어져라 쳐다보면 비용이 줄어들기라도 한대?”
소파에 앉아 있던 루나가 웃으며 물었다. 그녀는 솔라가 책상 위에 아무렇게나 던져 둔 스마트폰 고지서를 가리켰다.
“그것보다는 네 핸드폰 요금 고지서를 보는 게 더 도움이 될지도 모르겠네.”
“핸드폰 요금? 그건 갑자기 왜?”
솔라는 어리둥절한 표정으로 고지서를 집어 들었다. 매달 날아오는 익숙한 숫자들. 데이터 무제한 요금제, 월 8만 원.
“너 그 요금제, 약정 걸려 있지 않아? 2년 약정 같은 거.”
“응. 당연하지. 약정 안 걸면 11만 원인데, 누가 그걸 그냥 내.”
솔라는 너무나 당연한 걸 묻는다는 듯 대답했다. 약정을 걸면 통신사가 요금을 할인해준다는 건 상식이었다.
“그렇지? 매달 꾸준히 쓸 게 확실하니까, 미리 약속하고 할인을 받는 거잖아. 2년 동안 통신사를 바꾸지 않고 이 요금제를 유지하겠다고.”
루나가 차분하게 말했다.
“중간에 해지하면 위약금을 내야 하는 위험이 있지만, 어차피 계속 쓸 거니까. 그 약속 덕분에 넌 매달 3만 원씩, 2년이면 총 72만 원을 아끼는 셈이고.”
그 순간, 솔라의 머릿속에서 무언가 ‘탁’ 하고 연결되는 느낌이 들었다. 그녀의 시선이 스마트폰 고지서에서 화이트보드 왼편의 포스트잇들로 빠르게 옮겨갔다. ‘매달 꾸준히 쓸 게 확실하니까….’
‘메인 웹사이트’, ‘사용자 데이터베이스’. 이 서비스들은 회사가 문을 닫지 않는 한, 1년 365일 내내 단 한 순간도 꺼지지 않고 실행되어야 한다. 사용량이 조금씩 변동할 수는 있어도, 기본적인 사용량은 언제나 존재한다. 마치 매달 꼬박꼬박 나가는 핸드폰 요금처럼, 예측 가능하고 지속적인 지출이었다.
“아…!”
솔라는 나지막한 탄성을 내뱉었다. 자신이 놓치고 있던 것이 무엇인지 깨달았다. 온디맨드 요금은 약정 없는 핸드폰 요금과 같았다. 언제든 해지할 수 있는 자유가 있는 대신, 가장 비싼 가격을 지불하는 것. 그렇다면 이 꾸준한 워크로드에도 ‘약정’을 걸 수 있지 않을까?
“언니, 설마 EC2에도 그런 게 있어? ‘우리가 이만큼은 꾸준히 쓸 테니, 요금을 할인해달라’고 약속하는 그런 구매 방식?”
“빙고. 그게 바로 ‘Savings Plans’야.”
루나가 대답했다. ‘Savings Plans’. 솔라는 AWS 문서를 훑어볼 때 스쳐 지나갔던 그 단어를 떠올렸다. 당시에는 복잡해 보여 그냥 넘어갔었다. 하지만 핸드폰 요금 약정이라는 익숙한 개념에 빗대어 보니, 그 원리가 명확하게 이해되기 시작했다.
“Savings Plans는 1년 또는 3년의 기간을 약정하고, 시간당 특정 금액(예: $10/hour)의 컴퓨팅 사용량을 약속하는 거야. 그 약속의 대가로 온디맨드 요금보다 훨씬 저렴한 할인율을 적용받는 거지.”
이제 솔라에게 화이트보드 왼편은 더 이상 비싼 비용을 감수해야만 하는 절망의 벽이 아니었다. 거대한 비용 절감의 기회가 숨어있는 금광처럼 보였다. 그녀는 마치 자신만의 ‘기간 약정 계산기’라도 생긴 듯, 머릿속으로 빠르게 계산을 시작했다. ‘이 웹서버는 최소 이 정도는 항상 켜져 있으니까, 이만큼은 약정을 걸 수 있겠네. 데이터베이스도 마찬가지고. 와, 이것만 해도…’
“알겠다! 결국 워크로드의 ‘지속성’과 ‘예측 가능성’이 핵심이구나. 스팟 인스턴스가 ‘중단 허용도’를 기준으로 삼았다면, Savings Plans는 이 두 가지를 기준으로 삼는 거였어.”
솔라는 신이 나서 외쳤다. 안정성이 필요하다고 해서 무조건 비싼 온디맨드를 쓸 필요는 없었다. 그 안정적인 사용량이 얼마나 예측 가능하고 지속적인지를 파악하면, ‘약정’이라는 현명한 카드를 꺼내 들 수 있었다.
흥분한 솔라는 곧장 노트북으로 달려가 ‘Savings Plans’를 검색했다. 화면에 할인율과 함께 두 가지 유형의 이름이 나타났다. ‘Compute Savings Plans’, 그리고 ‘EC2 Instance Savings Plans’.
“어? 그런데 이건 또 뭐지? Savings Plans에도 종류가 두 가지가 있네… Compute와 EC2 Instance라니. 어떤 걸 선택해야 할인율이 더 높은 거지? 아니, 둘은 뭐가 다른 거야?”
방금 전까지 명쾌했던 머릿속이 다시 새로운 질문으로 가득 찼다. 금광을 발견했지만, 어떤 곡괭이를 써야 할지 다시 막막해진 기분이었다.
4장: Compute vs. EC2 Instance Savings Plans, 어떤 유연성을 선택할까?
솔라의 노트북 화면이 두 개의 브라우저 창으로 나뉘어 있었다. 왼쪽에는 ‘Compute Savings Plans’의 설명이, 오른쪽에는 ‘EC2 Instance Savings Plans’의 설명이 떠 있었다. 화면 중앙에는 솔라가 막 작성한 간단한 메모장 파일이 열려 있었다.
* Compute SP: 최대 66% 할인
* EC2 Instance SP: 최대 72% 할인 <-- 이거다!화살표까지 그려 넣은 모습에서 그녀의 결론은 명확해 보였다. 같은 약정이라면 당연히 할인율이 높은 쪽을 선택해야 했다. 6%의 차이는 결코 무시할 수 없는 숫자였다. 솔라는 만족스러운 미소를 지으며, 이제 이 결정으로 얼마나 비용을 아낄 수 있을지 계산해볼 참이었다. 이 간단한 비교조차 하지 않고 고민하는 사람들은 대체 뭘 망설이는 걸까, 하는 생각마저 들었다.
“결정했나 보네.”
어느새 다가온 루나가 솔라의 노트북 화면을 들여다보며 말했다.
“응. 당연히 EC2 Instance Savings Plans지. 같은 1년 약정인데 할인율이 6%나 더 높잖아. 이건 고민할 필요도 없는 문제였어.”
솔라는 자신만만하게 대답했다. 루나는 고개를 끄덕이더니, 잠시 생각에 잠긴 후 새로운 질문을 던졌다.
“만약 네가 뷔페 레스토랑을 운영한다면, 어떤 주방장과 계약하고 싶어?”
“뷔페 레스토랑? 갑자기?”
솔라는 또 시작이라는 표정을 지었지만, 이내 흥미를 보였다.
“두 명의 후보가 있어. 첫 번째는 한식 대가야. 갈비찜 하나는 세계 최고지. 대신 다른 요리는 전혀 못 해. 오직 갈비찜만 만들 수 있어. 계약하면 인건비가 아주 저렴해.”
“두 번째는? 양식, 중식, 일식 다 할 줄 아는 멀티플레이어 요리사. 맛은 한식 대가보다 조금씩 덜하지만, 모든 메뉴를 평균 이상으로 만들어내. 대신 인건비는 한식 대가보다 조금 더 비싸.”
루나의 설명이 끝나자, 솔라는 잠시 고민에 빠졌다. 처음에는 당연히 인건비가 싼 한식 대가라고 생각했지만, ‘뷔페 레스토랑’이라는 조건이 마음에 걸렸다.
“우리 뷔페가 ‘궁중 갈비찜 전문 뷔페’라면 당연히 첫 번째 요리사지. 하지만 그냥 일반적인 뷔페라면… 손님들은 다양한 음식을 원할 테니까. 내일 당장 파스타 메뉴를 추가해야 할 수도 있고, 계절 메뉴로 초밥을 내야 할 수도 있잖아. 갈비찜 장인만 있어서는 레스토랑 운영이 안 되겠네. 조금 더 비싸도 두 번째 요리사가 필요하겠어.”
“바로 그거야.”
루나가 솔라의 노트북 화면을 가리켰다. 솔라의 시선이 ‘EC2 Instance Savings Plans’와 ‘Compute Savings Plans’라는 이름으로 다시 돌아갔다.
“EC2 Instance Savings Plans가 바로 그 ‘한식 대가’야.”
루나가 말했다.
“특정 지역(예: 서울 리전)의 특정 인스턴스 패밀리(예: m5)만 사용하겠다고 콕 집어서 약속하는 거야. 마치 ‘우리 레스토랑은 앞으로 3년간 갈비찜만 팔겠다’고 약속하는 것처럼. 아주 구체적이고 확고한 약속이기 때문에, AWS는 더 높은 할인율(최대 72%)을 제공해주는 거지.”
솔라의 눈이 커졌다. ‘최대 72% 할인’이라는 숫자 뒤에 숨어 있던 ‘제약 조건’이 비로소 보이기 시작했다. 만약 나중에 더 좋은 성능의 m6 인스턴스가 나와서 바꾸고 싶거나, 다른 리전으로 서비스를 확장해야 한다면 이 할인은 적용받을 수 없게 된다. 마치 갈비찜 장인에게 갑자기 파스타를 만들어달라고 할 수 없는 것처럼.
“그럼… Compute Savings Plans는 그 멀티플레이어 요리사겠구나.”
솔라는 스스로 답을 찾았다.
“맞아. Compute Savings Plans는 특정 인스턴스 패밀리나 리전에 얽매이지 않아. 심지어 EC2뿐만 아니라 Fargate나 Lambda 같은 다른 컴퓨팅 서비스에도 할인이 자동으로 적용되지. 약속의 범위가 ‘EC2 m5 인스턴스 사용량’이 아니라 ‘시간당 컴퓨팅 사용량’ 그 자체거든. 어떤 요리든 해주는 대신 인건비가 조금 더 비싼 요리사처럼, 엄청난 유연성을 제공하는 대신 할인율이 EC2 Instance SP보다 조금 낮은 거야.”
솔라는 자신이 작성했던 메모장의 ‘<— 이거다!’라고 적힌 화살표를 조용히 지웠다. 단순한 할인율 비교가 얼마나 어리석은 생각이었는지 깨달았다. 중요한 것은 워크로드의 ‘미래’였다.
‘우리 웹 서비스는 앞으로 2~3년 동안 아키텍처를 바꿀 계획이 있는가?’ ‘다른 리전으로 확장할 가능성은?’ ‘EC2 외에 Fargate나 Lambda를 함께 사용하고 있나, 혹은 사용할 계획이 있나?’
이런 질문들에 ‘아니오’라고 확신할 수 있다면, 한식 대가, 즉 EC2 Instance Savings Plans가 최고의 선택일 것이다. 하지만 하나라도 ‘예’ 또는 ‘그럴 수도 있다’는 답이 나온다면, 조금 덜 할인받더라도 무엇이든 가능한 멀티플레이어 요리사, 즉 Compute Savings Plans가 훨씬 현명한 선택이었다.
“결국 이것도 워크로드의 ‘특성’을 파악하는 문제였네. 이번엔 ‘변동성’과 ‘범위’라는 특성.”
솔라는 중얼거렸다. 그녀는 이제 두 가지 Savings Plans를 놓고 어느 것이 더 좋다고 말하는 대신, 어떤 워크로드에 어떤 SP가 더 적합한지를 판단하는 새로운 기준을 갖게 되었다. 유연성과 할인율 사이의 관계를 보여주는 비교표가 머릿속에 그려졌다.
모든 조각이 맞춰지는 느낌이었다. 약정 없이 가장 유연하지만 비싼 ‘온디맨드’, 중단될 수 있지만 가장 저렴한 ‘스팟 인스턴스’, 그리고 안정적인 사용량을 약속하며 할인을 받는 두 종류의 ‘Savings Plans’까지. 각각의 구매 옵션이 가진 고유한 성격과 장단점이 명확해졌다.
이제 남은 것은 마지막 질문이었다.
“좋아, 이제 각각의 도구는 전부 이해했어. 그럼 이 도구들을 어떻게 사용해야 하지? 우리 서비스는 일정한 기본 사용량도 있고, 갑자기 트래픽이 폭증할 때도 있고, 밤에는 분석 작업을 돌리기도 하는데… 이 모든 상황에 맞춰서 온디맨드, 스팟, 그리고 두 가지 Savings Plans를 어떻게 조합해야 최적의 전략이 되는 걸까?”
5장: 워크로드에 맞춤 전략: EC2 구매 옵션 최적 조합 찾기
5. 워크로드에 맞춤 전략: EC2 구매 옵션 최적 조합 찾기
솔라는 거실 바닥에 주저앉아 커다란 스케치북을 펼쳐놓고 있었다. 스케치북 위에는 삐뚤빼뚤하지만 제법 그럴듯한 그래프 하나가 그려져 있었다. 하루 동안의 EC2 사용량을 나타내는 그래프였다. 꾸준히 유지되는 낮은 구간, 점심시간과 저녁에 완만하게 솟아오르는 언덕, 그리고 예측할 수 없이 갑자기 튀어 오르는 몇 개의 뾰족한 봉우리들. 완벽한 우리 서비스의 하루였다.
문제는 그 다음이었다. 스케치북 주변에는 솔라가 그동안 모은 무기들이 어지럽게 흩어져 있었다. ‘온디맨드: 가장 비싸지만 유연함’이라고 적힌 메모, ‘스팟 인스턴스: 최대 90% 할인, 중단 가능’ 포스트잇, ‘EC2 Instance SP: 할인율 높음, 제약 많음’, ‘Compute SP: 유연함, 할인율 조금 낮음’이라고 비교해놓은 표까지. 솔라는 이 도구들을 그래프 위에 어떻게든 배치해보려 애썼다. 스팟 포스트잇을 뾰족한 봉우리에 붙여보았다가, SP 메모를 낮은 구간에 대보기도 했다. 하지만 결과물은 그저 지저분한 스크랩북일 뿐, 어떤 통일된 전략도 보이지 않았다. 각 도구의 성능은 알지만, 이것들을 어떤 순서로, 어떤 비율로 조립해야 할지 감이 잡히지 않았다.
“각각은 다 이해했는데… 이걸 합치려니 뒤죽박죽이네.”
솔라는 한숨을 쉬며 턱을 궤었다. 마치 성능 좋은 엔진, 튼튼한 바퀴, 편안한 좌석을 각각 구해놓고도 정작 자동차를 만들지 못하는 기분이었다.
소파에서 책을 읽던 루나가 솔라의 중얼거림을 들었는지, 조용히 다가와 스케치북을 들여다보았다. 어지럽게 흩어진 메모들과 그 아래 깔린 워크로드 그래프를 잠시 보던 루나는, 아무 말 없이 부엌으로 가 투명한 유리컵 세 개를 겹쳐 들고 왔다. 그리고는 컵을 스케치북 옆에 내려놓았다.
“자동차를 조립하는 게 아니라, 칵테일을 만든다고 생각해 보는 건 어때?”
“칵테일?”
솔라는 뜬금없는 비유에 고개를 갸웃했다. 루나는 가장 아래에 있던 크고 넓은 컵을 먼저 집어 들었다.
“모든 칵테일에는 베이스가 되는 술이 있지. 가장 많은 양을 차지하고, 전체적인 맛의 중심을 잡아주는. 네 그래프에서 이 베이스에 해당하는 부분은 어디일까? 하루 종일, 일 년 내내 변함없이 깔려 있는 부분 말이야.”
루나의 손가락이 스케치북 그래프의 가장 낮은, 평평한 지대를 조용히 가리켰다. 솔라의 눈이 번쩍 뜨였다. 그녀는 항상 켜져 있는 웹 서버와 데이터베이스를 떠올렸다. 예측 가능하고, 지속적인 사용량.
“아… 기반 사용량(Baseline Usage)! 이 부분은 절대 꺼지지 않으니까, 가장 확실하게 약속할 수 있는 영역이네. 그렇다면…”
솔라는 ‘EC2 Instance Savings Plans’ 메모를 집어 들었다. ‘우리 서비스는 앞으로 1년간 m5 인스턴스 패밀리를 서울 리전에서 꾸준히 쓸 거야’라고 확신할 수 있다면, 가장 높은 할인율을 받는 것이 현명했다. 만약 미래에 아키텍처 변경 가능성이 있다면, 유연한 ‘Compute Savings Plans’가 더 나은 선택일 것이다. 솔라는 스케치북에 새로운 페이지를 넘겨, 그래프의 맨 아래에 두꺼운 사각형을 그리고 ‘Savings Plans (기반)’이라고 적었다. 마치 칵테일 잔의 바닥에 묵직한 베이스 리큐어를 붓는 것 같았다.
“좋아. 그럼 베이스 위에는 뭘 더할까?”
루나는 두 번째로 큰 컵을 집어 들었다. “매일 점심이나 저녁처럼 사용량이 늘어나는 건 예측 가능하지만, 계속 유지되지는 않지. 이 변동성을 어떻게 감당할까?”
이 부분은 Savings Plans로 모두 약정하기엔 부담스러웠다. 약정한 양보다 적게 쓰면 돈을 낭비하는 셈이니까. 그렇다고 모두 비싼 가격을 낼 필요는 없었다. 솔라는 잠시 고민하다 ‘온디맨드’ 메모를 집어 들었다. 그리고 방금 그린 SP 사각형 위에, 언덕 모양의 사용량 그래프를 따라 ‘온디맨드 (변동성)’라고 덧그렸다. 필요할 때 필요한 만큼만 쓰고, 사용이 끝나면 바로 끌 수 있는 유연함이 이 영역에 딱 맞았다.
“마지막으로…”
루나가 가장 작고 얇은 컵을 들어 보이며 그래프의 뾰족한 봉우리들을 가리켰다.
“예측할 수 없는 트래픽 폭증이나, 혹은 지금 당장 처리하지 않아도 되는 대규모 분석 작업은?”
“그건 스팟 인스턴스!”
솔라는 망설임 없이 외쳤다. 중단되어도 괜찮은 작업들이나, 잠시 급증하는 트래픽을 저렴하게 처리하기에 이보다 더 좋은 도구는 없었다. 그녀는 온디맨드 영역 위로 삐죽삐죽 튀어나온 봉우리들을 다른 색 펜으로 칠하고 ‘스팟 인스턴스 (단발성/중단 가능)’라고 이름 붙였다.
솔라는 자신이 완성한 그림을 물끄러미 바라보았다. 지저분했던 스크랩북과는 전혀 다른, 명확하고 안정적인 구조의 다이어그램이 눈앞에 있었다. 가장 아래에는 ‘Savings Plans’라는 단단한 기반이 비용의 중심을 잡고, 그 위를 ‘온디맨드’가 유연하게 감싸고 있으며, 꼭대기의 ‘스팟 인스턴스’가 비용 효율을 극대화하는 형태였다. 이것은 단순한 가격 비교가 아니라, 워크로드의 특성이라는 설계도 위에 각기 다른 구매 옵션을 순서대로 쌓아 올린, 하나의 아키텍처였다.
“알겠다… 이건 그냥 부품을 따로따로 최적화하는 게 아니었어. 워크로드의 성격에 맞춰서, 안정적인 기반부터 유연한 상층부까지 층층이 쌓아 올리는 거였구나.”
솔라는 더 이상 망설이지 않았다. 그녀는 노트북을 열어 실제 회사의 사용량 대시보드를 띄웠다. 그리고 방금 스케치북에 그렸던 것처럼, 실제 워크로드 그래프 위에 자신만의 비용 최적화 전략 보고서를 그리기 시작했다. 기반 사용량을 계산하여 SP 약정 금액을 정하고, 변동 구간에 필요한 온디맨드 용량을 예측하고, 스팟 인스턴스를 적용할 수 있는 작업을 식별해냈다. 더 이상 막막하지 않았다. 그녀는 이제 자신만의 ‘EC2 비용 전략 시뮬레이터’를 갖게 된 것이다.