DEVOCEAN

원문글 : https://gnidoc.tistory.com/entry/AWS-Serverless-%EC%9B%B9%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B5%AC%EC%B6%95-%EA%B2%BD%ED%97%98-%ED%9B%84%EA%B8%B01%ED%83%84

(나름 차별성을 두기 위해 원문글에는 데보션에 기재하지 않는 글이나 짤(?)도 있습니다. 한번 들어와서 구경해보세요... ㅎ)

지난 1년 동안 아래와 같은 구조의 서버리스(serverless) 아키텍처의 웹서비스를 구축, 개발, 운영했습니다.

일단 본 프로젝트는 아래와 같이 크게 3가지로 구성됩니다

1. frontend : UI, React 프로젝트

2. backend : API서버, Django 프로젝트

3. CI/CD : Code Series, CloudFormation

일반적으로 웹서비스를 만들때 많이 구성하는 방식이죠

사용자들은 frontend로 UI를 보고

UI에서 어떤 데이터를 봐야된다면 backend API에 요청해서 DB에 있는 값을 사용합니다

물론 저는 앱 없이 웹서비스만 제공하기 때문에 cloudfront로 충분했었습니다

그리고 위 그림은 큰 그림이고 세부적인 내용은 따로 다른 글에서 다루도록 하겠습니다

아무튼 본 글에서는 서버리스를 도입한 배경과 고민 포인트에 대해서 간략하게만 서술할 예정입니다

위의 3가지 구성요소까지 다루기엔 너무 길어서 해당 내용은 다른 글에서 다룰 예정입니다

어째서 서버리스...? - 서버리스를 택한 배경

서버리스 아키텍처를 택한 주요 이유는 아래와 같습니다

1. 적은 사용자 수(비용)

사실 이게 주요 이유였는데,

하루에 많아야 100명, 그것도 대부분 근무시간(9-to-6)에만 사용하고 주말에는 사용하지 않는 "사내서비스"를 구축해야되는 프로젝트였습니다

이걸 EC2와 같은 컴퓨팅 자원을 사용해서 구축할 경우엔,

일주일인 168시간을 계속 유지해야되서 아무리 auto scaling을 써도 불필요한 비용이 발생합니다

하지만 서버리스는 실제로 서비스가 동작(호출)할때만 비용이 발생하기 때문에

일주일에 45시간만 서비스를 유지하면 되니 시간적으로만 봐도 대략 70%정도의 비용을 절감을 할 수 있습니다

물론, 동접자가 많아지고 서비스 형태가 복잡해지고 무거워진다면 고민해봐야겠지만

B2B, B2C 서비스도 아닌 사내 서비스에선 충분하다고 판단했습니다

예전에 서버리스 비용관련 내용을 살짝 다룬 적이 있었는데 아래 링크를 통해서 간단하게 보시면 좋을 것 같습니다

https://gnidoc.tistory.com/entry/Zappa-AWS-IAM-Role-%EA%B4%80%EB%A0%A8-%EC%9D%B4%EC%8A%88#Elastic_Beanstalk_/Zappa%EA%B0%80%EA%B2%A9%EB%B9%84%EA%B5%90

2. 운영 난이도

아무래도 1에서 언급한 것처럼 서비스 사용자 수도 적고

굳이 인프라 구축에 많은 시간 투자를 하고 싶지 않았고

서비스 개발에 집중하기 위한 부분도 있어서

최대한 클라우드에서 제공해주는 "완전관리형 서비스"를 쓰기 위한 이유도 있었습니다

그리고 추후에 로깅이나 알림 시스템까지 구축을 해야된다고 생각하면 또 골치가 아픈데

서버리스 형태로 서비스를 구축하게 된다면

상대적으로 이런 부분들까지도 어느정도는 자동으로 제공되기 때문에 시간을 절감할 수 있습니다

그리고 서버리스는 고가용성(이중화)도 고민할 필요가 없으니 더 좋았습니다

이중화까지 완.전.관.리.해주거든요

심지어 MSA까지 가능한 서버리스...

