모두싸인의 AWS 성장기
9 likes5,638 views
연사: 모두싸인 CTO 정승현 행사 제목: 아마존-부산클라우드혁신센터 Startup Member Day 내용 요약: '모두싸인'이라는 전자계약 서비스를 만드는 로아팩토리가 MVP(최소기능제품)부터 12만 명의 회원 서비스가 되기까지의 경험으로 보는 스타트업의 성장 단계 별 AWS 아키텍처 진화와 비용절감 과정
모두싸인의 AWS 성장기
- 1. 모두싸인 AWS 사용기 CTO 정승현 간편 전자 계약 서비스 모두싸인 CTO 정승현 모두싸인 X AWS 성장기
- 6. MVP 버전 개발 시작 필요한 것 프로젝트를 24시간 가동할 서버 데이터를 저장할 MySQL 기반 데이터베이스 서버 계약서, 서명 등을 저장할 파일 서버 외부에서 접근 할 수 없는 폐쇠된 네트워크
- 7. 프로젝트를 24시간 가동할 서버 데이터를 저장할 MySQL 기반 DB 서버 계약서, 서명 파일 서버 서비스에 맞는 가상 네트워크 구성할 수 있는 VPC
- 9. 이메일 서비스 개발된 서비스에서 쉽게 추가 가격을 저렴하게 Transactional한 이메일만 지원해도 된다 DKIM, SPF, DMARC 지원 (계약 서비스다 보니) 개발을 하다보니 이메일을 보내야 되는 기능이 생김 필요한 것
- 10. AWS 환경에 익숙함(개발 편의성) 건당 가격이 다른 서드파티 서비스 보다 저렴 DKIM, SPF, DMARC 지원 요구 사항에 적합하여 AWS SES 선택
- 12. 세션 데이터 세션 데이터를 저장할 인메모리 데이터베이스 서버 세션 정보 가져오는 것을 실제 서비스 데이터베이스에 영향을 주지않고 기존 데이터베이스보다 빠르게 처리 할 수 있는 데이터베이스를 이용하자 필요한 것
- 13. 인메모리 데이터베이스는 Redis로 결정 Redis 지원하는 ElasticCache로 서버 관리를 쉽게 클러스터링 지원
- 15. 서비스 배포 자체 도메인 HTTPS 엔드포인트 Blue-Green 배포 플로우 Single Point Of Failure 완화 로드밸런싱 드디어 MVP 버전 서비스 배포 필요한 것
- 16. 쉬운 인터페이스 다른 AWS 서비스와 연동하기 쉬움 로드밸런싱 HTTPS 엔드포인트 지원 블루그린 배포 플로우 가능 Multi-AZ 지원
- 17. Amazon S3 Amazon EC2 Amazon SES Amazon Route 53 Amazon EC2 Availability Zone a Availability Zone c Load Balancer Amazon RDS Amazon ElastiCache
- 18. 요동치는 트래픽 트래픽이 높아 질 때 충분한 서버 배치 트래픽이 작을 때는 비용을 줄이기 위해 최소한의 서버만 배치 서비스 특성상 업무시간(약 8시 ~ 19시)에 트래픽이 많고 이후 시간 또는 주말에는 트래픽이 작다 이메일 마케팅 또는 프로모션시 트래픽 급증 대비 필요 필요한 것
- 19. EC2 AutoScaling을 사용하여 트래픽에 따라 유동적으로 서버를 배치할 수 있도록 하자
- 20. Amazon S3 Amazon EC2 Amazon SES Amazon Route 53 Amazon EC2 Availability Zone a Availability Zone c Load Balancer Auto Scaling group Auto Scaling group Amazon RDS Amazon ElastiCache
- 21. 프론트엔드와 백엔드 분리 프론트를 배포할 웹서버 필요(정적 파일 배포) HTTPS 지원 필요 웹 프론트 빌드 후 CLI로 간단히 배포 가능 기존에는 개발팀에서 서비스의 모든 개발을 공유하다가 프론트엔드팀과 백엔드팀으로 나뉘게 됨 웹 뿐만 아니라 이후 앱을 위해 필요한 것
- 22. S3를 통한 hosting와 CloudFront의 조합으로 쉽게 배포 가능 HTTPS 지원 Route53를 연동하여 도메인 쉽게 설정 HTTP에서 HTTPS Redirection 지원 AWS-CLI로 간단히 배포 가능 덤으로 전세계 엣지에서 낮은 지연 가능
- 23. Amazon S3 Amazon EC2 Amazon SES Amazon Route 53 Amazon EC2 Availability Zone a Availability Zone c Load Balancer Auto Scaling group Auto Scaling group Amazon Clou dFront Amazon S3 Amazon RDS Amazon ElastiCache
- 24. 이렇게 평온한 날들을 보내던 도중 서버팀 제안
- 26. 그래, 우리 해봅시다 근대 마이크로서비스라고 들어도 봤고, 좋은거 같던데 그게 정확히 뭐죠?
- 27. 현재(모놀리식)의 문제점 프로젝트가 하나에 모여있기 때문에 프로젝트가 커짐에 따라 한번 변경할 때, 변경사항이 기존 코드에 영향을 미쳐서 버그가 생겨날 것 같은 걱정. 기술 스택을 변경하고 싶은데 작은 변경이라도 프로젝트 전체 변경 필요. 장애시 모든 서비스 중단. 한 프로젝트안에 CPU를 많이 사용하는 부분, 메모리를 많이 사용하는 부분 등 무조건 최대치로 필요. 배포 규모가 커지고 부담이 크다. 팀원이 늘어남에 따라 프로젝트에 대한 복잡도가 더욱 커짐.
- 28. 기존 모놀리식한 프로젝트를 각 서비스별로 나누어 기존 문제들을 해결하자 (시간상 마이크로서비스의 장점 생략)
- 30. 나누었을 때, 각각 서비스들의 관리 서비스들을 나누니 나눈만큼 관리해야 된다. 예) 계정 서비스, 계약 서비스, 서명 서비스, 결제 서비스 등 로드밸런싱, 오토스케일링 초기 설정 및 관리 필요. 로그 관리 필요. 로드밸런싱, 오토스케일링 관리 쉽게 할 수 있는 것. 로그를 쉽게 볼 수 있도록 할 수 있는 것. 기타 관리를 편리 할 수 있게 하는 것 필요한 것
- 31. 콘솔로 몇 분만에 원하는 AWS 구성을 쉽게 만들 수 있음. 오토스케일링, 로드밸런싱 쉽게 설정 및 자동 관리 애플리케이션 버저닝 웹서버, 시스템, 애플리케이션 서버 등의 로그를 쉽게 볼 수 있음 AWS CLI로 편하게 배포 가능 결국, 코드만 배포하면 이외의 것들은 편하게 설정 및 관리 가능
- 32. 프론트엔드와 백엔드 사이 Gateway 필요 나누니 한 프로젝트에 공통으로 쓰였던 부분들이 모든 각 서비스에 중복적으로 들어가야하는 문제 발생. 각 서비스들이 핵심로직에만 신경 쓸 수 있도록 각 서비스 앞에서 모든 서비 스에서 필요로 하는 공통로직을 처리할 수 있는 Gateway 필요 여러 백엔드의 공통부분(유저인증, 액세스로그 등)을 처리 필요 0 백엔드 스택이 다양해도 일관된 인터페이스를 유지 필요 (JSON 형식, REST API) 모두싸인 API를 공개하기위해 요금지불 및 API 사용 제재 필요 필요한 것
- 33. AWS API Gateway를 사용하자 Authorizer를 사용하여 API에 대한 유저 인증 가능 프론트엔드와 백엔드 인터페이스를 맞춰 연결 가능 API-KEY로 요금지불 및 API 사용 제제 가능 배포단계 관리 가능 커스텀 도메인 지원 Swagger 지원 DDos 공격 완화
- 34. 서비스간의 통신 계정서비스의 회원가입시 서명 서비스 - 샘플 서명, 계약 서비스 - 샘플 계약문서 결제 서비스 - 회원가입시 제공되는 무료 이용권 3건 서버간 통신은 메시지큐를 이용하자 최대한 서비스간 의존성을 줄이자 필요한 것
- 35. AWS SNS AWS SQS 메세지 큐를 서버 만들어서 관리하면 번거로운 일이 많으니 AWS SNS와 SQS를 사용하자 SNS을 통해 서비스에서 일어난 일을 Publish하면 SNS를 Subscribe하는 각 서비스들의 SQS에서 받 아 필요한 일을 처리함 관리가 쉽고 AWS API, CLI 모두 제공
- 36. 회원가입 SNS topic Publish 서명 서비스 Queue 계약 서비스 Queue 결제 서비스 Queue
- 37. 로그관리 기존 모놀리식 프로젝트에서는 로그가 한 곳 각 서비스들의 나눠진 로그를 정리 필요 모든 로그를 한곳에서 볼 수 있도록 CS 또는 디버깅시 보고 싶은 로그 검색 필요 지표를 시각화하고 모니터링 필요한 것
- 38. Elasticsaerch에 로그를 모두 저장하고 Kibana를 이용해서 시각화해서 보자 AWS ElasticSearch Service를 사용하면 ElasticSearch와 Kibana를 쉽게 생성 적용가능
- 39. 많이 사용하는 ELK(ElasticSearch Logstash Kibana) 스택의 Logstash를 사용하려 했으나, 관리형의 Elastic Beanstalk 환경이다 보니 자유도가 떨어져 Logstash를 설정하기가 어려움을 겪음. 로그를 어디로 모을지는 정해졌는데, 어떻게 보낼까?
- 40. AWS에서 권장하는 CloudWatch Logs를 써보자!
- 41. 간단한 서비스는 람다 이메일 서비스 같이 크기가 작고 간단한 서비스에 Elastic Beanstalk 환경은 비용이 너무 아깝다 Worker로 쓰기 좋은 환경 없을까 AWS Lambda를 통해 비용을 절감하자 실행될 때만 가격 측정 => 비용절감
- 42. Amazon S3 Amazon SES Amazon Route 53 Availability Zone a Availability Zone c Amazon CloudFront Amazon S3 Amazon RDS Amazon API Gat eway AWS Elastic Beanstalk AWS Elastic Beanstalk AWS Elastic Beanstalk AWS Elastic Beanstalk AWS Elastic Beanstalk AWS Elastic Beanstalk AWS Lambda 프론트엔드 Amazon ES Amazon CloudWatch 로그 & 모니터링 파일서버 이메일서비스 Amazon SNS Amazon SQS Amazon SQS 서비스간 메세지
- 43. 마이크로서비스 도입시, 탈도 많고 힘들었지만 크게 만족 서비스 단위가 작아지니 변경에 대한 두려움 감소, 배포 속도 증가 장애시 해당 장애 서비스만 중단(다른 서비스 원할) 서비스에 맞게 기술 스택 자유롭게 사용 서비스에 맞는 컴퓨팅 파워 적용가능 전체적인 개발 만족도 향상
- 44. 다시 평화가 찾아왔고, 반복된 날들을 보내고 있었는데
- 45. ECS 서울 리전 출시!
- 46. ECS 출시 Elastic beanstalk으로 서비스를 나누고 스테이지와 실서버를 둘다 가지고 있다보니 효율적으로 서버 배치를 하여도 가격 부담 같은 이유로 서비스 크기 단위를 더욱 작게 나누기도 부담 Elastic Beanstalk를 사용하면 언어 플랫폼의 버전이 제공하는 것을 사용하기 때문에 버전을 올려서 사용하고 싶어도 할 수 없음 예) Node.js v8 Beanstalk이 완전 관리형이다 보니 기술스택에 대한 완전한 자유가 없음 마침, 새로운 서비스에서는 Docker를 활용하여 개발 중
- 47. 안 갈 이유 없으니깐, 도커로 가자
- 48. 한 인스턴스에 여러 컨테이너를 넣을 수 있으므로 비용 절감 ALB를 사용, 로드밸런서를 하나로 통합가능하여 비용 절감 ECS를 이용하여 쉽고 간단히 Docker 클러스터링 구현 가능 ECR로 Private Image Repository 가능 버저닝 가능 AWS CLI로 CI-CD서버만 잘만들면 크게 어렵지 않게 배포 자동화도 가능 당연히, 도커의 이점을 모두 가져올 수 있음
- 49. 새롭게 개발하는 서비스들 적용 완료 기존 서비스들, Elastic Beanstalk에서 ECS로 변경 중 기존 대비 40% 이상 비용 절감 (컴퓨팅)
- 50. Amazon S3 Amazon SES Amazon Route 53 Availability Zone a Availability Zone c Amazon CloudFront Amazon S3 Amazon RDS Amazon API Gat eway AWS Lambda 프론트엔드 Amazon ES Amazon CloudWatch 로그 & 모니터링 파일서버 이메일서비스 Amazon SNS Amazon SQS Amazon SQS 서비스간 메세지 Amazon ECS Amazon ECS Amazon ECS Amazon ECS Amazon ECS Amazon ECS Application Load Balancer
- 51. AWS의 지원 AWS Summit, 오피스 아워, 컨설팅 지원 등