[241030] 우아콘 2024 참여 후기

우아한형제들 주관 테크컨퍼런스인 WOOWACON 2024에 참여했다!

https://2024.woowacon.com/

WOOWACON 2024

 

작년 11월에는 우아콘 2023을 팀원분 한분과 함께 갔다왔었다. 

(후기: https://kth990303.tistory.com/468)

 

올해는 비교적 일찍인 10월 말에 우아콘이 열렸고, 팀원분 한분 뿐만이 아닌 팀원 5분 + 내 지인들 + 우테코 동료들 등등 엄청나게 많은 지인들과 함께 우아콘에 참여하였다.

우아콘 2024 굿즈

 

지난 해와 다르게 이번에는 쿠키를 굿즈에 포함시켜주었다.

아마 WOOWACON 내의 알파벳으로 구성된 쿠키 중 랜덤하게 주는 듯?

우아콘 2024 후기

 

우아콘 2024 영상들은 추후 유튜브에 올라올 예정이라고 한다.

그렇기 때문에 이번 우아콘 세션들에 대한 후기는, 내용 위주보다는 느낀 점 위주로 짧막하게 작성해보려 한다.

(아예 작성을 안할 세션도 있다. 딱 하나 있는데, 그 세션을 이해를 아예 못해서 작성을 못할듯하다 ㅜㅜ)

---

배달의민족 API gateway

우리 실 TL 이기도 하신 권용근님 (https://blog.kingbbode.com/) 의 세션 발표이다.

 

나는 API gateway 에 대한 정의 자체를 잘 몰랐다. (과거형이 아닌 현재형으로 써도 괜찮을 것 같다. 세션 하나 듣는걸로 `난 이거를 알아!` 라고 하기도 참 뭐하므로...) 그냥 단순히 api 서버 앞단에서 공통적인 관심사를 처리해주는 역할 정도로만 알고 있었다.

따라서 이번 세션을 통해 얻고 싶은 부분은 아래와 같았다.

 

• API Gateway 가 정확히 무엇인지?
• 배민에서 api gateway 는 어떻게 구현되고 있는지?

 

이번 세션을 통해 API gateway 가 각 서버들의 횡단관심사에 속하는 역할을 해주는 친구라는 걸 알게 됐다. 그 예로는 라우팅, 모니터링, 인증/인가 등이 있겠다.

 

내가 원래 알고 있던 내용과 비슷했지만, 한 가지 다른 점은 api gateway pattern 역할을 해주는 서버 (ex. BFF) 와 API gateway는 다르다는 것을 새롭게 알게 됐다. API gateway pattern 역할을 해주는 서버란, api gateway가 각 서버들을 위한 역할을 해주는 것과 달리, 클라이언트를 위한 client specific api 를 제공해주는 서버였다.

이게 무슨 소리냐, MSA 아키텍처로 구성돼있는 배달의민족 앱을 생각해보자. 그 중에서 마이배민 화면을 보면, 내가 현재 가지고 있는 쿠폰목록, 내가 어떤 등급에 속하는지 알 수 있는 화면, 내가 갖고 있는 포인트 등 다양한 도메인의 정보를 가지고 있다. (쿠폰, 결제, 회원, 주문 등) 각 도메인의 API를 단순히 병합만 해서 보내주게 된다면, 클라이언트가 수많은 도메인서버를 직접 의존하게되어 변경에 유연하지도 않고 불필요한 정보를 지나치게 많이 얻게 된다. 이 때 API gateway pattern 역할을 해주는 BFF 서버가 있다면 클라이언트의 요구사항을 위한 specific 한 api를 만들 수 있게 된다는점! 의존성도 줄일 수 있으니 금상첨화다.

 

API gateway 와 API gateway pattern 서버 (BFF 등) 의 아키텍처는 상당히 유사하나 목적과 역할이 확실히 다르다는 것을 알게 됐다. 이것만으로도 이 세션에서 얻어간 것이 많다고 생각이 들었다!

 

배달의민족 내에서 api gateway를 어떻게 구현하고 있는지에 대해서도 얘기를 들어보았다.

spring cloud gateway 를 이용하는데, 거기서 제공해주고 있는 필터체인 내 필터들을 커스터마이징한다고 한다. Spring Cloud gateway가 뭐지..? 싶은 생각과 함께, 나중에 횡단관심사 쪽 요구사항이 생기면 이 부분을 공부해봐야겠다 싶었다. (지금 한다는 말은 안함ㅋㅋㅋ 아..)

 

그리고 용근님의 coroutine, 리액터 에 대한 견해도 들었다. 사실 난 둘 다 잘 아는 건 아니라서.. 그런가보다! 하고 넘겼다.

쿠폰 쪽에는 리액터가 하나도 안쓰이는데, 좀 궁금하기도 하다. 주문 쪽 같이 엄청난 대용량 트래픽환경에선 사실상 필수적일 거 같은데. 참으로 궁금하군..

 

 

끝나고 세션 후기

 

처음에는 세션 후기들도 `나중에 봐야지~` 하는 마음으로 하나하나 캡처했었는데,

이게 처음이자 마지막으로 캡처한 사진이 됐다. 

 

나중에 캡처하려니까 귀찮아졌다ㅋㅋㅋ (그래도 세션 후기 구글폼 작성은 매 세션마다 열심히 했다.)

---

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

사실 카프카를 관리해본 적이 없어서, 이 세션을 들어야되나? 고민이 됐다.

하지만 장애에 대한 아키텍처 개선이 주가 되는 것 같아서 한번 들어보았다! 꼭 카프카를 알지 못하더라도, 개발자분들이 어떠한 문제상황을 어떻게 해결해나가는지 문제해결방식을 얻어가자는 마인드로 들었고, 아주 만족스러운 세션이 되었다!

 

해당 세션에서 포인트가 되는 부분 - 아키텍처

 

전사 LMS, SMS, 푸시알림 등을 다루는 메시지플랫폼의 아키텍처를 처음에 소개해주었다.

그리고 이 아키텍처를 바탕으로 병목을 해결해나가는 스토리텔링 세션이었다.

 

상황이 참 재밌었는데, 카프카 토픽 파티션 개수를 줄여달라는 요구사항과 함께 트래픽을 3배 이상으로 버텨달라~ 는 엄청난 요구사항을 처리해야 하는 상황이었다. (보는 입장에선 재밌지만... 개발자분들의 식은땀이 여기까지 보이는 것 같다.)

 

일단 프로듀서 쪽 InvalidProducerEpochException 예외로 인해 컨슈머 쪽 파티션 lag이 증가해서 발생하는 레이턴시를 없애기 위해, kafka에서 제공해주는 Exactly Once 를 과감히 버리고 직접 중복 제거를 했다고 한다. 쉽지 않은 결정이었을텐데 대단하다는 생각이 들었다. 참고로 중복 제거는 Redis + 해싱값을 이용하셨다고. 역시 프로젝트 규모가 커지고 다양한 트래픽이 들어오게 되면,  커스터마이징이 필요해지는 것은 어쩔수 없나보다.

 

worker 에서 발생하는 아웃라이어 지점을 파악하고, 어떤 부분이 문제인지 직접 확인해봤다고 한다.

sender -> FCM 부분에서 timeout limit 이 제대로 먹히지 않아 리밸런싱이 종종 발생했고, 이 부분에서 굉장한 latency가 발생하여 TimeLimiter를 따로 개발했다고 한다. 좀 의문인 부분은, 왜 timeout limit 이 제대로 먹히지 않았는지이다. 사실 이것만 제대로 먹혔어도, 이러한 개발 리소스가 들진 않았을텐데 말이다. (내가 놓친 부분 같기도 하고, 내가 해당 도메인 로직을 잘 몰라서 엉뚱한 소리를 하는 걸수도..)

 

그 외에는 불필요한 요청 제거, 비동기적으로 동작해도 되는 부분들은 비동기 이용 으로 개선한 내용들이었다.

발송결과를 기다리고 푸시를 할 필요 없이, 발송-> 푸시로 바로 이어지도록. (실패한 발송은 DLQ 에 쌓고 다시 전송되도록)

나도 지금 맡고 있는 과제에서, 이벤트 누락 방지를 위한 DLQ + 동기로 인해 느릴 것으로 예상되는 부분을 비동기로 변경 + 트랜잭션 관리 쪽에 대해 고민하고 있었는데 이렇게 해당 부분을 듣게 되니 반가웠다. 비동기는 진짜 양날의 검인 것 같다. 빨라지지만 관리하기가 좀 어려운... 공부를 열심히 해야겠다.

 

결과적으로 목표였던 `파티션 수 줄이고 트래픽 3배 견디기` 에 성공하셨다고.

(참고로 늘어난 파티션 수를 줄일 수 없기 때문에 카프카 새로 생성하여 active <-> standby 갈아끼우기 방식으로 잘 하셨다고 한다.)

---

 

Aurora MySQL Version 3  업그레이드의 모든 것

DB 쪽에 관심이 있어서 들어본 세션.

아마 거의 이해하지 못할 것이다~ 라는 생각으로 들어갔고, 실제로 대부분 이해하지 못했다.

 

우리 팀 내에서도 오로라 버전업을 진행했기 때문에, 버전업을 하면서 달라진 부분들이 무엇이 있을까 궁금하여 들어봤다. 

그런데 업그레이드 과정 내용이 주를 이뤄서,,, 사실 잘 이해하진 못했다. (이해라기보단, 이러한 파라미터들이 있구나... 신기하다 하면서 들음ㅋㅋㅋ)

업그레이드 과정은 여러 가지가 있다.

version up 과정 방식은 여러 가지가 있는데,

DBA 님은 블루그린 배포를 선택하셨다고 한다. 

In-place 방식은 처음 들어보는데, 그냥 호스팅돼있는 db를 바로 버전업하는 방식인 것 같다.

 

파라미터들

버전업하면서 신경써야 하는 파라미터들이라고 한다.

버퍼사이즈, 트랜잭션 여부, 병렬진행여부 등인 것 같다고 생각이 들었다.

사실 대부분 잘 뭔지 모르겠었다.

 

가장 중요한 옵션은 internal_tmp_mem_storage_engine=memory 라고 한다. 

이 옵션이 뭘까 하고 https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine 를 좀 찾아보았다.

temptable, memory 두 가지 옵션이 존재하며, temptable 을 설정하면 말그대로 temporary table 엔진을 사용할 수 있다고..

 

근데 솔직히 잘 모르겠다.. 나중에 아래 글들을 정독해봐야겠다.

https://surgach.tistory.com/135

Aurora3.0 Mysql 8.0 TempTable engine 동작 이해

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/ams3-temptable-behavior.html

Aurora MySQL 버전 3의 새로운 임시 테이블 동작 - Amazon Aurora

 

temptable이 기본 옵션인 것 같고, 더 효율적인 스토리지를 사용할 수 있는 것으로 보인다. 하지만 메모리 풀 오버플로가 발생할 확률이 높은 것 같기도 하다. ( << 이건 내 뇌피셜이고, 이 부분 아예 모른다. 혹시 이 글 보시는 분들은 참고하지 마시길!!)

 

Real MySQL 책을 좀 읽어야될텐데..

 

 

블루그린 업데이트 시에 주의해야 하는 파라미터들

 

사이즈가 큰 테이블을 작업할 때에는 위 파라미터들을 신경써야 한다고 함.

허허, 우리 쿠폰 쪽 작업할 때에도 꽤 고생하셨겠군.. 싶었다.

 

 

 

업그레이드 효과.

I/O 쪽 성능이 꽤 좋아졌다고 한다.

 

사실 아직 DB 버전업으로 인한 큰 성능차이 체감은 못하긴 했다. 일부 slow 쿼리는 되게 빨라졌고, 일부 slow 쿼리는 그대로이고..

하지만 버전업 자체는 굉장히 중요한 부분이라고 생각한다. 새로운 기능들, deprecated 제거, 성능 업데이트 등 모든 면에서 버전업을 해서 실이 되는 건 하나도 없다는 것을 많이 느꼈어서.. 이번 버전업에 열심히 해주신 스토리지개발팀 분들이 너무나도 감사할 뿐.

 

나중에 저 파라미터들은 Real MySQL 공부할 때, 그리고 DB 깊게 파고들 때 다시 한번 들여다봐야겠다.

그리고 어느정도 지식이 생기면 이 세션은 유튜브로 다시 한 번 보는걸로!

---

배달 데이터를 활용해 최적의 지역 클러스터링하기

학교 졸업프로젝트에 LLM을 녹여야 돼서, 그리고 요즈음 인공지능이 교양지식마냥 굉장히 중요해져서 들어보게 된 세션.

오, 근데 생각보다 매우 재밌었다!

공간모델을 언어모델과 유사하게 다루어 클러스터링한 내용인데, 마침 내가 공부하고 있는 쪽이 언어모델 LLM 쪽이라 개꿀!!

 

라이더분들이 다음 배차를 받을 때를 벡터화하여, word2vec의 skip-gram 모델을 이용해 지역 별 관계매핑을 하는 내용이었다. 마침 word2vec 이용하여 특정 단어간의 상관관계를 뽑아내야 하는 졸업프로젝트를 하고 있었는데 넘 재밌게 잘들었다.

확실히 일이 아닌 교양으로 공부하면 재밌나보다 ㅋㅋ

 

사실 다익스트라와 같은 그래프 이론 알고리즘들이 꽤 나올줄 알았는데, 다행인지 불행인지 그런 내용은 1도 없었다.

 

클러스터링 결과값을 받은 서버개발자분이 어떻게 백엔드 작업을 하시는지도 소개해주셨는데, 이 부분도 좋았다.

 

• 클러스터링 지역 + 도메인지식(서비스가능/불가능지역) = 최종보완지역
• 주피터로 클러스팅한 결과 지역을 S3에 넣고, aws 아테나를 이용하여 추출 후 백엔드 db 이용
• 지역의 최신변화는, 서비스 지역변경 이벤트를 kafka로 수신. 배차시스템에서 배차지역db, 서비스지역db 동기화.
• 미세한 수정은 지역어드민으로 관리.

 

앞으로도 AI 는 활용성이 무궁무진하리라 생각하는데, 그렇기 때문에 나도 ai 개발자분들과 협업할 일이 많을 것이라 생각된다.

그러한 면에서, 서버개발을 ai개발과 어떻게 협업하는지의 포인트는 알아두면 좋을 것이라 생각이 들었고 실제로 이번 세션을 통해 어느정도 궁금증이 해소됐다. (평소와 거의 비슷하나, 이용하는 인프라 툴이 조금 다를 뿐이란 생각이 들었음.)

 

나중에 언젠가 ai개발자분들과 협업하는 기회가 생겨도 좋겠다 싶다.

그리고 LLM, 이거 좀 더 공부해봐야겠다.

마침 DAN24 컨퍼런스(https://dan.naver.com/24/sessions)에서 LLM 내용이 엄청 많이 나오는 것 같다. 해당 컨퍼런스 열심히 들어봐야지.

---

우아한 데이터허브

사내에서 프로젝트할 때, 우아한 데이터허브 쪽과 소통할일이 꽤 있다.

그래서 우아한 데이터허브 쪽 아키텍처도 알아두면 좋을 거 같아 해당 세션을 들어보았다.

굉장히 많은 데이터량을 처리하는 데이터허브

 

예상은 했지만... 우아허브에서 정말 많은 데이터를 처리해야됐다.

분당 700만건의 데이터라니. 하루에 100억건의 데이터인 셈이다 ㅋㅋ

 

 

 

아키텍처가 위와 같았다.

데이터 통합 쪽에서는, 우아한 데이터허브에서 사용하는 kafka, consumer가 존재한다.

이렇게 될 경우, 각 도메인에서 kafka와의 의존성이 생겨버리게 된다. 따라서 우아한 데이터허브에서는 중간에 publisher를 두어 각 도메인 서버 측에서 publisher layer를 의존하게 했다. 추상화의 장점을 챙긴 것. 

 

우아한 데이터허브 세션을 쭉 들으면서 느낀 점이기도 한데, 허브 개발자분들.. 추상화를 정말 잘하고 추상화에 미쳐있다! 라는 점을 느꼈다. (내가 잘못 느낀건가 싶기도 한데, 일단 나는 세션을 들으면서 우아한 데이터허브가 추상화가 엄청 많이 이루어져있다고 느꼈음.)

그렇게 생각한 이유는 데이터 처리 쪽 때문이기도 한데, 이 쪽에서 처리해야 하는 내용은 아래와 같다.

 

• 수많은 task들이 존재한다.
• 각각의 task들은 연관관계가 존재한다. 해당 task의 결과에 따라 다음 task 실행 여부를 결정짓게 된다. 
  • 즉, task 간의 관계가 DAG 를 그린다. (위상정렬, dp를 떠올렸다면 당신은 ps변태입니다..)

 

따라서 각 task들을 @Service 빈으로 등록하고, 외부 객체에서 이 빈들을 주입해주었다고 한다. 일종의 전략패턴을 이용한 셈.

각 task들의 순서는 yml로 관리한다고.

내가 개인적으로 좋아하는 아키텍처여서 그런가, 굉장히 잘 관리되고 있구나 싶었다. 

 

 

 

데이터 저장 쪽에서는 샤딩&파티셔닝 얘기가 주를 이루었다.

aws 서비스에 따라 일부 서비스에는 DB 단의 파티셔닝이 지원되지 않아 애플리케이션 단에서 구현했다고 한다.

그런데 데이터허브는 쿠폰도메인, 주문도메인, 회원도메인, 선물도메인 등 다양한 도메인의 엔티티가 존재할텐데 어떻게 관리하지? 싶었는데, 각 도메인 별로 개발자분들이 직접 파티션번호를 지정하고 꼼꼼히 관리했다고 한다. 각 엔티티마다 도메인이 달라 중복key가 없어서 어쩔수 없었다고.. (흑흑 고생많으십니다.)

파티션 별로 어떤 샤드에 담을지는 look up table을 참고하는 directory-based 전략을 이용했다고 한다.

만약 트래픽이 몰려서 특정 샤드에 부하가 몰릴 경우를 대비해, back pressure 역할을 해주는 `데이터 통합` 쪽에서 이벤트 컨슘 속도를 조절했다고 한다.

 

 

데이터 조회 쪽에는 네트워크 얘기가 주를 이루었다. 

나는 json 밖엔 이용을 안해봤는데, 데이터허브 관리 시에 json 외에 protostuff, gRPC 등 다양한 선택지를 고려한 것 같다. 사실 이 부분은 잘 이해하지 못해서, 많이 적질 못하겠다.. json 외에 다른 포멧을 이용하는 케이스가 상상이 잘 안된다. (하더라도 gRPC?)

RPC 기반 통신은 우아콘 2023에도 언급된 적이 있다. (후기글: https://kth990303.tistory.com/468)

그런데 그 이후로도 나는 json만 다뤄가지고..ㅋㅋㅋㅋㅋㅋ 이번에도 RPC 내용은 뭔소린지 모르겠는 상태로 들었다 허허. 

---

마치며

아, 공부 좀 해야지.

근데 클라이밍도 하고싶고.

어떡하냐~