그래서 re-invent때 나온 말이 있죠

“No server is easier to manage than no server”

이는 AWS 공식 문서에도 나와있는 문구입니다

https://docs.aws.amazon.com/ko_kr/whitepapers/latest/microservices-on-aws/serverless-microservices.html

본 프로젝트도 위 링크를 참고해서 만들어졌습니다

3. 클라우드(AWS) 최적화

이 프로젝트에선 AWS를 썼는데,

클라우드사에서 제공해주는 완전관리형 서비스를 사용하는게 좋은게

일단 AWS에서 제공해주는 새로운 기술을 도입할때 AWS에서 문서를 제공해주니 별도로 문서화할 필요도 상대적으로 적고

대부분 DevOps(code-base)로 모두 운영 가능합니다

게다가 support plan을 가입하면 계륵같긴 하지만 도움을 받을 수도 있습니다

또한 일반적으로 많이 겪는 문제에 대해서도 문서로 제공되기 때문에

잘못된 아키텍처 설계로 인한 문제를 해결할 수 있는 단서를 찾을 수도 있습니다

그리고 AWS를 쓰면서 DevOps를 위해 오픈소스 중 terraform, zappa를 사용했는데

이 부분 또한 다른 글에서 자세히 다룰 예정입니다

서버리스를 도입하면서 고민했던 부분

하지만 서버리스를 아키텍처로 진행한다고 했을때 고민이 다 해결됐던건 아닙니다

아래와 같은 문제들도 있었습니다

1. EC2 안쓸 줄 알았지...?

"따로 또 같이" 일을 하다보면 누군가는 EC2를 쓰고 싶은 경우가 있습니다

예를 들어서 daily로 batch를 돌려야하는데

Lambda의 경우엔 최대 실행시간이 15분까지라

그 이상의 시간이 걸리거나 언제 끝날지 모르는 script를 돌려야된다면 그냥 EC2를 쓰는게 간단한 해결일 수도 있습니다

저희도 추천 모델을 만들거나 통계를 내기 위해서 일부 batch 작업은 EC2를 쓰고 있습니다

물론 AWS Batch 서비스를 쓰면 되긴하지만...

아무래도 ssh로 그냥 붙어서 코드짜서 shell 바로 돌리는게 빠르고 간편하죠

그리고 일회성 작업이라고 해도

로컬이나 VDI 내에서 실행했을때 얼마나 걸릴지도 모르고

분석할때 jupyter notebook 쓰려고 sage maker 를 쓰기엔 솔직히 너무 비싸긴 합니다

그렇다고 매번 맥북에 데이터 다운받아서 jupyter notebook 실행시켜서 하기엔 맥북 갈리는 소리가 들리죠

그냥 EC2에 설치해서 쓰는게 단기적인 관점에서는 오히려 저렴하죠

게다가 요즘엔 코로나로 인해서 재택 근무를 하니깐

출근하면 맥북(회사 소유) 쓰고 재택하면 윈도우(본인 소유)를 쓰시는 경우가 있는데

이러면 shell script나 일부 python 코드는 윈도우에서 안돌아가는 경우가 있습니다...

뭐 WSL 설치하거나 그러면 해결되긴 하는데

알아서 해결하시면 좋겠지만... 모든 사람들이 모든 문제를 스마트하게 해결하기란 쉽지 않죠

이러니 결국 공통된 환경을 위해서 EC2 하나 띄워서 쓰게 되는 부분도 있습니다

그래서 VDI쓰게 되면~ 맥북의 가장 큰 장점인 unix-like 포기하게 되는 것도 있습니다

2. vendor lock-in

vendor lock-in : 특정 vendor의 독자적 기술에 크게 의존한 제품, 서비스, 시스템 등을 채용했을 때 다른 vendor가 제공하는 동종 제품, 서비스, 시스템 등으로 갈아타기 어렵게 되는 현상

사실 제일 후폭풍이 쎈 영역이죠

AWS에 맞게 최적화해서 개발/구축해놨더니

갑자기 AWS가 비용을 2배로 올린다거나 모종의 이유(ex - 어른들의 사정)로

