[SLASH 24] Toss : No Limit 컨퍼런스 후기

 

최근 생각해 보니 컨퍼런스를 다녀온 후, 후기를 안 남기고 있었던 것 같아?(ex 인프콘 24) 오늘은 보고 온 당일 후기를 남겨볼까 한다.

추가로 회사 동료분들에도 내가 느낀것을 공유하고 싶다!

해당 후기는 모든 세션의 기술 내용을 기술하는 것 이 아니라, 제가 영감 받은 부분만 적어두도록 하겠습니다!

 

1. 신청부터, 당일 도착까지!

1-1) 사전 신청

오??? 드디어?? 내 힘으로 당첨돼서 가보는??

이전까지 대부분의 컨퍼런스에 지원만 하면 탈락하는 극악 확률의 남자였는데 ㅋㅋㅋ 이번에는 추첨 결과 대상자가 되었다!
크크 회사 다니며 해당 컨퍼런스 날이 오기를 손꼽아 기다리고 있었다 크크

 

특히, 이번 컨퍼런스는 Toss의 첫 오프라인 기술 컨퍼런스라 IT업계의 종사자라면 다들 큰 관심이 있었을 것 같다.

 

그도 그런 것이 ㅋㅋ 컨퍼런스 장에서 지인만 6명 만난 것 같다!

같이 부트캠프 했던 동기나, 학교사람, 회사 사람, Nexters 동아리 사람, 기타 등등 ㅋㅋㅋ

개발에 관심 있는 대부분의 사람들이 와있었던 것 같다! 항상 느끼지만 개발판은 좁다!

 

추가로, 이번 컨퍼런스에 편하게 참여하도록 배려해 준 회사에도 감사함을 꼭 전하고 싶다!

 

1-2) 당일날

약 10시쯤 도착했던 것 같은데, 이미 사람들이 줄을 서서 QR을 등록하고, 명찰을 받고 있었다!

 

명찰을 받고 들어가는데 익숙한 회사 동료분이 보였는데 ㅋㅋㅋ 조은이 VIP 줄에 있으셨다!

크크 바로 가서 인사를! 군기가 바싹 들어있는 나였다(?), 사진이 없어 아숩....

 

들어가자마자,  데스크에서 명찰을 보여주면 Welcome Gift를 주었다!

내용물로는, (우루샷(20정) + 물 + 키링 + 스티커)를 받았다!!

예전 같았으면 다른 기업 부스도 돌면서 이벤트에 참여했을 텐데, 올해는 그냥... pass.... 

도착 후 시간이 거의 다 되어, 바로 첫 세션부터 입장하게 되었다!!

 

2. 세션 시작

2-1) 리플레이 검증으로 새로운 금융 시스템 안전하게 도입하기

해당 세션에서는 차세대 원장시스템을 구축하면서 경험하신 내용을 공유해 주셨다!

기존의 C기반의 Monolithic 한 원장 시스템을 -> Kotlin 기반의 MSA 원장으로 전환하면서 경험하신 내용인 것 같다.

 

원장시스템을 개발하시면서 (테스트 -> 검증 및 확인)의 자동화를 위해 Read Verifier, Write Verifier라는 구조를 만들게 된 것에 대한 내용 공유이었다.

 

▶ Read Verifier : Read API 검증 자동화 + API 호출을 비동기로 리플레이

대충 다음과 같은 그림 구조였는데, 

요약하면 신규 서버의 read 반환값 비교를 위해,

4번에서 C기반의 원장 서버의 response를 반환 + Verifier로 전달하고

5번에 사용자의 요청을 동일하게 신규 원장서버로 보낸 후,

6번에서 해당 신규 서버의 응답값을 반환해 주면

 

해당 2개의 값을 비교하여 동일한 응답인지 확인하는 구조였다!

오!! 대단하다...라는 생각과 동시에, 어디서 저런 아이디어를 얻었을까? 란 생각을 했고!

내 지식 기반을 돌이켜 본 결과 RSA 암복호화 과정에 비슷한 아이디어가 있음을 깨닫게 되었다!

 

물론 해당 기술팀이 RSA 복호화 과정에 착안한 것 인지는? 모르지만

나는 원본 요청을 전달하면서, 생성된 결과와 최종적으로 비교한다는 점이 RSA복호화 과정과 유사하다 생각하였다!

