몇 년간 serverless 환경(주로 amazon lambda, 그리고 다른 것도)을 사용한 경험자로서, 저자 의견에 적극 동의함
serverless가 어느 부분에서는 일을 덜어주지만, 동시다발적으로 "인위적으로 생기는 문제들"을 해결하느라 다른 분야에서 일이 늘어남
나의 한 사례는 업로드 용량 제한 문제였음
기존 애플리케이션을 serverless로 이전했을 때, 대용량 고객 데이터 import를 위해 API 엔드포인트를 만들고 백그라운드 작업자를 붙이면 충분할 거라고 생각했음
하지만 "api gateway"(코드를 호출하는 프록시)에서는 100MB 이상은 업로드가 불가능했고, 제한 변경이 가능한지 문의했더니 단순히 고객에게 더 작은 파일로 나눠서 업로드하도록 하라고 안내받음
기술적으로는 그럴싸하게 들릴 수 있지만, 실제 고객이 업로드 방식을 바꿀 리 없다는 점이 현실임
"진공상태에서는 잘 동작한다"는 느낌에 가까우며, 이론상 멋진 것 같지만 실제로 해 보면 serverless로 전환해 절감한 시간과 비용을 결국은 serverless 특유의 문제를 해결하느라 재투입하게 됨
이 문제를 해결하려면 presigned S3 URL을 제공해야 함
사용자가 S3에 직접 업로드한 뒤 업로드 결과를 보내주도록 하거나, 파일 이름을 request id로 구분하는 방법 등으로 연동할 수 있음
AWS 환경을 오래 써본 입장에서 이런 점이 성가시기는 한데, 임의 파일 업로드 API를 열어두면 DoS 공격 위험이 크기 때문에 100MB 제한 자체는 이해 가능한 부분임
다만 요즘 인터넷 속도가 빨라진 걸 생각하면 100MB 기준은 다소 시대에 뒤처진 느낌임
그래도 언젠가는 제한이 필요하다고 생각함
우리 회사는 한때 AWS SSL 인증서 부서를 대표하는 고객이었음
Vanity URL(커스텀 도메인)을 지원하려니 도메인마다 SSL 인증서가 필요했는데, 수천 개가 필요했음
AWS의 인증서 관리 도구는 수백 개 규모까지만 쾌적했기 때문에, 이 문제가 해결될 때까지 3개월 정도 걸렸음
AWS의 일부 서비스가 극소수 고객의 수요에 맞춰 빨리 대응하지 못한다는 점이 놀라웠음
처음엔 Lambda가 엄청 가능성 있어 보여서 도입했지만, 결국 모든 Lambda 프로젝트를 포기하고 필요에 따라 컨테이너 환경으로 옮겼음
Lambda도 Node 런타임을 1~2년마다 업그레이드해야 하고, 컨테이너를 쓰면 그 주기를 스스로 결정할 수 있기 때문에 더 유연함
컴퓨터 공학에서 가장 어려운 문제는 한 컴퓨터에서 다른 컴퓨터로 파일 복사하는 것임
미래의 독자를 위해 참고자료를 남김
"tus" 업로더와 endpoint를 사용하면 업로드 시 분할, 이어받기 등 기능이 제공되어 이런 제한을 극복하기에 적합함 https://tus.io/
기사에서 설명한 것처럼, serverless는 분명히 그 나름의 용도가 있음
하지만 대부분의 애플리케이션에는 적합하지 않다고 생각함
특별한 상황이 아니라면 serverless를 핵심 인프라로 쓸 계획이 없음
실제로는 오히려 인프라 관리가 더 번거로워진다는 인상임
플랫폼마다 요구사항이 다르고, 테스트/개발 방식도 제각각이라 매번 애매하고 로컬 테스트도 어려움
추상화 레이어도 각 플랫폼마다 함정이 있고 진짜 표준이 존재하지 않음
도커 이미지로 실행 파일을 패키징하는 게 더 편하고, 환경 세팅도 적당히 추상화할 수 있어 내겐 더 자연스러운 개발 환경임
리눅스 환경과 파일시스템 수준의 최소한의 추상화가 가장 효율적이라 느껴짐
필요하면 해당 이미지를 서버로 띄워놓고 온디맨드 혹은 항상 대기 상태로 운영할 수도 있음
지난 10년간 유행한 여러 기술 트렌드를 보면, 대형 기업이 자기 규모에서만 실질적으로 존재하는 문제를 해결하려 썼던 기술이 인기몰이 하는 경우가 많았음
사례로 GraphQL, react, Tailwind, NextJS 등 여러가지가 해당됨
어떤 도구든 모든 문제에 만능으로 통하는 것은 아니며, 자신의 상황과 문제에 대해 경험과 이해를 바탕으로 선택하는 것이 중요함
지금 내가 얼마나 "재미있게" amazon lambda 앱을 로컬에서 실행해보려 시도하는 중인지 말해주고 싶을 정도임
배포 전에 테스트하려고 하니 도전 과제 그 자체임
Knative(Kubernetes용 Serverless)는 컨테이너를 직접 받아줌
표준 패키징 포맷이기 때문에 다양한 플랫폼으로 쉽게 이동할 수 있음
그 팀은 실제로 애플리케이션이 아니라 상태를 가진 서버 애플리케이션에 통합될 라이브러리를 개발하고 있었음
성능상의 장점도 authentication을 고객 환경 근처에서 처리한 덕분이지, serverless 그 자체 덕분은 아님
사실 모든 "serverless" 플랫폼이 도커 이미지를 받아주지 않나?
Cloud Run은 지원하는 것으로 알고 있음
실은 “serverless function”이 너무 많은 것을 추상화해서 생기는 현상에 대한 우려임
ClickHouse는 수천 번의 작은 insert를 싫어해서, 우리는 chproxy라는 Go 서비스로 이벤트를 모아서 대량 batch로 보냄
각 Cloudflare Worker가 chproxy에 analytic 이벤트를 보내면, chproxy가 모아 ClickHouse로 대량 전송함
ClickHouse 데이터에 한정해서 굳이 별도 서비스를 따로 만든 대신, 비동기 insert 기능도 있었는데 왜 그걸 안 썼는지 궁금함 https://clickhouse.com/docs/optimize/asynchronous-inserts
개발자들은 "간편하게 해준다는" 툴들에 파묻혀 있는 느낌임
사실 대부분의 문제는 가장 기본적인 도구(컴파일러, bash 스크립트, 라이브러리)로도 쉽게 풀림
이처럼 도구에 집착하다 보니 회사와 개발자 모두에게 오히려 해가 될 때가 있음
내 생각엔, 2013년의 Docker야말로 마지막으로 정말로 보편적이고 긍정적인 변화를 준 도구였음
이후로는 어느 회사에는 도움이 될 수 있지만, 모든 회사에 다 적용하려다가 오히려 생산성이 깨지거나 시스템이 무너지는 사례가 많음
요즘 Cloudflare같은 곳에서는 v8 isolates가 '차세대 docker'가 될 것처럼 밀고 있지만, 일부 워크로드엔 저격이지만 모든 곳에 맞는 건 아님
"docker 이미지를 받아서 인터넷에 띄워준다"는 패턴이 너무 강력해서 2040년에도 여전히 제일 센 방식일 거라고 봄
근본기를 아는 사람이 점점 드물어진 것도 문제임
스택 대부분을 제삼자 서비스에 외주를 주는 식으로 업무가 진행되고, 정작 직접 만든 건 핵심 애플리케이션 일부뿐임
심지어 그것조차 AI가 작성하게 될 수 있음
업계 전체가 "학습된 무력감"을 키우고 있는 중임
생각보다 많은 사람들이 컴파일러, bash 스크립트, 라이브러리를 잘 모름
AWS lambda는 너무 쌀 정도임
인지도 제고 용도로는 도움이 됨!
bash 스크립트 써서 Staff 등급까지 올라간 사람은 본 적 없음
"vercel security checkpoint"에게 묻고 싶음
아이폰에서 proton VPN과 Firefox Focus 조합으로 캘리포니아, 캐나다 exit 노드로 접속하면 code 99 "Failed to verify your browser" 오류가 반복적으로 발생함
뭐가 문제임?
sfo1::1760587368-8k6JCK3uO27oMpuTbnS4Hb3X2K9bVsc
이 쓰레드는 내 생각을 확신하게 만듦
serverless라는 용어 자체가 워낙 정의가 모호해서, 이름 자체가 넌센스라고 느낌
결국 서버는 여전히 존재함
"전기가 없는" 이라는 표현처럼, 실제로는 전기를 쓴다는 점과 비슷함
이름만 바뀌었을 뿐, 실제로 무슨 일이 벌어지는지 말해주지 않는 느낌임
"serverless가 나쁘다"는 결론이 전부는 아니라고 생각함
더 중요한 교훈은, 서비스에 종속성이 있다면 서비스를 클라이언트 가까이 옮기더라도 그 종속성까지 같이 옮기지 않으면 end-to-end 경험이 의외로 느려진다는 점임
필연적으로 종속성과 가까운 곳에서 빌드하는 것이 낫고, 부족하다면 모든 종속성을 클라이언트 가까이 옮기거나 동기화해야 하지만, 실제로는 그 과정이 너무나 복잡해지는 경우가 많음
이게 무조건 적용되는 규칙인지 잘 모르겠음
종속성을 어떻게, 얼마나 자주 쓰는지에 따라 다르고, DB라면 서버와 가까워야 할지, 클라이언트와 가까워야 할지 용도마다 다름
어떤 사용 시나리오에선 빠른 응답이 필요하고, 어떤 건 느려도 괜찮음
서버나 클라이언트에서 뭘 캐싱할 수 있냐에 따라 쪼갤 수도 있음
꼭 이분법적으로 생각할 일은 아니라고 생각함
최고 가격대비 성능비를 원한다면, 직접 인스턴스를 세팅해서 필요한 일을 자기가 직접 처리하는 것이 정답임
클라우드 업체들이 과도한 청구 마법사가 되게 둘 필요 없음
현재 우리가 "지역 최대치(local maximum)"에 도달한 것은, 도커 컨테이너를 표준 환경/배포물로 삼고 필요시 비밀값만 주입하는 식임
이렇게 하면 로컬 테스트가 쉽고, 인프라 자동화, 재현성 등 주요 이점은 대부분 살릴 수 있음
serverless는 대부분의 앱에는 과한 접근이지만, 일부 앱에는 잘 어울림
특히 자체 인프라가 필요 없는 간단한 유틸리티나 온디맨드 서비스, 규모가 큰 stateless 앱에는 serverless가 더 잘 어울릴 수 있음
serverless가 반드시 단순용도에만 쓰인다는 건 아니며, "전통적인 웹앱" 모델과 serverless 플랫폼 사이에는 근본적인 모순이 있다고 생각함
Docker는 마치 microservices와 비슷함
일부 앱에는 적합하지만, 업계 표준처럼 과대포장된 경향이 있음
Docker를 남발하면 보안 패치와 운영 부담이 생기는데, 무턱대고 모든 프로젝트에 쓰면 리스크 관리에 실패함
의존성 문제도 이제는 전역 설치를 안 하는 패턴으로 대다수 개발자가 해결함
예전만큼 Docker가 필수는 아니지만 여전히 대세임
호스팅 제공 업체 입장에서는 Docker 도입으로 마진이 최소 10%는 증가할 거라고 예상함
누군가가 아래에서 지적한 "도구 집착"에 Docker도 포함된다고 느껴짐
요점은 serverless가 안 통한다는 게 아니라, 저자들이 자기들이 구축하고 있는 기반을 잘 몰랐던 것임
지연 민감한 API를 stateless edge runtime에 올리는 건 초심자급 실수고, 그 결과로 겪은 고통은 충분히 예측 가능한 상황임
내 경험상, 클라우드 서비스의 문제 대부분은 아키텍처 오용이나 오해에서 비롯됨
좀 더 신중한 설계를 했으면 피할 수 있었던 인적 문제임
단, 문제는 대부분 클라우드 벤더들이 그럴듯한 마케팅으로 제품을 홍보하고 실제 성능 수치는 숨기고 있다는 점임
정말로 Lambdas가 내 워크로드에 충분히 빠른지, AWS RDS 외부 복제가 적합한지는 테스트 해보기 전까지 모름
AWS의 실제 성능은 직접 벤치마크 해야 한다는 걸 경험을 통해 배움
저자들이 이해하지 못했다는 게 포인트가 아니라, 누군가가 공유한 정보 자체가 가치 있음
이게 "초보 실수"라고만 볼 수 없을 것 같음
실제로 엔지니어들은 특정 방식이 실무에 적합하지 않다는 걸 알고 있고, 관리자가 "요즘 방식이니까" 식으로 손쉽게 밀어붙이는 경우가 흔함
혹은 시간과 비용 제한 때문에 "덜 나은 선택"을 할 수밖에 없을 때도 있음
또는 정말 원래 구현 팀이 제대로 몰랐던 것일 수도 있지만, 어쨌든 이런 스토리를 나누는 게 우리 전체 커뮤니티 발전에 큰 도움이 된다고 생각함
내 경험상 어떤 확실한게 필요하면(빠른 자동 확장, 짧은 지연, CPU, 디스크, 네트워크 속도 등) 직접 EC2 인스턴스를 관리하는 게 가장 확실함
제어권을 넘기고 성능 향상을 기대했다간 고칠 수 없는 병목을 맞게 됨
결국 저자들이 "오늘의 10,000명 중 한 명"임을 인정하는 셈임 https://xkcd.com/1053/
개인적으로 이런 정보와 실수를 공유해준 것에 고마움을 느낌
Hacker News 의견
몇 년간 serverless 환경(주로 amazon lambda, 그리고 다른 것도)을 사용한 경험자로서, 저자 의견에 적극 동의함
serverless가 어느 부분에서는 일을 덜어주지만, 동시다발적으로 "인위적으로 생기는 문제들"을 해결하느라 다른 분야에서 일이 늘어남
나의 한 사례는 업로드 용량 제한 문제였음
기존 애플리케이션을 serverless로 이전했을 때, 대용량 고객 데이터 import를 위해 API 엔드포인트를 만들고 백그라운드 작업자를 붙이면 충분할 거라고 생각했음
하지만 "api gateway"(코드를 호출하는 프록시)에서는 100MB 이상은 업로드가 불가능했고, 제한 변경이 가능한지 문의했더니 단순히 고객에게 더 작은 파일로 나눠서 업로드하도록 하라고 안내받음
기술적으로는 그럴싸하게 들릴 수 있지만, 실제 고객이 업로드 방식을 바꿀 리 없다는 점이 현실임
"진공상태에서는 잘 동작한다"는 느낌에 가까우며, 이론상 멋진 것 같지만 실제로 해 보면 serverless로 전환해 절감한 시간과 비용을 결국은 serverless 특유의 문제를 해결하느라 재투입하게 됨
이 문제를 해결하려면 presigned S3 URL을 제공해야 함
사용자가 S3에 직접 업로드한 뒤 업로드 결과를 보내주도록 하거나, 파일 이름을 request id로 구분하는 방법 등으로 연동할 수 있음
AWS 환경을 오래 써본 입장에서 이런 점이 성가시기는 한데, 임의 파일 업로드 API를 열어두면 DoS 공격 위험이 크기 때문에 100MB 제한 자체는 이해 가능한 부분임
다만 요즘 인터넷 속도가 빨라진 걸 생각하면 100MB 기준은 다소 시대에 뒤처진 느낌임
그래도 언젠가는 제한이 필요하다고 생각함
우리 회사는 한때 AWS SSL 인증서 부서를 대표하는 고객이었음
Vanity URL(커스텀 도메인)을 지원하려니 도메인마다 SSL 인증서가 필요했는데, 수천 개가 필요했음
AWS의 인증서 관리 도구는 수백 개 규모까지만 쾌적했기 때문에, 이 문제가 해결될 때까지 3개월 정도 걸렸음
AWS의 일부 서비스가 극소수 고객의 수요에 맞춰 빨리 대응하지 못한다는 점이 놀라웠음
처음엔 Lambda가 엄청 가능성 있어 보여서 도입했지만, 결국 모든 Lambda 프로젝트를 포기하고 필요에 따라 컨테이너 환경으로 옮겼음
Lambda도 Node 런타임을 1~2년마다 업그레이드해야 하고, 컨테이너를 쓰면 그 주기를 스스로 결정할 수 있기 때문에 더 유연함
컴퓨터 공학에서 가장 어려운 문제는 한 컴퓨터에서 다른 컴퓨터로 파일 복사하는 것임
미래의 독자를 위해 참고자료를 남김
"tus" 업로더와 endpoint를 사용하면 업로드 시 분할, 이어받기 등 기능이 제공되어 이런 제한을 극복하기에 적합함
https://tus.io/
기사에서 설명한 것처럼, serverless는 분명히 그 나름의 용도가 있음
하지만 대부분의 애플리케이션에는 적합하지 않다고 생각함
특별한 상황이 아니라면 serverless를 핵심 인프라로 쓸 계획이 없음
실제로는 오히려 인프라 관리가 더 번거로워진다는 인상임
플랫폼마다 요구사항이 다르고, 테스트/개발 방식도 제각각이라 매번 애매하고 로컬 테스트도 어려움
추상화 레이어도 각 플랫폼마다 함정이 있고 진짜 표준이 존재하지 않음
도커 이미지로 실행 파일을 패키징하는 게 더 편하고, 환경 세팅도 적당히 추상화할 수 있어 내겐 더 자연스러운 개발 환경임
리눅스 환경과 파일시스템 수준의 최소한의 추상화가 가장 효율적이라 느껴짐
필요하면 해당 이미지를 서버로 띄워놓고 온디맨드 혹은 항상 대기 상태로 운영할 수도 있음
지난 10년간 유행한 여러 기술 트렌드를 보면, 대형 기업이 자기 규모에서만 실질적으로 존재하는 문제를 해결하려 썼던 기술이 인기몰이 하는 경우가 많았음
사례로 GraphQL, react, Tailwind, NextJS 등 여러가지가 해당됨
어떤 도구든 모든 문제에 만능으로 통하는 것은 아니며, 자신의 상황과 문제에 대해 경험과 이해를 바탕으로 선택하는 것이 중요함
지금 내가 얼마나 "재미있게" amazon lambda 앱을 로컬에서 실행해보려 시도하는 중인지 말해주고 싶을 정도임
배포 전에 테스트하려고 하니 도전 과제 그 자체임
Knative(Kubernetes용 Serverless)는 컨테이너를 직접 받아줌
표준 패키징 포맷이기 때문에 다양한 플랫폼으로 쉽게 이동할 수 있음
그 팀은 실제로 애플리케이션이 아니라 상태를 가진 서버 애플리케이션에 통합될 라이브러리를 개발하고 있었음
성능상의 장점도 authentication을 고객 환경 근처에서 처리한 덕분이지, serverless 그 자체 덕분은 아님
사실 모든 "serverless" 플랫폼이 도커 이미지를 받아주지 않나?
Cloud Run은 지원하는 것으로 알고 있음
실은 “serverless function”이 너무 많은 것을 추상화해서 생기는 현상에 대한 우려임
ClickHouse는 수천 번의 작은 insert를 싫어해서, 우리는 chproxy라는 Go 서비스로 이벤트를 모아서 대량 batch로 보냄
각 Cloudflare Worker가 chproxy에 analytic 이벤트를 보내면, chproxy가 모아 ClickHouse로 대량 전송함
ClickHouse 데이터에 한정해서 굳이 별도 서비스를 따로 만든 대신, 비동기 insert 기능도 있었는데 왜 그걸 안 썼는지 궁금함
https://clickhouse.com/docs/optimize/asynchronous-inserts
개발자들은 "간편하게 해준다는" 툴들에 파묻혀 있는 느낌임
사실 대부분의 문제는 가장 기본적인 도구(컴파일러, bash 스크립트, 라이브러리)로도 쉽게 풀림
이처럼 도구에 집착하다 보니 회사와 개발자 모두에게 오히려 해가 될 때가 있음
내 생각엔, 2013년의 Docker야말로 마지막으로 정말로 보편적이고 긍정적인 변화를 준 도구였음
이후로는 어느 회사에는 도움이 될 수 있지만, 모든 회사에 다 적용하려다가 오히려 생산성이 깨지거나 시스템이 무너지는 사례가 많음
요즘 Cloudflare같은 곳에서는 v8 isolates가 '차세대 docker'가 될 것처럼 밀고 있지만, 일부 워크로드엔 저격이지만 모든 곳에 맞는 건 아님
"docker 이미지를 받아서 인터넷에 띄워준다"는 패턴이 너무 강력해서 2040년에도 여전히 제일 센 방식일 거라고 봄
근본기를 아는 사람이 점점 드물어진 것도 문제임
스택 대부분을 제삼자 서비스에 외주를 주는 식으로 업무가 진행되고, 정작 직접 만든 건 핵심 애플리케이션 일부뿐임
심지어 그것조차 AI가 작성하게 될 수 있음
업계 전체가 "학습된 무력감"을 키우고 있는 중임
생각보다 많은 사람들이 컴파일러, bash 스크립트, 라이브러리를 잘 모름
AWS lambda는 너무 쌀 정도임
인지도 제고 용도로는 도움이 됨!
bash 스크립트 써서 Staff 등급까지 올라간 사람은 본 적 없음
"vercel security checkpoint"에게 묻고 싶음
아이폰에서 proton VPN과 Firefox Focus 조합으로 캘리포니아, 캐나다 exit 노드로 접속하면 code 99 "Failed to verify your browser" 오류가 반복적으로 발생함
뭐가 문제임?
이 쓰레드는 내 생각을 확신하게 만듦
serverless라는 용어 자체가 워낙 정의가 모호해서, 이름 자체가 넌센스라고 느낌
결국 서버는 여전히 존재함
"전기가 없는" 이라는 표현처럼, 실제로는 전기를 쓴다는 점과 비슷함
이름만 바뀌었을 뿐, 실제로 무슨 일이 벌어지는지 말해주지 않는 느낌임
"serverless가 나쁘다"는 결론이 전부는 아니라고 생각함
더 중요한 교훈은, 서비스에 종속성이 있다면 서비스를 클라이언트 가까이 옮기더라도 그 종속성까지 같이 옮기지 않으면 end-to-end 경험이 의외로 느려진다는 점임
필연적으로 종속성과 가까운 곳에서 빌드하는 것이 낫고, 부족하다면 모든 종속성을 클라이언트 가까이 옮기거나 동기화해야 하지만, 실제로는 그 과정이 너무나 복잡해지는 경우가 많음
종속성을 어떻게, 얼마나 자주 쓰는지에 따라 다르고, DB라면 서버와 가까워야 할지, 클라이언트와 가까워야 할지 용도마다 다름
어떤 사용 시나리오에선 빠른 응답이 필요하고, 어떤 건 느려도 괜찮음
서버나 클라이언트에서 뭘 캐싱할 수 있냐에 따라 쪼갤 수도 있음
꼭 이분법적으로 생각할 일은 아니라고 생각함
최고 가격대비 성능비를 원한다면, 직접 인스턴스를 세팅해서 필요한 일을 자기가 직접 처리하는 것이 정답임
클라우드 업체들이 과도한 청구 마법사가 되게 둘 필요 없음
현재 우리가 "지역 최대치(local maximum)"에 도달한 것은, 도커 컨테이너를 표준 환경/배포물로 삼고 필요시 비밀값만 주입하는 식임
이렇게 하면 로컬 테스트가 쉽고, 인프라 자동화, 재현성 등 주요 이점은 대부분 살릴 수 있음
serverless는 대부분의 앱에는 과한 접근이지만, 일부 앱에는 잘 어울림
특히 자체 인프라가 필요 없는 간단한 유틸리티나 온디맨드 서비스, 규모가 큰 stateless 앱에는 serverless가 더 잘 어울릴 수 있음
serverless가 반드시 단순용도에만 쓰인다는 건 아니며, "전통적인 웹앱" 모델과 serverless 플랫폼 사이에는 근본적인 모순이 있다고 생각함
이제 misterio를 받아볼 준비가 된 것 같음
https://github.com/daitangio/misterio
간단한 stareless 도커 클러스터 래퍼임
나의 홈랩에서 시작했는데, 반향이 커졌음
Docker는 마치 microservices와 비슷함
일부 앱에는 적합하지만, 업계 표준처럼 과대포장된 경향이 있음
Docker를 남발하면 보안 패치와 운영 부담이 생기는데, 무턱대고 모든 프로젝트에 쓰면 리스크 관리에 실패함
의존성 문제도 이제는 전역 설치를 안 하는 패턴으로 대다수 개발자가 해결함
예전만큼 Docker가 필수는 아니지만 여전히 대세임
호스팅 제공 업체 입장에서는 Docker 도입으로 마진이 최소 10%는 증가할 거라고 예상함
누군가가 아래에서 지적한 "도구 집착"에 Docker도 포함된다고 느껴짐
요점은 serverless가 안 통한다는 게 아니라, 저자들이 자기들이 구축하고 있는 기반을 잘 몰랐던 것임
지연 민감한 API를 stateless edge runtime에 올리는 건 초심자급 실수고, 그 결과로 겪은 고통은 충분히 예측 가능한 상황임
내 경험상, 클라우드 서비스의 문제 대부분은 아키텍처 오용이나 오해에서 비롯됨
좀 더 신중한 설계를 했으면 피할 수 있었던 인적 문제임
단, 문제는 대부분 클라우드 벤더들이 그럴듯한 마케팅으로 제품을 홍보하고 실제 성능 수치는 숨기고 있다는 점임
정말로 Lambdas가 내 워크로드에 충분히 빠른지, AWS RDS 외부 복제가 적합한지는 테스트 해보기 전까지 모름
AWS의 실제 성능은 직접 벤치마크 해야 한다는 걸 경험을 통해 배움
저자들이 이해하지 못했다는 게 포인트가 아니라, 누군가가 공유한 정보 자체가 가치 있음
이게 "초보 실수"라고만 볼 수 없을 것 같음
실제로 엔지니어들은 특정 방식이 실무에 적합하지 않다는 걸 알고 있고, 관리자가 "요즘 방식이니까" 식으로 손쉽게 밀어붙이는 경우가 흔함
혹은 시간과 비용 제한 때문에 "덜 나은 선택"을 할 수밖에 없을 때도 있음
또는 정말 원래 구현 팀이 제대로 몰랐던 것일 수도 있지만, 어쨌든 이런 스토리를 나누는 게 우리 전체 커뮤니티 발전에 큰 도움이 된다고 생각함
내 경험상 어떤 확실한게 필요하면(빠른 자동 확장, 짧은 지연, CPU, 디스크, 네트워크 속도 등) 직접 EC2 인스턴스를 관리하는 게 가장 확실함
제어권을 넘기고 성능 향상을 기대했다간 고칠 수 없는 병목을 맞게 됨
결국 저자들이 "오늘의 10,000명 중 한 명"임을 인정하는 셈임
https://xkcd.com/1053/
개인적으로 이런 정보와 실수를 공유해준 것에 고마움을 느낌