[당근] 당근 테크 밋업 2024 후기

 

이번에 내가 다니고 있는 당근에서도 "당근 테크 밋업"이라는 이름으로 첫 오프라인 컨퍼런스가 열렸다!

 

원래는 당일날 후기를 남겨볼까 했는데 ㅋㅋㅋ 밋업 끝나고 회사로 와서 남은일을 처리하느라 ㅋㅋㅋ 당일날 못 남겼다... ㅠ,ㅠ

이번 주말에도 후기를 안 남기면 결국 작성을 안 하게 될 것 같아.... 윽!

주말 아침에 커피 한잔의 여유를 부리며 후기를 남겨본다!

항상 그래왔듯, 내가 영감을 받은 부분에 대해서만 후기를 작성해 보겠다.

 

1. 당일 도착!

1-1) 입장

정확히 10시 30분에 컨퍼런스 장에 도착하였다! 

 

사원의 경우 사원증을 들고 가서 직원용 출입증으로 교환하는 방식으로 입장할 수 있었다!

바로 가서 자신감 있게 사원증을 제시하였고(??) 입장 명찰로 교환받을 수 있었다!

 

입구에 보니 우리 커뮤니티 실의 Lydia, Reo, Louie가 있어서 반갑게 인사를 하고 컨퍼런스 룸 쪽으로 입장하였다!

아참, 이번에는 조은에게 경례도 할 수 있었다 ㅋㅋㅋㅋㅋ

 

1-2) 네트워킹 세션

첫 세션의 시작이 12시부터 이지만, 내가 이렇게 1시간 30분 일찍 온 이유는!

바로, 11시부터 내가 주인공이 되어 "동네생활"이라는 주제로 네트워킹을 하는 세션을 열었기 때문이다!

 

뭔가? 아무 준비도 안 해서 가면 30분이라는 시간이 긴 시간처럼 느껴질까 봐...

미리 11page 정도의 PPT자료를 준비해서 갔다!

 

크게 다음 2가지를 중심으로 논의해 보면 좋겠다 생각하면서 PPT를 만들었다!

1. 동네생활의 목표, 다만 전사의 목표라기 보단 우리 팀이 지금 생각하는 목표를 공유해드리고 싶었다!
2. 개발자들의 모임인 만큼, 팀에서 사용하는 서버의 기술에 대한 논의도 해보고 싶었다!

 

대부분 청중으로 컨퍼런스에 참여해 왔던 내가, 조금 더 주도적인 주체로써 컨퍼런스에 참여할 수 있던 좋은 경험이 되었다고 생각한다!
어쩌면 이번 컨퍼런스에서 나에게 가장 큰 경험이 돼준 시간이었던 것 같다!

---

2. 세션 시작

다행히 사전에 발표 PPT를 공유해 주신다고 공지를 해주셔서, 이전 Toss SLASH 컨퍼런스 처럼 듣는 동안 타이핑을 계속 치지 않아서 좋았다! 내용만 잘 듣고, 블로그에 정리할 때는 PPT를 참고해야겠다 생각했다!

 

2-1) 우리 동네 어디까지 좁아지는 거예요? (Geo)

 

해당 세션에서는 당근에서 "지역"이라는 기준을 어떻게 나누는지? 에 대한 내용을 공유해 주셨다.

 

"어디까지가 우리 동네인가?"

 

에 대한 질문을 시작으로 세션을 시작해 주셨는데, 해당 질문 하나가 나의 마음을 확 끌어당기는 역할을 해주셨다! 과연 우리 동네는 어디까지일까? Geo는 홍대를 기준으로 이를 설명해 주셨다!

 

정말 단순하게 행적적으로 명시되었있는, 가령 도로명 주소 라던가? 이런 부분만으로 당근의 사용자에게 적합한 "동네"의 개념을 제공해 줄 수 있을까?

 

