[데이터 엔지니어링] 실시간 코인 데이터를 활용한 모의투자 게임 "코인예측왕" part.3(백엔드)

2024.11.29 - [데이터 엔지니어링] - [데이터엔지니어링] 실시간 코인 데이터를 활용한 모의투자 게임 "코인예측왕" 개발-2 (데이터엔지니어링)

[데이터엔지니어링] 실시간 코인 데이터를 활용한 모의투자 게임 "코인예측왕" 개발-2 (데이터엔

이번 포스팅에서는 게임 개발 백엔드 파트에 대해 포스팅 하겠다.

 

백엔드 개발 부턴 프론트 엔드 팀원과 딥러닝/데이터분석 팀원과 같이 맞춰가면서 작업했다.

내 팀 프로젝트 중에 좋았던 기억이 별로 없었지만, 이번 프로젝트는 팀 프로젝트의 희망편이었을 정도로 좋았다.

팀원을 믿고 서로 맡은 파트를 부족 없이 개발해주면서, 서로 원하는 사항이 있으면 의견을 내서 점점 업데이트하는 과정이 재밌었다.

최종 데이터파이프라인 아키텍처

---

백엔드 파트 개발

기존에는 Spring Framework를 사용해서 백엔드 개발을 주로 했지만,

AWS EC2로 배포를 하고 테스트 기간과 런칭 기간을 합치면 최소 2주는 계속 실행해야 하기 때문에, 비용 문제가 있을 거 같았다.

 

그래서, 비용 문제를 해결하기 위해 AWS Lambda로 서버리스 백엔드를 개발하고자 했다.

 

그렇다면, AWS Lambda가 대체 뭘까?

a. AWS Lambda란?

AWS Lambda는 서버리스 컴퓨팅 서비스이며, 코드가 실행될 때만 컴퓨터 자원을 사용해서 사용한 만큼 요금이 부과되는 방식이다.

주요 특징으로는,

• 서버리스: 서버를 직접 설정하거나 유지 관리할 필요가 없다 (이 특징이 선택한 큰 이유이기도 하다)
• 이벤트 기반: 특정 이벤트 (HTTP Request)에 반응해서 실행한다
• 자동 스케일링: 동시에 실행되는 요청 수에 따라 Lambda 함수가 자동으로 확장 또는 축소한다
• 제한된 실행 시간: 최대 15분까지 실행 가능하다 (게임이였기 때문에, 이 부분이 걱정이 되었다)

그래서, Lambda를 사용한 이유는 다음과 같다.

• 서버 관리 불 필요: 서버리스라서 로직 작성에 집중하고 서버 설정이나, 패키지 관리 등을 AWS가 해주기 때문에 편하다
• 비용 효율성: Lambda는 실행 시간에 기반해서 요금이 청구 되어서, 특정 요청이 없을 때는 비용이 발생하지 않는다
• 빠른 배포 및 개발: 코드만 작성해서 배포하면 Lambda가 즉시 실행되어서, 기존의 Spring과 같은 서버 설정 없이 빠르게 개발 및 배포할 수 있어 편했다
• 보안 통합: AWS Identity and Access Management(IAM)과 통합해서 Role을 통해 보안 권한을 세부적으로 제어할 수 있어서, 개발에 참여한 인원도 최소한의 권한을 줄 수 있었다
• 서비스 중단 방지: 게임 특성상 24시간 돌아가고, 서버가 터지거나 중단되는 현상이 발생하면 안되기 때문에, 서비스 중단 방지도 상당히 중요한 선택 사항이었다

그렇다면, Lambda를 사용했을 때, 단점이 뭐가 있을까?

• 15분 실행 제한: Lambda 함수는 최대 15분 까지만 실행되므로, 장시간 실행이 필요한 경우 부적합할 수도 있다
• Cold Start 문제: 초기 실행 시 지연이 발생할 수 있다, 하지만 지금 게임 특성상 1초 단위로 데이터를 가져오는 것이 중요한 요소였기 때문에, 이 부분이 걸림돌이었다
• 로깅 비용: CloudWatch Logs에 로그를 기록해서, 과도한 로그는 비용을 발생할 수 있다. 하지만, EC2 보단 저렴할 것이다

b. AWS Lambda + API Gateway로 API 개발

DynamoDB에 적재된 데이터를 프론트엔드에서 가져오기 위해, Lambda와 API Gateway를 활용해서

트리거를 만들어서 API로 데이터를 가져올 수 있게 하였다.

API Gateway 경로 생성

먼저, API Gateway로 필요한 API를 생성해준다.

AWS Lambda 함수 작성

필요한 AWS Lambda 함수를 작성하고 트리거로 API Gateway를 연결해주면 된다.

API Gateway에 Lamdba 함수 연결

API Gateway에 Lambda를 연결해주면 끝다.

CORS 설정 필수

웹 브라우저의 보안 정책인 SOP(Same-Origin Policy) 때문에, 한 도메인에서 로드된 웹 애플리케이션이 

다른 도메인의 리소스에 접근하지 못 하도록 제한한다.

따라서, CORS(Cross-Origin Resource Sharing) 설정을 통해 이 제한을 완화해서,

특정 조건에서 다른 도메인의 리소스에 접근할 수 있도록 허용해줘야한다.

Postman으로 API 테스트

이렇게 API Gateway + Lambda로 서버리스 API를 개발했다.

 

하지만... 편하고 좋기만할 거 같은 Lamdba 에서 문제가 발생했는데...

pymysql 사용을 하려고 하니까 No module Name 이라는 에러가 발생했다.

Lambda CloudWatch 로그 확인

Lambda 에러는 CloudWatch로 확인할 수 있는데, No module named 'pymysql' 이라는 에러가 발생했고,

생각해보니까, Lambda 환경에서 어떻게 외부 패키지나 라이브러리를 설치해서 사용하는 지 고려를 안 해봤었다.

 

그래서, 알아본 결과 계층 (Layer)를 추가해서 라이브러리를 추가해서 사용하면 된다고 한다.

pymysql를 위한 계층 추가

하지만,, 계층을 추가한 이후에도 에러가 발생했다.

이때 이 에러를 해결하고 싶어도 해결이 잘 안되어서.. Lambda를 포기해야하나 생각도 했었다. 그러나... 이때 AWS SAM을 찾았다.

c. AWS SAM 사용

AWS SAM (Serverless Application Model)은 서버리스 애플리케이션을 개발, 테스트, 배포 할 수 있는 오픈소스 프레임워크이다.

AWS CloudFormation을 기반으로 작동하며, Lambdam API Gateway, DynamoDB 등 서버리스 서비스를 빠르게 배포할 수 있다.

 

AWS SAM은 AWS CLI의 확장으로 작동하고, template.yaml 구성 파일을 사용하여 리소스를 명시해서 사용한다.

AWS SAM을 설치해서 sam init으로 SAM 초기화하고, 템플릿을 적절하게 환경에 맞게 설정하면 된다.

 

SAM은 스택을 배포를 하기 때문에, 하나의 스택에 template.yml, requirements.txt 등 애플리케이션 단위로 필요한 것들을 집합으로 배포하게 된다.

(좌) template.yml 작성 / (우) 라이브러리 사용을 위한 requirements.txt 작성

DynamoDB에서 유저 데이터를 가져오는 Lambda 함수 코드

이렇게 template.yml, requirements.txt, Lambda 함수를 작성해서 스택을 sam deploy로 배포하게 되면,

 

AWS Lambda에 필요한 라이브러리와 함께, 잘 배포가 되고 실행이 되는 기적을 봤다.... 그리고 기존에 Lambda 함수는

함수 하나씩 작성하고 테스트 하고, 배포하고 했지만, SAM을 사용해서 스택 즉, 애플리케이션 단위로 배포해서 매우 편해졌다.

 

그렇게 백엔드 개발은 AWS SAM으로 매우 편하게 비용 효율적으로 배포 했다.

이제, 프론트엔드 팀원과 딥러닝/데이터분석 팀원과 맞춰서 API 명세서를 작성하면서 API를 맞췄다.

d. API 명세서 작성 및 테스트

API 명세서 작성

이제, 가장 중요한 게임에 필요한 1초마다 코인 데이터를 가져올 수 있게 Lambda가 지원을 해줄 지 테스트를 해봐야했다.

첫 API 요청은 3.23s 정도의 시간 소요

DynamoDB에 있는 데이터를 가져오는 첫 API 요청은 3.23초 정도 걸렸다...

우리 팀의 코인 모의투자 게임 특성상 1초마다 코인 데이터를 계속 가져와야 하는데, 데이터를 요청하는 데 3초가 넘게 걸리면 문제다.

 

하지만, 2번째 요청부터 1초 이내의 응답 시간을 확인하였다.

1165ms 응답 시간 소요

865ms 시간 소요

783ms 시간 소요

이게 앞서 걱정했던, Lamda의 Cold Start 문제였는데, 첫 번째 실행만 시간이 걸렸고, 그 뒤로는 그래도 1초 내의 응답 시간을 보였다.

 

그래서, 이 게임에선 Lambda를 사용해도 문제가 없다고 판단하여, 최종적으로 Lambda를 사용해서 배포했다.

백엔드 파트 개발 마무리

이번 포스팅에선 어떻게 백엔드 파트를 개발했는지에 대해 간단하게 다뤄봤지만,

사실, AWS Lambda, API Gateway, SAM을 처음 사용해봐서 에러도 엄청 경험했고, 시간 박치기를 하면서 대부분 해결했다..

 

나는 백엔드 개발을 잘 하지 못한다고 생각한다, 그래도 게임이 에러 없이 돌아가고 서비스 요구사항을 만족하게끔 개발을 해서 데이터 엔지니어링 개발 만큼 재밌었고, 뿌듯했다.

 

다음 포스팅에선 그래서 어떤 게임을 만들었는지, 게임에 대해 드디어 소개해보도록 하겠다.