토스 SLASH 24 후기

개요

탄탄한 기술 테크 기업인 토스의 컨퍼런스에 참석한 후 받은 인상을 스케치하듯 정리해본다.

행사 개요

• https://toss.im/slash-24
• 일시: 2024년 9월 12일 목요일 10:00-17:00, 오전 9시 30분부터 입장 가능
• 장소: 삼성동 COEX 그랜드볼룸

아키텍처의 핵심, 카프카

많은 발표에서 아키텍처를 이야기할 때에 카프카가 등장했다.

아키텍처를 동기적으로 처리되는 강한 일관성(strong consistency)과 결과적, 최종적 일관성(eventual consistency)로 구분하고 최종적 일관성으로 충분한 지점의 핵심을 카프카가 담당하는 것이다.

메시징 시스템은 충분히 시간을 투자하여 공부해둘 가치가 있는 영역이라 생각하고 카프카는 입문하기에 나무랄데 없는 제품이다.

외화 예금 트랜잭션 아키텍처 소개

고객의 빠른 경험이 필요한 부분은 동기적으로 구현하고, 은행 내부의 결과적 일관성으로 충분한 부분은 카프카를 이용했다.

동시성 제어가 필요한 부분에서는 레디스 분산락을 사용하였다 하며, 여러 작업을 동시에 실행하여 결과를 받아와야 할때는 코틀린 코루틴을 이용하여 레이턴시를 낮추었다. 한다.

메시지 브로커의 선택

토스증권에서 polling 으로 주기적으로 데이터베이스를 조회하던 부분을 이벤트 발생시에만 SSE를 이용해 고객에게 알리는 방법으로 개선을 하였는데 이때 이벤트를 전달하는 부분에서 메시지 브로커의 선택을 고민하였는데 최종 결정은 NATS 였다. Redis Pub/Sub에 비해 throughput 이 60k → 300k 로 5배에 달했다. 물론 이러한 선택은 도메인, 요구사항의 특성을 고려하여야 한다.

Apache Kafka

기본적으로 at least once이며 exactly once도 지원가능

대규모 데이터 스트리밍 처리에 적합하며, 메시지를 브로커에 저장해 재처리가 가능하다. 순서 보장을 하면서 높은 처리량을 제공하고, 내구성이 뛰어나다. 데이터 파이프라인, 실시간 로그 수집, 대규모 이벤트 스트리밍 처리에 적합하다.

Redis Pub/Sub

at most once 이다. 유실 가능성이 있다는 말이다.

인메모리 기반으로 매우 빠른 메시징 처리를 제공하며, 영속성이 필요 없는 비동기 통신에 적합하다. 단순한 실시간 메시지 처리에 강하다. 실시간 채팅, 알림 시스템 등 즉각적인 응답이 필요하지만 영속성이 필요하지 않은 경우에 사용한다.

NATS

at most once 이며, JetStream을 통해 at least once 도 가능하다.

경량화된 메시지 브로커로, 매우 낮은 지연 시간과 높은 성능을 제공한다. 설정이 간단하고 클라우드 네이티브 환경에서 유연하게 확장할 수 있다. 마이크로서비스 간의 고성능 저지연 메시징이 필요한 경우에 적합하다.

테스트의 자동화

c 언어로 작성되어 있는 거대한 모놀리스 레거시를 Kotlin MSA로 조금씩 전환하는 중인데 전체 프로세스중에서 테스트가 개선할 점이 많아 자동화를 하였다 한다. 같은 요청에 대해 레거시와 새로운 시스템이 동일하게 동작하는지를 검증하는 것이다.

읽기 요청 테스트는 쉽다

1. 레거시로의 요청을 녹화
2. 어드민 페이지에서 테스트할 호출을 선택하면 해당 요청을 새로운 시스템으로 보내고 결과를 확인한다.
3. 주기적으로 슬랙 메시지로 테스트 결과를 리포팅한다.

상대적으로 복잡한 쓰기 요청 테스트

