Serverless는 유행인가?

최근에 느꼈던 나의 궁금증은 다음과 같다. 
 

aws에서 Lambda, DynamoDB를 최근 몇 년간 홍보하는 근본적인 이유가 궁금하다.

1.1. msa 방식이 많아지면서 서버리스 구축이 늘어나기 때문인지? 
1.2. 서버리스로 msa구축시 인프라 관리에 유연함이 생기긴 하겠지만, coldstart 문제와 비용 측면 때문에 작은 서비스에서는 많이 채택하지 않는 것으로 알고있다. dynamodb는 join이 안되고, foreignKey역할을 못한다는 단점 등이 있는데, 물론 서비스마다 적합한 db는 다르겠지만 rds보다 dynamoDB를 사용하는게 비용절감 되는 폭이 이러한 단점들을 극복하거나, 서버리스가 확실한 장점이 있기 때문에 적용이 되는 것인가? 
 
서버리스가 어느정도 '유행'처럼 느껴져서 어떠한 이유로 많은 활용을 추진하는지 궁금했다.
 
그에 따른 여러 기업과, 서버리스 혹은 IaC에 관심있는 사람, 그리고 스타트업에 종사하는 입장은 다음과 같았다. 
 

 

답변 1. 

AWS에서 본인들 자체적으로 NoSQL 데이터베이스를 만들어서 serverless로 비용이 저렴하게 제공하는 건 아마 본인들의 고객들을 lock-in 시키기 위한 목적이 제일 클거에요. AWS에서는 특정 VC로부터 투자받은 스타트업들을 대상으로 2년간 최대 10만불(약 1억3천만원정도)의 크레딧을 지원하기도 하는데, 스타트업 생태계를 위한 지원인 것 같지만, 사실 2년간 1억3천만원을 다 태울정도의 서비스를 운영하는 회사라면 

서비스의 규모가 클것이고,당연히 트래픽이 클것이고쌓이는 데이터가 많을 것입니다.

그러면 이 트래픽을 AWS에서 처리하기위해 엄청 노력했는데 ,크레딧을 다 썼다고 다른 플랫폼으로 넘어가기 어려워질것이고. 그러면 앞으로 향후 몇년간 해당 회사는 AWS의 고객이 될 수밖에 없을거에요. 결국엔 돈때문이 아니냐!라는 의견입니다

 
람다 자체도 벤더 이동이 어렵고,
AWS도 어쩔 수 없는 enterprise기업이기 때문에
값 싸게 dynamoDB를 제공하는 식으로 운영해서 lock-in시키는 게 목적이지 않은가 하는 입장.
 
 

답변 2.  

저는 "서버리스"를 부정적으로 생각하진 않습니다.
메모리 수준부터 관리하던 c언어에서, 가비지 컬렉터가 책임지는 go까지 기술의 발전은 점점 개발 외에 신경 쓸 일을 줄이고 있음
인프라 기술도 비슷한 방향으로 가는 거라고 생각
그래서 서버리스를 저렴하게 사용할 수 있는 Cloudflare 짱짱

 
최근 cloudflare에 관해 알게 되었는데, 
IfC(infra from code)라는 새로운 개념도 알게 되었다.
 
 

출처 : https://dev.to/swyx/the-self-provisioning-runtime-3g6d

나는 이 사진 속 로직에서,
←
이런 방향으로 발전이 되어가고 있는건지가 좀 궁금했는데,
그래서 현재 나온 개념 중의 최종 발전은 IfC인가? 싶었는데,
그런 식이라기보다
어쩌면 좋은 점들을 통합한 logic이 IfC 일 수 있겠다는 생각을 했다.
cloudflare에 관련한 글을 찾고자 한다면 최근 pingora를 오픈소스로 공개한 내용을 찾아보길 바란다. 
(Rust의 대중성에 대해선 약간은 회의적인 입장이 들지만...)
 

"서버리스에 속지 마세요. 컴퓨터의 컴퓨팅 사이클 전체가 필요하다면, 그 컴퓨터를 사야 한다는 사실을 바꾸는 마법 같은 것은 없어요. 독점적인 서버리스 구성으로 시작하면 락인에서 벗어날 수 없다는 걸 알게 될 거에요"

 
서버리스가 어쩔 수 없는 락인 구성으로 되어있다는, 속지말라는 의견도 존재!
 