나 또한 같은 고민을 해본 적이 있었고, 이에 대한 해답으로는 사용자가 살아왔던 사회적, 문화적, 감정적 연관성이 큰 영향을 준다는 점을 세션을 통하여 알게 되었다.

 

따라서, 당근도 행정동/법정도 의 범위를 충분하게 지원하고 있지만, 더 나아갈 방향에 대한 고민이 많았던 것으로 생각된다.

 

해결하는 개념 자체는 매우 간단하다!

(간단하다라고 생각한 이유는 나도 떠오를 정도의 방법이기 때문이다!, 다만 이걸 기술적으로 풀어가는 과정에서 로컬인텔리전스 팀의 영혼이 어느 정도 불탔을 점을 생각하면? ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ)

그렇다! 저 좁히면 된다! 여기 까지는 어쩌면 당연할수도?

 

그럼 한 가지 생각이 들어야 정상이다! -> 어떤 방식으로 더 줄일 건데??

 

▶ 우편번호 : 도심지역에서는 어느 정도 효과 있지만, 비도심 지역에서는 너무 지역 경계를 나누기 어려움. 또한 산간지역과 같은 곳은 너무 넓기도 해서, 진짜 땅의 경계만 나눠지는 경우라 효율적이지 못하다.

 

▶ S2, H3와 같은 격자 적용 : 

 

하지만 위 방식에서는, 지금 로컬인텔리전스의 목표인 HyperLocal을 달성하기에는 아쉬운 점이 3가지가 남아있었다.

1. 사람들이 인식하는 경계, Context를 포함시키기 힘들다는 점
2. Border Problem, 즉 경계가 진짜 6각형으로 나뉘기 때문에, 어떤 의미가 적용된 경계가 아님
3. 정확한 영역을 표시하기 위해선 더 많은 메모리가 필요하다.

 

또한 3번 문제, 많은 메모리가 필요하다는 점을 예전에 "가상 면접 사례로 배우는 대규모 시스템 설계 기초 2"라는 책에서 딱 봤던 내용이 바로 연관되어 생각이 나서 매우 신기했다.

 

확대 수준을 최대로 하여 21 depth까지 들어가면, 무려  440PB만큼의 공간이 필요하다.... 페타바이트 라니.......

기존의 방식은 더 작은 지역을 표현하기 위해 너무나 많은 메모리가 필요하다...

가상 면접 사례로 배우는 대규모 시스템 설계 기초 2

 

따라서 다른 방식의 접근이 필요했다고 하셨다. 따라서 로컬인텔리전스 팀은 다음과 같이 사람들의 인식을 사용하기로 하셨다고 한다.

 

▶ 사람들이 인식하는 경계를 기준으로 나눠봐요 (feat, 자연 경계)

 

자연경계(철도, 도로, 등고선, 녹지...)등의 데이터는 쉽게 구할 수 있었으며, 해당 데이터를 잘 overlay 분석만 잘하면 끝?

또한 경계 간 겹치는 부분은 중복제거를 하여 단일 영역으로 바꿔주는 작업 또한 진행되었다고 한다.

 

오? 해치웠나??? 그 결과는? 다음과 같다.

서초 4동 쪽의 도로인데;... 너무 엉켜서 복잡해져 버렸다...

이론상 추구한 결과가 나오긴 했지만... 조금 더 공간 특성이 필요할 것 같다... 특히 오른쪽의 사진을 보면... 음...

 

따라서 모든 영역을 개별영역으로 만들어 overlay 하는 작업을 통해 다음과 같이 구분되었지만, 아직도 경계 사이사이에 빈틈이 생겨났기에 이를 해결해야 할 필요가 있었다. 

(좌) 적용 전, (우) 적용 후

 

이 문제를 해결하기 위해 Voronoi Diagrma을 적용하셨다 한다. (나도 처음 듣는 알고리즘이라 설명은 패스하겠다...)

대략적으로? 각 건물들의 태두리를 점선으로 변경한후 점들간의 중심을 찾는 느낌이였다??