부하가 큰 테스트이므로 자주 할 수 없고, 프로덕션 환경에서는 사용할 수 없다.

1. 요청을 새로운 시스템으로 먼저 보내고 결과를 레디스에 저장한다. 이후에 이 작업을 롤백한다.
2. 다시 요청을 레거시로 보내어 응답을 레디스에 저장된 결과값과 비교한다.

시간을 조정해야 하는 테스트

대출 상품의 1년 뒤를 시뮬레이션하여 테스트를 하여야 하는 경우등이 있다.

• 운영DB, 테스트DB 에서 복제를 빠르게 떠서(3분 이내) 테스트 환경에서 시간대를 바꿔가며 테스트 한다.

서버 개발자의 영역은 어디까지인가?

테스트 자동화에 대한 발표도, 심지의 인텔 하이퍼스레딩 환경에서의 성능문제를 다룬 발표도 발표자가 서버 개발자였다. 직함만 서버 개발자일 수도 있겠지만, 토스가 단순히 자신에게 할당된 일을 하는 것이 아닌, 회사가 당면한 문제를 해결하는 목적지향 조직이어서가 아닐까 생각이 들었다.

덧붙여서, 외환 서비스라는 만만치 않아보이는 서비스를 5명이서 6개월만에 성공적으로 런칭했다는 이야기를 듣고 한국의 개발조직들에 많은 영감을 줄 수 있겠다 싶었다.

고객 우선

일반 은행권은 잠깐이라 하더라도 자정에는 잠시 거래를 멈춘다고 한다. 하루 동안의 모든 거래를 가져와서 맞아떨어지는 지를 체크하는 것이다. 토스는 이 찰나조차 집중하여 24시간 365일 무중단으로 처리할 수 있도록 시스템을 구성하고 보상조치를 통해 해결했다.

WebSocket과 SSE(Server Side Event)

HTTP와 달리 연결을 오래 유지한다는 측면에서 두 기술은 닮았지만 WebSocket은 양방향, SSE는 단방향이라는 차이가 있다. 토스는 두 기술을 상황에 맞게 아키텍처 여기저기에 잘 활용하고 있었다.

분산 트랜잭션 - SAGA 패턴

하나의 데이터베이스에서의 트랜잭션은 간단하다. 하지만 여러 이유로 분산환경을 선택하면 이러한 분산환경에서 분산 트랜잭션을 구현하여야 한다. 토스는 2PC(two phase commit)과 SAGA 패턴중에서 자신들에 맞는 (Orchestrator) SAGA 패턴을 선택하였다.

중요한 핵심 키워드중 하나는 보상이었다. 모든 것을 완벽하게 처리하려면 그만큼의 성능 손실을 감수해야 한다. 성능을 선택한 다음 자주 발생하지 않는 오류에는 그에 대한 보상을 해주어서(예: 잘못해서 만원을 덜 드렸네요, 늦게나마 만원 넣어놓았습니다.) 해결하는 것이다.

콘웨이 법칙 - 조직과 제품이 상관관계

개발을 하다보면 다양한 법칙들을 만나게 되고 그렇구나 하고 넘어가게 된다. 콘웨어 법칙도 그 중 하나인데 언듯 식상하게 느낄 수도 있겠다.

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” — Melvin E. Conway (1967)

“어떤 조직이 시스템을 설계할 때, 그 조직이 만든 설계는 그 조직의 의사소통 구조를 복사한 형태가 된다.” — 멜빈 E. 콘웨이 (1967)

 

하지만 때로 아키텍처 속의 소통을 고민할 때에 이를 만드는 조직의 구조를 그 목표에 맞게 변화시키는 게 답일 수 있다. 토스는 이를 실천해보았고 성과를 얻었다 한다.

정리

발표자들이 (아마도) 모두 토스 개발자 분들이고, 토스의 기술 여정이라는 공통 주제를 다루는데다 발표의 품질, 톤앤매너가 한결같다는 인상을 받으며 즐겁고 편하게 들을 수 있었던 컨퍼런스 였다.