서버리스 아키텍처는 데이터베이스 연결을 어떻게 관리합니까?

서버리스 아키텍처의 주요 장점은 이러한 프로그램에 전용 서버가 필요하지 않다는 것입니다. 그런 다음 요청시 호출되고 함수 종료시 중지됩니다.

이는 서버리스 프로그램이 신속하게 시작되어야 응답 할 수 있음을 의미합니다. 그러면 데이터베이스 연결과 같은 시간이 많이 걸리는 작업을 어떻게 처리합니까? 서버 응용 프로그램에서와 같이 함수 호출을 위해 매번 데이터베이스에 연결하거나 데이터베이스 연결을 별도로 관리합니까?

서버리스 앱은 실행간에 상태를 유지하지 않으므로 데이터베이스 연결 풀을 유지할 수 없습니다. 서버리스 앱은 90 년대 CGI 스크립트와 동일한 제약 조건에 직면합니다. 일반적으로 영구 서버 프로세스는 요청 당 한 번이 아니라 서버가 한 번 초기화하기 때문에 요청 당 프로세스 또는 요청 당 컨테이너 아키텍처보다 성능이 뛰어납니다.

서버리스 프로그램은 웹 사이트 서비스와 같은 지연 시간에 민감한 작업에는 적합하지 않습니다. 추가 응용 프로그램 서버를 수동으로 관리하고로드 밸런싱하지 않고도 주 서버에서 실행하지 않으려는 산발적 인 백그라운드 작업에 더 적합합니다. 지연 시간이 짧은 응답보다 개발자 생산성이 훨씬 중요한 경우에도 적합 할 수 있습니다.

때에 따라 다르지.

람다 러너의 배후 구현은 이것에 영향을 줄 것입니다. AWS에서 컨테이너가 재사용 될 수 있음을 알 수 있습니다.

http://docs.aws.amazon.com/lambda/latest/dg/lambda-introduction.html

따라서 일부 요청에 대한 연결 풀링 / 재사용을 볼 수있었습니다. 또한 데이터베이스 자체와 들어오는 연결 요청을 처리하는 방법을 고려해야합니다.

나에게 이런 종류의 질문은 여전히 ​​매우 새롭고 미성숙 한 '서버리스'와 관련된 문제 중 일부를 강조하므로 세부 사항이 손상되지 않았습니다.

우리는 항상 서버리스가 서버가 없음을 의미하지는 않는다는 것을 기억해야합니다. 당신은 람다 전화하는 속도가 충분히 높은 경우, 당신은 할 수 효과적으로 여러 서버, 또는 실행 '용기'를 가지고있다.

실제로 시작 시간과 람다의 IP 주소와 같은 리소스는 실제 문제가 될 수 있습니다. 어쩌면 그들이 어떻게 운영하는지에 대한 합의가 성숙해지면서 이러한 문제들이 확실한 답을 얻게 될 것입니다.