마법처럼 나타나는 군대 (Auto Scaling)
문과생 성시은의 AWS 정복기
“지배인(로드 밸런서)이 손님들을 여러 테이블(EC2)로 잘 나눠주는 건 알겠습니다. 그런데… 만약 그 테이블들이 전부 꽉 차면요? 그럼 또다시 줄을 서야 하는 거 아닌가요?”
다음 날 아침, ‘이노베이트’의 사무실은 전날의 패배감 대신 비장한 결의로 가득했다. 화상 회의 화면 너머로 보이는 안민준에게 성시은이 물었다. 그녀의 눈은 밤샘 공부로 퀭했지만, 그 어느 때보다 총명하게 빛나고 있었다. 어젯밤 그녀는 ‘로드 밸런서’에 대한 모든 유튜브 영상과 기술 블로그를 닥치는 대로 읽었다.
“아주 좋은 질문입니다. 핵심을 짚으셨군요.” 민준이 만족스러운 듯 고개를 끄덕였다. “어제 우리는 문을 여러 개 만드는 법을 배웠습니다. 하지만 손님이 계속 몰려들면, 결국 가게 안이 꽉 차서 문을 더 만들어도 소용이 없게 되겠죠. 그래서 우리에게는 ‘마법 같은 능력’이 하나 더 필요합니다.”
그는 화면에 손가락을 튕기는 시늉을 했다.
“손님 줄이 길어지는 걸 본 레스토랑 주인이, 손가락을 한번 튕기는 것만으로 순식간에 가게가 옆으로 확장되면서 새로운 테이블과 주방장이 뿅 하고 나타나는 능력 말입니다.”
“네? 그런 게 가능한가요? 판타지 소설도 아니고요.” 이철민이 믿을 수 없다는 듯 물었다.
“클라우드에서는 가능합니다.” 민준의 목소리에 장난기가 섞였다. “그걸 ‘오토 스케일링(Auto Scaling)’, 자동 확장이라고 부릅니다.”
그는 화면 공유를 통해 간단한 도식을 그렸다. 입구에 ‘지배인(ELB)’이 서 있고, 그 뒤로 ‘계산대(EC2)’들이 여러 개 놓여 있었다. 그리고 그 전체를 ‘오토 스케일링 그룹’이라는 커다란 테두리가 감싸고 있었다.
“오토 스케일링 그룹은 일종의 ‘인력 관리 자동화 시스템’입니다. 우리는 이 시스템에 아주 구체적인 규칙만 알려주면 됩니다. 예를 들어, ‘우리 가게에 있는 모든 계산대의 평균 작업량이 70%를 넘으면, 즉시 새로운 계산대를 하나 더 만들어라’ 같은 규칙이죠.”
그는 말을 이었다. “반대로, ‘손님이 없어서 평균 작업량이 30% 아래로 떨어지면, 괜히 전기세만 나가니 놀고 있는 테이블 하나를 없애서 비용을 아껴라’는 규칙도 가능합니다. 필요할 때만 나타나고, 일이 끝나면 사라지는 군대 같은 거죠.”
마법이었다. 사람의 개입 없이, 시스템이 스스로 상태를 판단하고 자원을 늘리거나 줄인다니. 이것은 단순히 서버를 여러 대 띄워놓는 것과는 차원이 다른 이야기였다. 살아 숨 쉬는 유기체처럼, 수요에 따라 스스로의 몸집을 조절하는 인프라.
“그런데… 시스템이 ‘테이블이 꽉 찼다’는 걸 어떻게 아나요? 누가 계속 지켜보고 알려줘야 하는 거 아닌가요?”
박서준이 날카로운 질문을 던졌다.
“물론입니다.” 민준이 답했다. “그래서 우리 가게에는 아주 예민한 ‘센서’가 필요합니다. 각 테이블마다 센서를 붙여서, ‘지금 얼마나 바쁜지(CPU 사용률)’, ‘손님이 얼마나 많이 오는지(네트워크 트래픽)’ 같은 정보를 실시간으로 중앙 관제실로 보내는 거죠. 그 신경계가 바로 ‘클라우드워치(CloudWatch)’입니다.”
그는 도식에 ‘CloudWatch’라는 눈 모양 아이콘을 그리고, 각 EC2와 연결했다.
“우리는 클라우드워치에 ‘경보(Alarm)’를 설정할 수 있습니다. ‘만약 5분 동안 평균 CPU 사용률이 70%를 넘으면, 즉시 사이렌을 울려라!’ 하고요. 그럼 그 사이렌 소리를 들은 오토 스케일링 시스템이, 약속된 규칙에 따라 새로운 테이블을 만들어내는 겁니다. 모든 것이 자동이죠.”
“자, 그럼 지금부터 마법을 한번 부려보죠.”
그날은 ‘이노베이트’에게 역사적인 날이 되었다. 안민준의 원격 지휘 아래, 어제의 적이었던 박서준과 이철민은 다시 한 팀이 되어 움직였다. 그들의 눈에는 더 이상 패배감이 아닌, 새로운 무기를 손에 넣은 전사의 흥분이 감돌았다.
먼저, 새로운 EC2 인스턴스를 똑같이 찍어낼 ‘설계도’, 즉 ‘시작 템플릿(Launch Template)’을 만들었다. 어떤 종류의 인스턴스(t2.micro)를, 어떤 운영체제(Amazon Linux)와 소프트웨어(Node.js, Connect-AI)를 설치해서 만들 것인지 꼼꼼하게 정의하는 작업이었다. 마치 전투에 나갈 병사의 표준 장비를 정하는 것과 같았다.
다음으로, 이 설계도를 바탕으로 병사들을 관리할 ‘오토 스케일링 그룹(Auto Scaling Group)’을 설정했다. ‘최소 1대, 최대 10대의 인스턴스를 유지할 것’, 그리고 ‘평균 CPU 사용률이 70%를 넘으면 인스턴스를 2대씩 늘릴 것(스케일 아웃)’이라는 구체적인 규칙을 입력했다.
마지막으로, 모든 트래픽의 관문이 될 ‘로드 밸런서(ELB)’를 생성하고, 그 트래픽의 목적지를 방금 만든 오토 스케일링 그룹으로 지정했다. 이제 모든 손님은 지배인을 통해서만, 그리고 가장 한가한 계산대로만 갈 수 있게 되었다.
몇 시간의 사투 끝에, 모든 설정이 끝났다. 박서준은 이마의 땀을 닦으며, 마치 수술을 마친 외과 의사처럼 말했다.
“대표님… 준비됐습니다.”
“좋아요.” 시은은 심호흡을 했다. 그녀의 심장이 미친 듯이 뛰었다. 이것은 단순한 테스트가 아니었다. 어제의 굴욕을 갚아줄 복수전이었다. “철민 님, 어제 중단했던 이벤트, 다시 시작해 주세요. 이번엔… 두 배로 갑시다. 모든 채널에 동시에 뿌려주세요.”
“옛썰!”
이벤트 공지가 다시 올라가자, 거짓말처럼 트래픽이 몰려들기 시작했다. 어제보다 훨씬 더 거대하고, 포악한 파도였다. 모두가 숨을 죽이고 AWS 콘솔의 클라우드워치 화면을 지켜봤다. CPU 사용률 그래프가 수직으로 치솟으며 순식간에 70%를 넘어섰다.
“온다…!”
심장이 철렁 내려앉는 바로 그 순간, 마법이 일어났다.
클라우드워치 대시보드의 ‘CPU Utilization Alarm’ 상태가 ‘OK’에서 ‘ALARM’으로 바뀌며 붉게 빛났다. 그리고 거의 동시에, 오토 스케일링 그룹의 ‘실행 중인 인스턴스(InService)’ 숫자가 ‘1’에서 ‘3’으로 바뀌었다. 잠시 후, 트래픽이 더 거세지자 숫자는 다시 ‘5’로 바뀌었다.
화면 속에서, 보이지 않는 마법의 군대가 나타나 밀려드는 적들을 막아내는 것 같았다. 로드 밸런서 대시보드에서는 수천 개의 요청이 5대의 인스턴스에 고르게 분산되는 모습이 실시간으로 그려졌다. 웹사이트는 그 폭발적인 트래픽 속에서도 조금의 느려짐도 없이, 마치 한가로운 오후처럼 쾌적하게 반응했다.
“와….” 철민의 입에서 낮은 탄성이 터져 나왔다. “이게… 이게 클라우드구나.”
박서준은 말없이 화면을 바라보고 있었다. 그의 눈에는, 자신이 만든 시스템이 스스로 살아 움직이며 위기를 극복하는 모습을 지켜보는 창조주의 경이로움이 담겨 있었다.
몇 시간이 지나 트래픽의 정점이 지나가자, CPU 사용률은 서서히 떨어졌다. 그러자 이번에는 반대의 마법이 일어났다. 인스턴스 숫자가 5에서 3으로, 그리고 마침내 다시 1로 줄어들었다. 격렬했던 전투를 마친 군대가, 다음 전투를 위해 흔적도 없이 사라진 것이다. 그들은 어제의 위기를 막아냈을 뿐만 아니라, 앞으로 다가올 어떤 거대한 파도도 감당할 수 있는 강력한 무기를 손에 넣었다. 비용은? 딱 그 마법의 군대가 전투에 참여했던 몇 시간만큼만 지불하면 그만이었다.
시은은 피곤하지만 승리에 취한 팀원들을 둘러보았다. 어제 걸려왔던 한유라 팀장의 차가운 목소리가 떠올랐다. 그녀는 ‘이노베이트’가 작은 파도에 허우적대는 조각배라고 생각했겠지.
시은은 나지막이 웃으며 말했다.
“타이탄 코퍼레이션은 우리가 파도에 휩쓸려가는 줄 알았을 거야.”
그녀가 승리의 전리품인 대시보드 화면을 향해 눈을 빛냈다.
“우리가 방금 항공모함을 만들었다는 건 꿈에도 모르고 말이야.”
▶ 6화 기술 TIP
로드 밸런싱 (Load Balancing) & 오토 스케일링 (Auto Scaling): 이 두 서비스는 클라우드 아키텍처의 핵심적인 짝꿍입니다. 로드 밸런싱이 트래픽을 여러 서버로 ‘분산’하는 역할을 한다면, 오토 스케일링은 트래픽의 양에 따라 서버의 ‘숫자’ 자체를 조절하는 역할을 합니다. 이 둘이 함께 작동할 때, 시스템은 갑작스러운 트래픽 변화에도 흔들리지 않는 탄력성(Elasticity)과 고가용성(High Availability), 그리고 비용 효율성을 동시에 확보할 수 있습니다.
시작 템플릿 (Launch Template): 오토 스케일링 그룹이 새로운 EC2 인스턴스를 만들어낼 때 사용하는 ‘설계도’ 또는 ‘붕어빵 틀’입니다. 어떤 종류의 인스턴스(t2.micro 등), 어떤 운영체제 이미지(AMI), 어떤 보안 그룹과 IAM 역할(Role)을 적용할지 등을 미리 정의해 둡니다. 덕분에 모든 인스턴스가 동일한 구성으로 일관성 있게 생성될 수 있습니다.
오토 스케일링 그룹 (Auto Scaling Group, ASG): EC2 인스턴스들의 집합을 관리하는 컨테이너입니다. 이 그룹에 ‘최소/최대/희망’ 인스턴스 개수를 설정하고, ‘스케일링 정책’을 정의합니다. 예를 들어, ‘항상 최소 2대를 유지하고(고가용성 확보), 최대 10대까지 늘어날 수 있으며, 평소에는 2대를 유지하라’고 설정할 수 있습니다.
스케일링 정책 (Scaling Policy): 오토 스케일링 그룹이 언제, 어떻게 인스턴스 수를 조절할지를 결정하는 ‘규칙’입니다.
동적 스케일링 (Dynamic Scaling): 소설에서처럼 CPU 사용률, 네트워크 트래픽 같은 실시간 지표(Metric)에 따라 자동으로 확장(Scale-out)/축소(Scale-in)하는 가장 일반적인 방식입니다.
예측 스케일링 (Predictive Scaling): 과거의 트래픽 패턴을 머신러닝으로 분석하여, 트래픽이 몰릴 것을 ‘예측’하고 미리 인스턴스를 준비시키는 방식입니다.
예약 스케일링 (Scheduled Scaling): 매주 금요일 저녁 7시처럼, 특정 시간에 트래픽이 몰릴 것을 미리 알고 있을 때, 정해진 시간에 맞춰 인스턴스를 늘리거나 줄이도록 예약하는 방식입니다.
CloudWatch: AWS 리소스와 애플리케이션을 위한 모니터링 및 관찰 기능 서비스입니다. EC2의 CPU 사용률, 네트워크 사용량, 디스크 I/O 등 다양한 지표(Metric)를 수집하고 시각화합니다.
CloudWatch 경보 (Alarm): 특정 지표가 설정된 임계값을 넘었을 때 자동으로 작업을 트리거하는 기능입니다. 소설에서처럼 ‘CPU 사용률이 5분간 70% 이상’일 때 경보를 발생시켜 오토 스케일링 정책을 실행하게 하거나, 관리자에게 이메일(SNS 서비스 연동)을 보내는 등의 자동화된 조치를 취할 수 있습니다.
