2023 woowacon(우아콘)을 다녀왔습니다

 

2023 우아콘을 참석했습니다.

컨퍼런스는 몇번 가봤지만 서비스 개발 회사에서 진행하는 컨퍼런스에 참석하는 것은 처음이었습니다. 우테코를 진행하면서 유투브에 올라와있는 우형 개발자분들의 세미나를 여럿 본지라 발표에 대한 기대감이 있었습니다.

총 7개의 세션에 참여했습니다.

 

대규모 트랜잭션을 처리하는 배민 주문시스템 규모에 따른 진화

프론트엔드 모킹 환경에 감칠맛 더하기

어제보다 오늘을 조금 더 똑똑하고 편하게! 수기 업무 플로 자동화의 3가지 사례

우아한 FinOps: 클라우드 비용과 성능 사이

낯선 서드파티와의 동행: 믿을 만한 배민커넥트 서버 구축하기

우형의 새로운 백엔드 개발 표준

ElastiCache 운영을 위한 우아한 가이드: 초고속 메모리 분석 툴 개발기와 레디스 운영 노하우 소개

 

발표 제목과 내용을 보고 관심이 가는 세션을 골랐습니다. 분야별로는 백엔드 세션 3개, 클라우드 1개, 프론트 1개, 데이터베이스 1개, PM 1개입니다.

우아콘 세션을 7개나 들으니 우형의 문화가 좋다는 사실을 다시 한번 더 알수 있었고 발표자 팀에서 1년동안 주요하게 진행해온 일, 사용하는 기술과 앞으로 할 업무에 대한 약간의 정보를 알 수 있어서 좋았습니다.

세션도 유익한 내용이 많았는데 특히 대규모 트랜잭션 처리 세션과 FinOps 관련 세션이 정말 재미있었습니다.

기억에 남았던 세션 내용들을 짧게 정리해봤습니다.

대규모 트랜잭션을 처리하는 배민 주문시스템 규모에 따른 진화

배민 주문 시스템은 점심, 저녁에 트래픽이 몰리는 트렌드를 가지고 있고 일 300만건 이상의 데이터를 처리하고 있다.

이렇듯 서비스가 성장하는 과정에서 4가지 문제를 해결해야 할 필요성이 생겼다.

 

1. 단일 장애 포인트(SPOF) 제거

2. 대용량 데이터를 RDBMS 기반으로 조인 연산을 해서 조회할때 성능 저하

3. 대규모 트랜잭션 처리

4. 복잡한 이벤트 아키텍처에서 이벤트 발행에 대한 일관성 및 이벤트 유실에 대한 보장

 

각각의 문제를 해결한 방식은

 

1. 중앙 집중 DB 로 사용하던 Ruby 기반 Database 를 벗어나기 (탈루비)

 

• 가게, 메뉴, 주문, 결제, 배달 등의 여러 서비스를 MSA 로 전환해서 서비스간 느슨한 결합
• 각각 서비스 간에는 MessageQueue 를 사용하여 이벤트 통신
• 특정 시스템에서 장애가 발생해도 MessageQueue 에 있는 이벤트를 재발행하면 됨

 

2. 코맨드와 조회의 DB 분리 (CQRS)

 

• 주문 내역 상세페이지를 조회할때 많은 테이블들을 조인해서 가져오면 성능 저하 발생
• 데이터 조회는 NoSQL (MongoDB) 을 사용하여 역정규화한 데이터베이스 사용
• 단일 도큐먼트 사용하며 Id 기반으로 조회
• 동기화는 주문 도메인 생명 주기에 발생되는 도메인 이벤트를 통해 데이터 동기화 진행

 

3. 대규모 트랜잭션 관리

 

• 실시간 조회는 replica 를 통한 scale-out 이 가능하지만 쓰기 요청은 spec-up 을 했는데 한계에 부딪힘
• 샤딩을 고려하지만 Amazon Aurora 는 샤딩을 지원하지 않음
• 어플리케이션 샤딩 구현
  • SPOF 를 피하고 동적 데이터는 최대 30일까지만 저장된다는 주문 시스템의 특징을 고려하여 key based 샤딩으로 구현하기로 결정
  • key 는 주문 순번

 

4. 복잡한 이벤트 아키텍처로 인한 발행 주체 파악 어려움/ 이벤트 유실 시 재처리가 어려움

 

• 도메인 로직과 서비스 로직(알림, 현금 영수증 발행) 을 분리
• 도메인 로직은 내부 이벤트로, 서비스 로직은 외부 이벤트로 처리
• 내부 이벤트 발행되면 SQS 에 실리고 이벤트 처리기가 처리함 -> 이벤트 처리 주체 단일화
• 이벤트 처리기가 외부 시스템과 연결되어 외부 이벤트도 처리 (분석 로그, 데이터 동기화, 기타 외부 시스템 등)
• 트랜잭션 밖에서 이벤트 발행이 실패할때 이벤트 유실 시 재처리를 위해 트랜잭션 아웃박스 패턴 도입하여 재발행 가능하게 구현

