Run Your Functions Instantly over HTTP

‘서버리스’ 방식은 인프라를 구축하는 입장에서 보면 고려해야 할 점이 많은 흥미로운 시스템입니다.

서버리스 방식은 무엇을 고려해야 할까?

1. 콜드 스타트 비용의 딜레마

• 문제: Scale-to-Zero는 비용이 0원이지만, 첫 요청이 왔을 때 컨테이너를 띄우는 데 시간이 걸린다.
• 고려할 점:
  • 미리 예열된 컨테이너를 몇 개 둬야 할까?
  • 어떻게 하면 컨테이너 Startup 시간을 줄일 수 있을까? (Knative Activator)

2. 멀티 테넌시 격리 (Multi-tenancy Isolation)

• 문제: 하나의 물리 서버(EC2) 위에 사용자 A의 코드와 사용자 B의 코드가 같이 돌아갑니다.
• 고려할 점:
  • 보안 격리: 사용자가 rm -rf /를 실행해도, 다른 사용자의 서비스나 호스트가 죽으면 안 됩니다.
  • 성능 격리: 사용자가 CPU를 100% 써서 다른 사용자의 함수가 느려지면 안 된다.

3. 스케줄링

• 문제: 서버 리소스는 한정
• 고려할 점:
  • 4GB 메모리 서버에 100MB짜리 함수를 몇 개나 넣을 수 있을까?
  • 특정 노드가 꽉 찼을 때, 얼마나 빠르게 다른 노드로 함수를 보낼 수 있을까?

4. 네트워크 동적 라우팅

• 문제: 일반적인 서버는 IP가 고정되어 있지만, 서버리스의 컨테이너(Pod)는 수시로 생겼다 사라짐
• 고려할 점:
  • 사용자의 요청이 들어왔을 때, 지금 막 생성된 컨테이너의 IP를 어떻게 알아내서 연결해 줄 것인가?

5. 상태 관리

• 문제: 오토스케일링으로 서버가 줄 때, 지금 작업 중인 컨테이너를 그냥 꺼버리면 데이터가 사라짐
• 고려할 점:
  • Scale-down 신호가 왔을 때, 처리 중인 요청의 Graceful Shutdown Timeout을 얼마나 줄 것인가?
  • 함수가 죽어도 데이터는 어디에 저장해야 하는가? (Stateless 원칙과 외부 스토리지/NFS 연결)

OpenFaaS vs Knative