https://news.hada.io/topic?id=8623

서버리스에 속지 마세요 | GeekNews

 

 

답변 3. 

그리고 어쩔 수 없이
가장 값싼 비용과 쉬운 배포를 주안점에 둘 수 밖에 없는 스타트업, 창업 기업의 입장은
아무래도 
serverless가 서버를 구축하지 않고
firebase, supabase, aws amplify와 같은 저렴한 BaaS 서비스를 이용할 수 밖에 없다는 것!
서버리스가 아무래도 시발점에서는 큰 매력으로 다가올 수밖에 없고,
DAU가 적은 입장에선 활용하는 것이 유리하다는 입장.
 

 

답변 4. 

 

1. lambda와 dynamodb의 홍보 이유?

- Serverless 시장을 지금 누가 많이 먹냐 싸움이여서 파격적인 가격 (몇백만건까지 무료)으로 CSP들이 본인들 서버리스를 제시하고 있어서 lambda 홍보가 많이 보이는 것 같습니다.

- DynamoDB는 NoSQL 쪽 시장이 뜬지 얼마안됐고,서버리스까지 합쳐서 Cloud 쪽에서 해당 서비스 파이를 많이 차지하고 싶어서 홍보가 많은 것 같습니다.
- 서버리스 db 자체는 aurora와 같은 rds에서도 사용가능합니다.

 

 

1.1. msa 방식이 많아지면서 서버리스 구축이 늘어나기 때문인지? 

서버리스 인기는 MSA와는 별개인 것 같습니다. 
그냥 어중간한 트래픽 발생량에서 효율적인 거 같아요. 
서버리스-MSA 아키텍처라는 의미를 정확히 이해가지않는데, Fargate 기반으로 구축한 것 정도는 주변 사례에서 봤습니다.

+ Fargate msa

• https://brunch.co.kr/@tmapmobility/13
• https://youtu.be/N0uLK5syctU?si=zdzXFyHCtcWwdF7s

 

 

1.2. 서버리스로 msa구축시 인프라 관리에 유연함이 생기긴 하겠지만, 

coldstart 문제와 비용 측면 때문에 작은 서비스에서는 많이 채택하지 않는 것으로 알고있다. 

말씀하신대로 cold-start가 실 프로덕션 운영에 지장을 주는 경우를 고려하여
많은 csp가 “Instance Pre-warming” “Instance Reuse”라는 방안으로 대처 중입니다. 
최적화가 되지 않는다는 단점외에는 모놀리스 서비스에는 대처 가능합니다.

 

+ 이 답변을 받고

1) cold-start 해결방법으로 가장 많이 쓰이고 있는 방안은 무엇인지?

2) 얼마나 cold-start문제를 극복할 수 있는지?

3) cold-start를 신경 쓰지 말라는 의견은 왜 그런건지? 

궁금해져서 더 찾아봤다.

 

 

 

1) cold-start 해결 방안 

 

1. function을 warm하기 유지하기 : 정기적인 저비용 호출 또는 "ping"을 통해 warm상태로 유지 
2. VPC 리소스를 최소화 하기 : VPC 내의 리소스에 액세스해야 하는 Lambda 함수의 경우 콜드 스타트가 더 오래 걸리니까 VPC 리소스 사용을 줄이기
3. 기능 구성 최적화 : Runtime이 짧은 언어를 선택하거나, Lambda의 CPU 성능, 네트워크 대역폭 및 디스크 I/O는 구성된 메모리 양에 비례하므로 메모리가 더 많은 함수는 더 빠르게 실행되고 초기화될 수 있습니다. 메모리를 늘리거나 / 배포 패키지를 줄이기 = 메모리를 늘리면 인스턴스의 사양이 올라가 처리 속도가 빨라질 수 있음, 
4. Lambda 컨테이너 재사용하기 (Instance Reuse) : 이는 Lambda 함수가 한 번 실행된 후 일정 시간 동안은 컨테이너가 유지되어, 같은 함수가 다시 호출될 때 빠르게 응답할 수 있게 합니다.
5. 프로비저닝된 동시성(Provisioned Concurrency) 기능 활성하기 : AWS Lambda의 프로비저닝된 동시성 기능을 활성화하여, 미리 일정 수의 Lambda 인스턴스를 "warm" 상태로 유지함(계속 켜두기)으로써 Cold Start를 줄일 수 있습니다. 이 방법은 특히 예측 가능한 트래픽 패턴이 있는 경우 유용합니다.
   • (하지만 EC2와 비용차이가 많이 안난다)