뭔가 굉장히 길어졌는데.. 긴 내용이었는데 굉장히 재밌게 들었고 필기도 열심히 했다. 우테코에서 공부하면서 이것저것 주워들었던 지식들도 많이 나오고 그런 단편화된 지식들이 한번에 싹 정리가 된 느낌이었달까. 그리고 업무가 굉장히 재밌어보였다. 개발 문화가 좋은 서비스 회사에선 문제가 발생했을 때 어떤 식으로 고민하고 어떻게 해결하는지 맛볼 수 있어서 굉장히 굉장히 유익했다. 개인적으로 들은 세션 중에 제일 좋았다 👍

프론트엔드 모킹 환경에 감칠맛 더하기

작년에 프론트엔드 개발을 살짝 했던 경험으로 프론트 개발은 항상 서버 API 가 나온 다음에 할 수가 있었다. 그리고 나는 그게 매우 답답했다. 그래서 우테코에서 프로젝트를 하면서 프론트 크루들은 어떻게 개발을 하는지 궁금했었고 백엔드 API 가 나오기 전에는 모킹을 사용한다는 사실을 배웠다. MSW 라는 단어를 많이 들었었는데 이 세션에서 Mock Service Worker 라는 프로그램이 나왔는데 그게 MSW 였다. 근데 프로젝트를 할 때 보니까 MSW 도 불편한 점이 있는 것 같던데.. 그래서인지 세션 발표자의 팀도 Mock Service GUI 라이브러리를 개발해서 API 단위로 Mock Data 를 1:N 매핑하고 사용 케이스에 맞춰 상황 단위로 Profile 을 만드는 등의 커스텀을 할 수 있도록 했다고 한다.

서버와 프론트가 동시에 개발에 착수하는 경우가 많을거고 개발 일정을 맞추기 위해서 API 모킹은 필수적일 것 같은데 뭔가 더 편리하고 쉽고 범용화된 그런 것(?).. 이 얼른 세상에 나왔으면 좋겠다 (이미 있을수도..? 🤔)

백엔드 개발자 입장에서는 API 개발한 다음에 열심히 OAS 스펙으로 문서화해야겠다는 생각을 다시 한번 했다. OAS 를 추출해서 프론트엔드에서 API 호출을 이것저것 커스텀할 수 있는게 많은 것 같다.

어제보다 오늘을 조금 더 똑똑하고 편하게! 수기 업무 플로 자동화의 3가지 사례

라이더 플랫폼팀에서 기존에 수기로 진행하던 업무를 자동화한 프로젝트들을 프로젝트별로 중요시했던 부분을 강조하면서 설명해주셨다. 자동화 프로젝트도 프로젝트니까 사용자(목적) 정의 -> 기획 -> 개발 -> 배포 -> 운영 및 유지보수 의 프로젝트 개발 흐름을 따라간다.

 

1. 목적 정의를 중시 : 수수료 지급 명세서 발급 자동화

 

• 기존에는 고객센터로 발급 요청이 오면 서류에 수기로 작성해서 PDF 로 문서화한 뒤 메일로 발송해줌
• 지금 운영되고 있으니/ 당장 급하지 않으니/ 사업의 성장 목표가 중요하니까 우선순위에서 계속 밀림
• 하지만 업무량이 많아지고 국가 제출 증빙 서류이고 개인정보를 다루는만큼 휴먼 에러의 발생 가능성을 줄여야 하고 소득 신고 기간에 제출해야 하는 만큼 처리 기간이 늘어지면 라이더들의 만족도가 낮아짐
• 기존 운영자의 리소스 절감 및 편의성 개선이라는 목적에 휴먼 에러 방지 및 라이더 만족도 증가라는 목적이 추가되어 우선순위가 높아짐
• 정의한 목적에 맞게 기능 구현
  • 개인 정보 수집 최소화 -> 메일주소를 받지 않고 직접 기기에 다운로드 받을 수 있음
  • 생년월일 기반 개인정보 암호화
  • 원하는 기간을 선택하여 10초내 발급 가능

결론 : 운영자가 힘들게 일하면 그 여파는 서비스 어딘가에서 나타난다. 그 곳을 찾아 서비스를 개선하자

 

2. 상세 구현 내용 기획을 중시 : 시간제 보험료 정산 자동화

 

• 수기 업무는 기존 '수기업무 담당 운영자' 가 항상 있다
  • 운영자의 특징: 니즈 명확. As-Is 의 처음부터 끝 흐름까지 전부 파악. Edge 케이스 많이 알고 있음. 그러나 개발 프로세스에 익숙하지 못함
