AWS Serverless 웹서비스 구축 경험 후기(1탄)

아키텍쳐/Cloud

AWS Serverless 웹서비스 구축 경험 후기(1탄)

gnidoc 2022. 5. 21. 21:34

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

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

frontend : UI, React 프로젝트
backend : API서버, Django 프로젝트
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

Zappa + AWS IAM Role 관련 이슈

오늘 글은 GDG 글쓰기 공방(aka 모각글) 행사를 참가하면서 작성된 글입니다 gdg.community.dev/events/details/google-gdg-seoul-presents-gdg-geulsseugi-gongbangaka-mogaggeul/#/purchase GDG 글쓰기 공방(aka..

gnidoc.tistory.com

2. 운영 난이도

아무래도 1에서 언급한 것처럼 서비스 사용자 수도 적고
굳이 인프라 구축에 많은 시간 투자를 하고 싶지 않았고
서비스 개발에 집중하기 위한 부분도 있어서
최대한 클라우드에서 제공해주는 "완전관리형 서비스"를 쓰기 위한 이유도 있었습니다

사실 서버에 문제가 있을때 단순히 재시작만 해도 해결되는 경우가 많긴한데
애초에 재시작을 할 이유가 없게 구축하는것도 하나의 방법이라 생각했습니다

물론 뭔가 클라우드에서 알아서 해준다라고 했지만
이 또한 클라우드, 서버리스에 대한 이해도가 뒷받침되어야 알아서 해주겠죠...?

당연히 기본적인 이해없이 도입했다가는 기술부채로 인한 많은 문제들이...

그리고 추후에 로깅이나 알림 시스템까지 구축을 해야된다고 생각하면 또 골치가 아픈데
서버리스 형태로 서비스를 구축하게 된다면
상대적으로 이런 부분들까지도 어느정도는 자동으로 제공되기 때문에 시간을 절감할 수 있습니다

그리고 서버리스는 고가용성(이중화)도 고민할 필요가 없으니 더 좋았습니다
이중화까지 완.전.관.리.해주거든요

사실 온프렘 환경에서 개발/운영해봤다고 해도

단일 서버에서 서비스 해본 사람들이 대부분이고
이중화 구성 및 무중단 배포까지 구축해본 경험이 있는 사람이 많진 않습니다

~~그리고 애초에 그런 경험했다면 k8s(kubernetes)를 쓰고 있었겠죠~~

물론 당연히 k8s를 쓰는게 장기적으로는 좋습니다
하지만 제가 개발/운영/인프라 모두 담당했어야하는 상황이라 최대한 손을 줄이고 싶었습니다
그리고 k8s를 쓴다고 모든게 해결되진 않거든요
오히려 k8s를 운영하기 위한 일이 더 많을 수도 있습니다

또한 클라우드에서는 auto scaling이 비용 최적화하는데 가장 큰 요인인데
애초에 해당 프로젝트에 참가한 인원들이 이중화, 무중단 배포, 클라우드 경험이 별로 없는 사람들이 대부분이라 참 애매했습니다

이런건 책으로 배울 순 없고 서비스를 운영해보던 경험을 기반으로 터득해나가는 부분인데
아직 서비스 구축도 안했는데 이런걸 배우다가 지치는것보다는
빠르고 쉽게 만드는게 좋다는 개인적인 생각입니다

아 물론 팀원들이 k8s 고수에 모든 오픈소스에 능통하고 서비스 운영경험도 풍부하다면 EKS 로도 충분할겁니다
근데 전 그런 상황이 아니었거든요
풀스택 맛 좀 볼래...?

심지어 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

Serverless microservices - Implementing Microservices on AWS

Thanks for letting us know this page needs work. We're sorry we let you down. If you've got a moment, please tell us how we can make the documentation better.

docs.aws.amazon.com

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

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

이 프로젝트에선 AWS를 썼는데,
클라우드사에서 제공해주는 완전관리형 서비스를 사용하는게 좋은게
일단 AWS에서 제공해주는 새로운 기술을 도입할때 AWS에서 문서를 제공해주니 별도로 문서화할 필요도 상대적으로 적고
대부분 DevOps(code-base)로 모두 운영 가능합니다

게다가 support plan을 가입하면 계륵같긴 하지만 도움을 받을 수도 있습니다
또한 일반적으로 많이 겪는 문제에 대해서도 문서로 제공되기 때문에
잘못된 아키텍처 설계로 인한 문제를 해결할 수 있는 단서를 찾을 수도 있습니다

그리고 AWS를 쓰면서 DevOps를 위해 오픈소스 중 terraform, zappa를 사용했는데
이 부분 또한 다른 글에서 자세히 다룰 예정입니다

