포켓몬 고 출시가 일깨운 교훈: ‘확장 가능하게 구축하기’가 ‘장애를 전제로 구축하기’만큼 중요한 이유

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

지난, 그러니까 아주 오랫동안 DevOps와 클라우드 분야에서 유행한 문구 중 하나는 “실패를 전제로 구축하라”였습니다. 용량과 관련된 성능 문제로 인해 너무 많은 기업이 막대한 비용이 드는 서비스 중단과 매출(및 생산성) 손실을 겪고 있으니, 그런 끔찍한 일이 다시 발목을 잡지 않도록 앱과 인프라를 ‘실패를 전제로’ 구축해야 한다는 취지입니다. 헤헤. 제가 무슨 말장난을 했는지 아시겠죠? 네, 저는 사무실에서 혼자 원격 근무를 합니다. 가끔은 스스로를 즐겁게 해줘야 하거든요.

썰렁한 말장난은 제쳐두고, 최근 Pokémon Go의 경이적인 성공(설마 못 들어보신 건 아니죠?)은 많은 사람에게 그만큼 엄청난 좌절감을 안겨 주었습니다. 특히 당장이라도 나가고 싶어 안달이 난 아이들을 둔 부모들은 폭발적인 수요로 인해 계정 생성이 일시 중단된 데 이어 엄격히 제한되는 바람에 그러지 못했습니다.

일각에서는 Amazon CTO 베르너 포겔스의 지원 제안이 회사의 용량 문제 해결을 돕겠다는 것이었다는 점을 들어, 애초에 이 회사가 ‘클라우드로 전환’하지 않았고 그것이 근본적인 문제였음을 시사한다고 볼 수도 있습니다. 하지만 이는 이 회사가 클라우드로 전환하지 않았다는 전제에 따른 것으로, 현시점에서는 그 여부가 명확하지 않습니다. 실제로 이 증강 현실 개발사에 관한 Wikipedia 업데이트에 따르면, 이 회사는 ‘사람들이 현실 세계에서 실제 사물과 가상 객체를 상호작용하는 과정에서 하루 2억 건이 넘는 게임 동작’을 처리합니다. 이 정도라면 조금은 너그럽게 봐줘도 되지 않을까요? 적어도 시스템 상호작용과 패킷 전송 측면에서 이것이 무엇을 의미하는지 아는 사람이라면 말입니다. 업데이트에서는 ‘서버 문제’를 원인으로 지목했지만, 솔직히 우리 모두 ‘서버’가 ‘앱과 네트워크 인프라 전반에 분산된 15개의 서로 다른 구성 요소’를 뜻하는 기술 업계식 표현이라는 걸 알고 있잖아요.

어쨌든 여기서 얻을 수 있는 근본적인 교훈은 클라우드가 예상치 못한 성공에 반드시 더 잘 대처한다는 것이 아닙니다. 실제로 더 잘 대처할 수도 있지만, 단순히 클라우드이기 때문은 아닙니다. 클라우드는 장애를 견디도록 설계되었을 뿐만 아니라 확장할 수 있도록 설계되었기 때문입니다.

Niantic Labs가 수요를 감당하지 못한 이유를 제가 판단할 수는 없습니다. 용량 부족이 원인이었다면 클라우드가 좋은 선택이었겠지만, 애플리케이션이나 인프라가 확장 가능하도록 구축되지 않았던 것이 원인이었다면 클라우드도 전혀 도움이 되지 않았을 수 있습니다. 여기서 중요한 것은 그들이 무엇을 했고 하지 않았는지를 꼬집으려는(말장난입니다) 것이 아닙니다. 핵심은 애플리케이션 중심의 세상에서 조직이 성공에 대비해 시스템을 구축하는 것만큼이나 장애에 대비해 구축하는 데도 신경 써야 한다는 현실을 그들이 완벽하게 보여 주는 사례라는 점입니다. 그것도 점진적인 성공뿐만 아니라 Pokémon Go처럼 하루아침에 찾아오는 폭발적인 성공에까지 대비해야 합니다.

