Making magic: Reimagining Developer Experience for the World of Serverless
Today I’m going to talk about TTFD, or time to first dopamine, and announce a huge improvement to the Workers development experience — wrangler dev.
blog.cloudflare.com
이번 주에는 전 세계 200개 이상의 도시에서 콜드 스타트 없이 lightweight isolates 기능을 실행하여 애플리케이션의 TTFB를 개선한 Workers에 대해 이야기해보았습니다. 오늘은 이보다 더 중요한 또 다른 지표인 TTFD(첫 도파민 생성 시간)에 대해 이야기하고, 로컬 환경의 모든 장점을 갖춘 에지 기반 개발환경인 랭글러 개발자 환경을 대폭 개선한 Workers 개발 환경을 발표하려고 합니다.
처음 몇 줄의 코드가 작동할 때의 짜릿함만큼 좋은 것은 없습니다. 이전에 몇 번이나 해봤어도 컴퓨터가 내가 원하는 것을 정확히 이해하고 실행하는 마법같은 일이 벌어지는 것 입니다.
이것이 제가 "서버리스"에 기대했던 마법과 같은 기능이며, 오늘날 대부분의 서버리스 제품이 가상 서버를 설정하는 것보다 더 빠르게 이러한 느낌을 주는 것은 사실이지만, 오늘날 대부분의 서버리스 플랫폼의 개발이 얼마나 부진한지에 대해서는 여전히 실망스러울 수 밖에 없습니다.
코드를 작성하기까지의 여정이 서버(지역, 메모리 할당 등)에 대한 강제적인 의사 결정으로 인해 길어집니다. 하지만 오늘날 서버리스 세계에서 개발자가 마법 같은 즐거움을 누리는데 서버만이 걸림돌이 되는 것은 아닙니다.
테스트 애플리케이션을 호출하기 위한 올바른 엑세스 정책을 구성하고 HTTP 또는 REST API 중 어떤 것이 더 적합한지 결정하는데 30분이 쉽게 지나갔고, 여전히 애플리케이션 호출을 위해 호출할 수 있는 URL을 찾지 못했습니다. 하지만 5개의 서로 다른 서비스를 스핀업했고, 요금이 부과되지 않을까 벌써부터 서비스를 정리해야 한다는 걱정이 들었습니다.
마법처럼 느껴지지 않나요
저희는 미래의 서버리스 플랫폼이라고 믿어 의심치 않는, 매우 마법처럼 느껴지는 약속을 구축하면서 개발 여정의 모든 단계에 그 마법 같은 느낌을 되살리고 싶었습니다. 서버리스가 개발자의 역량을 강화하는 것이라면 PoC부터 MVP에 이르기까지 모든 단계에서 개발자의 역량을 강화해야합니다.
오늘 개발자 경험을 즐겁게 만들기 위한 접근 방식을 여러분과 공유하게 되어 기쁩니다. 아직 성장과 혁신의 여지가 많다는 것을 잘 알고 있지만(그리고 현재 작업 중인 모든 사항에 대해서도 여러분께 말씀드리고 싶습니다!), Workers를 개발자가 사용하기 가장 쉬운 개발 플랫폼으로 만들기 위해 이룬 모든 진전에 자부심을 느낍니다.
Defining “developer experience”
먼저 개발자의 여정에 어떤 것들이 수반되는지 살펴보겠습니다. 오늘은 사용자 경험을 다음 4가지 단계로 정의합니다.
- Getting Started: 키 입력을 하기 전에 수행해야하는 모든 단계
- Iteration: 내 코드가 예상한 대로 동작하나요? 그렇게 하려면 어떻게 해야 하나요?
- Release: 할 수 있는 모든 테스트를 마쳤으니 이제 큰 빨간 버튼을 누를 차례입니다.
- Observe: 고장난 부분이 있나요? 어떻게 고치면 되나요?
개발의 각 단계에 접근할 때, 우리는 항상 우리가 원하는 개발 흐름이 작동하는 방식과 경험을 재구상하고 기존 플랫폼이 우리를 실망시켰던 부분을 수정하고자 했습니다.
Zero to Hello World
Workers를 통해 앞서 언급한 즐거운 기분을 최대한 빨리 느끼고 코드를 작성하고 배포하는데 방해가 되는 모든 장애물을 제거하고자 합니다. 첫번째 배포경험은 정말 중요합니다. 한 번 해보고 도중에 포기하지 않았다면 다시 할 수 있습니다.
Cloudflare 계정이 없는 신규 사용자의 경우에도 3분이라는 매우 짧은 TTFD를 자랑스럽게 말씀드릴 수 있습니다. 기존 고객의 경우, 몇 초만에 첫번째 Wokrer를 실행할 수 있습니다. 선택할 지역도, 구성할 IAM 규칙도, 설정하거나 비용에 대해 걱정할 API 게이트웨이도 없습니다.
Workers를 처음 사용하지만 아직 익숙하지 않다면 버튼 클릭 한 번으로 전 세계 200개 도시에 Worker를 몇 초 안에 즉시 배포할 수 있습니다.
이미 다음 애플리케이션을 빌드하기 위한 선택으로 Workers를 결정하셨다면, Vim emacs, VSCode등 선호하는 모든 IDE를 사용할 수 있도록 하여 집처럼 편안하게 사용하실 수 있도록 하고 싶습니다.
Workers의 공식 명령줄 도구인 랭글러가 출시되었으니 이제 아주 쉽게 시작할 수 있습니다.
wrangler generate hello
cd hello
wrangler publish
다시 말하지만, 몇 초만에 코드가 실행되고 전 세계에서 엑세스할 수 있습니다.
Workers를 사용하여 개발을 시작하고 익숙해지는 데 도움이 되는 다양한 튜토리얼을 제공합니다. 템플릿 갤러리에서는 새로운 GraphQL 서버든 새로운 정적 사이트든 원하는 제품을 바로 구축할 수 있도록 시작용 템플릿을 제공하여 시작 시간을 절약할 수 있도록 도와드립니다.
Local(ish) development: code, test, repeat
사용자를 대신하여 코드를 올바르게 만들겠다고 약속할 수는 없지만, 코드를 올바르게 만드는데 필요한 피드백을 제공하기 위해 최선을 다할 것을 약속할 수는 있습니다. 개발 여정에는 수많은 시행착오, 디버깅이 필요합니다. 제가 받은 컴퓨터 공학 학위 뒷면에는 이렇게 적혀있을 것입니다. "코딩, print, 반복" 이라고 적혀있을 것입니다.
코드를 올바르게 작성하는 것은 매우 반복적인 피드백 중심의 프로세스입니다. 우리 모두 처음부터 코드를 올바르게 작성하고 계속 진행하면 좋겠지만, 현실은 컴퓨터가 마음을 잘 읽지 못하기 때문에 JSON에 불필요한 괄호나 쉼표가 들어가서 코드가 실행되지 않는 경우가 있습니다. 느슨한 괄호가 도입된 곳을 찾았나요? 다행이네요! 이제 코드가 실행되고 있지만 출력이 올바르지 않다면 잘못된 오류를 찾아야 할 때입니다.
로컬 개발은 전통적으로 개발자가 개발 과정에서 긴밀한 피드백 루프를 확보할 수 있는 방식이었습니다. 효과적인 로컬 개발 환경을 구성하고 훌륭한 테스트 환경으로 만드는 중요한 요소는 빠른 피드백 루프, 샌드박스가 적용된 특성(프로덕션에 영향을 주지 않고 개발할 수 있는 기능), 정확성입니다.
이 세가지 목표를 모두 달성하기 위해 고민하기 시작하면서 로컬이라는 것 자체가 필요조건이 아니라 속도가 진짜 필요조건이며, 클라이언트에서 실행해야만 충분한 피드백 루프에 적합한 속도를 달성할 수 있다는 것을 깨달았습니다.
한 가지 옵션은 기존으 로컬 개발 환경을 제공하는 것이었지만, Workers 런타임을 위한 로컬 개발 환경을 제공하고 싶었지만 런타임보다 요청을 처리하는데 더 많은 것이 있어 정확성이 저하될 수있다는 점이 마음에 들지 않았죠. 사용자 컴퓨터에서 작동하지만 우리 컴퓨터에서는 작동하지 않는 코드로 인해 사용자가 실패하도록 설정하고 싶지 않았습니다.
나머지 엣지 인프라를 사용자에게 제공하려면 이를 최신 상태로 유지하는데 어려움이 따르고, 사용자가 수백개의 불필요한 디펜던시를 설치해야하며, 결국 StackOverflow에서 설명을 찾을 수 없는 설치 버그에 부딪히는 가장 불쾌한 경험을 하게 될 수도 있습니다. 이러한 경험은 저희와 맞지 않았습니다.
알고보니 이것은 우리가 고객을 위해 일반적으로 해결하는 문제와 매우 유사한 문제였습니다. 클라이언트에서 코드를 실행하면 빠르지만 필요한 제어 기능을 제공하지 못하고, 서버에서 코드를 실행하면 필요한 제어 기능을 제공하지만 오리진까지 왕복하는데 시간이 오래 걸립니다. 저희는 조언을 받아들여 엣지에서 실행하기만 하면 되었습니다. 코드가 최종 사용자와 매우 가까운 곳에서 실행되므로 제어권을 잃지 않으면서도 클라이언트에서 실행하는 것과 동일한 성능을 얻을 수 있다는 두가지 장점을 누릴 수 있습니다.
개발자들이 이 긴밀한 피드백 루프에 엑세스할 수 있도록 올해 초 wrangler dev 를 도입했습니다.
wrangler dev는 로컬 개발 환경의 모양과 느낌을 가지고 있습니다. 로컬 호스트에서 실행되지만 엣지로 터널링되며 원하는 IDE로 직접 출력을 제공합니다. 이제 wrangler dev는 엣지에서 실행되므로 여러분의 컴퓨터와 저희 컴퓨터에서 완전히 동일하게 작동합니다.
Release
모든 코드를 작성하고, 상상할 수 있는 모든 엣지 케이스를 테스트하고, 코드 리뷰를 거친 후에는 언젠가는 전 세계가 노력의 결실을 맺소 여러분이 구축한 기능을 즐길 수 있도록 코드를 공개해야합니다.
작고 빠른 애플리케이션의 경우, '저장 및 배포' 버튼을 누르고 운명에 맡기는 것이 좋습니다. 그러나 프로덕션 레벨 프로젝트의 경우 프로덕션에 배포하는 프로세스가 약간 다를 수 있습니다. 조직마다 코드 릴리스에 채택하는 프로세스가 다릅니다. Github를 사용하는 사람들을 위해 작년에 통합 릴리스 프로세스를 쉽게 구성할 수 있는 Github Action을 도입했습니다.
랭글러를 사용하면 기존 CI 를 사용하여 배포하도록 워커를 구성하고, 배포를 자동화하고, 사람의 개입을 최소화할 수 있습니다.
프로덕션 환경에 배포할 때도 피드백이 매우 중요합니다. 오늘날 일부 플랫폼에서는 코드를 배포하는데 몇 분 정도 걸리는 경우도 있습니다. 몇 분이라는 시간은 사소해 보일 수 있지만, 코드가 아직 라이브 상태인지, 사용자에게 어떤 버전의 코드가 표시되는지 궁금해하며 초조하게 몇 분을 보내는 것은 스트레스가 될 수 있습니다. 특히 롤백이나 버그 수정이 필요한 상황에서 새 버전을 최대한 빨리 배포해야하는 경우에 더욱 그렇습니다.
새 Worker는 5초 이내에 전 세계에 배포되므로 새로운 변경 사항을 즉각적으로 적용할 수 있습니다. 더 좋은 점은 Worker가 lightweight isloates에서 실행되기 때문에 새로 배포된 Worker는 콜드 스타트같은 끔찍한 문제가 발생하지 않으므로 Worker를 미리 예열하기 위해 시간을 투자할 필요 없이 코드를 출시할 수 있는 만큼 자주 배포할 수 있으므로 다음 기능 작업을 시작할 수 있는 시간이 더 많아집니다.
Observe & Resolve
큰 빨간 버튼을 눌렀습니다. 도파민이 아드레날린으로 대체된 순간, 머릿속에는 "내가 무언가를 망가뜨렸나?"라는 질문이 떠오릅니다. 그렇다면 무엇을, 어떻게 고쳐야할까?라는 질문입니다. 이러한 질문을 업계에서 "observability"라고 부르는 것이 핵심입니다.
오류 증가, 트래픽 감소, 심지어 성능 저하도 퇴보로 간주될 수 있는 등 다양한 방식으로 장애가 발생하고 사고가 나타날 수 있습니다. 이러한 종류의 문제를 식별하려면 추세를 파악할 수 있어야합니다. 하지만 raw 데이터는 추세를 파악하는데 그다지 유용한 매체가 아닙니다. 사람은 미묘한 오류 증가를 식별하기 위해 raw line을 구문분석할 수 없기 때문입니다.
따라서 개발자가 문제를 식별하고 해결하는데 도움을 주기 위해 분석을 통해 트렌드 데이터를 노출하는 동시에 포렌식 및 조사를 위해 프로덕션 로그를 추적할 수 있는 기능을 제공하는 두가지 접근 방식을 취했습니다.
올해 초, 개발자가 프로덕션 트래픽의 추세를 쉽게 파악할 수 있는 작업자 메트릭을 도입했습니다. 요청 메트릭을 사용하면 특정 릴리스 이후 오류가 증가하거나 트래픽 패턴이 급격하게 변화하는 것을 쉽게 파악할 수 있습니다.
또한 새로운 코드가 애플리케이션의 전반적인 성능에 예기치 않은 퇴보를 가져올 수도 있습니다. 이제 개발자는 CPU 시간 메트릭을 통해 워커의 성능 변화를 파악할 수 있을 뿐만 아니라 해당 정보를 사용하여 코드를 안내하고 최적화할 수 있습니다.
회귀를 식별한 후에는 버그를 찾아 수정하는데 필요한 도구를 제공하고자 했으며 이를 위해 최근 단일 명령으로 프로덕션 로그를 확인할 수 있는 "wrangler tail"도 출시했습니다.
wrangler tail은 console.log() 출력과 예외를 노출하기 때문에 코드가 실패하는 지점이나 특정 고객에게 예기치 않은 결과가 발생하는 이유를 진단하는데 도움이 될 수 있습니다. 개발자는 이 출력에 액세스하여 프로덕션 환경에서 발생하는 모든 문제를 즉시 진단, 수정 및 해결할 수 있습니다.
잘못된 코드가 고객 트래픽에 영향을 미칠 때 매 순간이 얼마나 소중할 수 있는지 잘 알고 있습니다. 다행히도 버그를 발견하고 수정한 후에는 사용자가 수정의 혜택을 받기 시작하는데 몇 초밖에 걸리지 않습니다. 최대 5분까지 기다려야 하는 다른 플랫폼과 달리 Workers는 5초 이내에 전 세계에 배포됩니다.
Repeat
다음 기능에 대해 고민하다가 새 브랜치를 체크 아웃하면 사이클이 다시 시작됩니다. 첫번째 도파민(TTFD)에 도달하는 시간을 단축하기 위해 Workers의 개발환경을 개선한 모든 사항을 확인해보시기 바랍니다.