[AWS] Lambda: 특징과 주의사항
Lambda는 간편한 서버리스 서비스이며, AWS에서 가장 강력한 도구 중 하나다.
배포도 간편하고, 사용도 간편하고, 사용량에 따른 스케일링도 자동으로 되니 이상적인 시스템으로만 보인다.
하지만 다른 모든 것과 마찬가지로, 흑과 백이 존재한다. 잘 알고 활용해야 한다.
비용 효율성
Lambda는 사용사례에 따라서 저렴할 수도, 비쌀 수도 있다.
정확히 말하면, CPU 집약적이면서도 사용량이 불규칙하게 튈 수 있는 경우에는 Lambda가 확실히 강력하고 비용면에서도 좋을 수 있다.
혹은, 하루에 몇번 호출되거나 하는 사용 빈도가 낮은 배치성 작업에도 괜찮은 편이다.
하지만 사용량이 증가한다면 EC2나 Fargate 같은 프로비저닝 리소스에 비해 비용효율성도 급감하기 시작한다.
이런 식으로 비용이 깨지는 것도 드물지 않게 발생할 수 있다.
이 경우에 500$가 나온건 "LLM을 쓰는 에이전트 서버"였는데, 사실 LLM I/O로 인한 대기가 너무 많아서 Lambda에는 적합하지 않은 사례였다.
Lambda는 실행시간이 길어질수록 비싸지는데, I/O로 인한 대기는 리소스도 쓰지 않고 yield가 가능한 저렴한 동작이기 때문이다.
그래서 저 500$가 나온건 실제로 ECS로 교체했을 경우 50$~100$ 정도 선에서 감당 가능했다.
네트워크 & 트래픽 구조
Lambda는 네트워크적으로 독특한 구조를 갖고 있다.
VPC를 설정하고 아니고에 따라서 동작 방식이 완전히 달라진다.
VPC 없는 경우
이게 기본 옵션이다.
그냥 만든 Lambda는 public 리소스처럼 동작한다.
대충 뭐 이래저래 쓰는건 괜찮은데, VPC 내에서만 접근 가능한 DB나 서버 등에 접속할 수 없고, 내부통신이 안된다는 문제가 있다.
- 외부통신을 타기 때문에 트래픽 비용 상승 가능성
- VPC 전용 리소스 접근 불가
VPC가 있는 경우
뭔가 서버 스택들과 유기적으로 맞물리게 하려면 VPC를 구성하고 private 서브넷을 붙여야한다.
여기서 유의할 점은, public 서브넷을 붙인다고 public 리소스처럼 동작하지 못한다는 것이다. 그러면 그냥 외부인터넷 접근이 안된다.
이렇게 하면 VPC 내 접근이 가능하며, 내부통신으로 인한 보안/트래픽 비용 최적화가 가능해진다.
단점은 private 리소스가 되기 때문에 외부 인터넷에 대한 접근은 NAT Gateway를 통해서만 이루어진다는 것이다. NAT 요금이 튈 수 있다.
서버리스는 마법이 아님
그냥 대충 실행하는대로 마법처럼 서버가 뜨고 사라지는 것처럼 보이지만, 사실 그렇게 순진하게 돌아가진 않는다.
Lambda의 동작방식은 대강 이렇다.
- 처음 요청이 들어왔을때는 서버 컨테이너 A를 하나 띄우고, 거기에서 처리한다.
- 또 요청이 들어왔을때, A 컨테이너가 놀고있다면 A 컨테이너에서 처리한다.
- 또 요청이 들어왔을때, A 컨테이너가 바쁘다면 B 컨테이너를 띄워서 거기에서 처리한다.
그냥 이렇게 작고 빠르게 뜨는 서버를 올렸다 내렸다 하면서 서버가 없는 것처럼 마술을 보여줄 뿐이다.
그래서 컨테이너를 새로 띄우는 시점에는 지연시간이 좀 존재할 수 있으며 (일명 cold start)
https://m.blog.naver.com/sssang97/223091966658
기존 컨테이너 상태가 별로 좋지 않다면 순간적으로 성능이 떨어지거나 하는 문제도 종종 발생한다.
처리량이나 성능이 항상 균일하지는 않다는 것이다.