왜냐하면 그런 일이 벌어졌을 때, 그 성공적인 실패가 인터넷 곳곳에 대대적으로 퍼지는 것은 원치 않을 테니까요.

확장성 문제의 흔한 원인 중 하나는 데이터 소스입니다. 트위터를 오래 사용한 사용자라면 이 소셜 미디어가 초창기에 데이터베이스 확장성 문제로 어려움을 겪었다는 사실을 기억할 것입니다. PayPal은 방대한 사용자 규모로 인한 문제를 해결하기 위한 확장 전략으로 샤딩을 가장 일찍부터 적극적으로 지지한 기업 중 하나였으며, 이 기법은 데이터베이스뿐만 아니라 성능 서비스, 그리고 애플리케이션에도두루 적용할 수 있는 일반적인 기법으로 자리 잡았습니다. NoSQL 데이터 소스는 기존 관계형 데이터베이스보다 확장성이 뛰어나다는 점을 장점 중 하나로 내세웁니다.

확장성 문제의 또 다른 원인은 전적으로 인프라에 있습니다. 클라우드의 자동 확장은 단순히 컴퓨팅 리소스를 자동으로 추가하는 것뿐만 아니라 ‘앱 엔드포인트’의 용량까지 늘릴 수 있어야 합니다. 확장을 통해 용량을 늘리는 모든 아키텍처에는 일종의 부하 분산 서비스가 필요합니다. 컴퓨팅 리소스가 추가되면 이를 부하 분산 서비스에 등록해야 합니다. 이를 위해서는 API와 스크립트, 자동화 및 오케스트레이션을 활용해야 합니다. 이러한 구성 요소는 필요해지기 전에 미리 마련되어 있어야 하며, 그렇지 않으면 수요 증가로 용량을 늘려야 할 때 지연이 발생할 수 있습니다.

모든 앱 아키텍처에는 부하 분산 서비스가 반드시 포함되어야 합니다. 부하 분산 서비스는 두 애플리케이션 인스턴스 간의 장애 조치를 기본적으로 지원하므로 ‘장애를 전제로 구축’해야 한다는 요구를 충족할 뿐만 아니라, 성공에 필요한 ‘확장을 전제로 구축’해야 한다는 요구도 뒷받침합니다. 하지만 앱(또는 선호한다면 마이크로서비스) 앞에 부하 분산 서비스를 하나 배치하기만 하면 된다고 생각해서는 안 됩니다. 수요가 발생했을 때 자동 확장으로 대응할 수 있도록 운영팀이 자동화(스크립트)와 오케스트레이션(프로세스)을 미리 마련해 두는 것이 중요합니다. 오늘날 확장의 핵심은 알고리즘이 아니라 아키텍처이며, 아키텍처 부채로 인해 기존 환경에 얽매여 아무것도 바꿀 수 없게 되기 전에 처음부터 아키텍처를 고려하는 것이 중요합니다.

솔직히 말해 Niantic Labs는 장애에 대비한 설계를 훌륭하게 해냈습니다. 용량 부족 문제가 발생했을 때도 흔히 보게 되는 기본 HTTP 상태 코드 페이지 대신 친근한 메시지가 표시되었습니다. 메시지는 유머러스했고 아이들도 쉽게 읽고 이해할 수 있었습니다(제 여덟 살 아이가 20분마다 그 메시지를 우리에게 읽어 줬으니 잘 압니다). 하지만 아마도 예상치 못했을 정도의 성공을 거두리라는 점까지는 대비하지 못했습니다. 이는 확장성을 고려한 설계가 장애에 대비한 설계만큼이나 중요하다는 사실을 모두에게 일깨워 줍니다.

그렇게 하지 않으면 로켓단이 승리하게 되기 때문입니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물