다시 보는 배달의민족 데이터 흐름 +) 클라우드 서비스
[코드스테이츠 PMB 11] Ep27. 개발 지식
지난 포스팅에서, 배달의민족의 데이터 흐름을 예측하기 위해 플로우 차트를 작성하고 클라이언트와 서버, DB를 분석해 보았다. 나의 앱 사용 경험과 우아한형제들 기술 블로그, 기타 자료들을 참고해서 익힌 개발 지식으로 풀어냈었다.
개발 알고리즘과 용어를 학습한 내용을 바탕으로 다시 한번 배달의민족의 데이터를 분석해보려고 한다. 그러면서 새롭게 알게 된 부분들을 점검해 볼 수 있을 것 같다. 처음엔 어렵고 생소한 내용들도 여러 번 반복하다 보면 점차 익숙해지고 보이지 않았던 것들이 보이게 되는 것처럼 개발자의 용어들을 배우는 것도 마찬가지이지 않을까?!
회고
지난 포스팅에서는 배달의민족의 일부 기능에 대해 간단한 플로우 차트를 작성해 보며 유저의 서비스 이용 프로세스를 파악해 보았다. 또한, 서버의 응답이 없는 상황에서 배달의민족 앱을 사용할 수 있게 만든 '오프라인 모드' 기능을 통해 유저-클라이언트-서버 API에 이르기까지 데이터가 어떻게 이동되는지, 결과적으로 사용자가 보는 화면을 구현하여 노출할 수 있는지 알게 되었다.
오늘은 유저의 서비스 이용 관점에서 기본적인 데이터 흐름을 파악하는 것에서 나아가 플로우 차트와 데이터 관점에서 보다 세부적인 내용들을 추가해 보려고 한다. 관련하여 아래와 같이 2가지로 정리하였다.
1) 배달의민족 전체 서비스 유저 프로세스 파악하기
지난 포스팅의 '유저 프로세스에 따른 플로우 차트' 유형지난 포스팅에서 '회원가입 및 로그인'과 '배달 주문 및 결제'라는 유저의 두 가지 행동에 대해 서비스 이용 프로세스를 알아보았다. 당시 플로우 차트의 개념을 이해하고 유저의 흐름에 따라 플로우 차트를 직접 그려본다는 점에 초점을 두고 작성했었다.
하지만 배달의민족 서비스 전체적인 관점에서 유저 흐름을 파악하기에는 무리가 있었기 때문에 이번에는 '메인 홈'을 기준으로 서비스 전체보기, 주소 설정, 검색, My배민 순으로 플로우 차트를 그려보려고 한다. 서비스 전체 흐름을 파악하고 시각화하는 데 용이할 거라는 생각이 들었다.
2) 배달의민족 클라우드 서비스 알아보기
테크 기반 기업들이 대부분 그렇듯 어마무시하게 쌓인 방대한 데이터들을 어떻게 관리하고 저장하는지 궁금해졌다. 배달의민족은 2010년 출시된 이후 배민 라이더스, 배민상회, B마트 등 다양한 서비스로 확장했고 현재는 국내 배달앱 1위로 압도적인 시장 점유율을 차지하고 있는 만큼 트래픽도 크게 증가했다.
배달의민족은 클라우드 서비스를 이용함으로써 이 문제들을 해결하였는데, 어떻게 해결하여 안정적인 서버를 구축할 수 있었는지 간단히 살펴보겠다.
1. 배달의민족 플로우 차트 다시 그리기
배달의민족 홈 화면배달의민족에 접속하여 로그인하면 가장 먼저 보이는 홈 화면이다. 홈 상단의 탭 바를 기준으로 서비스 전체보기, 주소 설정, 검색, My배민을 큰 카테고리로 두고, 각 카테고리 아래 하위 메뉴들이 포함되어 있는 구조로 플로우 차트를 작성하였다.
메인 홈 상단 배너를 기준으로 다른 메뉴로 이동할 수 있는 플로우를 그린 것이기에 배달의민족의 모든 기능의 플로우를 담지는 못했지만 음식을 배달/포장 주문하려는 유저의 입장에서 꼭 사용해야 하는 기능들을 포함하여 서비스 이용 프로세스를 나타냈다.
2. 배달의민족이 클라우드 서비스를 이용하기까지
우아한형제들은 좋은 음식을 먹고 싶은 곳에서 라는 기업 비전을 가지고 있는 대표적인 대한민국의 푸드테크 기업이다. 2010년 '배달의 민족'을 시작으로, 꾸준히 서비스를 확장했다. 2015년부터 2020년까지 5년간 총 6개의 서비스를 론칭했다.
2016년 AWS로의 All in Migration을 발표한 이후, 모든 온프레미스 환경을 클라우드로 이관(migration)했다. 2020년 11월부로 데이터 센터에 남아있던 금융권 워크로드를 모두 이관하게 되었다. 국내에서는 처음으로 모든 환경을 클라우드로 이관하는 사례가 되었다.
배경
Challenge 1. 서비스의 확장
배달의민족 서비스의 확장 / 출처: https://velog.io/@htchoi1006Challenge 2. 트래픽 증가
일일 트래픽 증가 시간 / 출처: https://velog.io/@htchoi1006배달의민족은 점심과 저녁, 하루 두 번의 피크시간이 존재한다. 원하는 시간에 식사를 하는 것이 매우 중요하기 때문에 이런 트래픽에서도 서비스를 안정적으로 제공하기 위한 노력이 필요했다.
어떻게 해결했는가
1) 서비스의 확장에 따른 가용성과 유연성 확보
2016년 AWS 클라우드로 전환 시에는 몇 개의 주요 앱들이 하나의 메인 DB를 사용하는 모놀리식 아키텍처*였고 메인 DB는 클라우드가 아닌 온프레미스* 환경에서 운영되고 있었다. 메인 DB는 아주 복잡했기 때문에 마이크로서비스* 단위로 주문하고, 서비스 중단 없이 이관하는 과정에서 많은 시행착오를 겪었다. 4년에 걸친 이관 과정에서 Aurora, ES, NoSQL 등도 적극적으로 사용했다.
따라서 현재 우아한형제들의 많은 서비스는 600개 이상의 마이크로서비스들로 구성된 아키텍처로 전환되었고, 각 마이크로서비스들은 도메인에 최적화된 가용성과 유연성을 확보하게 되었다.
모놀리식 아키텍처에서 마이크로 서비스로 변화 / 출처: https://velog.io/@htchoi1006- 모놀리식 아키텍처(Monolithic Architecture) : 전통의 아키텍처를 지칭하며, 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태이다. 모놀리식 아키텍처의 경우 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다.
- 마이크로 서비스 : 하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말한다. 각 마이크로 서비스는 상호 통신이 가능하며 이를 통해 전체 서비스를 구성한다.
- 온프레미스 : 소프트웨어 등 솔루션을 클라우드 같이 원격 환경이 아닌 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식
모놀리식 아키텍처와 마이크로서비스 / 출처: velog2) DB의 부하를 줄여 안정적인 속도로 서비스를 제공
트래픽의 증가에 따른 DB 부하를 해결하기 위해 캐시 아키텍처로 전환을 시작했다. 데이터 영역의 높은 복잡도는 마이크로서비스 아키텍처로 전환되면서 개선됐지만 마이크로서비스 아키텍처로 인한 내부 트래픽이 증가하면서 각 도메인별로의 DB 부하가 보통 수준으로 증가했다.
이 문제를 해결하기 위해 자주 변경되지 않거나 실시간 반영이 필요하지 않은 데이터의 경우 캐시레이어를 추가하여 DB 부하를 최소화했다. 이 방법으로 트래픽이 증가해도 안정적인 서비스를 제공할 수 있게 되었다.
* 캐싱 : 컴퓨팅에서 캐시는 일반적으로 일시적인 특징이 있는 데이터 하위 집합을 저장하는 고속 데이터 스토리지 계층이다. 따라서 이후에 해당 데이터에 대한 요청이 있을 경우 데이터의 기본 스토리지 위치에 액세스할 때보다 더 빠르게 요청을 처리할 수 있다. 캐싱을 사용하면 이전에 검색하거나 계산한 데이터를 효율적으로 재사용할 수 있다.
캐시 아키텍처 / 출처: https://velog.io/@htchoi10063) 코드로 인프라 관리
안정적인 클라우드 인프라를 운영하기 위해 코드로 인프라를 관리하고 프라이빗 네트워크 허브를 구축했다. 누가 작업하더라도 일관성을 유지해야 했고, 변경에 대한 추적도 하기 위함이었다. 이것을 위해 테라폼 등의 기술을 사용했다. 그 결과 많은 인프라 변경을 빠르게 할 수 있었고, 형상 관리를 통해 인프라 변경을 쉽게 파악할 수 있게 되었다.
기존에는 네트워크 연동을 추가할 때마다 메시지 형태로 복잡도가 증가하는 구조였다. 이 구조에서는 복잡도가 높아지면서 작업에 필요한 시간이 증가하고, 실수 확률 또한 증가했다. 하지만 새롭게 네트워크 허브를 구축한 후에는 복잡도도 낮아지고 관리 비용이 감소했다. 또한 신규 네트워크를 쉽게 연동할 수 있었다.
배달의민족 유저 입장에서 서비스 프로세스를 다시 파악해보고, 배달의민족이 클라우드 서비스를 도입하기까지 과정을 살펴보았다. 아직 기술 블로그나 개발자를 위한 블로그인 velog를 보면 모르는 용어 투성이지만 처음 보는 용어들은 계속 구글링해서 눈에 익히고 있다.
그래도! 배경지식이 전혀 없었던 처음보다는 데이터, 개발 관련 용어를 이해하기가 수월했다. 기술 블로그와 개발자 블로그를 찾아봤지만 생각보다 배달의민족의 데이터 구조나 흐름에 대한 개략적인 내용을 찾기가 어려워(내가 이해를 못한 것일 수도...) 살짝 산으로 간 느낌도 들긴 하는데 그래도 이전에 학습했던 내용에 대한 회고나 복습이 꼭 필요하다고 느낀 시간이었다:)