4. 보안

주변에 지인들과 얘길해보면 어느 회사나 보안팀은 욕을 먹는거 같은데...
저희 회사도 좀 비슷한 상황이긴 합니다 ㅎㅎ...
데이터 유출 방지나 개인정보보호법을 준수하기 위해서 불편함을 감수하고 망분리 환경에서 클라우드를 써야하는데
이게 개발자들 입장에서는 매우x10 귀찮습니다

망분리는 보통 운영하는 시스템 자체가 개인정보처리시스템이라 ISMS 인증 획득을 위해서 하는 경우가 많은데
실제로 왜 망분리를 꼭 VDI로 해야되는가에 대해서까지 아는 사람은 잘 없었습니다

VPN으로도 법적 요건은 충족할 수 있고
보안솔루션이 적용된 bastion host로 터널링해서 사용하는 방식도 있고
어차피 VDI를 쓴다고 해서 PC에 보안프로그램을 안까는것도 아니거든요

그리고 AWS에서 제공해주는 session manager는 콘솔 내에서 ssh 접속이 되게 제공해주는 기능이고
Azure, GCP는 Cloud Shell을 제공해주고 있습니다
개발자 입장에서는 이거라도 쓸 수 있다면 매우 행복하죠...
근데 이것도 못쓰게 하는 보안정책을 가진 회사들이 있습니다

그리고 주변에 왜 망분리를 할때 VDI를 쓰는거에요라고 물었을때
"그냥 다른 기업도 그렇게 쓰고 있다"고 답변을 들은 경우가 더 많았습니다

특히 코로나 시국이 되면서 금융기관도 한시적으로 VPN을 활용한 재택근무를 허가해줬는데
보안에 예외가 생긴다는건 참 이상하죠 ㅎㅎ;;

그리고 이제까지 금융권은 클라우드 애초에 쓸 수 없는데
이를 쓸 수 있도록 완화해주는 제도가 내년인 23년부터 시행될 예정이라고 합니다
4월 14일에 발표했는데 실제로 쓸 수 있는 정도의 개선안인지는 모르겠습니다만
어쨋든 판도가 바뀌고 있습니다

그리고 위에서 언급한 VPN도 VPN 장비에 대한 공격도 무시할 수 없는 부분인데
그렇다고 사용하는 VDI 에 대한 공격도 무시할 수 있을까요...?
(국내 대기업들은 citrix사의 VDI를 많이 쓰는데 과연 한번도 공격 당한적이 없을까란 생각이 듭니다)

아무튼 망분리에 대해서는 이견이 없지만 그 수단이 꼭 VDI여야하는지는 의문입니다
저도 일개 개발자라 법은 잘몰라서 ㅎ...
~~DevOps를 넘어서 이젠 DevSecOps로...???!!!???~~

보통 보안을 어느정도 챙기는 회사라면
~~레거시하지만...~~ chakra max 같은 보안프로그램을 사용해서만 ssh, rds 접속을 허가해주고
모든 EC2에는 별도의 3rd party 보안프로그램을 설치해서 사용합니다
(즉, session manager나 직접적인 ssh 접속을 막습니다)

근데 개발자들이 chakra max 쓰는거 귀찮으니깐
ssh 포트를 22 -> 8022로 바꾼다거나
code-server, jupyter notebook 같은거 설치해서 써버리는 아이러니한 상황이 되죠....

보안을 위해서 막았는데 보안홀을 스스로 만드는꼴이...

이런걸보면 보안도 중요하지만 편의성도 필요한 것 같습니다
개발자들도 당연히 보안 중요하다고 생각하겠지만 과도한 보안은 오히려 업무 효율성만 떨어트리는 꼴이 될 것 같네요

더 문제는 PC에서 직접 charkra max를 사용해도 귀찮을텐데 망분리를 위해서 VDI를 써야하면
전용선 연결이 되지 않는 클라우드 계정에 올라간 Public한 리소스인 EC2나 RDS를 접속하기 위해선 아래와 같이 접속이 필요했습니다

맥북 -> VDI(윈도우) -> chakra max -> bastion(EC2) -> EC2/RDS

위와 같은 구조에서 개발자는 VDI 내에서 개발을 해야되는데...
VDI는 보통 인터넷이 되지 않기 때문에 개발하기가 쉽지 않습니다

일반적으로 망분리를 위해서 사용하는 VDI 안에서는 인터넷(외부망)이 안되기 때문에
github, jenkins, yarn, npm, pip, maven, gradle, docker registry 등등의 public repository 사용이 제한됩니다
그럼 VDI에서 개발을 해야된다면 위와 같은 시스템을 쓰기 위해선
일반적으로 nexus와 같은 private repository를 별도로 구축하여 사용해야됩니다

