[AWSKRUG] 4월 16일 (화) - 서버리스 #serverless 모임 후기

 

강남 교보문고 빌딩 11층 당근 사무실 한켠에서 한 밋업이었다.

공간이 뭔가 발표를 하고, 듣기엔 조금 특이한 공간이었다.

 

 

세션은 두 개로 구성되어 있었는데, 두 세션 모두 빨리 끝나서 추가 세션을 하나 더 진행했다.

 

Session : 스타트업을 위한 Serverless 기반에서 개발환경 운영 및 부하 테스트 진행 방법
Host 1 : 윤창현 님 (Software Engineer, granter)
Host 2 : 김선형 님 (Backend Engineer, Wonderwall)

 

스타트업을 위한 Serverless 기반에서 개발환경 운영 

스타트업의 개발 라이프 사이클을 효율적으로 구성해보자는 취지에서 시작

 

제품 : 스타트업을 위한 AI 지출 분석 서비스

 

기존의 개발환경의 한계

1. 배포/hotfix가 너무 많음

2. 개발/prod 에서 하루에 수십번의 배포가 이뤄짐

3. 애자일 개발 방법론을 사용하다보니 개발하면서 배포가 잦음

= 잦은 배포를 위해서 각각의 개발자에게 dev/stag을 제공할 필요가 있다. 번갈아가면서 수동 배포를 하는건 너무 힘듬

 

그리고 금융정보를 다루다보니 꼼꼼히 확인할 필요가 있음

= 준 prod , 준준 prod 계속해서 생김

 

유연하고 탄력적인 개발환경이 필요했다.

 

기존 개발 환경

Frontend : Vercel

Backend : AWS EKS

 

Frontend는 비용 때문에 eks -> vercel로 갈아탔음(그러나 vercel도 사실 aws로 동작함)

문제는 verceld이 ci/cd가 계정당 하나만 제공되어 프로젝트가 커짐에 따라서 빌드가 밀리는 현상이 발생

비용도 한명당 20달러 + 노드(concurrent build)당 50달러가 추가됨 = 인원 추가 시 70달러가 추가됨

 

거기다 vercel이 Monitoring을 제공하지 않음 -> github action에서 customizing해야 하는데, github이 마비가 됐을 때 큰 문제가 생겼었음.

 

vercel & github action에서 문제가 생기면 그 쪽에서 수정해 줄 때가지 손 놓고 있어야했다.

 

Backend는 비용 절감을 위해 하나의 클러스터에서 돌리다보니 문제가 생겼었음

서버 자원이 부족해 dev를 사용하기위해 prod를 종료되는 슬픈 경우도 있었음.

(BE는 AWS EKS에서 완전관리를 해주니 큰 문제는 없었나봄)

 

대처 방안

No server is easier to manage than no server

서버가 없고, 오토스케일링, 고가용성이 가능하고, 저렴해야 해!

-> 서버리스 도입

 

AWS Paramter Store : env 관리

AWS CodeDeploy : Fargate Deploy - cdk 사용

 

빌드 최적화 : AWS CodeBuild에서 jar파일 캐시를 적용해서 빌드시간을 15분 ->2분으로 줄임

비용 최적화 : ECR Life Cycle - 테스트 환경에선 레포지토리가 필요가 없으므로 바로바로 삭제하도록 함

사용하지 않을 때는 EventBridge에서 시간을 지정해서 서버를 자동 종료하도록 함.

 

Fargate Spot 인스턴스로 사용하는 경우-> EKS와 같은 Karpenter가 없으므로 서버가 꺼지는 것에 유의해야함

 

생각보다 꽤 재밌게 들었던 세션. 우리 회사가 서버 금액의 압박이 없다는게 생각보다 큰 장점이라는걸 느꼈다.

 

우리는 그냥 EKS를 필요한만큼 사용하고 있기 때문에 못 느꼈던 문제들이다.(유저가 적은 문제도 한 몫할 것 같다)

 

기회가 되면, 배포 과정의 최적화(서버리스를 이용한)도 나름 도전적인 과제일 것 같다.

---

스타트업을 위한 Serverless 기반에서 부하 테스트 진행 방법

한정된 리소스의 스타트업에서 부하 테스트까지 준비하긴 필요성도 적고, 어렵다.

 

제품 : 아티스트가 프라이빗한 메시지를 팔로워들한테 보내는 앱

 

아티스트가 한번 메시지를 보내면 한번에 트래픽이 몰리는 현상이 있음

 

이에 대응하기 위해 하드웨어 스펙을 올리는데 한계가 있었음, 비용도 많이 오름

 

그래서 트래픽이 스파이크가 일어날 때 적절한 대응을 하기 위한 부하테스트 이해도를 높이기 위한 세션

 

부하테스트 진행 절차

테스트 툴 선정

사용자가 많은 툴 사용 : jmeter, ngrinder, locust, k6 -> 강연자 분은 locust 을 사용했고 추천함

힙스터 툴 사용 지양 - 레퍼런스가 없음

 

테스트 시나리오 정의

앱에서 호출하는 api 순서 확인

운영 환경과 동일하게 동작하게끔 해야한다.

시나리오 이해 필수

 

목표 지표 정리

ex) 초당 vu 10만명이 10초동안 들어왔을 때 레이턴시 p95 200ms

원활할 때를 기준으로 지표 확인한다.

 

인프라 파악

모든 인프라 리소스 체크해두기

어떤 인프라에서 병목이 생길지 모르기 때문에 다 알아둬야 함(여기 문제가 있겠어 ㅋㅋ? 했던 곳에서 바로 문제 발생)

 

테스트 준비

실제 운영 상태와 완전히 동일 API 서버, DB 등을 구성한다.

테스트용 유저 데이터 추가

 

