if kakao 2019 day1 참석 후기

• Keynote 키워드는 Growth
• 기억에 남는 문구는?
  • 개발자는 곧 첫번째 고객. 개발자의 의견이 프로덕트에 적극적으로 반영되어야한다.

오픈소스 DB

• 흐르는 데이터를, 실시간 데이터 변경 재배치하는게 목표. 왜 필요한가? shard에도 한계가 있어서?
  • Overwrite & Sequential & Parallel

데이터 분산 재배치 방안 2가지?

• 1. SQL로 데이터 퍼가기
• 1. Change Data Capture로 변경분 퍼가기
• SQL로 데이터 퍼가기?
  • 상대적으로 구조가 간결하지만 소스에 DB에 부하.(SELECT, INDEX) 지연된 커밋에 따라 데이터 누락 발생 가능.
• CDC로 변경분 퍼가기
  • 소스 DB에 SELECT등이 발생하지 않기 때문에 부하가 거의 없음.
  • 비동기 데이터 복제 및 복제 시스템 운영 부담.
  • 원하는 형태로 데이터 재구성 어려움

그래서 울드라맨이라고 만들었다고 함.

• 울드라맨이라는건 Source DB에서 실시간으로 MySQL Binary Log를 파싱해서 Target DB쪽에 분산 재배치해주는 역할.
• 울드라맨 이전에 쓰던건https://github.com/kakao/adt
  • Kakao sharding rebalancer -> kakao adt -> uldraman
  • adt는 배치 프로세스 초점. 이관 및 재분배 (타겟이 서비스 투입되지 않음)
  • 그러나 ULDRAMAN은 온라인 서비스(타겟이 중요), 샤딩키 변형, 커스터마이징 전략, 빠른 복구
• Overwrite는 장애 지점 이전부터 차례대로 덮어쓰다보면 언젠가는 맞춰진다는 접근방법임.
  • 그래서 log를 다음과 같이 해석해서 작업해야 함.
  • Write log -> Replace
  • Update log -> [delete +] replace
    • delete가 수행되느냐는 샤드키 혹은 PK 변경이 되었으면 delete도 수행.
  • 막 덮어쓰면 과거 데이터가 보일 수 있어서, table에 버전을 매겨서 버전이 낮은 경우에만 overwrite하는 식으로 동작한다.
  • Source DB에 없는 샤드키를, uldraman을 통과하면서 샤드키를 만들고 그 샤드키에 따라서 target DB로 데이터 분산 재배치.

초당옥수수 어쩌고…

TMS란? 카카오 쇼핑같은데서 사용자한테 보내주는 카톡 메시지. Target 어쩌고…

배송지연 표시 -> 일정 주기로 배치 돌아서 multithread 모델로 처리하던걸

RabbitMQ이용 배송지연 큐에 쌓기 -> 큐에서 하나씩 가져가서 비동기처리.

배치를 비동기로 변경하면서 실시간 처리 가능.(실시간으로 TMS 보낼 수 있음)

처리 속도 때문에 비동기 layer를 2개로 나눔. controller단 validation(@Valid 쓰더라.) -> business logic 비동기 -> TMS 발송 처리 비동기 이렇게.

queue는 한개고 consumer를 여러개 두는 구조로 했는데, 이렇게 하기 위해 consumer가 최대한 atomic하게 동작하도록 구성. 서로 간섭 안하도록.

왜 message broker 중에 RabbitMQ를 썼는가? RabbitMQ의 Message Header와 Queue 속성을 이용하기 위함. x-death-count 같은 것을 이용해서 retry하기 위해서.

이런 구조를 통해 actor 모델로 변경했는데… actor 모델의 장점이 scaleable하다는 것이므로 필요한 경우 Actor를 확장하면서 수행 시간을 더 줄일 수 있다.를 얘기함. 1세션도 그렇고 확장성이 역시 중요한 듯…

배포는 어떻게? 배포 없이 롤백?

• swtich를 사용했다함. zookeeper에 값 하나 올려두고 얘를 참조해서 스위치가 켜져있으면 새로운 로직, 꺼져있으면 기본 로직
  • 이런식으로 해서 한시간만 스위치 켜서 테스트하고 뭐 그런 식…
  • 컨트롤러에서 switch를 달아서 동작.하고 기존 요청을 새로운 요청으로 wrapping한 다음 비즈니스 로직단으로 넘겨주는 방식.
• 근데 이건 이 서비스가 이게 가능한 방법이니까 되는 거라고 볼 수 있을 듯. 딱 비즈니스 로직만 변경되었을 때…
  • blue-green deploy같은 느낌이긴 한데, 보편적으로 적용할 수 있는 방법은 아닌 것 같다.

카카오 T 대리

백엔드에서 Go를 썼다. Java도 고려 사항이었으나

1. Spring framework는 내부를 들여다 보기 어렵다.
2. JVM 튜닝이 아주 골치아프다.
3. 문법의 자유도가 높아서 개발자 간 코드 결과물 편차가 크다.

등의 이유로 안쓰고 Go로 결정하게 되었다고 함. DI 같은 것은 go에서는 FX로 달성했다함. go.uber.org/fx

HTTP1.1/Json 기반의 RESTful 통신 대비 gRPC가 Throuput이 몇 배나 더 잘 나와서 gRPC로 통신하는 것으로 결정. protobuf 기반의 binary 통신을 하는 듯? grpcui라는 postman이랑 비슷한 테스팅 툴이 이씀. grpc-gateway를 사용하면 grpc를 REST처럼 공개할 수 있다. (go 언어 구현체 일 경우만 사용 가능) 통합테스트는 docker-compose로 묶은 다음 postman으로 함.

