좋은 의견 감사드립니다. 말씀해주신 "지연 시간을 줄이기 위해 state가 필요하다"는 점은 저희 아키텍처의 핵심적인 트레이드오프를 정확히 짚어주셨습니다.
먼저 쿼리 지연 시간에 대해 말씀드리면, 저희 벤치마크에서 p99(99th percentile)는 약 130-210ms 수준입니다. 아마 100배 차이라고 하신 부분은 본문에 언급된 '콜드 스타트 시 수 초가 걸릴 수 있다'는 최악의 경우를 보시고 말씀하신 것 같습니다. 짚어주신 대로 이 부분은 분명 저희 아키텍처의 단점이며, 본문에 언급했듯 프로덕션 환경에서는 0.01% 미만(P99.99)에서 발생합니다. 그외 대부분의 쿼리는 각 람다의 로컬 메모리와 디스크를 캐시로 활용하여 안정적인 성능을 내도록 설계되어 있습니다.
따라서 말씀해주신 대로, 모든 쿼리가 10ms 이하로 보장되어야 하는 초저지연 금융 거래 시스템 등에는 이러한 아키텍처가 적합하지 않을 수 있습니다. 하지만 대다수의 AI 기반 검색 및 추천 애플리케이션에서는 P99 기준 100-200ms 수준의 지연 시간은 충분히 좋은 성능이며, 인프라 비용과 운영 부담을 90% 이상 절감하는 이점이 훨씬 크다고 생각합니다.
다시 한번 깊이 있는 의견에 감사드립니다.
한글로 답변이 달릴 줄은 몰랐습니다! (너무 시니컬하게 썼네요...)
획기적인 아이디어라는 생각을 먼저 했었습니다. 사실 서버리스 DB들의 가장 큰 문제점이 드러나지 않는 곳에서 실제 서버가 돌아가고 있는 점이었습니다. 그래서 트래픽이 몰리면 그 서버가 할당 될 때까지 먹통이 되는 상황이 발생합니다. (대략 5분 정도) 그래서 현존하는 클라우드(AWS 등)의 서버리스 DB가 프로덕션 레벨에서 사용하기 어렵거든요.
써볼까? 싶었는데 걱정했던 이유는 그럼 mysql, postgresql 등에서 만들어놓은 인덱싱, 정렬 등의 바이너리 로직등을 구현해야하는데 그만큼 신뢰있는 오픈소스 DB 프로젝트를 람다 위에서 다시 만드는게 얼마나 어려운 일일까? 라는 생각이 들어서 였습니다.
직접 만드시는 제품이니 많은 발전을 기대하겠습니다~!
발상은 좋으나 쿼리 지연 시간이 줄이기 위해서 필연적으로 state가 필요해집니다. mysql, postgresql 등과 비교해서 쿼리 지연시간이 거의 100배나 높은 것 같습니다. 거의 파일 시스템에 입력하고 출력하는 것과 유사한 것 같네요.