누가 내 트래픽을 옮겼을까
컴퓨터 서비스센터를 통해 기초적인 트래픽 대응 구조를 알아보자
목차
코로나19 이후 전세계 트래픽 증가 현황
서비스 센터를 운영해보자
IT 서비스 트래픽 대응 방식
결론
코로나 19 발생 이전의 세상은 다시 오지 않는다.
중앙방역대책본부 권준욱 부본부장이 브리핑에서 이와 같은 선언을 하였습니다. 코로나 19 이후 방역활동이 일상이 되야한다는 사실을 강조합니다. 많은 사람들이 오프라인 활동을 줄이고 온라인에서의 활동에 주목하고 있습니다. 오프라인 모임이 랜선모임으로 대체 됐으며 교육기관의 오프라인 수업이 온라인 수업으로 대체되었습니다. 심지어 애플의 개발자 컨퍼런스인 WWDC가 올해 처음으로 온라인에서 진행됐습니다. 바야흐로 언택트 시대가 도래했습니다.
사상 처음으로 온라인에서 개최된 WWDC 2020그렇다면 과연 코로나 19 발생 이후의 온라인 세상은 얼마나 커졌을까요? 독일 온라인 통계 포털 Statista에서 조사한 자료에 의하면 1400개의 사이트를 조사한 결과 20개 국에서 코로나 이전인 2020년 1월, 2020년 2월 보다 트래픽이 약 10.2% 증가, 트랜잭션이 32.9% 증가했다고 합니다. 코로나 19로 인해 트래픽이 증가한 대표적인 화상회의 서비스 줌(Zoom)은 2020년 2달 동안의 증가가 2019년 일년의 증가보다 많았다고 합니다.
그렇다면 IT 서비스 기업에서는 이번 코로나 19 이슈처럼 트래픽이 비정상적으로 증가하면 어떤 식으로 대응할까요? 실생활과 관련된 예를 들어 설명해보겠습니다. 우리가 컴퓨터 서비스 센터를 차렸다고 생각해봅시다. 사람들은 컴퓨터에 이상이 생기면 서비스 센터에 전화할 것입니다. 하지만 만약 서비스 센터의 전화번호가 특정 한 상담원의 전화번호라면 어떻게 될까요?
사용자가 상담원에게 전화할 때
서비스 센터의 전화번호가 특정 상담원의 번호라면 위 그림처럼 상담원이 최대 한 명 밖에 대응할 수 없을 것 입니다. 사용자 1와 상담원이 통화를 하고 있으므로 사용자 2는 통화를 할 수 없습니다. 사용자 2는 사용자 1이 통화를 끝낼 때까지 기다려야하고 상담원은 쉴 수가 없습니다.
위 상황에서 다른 사람이 전화를 한다면?
상담원과 전화번호를 추가하면 해결됩니다. 하지만...이런 구조에서 서비스 센터에서 동시에 여러 사용자를 응대하려면 전화번호를 사용자 수 만큼 더 늘려야 합니다. 상담원들 또한 전화번호 수 만큼 있어야 할 것 입니다. 만약 사용자 1이 상담원 1과 통화를 하고있다면 사용자 2는 상담원 1이 통화 중임을 확인한 후 상담원 2에게 전화를 할 것입니다.
우리는 문제를 해결했다고 생각했지만 문제점이 있습니다. 사용자 2가 상담원 1, 상담원 2의 번호 모두를 알고 있어야한다는 것입니다. 만약 상담원 1의 번호밖에 모른다면 위의 상황과 같은 결과가 나올 것 입니다. 상담원 1에게 전화만 오고 상담원 2에게는 전화가 오지 않는 상황이 올지도 모릅니다.
우리는 서비스 센터 전화번호를 안내하는 모든 홍보물에 상담원 1, 상담원 2의 전화번호를 기록하기로 했습니다. 하지만 이 방법에도 문제점이 있어보입니다. 만약 상담원을 늘어나게 된다면 홍보물을 전부 수정해야 합니다. 상담원 수가 많아지면 서비스 센터 주인인 저도 전화번호를 다 못 외울 상황이 올지도 모릅니다.
더이상 우리끼리 문제는 해결 못할 것 같으니 서비스 센터 운영 10년차인 똑똑한 친구에게 방법을 물어 보도록 합시다. 친구는 "교환기"에 대해 알려주었습니다. 교환기를 사용하면 특정 전화번호, 예를 들면 "031-123-3456"으로 전화할 경우 교환기를 통해 상담원과 사용자를 연결하는 구조로 변경할 수 있다고 합니다.
이제 사용자가 늘어나면 전화번호를 늘리고 홍보물을 수정할 필요없이 상담원만 늘리면 상담원만 늘리면 앞서 언급했던 문제들이 해결됩니다. 교환기를 통해 상담원과 연결을 하므로 교환기 내에서 마법을 부려 상담원들이 전화를 공평하게 받게 할 수도 있다고 합니다.
이제 대부분의 문제가 해결 됐습니다. 하지만 갑자기 이런 의문이 듭니다. "적절한 상담원의 수는 몇명일까?" 이를 정하는 데 중요한 요인은 특정 시간대에 전화하는 사람의 수, 즉 동시 전화 수 입니다. 게임의 동시접속자수를 생각하시면 이해에 도움이 될겁니다. 즉, 동시에 전화하는 사용자 수와 동일한 수의 상담원만 보장되면 됩니다. 하루 평균 동시에 몇 건의 전화 오는지 조사를 하여 그만큼의 상담원을 고용하였습니다. 이제 우리는 부자가 될 일만 남았습니다.
하지만
코로나로 인해 실내활동이 잦아져 컴퓨터 사용 빈도가 늘어났고 그만큼 고장도 늘어나 버렸습니다. 갑자기 전화가 폭주하기 시작했습니다. 이 상황을 예측할 수 있는 능력이 있었다면 상담원을 추가적으로 고용했겠지만 그런 능력이 있었다면 사업을 하기보다 로또를 샀을 겁니다. 결국 예방은 불가능하고 최선의 대응만 할 수 있습니다.
하지만 IT 서비스에서는 이를 예방할 수 있습니다.
이제 충분한 배경지식을 갖췄으니 IT 서비스에 대해 얘기해보겠습니다. IT 서비스에서는 상담원을 Server, 교환기를 Load Balancer라는 용어로 부릅니다. 앞서 서비스 센터의 예와 차이점은 상담원이 다수의 사용자를 대응할 수 있다는 점입니다.
실제 AWS를 사용한 아키텍쳐 [출처 : 천만 사용자를 위한 클라우드 아키텍처, 5년간의 여정, Channy Yun]트래픽 대응에 있어서 중요한 것은 "언제 확장할 것인가"를 정하는 것입니다. 위에서 얘기했던 "예지 능력"을 갖추어야 합니다. 요리에 재료가 필요하듯이 예지 능력을 가지려면 세 가지 재료가 필요합니다.
1. 모니터링
2. 위험도 판단기준
3. 위험 알람
첫 번째, 현재 트래픽 발생량을 모니터링할 수 있어야 합니다. 실시간으로 각 서버에서 트래픽이 얼마나 발생하고 있는지 확인이 가능한 인프라가 구축되어야 합니다.
두 번째, 각 서비스마다 위험도를 판단하는 기준이 있어야 합니다. 지금 예시로 든 것은 서버와 로드 밸런서 두 개 밖에 없습니다. 하지만 IT 서비스를 운영하기 위해서는 데이터베이스, 캐시 스토리지, 메세지 브로커 등 다양한 서비스가 추가적으로 필요로 합니다. 각 서비스 마다 위험도 기준이 다릅니다. 만약 위험도 기준을 통일시켰을 경우 서버에서는 문제 없는데 데이터베이스에서 문제가 생길 수 있습니다. 여기서 중요한 것은 한 서비스가 죽으면 장애가 전파되어 전체 서비스가 죽는다는 것 입니다.
세 번째, 위험이 발생할 가능성이 있다는 것을 알리는 알람이 필요합니다. 알람은 위험 예방과 대응에 중요한 역할을 합니다.
이 세 가지가 준비되면 우리는 코로나 19와 같은 트래픽 증가하는 이슈에도 견고한 서비스를 운영할 수 있습니다. 예기치 못한 트래픽 증가에 서버가 죽어 새벽에 부랴부랴 일어나 졸린 눈을 비비며 복구하는 상황에서 벗어날 수 있습니다.
지금까지 코로나 19로 인해 늘어난 트래픽과 대처법에 대해 알아보았습니다. 간단하게 요약하면 IT 서비스가 효과적으로 트래픽에 대응하기 위해서는 확장성 있는 구조를 갖추고 트래픽 증가를 예측하고 이에 맞춰 확장할 수 있어야 합니다. 이를 위해서는 세 가지가 가능해야 합니다. 트래픽을 모니터링 할 수 있어야 하고 위험도를 판단하는 기준을 서비스마다 정해야 하고 위험이라고 판단됐을 때 알람을 보낼 수 있어야 합니다. 이제 왜 N와 K 같은 IT 서비스가 트래픽이 늘어나도 죽지 않는지, 내 트래픽이 어떻게 옮겨지고 있는지 감을 잡았을 거라고 생각합니다. 지금까지 읽어주셔서 감사합니다. 잘못된 점이 있다면 댓글로 남겨주세요 :D
참고자료
https://www.statista.com/statistics/1105495/coronavirus-traffic-impact/
https://aws.amazon.com/ko/blogs/korea/5-years-scalling-up-to-10-million-users/