6. 프로비저닝 오토스케일 : 함수에 예측 가능한 트래픽 패턴이 수신되는 경우 예약된 크기 조정을 사용합니다. 함수가 특정 사용률(%)을 유지하도록 하려면 대상 추적 스케일링 정책을 사용합니다. 대상 추적을 통해 Application Auto Scaling은 스케일링 정책 정의 방식에 따라 CloudWatch 경보 세트를 생성하고 관리합니다. 이러한 경보가 활성화되면 Application Auto Scaling은 프로비저닝된 동시성을 사용하여 할당된 환경의 양을 자동으로 조정.
   •  가장 정석적이지만 조금 까다로운 방식.
   • https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/provisioned-concurrency.html#managing-provisioned-concurency

 

 

1.1) autoscaling이 정석적인 방식인 것 같은데, 현업에서는 cold-start를 최대한 해결하기 위해서 기능 구성 수정(메모리 늘리기, 패키지 줄이기, VPC 리소스 최소화 등등)이나, instance pre-warming 이나 reuse 의 방안을 더 많이 쓰는지? (아무래도 이것도 서비스에 따라 다르게 선택하겠다는 생각이 들지만…) 보편적으로 많이 선택하는 방안이 있는지?

 

 

auto scaling은 요즘은 기본적인 사항이라 고려하지 않을 기업은 없을 것 같습니다. 
auto scaling을 사용하지 않는 경우는, 
굳이 해당 작업을 해야할 정도로는 1) 트래픽 변동성이 크지 않다. 2) 트래픽이 많지 않다 정도
auto scaling을 사용해도 여전히 문제가 발생할 거다.

기본적으로 cold-start가 생김에 따라 전체적인 트랜잭션 처리에 추가적인 latency가 하나 생길 수 밖에 없습니다. 
메트릭을 일정 시간 단위 이상으로 쪼개서 처리도 현재는 불가능해서 한계가 있습니다.

(AWS Korea 시니어)박사분이 새 연구를 진행하고 계시는데, 
해결하고자하는 문제점 중 하나가 '시계열 딥러닝 모델이 아무리 발전하더라도 정말 최적으로 동적인 auto scaling은 현재는 불가능하다. 시계열 메트릭 데이터 time window(분, 초,…)를 쪼개서 예측하는데 한계가 있고, 그렇다고 더 쪼개지 못하면 UX에 지장을 주는 latency가 발생하기 때문이다' 입니다. 
>> 아직 CSP 들도 고려하는 문제다 ㅎㅎ

 

 

instance pre-warning이나 reuse 등은 “serverless”라는 Cloud Service에서 사용가능한 옵션 같은 것입니다. 
다만 동적이 아닌 정적인 옵션으로 아키텍처 별 최적화가 불가능하다는 단점 + 현재는 CSP 측에서 비용 부담 중 으로 인해, 
아직도 연구되고 있습니다. 
(재작년부터 나온 서버리스 논문의 대부분이 “Stateless”와 “Cold-Start”를 심각하게 찝고있는 걸 보면 아직도 이 부분은 명확한 답이 없을 것 같습니다.)

 

 

메모리 확장, 패키지 압축, docker container image 용량 최적화 등은 “Application” 특성에 따라 최적화 가능한 옵션입니다.
위에 것들 + auto scaling까지 다 하면 어찌됐든 아예 안할 때보다는 최적화되겠죠. 
유즈케이스에 따라 비용(학습이든 개발이든 유지, 관리든 모든 비용)만 따졌을 때 타당하고 이득이 많은 솔루션이면 기업은 도입합니다. 

 

 

 

