[WOOWACON 2024] 우아콘 2024 후기

 

이번 10월 30일에 열린 우아콘 2024에 참가하였습니다.

 

원래는 참가권 응모 당첨에 실패하여 이번 컨퍼런스는 온라인으로 들어야하나 고민하였는데, 다행이도 같이 신청했던 친구에게 초대권을 양도받아 현장에서 모든 세션을 즐길 수 있었습니다.

 

다만 참가자 정보 목걸이가 다른 회사와 친구 이름으로 나와서 혹시나 마주친 다른 사람들에게 설명을 어떻게 해야할지 열심히 생각했었는데, 다행이도(?) 아는 사람을 마주치지 않아 해명할 기회는 없었던... 슬픈 사연이 있었습니다.

 

https://2024.woowacon.com/

WOOWACON 2024

 

 

이번 컨퍼런스는 오전 10시부터 오후 6시까지 알이 꽉 찬 구성으로 진행되었는데요, 아주 보람차게 하루를 즐기고 왔습니다.

 

저는 백엔드 관련 세션을 즐기고 왔는데, 제가 참여한 세션들은 다음과 같습니다.

 

배달의 민족 API Gateway

많은 서비스 및 시스템에서 사용하는 API Gateway에 대한 정의와 필요성, 핵심 기능(라우팅 & 횡단 관심사)에 대해서 설명해주고, 실제 API Gateway와 API Gateway pattern에 대해서 명확하게 분리해서 설명하여 아주 이해가 잘 되도록 발표해주셔서 감사했습니다.

 

실제 배달의 민족에서는 이 API Gateway를 어떻게 구축하고 활용했는지 설명해주고, 크게 인증, 라우팅, 보안, 흐름제어 부분으로 파트를 나눠 발표해주었습니다.

 

Kafka를 이용하는 메시지 플랫폼에서 장애를 겪으며 아키텍처를 개선한 이야기

현재 배달의 민족에서 사용하는 FCM 시스템에서 발생하는 장애 건수를 줄이고, 플랫폼 유지 비용을 줄이기 위해서 수행한 아키텍처 개선 방법에 대해서 고민하고 수행한 방안에 대해서 공유해주는 세션이었습니다.

 

단순히 시스템 스케일 업이나 아웃을 통해 Kafka 파티션 증가를 통한 개선 방법이 아니라, 다음과 같은 방법 등을 통해 새로운 아키텍처를 구성한 경험을 공유해주었습니다.

• 아웃라이어 제거
• 동시 처리량 증가, 비동기 전환
• 트래픽 성격에 따른 쓰레드 분리
• 불필요한 카프카 요청 제거 (중간 모듈 제거, 배치 리스너 적용)

 

Kafaka 기반 대규모 데이터 동시성 최적화: Reuqest-Reply 패턴 활용 사례

현재 배달의 민족에서는 각종 여러 상황과 이벤트를 통해 배달의 주문이 가능한 범위를 유동적으로 조절하는데, 이러한 사례에서 여러 트리거가 동시 발생했을 때 일어날 수 있는 문제에 대해 고민하고 이를 개선하기 위한 아키텍처를 구성하는 방안에 대해서 발표해주었습니다.

 

트리거가 동시 다발적으로 발생했을때, 정확한 순서 보장을 위해 Key를 구분하여 Kafka의 같은 파티션을 사용하도록 하여 순서를 보장하고, 처리 결과는 EIP(기업 통합 패턴)를 사용하여 처리했습니다.

 

Spring에서 Reply kafka 기능을 지원해주기 때문에 Req-Reply Messaging Pattern을 적용한 사례를 공유해주었습니다.

 

WMS 재고 이관을 위한 분산 락 사용기

해당 세션은 명료하고 깔끔한 세션이었던 것 같습니다. 

 

WMS는 Warehouse management system의 약자로 B마트 서비스를 수행하기 위한 물류 센터 시스템입니다.

해당 시스템에서 재고를 할당하고 물류를 이관하는 과정에서 발생한 동시성 문제로 인해 기대와 다르게 동작하는 시스템을 개선하기 위해 분산 락을 활용한 방법에 대해 공유해주었습니다.

 

분산 락 방식을 적용하였을때 발생한 지연 대기 문제나 동일 유형 처리에 대해 병렬로 처리할 수 있는 아키텍처를 구성하기 위해서 분산 락과 상태 키를 함께 활용한 방안에 대해서 발표해주었습니다.

 

