14탄-단 "2명"으로 연 매출 650억 온라인 쇼핑몰
단 "2명"으로 연 매출 650억 온라인 쇼핑몰을 구축한 '리씽크 몰'의 성공 비결
AWS서버리스 사용
<1> 리씽크 회사 소개
<2> 인프라 구성?
<3> 클라우드로 이전
<4> 개선된 부분?
<5> 비즈니스 관점 좋아진 점?
<1> 리씽크 회사 소개
1
프리미엄 제고 온라인 쇼핑몰
기업의 재고 문제를 해결하기 위해 다양한 설루션을 제공하고 소비자에게 가성비 높은 상품을 판매하는 플랫폼.
<2> 인프라 구성?
1
비즈니스의 증명이 먼저
처음에는 호스팅 사의 솔루션을 이용함.
조금 수정해 사용함.
1대의 서버로 디비, 웹 모두 사용
트래픽 증가로 3 티어로 서버 증설함.
2
문제점?
예측하지 못한 트래픽 문제
호스팅사에서도 스케일 아웃이 가능하지만, 며칠 전에 미리 스케줄을 잡아야 함.
스케일 아웃 이후에는 소스 변경이 어려움.
인기상품 발생 시 실시간으로 증가가 불가능함
미리 서버를 증설해 놓으면 서버가 남게 됨.
AWS솔루션 사용으로 결정함
이미 시장에 검증된 레퍼런스가 많아 AWS 선택함.
3
서버 리스를 선택한 이유?
3 티어 운영도 문제
개발과 비즈니스에 집중이 필요함
운영에 대해 리소스를 적게 가져가는 방향으로 접근
서버리스를 사용하기로 함.
4
서버 리스로 전환 후?
개발자 경험이 좋았다.
개발하고 테스트하고, 배포하는 이런 과정이 빠르게 동작할 수 있다는 점이 개발자로서 가장 만족.
<3> 클라우드로 이전
1
이전 시에도 서비스가 계속되어야 하는 요건.
2
인프라 레벨에서 적용할 수 있는 부분부터 우선 적용함.
Route53으로 부하 분산, GSLB로 임시적으로 부하 분산
CloudFront로 분산, 웹서버에 부하 줄임.
람다를 이용해 컴퓨팅 서비스를 제공함. 스케일 아웃에 대한 문제를 해결함.
3
동작?
모든 요청은 API Gateway 사용. Cloud fornt 사용하도록 함. 람다 사용.
상품 검색은 Cloud Search
스테 텍 리소스 저장은 S3
캐시로는 다이나모 디비 사용
비동기 요청 처리를 위해 SQS
관계형 데이터 베이스는 오로라 서버리스
4
애플리케이션 마이그래이션은?
기존 개발 코드가 스케일 아웃에 대한 고려가 안된 상태
람다가 스케일 아웃이 된다고 해도 데이터베이스 등은 스케일 아웃이 되지 않는 구조.
스케일 아웃이 가능한 애플리케이션 작성 필요.
애플리케이션은 뷰레 이어와 비즈니스 레이어로 되어 있다.
우선 뷰 레이어는 유지
고객이 체감하기 좋은 부분부터 개선 시작.
비즈니스 레이어를 교체 시작.
상품 카탈로그 API구현을 시작, 이벤트 기획, 상품 검색, 상품 상세 조회, 로그인, 회원가입 등을 REST API 형태로 구축.
대부분의 API 구축 완료.
뷰도 서버리스로 변경함.
5
람다 형태?
2개의 람다 서비스
사용자의 웹 요청에 대응되는 람다.
SQS에 의해 트리거 되는 람다.
커스텀 런타임을 이용해 도커 컨테이너를 람다에 올리는 형태이다.
6
동작?
모든 요청은 API Gateway를 통해서 람다가 트리거 되는 형태입니다.
람다 애플리케이션 내부에서는 API Gateway를로 들어온 요청을 분석해서 매핑되는 컨트롤러가 실행되고 있다.
람다가 1개라 유리한 부분?
람다가 웜 상태이다. 여러 서비스 요청이 있다 보니 계속 웜 상태. 콜드 상태로 안 간다.
람다 함수를 서비스 별로 분리하면 개발 배포가 용이하고 가벼워지지만, 개발 함수를 관리해야 하는 관리 이슈가 생긴다.
비동기 처리는 SQS를 이용하여 람다가 트리거 되는 형태이다.
<4> 개선된 부분?
1
커머스 서비스 , 상품 관련된 동작이 많다.
카테고리 별로 상품을 노출한다거나 이벤트에 맞는 상품을 보여주거나 상품 검색 등이 빈번하다.
기존에는 모두 mysql 사용. 요구 사하이 생기면 불필요한 join이 많아짐.
응답 속도가 느려짐
쿼리 최적화로 처리하기보다는 , 요구사항을 빠르게 처리하고 확장하기 좋은 설루션을 이용하기로 함.
아마존 클라우드 서비를 이용해 상품 풀을 구축함.
상품 풀을 구축하는 것만으로도 고객에게 딜리버리 되는 응답 속도가 3배 이상 빨라졌다.
2
Cloud Search는 인스턴스만 생성하면 운영에 대한 고민 없이 사용하기 쉬워짐.
실제로 인덱싱 구축 이후에 1주일 만에 실제 프로덕션에 적용했을 정도로 사용법이 쉬웠음.
3
Cloud Search를 사용함으로써 인덱싱 구현이 필요해짐
SQS를 이용하여 상품 인덱싱을 함.
상품의 상태가 변경될만한 이벤트를 지정하여 이벤트가 발생되었을 때 SQS에 쌓이고 , 람다가 트리거 되어
Cloud Search에 인덱싱 하는 형태이다.
4
응답 속도를 개선하기 위해 캐시 레이어를 사용함.
동일한 형태의 응답을
클라우드 프런트나 다이나모 디비를 사용
다이나모 디비는 파티션 키만 잘 관리하면 10ms 이내로 응답.
클라우드 프런트는 API응답을 캐싱하여 에지에서 응답함. 람다의 요청수를 줄이고 응답 속도를 높임.
5
다이나모 디비에 캐싱하는 방법도 SQS 사용함.
캐싱을 만료되는 시점에 두기보다는 캐싱을 재갱신해야 하는 시점을 이벤트로 지정하여 람다가 실행되어
람다가 캐싱을 재갱신하는 형태로 구현함.
<5> 비즈니스 관점 좋아진 점?
1
속도
동일한 오퍼레이션 600% 높아짐
구매 전환율도 올라가는 효과 생김
마케팅을 하더라도 응답 속도 저하가 없어짐.
2
개발 측면?
개발자 경험이 향상됨.
기존 운영 업무에 대해 고민하다 보니 기능 개발이 어려웠다.
기능 구현을 빠르게 배포하여 비즈니스적으로 검증하길 원하는 부분에 있어 서버리스은 괜찮은 대안.
3
이후 서버 리스트로 데이터 파이프 라인 구축, 분석 등으로 개선 예정
<6> 정리
서버리스 사례들의 공통적으로 나오는 이야기는 비즈니스 구현에만 집중할 수 있었다는 것이다.
글보다 서버리스로 적용하면서 얻는 인사이트가 훨씬 크다.
작은 부분부터 적용하길 추천한다.
경험치를 쌓아갈 수 있다.
https://brunch.co.kr/@topasvga/2617
감사합니다.