위 사진에서 5번의 생성된 해시값과 기존 해시값을 비교하는 과정이 Verifier와 유사하다 생각

 

 

▶ Writer Verifier : 직전의 Read Verifier의 효과가 좋음을 보고, Write Verifier도 도입하고 결정하였다고 한다.

Write를 할 때는 우선적으로 신규 원장서버에서 결과를 생성한 후,

해당 결과를 Redis에 저장하고 + CUD 쿼리를 R쿼리(조회)로 변환하여 저장한다.

이때 ANTLR이라는 CUD를 분석하여 조회 쿼리로 변환하는 과정이 매우 신기하다고 생각하였다!

GitHub - antlr/antlr4: ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, exe

 

추가로, 위 그림에서 4번 응답을 하기 전에 Kotlin MSA 원장 서버는 해당 요청을 Rollback 한다고 한다.

-> 즉, Writer Verifier는 개발 환경에서만 사용한다고 하였다!

 

2-2) Next 코어뱅킹, MSA와 MySQL로 여는 평생 무료 환전 시대

기존의 뱅킹서버를 MSA화 하였지만, 아직 DB만큼은 단일 Oracle을 공유하고 있다는 문제가 있었다고 한다.

물론 각 마이크로 서비스마다 독립된 OracleDB를 할당할 수도 있지만, 라이선스의 금전적 문제로 어려운 방법이라 생각하였다고 하셨다.

 

따라서 원화는 아직 Oracle이지만, 외화는 모두 MySQL을 사용하는 방식을 선택하였다고 한다.

 

이중 외화예금 Tx 아키텍처에 대하여 조금 더 정리하면 다음과 같았다!

잘 안보이는...

외환서버(MySQL) -> 수신 외화예금 서버(MySQL) 이 고객 관련 부분에 해당되는 내용이었다.

 

즉, 앞단에서 환전거래를 할 때 다음과 같은 과정을 거친다고 한다.

로직의 흐름은 다음과 같다.

 

1. 환율 확정 (외환 서버)

2. 수신 원화예금 서버에서 차감

3. 수신 외화예금 서버에서 증감

4. 외화 손익 처리

5. 회계 처리

6. 총계정원장 처리 (계정계)

 

여기서 배울 점은,

기존의 레거시 Core Bank였다면, 위 1부터 5까지의 과정을 하나의 Transaction으로 구성했어야 했을 것이다.

하지만 (1,2,3) - 카프카 - (4) - 카프카 - (5) - 카프카 - (6)의 과정을 통해 서로 간의 의존성을 줄이고, 분리된 Tx를 적용할 수 있었다고 한다! DB를 분리하면서 서비스를 분리한 점의 장점이 여기서 오는것 같다!

 

그만큼 기존의 DB가 아닌, Application의 SAGA패턴과 같은 다양한 Transaction보증 방법들이 등장한것이 도움됬을것 같다?

 

또한 모두 동기식 호출이라 그만큼 느렸는데, 이 또한 Corutine을 활용한 비동기 처리를 통하여 Latency를 많이 줄였다고 한다!

 

사실 다음 내용이 더 나에게는 재미있었는데!! 다음과 같다!

 

▶ 00:00 시에도 무중단 환전 서비스를 구현하는 방법

다들 00:00분 근처 때 은행앱을 사용해 봤다면, 거래가 막히는 시간이 있음을 경험해 본 적 다들 있을 것이다!

 

이는 잔액대사, 즉 전일자 고객 잔액과 은행 계좌의 잔액을 모두 비교하여 동일함을 보증하는 작업인데...

문제는 이 시간에 전일자의 정확한 잔액이 필요하기 때문에

1. 00시 근방에 거래를 막고

2. 전일자 SnapShot을 만들고

3. 이를 은행계좌와 비교

 

하는 방법이 이전까지 사용되었다고 한다.

 

그럼 Toss는 이를 어떻게 해결하였을까? 간단하게 요약해 보면

 

1. 00분에 전일자 Snapshot 테이블을 일단 만든다.

2. 00분 이후의 거래내역을 확인한다.

3. 2번의 거래내역으로 역연산 하여 1번에서 구한 SnapShot을 보정한다.

 

오?? 3번 아이디어가 나에게는 큰 신선함으로 다가왔다!

단순한 더하기 빼기의 스토리 같지만.. 나는 생각 못해봤을 것 같으니 말이다..

 

