후기

toss slash24 를 다녀왔어요. 저는 탈락했지만 당첨됐지만 못간 친구의 양도를 받았답니다.

제가 듣고싶었던 강의는 거의 Server 였지만 관심있는 devops도 중간중간 있었어요. 가보니 서버 듣는 곳이 제일 크고 사람도 많았어요. 이번에는 server, data, devops 위주였던 것 같아요. front는 제가 관심이 없어서 그런건지 강의는 많이 없었어요.

회사에서 이렇게 큰 컨퍼런스를 진행하고 발표할 수 있는 기회가 주어져서 지식을 나눌 수 있는 경험이 주어진 다면 정말 뜻깊겠죠? 저도 아직 많이 부족하지만 언젠가 그런 기분 느껴보고 싶네요.

생각보다 slash24 소개하는 대표 영상이 정말 멋있었어요. 다시 한 번 보고싶네요
컨퍼런스를 위해 많은 준비를 했다는게 느껴졌답니다.

아쉬웠던 점이 있다면 쉬는 시간 없이 연속으로 발표를 진행하는 게 몇몇 있었는데 중간에 듣고 오시는 분과 다른 발표 들으러 나가시는 분이 겹쳐져서 북적북적해서 초반에는 집중이 잘되지 않는 분위기였어요.

강의정리

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

1. 토스뱅크의 기술 전환 배경

   코어뱅킹 아키텍쳐 모놀리식 형태였다. 점진적으로 마이크로 형태로 변경 중이나 디비는 오라클 의존적이야

   오라클

   장점 금융업계 축적된 노하웅
   단점 단일장애지점 비싸요 제한적인 scale out

   → 대체! 트랜잭션 redis 분산락, kafka saga 패턴, 확장성 mysql replicairon, 안정성 mvcc 기술

• 고객관련 트랜잭션은 엄격하게 관리은행관련 kafka 비동기로 연결
• 고객은 빠른 출입금 처리를 보여주고 뒤에서 은행 동기작업을 한다!
• 입금 시 필수 검증 항목은 코루틴으로

T) No-Code Tool로 만드는 마지막 인터널 제품

• 노코드 중요 ! 하나의 제품으로서 완결성과 범용성 , 확장성
• 외부서비스에스 노코드 사용 : API, 웹훅 제공
• 노코드에서 외부서비스 제공 : 노코드 툴이 Proxy 역할

S) 생산성과 안정성 모두 잡는 마스터키, Canary 배포 개선기

• rolling update와 canary 배포전략 사용
• rolling update 이슈 발생 시 중단 불가 , 내부서비스 적합
• canary 외부 서비스 적합, 트래픽을 늘리는 배포 방식으로 이슈 발생 시 빠른 대응 가능
• 기존 canary 배포의 문제 -> page not found (진입점 페이지 분리배포는 생산성 하락 및 사람의 실수 생김!)
• sticky canary sticky session은 동일한 유저의 호출은 동일한 버전으로 적용될 수 있도록 (user -> ssr api gateway -> vs(어떤버전?) -> pod
• toss는 vivasystem을 만들어 es조회 에러로그 임계치/ log lag 만족하지 않을 경우 롤백하여 사용

단순히 배포 방식을 발전 시키는 것이 아닌 시스템 특징에 맞게 필요한 배포 방식을 선택하고 적용한 게 단순한 개발이 아닌 문제를 해결하는 개발자로 생각했음

O) 보상 트랜잭션으로 분산 환경에서도 안전하게 환전하기

• 2pc vs saga pattern 중 높은 가용성, 확장성을 위해 saga 선택했음

• 보상 트랜잭션이 필요로 한데 비동기로 했음

• 오케스트레이션 saga선택? 상태 관리가 필요해성

• 서비스 이슈 발생했을 대 kafka message scheduler 사용해서 지연시간과 함께 메시지를 발송해서 지연시간 뒤에 컨슘(?) 되도록 처리했다.

• 컨슈머 데드레터 브롴, 프로시져 데드레터 브로커 활용해서 eventually consistency 구현했다

• 듣는데 좀 어려웠고 말이 빠르셔서 적기 힘들었다 내용은 좋아서 다시 유투브로 보는게 좋을 듯!

O) 토스뱅크가 차세대를 하지 않는 이유: 지속 가능한 마이그레이션 전략

• 연역적분석, 귀납적분석(구체저긴 사례나 데이터를 통해 일반적인 원칙이나 이론을 도출) 방식을 이용해 기능 정의 및 마이그레이션 사이클 정리
• 설계 단계에서 도메인 캡슐화를 통한 데이터 표준화 , 효과적인 도메인 문서화와 지속적인 관리의 중요성
• 구현 단계 컴포지트 패턴(분할정복)
• 콘웨이 법칙?

개발이 아닌 문제를 분석 정복하고 개발하는 느낌(?) 책 많이 읽어야겠다 ^^ 개발만 하는 건 이제 시대에 안맞음

O) 대규모 사용자 기반의 마이데이터 서비스 안정적으로 운영하기

• Resilience4j 사용 client → mydata → 공유(버그)
• 별도의 서버에 구현 → 장애포인트 일원화 , 유연하고 확장 가능한 시스템

오늘의 수확 중 ~짱 좋은 것

no limit();