
올해 개발한 서비스에서 다루는 사용자의 민감정보(PII) 보호를 위해 기존 온프레미스 환경에 DB를 유지하면서(기존 리소스도 사용 고려), 변동성 큰 워크로드는 퍼블릭 클라우드를 활용하는 하이브리드 아키텍처로 전환을 계획하던 과정에서 고민했던 것에 대해 끄적여보겠습니다. . .
우선 Site-to-Site VPN을 통해 두 환경 간의 안전한 통신망을 확보한 상태에서, 변동성이 큰 워크로드를 많이 다뤄봤던 AWS(퍼블릭 클라우드) 환경에 구축하는 것으로 와꾸를 짜봤습니다.
저는 서비스 규모가 작기도 하고 트래픽도 아직 일정한 패턴이 없을 것으로 보이며 저 혼자 운영을 맡아 하기때문에 자동 확장이 가능하고 운영 오버헤드가 적은 서버리스 기반 구성을 검토하였습니다. 이에 따라 아래 두 가지 서버리스 서비스 사이에서 고민하게 되었습니다.
모든 아키텍처 설계는 요구 사항과 제약 조건에서 출발해야 한다고 생각합니다. 제가 마주한 핵심 요건은 다음과 같습니다.
Lambda는 이벤트 기반의 서버리스 함수를 통해 요청을 처리하는 방식입니다. API Gateway와 연동하면 RESTful API를 손쉽게 구축할 수 있으며, 트래픽에 따라 즉각적으로 스케일 인/아웃되는 강력한 장점이 있습니다. 'Scale-to-Zero'가 가능하여 비용 효율성 면에서는 최고라고 생각했습니다.
그러나 온프레미스 DB와의 연동에서 몇 가지 한계가 있을 수 있는 점을 발견했습니다. . .
Lambda 함수는 요청이 올 때마다 새로운 실행 환경이 프로비저닝될 수 있습니다. 이는 온프레미스 DB에 매번 새로운 커넥션을 열어야 함을 의미합니다..
Site-to-Site VPN을 통한 통신은 지연이 필연적으로 발생하는데, 여기에 매번 DB 커넥션을 맺는 오버헤드까지 더해지면 서비스 응답 속도, 그리고 온프레미스 DB에 상당한 부하를 줄 것이라고 생각했습니다.
전에 AWS SAA 자격증 공부 중, Lambda가 RDS Proxy와 연동되어 기존 연결 재활용이 가능하다고 배운게 갑자기 생각이 났는데 이것을 온프레미스 환경의 DB에 적용할 수 없으니 좀 아쉽습니다. . .
온프레미스 DB와 통신하기 위해서는 Lambda 함수를 VPC 내부에 위치시켜야 하는데, VPC 내부의 Lambda는 요청을 받을때 콜드 스타트 시간이 상대적으로 길어질 수 있다고 합니다.
변동성이 예를들어 0에서 N으로 꽤 자주 스케일링되는 시나리오라면, 이 콜드 스타트가 사용자 경험에 부정적인 영향을 미칠 것이라고 판단하였습니다.
참고: https://www.simplybusiness.co.uk/about-us/tech/2019/03/aws-lambda-cold-start-vpc/
또한 기존 애플리케이션을 Lambda 환경으로 이전하려면, 함수형 실행 모델에 맞게 코드를 리팩토링해야 하는 오버헤드가 있기도 합니다. 백엔드 팀원이 Lambda 함수 작성 경험이 없기때문에 이 점도 고려할 수 밖에 없었습니다.
여러 후보를 검토한 끝에, 최종적으로는 ECS Fargate를 선택하게 되었습니다. 컴퓨팅 인스턴스로는 초기 트래픽이 불규칙적이고 예측하기 어렵다고 판단하여 Lambda 처럼 완전한 서버리스인 Fargate로 선택하게 되었습니다. 대신, Lambda처럼 트래픽이 없을 때 자동으로 실행 수가 0까지 줄어들지는 않으므로, 태스크가 떠 있는 동안의 비용은 감수해야 하는 구조입니다.
특히, 컨테이너를 실행하기 위해 별도로 EC2 인스턴스를 관리할 필요가 없어 운영 측면에서 얻는 편의성도 체감될거라고 판단했습니다!
https://cloudonaut.io/serverless-hybrid-cloud-accessing-an-api-gateway-via-vpn-or-direct-connect/