• 수기 업무 담당 운영자와 자주자주 만나 소통해야 한다 (사용자 스토리 및 flow 그릴때, 초안 그릴때, 개발 전 최종 컨펌때는 꼭!)
• 시간제 보험료 정산 자동화 후 피드백을 받을때 보험료 정책은 어디서 관리하냐는 피드백을 받음 -> 당황
  • 보험료 정책은 계속 변한다
  • 최초 정의때 예상하지 못한 개발 범위 등장 ! -> '보험료 관리 어드민' 페이지 필요
  • 그 이후 꼬리 질문을 통해 다양한 답변들을 받음 (비슷한 유형 보험 추가하고 싶음. 변경 히스토리 파악...)

결론: 운영자와 끊임없이 소통하자!

 

3. 피드백 분석/ 후속 대응을 중시 : 운전면허 검증 자동화

 

• 수기 업무가 자동화보다 나은점
  • 온갖 Edge 케이스에 사람은 자연스럽게 대응가능하다
• 운전면허 검증 자동화 후 배포 했을 때 다양한 이슈 등장
  • 외국인 라이더들의 이름이 너무 다양. 외국인 등록증/면허증 이름이 다름. 검찰청의 서버 검증 기간 시 서버 다운. 재발급->서버 연동의 시간 차 등
  • 자동화 on/off 기능 제공으로 대응

 

결론: 예상치 못한 후속 이슈에 대응하자

 

생각보다 배민이 최근까지 수기 작업을 많이 하고 있었구나 알 수 있었다. 또 완전한 자동화라는게 쉬운 것이 아니란 걸 다시금 느꼈다. 자동화한 곳에서 문제가 터지고 그 문제를 해결하려면 또 사람의 노동력이 필요하고 자동화를 위해 최소로 해야 할 수기 작업들도 있는 등 (프로젝트할때 PR 에 라벨을 붙여줘야 백엔드/프론트엔드 구분되서 CI/CD 파이프라인이 돌아가도록 구현한 것처럼) 사람의 수작업을 완전히 버리는건 참 어렵다. 위의 프로젝트들도 자동화로 전환하긴 했지만 사람이 해줘야 하는 최소한의 작업들이 있다고 한다. 완전한 자동화는 어떻게 할 수 있을까.....

우아한 FinOps: 클라우드 비용과 성능 사이

배민 서비스 매출 성장도 가팔랐지만 그만큼 클라우드 비용 증가 속도도 가팔랐다고 한다. 그래서 기술기획/엔지니어/재무/경영진/프로덕트오너(AWS) 가 함께 모여 클라우드를 잘 쓸 수 있는 환경을 구축하는 FinOps 를 시작했다고 한다.

기업은 수익을 창출해야 하는 집단이기 때문에 쓸데없는 비용을 절감하는게 참으로 중요하다. 전에 회사 다니면서도 느꼈다!! 그리고 항상 재무 목표는 엔지니어가 하는 일과 목표가 상충된다. 엔지니어는 장애율을 줄이고 안정성을 높이고 싶어하기 때문에 항상 넉넉한 리소스를 필요로 한다. 개발 도메인에서도 당연히 그랬다 ㅎㅎ FinOps 의 목적은 비용 절감이고 개발/Infra 팀의 목적은 장애 감소와 안정적 서비스 운영이기 때문에 둘의 KPI 가 상충된다. 그래서 클라우드를 잘 쓰고 있는지, 어떻게 효율화를 할 수 있을지 근거를 숫자로 표현하여 두 개의 상충되는 목표를 최적화시켰다고 한다. AWS CUR 을 이용해 비용을 상세 분석하고 비즈니스 데이터와 연결 분석하여 지표 분석 및 시각화, 이상 탐지를 자동화시켰다. 그리고 분석을 바탕으로 트래픽이 적은 새벽시간에 Scale-In 을 적용하기로 결정하였고 AWS CLI 로 CI/CD 에 일괄 적용하였다고 한다. 그리고 배포시스템개발팀에서는 추가로 스팟 인스턴스 (AWS 에서 기간 한정 세일로 제공해주는 인스턴스) 를 활용할때 종단률 관리가 필요하기 때문에 종단률 자체 추적하는 프로그램을 개발했다고 한다. 또한 오래된 기술을 페이드아웃하고 사용되는 클라우드 기술들을 표준화하고 K8S 를 도입하려는 등 여러 업무를 하고 있다고 한다. 

우아콘 후기

세션을 7개나 들어서 후반에는 좀 피곤하긴 했지만 취준으로 지친 마음에 기분 리프레시도 되고 지식도 쌓고 재밌었습니다.

우아한 FinOps 들을 때 배포시스템개발팀 지원했었는데 우형 떨어져서 마음이 좀 아팠습니다.. 업무 재밌어보였는데.... 😔 열심히 관련 공부해서 꼭 이쪽 분야에서 일해야겠습니다!