추가로 3번째 방법도 알려주셨는데, Hadoop을 이용하면 된다는 것만 기억난다... 나중에 영상 나오면 다시 봐야지....

대충 아예 별도의 테이블 만들어 관리한다는 내용이었던 것 같다?

 

▶ 성과

실시간으로 3000 TPS를 받음

가장 빠른 환전: (기존 원화 송금의 경우 평균 한건당 280ms → 30ms로 빨라짐) 무려 10배 가까이 개선

 

2-3) 미처 알지 못했던 Kernel까지 Observability 향상하기

사실 다른 부분보다 해당 세션이 기억에 남는 이유는, 학교에서 OS시간에 배웠던 numa 아키텍처 내용이었기 때문이다!

간만에 공부했던 ppt자료를 찾아보니 남아있었다!!

SMP와 NUMA 아키텍처

 

확실히 알고 있는 내용이라 더욱 다가오며 + 기억에 많이 남는 것이 사실인 것 같다.

 

위 그림의 NUMA(Non uniform memory access)에서 알 수 있듯,

NUMA는 CPU에서 memloc()호 출시  1, 2번 메모리 중에 할당하는데, 문제는 물리적으로 거리가 달라 생기는 지연이 있다는 것이 문제이다.

 

이를 토스에서는 어떻게 해결하였을까?

 

일단 모니터링을 위해 ebpf를 사용하여 cpu사용률을 분석하였다고 하셨다.

eBPF - Introduction, Tutorials & Community Resources

리눅스 커널에서 일어나는 다양한 이벤트들에 대해 사용자 정의된 함수들이 커널 내 샌드박스 환경에서 동작하게끔 하는 기술인 것 같다.

 

▶ 기존에 numa가 얼마나 영향을 주는지 확인하기

우선 진짜 numa의 영향을 받는지 확인할 필요가 있다고 하셨다.

이를 ebpf로 확인한 결과, numa migraion으로 1초에 약 50ms를 cpu 스케쥴러가 소모하고 있었다는 점이다.

ebpf지표를 보면 local dram, remote dram의 접근 횟수를 확인할 수 있다는 점도 놀라웠다.

이를 통해 numa의 영향을 확인해볼 수 있었다

 

▶ numa를 kubernetes에서 해결하는 방법

1. cpu pinning으로 메모리가 사용할 cpu 고정하기.

근데 상식적으로 CPU를 고정할당 해버리면, 더 많이 사용하고 싶은 쪽에 사용량이 제한될 수 있을 것 같다?

 

2. memory pinning

역으로 사용할 메모리를 고정하는 방식인데, 단점으로는 내부적으로 socket을 사용해서 pinning을 유지해야 한다는 단점이 있다.

그럼 socket을 이용하는 오버헤드는 적으려나?, 이부분에 대한 언급이 조금더 있었으면? 이라는 생각이 남았던 것 같다.

 

여하튼, 전체 클러스터의 cpu 사용률이 13% 향상되었다고 한다!

 

3. 끝으로~

위에는 좋은 내용만 가득 했는데... 아쉬운 점도 적자면?

 

1. 급한 세션 진행? 20분이라?
세션당 시간이 20분이라 그런지, 연산자들이 발표를 정말 급하게 하는 느낌이 들었다.
동영상 강의였다면 모를까? 일부 빠른 속도로 진행한 세션 진행은 이해도를 낮췄던 것 같다??

2. 한 세션에 다양한 주제?
언급할 수는 없지만, 특정 발표 주제를 보면 제목은 분명 aaa에 관한 내용인데,
다 듣고 나면 bbb라는 내용으로 끝나있다… 응? 뭐지? 싶은 발표도 있던 것은 사실이다?

 

 

이외 더욱 재미있는 내용들이 많았지만!

모든 내용을 여기다 기술하는 것이 이번 글의 목적은 아니기에!

이번 글의 목적은 뇌리에 스치는 것들을 빠르게 기록하는 것이 목적이었기에! 이쯤 되어 글을 마무리할까 한다!

 

이번 컨퍼런스에서 배운 점이 많아 좋은 것 같다!

추가로 같이 세션을 들어준 회사동기 레오에게도 고맙다는 말을 전해주고 싶다!!

 

얼마 안 있으면.. 우리 회사의 콘퍼런스가 열리는데! 그때도 많은 내용을 남겨보도록 하겠다!