Delaunay triangulation - Wikipedia

 

따라서 다음과 같이 더 작은 HyperLocal을 적용해 낼 수 있었다.

단순하게 경계를 나눈 것 이 아니라, 사람들이 더 자주 사용하고 밀집된 곳일수록 세분하게 나눠지고, 강이나, 산과 같은 곳일수록 큰 덩어리로 분류되는 것을 확인할 수 있다.

위 사진의 왼쪽 광진구를 보면, 건국대 는 하나의 덩어리로 분류된것을 확인할 수 있다.

건국대 학생들은 학교라는 개념적인 공간 안에서 거래한다는 점이 잘 반영된것 같다!

 

그럼 이렇게 구해진 영역이 어떤 의미를 사용자에게 줄 수 있을까?

바로 "실제로 내가 갈 수 있는 영역을 구한다"라는 점에서 당근만의 특성을 살려주는 것 같다!

 

2-2) 멈춰버린 세계 (Jeremy, Heshy)

이번 발표에서는 네트워크 통신이 불가능 한 상황에서의 해결을 위한 당근 Pay팀의 여정에 관한 이야기였다.

 

어느 날 Redis에서 에러가 발생하고 있었으며, 이는 Redis Client인 Lettuce에서 Latency가 튀고 있는 현상 또한 관찰이 같이 되고 있었다고 한다.

 

근데 신기한 점은 Redis Server의 메트릭 자체에서는 별다른 변화는 관찰할 수 없다는 점이 핵심이었다.

 

원인으로 논의되었던 부분으로는

1. Application Thread 고갈?
2. JVM GC Pause Time 증가?
3. Redis, DB 장애?
4. AWS maintenance?
5. Core DNS 장애?

원인을 찾아가는 과정에서 Internal api 호출을 분리하면서, 기존 User의 트래픽을 모두 감당하던 서버 쪽의 트래픽을 상당량 줄이는 경험을 하셨다 했다 -> Application Thread 가 실질적은 사용자의 요청만 처리하니, 이전보다 고갈될 일이 매우 줄어들었을 것

 

ZGC를 도입하여 이전 GC대비 느렸던 부분을 개선할 수 있었다고 한다!

이를 통해 GC Pause Time은 확실하게 개선된 것 같다.

 

이건 세션과 관련 없는 여담이지만, 단순 JDK런타임 변경만으로 메모리 30%를 절감할 수 있다는 사실도 최근에 들은 적 있는데 남겨본다.
https://www.facebook.com/digimon1740/posts/pfbid02krzn2AZRHesQPYvMFZUCtbw4ct8qmVyyapBPk3iiy3ebF9UFVLRNeGFVK8z8H5GJl

이상훈

또한 쿼리를 개선하고, 이전보다 API Performance 또한 확실하게 증가된 것을 확인하셨다고 한다.

즉, 원인으로 생각되는 부분에서 나름 모두 개선이 이루어진 것이다.

 

그럼 해치웠나?

 

여전히 동일한 문제가 발생하고 있었다고 한다...

문제의 근본적 원인은 Istio의 Proxy에서의 CPU Limit 설정 때문이었음을 나중에 확인하게 되었다고 한다.

 

실제로 부하테스트를 통해 CPU 사용량이 증가한 상태에서, 배포를 진행하게 되었고, -> 네트워크 오류 발생 -> HTTP Latency가 급증하는 것을 확인할 수 있었다고 한다.

 

따라서 다음과 같이 CPU Limit을 삭제하면서 해당 문제를 해치울 수 있었다고 한다!

 

이후에도 뭐 추가적인 문제가 연이어 발생하셨다 했는데, 사실 마지막 말만 뇌리에 박혀서 남겨보자면!

1. 가시성은 빠른 문제 해결과 사후 분석의 기반이 된다는 점
2. 각 팀의 Load Paramter를 미리 설정해 둘 것, 간단하게 말해서 어느 정도 부하를 견딜 수 있는지 미리 수치를 파악해둬야 한다는 것이다.!

 

