AWS로 토이프로젝트 운영삽질기
도커에서 서버리스까지 운영자동화하기
개발자로써 공부를 하다보면 자연스럽게 튜토리얼은 따라하게되고 그러다보면 자연스럽게 토이프로젝트를 만들어보게됩니다. 저 또한 개인적으로 만든 토이프로젝트들을 운영하게되며 겪은 삽질기와 느낀점들에 대해 공유해보려합니다.
내가 만들고 싶은걸 만들고싶다!
회사업무 혹은 프리랜서를 하다보면 외주업무등에 치이다보면 정작 내가하고싶은건 만들기 어렵습니다. 또한 내가 생각하는게 맞다고 생각해도 위에서 믿어주지를 않습니다.
필요조건
- 본업에 충실해야하기때문에 관리가 편할것
- 모니터링을 한눈에 할 수 있어야할 것
- 신경쓰지 않아도 자동으로 돌아갈것
관리가 편하고 모니터링이 편해야한다는 이유때문에 운영은 AWS 클라우드에서 하기로 결정하였습니다.
백엔드 사이드 CI/DI 구성
당시 개발환경을 구축할때만해도 AWS에서는 쿠버네틱스를 지원하지 않았습니다. (진작좀 지원해주지…) Git의 Dev 브랜치를통해 개발을하고 Master 브랜치로 Merge하면 Code Build에서 자동으로 변경내역을 감지하고 Github에서 코드를 땡겨옵니다. 그 후 Mocha.js를 통해 테스트들을 실행하고 문제가 없다면 이후 Code Deploy를 통해 운영버전을 배포합니다.
토이프로젝트로 운영하는경우 CodePipline을 통해 상태가 변경될때마다 슬랙메세지로 확인을해도 괜찮지만 모니터링 해야하는 사람이 많다면 협업과 이슈트래킹을 위해 TeamCity나 Jenkins를 이용하는것이 더 바람직합니다.
모바일(안드로이드) CI/DI 구성
백엔드 부분과 많이 다르지 않습니다. Code Build에서 Git을 통해 소스코드를 가져온 후 도커머신을 통해 APK파일을 빌드합니다. 빌드직전 JUnit을 통해 테스트를 진행합니다. UI테스트를 위해 Esprsso도 적극사용하고 싶었지만 내공의 한계인지 원하는만큼 구현하기는 힘들어습니다. 대신 UI테스트를 위해 Device Farm을 이용하였습니다.
AWS Device Farm
생각보다 널리 알려지지 않은 AWS 서비스입니다. 그냥 AWS로 생각보다 홍보할 생각은 없는것같습니다(…) Firebase의 Device Test와 비슷하게 여러 디바이스에서 무작위클릭 혹은 시나리오를 통해 테스트를 도와주며 IOS기기도 사용가능합니다. 가장 큰 장점은 할당받은 디바이스를 웹브라우저를 통해 접속하여 컨트롤할 수 있습니다.
모놀리스에서 마이크로서비스로
발생하는 문제점들
한가지 슬픈사실은 Application Load Balancer까지 붙였지만 한번도 사용할만큼 유저가 몰리지는 않았습니다(…) 반면 Redis, MongoDB, Express.js까지 도커라이징 해두었기때문에 EC2는 2대이상 작동을 해야했고 유휴자원이 많이 발생하였습니다.
- EC2의 유지비용을 생각보다 무시할 수 없음
- ECS내부에서 발생하는 로그관리가 생각만큼 쉽지가 않음
- 조금의 변경만 발생해도 전체 도커를 다시 빌드해야함
- 서버들이 놀때가 많음…
마이크로서비스로 옮겨가기
우선 Express를 람다를 이용하고 데이터베이스는 RDS를 이용하였습니다. DynamoDB와 MongoDB도 좋지만 저에게있어 가장 큰 문제는 툴이었습니다. RDS영역에는 Datagrip이나 Workbench와 같은 툴이 있지만 MongoDB의 Robomongo는 무료버전의 제약이 상당히 심하고 DynamoDB는 사실상 웹브라우저말고는 마땅한 툴이 없었습니다.
마이크로, 서버리스, 성공적
위 이미지에는 167달러로 되어있지만 S3비용을 80달러가량을 제외하면 컴퓨팅요금으로 . 70~80달러정도의 금액을 매달 지불하고있었습니다. 람다로 바꾼 후부터는 한화로 8~9만원의 비용을 300원까지 성공적으로(?) 낮출 수 있었습니다.
모든걸 캐싱한다!
사용자가 늘어가며 생기는 문제점
큰 서비스는 아니지만 사용자가 조금씩은 늘어가기 시작하며 비용의 부담이 생겼습니다. Lambda의 경우는 비용이 거의 발생하지 않았지만 S3에서 비용이 많이 발생하고있었고 특히 RDS 연결의 숫자가 프리티어의 경우 100여개 미만을 제공하는데 커넥션 숫자도 점점 아슬아슬(?) 해지고있었습니다.
- 의미없는 데이터베이스 트랜잭션 처리가 많음
- S3 요금의 증가
람다에서의 RDS 커넥션문제는 상당히 복잡합니다. 혹시 람다에서 Sequalize.js를 쓰고계신분이라면 최근에 나온 Sequalize.js v5를 쓰시길 권장드립니다. v5버전부터는 General Pool 라이브러리가 아닌 Node Pool 라이브러리로 변경되어 커넥션 풀이 끊어질때 생기는 문제들이 수정되고 람다에서 더 사용하기 쉽게 리팩토링되었습니다.
API Gateway 캐싱
API Gateway는 기본적으로 캐싱처리를 지원합니다. 특정 URL로 동일한 요청이 들어오면 해당 요청을 람다를 통해서 가져올지 아니면 캐싱된 데이터를 처리하여 가져올지를 설정해줄 수 있습니다. 이를통해 최신글 데이터와 같은 정보를 캐싱처리 하였습니다.
데이터베이스 캐싱
또한 데이터베이스도 캐싱처리하도록 변경하였습니다. RDS의 memcache기능을 붙여보진 않았지만 해당 기능도 위와같이 메모리캐시를 쉽게 적용해주는것 같습니다. 대신 프리티어범위내에서 적용가능한 Elastic Cache의 Redis를 사용하였습니다.
S3캐싱
Cloud Front를 붙여 S3 데이터가 캐싱하도록하였습니다. 경험상으로는 Cloud Front를 이용한 비용절감효과보다는 S3에서의 이미지 최적화를 통한 비용절감이 상당히 효과를 보았습니다. 비트윈에서 작성한 서버비용 70% 줄이기를 참고하여 큰 도움이 되었습니다.
마치며
현재 시스템의 모니터링은 모바일의 경우 Crashlystic 백엔드의 경우 Kibana와 Dashbird를 사용하고있습니다. 애널스틱스 로그처리를 위해 처음에는 모든AWS의 AppSync와 Mobile 애널스틱스를 붙였지만… AWS에서 Mobile SDK는 정말 괴랄하게 만들다는걸 깨달은 후 Firebase로 갈아타게 되었습니다. 에러로그는 Crashlystic 그리고 사용자 로그는 Big Query로 Export하여 Elastic Search로 가져오도록 하였고 정신건강이 크게 회복되었습니다.
전체 시스템을 구성하는데 밑바닥부터 작업하여 틈틈이 10개월 여간 구축에만 몰두했던것같습니다. (그로인해 삶은 엄청나게 피폐해졌습니다..) 하지만 뭔가 저만의 서비스가 있다는 사실이 뿌듯하다고 쓰고싶습니다..
잘한점
- 피눈물 흘리며 공부할 수 있었음
- 모바일은 Crashlistic 백엔드는 Kibana와 Dashbird를 통해 슬랙으로 간단히 모니터링이 가능
- S3를 제외하고는 사실상 몇천원 수준의 유지비용
못한점
- 구지 개인 서비스를 이렇게까지 짜야 했나 싶음
- 다시하라고하면 도저희 못할 것 같음
- 차라리 이시간에 다른걸 했으면 돈을 더 벌지 않았을까 싶음
