Enterpret가 단 두 명의 엔지니어만으로 확장 가능한 AI 플랫폼을 구축한 방법
대부분의 초기 단계 SaaS 스타트업이 서버를 프로비저닝하고 Kubernetes 클러스터를 계획할 때 Enterpret는 조용히 다른 방향으로 나아갔습니다. 당시 3명 남짓한 팀은 주로 AWS Lambda를 기반으로 엔터프라이즈급 AI 피드백 플랫폼을 구축하기로 결정했습니다.
그것은 반대의 내기였습니다. 5년이 지난 지금도 이는 회사의 아키텍처, 문화 및 속도를 형성하는 중추적인 결정 중 하나로 남아 있습니다.
제약에 의한 시작
초기에 Enterpret는 고객이 기록 데이터를 동기화하거나 공개 이벤트가 입소문을 낼 때마다 대량의 텍스트, 컨텍스트, 메타데이터 등 엄청난 양의 고객 피드백 데이터를 수집해야 했습니다. 섭취와 농축에 대해 많은 계산이 이루어졌습니다. 실제 사용자 문의는 상대적으로 적었습니다.
자본은 부족했고 엔지니어링 능력은 더욱 부족했습니다. 수석 설계자인 Anshal Dwivedi는 “우리는 상시 컴퓨팅을 할 수 있는 여유가 없었습니다. 두 명의 엔지니어와 한 명의 인턴이 있기 때문에 클러스터를 유지 관리하는 것은 비현실적이었습니다.”라고 회상합니다.
Lambda는 기존 컴퓨팅이 제공할 수 없는 기능, 즉 비용 부담 없는 탄력성을 제공했습니다. 무슨 일이 일어났을 때만 비용을 지불했습니다. 유휴 상태는 무료였습니다.
Enterpret는 작지만 빠르게 진화하는 풋프린트인 8개의 마이크로서비스와 약 35개의 Lambda 기능으로 출시되었습니다. 이를 통해 팀은 인프라 트레일을 소진시키지 않고 긴급하게 움직일 수 있었습니다.
결정을 눈에 띄게 만든 것은 서버리스에 대한 초기 투자가 아니었습니다. 그가 의도적으로 출구 경사로를 설계한 방식이었습니다. 워크로드에 좀 더 지속적인 기능이 필요한 경우 ECS로 마이그레이션하려면 배포 래퍼를 변경하는 것 외에는 거의 필요하지 않습니다. 비즈니스 논리는 그대로 유지됩니다.
이 예측은 팀이 내린 가장 중요한 결정 중 하나입니다.
시스템의 일관성을 유지하는 모노레포
제품 규모가 확장됨에 따라 Enterpret는 코드 기반을 손상하지 않고 성장을 관리해야 하는 새로운 문제에 직면했습니다. 그들의 대답은 각 백엔드 마이크로서비스, 공유 라이브러리 및 인프라 설정에 대한 단일 Go 모노레포라는 전통적인 시작 조언에 어긋나는 또 다른 결정이었습니다.
혼란보다는 일관성을 부여했습니다.
모델을 한 번 변경하고, 한 번 수정하면 어디든 배포할 수 있습니다. 오류 코드, 로그 형식 및 추적 표준은 모든 서비스에서 균일하게 유지되었으며, 이는 일반적으로 디버깅에 리포지토리와 로그 스트림 간의 동굴 탐험이 포함되는 분산 시스템의 축복입니다.
리팩토링은 위험하지 않고 일상화되었습니다. 자동 중단으로부터 보호되는 IDE 수준 유형 검사입니다. 배포는 예측 가능하게 유지되었습니다.
이 동일한 모노레포는 이제 원래 8개에서 늘어난 26개 서비스를 호스팅합니다. 배포는 일주일에 여러 번 발생하며 기본 구조가 분리되지 않았기 때문에 팀이 빠르게 이동합니다.
여전히 유지되는 경량 RPC 레이어
아주 초기에 팀은 한계에 부딪혔습니다. AWS API Gateway는 기본적으로 gRPC를 지원하지 않았지만 Enterpret에는 Lambda에 적합한 소형 바이너리 통신 계층이 필요했습니다.
일반적인 경로에는 해결 방법이나 더 무거운 프레임워크 채택이 포함되었습니다. 대신 효율성을 위한 HTTP 기반 protobuf, 유연성을 위한 JSON, 다운스트림 gRPC 지원 등 여러 인코딩을 지원하는 린 RPC 추상화를 만들었습니다.
몇 달이 아니라 며칠이 걸렸습니다. 그럼에도 불구하고 이는 지금도 서비스 통신의 중추로 남아 있습니다. 압축, 분산 라우팅, 메트릭 및 고객 생성은 개별 서비스를 건드리지 않고 계층화되었습니다. 이는 이제 팀이 의도적으로 최적화하는 복합적인 효과입니다.
Lambda가 정답이 아닌 경우
성장은 결국 서버리스의 한계를 드러냈습니다.
프런트 엔드 분석에서 첫 번째 균열이 나타났습니다. 콜드 부트는 대시보드가 수십 개의 병렬 쿼리를 실행할 때 눈에 띄는 대기 시간을 추가했습니다. 프로비저닝된 동시성으로 인해 지연이 줄어들었지만 시스템 실행 비용이 많이 들었습니다. 이러한 워크로드를 ECS로 마이그레이션하면 P95와 그에 따른 비용이 절감됩니다.
장기적인 작업이 이어졌습니다. Lambda의 15분 제한은 대부분의 비동기 작업에 적합했지만 보고 및 내보내기에는 더 많은 여유 공간이 필요했습니다. Enterpret는 포인트 인스턴스를 지원하는 AWS Batch로 전환하여 훨씬 적은 비용으로 동일한 유연성을 달성했습니다.
Lambda의 6MB 페이로드 제한, API Gateway의 29초 제한 시간과 같은 다른 제한 사항도 있었습니다. 팀은 S3 기반 응답 및 일괄 요청을 다운로드하여 라우팅했지만 교훈은 분명했습니다. 올바른 도구는 시간이 지남에 따라 변경된다는 것입니다.
팀이 시스템을 설계한 방식으로 인해 마이그레이션을 다시 작성하는 경우는 거의 없었습니다. 종종 한 시간이었습니다.
철학으로서의 비용 규율
부팅 속도 단계에서 비용은 측정 기준이 아니라 생존 가능성 제약 조건입니다. Enterpret는 메모리 할당, 유휴 계산, 콜드 스타트, 서비스 간 채팅 등 모든 것을 감사했습니다. Go의 효율성 덕분에 많은 Lambda 기능이 여전히 128MB에서 실행됩니다.
어느 시점에서는 CloudWatch 청구서가 총 IT 지출을 초과했습니다. 이로 인해 이상주의가 아닌 운영 현실에 기반을 둔 더욱 엄격한 관찰 위생, 경고 임계값, 청구 검토 및 아키텍처 선택이 가능해졌습니다.
징계가 중단되었습니다.
Enterpret 플레이북은 이제 다른 기능을 제공합니다.
돌이켜보면 Dwivedi는 회사가 다시 같은 결정을 내릴 것이라고 말했습니다. 서버리스는 팀에 가장 필요할 때 속도, 비용 제어 및 집중을 제공했습니다. 모노레포, RPC 추상화, 마이그레이션 준비 디자인 등 모든 것이 동일하게 유지됩니다.
그러나 회사는 Lambda 이외의 하드 튜닝 워크로드에 대해서는 더 신중할 것입니다. 이전에는 데이터 수집 서비스 중 하나에 긴 실행 시간이 필요했기 때문에 팀에서는 대기 시간을 피하기 위해 이를 AWS Step Functions 및 체크포인트 로직과 결합했습니다. 효과가 있었지만 유지하는 것은 고통스러웠습니다. AWS Batch는 첫날부터 올바른 결정이었을 것입니다.
다른 엔지니어링 팀에 대한 그의 조언은 다음과 같은 몇 가지 원칙으로 요약됩니다.
인프라를 완전히 단순하게 유지하세요. Enterpret는 4년 동안 단일 인프라를 호스팅하지 않았습니다. 관리형 서비스와 지루한 기술이 점점 더 스마트 솔루션을 압도하고 있습니다. Dwivedi는 “살아남는 스타트업은 스마트 인프라를 갖춘 스타트업이 아니라 클라우드가 무거운 작업을 수행하는 동안 제품에 집중하는 스타트업입니다”라고 말합니다.
비용을 무자비하게 대하십시오. 이는 트랙에 직접적인 영향을 미칩니다. 비용 알림을 설정하고, 매주 송장을 검토하고, 모든 품목에 대해 질문하세요. 작은 누출로 인해 출혈이 발생했습니다.
첫날부터 수평적 규모를 고려한 설계. “빠른 것과 더러운 것”과 “확장 가능한 것” 사이의 인지된 노력의 격차는 종종 환상입니다. 몇 가지 좋은 추상화와 명확한 서비스 경계를 구현하려면 사전에 시간이 조금 더 걸리지만 나중에 다시 작성할 필요가 없습니다.
클라우드 불가지론을 너무 빨리 추구하지 마세요. Enterpret는 AWS에 전념하고 있습니다. 어디에서나 작동하는 것으로 자신을 제한하면 가장 낮은 공통 분모를 최적화하는 것입니다. 각 클라우드가 잘하는 것이 아니라 클라우드가 가장 잘하는 것을 채택하여 더 나은 시스템을 확보하세요.
5년이 지난 지금도 그 건축물은 여전히 남아있습니다.
여행은 계속된다
Enterprise는 현재 수억 건의 고객 피드백 기록을 처리하고 있습니다. 첫 해에 팀이 작성한 많은 시스템은 여전히 작동 중이며, 작동할 뿐만 아니라 번성하고 있습니다. 팀이 구성 임계값을 조기에 발견하고 이를 고수했기 때문에 진화, 확장 및 적응이 가능했습니다.
회사는 현재 에이전트 아키텍처를 구축하여 AI가 고객 피드백을 통해 수행할 수 있는 작업의 새로운 영역을 확장하고 있습니다. 환경은 여전히 진화하고 있으며 팀은 여전히 무엇이 효과적인지 배우고 있습니다.
“서버리스 여정의 일부 패턴은 매우 잘 해석됩니다. 다른 패턴은 완전히 다시 생각해야 합니다.”라고 Dwivedi는 말했습니다.
교훈은 서버리스가 모든 사람을 위한 답이 아니라는 것입니다. 사소하고 사려 깊은 결정은 시간이 지나면서 쌓이게 됩니다. 확장보다는 진화하는 시스템을 설계하십시오. 재치보다는 명확성을 선택하십시오. 기술의 한계에 도달하면 기술이 마이그레이션됩니다. 다시 쓰지 마세요
이는 Enterpret이 구축하는 기능을 간략하게 보여줍니다. 엔지니어링 블로그에서 이에 대해 자세히 알아보세요. 여기.