• 아티클 참고

제일 눈에 잘 들어오게 정리되어 있다고 생각하는 글 ↓

• https://medium.com/@bloggeraj392/demystifying-cold-starts-in-aws-lambda-e2b333320bc4

Demystifying Cold Starts in AWS Lambda

• https://hackernoon.com/how-to-solve-the-problem-of-cold-starts-in-serverless-systems
• https://conermurphy.com/blog/pre-warming-lambda-functions-eventbridge-rules
• https://builtin.com/software-engineering-perspectives/cold-starts-challenge-serverless-architecture
• https://blog.bohr.io/cold-start-in-serverless-the-overcome-problem-that-still-generates-prejudice#heading-how-was-the-cold-start-problem-in-serverless-overcome
• https://www.readysetcloud.io/blog/allen.helton/built-better-serverless-apis-by-going-storage-first/
• https://www.pluralsight.com/resources/blog/cloud/does-coding-language-memory-or-package-size-affect-cold-starts-of-aws-lambda
• https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-%EB%9E%8C%EB%8B%A4-%EC%84%B1%EB%8A%A5-%EA%B0%9C%EC%84%A0-Cold-Start-%ED%95%B4%EA%B2%B0

 

 

 

 

 

2) 에 대한 답변은, 각종 실험 결과로 얼마나 줄일 수 있는지 연구한 자료를 참고할 수 있다.

 

• coldstart 해결에 관한 논문 참고

• https://www.usenix.org/system/files/hotcloud19-paper-mohan.pdf
• https://sites.cc.gatech.edu/fac/Kishore.Ramachandran/pubs/ACM-SEC-2022-Cold-Start.pdf
• https://par.nsf.gov/servlets/purl/10320371
• https://www.researchgate.net/profile/Thiago-Silva-18/publication/347439620_Prebaking_Functions_to_Warm_the_Serverless_Cold_Start/links/5fdbb259a6fdccdcb8d6c98d/Prebaking-Functions-to-Warm-the-Serverless-Cold-Start.pdf

 

 

3) cold-start를 신경 쓰지 말라는 의견

 

: https://www.readysetcloud.io/blog/allen.helton/lets-stop-talking-about-serverless-cold-starts/

 

왜 신경 쓰지 말라고 하나? >> 

- 우선, 추가 종속성(additional dependencies)을 사용하지 않더라도 function package size가 증가하면 cold start duration이 증가한다.
- 언어의 경우 평균 콜드 스타트는 500ms 미만으로 실행되는 반면, 컴파일된 언어는 조금 더 오래 실행됩니다(Java의 경우 약 5초, Java는 JDK 때문에 제일 느리고, Python이 제일 빠르다.)
- 500ms의 추가 대기 시간을 고려할 때 대부분의 프로덕션 사용 사례는 콜드 스타트로 인해 심각한 영향을 받지 않습니다.

 

>> 하지만 latency에 sensitive한 영향을 받는 프로덕션은 반드시 존재할 것이라고 생각한다. 

이런 프로덕션은 serverless를 사용하지 않든가, serverless를 사용하는 게 그래도 좋다면 cold-start를 최대한 줄이는 방안을 사용하지 않을까... 

 

 

요 링크는 aws와 edge 플랫폼 상 서버리스 관련 연구인데, 기존 서버리스 비효율 제시하는 부분만 보고 버리셔도 됩니다.
비용은 둘째치고 msa에서 serverless 사용 시, 트랜잭션 처리가 문제될 것 같네요.

 

Latency and resource consumption analysis for serverless edge analytics - Journal of Cloud Computing

 

 

+ msa에서 serverless활용한 사례가 궁금해서 찾아봄.

• Amazon Memory DB를 활용해 더 견고한 MSA 서비스 구축하기: https://www.youtube.com/watch?v=hcxBR21J9Xg
• https://docs.aws.amazon.com/ko_kr/memorydb/latest/devguide/what-is-memorydb-for-redis.html

MemoryDB for Redis란 무엇입니까? - Amazon MemoryDB for Redis

 