2-3) 지역기반으로 중고거래 검색을 샤딩하라 (Johnny)

ㅋㅋㅋ 아니 발표 너무 재미있게 하신다 ㅋㅋㅋ 중간중간 던지시는 말들이 나는 너무 웃겼다 ㅋㅋㅋㅋ

 

당근 또한 서비스의 크기가 크니 당연히 샤딩이 적용된 인프라들이 많다.

 

문제는 제주도에 있는 사용자가 단순하게 적용된 샤딩으로 인하여 서울의 인프라 장비에 request를 보네 오는 것이 문제의 시작이었다고 하셨다. 따라서 지역기반의 샤딩이 필요하다 하셨다.

 

해당 과정의 PoC 과정에서 대박 신기했던 점이 있다면 다음인데, 지도상에 적용된 상황을 mapping 하여, 특정 지역에서의 요청이 잘 군집되어 있는지 확인할 수 있었다는 점이다. 

 

다음 사진을 살펴보자! 빨간 박스 부분의 노란 지점은 샤딩이 잘못된 지점이라는 것을 지도로 한눈에 파악이 가능하다.

 

2-4) 당근 회원 시스템을 마이크로 서비스로 분리하기

 

마지막 세션에도 뇌리에 박히는 내용이 있었다! 재미있었던 세션이었다!

 

서비스를 분리하면, 기존의 서비스를 바라보고 있던 클라이언트는 신규 서비스를 어떻게 바라볼까? 앱 업데이트가 필요할 수 있다.

 

이련 경우 Istio proxy와 SideCar를 활용하면 된다!

클라이언트가 모노리스를 호출해도 트래픽을 신규로 이동시켜 주는 isto의 기능을 사용하는 것이다!

 

proxy를 통해 기존 모노리스로 온 요청을 신규 서비스로 전달해 준다는 점이 Nginx의 Revers Proxy의 역할과 비슷하다 생각하였다.

istio proxy도 결국 원하는 서버로 요청을 bypass해주는 것이 핵심인 것 같다.

 

한 가지 궁금한 점이? 그럼 모노리스의 응답과 신규로 개발된 서버의 응답이 동일한지 어떤 방식으로 검증하지?라는 생각이 들었다.

직전에 갔었던 Toss 컨퍼런스에서도 비슷한 문제를 해결하는 방법을 들었었기 때문이다.

 

당근에서는 이 또한 SideCar를 통하여 해결하였다.

 

예를 들어 기존 모노리스에서는 매너온도가 40.0 (float형), 신규 서버에서는 40 (Int형)으로 반환해주는 상황이었다고 해보자.

 

이런 경우 Sidecar에서 일단 기존 모노리스와 신규 서버에 동일한 요청을 전달하고, 양쪽에서 받은 각각의 Response를 비교하여 동일한 경우에만 반환하고, 위 에시처럼 다른 경우에는 경고등을 남겨 개발자가 처리 가능하도록 해준다고 하였다.

 

3. 끝으로!

이번 컨퍼런스는 (참가자 + 진행자) 2가지 경험을 모두 해볼 수 있었던 시간이었다.

나도 언젠가는 기회가 된다면 내가 해결한 문제를 많은 사람들과 공유하는 세션을 꼭 한번 진행해보고 싶다는 생각을 다시 한번 하게 되었다.

 

특히 이번 컨퍼런스는 네트워킹 세션이 잘 준비되어 해당 공간에서 그 열기를 느낄 수 있었던 점이 좋았다.

컨퍼런스장 입구 바로 앞에서 네트워킹이 이루어진 점이 좋은 영향을 줬다고 나는 생각한다.

 

피곤한 하루를 마무리하기 위해... 회사로 향하였고(???), 나도 주어진 일을 마무리하며 완벽한 하루를 경험할 수 있었던 것 같다!