테스트 진행 결과 기록

변수 차단 철저하기. 테스트는 시간을 줄이는 것과 비용 절감을 함께 고려해야한다.

테스트 대상 리소스 변경이 빠르게 이뤄질 수 있는 환경 구축

그런데, 부하 발생기 본인이 병목와 네트워크가 명목이 있을 수 있으므로 잘 파악해야한다.

 

개선방향 정리 결과 적용

인프라 변경, api 수정 등의 방법을 점진적인 배포를 통해 모니터링 병행 변경 사항 적용

 

유용한 팁

스파이크성 트래픽 - 단시간에 많은 데이터가 들어올 때

AWS Support plan 활용

일반적인 경우 테스트당 1회당 1개의 변수만 변경

비용을 너무 절약하는 것보다 테스트를 빠르게 진행하는 것이 최종적으로 비용 시간 아끼는길 과감하게 써라

 

부하 테스트 주요 변수들

AWS Fargate 주요 변수 : task count, cpu memory network

 

Fargate는 네트워크 메트릭을 주지 않음. network bandwith lmit을 aws support 문의하면 답변 해줌

 

컨테이너가 빠르게 뜨도록 변경 딜레이를 줄여서 작업하는게 필요함

 

RDS : cpu, memory db connection count, network

 

rds 퍼포먼스 인사이트 모니터링 탭에서 주로 진행 커넥션 풀의 문제가 있는 경우가 많아서 rds 프록시 적용 고려

 

퍼포먼스 인사트의 cpu 대기가 길다면 쿼리의 최적화 지점을 알아봐야함. scale up/out 진행

특정 쿼리로 인해 리소스 많이 사용하거나 저하된다면 expalin 명령을 통해 쿼리 사용계획

 

vacuum analyze 쿼리 실행(대량 리소스가 들어갔다면)

 

AWS Elastic cache(redis - memory cpu, network)

 

스파이크 테스트 중 예상치 못한 network 지연이 발생해 문제원인 을 찾기 힘들었음

redis는 하나의 vCPU만 사용해 스케일 업보다 스케일 아웃을 통한 엔진 cpu를 여러 노드로 분산시키고 네트워크 사용량을 여러 노드로 분산해라

작고 동일한 크기와 타입을 가진 키를 사용해라 - 성능에 유리 : 너무 큰 키는 성능 저하

 

내가 잘못 이해했던 건지 서버리스에 대한 내용이 맞나? 싶은 세션.

 

부하테스트를 안해본건 아니지만, 솔직히 100% 꼼꼼하게 모든걸 고려해가면서 진행하지는 않았다.

 

우려되는데 부분은 대부분 스케일업으로 떼워버렸다.

 

그리고 AWS 자원에 대한 부하테스트에 대한 관심은 전부터 있었기 때문에, 꽤 유익했던 세션이었다. 

 

두 세션이 너무 빠르게 끝나서 추가 세션 진행

---

AWS Serverless 서비스 기반 채팅 만들기

람다로 만들어둔 채팅 서버를 실제로 사용해보며, 아키텍처를 소개하는 세션이었다.

 

사용 서비스 : 람다 다이나모 디비, 다이나모 디비 스트림, api gateway

월 예상 비용 : 10원

람다 사용 : 채팅 불러오기, 채팅 입력, 유저목록 추가, 유저 목록 가져오기, 채팅 전달

s3의 static hosting : 서버 없이 static 컨텐츠를 웹으로 제공(엄청난 가용성! 99.99999999%)

AWS Cloud Front : 람다 엣지를 이용해서 적용해서 동적 컨텐츠를 제공할 수 있게함

API Gateway : webSocket을 지원 - 람다랑 연결 가능 Connection ID를 주고 받아야함

DynamoDB : 람다는 RDBMS랑 잘 안맞음(왜? 커넥션 리밋이 있음. But 람다는 무제한으로 커넥션이 이뤄질 수 잇다)

Lambda : 프로비저닝 없이 코드를 실행할 수 있는 서비스. 멀티쓰레딩으로 돌리지 말고 함수를 나눌 생각을 해라

 

람다도 로컬 테스트, 디버깅이 다 가능함 옛날 람다가 아님ㅋㅋ

 

콜드 스타트 : 웜업을 해두거나 기획으로 해결(30분걸리면 30분 5초나 10초나 똑같음 : 걍 둔다)

 

강연자분의 Serverless의 내공이 느껴지는 세션이었다.

 

예상비용이 저정도라면 나도 부담없이 개발해보고 싶은 구조였다.

(사실 아직 FE를 조금 더 봐야한다..)

 

나도 람다를 이것저것만져보면서 Serverless 프레임워크를 사용했었는데, 강연자분도 사용한다고해서 어떻게 사용했는지 꼭 한번 보고 싶다.

 

강연자 분이 운영하는 유튜브 AWS 강의실에 해당 내용이 있다.

https://www.youtube.com/watch?v=SPtRdnB5wSE

 

좋댓구 필요없다고 계속 말씀하시는게 꽤 재밌었다.

---

세번째로 가는 AWSKRUG 밋업이었지만, 나한테 가장 유익했던 세션이었다.

 

첫번째는 제품에 대한 소개를 하기위한 AWS 시큐리티 세션이었는데, 강연자분에게 주어진 시간이 너무 짧아서 아쉬웠다.

 

두번째는 내가 알아들을 수 없는 내용이 90%였다...

 

회사가 스타트업 규모라 그런지 나랑 같은 눈높이에서 했던 고민들이 느껴지는 세션이었다.

 

그리고... 비용 절감에 대한 고민이 정말 크게 느껴졌는데, 나도 AWS 관리자라면 이 단계까지는 가봐야하지 싶다.