모두싸인의 AWS 성장기

모두싸인 AWS 사용기
CTO 정승현
간편 전자 계약 서비스
모두싸인
CTO 정승현
모두싸인 X AWS 성장기

MVP 버전 개발 시작
필요한 것
프로젝트를 24시간 가동할 서버
데이터를 저장할 MySQL 기반 데이터베이스 서버
계약서, 서명 등을 저장할 파일 서버
외부에서 접근 할 수 없는 폐쇠된 네트워크

프로젝트를 24시간 가동할 서버 데이터를 저장할 MySQL 기반 DB 서버
계약서, 서명 파일 서버 서비스에 맞는 가상 네트워크 구성할 수 있는 VPC

Amazon
S3
Amazon EC2 Amazon
RDS

이메일 서비스
개발된 서비스에서 쉽게 추가
가격을 저렴하게
Transactional한 이메일만 지원해도 된다
DKIM, SPF, DMARC 지원 (계약 서비스다 보니)
개발을 하다보니 이메일을 보내야 되는 기능이 생김
필요한 것

AWS 환경에 익숙함(개발 편의성)
건당 가격이 다른 서드파티 서비스 보다 저렴
DKIM, SPF, DMARC 지원
요구 사항에 적합하여 AWS SES 선택

Amazon
S3
Amazon EC2 Amazon
RDS
Amazon
SES

세션 데이터
세션 데이터를 저장할 인메모리 데이터베이스 서버
세션 정보 가져오는 것을 실제 서비스 데이터베이스에
영향을 주지않고 기존 데이터베이스보다 빠르게 처리
할 수 있는 데이터베이스를 이용하자
필요한 것

인메모리 데이터베이스는 Redis로 결정
Redis 지원하는 ElasticCache로 서버 관리를 쉽게
클러스터링 지원

Amazon
S3
Amazon EC2
Amazon
RDS
Amazon
SES
Amazon
ElastiCache

서비스 배포
자체 도메인
HTTPS 엔드포인트
Blue-Green 배포 플로우
Single Point Of Failure 완화
로드밸런싱
드디어 MVP 버전 서비스 배포
필요한 것

쉬운 인터페이스
다른 AWS 서비스와 연동하기 쉬움
로드밸런싱
HTTPS 엔드포인트 지원
블루그린 배포 플로우 가능
Multi-AZ 지원

Amazon
S3
Amazon EC2
Amazon
SES
Amazon
Route 53
Amazon EC2
Availability Zone a
Availability Zone c
Load Balancer
Amazon
RDS
Amazon
ElastiCache

요동치는 트래픽
트래픽이 높아 질 때 충분한 서버 배치
트래픽이 작을 때는 비용을 줄이기 위해 최소한의 서버만 배치
서비스 특성상 업무시간(약 8시 ~ 19시)에 트래픽이 많고
이후 시간 또는 주말에는 트래픽이 작다
이메일 마케팅 또는 프로모션시 트래픽 급증 대비 필요
필요한 것

EC2 AutoScaling을 사용하여 트래픽에 따라
유동적으로 서버를 배치할 수 있도록 하자

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

프론트엔드와 백엔드 분리
프론트를 배포할 웹서버 필요(정적 파일 배포)
HTTPS 지원 필요
웹 프론트 빌드 후 CLI로 간단히 배포 가능
기존에는 개발팀에서 서비스의 모든 개발을 공유하다가
프론트엔드팀과 백엔드팀으로 나뉘게 됨
웹 뿐만 아니라 이후 앱을 위해
필요한 것

S3를 통한 hosting와 CloudFront의 조합으로 쉽게 배포 가능
HTTPS 지원
Route53를 연동하여 도메인 쉽게 설정
HTTP에서 HTTPS Redirection 지원
AWS-CLI로 간단히 배포 가능
덤으로 전세계 엣지에서 낮은 지연 가능

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

이렇게 평온한 날들을 보내던 도중
서버팀 제안

우리 아키텍쳐를
마이크로서비스로 하자

그래, 우리 해봅시다
근대 마이크로서비스라고 들어도 봤고,
좋은거 같던데 그게 정확히 뭐죠?

현재(모놀리식)의 문제점
프로젝트가 하나에 모여있기 때문에
프로젝트가 커짐에 따라 한번 변경할 때,
변경사항이 기존 코드에 영향을 미쳐서 버그가 생겨날 것 같은 걱정.
기술 스택을 변경하고 싶은데 작은 변경이라도 프로젝트 전체 변경 필요.
장애시 모든 서비스 중단.
한 프로젝트안에 CPU를 많이 사용하는 부분,
메모리를 많이 사용하는 부분 등 무조건 최대치로 필요.
배포 규모가 커지고 부담이 크다.
팀원이 늘어남에 따라 프로젝트에 대한 복잡도가 더욱 커짐.

기존 모놀리식한 프로젝트를
각 서비스별로 나누어
기존 문제들을 해결하자
(시간상 마이크로서비스의 장점 생략)

좋은건 알겠는데,
어떻게 구현할까?

나누었을 때, 각각 서비스들의 관리
서비스들을 나누니 나눈만큼 관리해야 된다.
예) 계정 서비스, 계약 서비스, 서명 서비스, 결제 서비스 등
로드밸런싱, 오토스케일링 초기 설정 및 관리 필요.
로그 관리 필요.
로드밸런싱, 오토스케일링 관리 쉽게 할 수 있는 것.
로그를 쉽게 볼 수 있도록 할 수 있는 것.
기타 관리를 편리 할 수 있게 하는 것
필요한 것