하지만 nexus를 구축을 해도 이를 VDI에 연결해줘야하고
만약 jenkin와 같은 CI/CD를 구축한다면 그쪽에도 연결해야하고
요즘은 언어, 프레임워크도 다양해서 go, flutter, helm 등을 써야된다면 그걸 또 작업해야되고...

아마도 nexus 하나만 담당해도 담당자는 죽어날겁니다
~~담당자가 살 수 있는 방법은 이런 확장을 제공 안해주...~~

그래서 private repository는 팀마다 따로 가져가는 경우가 많습니다
아니면 저처럼 클라우드에서 제공해주는 서비스를 사용하거나요

그리고 클라우드에서 제공하는 서비스들은 기본적으로 Public한 형태가 많습니다
proxy로 하나하나 열어주다보면 결국 *.amazon.com으로 열어주는거랑 다름없게 되는 상황이....

특히 맥북이 있는데 부트캠프도 아니고 굳이 또 VDI를 통해서 윈도우를 써야한다...?
게다가 bastion을 통해서 RDS에 붙어야되는데 굳이 또 터널링해서 개발해야되는 문제도 있습니다
~~(이러면 맥북을 왜 주는거야?)~~

아무튼 보안을 지키기 위해서 점점 네트워크/인프라 환경이 복잡해지다보니
어느샌가 보안 규칙이 하나가 바뀌면 그걸 적용하기 위해서 다른 일을 못하는 상황이 발생하게 됐습니다
~~(이 또한 현재 진행형...)~~

근데 제일 짜증나는 문제는
회사 내부적으로 사용하는 보안프로그램들이 auto scaling이 적용된 서버에서 계속 프로세스가 실행이 안되거나 죽고
RDS, Lambda, Elastic Beanstalk, ECS, EKS와 같은 완전관리형 서비스에서는 애초에 적용하기 어려운 상황이 발생하는 등 난감한 상황이 많았습니다
그리고 최근 log4j처럼 보안 사건 사례들을 참고하거나 관련 법안이 바뀌면서 보안정책도 계속 바뀌기 때문에
그때마다 보안팀과 회의를 하고 협의하고 프로세스가 죽으면 재시작하고 등등... 점점 점차 개발에 투자할 시간이 줄어들었습니다
~~우리 회사 인프라팀은 뭐하고 내가 왜 이걸하는거야 읍읍~~

아무튼 그래서 이 프로젝트를 진행할때 서버리스를 택한거기도 합니다
애초에 API Gateway, Lambda, CloudFront를 사용한다면 저런 레거시한 보안프로그램을 사용하지 않고
클라우드에 최적화된 방식(WAF, Firewall Manager, IAM Policy 등)으로 보안정책을 가져갈 수 있기 때문입니다

글로 정리하다보니 드는 생각이 참 보안쪽 하시는분들도 클라우드 도입할때 고민이 많을 것 같네요...

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

하지만 서버리스를 아키텍처로 진행한다고 했을때 고민이 다 해결됐던건 아닙니다
아래와 같은 문제들도 있었습니다

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, 한글과컴퓨터, 어도비(포토샵, 일러스트, 프리미어) 등이 있죠

대학생 시절,
대학생들에겐 무료로 MS Office를 제공해주는데
무슨 서류 낼때는 꼭 한글 파일(hwp)로 내라고 해서 매우 고통 받았던 적이 많았습니다

한글은 프로그램 사주지도 않으면서 내라고 하니 결국 어둠의 경로로 구해서 냈던 기억이 있네요

그리고 오라클DB에 Lock-in되어 있는 솔루션을 mysql로 변경하는 프로젝트도 했었는데
이것도 정말 끔찍한 경험이었습니다...

그래도 아직까진 ERP를 건들일은 없었는데...
이거 말이 씨가 될지도 모르겠네요

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

하지만 frontend는 react, backend는 django, DevOps는 terraform 등을 사용하여 최대한 오픈소스를 활용하여
vendor lock-in을 최대한 피했습니다

물론 위에서 언급했었던 zappa와 같은건 AWS 환경만 지원하는 프레임워크인데
어차피 배포되는 application은 django라서 큰 문제는 없다는 판단이 들었습니다
또한 DB도 aurora mysql이라 특별히 더 걱정할 이유도 없었습니다
~~물론 dynamo db 같은걸 쓴다면 좀...~~

그리고 혹시나 온프렘으로 롤백된다면 k8s를 써야할텐데
k8s 로 바꾼다고 해도 코드 레벨에서 바꿀건 설정값 정도뿐이거든요