최근 AWS 아키텍처 스터디를 진행하면서 개발과 분석 파트 중 개발을 골라 기존에 Node.js로 개발했던 백엔드를 AWS Lambda와 API Gateway 기반 아키텍처로 마이그레이션을 시도했다.
스터디를 진행하며 단독으로 구현했고 프로젝트 리드미는 다음와 같다.
Young_Backend_Serverless
⏰2024.05.06 ~ 2024.06.14
Node.js 백엔드 ➡️ Lambda 기반 서버리스 백엔드
서버리스를 경험하고 AWS 서비스를 직접 활용하기 위해 시작한 프로젝트입니다.Details
- Node.js 20.x 런타임과 CommonJs 문법을 활용했습니다.
- 📁models 와 📁utils 를 제외한 모든 파일은 각각 Lambda 함수 하나의 index.js입니다.
- Lambda Authorizer를 활용하여 JWT 유효성을 검증했습니다.
- CloudFront를 연결한 S3로 정적 이미지 파일을 배포했습니다.
- 모듈은 Lambda Layer로 추가하여 활용했습니다.
왜?
왜?라는 질문으로 내가 프로젝트를 진행한 이유를 설명하겠다.
분석이 아닌 개발?
개발과 분석의 장단점은 명확할 것 같다.
개발
😊 직접 경험하면서 이해할 수 있음, 눈에 보이는 결과물
🙁 복잡한 아키텍처 접근이 어렵고 시간이 소요됨
분석
😊 복잡하고 다양한 아키텍처를 찾아서 이해할 수 있음
🙁 각각의 서비스를 깊게 이해하기 어려움
많은 아키텍처를 알고있지 못한만큼 분석으로 가고 싶은 마음도 컸다.
개발이 빨리 끝나면 분석으로 가려고했는데 실패했다..
그런데 분석은 하고싶으면 부족해도 혼자 하나씩 찾아가면서 공부할 수 있을 것 같았다. 반면에 개발은 스터디라는 기회가 아니면 우선순위에서 밀려서 하기 어려울 것 같다고 생각했고 특히 서버리스 백엔드 아키텍처를 내가 구현할 일이 앞으로 있을까 생각해봤을 때 이번에 진행해서 확실히 이해하자! 라는 마음이 들어 개발을 선택하게 되었다.
그리고 개발을 하고 아키텍처별로 API를 호출할 때 효율을 비교하고 싶었다!
마이그레이션?
AWS 아키텍처 개발을 결정했을 때 가장 먼저 생각난 서비스가 있었다.
이미 1월에 서비스 운영이 끝났던 아주 간단한 서비스인데 Azure 학생 구독이 7월쯤 종료되어 과금을 막기위해 서버를 내릴 타이밍을 기다리고 있었다.
- Node.js로 구현 - Lambda 런타임에서 지원
- 운영이 끝나서 서버리스면 트래픽이 거의 없어 프리티어가 아니어도 비용이 거의 부과되지 않을 것으로 예상
- 신규 개발이 아닌 마이그레이션으로 트러블슈팅 정도의 가벼운 구현과 함께 설계와 서버리스 경험에 비중을 높임
- 마침 리팩토링 프로젝트를 진행하고 싶다는 프론트엔드 개발자의 등장
스터디의 한정된 시간에서 개발을 마치고 분석까지 할 수 있을 것이라는 기대로 해당 프로젝트의 마이그레이션을 결정했다.
서버리스?
"서버리스 백엔드 아키텍처를 내가 구현할 일이 앞으로 있을까?"
이게 제일 컸다. 물론 위 프로젝트에 컨테이너 또는 컨테이너 오케스트레이션, CI/CD를 적용할 생각도 있고 이 계획은 현재 진행형이다.
하지만 위와 같은 사항들은 도커와 쿠버네티스 공부를 좀 더 하고 이런 간단한 프로젝트보다는 정말 운영이 필요한 서비스에 언젠간 붙일 것이라는 확신이 있었다. 하지만 서버리스 백엔드..? 당시 가장 큰 관심사였던 AWS Lambda를 이해하기 가장 좋은 방법이면서 앞으로 할 기회가 없을 것 같아 지금 해야겠다!로 결심했다.
[ API Gateway - Lambda - DynamoDB ]
이 아키텍처를 보며 Lambda는 어떻게 실행하지? Lambda가 Stateless라면 DB 연결은 어떻게 하지? 와 같은 생각부터 들었고 OAuth를 공부하고 이전부터 가지고있던 MSA에서 인가는 어떻게 구현하지에 대한 답을 구현하고 싶어 컨테이너와 오케스트레이션이 아닌 서버리스를 구현하게 되었다.
결과
기존에 활용하던 외부 MongoDB를 그대로 가지고 Lambda와 API Gateway를 연결하여 백엔드를 구성하였고 Lambda Authorizer를 이용해 간단하게 카카오 소셜로그인 계정을 통한 인가를 구현하였다. 더하여 가상머신 서버의 /public을 활용했던 정적 이미지 배포도 S3와 CloudFront를 통해 안전하게 제공하였다.
알게된 점
클라우드 서비스를 활용하고자 시작한 프로젝트에서 스터디를 함께 하신 분들의 도움으로 서버에 대한 이해도 올라간 것 같다.
Lambda 이해
Lambda를 이벤트 기반 함수형 서버리스 컴퓨팅 서비스~ 이라고 "무엇인지"만 알고 있었는데 이것과 더불어 "무엇을 할 수 있는지"를 더 이해할 수 있었던 것 같다. 이전에는 함수 하나 돌려서 일을 할 수 있다!로 이해했다면 Lambda도 컴퓨팅 서비스인 만큼 용량을 설정할 수 있고 Lambda 하나가 하나의 엔드포인트를 담당하거나 Lambda 하나에서 모든 엔드포인트로 연결해주는 두가지 모두 가능하고 모듈은 Layer에 넣어서 관리하는 등 Lambda도 서버다! 를 체감할 수 있었다.
Serverless 이해
Serverless를 단순히 개발자가 아닌 CSP가 서버를 관리한다~ 로 이해했던 것과 달리 한 강의를 듣다가 Serverless가 MSA에서 서버라고 부를 수 없을 수 없을 만큼 작은 일을 수행해서 서버가 없는 Serverless라는 이야기를 듣고 혼란스러웠는데 구현하면서 와닿았던 것 같다.
아키텍처 비교
Lambda + API Gateway 구현을 마치고 해당 아키텍처와 Lambda Function URL로 호출했을 때의 시간을 비교했을 때 차이가 있는 것을 알 수 있었다. 정확한 비교를 위해서는 Lambda Function URL을 CloudFront에 연결하고 다시 시도해야할 것 같지만 시간의 차이가 눈에 보여서 목적과 비용에 맞는 아키텍처를 고민하는데 도움이 되었다.
그리고 API Gateway에서는 HTTP/2를 지원하고 Lambda Function URL에서는 HTTP/1.1을 지원하던데 이 이유도 더 생각해보고 싶다.
기존 코드와 구조에 대한 반성
Node.js 백엔드 개발 당시에 빠르게 MVP를 구현한 것에 비해 재사용도 신경쓰고 나쁘지 않게 구성했다고 생각했는데... API별로 코드를 하나의 index.js에 쭉 작성하기 위해 코드를 타고타고 들어가는 과정에서 아 로직이 지저분하구나..를 느꼈다. 그 코드에 익숙했던 당시에는 못 느꼈던 것 같고 앞으로 어떻게 개선할지를 다른 프로젝트를 참고하며 고민해야할 것 같다.
서버 호출 제한
프로젝트를 진행하면서 큰 걱정이 하나 생겼다. 누군가 악의적으로 API를 호출해서 과금이 된다면..? 그래서 그걸 막을 방법을 찾았다.
AWS Best Practices for DDoS Resiliency DDoS에 대응하는 아키텍처 설명을 읽고 API Gateway에서 Usage Plan, Throttling을 설정했지만 '이걸로 돼..?'라는 의구심이 가득이었고 스터디에 질문하자 서버에서 IP 또는 API Key 등으로 호출별로 관리한다는 답변을 들을 수 있었다. 직접 해보지 않아서 완전히 이해하지는 못했지만 서버 관리를 위한 작업을 더 알 수 있었다.
아쉬운 점
이게 맞나요..?
구현을 하면서 질문이 끊임없이 생긴다.
람다 하나가 하나의 엔드포인트를 연결한 지금과 같은 경우에
- models이나 utils와 같은 코드를 재사용하지 못하고 매번 파일을 새로 생성하고 작성해야 한다.
- 각 함수별로 DB 연결을 따로 하므로 API마다 지속적인 호출이 이어지지 않는 경우에 DB 연결 시간과 비용이 크다. 특히 외부 DB를 사용해서인지 체감상 더 크게 느껴진다.
위와 같은 비효율적인 부분이 많이 보이는데 Lambda를 필요한 만큼은 합치는 게 더 효율적인지 아직도 의문이 해결되지 않았다.
트래픽 제한하기
API Gateway에서는 전체적인 호출 제한 이외에 세부적인 사항으로 호출을 제한하는 장치가 없어보인다. 결국 이 부분을 직접 처리를 해주어야한다 것인데.. 어떻게 할지 모르겠다.🥲 네트워크에 관심이 있는 만큼 더 찾아봐야할 것 같다.
트러블슈팅과 구조 이해에 시간을 쏟느라 분석을 못한 것 등 아쉬운 점이 더 많지만 이만 줄이겠다. 부끄러워서 스터디 같이 하신 분들이 안 보셨으면 좋겠지만 덕분에 재밌었고 많이 공유해주셔서 감사하다고 전하고 싶다.😆