DDD 그거 그렇게 하는 거 아닌데

요새 어느 컨퍼런스나 기술 블로그에서 빠지지 않는 세션인 것 같습니다.

현재 제가 회사에서 참여하고 있는 프로젝트에서도 해당 DDD를 주도적으로 도입하고 있기 때문에, 최대한 귀에 담기 위해서 노력했던 세션이었습니다.

 

일반적으로 DDD 세션에서 나오는 내용 말고도, 해당 세션에서 특히 기억에 남았던 내용을 정리하면 다음과 같습니다.

• 한글, 영문 네이밍을 개발자만 고민하지 말고 구성원 전부 같이 고민하자.
• 용어 사전을 README에서 관리. 용어 또한 리뷰 대상이 될 수 있다. 명사만 네이밍할 수 있는 것이 아니며, 사전적 정의 뿐 아니라 예시도 넣어서 관리하면 좋다. 또 이를 프로젝트 모든 곳에서 사용해야 한다.
• 고객, 개발자, 테스터가 함께 작성하는 인수 테스트. 고객의 관점에서 SW가 어떻게 작동해야하는지 고려하자.
• 도메인 지식 탐구: SW가 해결해야하는 문제 영역을 구하고, 비지니스 도메인을 통해 부족하거나 지나치지 않은 도메인 확장을 고려하자.
• 점진적인 DDD 적용을 위해서 처음부터 모든 영역을 나누는 것이 아니라, 작고 영향력이 적은 도메인 친구들부터 분리해보자.

 

우아한 데이터 허브. 일 200억 건 데이터 안전하게 처리하는 대용량 시스템 구축하기

해당 세션은 컨퍼런스에서 만났던 배민 개발자 지인이 꼭 들어보라고 강추했던 세션이었습니다. 정말로 가장 재밌고, 어려웠던 세션이었습니다. 😂  해당 세션은 2개의 파트로 나누어져 발표되었습니다.

 

분당 700만, 하루 200억 데이터가 수집되는 배달의 민족 시스템에서 이를 관리하고 해결하기 위한 다음과 같은 스텝을 통해 인사이트를 공유해주었습니다.

 

데이터 통합

Back Pressure(생산자(메시지) 속도를 조절해 안정적으로 처리할 수 있도록 해주는 매커니즘)을 통한 방법 공유.

이를 통한 이벤트 드리븐 아키텍처를 퍼블리셔 서버, 리스너 구성

 

데이터 처리

고가용성, 읽기 및 쓰기 성능에 대한 고민. Index가 커짐에 따른 DMC(Data Manipulation Commands)처리 저하.

파티션 분리 시, SPOF 문제를 샤딩 처리를 통해 해결.

Hot, Cold 파티션 문제 해결을 위해 룩업 테이블 수정으로 부하 분산 처리 수행.

 

데이터 저장,  데이터 조회, @네트워크

Persistence API 개발

- 서버별 중복된 코드와 다른 환경, 데이터 일관성, 호환성, 스키마 관리를 위해 Persistence API 개발

우아한 RPC에서 미리 받고 싶은 포맷을 지정하여 이를 통해 직렬화, 역직렬화에서 발생할 수 있는 부하를 Client에서 관리할 수 있도록 처리.

 

 

그래서 후기는?

역시나 명성에 걸맞게 IT에 진심인 컨퍼런스였다고 생각합니다. 이러한 기술과 문화를 가진 회사에서 일하면 어떨까? 에 대해서 계속해서 생각해보게 되는 시간이였던 것 같습니다.

 

또 여러 백엔드 개발자들과 관련해서 이야기를 나누다 보면, 백엔드 영역은 더더욱 경험이 없으면 실제로 알기 어려운 것들이 많은 영역이라고 생각하는 분들이 많고, 저 또한 그렇게 생각합니다.

 

실제로 현재 운영하고 있는 영역에 새로운 기술들을 적용해보기는 쉽지 않은데요, 그러한 부분들을 컨퍼런스에서 공유해주어 실제 경험해보지 않더라도 대규모 트래픽이 발생하는 실제 시스템에서 기술을 적용할때 발생하거나 놓칠 수 있는 부분들을 간접적으로 경험할 수 있는 좋은 기회라고 생각합니다.

 

내년 2025 우아콘도 꼭 참여해야겠다고 생각해본 하루였습니다. 😊