포켓몬 고 출시 알림 '실패를 위한 구축'만큼 '확장을 위한 구축'이 중요한 이유

수년 동안 DevOps와 클라우드의 캐치프레이즈 중 하나는 "실패를 위해 구축"이었습니다. 전제는 너무 많은 기업이 용량 관련 성능 문제로 인해 비용이 많이 드는 가동 중지 시간과 수익(및 생산성) 손실을 경험한다는 것입니다. 따라서 이런 끔찍한 사건이 다시 발생하여 문제가 되지 않도록 앱과 인프라를 '실패하도록' 구축해야 합니다. 허허. 제가 뭘 했는지 알겠어요? 네, 저는 사무실에서 혼자 원격으로 일합니다. 가끔은 혼자 즐겁게 놀아야 해요.

나쁜 말장난은 차치하고, 포켓몬 고의 최근 엄청난 성공(이 이야기를 들었나요?)은 많은 사람에게 엄청나게 좌절스러운 경험을 안겨주었습니다. 특히 지금 당장 가고 싶어했지만 계정 생성이 일시적으로 중단된 후 엄청난 수요로 인해 엄격하게 측정되었기 때문에 갈 수 없었던 매우 흥분한 자녀를 둔 부모들이 그렇습니다.

이제, 일부 사람들은 Amazon CTO인 베르너 포겔스가 회사의 용량 문제를 해결하도록 돕겠다고 제안한 것이 회사가 처음부터 "클라우드 전환"을 하지 않은 것을 의미하며, 그것이 근본적인 문제라고 지적할 수도 있지만, 그것은 회사가 클라우드로 전환하지 않았다는 전제 하에 말하는 것이고, 지금으로서는 그것이 무엇인지 잘 모르겠습니다. 진지하게, 증강 현실 개발자에 대한 위키피디아 업데이트 에 따르면, "사람들이 물리적 세계에서 실제 및 가상 객체와 상호 작용할 때 하루에 2억 개 이상의 게임 액션을 처리합니다." 이 부분에서는 우리가 그들에게 약간의 여유를 줄 수 있을 것 같습니다. 적어도 시스템 상호작용과 패킷 푸시의 의미를 이해하는 사람이라면 그럴 수 있을 겁니다. 업데이트는 "서버 문제"를 지적했지만, "서버"는 "앱과 네트워크 인프라에 분산된 15개의 서로 다른 구성 요소"를 의미하는 기술 코드라는 것은 우리 모두 알고 있습니다.

어쨌든, 여기서 얻을 수 있는 교훈은 예상치 못한 성공을 처리하는 데 클라우드가 반드시 더 뛰어나다는 것은 아닙니다. 그럴 수도 있겠지만, 클라우드이기 때문은 아닙니다. 클라우드는 실패 하도록 만들어졌을 뿐만 아니라 확장 가능 하도록 만들어졌기 때문입니다.

Niantic Labs가 수요에 부응하지 못한 이유를 알 수 없습니다. 아마도 용량이 부족했을 수도 있는데, 이 경우 클라우드가 좋은 선택일 수 있고, 앱 및/또는 인프라가 확장성을 염두에 두고 구축되지 않았을 수도 있는데, 이 경우 클라우드가 전혀 도움이 되지 않을 수 있습니다. 요점은 그들이 무엇을 했거나 하지 않았는지에 대해 그들을 건드리지 않는 것입니다. 요점은, 이것이 애플리케이션 세계에서 조직이 성공을 위한 구축만큼 실패를 위한 구축에도 관심을 가져야 한다는 현실을 완벽하게 보여주는 사례라는 것입니다. 그리고 점진적인 성공이 아니라, 포켓몬 고처럼 순식간에 하룻밤 사이에 성공을 거두는 것입니다.

그런 일이 일어나면 그 성공적인 실패 사례가 인터넷에 퍼지는 건 원치 않을 테니까요.

확장성 문제는 일반적으로 데이터 소스와 관련됩니다. 숙련된 트위터 사용자라면 소셜 미디어 초창기에 데이터베이스 확장성 문제로 어려움을 겪었다는 사실을 기억할 것입니다. PayPal은 엄청난 규모의 사용자 문제를 해결하기 위한 확장성 전략으로 샤딩을 가장 일찍부터 강력하게 주장한 기업 중 하나였으며, 이 기술은 데이터베이스, 성능 서비스 , 애플리케이션 등에 모두 적용할 수 있는 일반적인 기술로 채택되었습니다. NoSQL 데이터 소스의 증가는 기존 관계형 데이터베이스보다 뛰어난 확장성을 장점으로 내세웁니다.

확장성 문제의 또 다른 원인은 인프라의 한계 때문입니다. 클라우드에서의 자동 확장은 단순히 더 많은 컴퓨팅을 자동으로 추가하는 것이 아니라 "앱 엔드포인트"의 용량을 늘리는 기능에 의존합니다. 용량 증가를 달성하기 위해 확장에 의존하는 모든 아키텍처에서는 어떤 종류의 부하 분산 서비스가 필요합니다. 컴퓨팅이 증가하면 로드 밸런싱 서비스에 등록해야 합니다. 즉, API 및 스크립트, 자동화 및 오케스트레이션을 사용하는 것을 의미합니다. 이러한 구성 요소는 필요하기 전에 마련되어야 하며, 수요에 따라 용량을 늘려야 하는 경우 지연이 발생합니다.

모든 앱 아키텍처에 부하 분산 서비스를 포함하는 것은 필수입니다. 로드 밸런싱 서비스는 두 애플리케이션 인스턴스 간의 장애 조치를 본질적으로 지원하기 때문에 "실패를 대비한 구축"의 필요성을 충족할 뿐만 아니라 성공에 필요한 "확장을 대비한 구축"의 필요성도 지원합니다. 하지만 앱(혹은 마이크로서비스라면) 앞에 로드 밸런싱 서비스를 붙이는 것만으로 충분하다고 생각하지 마세요. 운영 부서에서는 수요에 맞춰 자동 확장을 가능하게 하는 자동화(스크립트) 및 오케스트레이션(프로세스)을 구축하는 것이 중요합니다. 오늘날 확장은 알고리즘이 아니라 아키텍처 에 대한 것이며, 아키텍처 부채가 너무 제한적이어서 지금 있는 것에 얽매이기 전에 아키텍처를 미리 고려하는 것이 중요합니다.

솔직히 말해서, Niantic Labs는 실패를 위해 좋은 일을 했습니다. 용량 부족으로 인해 내가 자주 접하는 기본 HTTP 상태 코드 페이지가 아닌 친절한 메시지가 표시되었습니다. 아이들이 읽고 이해하기 쉽고 유머러스한 내용이었습니다(저는 8살짜리 아이가 20분마다 읽어줬기 때문에 알고 있습니다).  그들이 계획하지 못했던 것은 예상치 못한 성공이었습니다. 이는 모든 사람에게 규모에 맞춰 구축하는 것이 실패에 맞춰 구축하는 것만큼 중요하다는 점을 상기시켜 주는 좋은 내용입니다.   

그러지 않으면 로켓단이 이기기 때문이죠.