11월 15일 수요일 우아한형제들의 우아한테크콘퍼런스에 다녀왔습니다.
💋 배달 사이언스
이번 우아콘에서 내세운 키워드입니다. 배달에 사용하는 로봇도 개발중인 것으로 보였는데 (찾아보니 일부 상용화중이라고 합니다.) 우형이 단지 배달이라는 이미지에 갇히기 싫고, 굉장히 기술에 진심이라는 것을 어필하고 싶다는 느낌을 받았습니다.
✔️ 배달의민족의 요구사항
배민은 고객과 사장을 대상으로 하는 2 side user 서비스입니다.
CEO가 배달의민족의 요구사항을 크게 정리해 줬습니다.
- 고객 대상
- 배달 경험 ⇒ 한집 배달, 알뜰 배달 등 시간예측을 통해 따끈한 밥을 받을 수 있어야 함.
- 탐색 경험 ⇒ 30만 개 음식점에서 맘에 드는 음식을 빠르게 찾을 수 있어야 함.
- A/B 테스트를 통한 최선의 UX 탐색
- GPT 등 AI를 활용한 사용자에 맞춤 추천
- 사장 대상
- 이슈 제공
- 장사 캘린더, 새로운 이슈 제공
- 데이터 제공
- 신규 고객, 나이, 지역별 재주문율 등 다양한 고객 관리 데이터 제공
💋 배달의 민족 성장통 (2018~2023)
배민 특성 상 밥 시간인 오후 12시와 6시 무렵 주문수가 폭증합니다.
2018년부터 꾸준히 성장하던 배달의 민족 현재는 정말 많은 트래픽이 발생하는데, 어떤 문제가 있었을까요?
✔️ 중앙 집중 DB가 단일 장애 포인트로 작용
Ruby 데이터베이스가 초기 중앙 DB로 사용되었지만, 장애가 많이 발생하자, 탈 루비를 시도했습니다.
탈 루비가 성공하자, 이제 장애 발생 시에 메시지 발생 실패 정도로 영향을 줄일 수 있었습니다.
✔️ 대용량 데이터(일 300만 건)을 수 년 간 보관해 조회 성능이 저하
MongoDB 등 NoSQL 역정규화를 통해서, 수많은 테이블을 JOIN하는 쿼리를 버리고, id만으로 조회할 수 있게 변경했습니다.
데이터의 동기화는 이벤트를 사용했습니다.
✔️ 대규모 트랜잭션으로 순간 트래픽에 쓰기 성능이 저하
읽기 성능의 경우, scale out을 통해 보강할 수 있었지만, 쓰기 성능은 scale up에 한계가 있었습니다.
샤딩을 사용하기로 했고, AWS 오로라에서 샤딩을 지원하지 않아 애플리케이션 코드로 구현했습니다. (이때 왜 탈 AWS를 생각하지 않았는지는 의문이지만, 설명해주시지는 않았습니다. 이때는 AWS가 가장 핫해서 탈 AWS에 대한 선택지는 없었던 걸까요?)
무튼 애플리케이션 코드로 구현한다는건 진짜로 신박!
데이터를 어떤 샤드에 넣을 지 3가지 방법이 있었습니다.
- Key ⇒ 해시를 기준으로 샤드 결정
- 균등하게 분배되고 구현이 간단함.
- 데이터 제거 시 분배, 재배치가 복잡함.
- Range ⇒ 예를 들어, 가격을 기준으로 샤드 결정
- 범위만 구분하면 되므로 구현이 간단함.
- 데이터가 균등하게 분배되지 않아, Hot Spot이 생겨 성능이 저하될 위험이 있음.
- Directory ⇒ 해시와 비슷한데, 결정된 샤드가 무엇인지 저장하는 테이블을 별도로 관리
- 유연하게 관리 가능
- Look Up Table에 장애가 발생하면 또다시 단일 장애 포인트가 됨.
배민 서비스 특성 상, 장애 발생 시 배고픈 고객들이 화를 내기 때문에 치명적입니다.
데이터는 30일까지 주문이 취소 가능하다는 정책인데, 대부분은 1일 이내 데이터가 완결됩니다.
Hash Based인 방식(Key)을 채택해, 주문번호를 샤드 수로 나눈 나머지를 샤드 번호로 선정했습니다.
AOP, AbstractRoutingDataSource를 사용해서 애플리케이션 레벨에서 구현했습니다.
⇒ N개의 RDMS에서 함께 쓰기를 지원하게 되어, 쓰기 성능이 향상되었습니다.
✔️ 이벤트를 무분별하게 발행해, 이벤트가 유실되고 서비스의 복잡도 증가
주문 시 이벤트를 발행하면, 여러 개의 다른 서비스에서 알아서 이벤트를 받아 처리하는 식으로 서비스 중이었습니다. 하지만, 이벤트가 규칙 없이 발행되어 서비스 복잡도가 커지고 Spring Event는 유실 시 재처리가 어렵다는 문제가 있었습니다.
내부 이벤트와 외부 이벤트를 정의했습니다.
내부 이벤트는 order id, order status 정도의 정보만 전달하면 이벤트 처리기가 알아서 모든 로직을 처리하도록 로직 처리 지점을 단일화해서, 도메인 로직의 처리에 가독성을 높였다고 합니다.
트랜잭션 내 실패하는 경우에는 전체 로직이 실패하므로 일관성을 유지할 수 있었고, 트랜잭션 외에서 실패하는 경우에는 데이터의 정합성이 훼손되므로, Outbox라고 하는 일종의 스냅샷을 별도로 두어, event 발행 전의 payload를 저장하고 트랜잭션 외 실패 시에 유실 이벤트를 재발행하는 식으로 해결했다고 합니다.
💋 배달의 민족 대세는 MSA?
성장통을 보다 보면, 자연스럽게 MSA로 향하게 됩니다.
백엔드 오전 세션 내내 MSA에 대한 내용 뿐이라 솔직히는 좀 다양성 면에서 아쉬움이 있었습니다. 다른 내용을 다뤘으면 더 좋았을걸.. 하면서도 이만큼 MSA가 요즘 핫한 주제인가.. 싶기도 했습니다.
공개 발표라서 하지 못한 이야기들이 있겠지만, 몇몇 세션에서는 발표에서 설명한 내용으로는 MSA 도입에 대한 충분한 고민이 느껴지지 않아서 아쉽기도 했습니다. B2B 서비스이기도 해서 그렇게까지 트래픽 과중이 심하려나 싶어서 그냥 하고 싶어서 한 건가 하는 느낌도 들었는데, 그만큼 배달 서비스에서는 MSA가 큰 이점이 있는 것일 수도 있겠다는 생각도 들었습니다.
소프트웨어의 구조는 커뮤니케이션 구조를 따라가게 된다는 콜웨이 법칙에 대해서도 처음 알게 되었습니다. 이전에 제가 DDD 리팩터링 미션을 진행할 때, 했던 생각과 굉장히 유사해서 신기했습니다.
그럼에도 다른 부서들이 MSA에 대해서 우선순위가 매우 밀려있을 때 우리 팀의 코드부터 서서히 분리해낸다는 것이 대단하다고 느껴졌습니다.
RPC 통신에 대해서는 좀 생소했는데, 스프링부트에서 직접적으로 지원을 해주지는 않는 것 같았습니다. 저와 같이 RPC 통신을 낯설어 하는 사람들을 위해서 스프링부트와 거의 기시감이 느껴지는 라이브러리를 구현하신 것을 시연까지 보여주셨는데 상당히 인상깊었습니다. 물론 당장 RPC를 직접 사용할 일은 없겠지만, 저런 식으로 팀원들이 어려워하는 것을 도입하고 싶을 때는 직접 라이브러리를 만드는 방법도 있구나 하고 정말 신박하다고 느꼈습니다.
✔️ 참고자료
- https://www.samsungsds.com/kr/insights/msa.html
- https://story.baemin.com/3795/
- https://tech.kakao.com/2021/09/14/msa/
- https://www.baeldung.com/grpc-introduction
💋 뭐든 수치화해서 보여주면 좋겠구나.
보안을 숫자로 관리한다는 세션에 궁금해서 들어가봤는데, 보안에 대한 이야기는 거의 하지 않아서 쪼금 아쉬웠습니다. 들어보니 2018년까지 우아한형제들에 보안 관리를 거의 안했다고 해서 좀 깜짝 놀랐는데, 아무튼 현재는 소수의 인원이 담당하고 있다는 내용이었고, 발표 자체는 보안보다는 어떻게 위험 지수를 수치화했는지에 대한 이야기였습니다. 생각해보니 보안에 대해서 터놓고 말할 수는 없을텐데 그런 것까지는 생각을 못하고 선정했던 것 같네요.
수치 측정과 관련해서는 내부적인 이야기라 그런지, 발표 내용만으로는 너무 주관적인 수치라는 생각이 들긴 했습니다. 그래도 이런 식으로 ‘깃짱의 공부 위급 지수’ 이런거 나타내면 재밌을 듯. 우리 팀에서도 ‘스탬프크러쉬의 개발 지수’ 이런거 나타내면 나중에 발표할 때 재밌을 것 같네요ㅎㅎ
💋 QA는 정말로 테스트코드 작성을 어려워 하는구나.
인사할 시간도 없이 테스트를 자동화한다기에 들어갔습니다. QA 부서에서 AI를 사용해 QA를 자동화..?
근데 AI가 Chat GPT에게 어떻게 테스트코드 쓰냐고 물어보는 것이었어서 좀 반전ㅋㅋ
그래도 QA 부서가 이만큼 코드 작성과 테스트 코드 작성도 부담이구나 하는 내용을 얻어갔습니다.
💋 배달 로봇?
라스트마일에 대한 운송비 부담이 커지면서 배민에서는 배달 로봇을 도입하려는 것처럼 보였습ㄴ디ㅏ. 실제로 기사를 찾아보면, 우형에서 낸 듯한 기사가 많이 있었는데, 이미 커피 같은 작은 것들은 상용화하고 있었다고 하네요. 앞으로 인구 감소에 대비해서 좋은 해결책이 될 것 같다고 느꼈습니다. 배달팁이 줄어들려나요?
사람이 타고있지는 않으니깐 규제나 윤리적 부분에서 자율주행만큼 복잡하게 생각할 필요가 없을 것 같긴 할테지만, 그래도 이 로봇으로 인해 사고가 난 경우에 어떻게 해야 할지는 미지수네요 궁금합니다!
해외에서는 라스트마일을 드론 등이 대체한 규모가 꽤나 된다고 하지만, 해외의 주택 문화과 다르게 우리나라는 굉장히 밀집해서 아파트 문화이라는 특수한 조건에서 살고 있어서, 정말로 문앞까지 배송을 완료하게 되는건 또 다른 문제일 것 같습니다. 또 웃기게 길가다가 나쁜 사람이 로봇을 두들겨 패서 안에 있는 것을 빼먹으면 어떡하지 하는 생각도 듭니다.
✔️ 참고자료
- https://economist.co.kr/article/view/ecn202212030017
- https://weekly.chosun.com/news/articleView.html?idxno=28859
💋 회고
몇달 전이었으면 거의 못 알아들었을 내용들이었을 텐데, 그래도 이만큼 성장해서 알아들을 수 있단게 즐겁고!
다음에도 또 한 번 가보고 싶네요. 그때는 네트워킹을 좀 더 열심히 해보고 싶어요.
도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!
