[사례 공유] 아임웹은 갑자기 터지는 트래픽을 어떻게 감당하나(feat. AWS)

이 기사는 20일 서울 양재동 엘타워에서 열린 ‘아마존웹서비스(AWS) 유니콘 데이’에서 김형섭 아임웹 최고기술책임자(CTO)가 발표한 내용을 재구성한 것입니다. AWS는 내부에 스타트업팀을 두고, 각 회사의 성장 단계에 따른 비즈니스 및 기술 지원 프로그램을 제공하고 있는데요. 김형섭 CTO는 이날 AWS 솔루션을 가지고 어떻게 폭증하는 트래픽에 대처해왔는지 사례 발표를 했습니다. 여러 세션 중 김 CTO의 발표를 공유하는 이유는 △트래픽이 폭증하는 원인 △기존 서버 솔루션에서의 고민 △이를 어떻게 해결했는지 등을 비교적 알기 쉽고 상세하게 밝혀줬기 때문입니다.

먼저, 아임웹이란 회사를 소개부터 하겠습니다. 원래는 홈페이지를 만들어주는 회사로 시작했죠. 그런데 지금은 홈페이지를 모두들 쉽고 빠르게 만드는 세상이 되지 않았습니까. 그래서 회사가 표방하는 바는 ‘브랜드 빌더’가 됐습니다. 홈페이지 제작이라는 기본 틀을 갖고, 여기에 “코딩과 디자인을 모르더라도 누구나 쉽게 웹사이트와 쇼핑몰을 만들 수 있는 반응형 웹 빌더”로 전환한 것이죠. 작은 쇼핑몰이더라도, 자기 브랜드를 쌓아가려면 자체 홈페이지가 필요하기 때문에 아임웹이 이를 위한 서비스와 기술 지원을 하겠다는 뜻으로 읽힙니다.

아시겠지만, 이런 회사들은 필수적으로 특정 상황과 마주칩니다. 예측할 수도, 통제할 수도 없는 갑작스런운 트래픽 폭증이죠. 김형섭 CTO에 따르면 현재 아임웹을 통해 만들어져 운영되는 이용자 사이트는 70만여개 입니다. 아임웹은 이용자들이 사이트를 열어 운영할 수 있도록 플랫폼을 제공하지만, 사실 여기에서 어떤 이들이 어떤 쇼핑몰을 운영하는지 세세히 알지는 못하죠. 월 기준 1억 명 이상 방문자가 찾다보니 그 중 누군가의 사이트가 언제 트래픽이 폭증할지, 정말 예상할 수 없습니다.

그러다보니, 이런 일이 발생합니다. 김형섭 CTO의 육성으로 들어보시죠.

“아임웹을 이용하는 사이트에는 이커머스도 있고, 게임이나 숙박, 패션 등 굉장히 다양한 카테고리가 있어요. 아임웹을 이용하는 사이트의 수도 많지만, 평균적으로 분당 30만 건 정도의 트래픽 요청을 받고 있습니다. 그런데 심한 경우엔 평상시 트래픽의 60배 이상인 2000만건의 트래픽도 들어옵니다.”

대체 이렇게 많은 트래픽은 어디서 이렇게 갑작스레 들어올까요?

김 CTO는 상황을 세 가지로 정리합니다. 첫번째, 고객사의 이벤트죠. 아이돌이나 인플루언서 같은 유명인들도 모두 각자의 사이트를 운영하는 경우가 많은데요. 그런데 이들은 한날 한시 동시접속을 부르는 ‘한정판 판매’ 이벤트 같은 걸 자주 엽니다. 팬 미팅이나 혹은 콘서트 표 예매를 위해 PC방에서 총공격(?) 대기를 해보신 분들은 알텐데요. 이때 주로 서버가 터져 나갑니다. 페이지를 불러 올 수 없는 장애가 발생하죠.

또 다른 것은 고객사가 뉴스에 노출되는 때입니다. 사람들이 해당 회사나 인물이 궁금해 사이트 검색을 시도하겠죠? 또, 배너 광고나 포털 사이트에 메인 광고를 하는 경우도 트래픽을 몰아옵니다. 이 역시, 아임웹이 미리 알고 트래픽을 대비할 수 있는 사안은 아닙니다. 마지막으로 디도스(DDOS) 공격. 분산 서비스 공격도 생각보다 자주 일어납니다. 심지어는 경쟁 관계에 있는 두 회사가 서로간에 디도스 공격을 퍼붓는데 양측이 모두 아임웹을 쓰고 있어 트래픽 폭탄을 맞았더라는 슬픈데 어딘가 웃긴 이야기도 있었습니다. 이렇게 트래픽이 특정 회사에 몰렸을 때 더 큰 문제는, 아임웹의 인프라를 같이 쓰고 있는 전혀 다른 사이트도 장애라는 영향을 받을 수 있다는 겁니다.

여기까지 들으신 분이라면 그런 생각이 들 겁니다. “고객의 전용 AWS 테넌시를 만들어주면 하나의 사이트에 트래픽이 몰려도 다른 사이트에는 영향을 안 주지 않겠느냐”는 거죠.

왜 모르겠습니까. 알죠. 문제는 돈이죠. 70만 고객사의 테넌시를 모두 일일이 별도로 구축한다면, 지금의 이용자 사용료로는 감당할 수 없게 됩니다. 아임웹 이용료가 올라가야 하고, 이 경우 비싼 요금제에 부담을 느낀 고객사들이 떠나가는 상황이 머릿속에 그려집니다. 그래서 아임웹은 소프트웨어로만 고객들의 테넌시를 구분해 놓은 상태입니다. 결과적으로 사이트들이 공통의 인프라를 사용할 수밖에 없다는 뜻이죠.