콘솔로 몇 분만에 원하는 AWS 구성을 쉽게 만들 수 있음.
오토스케일링, 로드밸런싱 쉽게 설정 및 자동 관리
애플리케이션 버저닝
웹서버, 시스템, 애플리케이션 서버 등의 로그를 쉽게 볼 수 있음
AWS CLI로 편하게 배포 가능
결국, 코드만 배포하면 이외의 것들은 편하게 설정 및 관리 가능

프론트엔드와 백엔드 사이 Gateway 필요
나누니 한 프로젝트에 공통으로 쓰였던 부분들이
모든 각 서비스에 중복적으로 들어가야하는 문제 발생.
각 서비스들이 핵심로직에만 신경 쓸 수 있도록 각 서비스 앞에서 모든 서비
스에서 필요로 하는 공통로직을 처리할 수 있는 Gateway 필요
여러 백엔드의 공통부분(유저인증, 액세스로그 등)을 처리 필요
0
백엔드 스택이 다양해도 일관된 인터페이스를 유지 필요 (JSON 형식, REST API)
모두싸인 API를 공개하기위해 요금지불 및 API 사용 제재 필요
필요한 것

AWS API Gateway를 사용하자
Authorizer를 사용하여 API에 대한 유저 인증 가능
프론트엔드와 백엔드 인터페이스를 맞춰 연결 가능
API-KEY로 요금지불 및 API 사용 제제 가능
배포단계 관리 가능
커스텀 도메인 지원
Swagger 지원
DDos 공격 완화

서비스간의 통신
계정서비스의 회원가입시
서명 서비스 - 샘플 서명,
계약 서비스 - 샘플 계약문서
결제 서비스 - 회원가입시 제공되는 무료 이용권 3건
서버간 통신은 메시지큐를 이용하자
최대한 서비스간 의존성을 줄이자
필요한 것

AWS SNS
AWS SQS
메세지 큐를 서버 만들어서 관리하면 번거로운
일이 많으니 AWS SNS와 SQS를 사용하자
SNS을 통해 서비스에서 일어난 일을 Publish하면
SNS를 Subscribe하는 각 서비스들의 SQS에서 받
아 필요한 일을 처리함
관리가 쉽고 AWS API, CLI 모두 제공

회원가입
SNS topic Publish
서명 서비스 Queue
계약 서비스 Queue
결제 서비스 Queue

로그관리
기존 모놀리식 프로젝트에서는 로그가 한 곳
각 서비스들의 나눠진 로그를 정리 필요
모든 로그를 한곳에서 볼 수 있도록
CS 또는 디버깅시 보고 싶은 로그 검색 필요
지표를 시각화하고 모니터링
필요한 것

Elasticsaerch에 로그를 모두 저장하고
Kibana를 이용해서 시각화해서 보자
AWS ElasticSearch Service를 사용하면
ElasticSearch와 Kibana를 쉽게 생성 적용가능

많이 사용하는 ELK(ElasticSearch Logstash Kibana) 스택의
Logstash를 사용하려 했으나,
관리형의 Elastic Beanstalk 환경이다 보니
자유도가 떨어져 Logstash를 설정하기가 어려움을 겪음.
로그를 어디로 모을지는 정해졌는데,
어떻게 보낼까?

AWS에서 권장하는
CloudWatch Logs를 써보자!

간단한 서비스는 람다
이메일 서비스 같이 크기가 작고 간단한 서비스에
Elastic Beanstalk 환경은 비용이 너무 아깝다
Worker로 쓰기 좋은 환경 없을까
AWS Lambda를 통해 비용을 절감하자
실행될 때만 가격 측정 => 비용절감

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
서비스간 메세지

마이크로서비스 도입시,
탈도 많고 힘들었지만 크게 만족
서비스 단위가 작아지니 변경에 대한 두려움 감소, 배포 속도 증가
장애시 해당 장애 서비스만 중단(다른 서비스 원할)
서비스에 맞게 기술 스택 자유롭게 사용
서비스에 맞는 컴퓨팅 파워 적용가능
전체적인 개발 만족도 향상

다시 평화가 찾아왔고,
반복된 날들을 보내고 있었는데

ECS 출시
Elastic beanstalk으로 서비스를 나누고
스테이지와 실서버를 둘다 가지고 있다보니
효율적으로 서버 배치를 하여도 가격 부담
같은 이유로 서비스 크기 단위를 더욱 작게 나누기도 부담
Elastic Beanstalk를 사용하면 언어 플랫폼의 버전이 제공하는 것을
사용하기 때문에 버전을 올려서 사용하고 싶어도 할 수 없음
예) Node.js v8
Beanstalk이 완전 관리형이다 보니 기술스택에 대한 완전한 자유가 없음
마침, 새로운 서비스에서는 Docker를 활용하여 개발 중

안 갈 이유 없으니깐,
도커로 가자

한 인스턴스에 여러 컨테이너를 넣을 수 있으므로 비용 절감
ALB를 사용, 로드밸런서를 하나로 통합가능하여 비용 절감
ECS를 이용하여 쉽고 간단히 Docker 클러스터링 구현 가능
ECR로 Private Image Repository 가능
버저닝 가능
AWS CLI로 CI-CD서버만 잘만들면
크게 어렵지 않게 배포 자동화도 가능
당연히, 도커의 이점을 모두 가져올 수 있음

새롭게 개발하는 서비스들 적용 완료
기존 서비스들,
Elastic Beanstalk에서 ECS로 변경 중
기존 대비 40%
이상 비용 절감 (컴퓨팅)

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

AWS의 지원
AWS Summit, 오피스 아워, 컨설팅 지원 등

감사합니다
정승현
imaster0209@lawoafactory.com

모두싸인의 AWS 성장기

More Related Content

What's hot

Similar to 모두싸인의 AWS 성장기

More from Amazon Web Services Korea

모두싸인의 AWS 성장기