++ 근데 여기서 발생하는 transaction문제는 어떤 클라우드 서비스를 활용해서 해결할까?

 

>> cloudwatch이나 cloudtrail를 통해 로깅과 모니터링은 가능하나, 뭔가 transaction 내구성을 높였다는데 memoryDB 안에서 primary로 쌓인 log를 확인해서 관리하는 건지, 어떤 식으로 해결하는지는 아직 잘 모르겠다. 

 

>> 추가로 받은 답변. 

데이터 손실이 되어도 큰 문제가 없는 데이터 위주로 처리하는 것 같습니다.
memoryDB를 도입할 정도면 이미 가용성 높은 데이터베이스가 있을 것이다.
하지만 트랜잭션(ACID) 원칙 자체에는 취약할 수 밖에 없는 근본
그럼에도 aws라 우리가 세팅하는 데이터베이스보다 가용성은 높을 것.
아마 마이크로서비스 하나를 빠르게 만들 필요가 있을 때는 도움이 많이 될 것 같습니다.

in-memoryDB랑 활용점은 유사한 듯...

하지만 데이터는 중요하니까... 서버리스DB를 사용하는 건 정말 선택적인 문제... 

 

 

 

1.2. dynamodb는 join이 안되고, foreignKey역할을 못한다는 단점 등이 있는데, 물론 서비스마다 적합한 db는 다르겠지만 rds보다 dynamoDB를 사용하는게 비용절감 되는 폭이 이러한 단점들을 극복하거나, 서버리스가 확실한 장점이 있기 때문에 적용이 되는 것인가? 

dynamodb의 join, foreignKey등에 대해서 말씀하신 부분은 서버리스와 별개로 그냥 nosql의 단점입니다.
유즈케이스, 서비스, 데이터 특성에 맞게 nosql이나 rdbms 중 하나 선택하면됩니다. 정답은 절대 없습니다.
온프레미스로 따지면, Cassandra vs MySQL? 정도 되겠네요

 

+ https://aws.amazon.com/ko/compare/the-difference-between-cassandra-and-mongodb/

Cassandra와 MongoDB - NoSQL 데이터베이스 간의 차이점 - AWS

 

 

 

++

 

요 링크는 작년 USENIX라는 탑 컨퍼런스에서 AWS가 발표한 lambda관련 논문 요약입니다.
대충 서버리스 기술 뿐만 아니라 기존 s3 + aws caching 시스템 + aws만의 가상화 기술(firecracker?) 등등으로 “클라이언트 한명 당” 10GB가 넘는 Docker Image를 150개까지 동시 스케쥴링이 가능하다는 얘기입니다.

(Review) On-demand Container Loading in AWS Lambda

 

 

---

 

 

 

선택적으로 서비스별 적절한 서버 구축 서비스를 선택하는 것이 당연하다는 생각으로 종결되었다.
그리고... 아무래도 서버를 관리할 필요가 없다는 것은, 
유지보수 측면에서 어느정도 위험한 점이 크다는 생각. 
서버를 구축할 수 밖에 없는 기업 입장에서는 유지보수와 msa라면 각종 tracing과 observability 도 추적해야하기에
어느정도 적당한 서비스의 운영에서까지만 서버리스가 용이한 방식으로 채택되는 게 아닌가 싶은 생각이었다.

 

참고한 글은 다음과 같다.
유행처럼 느껴졌던 서버리스에 대해서 조금은 여러 입장을 이해할 수 있게 된 것 같다. 
 

 

---

 

 

• DynamoDB에 관한 참고 글

https://www.alexdebrie.com/posts/dynamodb-single-table/

The What, Why, and When of Single-Table Design with DynamoDB | DeBrie Advisory

 

 

• msa에 관한 참고글

https://news.hada.io/topic?id=13754

단순한 아키텍처를 옹호하며 (2022) | GeekNews

 
https://www.youtube.com/watch?v=r8mtXJh3hzM

 
이 강연은 조금 옛날 영상이긴 하지만,
msa의 failing한 이유와 fd에 따를 경우 어떤 식의 단점이 있는지
초기 msa구축에 대해서 잘 설명해 준 것 같다.