Azure, GCP 같은 다른 클라우드로 이전하라거나

최악의 시나리오인 온프렘으로 롤백하라는 경우엔

엄청난 규모의 서비스 migration 프로젝트가 되어버립니다

클라우드 외엔 대표적인 vendor lock-in으로 유명한 SW는 오라클DB, 한글과컴퓨터, 어도비(포토샵, 일러스트, 프리미어) 등이 있죠

아무튼 서버리스로 구축하게 된다면 AWS에서만 동일한 환경을 구축할 수 있게 되니 vendor lock-in이 좀 걱정되었습니다

하지만 frontend는 react, backend는 django, DevOps는 terraform 등을 사용하여 최대한 오픈소스를 활용하여

vendor lock-in을 최대한 피했습니다

물론 위에서 언급했었던 zappa와 같은건 AWS 환경만 지원하는 프레임워크인데

어차피 배포되는 application은 django라서 큰 문제는 없다는 판단이 들었습니다

또한 DB도 aurora mysql이라 특별히 더 걱정할 이유도 없었습니다

물론 dynamo db 같은걸 쓴다면 좀...

그리고 혹시나 온프렘으로 롤백된다면 k8s를 써야할텐데

k8s 로 바꾼다고 해도 코드 레벨에서 바꿀건 설정값 정도뿐이거든요

3. 아 k8s 쓰고 싶다...

위에서는 서버리스에 대해서 좋은 얘기만 써놨는데

이게 결국 서비스가 발전하다보면 k8s를 쓰고 싶을때가 옵니다

왜냐면 서버리스로 제공되는 서비스는 AWS가 알아서 관리해주기 때문에

만약에 평소엔 100명만 들어오다가 갑자기 어느날 만명이 접속한다...?

서버리스는 알아서 scaling될때까지 기도해야됩니다

좀 더 세부적으로 인프라를 다루고 싶을땐 오히려 자동관리가 독이 됩니다

그리고 Lambda 를 쓰게 되면서 주로 발생하는 code start 문제도 있구요

그리고 CloudFront로 정적 웹서비스를 하다보면 이래저래 귀찮은 점이 많습니다...

또한 AWS에서 비슷한 기능의 서비스를 제공 하지만기능이 약간 애매해서 오픈소스를 도입하고 싶을때도 있는데 이럴때가 참 난감하죠 ㅎㅎ...

• 1번 내용 포함(큰 용량의 데이터 세트를 분석 + MLOps)

• Gitlab, Jenkins, nexus 같은걸 쓰고 싶은데 유사하지만 약간 불편한 code series

• mongodb를 쓰고 싶지만 아쉬운대로 documentdb

• slack bot을 ec2에 깔아서 쓰긴 애매하니 아쉬운대로 chatbot

• wordpress 같은 블로그를 운영하려면 어쩔수없이 jekyll, hexo 같은 정적 사이트 생성기를 쓰거나 EC2 필요

등등 서버리스로만 가자니 위와 같이 가끔 IaaS가 필요하다고 생각이 들때가 있습니다

4. AWS 장애

상황따라서 다르긴 하겠지만 답이 없긴 합니다

종교는 없지만 기도라도 해야죠

결론

아무튼 서버리스를 쓴다는건 기본적인 클라우드 지식뿐만 아니라 서비스 운영 경험도 필수적입니다

완전관리형 서비스는 손이 덜간다는거지 완전 자동은 아닙니다

지속적인 모니터링과 적절한 아키텍처 설계는 필수적이고

비용의 효율성이나 성능 검증도 다 계산해봐야 됩니다

왜냐면 오히려 서버리스로 갔을때 더 비싼 경우도 많거든요

그래서 개인적인 의견으로는

큰 규모의 서비스로 발전한다면 서버리스로는 언젠가 한계가 올 것입니다

항상 k8s로 도망갈 준비를...

아무튼 서버리스 경험에 대한 전반적인 내용은 여기서 마치며

다음 글에서는 frontend쪽에 대해서 구체적으로 설명할 예정입니다