로컬 퍼스트 소프트웨어는 왜 트래픽 증가에도 인프라 확장 부담이 적은지, Harper의 사례를 통해 설명합니다.
이 글의 제목은 다소 오해를 불러일으킬 수 있습니다. 로컬 퍼스트 소프트웨어는 아예 확장이 거의 필요하지 않기 때문입니다.
Harper는 최근 트래픽과 사용자 수가 모두 크게 증가했습니다. 어떻게 그랬을까요? Hacker News의 첫 페이지에 올랐기 때문입니다. 제가 이 이야기를 계속 꺼내는 정도만 봐도 알 수 있겠지만, 저는 정말 기쁩니다. 다른 것이 없다 하더라도, 이것만으로도 엄청난 규모의 무료 광고 효과가 있었습니다.
저는 엣지에서 작업하는 것의 놀라운 이점들에 대해 많이 생각해 왔습니다. 이것은 사람들이 Harper를 설명할 때 쓰는 여러 표현 중 하나일 뿐입니다. “edge-first”라고도 부릅니다. 다른 표현으로는 “local-first”, 혹은 그냥 “on-device”가 있습니다. 이것들은 모두 단순한 아이디어를 가리키는 전문 용어일 뿐입니다. 우리는 관련된 모든 문법 검사 코드를 가능한 한 물리적으로 사용자와 가장 가까운 곳에서 실행합니다. 그렇게 하면 누구보다도 빠르게 제안을 제공할 수 있습니다. 이 목표를 달성하기 위해, 우리는 모든 것이 잘 최적화되어 있고 군더더기 없도록 합니다. Harper는 CPU나 메모리를 거의 사용하지 않습니다.
최근 사용자 유입 증가라는 맥락에서 이 모든 것이 무엇을 의미할까요? 잠시 우리가 LanguageTool이라고 상상해 봅시다. 우리의 소프트웨어는 Java로 작성되어 있고, 코드 효율성에 대한 신경은 다소 부족합니다. 소프트웨어를 실행하려면 큰 서버가 필요하기 때문에, 우리는 예상되는 일정 수준의 부하를 처리하기 위해 일정 수의 서버를 대기 상태로 두고 있습니다.
만약 우리가 받는 요청 수가 갑자기 두 배로 늘어난다면(Chrome 확장 프로그램에서 실제로 그랬던 것처럼), 우리는 큰 곤경에 빠질 것입니다. 요청 지연 시간을 늘리지 않거나(또는 요청을 아예 놓치지 않으려면), 실행 중인 서버 수를 늘려야 합니다. 이것은 단지 클라우드 아키텍처 전문가를 고용하는 일만이 아니라, 월말에 AWS(혹은 다른 어떤 서비스든) 요금을 지불하기 위한 추가 자금도 필요하다는 뜻입니다.
Harper는 엣지에서 실행되기 때문에(즉, 서버가 필요 없기 때문에), 우리는 그런 걱정을 할 필요가 없습니다. 실제로 저는 다음 날 아침 Hacker News를 방문하고 나서야 사용자 수가 급증했다는 사실을 알아챘습니다. 아무런 문제도 없었습니다.
많은 클라우드 제공업체들은 사용자 증가에 맞춰 확장할 수 있다는 점을 자랑하곤 합니다. 저는 아예 확장할 필요가 없다는 점을 자랑하고 싶습니다.