API gateway 설계

1. 클라이언트가 요청하는 기능 단위로 API를 제공해줘야 하나?
2. API는 몇 개만 뚫고, 필터를 파라미터로 받아서 해야하나?
   • 버저닝은 어떻게 해야하나?

이런 고민을 한꺼번에 해결해줄 수 있는 솔루션 GraphQL

단 하나의 endpoint POST /graphql

query로 원하는 것을 요청.

데모 보니까 좋네.. 내가 원하는 데이터만 query 형태로 적어서 넘기면 딱딱 그것만 빼서 받아볼 수 있으니까 어떤 API를 뚫어야 할지 고민할 필요가 없어짐. 구현체는 Java, Go, Node.Js 공식적으로 미는건 Node. 라이브러리도 많고 쓰기 편하게 되어있다고 함.

모니터링은 Prometheus + 시각화는 Grafana

장애 원인은 성능이 낮은 staging 서버 주소를 product 서버 주소로 잘못 입력해서, 거기가 병목이 되어 전체적으로 지연 현상이 발생했던 것임. 그래서 모니터링은 꼭 필요… 분산 로그 추적 시스템도 필요. Zipkin

펌 뱅킹(Firm)에서 코틀린 적용하기

펌뱅킹이란? 기업(firm)이 은행(bank)과 전용선 뚫어서 전문 날려서 은행 업무 처리하는 것.

카카오 전사적으로 쓰는 내부 펌뱅킹이라는걸 보니, 카드결제개발 팀이랑 비슷한 느낌인 것 같다.

완전히 코틀린으로 되어 있는게 2개. 하나가 user-side, 하나는 카카오톡 내부에서 사용하는 것 1개. 자바+코틀린은 2개.

유저가 카카오톡 회원이면 펌뱅킹 서비스를 거치지는 않음. (은행이랑 전문통신 안하나봄?) 근데 송금을 한다거나 인증을 한다거나 ARS를 한다거나 하면 펌뱅킹을 거침.

코틀린에 async await가 언어 자체에 포함이 안된 이유?
코틀린 컴파일러 개발자의 말에 따르면… 어려운 부분은 다 라이브러리로 빼고, 언어 자체 문법은 실용적, 간결하게 놔두어서 진입장벽을 낮추고 싶었다. 라고 함.
왜 잘 쓰던 자바 말고 코틀린을 적용했는가? -> 발전이 너무 더디다… 멈춰있는 동안 다른 좋은 언어가 많이 나왔다. 특히 JVM 호환 언어들.

그렇다고 해도 결과를 보장할 수 없는 신기술을 어떻게 안전하게 적용할 수 있을까? -> 일단 신규 프로젝트에 적용해보자! -> Hibernate 등등 자바 라이브러리를 같이 쓰면서 코틀린으로 잘 개발해서 오픈.

-> 그 다음은 돈이 왔다갔다하는거니까… 사용자 영향이 거의 없는 Batch나 Admin부터 코틀린으로 해보자!

그 다음은?

한꺼번에 전환한게 아니라 테스트와 같이 차근차근. 테스트가 아주 중요하다.

특히 돈나가는거니까… 테스트를 아주 꼼꼼히 작성하는 듯.

프로덕션 환경에서 발생한 문제점!!! -> 사실 문제가 별로 없었다. 자바와 코틀린의 호환성이 그 정도로 훌륭하다. 근데, 라이브러리에 대한 호환성이 100%가 아니기 때문에 어떤 라이브러리에서 코틀린을 썼더니 문제가 발생했더라 와 같은 상황이 있을 수 있음.

아래에서 2~5는 플러그인으로 해결 가능한 이슈.

Lombok과 관련된 문제 해결방법은 코틀린으로 전환하거나 delombok(직접 getter/setter정의)로 해결

질문 :

1. 기존 구성원들의 기술 스택이나 이런 점 때문에 소극적으로 대응하거나 하는 팀원은 없었나? 익숙하지 않으니까 트러블슈팅이 어렵다와 같이 좀 소극적으로 대응하는 팀원을 어떻게 설득했는가? -> 설득이 있었다함. 이 정도는 해도 괜찮지 않겠냐 직접 코드를 작성해서 보여주기도하고. 단계적으로 별로 크리티컬하지 않은 것 부터(batch) 차근차근 적용하고.

2. 전문 통신 하는 부분에서 코틀린을 썼기 때문에 편했던 점이 있느냐. -> 뭐 하나만 딱 찍어서 얘기할 수는 없는데 전체적으로 가독성과 생산성이 향상되었다.

if kakao 2019는 어떻게 진행되었나?

• 우리는 어떤 요구사항을 만족하기 위해서 어떤 기술을 선택했고, 기술 중에서 왜 그걸 골랐고 의사 결정은 어케했는지 등에 대한 발표가 대부분.
• 무슨 기술을 쓰고 있나, 왜 그 기술이 더 좋은가에 대한 인사이트를 얻을 수 있어서 괜찮았음.
• 카카오가 도입이 더딘 부분도 있다. circuit breaker 같은 것? 단순한 실수로 장애가 발생한다던가.
• 한 가지 확실한건 새로운 기술에 대해 굉장히 적극적으로 반영함.