자, 비용 때문에 공통의 테넌시를 제공할 수밖에 없는데 그렇다고 장애가 일어나는 걸 그대로 두고 볼 수도 없습니다. 쇼핑몰의 경우엔 특히나 그렇죠. ‘아임웹을 썼더니 자꾸 뻑이나, 그래서 손님이 결제를 실패하고 떠나’, 이런 상황이 닥치는 것은 정말 최악입니다.

“서비스가 너무 빨리 크다보니까 수시로 망가지고 장애가 너무 많이 났습니다. 장애가 났을 때 저희가 할 수 있는 말은 그저 ‘죄송하다’ 뿐이었고요. 개선 작업을 내부적으로 많이 했습니다만, 내부 리소스 한정이라는 한계가 있었죠. 그러다 재작년, 정말로 큰 장애를 맞은 이후로 본격적인 인프라 개선이 시작됐습니다.”

해결책을 찾아야죠? 인프라 개선 작업에 착수합니다. 미션은 “제어할 수 없는 영역에서 트래픽이 치솟아도 모두 받아낼 수 있도록 하자”입니다. 인플루언서의 이벤트? 그래, 그거 갑자기 해서 트래픽 폭증해도 우리가 다 받아내겠다, 이런 거죠.

아키텍처 개선에 들어갑니다. 개선하려면 제일 처음, 우리가 지금 어떤 상황에 처해있는지를 점검해야겠죠. 김형섭 CTO가 공개한 아임웹 초기 인프라는 아주 단순합니다.

AWS를 쓰긴 했지만 아주 기본적인 구성입니다. 아마존 클라우드 서버 호스팅인 EC2에 부하 분산을 위한 로드밸런서(ALB), 그리고 리소스 조정을 위한 오토 스케일링이 사실상 전부였죠. 그러다 보니 트래픽이 몰렸을 때 사실상 제대로 대처하기 어려웠다고 김형섭 CTO는 회고합니다. 이건 그냥 너무 기본 중의 기본만 갖춰놨었다는 거죠.

그래서 솔루션을 하나씩 더 붙였습니다. 우선은 디도스 공격을 막기 위한 AWS의 앱애플리케이션방화벽(WAF)을 붙입니다. 뭐가 달라졌냐고요? 디도스를 효과적으로 막기 위한 방어 전략을 상당히 잘 갖출 수 있게 됐다는 게 김 CTO의 설명입니다. 그러나, WAF 하나 붙였다고 트래픽 문제를 모두 해결할 수 있나요. 세상 일 그렇게 쉽지 않죠. 앞서 언급한 것처럼 디도스 말고도 트래픽 증대 원인은 더 있으니까요. 만약에, 사이트에서 판매하는 상품의 인기가 높아져 갑작스레 구매자가 몰려오는 걸 디도스로 알고 사이트를 막아 버린다면, 골치 아파지죠.

그 다음으로 추가한 것이 ‘비회원 로그인’ 입니다. 캐싱이라는 것이 데이터를 저장해놨다가 다시 꺼내 볼 수 있게 함으로써 애플리케이션의 처리 속도를 높여주는 것이잖아요. 비 로그인 유저 캐싱을 사용, 전체 트래픽의 절반을 캐싱하기 시작했다고 합니다. 일부 속도 개선의 효과가 있었으나, 그럼에도 불구하고 실제 상품을 구매하려 오는 이들의 트래픽은 캐싱할 수 없다는 문제에 부닥쳤죠.

마찬가지로 아직 장애가 발생하니 이제는 조금 더 근본적으로 인프라를 개선해야 할 필요를 느낍니다. 컨테이너로 바꿔보자. 그래서 도입한 것이 아마존 엘라스틱 컨테이너 서비스(Elastic Container Service, ECS)와 별도 서버 인프라 없이 애플리케이션을 구축하는 서버리스(Serverless)와 파게이트(Fargate)입니다.

어떤 변화가 있었냐고요?

“오토 스케일링의 속도가 빨라졌어요. 5분 걸리던 것이 15초 이내로 줄었습니다. 저희는 조금 더 최적화를 해서 5초 이내로 뜨게끔 설계를 해뒀고요. 이렇게 왔어도, 웹 서버는 잘 버티는데 데이터베이스가 또 멈추기 시작했습니다.”

이렇게 했는데도 왜 아직도 잘 안 되냐고요? 이제 곧 끝나갑니다. 이들은 AWS의 관계형 데이터베이스 오로라 2를 오로라 3로 업그레이드를 하면서 서비스의 절반은 온디맨드에 두고, 나머지 절반은 서버리스를 선택하는 ‘믹스드 클러스터’라는 걸 운영키로 합니다. AWS에서 제공하는 기능인데, 이걸 이용하면서는 “갑자기 늘어나고 줄어드는 트래픽에 대해 잘 버티기 시작했다”는 긍정적 효과를 봤죠. 하지만 그래도 갑작스런 큰 이벤트에는 장애가 일어나는 문제가 있었습니다.

결과적으로는 AWS가 제공하는 솔루션에 더해 아임웹이 자체적으로 만든 ‘자동 트래픽 격리 시스템’을 추가했습니다. 김 CTO는 “스케일 아웃을 얼마나 빨리 할 것인가의 속도 측면은 간단하게 AWS의 WAF를 쓰고 캐싱을 할 수 없는 서버사이드 랜더링이라고 하더라도 스마트하게 캐싱을 해보고, 그럼에도 불구하고 트래픽 방어가 안 될 때는 ‘격리’라는 시스템을 넣어보기로 했다”면서 “이 모든 걸 자동화해보기로 해서 만든 아키텍트”라고 다음의 그림을 소개합니다.