if(kakao)2020 보고 요약 및 생각들

봐야지 봐야지... 마음만 먹고 있다가 이번 주에 몰아서 if(kakao) 2020을 봤다.

개발 관련 세션뿐만 아니라 비즈니스, 서비스, VLOG, 인터뷰 등 다양한 내용들이 있는 게 좋았고,
온라인으로만 진행해서 그런지 몰라도 세션 네비게이션(?) 할 때 쉽게 파악 할 수 있어서 좋았다.

 

다른 사람들의 경험과 생각들을 보고 내 것으로 곱씹어보는 이런 시간이 생각의 폭도 넓히고 고정된 생각이 있다면
말랑하게 해준다.

요새 입력한 정보의 양에 집중하지 말고 내가 이걸 어떻게 소화할지와 그 소화된 것을
output(글이나 실제 코드 또는 실제 생활의 행동)까지의 한 바퀴를 경험하는 것에 집중하고 있다.
(쉽지 않다 ㅋㅋㅋㅋ, 그래도 이 생각은 잊지 말고 꾸준히 상기하자)

시간 되면  if(kakao)dev 2019 도 봐야겠다.

 

---

브런치 작가들의 이유기 - 글을 쓰면 기회가 온다. 계속 쓰면 힘이 된다.

브랜치에서 활동하고 있는 4명의 작가들이 하나의 질문을 가지고 각자 생각들을 나누는 형식이었다.

글쓰기 노하우는 가장 크게 갖고 있는 고민/생각/관심거리를 삼는 게 좋다.
업무 관련도 좋고 하고 싶은 일을 찾는 걸 먼저 해보는 것도 추천한다.
인간 극장 방송 작가셨던 분이 인간 극장(다큐 드라마)과 글쓰기를 비교하였는데 평범한 사람을 20일 동안 따라다니면서
활동들을 찍고 이것을 중간중간 가져오면 구성이 되고 한 편의 드라마가 된다.
그날의 생각/감정들을 꾸준히 일기 형식으로 쓰고 이것이 모이면 구성이 되고 한편의 에세이가 나온다.

※ 개발 공부도 비슷한 것 같다. 현재 내가 하는 개발과 너~~ 무 먼 개발 공부는 지속하기도 어렵고 적용하기는 더욱 어렵다.
현재 하는 일과 어느 정도 겹치는 게 있는 영역의 공부를 하고 정리하고 내 것으로 익히다 보면 꾸준히 할 수 있고
영역을 점점 넓힐 수 있다고 생각한다.
나의 개발 경력 중반까지 중 아쉬웠던 부분이다. 업무에 도움이 안 된 건 아니지만 가성비(?)가 좋지 않았다.
하지만 돌고 돌아 그때 했던 것들이 요새 종종 도움되고 있다. (가성비 맞춰지는듯??)
단기 투자냐, 장기 투자냐, 본인이 힘들어도 버티고 꾸준히 할 수 있는지를 생각하고 한다면 열매는 나온다.
혹시나 얘기하면 지금 잘 한다는건 아니고, 위 사실을 인지하고 있고 그 사이 중간을 유지하려고 노력하고 있다.

 

글쓰기의 장점으로는
흩어져 있던 생각들이 정리된다. (마음이 정돈)
나라는 사람을 선명하게 해 준다. (자기 객관화)
글이 쌓인 것을 보고 '아!! 내가 이걸 할 수 있구나' (작은 목표들을 하나씩 이루었고 이게 쌓인 결과물을 보며 자존감 UP!!)

 

※ 글쓰기나 코딩을 하면 내가 뭘 모르고 뭘 아는지, 이걸 더 알아야 할지 대강 알아도 되는지 감이 생긴다.
단순히 생각에서 끝나지 않고 표현 된다면 정리 되고 객관적으로 판단 한다는 장점이 있다.

브런치까지는 아니더라도 티스토리도 글쓰기가 개선되었으면 하는 소박한(?) 마음이 생겼다 ㅋㅋㅋ

 

 

ClickHouse - analytical database

Druid pre-aggregation 다양하고 빠른 분석이 필요했는데 이를 만족하지 못함 Druid ㅜ,ㅜ
ClickHouse의 특징
. Vectorized process: Single Instruction Multiple Data(SIMD) 1번의 연산, 여러개의 데이터에 적용
. MergeTree Engine: 데이터 저장시 개별적인 파트로 저장해서 속도가 빠름. 백그라운드로 파트들을 머지함. 파티션 갯수 감소
. Primary Index: primary.idx, data.mrk/data.bin(컬럼별 생성). 
        primary index와 컬럼 데이터는 mark파일로 연관. 한 파티션의 스캔양을 줄임
. Data skipping: 테이블 생성시 bloom_filter 인덱스 생성. 오픈소스 기여!!
. Replication: Asynchronous Background copy. multi-master 방식
. Distributed Processing: 데이터를 여러개 shard로 나누어 저장. Initiator Node[사용자의 쿼리를 처음 받은 노드]
        각 샤드는 로컬에서 중간 단계 결과를 만들고 Initiator Node에 전달하고 Merged 후 사용자에게 전달
. Funnel Analysis: 유저 행동을 일련의 이벤트 단계별로 분석. non-aggregate(Druid ㅜ,ㅜ)
        이벤트가 중복되거나 명시되지 않은 이벤트가 있을수도 있음. strict, strict_order 오픈소스 기여!!

 

Flink 기반 log streaming pipeline - log와 사용자를 잇는 무지개 다리

. pipeline의 설명, stream과 batch 차이
. KEMI 전사 로그 시스템에서 어떠한 요구사항이 생겼고 Flink를 도입한 이유
. ES는 비싼 자원, Hadoop에서 배치로 ES에서 적재되던 것을 Kafka에서 실시간으로 ES에 적재를 해야 했고 이곳에 Flink 도입
. K8S에서 동작, KOCOON(Prometheus)로 모니터링하고 체크포인트는 Minio를 사용
. rebalance와 rescale의 차이, task 간 통신이 어떻게 이루어지는지 차이
. task들을 노드나 slot안에서 처리하는 것도 좋은 방법일 수 있다. (네트워크 비용 감소) Task chaining, SlotSharingGroup, CoLocation

 

 

How to make log based Alert with Flink

. 수집 -> 필터 -> 집계 -> 알람으로 모니터링이 진행되고 있는데 필터와 집계 사이에 어떤 일이 발생하는지 설명
. 1분마다 집계한 데이터를 slot에 저장하고 3분 혹은 5분으로 시간 단위를 자유롭게 조건을 걸 수 있다.
. Window(스트림을 시작과 끝을 정해준다.)와 WaterMark(Window가 시작과 끝을 정할 때 사용되는 기준)
그리고 trigger를 이해하기 쉽게 설명해준다.
. EventTime으로 세팅한 경우 Flink의 인입되는 데이터가 없다면 Flink 시간도 멈추게 된다... 크흐~~~ 멋지다.

현재 데이터 엔지니어링에서 서비스 백엔드 개발로 업무가 바뀌어 더 이상 Flink를 사용하지는 않지만
이렇게 두 개 세션에 Flink가 나오니 괜스레 기분이 좋았다. ㅋㅋㅋ
마치 어렸을 때 좋아했던 신입 연예인이 시간이 흘러 유명해졌는데 이를 멀리서 바라보며 흐뭇한 느낌? ㅋㅋㅋㅋ

 

 

카카오와 MongoDB

. MongoDB 특징 설명
. 카카오 모빌티리에서 공간 인덱스를 어떻게 사용하는지 설명
. 대용량 로그 저장, 샤드와 TTL Index
. 손쉬운 확장, 다양한 인덱스 지원, 유연한 스키마

 

 

카카오톡 4M/s 캐시 클러스터 전환기

. 트래픽마다 캐시 클러스터 노드수가 다르다.
. 기존 캐시 클러스터의 상황 및 단점 설명, 메모리 흥청망청, 최첨단 수동 작업 ㅋㅋㅋㅋ
. 쿠무새, Redis + K8S = 레디스 팜이 생성되었다.
. Deployment가 아닌 Statefulset을 사용, OnDelete update 전략, Host Network(k8s 안티패턴, 병목구간 줄이기)
. 레디스 팜은 Sentinel과 Barn을 활용, (Barn은 센티넬 모니터링 및 레디스 팜 관리하는 자체 도구)
. 대규모 장애 상황에는 자동화된 장애 대응을 하지 않는다. Safe ODOWN(Enough Downtime + Large Quorum), Disaster threshold
. 기존에 Memcached를 사용하고 있었는데 레디스 팜으로 트래픽 전환하는 얘기
. 캐시를 어떻게 사용했는지 (Cache aside pattern, Consistent Hash)
. 주키퍼를 이용한 Dynamic config를 통해 문제점을 미리 잡았던 경험 소개(memcached의 멀티쓰레드)

 

 

터널 안에서 위치를 계산하는 FIN 기술

. FingerPrint, 기지국에 가까울수록 신호는 세지고 멀수록 신호는 약해진다. 이걸 이용해서 위치를 파악
. 하지만 신호만으로 위치 파악하기엔 어렵다. 이유는 노이즈가 심하기 때문, 이를 해결하기 위해 어떤 걸 했는지 공유
. OBD2(차량의 속도를 알 수 있는 정보) + GPS + 도로 네트워크 정보와 Kalman smoother를 적용하여 위치 계산 진행
. Dynamic Time Warping(DTW) 활용해서 사용자 데이터와 DB 데이터를 비교

 

 

Kubernetes 환경 Spring Cloud Data Flow 를 이용한 백업, 정산 데이터 파이프라인 구축 - 카카오페이머니클랜의 데이터파이프라인은 어떻게 생겼을까? 

. 하루 천만 건 이상의 정산 데이터가 쌓인다. 기존 정산 단점 (배치 양이 많아진다면? 크론 잡, 백업 데이터에서 정산 진행)
. 그래서 생각한 게 Data pipeline, 이것의 장점, SCDF 선택한 이유
. 정산 전 관련 거래 데이터 백업, 정산 배치 파이프라인을 조합 가능, 쉬운 파이프라인 생성 및 수평/수직 확장 가능
. 어떤 파이프라인 구축했는지 경험 공유, Source, Processor, Sink
. 스트림(stream, pod 항상 떠있음), 태스크(batch, 실행될 때 pod 뜸), 스트림은 보정되지 않는 데이터일 경우 사용할 예정

 

 

 

Pacemaker와 함께...따뜻한 서비스의 첫 걸음

. 상품 이벤트뿐만 아니라 특별한 날의 트래픽, 그리고 Scale-out이 답이 아닌 이유, 거친 request를 부드러운 response로 내어주기
. 그래서 나온 게 Pacemaker Library + Pacemaker Server
. 확률적 자료구조 Count Min Sketch를 이용하여 상품별 카운트 그리고 TTL은 HashedWheelTimer를 이용, ExpireCountMinSketch
. @PacemakerTarget annotation, Interceptor를 WebMvcConfig에 추가하면 끝
. Pacemaker Server는 Disruptor, 이벤트가 들어오면 보관하고 선입 선출, BlockingQueue와 유사, 그리고 WebFlux이용
. Pacemaker Server 처음 접속한 유저에게 서버 번호를 넘겨주고 다음부터 유저는 request param에 서버 번호를 붙여서 요청
. Pacemaker에서 대기하다가 순서가 되면 다시 Front서버로 가는데 Pacemaker 인증 토큰을 추가함
(Library에서 토큰이 있을 경우 카운트를 안 하기 위함일 것 같다.)

 

메트릭 기반 모니터링 환경 구축 (feat. Prometheus)

. 카카오페이 기존 모니터링의 문제점 설명.  Metric, Alert, DashBoard
. 목표는 MTTD(평균 탐지 시간) 5분 이내(먼저 적용이 목적), 운영 피로도를 줄이기 위한 프로세스 도입
. Metric과 Log의 차이와 공통점 비교, Metric Label, 고객/시스템 입장의 메트릭 수집
. 예시: Netflix는 playback 버튼 요청을 Metric으로 사용
. 무엇을 수집할 것인가? RED 방법론
Rate: 서비스에서 제공하고 있는 시간당 요청수, Errors: 시간당 에러 숫자, Duration: 각 요청에 걸리는 시간 분포
. 대시보드 만들 때 운영과 분석은 분리하기
. Alert은 어떻게 하는 게 좋을까?
증상 기반, 행동을 필요로 하는 것(scale out, 타 부서 협업 필요 등), 에러/인포 레벨 분리, 적중률 검토를 통한 관리
. pull 방식, Promethues는 클러스터링 기능이 없다. zone마다 prometheus를 설치하고 federate를 이용하여 수집을 분산
. HA를 지원하기 위해 LB를 두고 sticky session이나 Active/StandBy를 사용할 수도 있지만,
근본적인 해결 방법은 아니어서 Thanos를 사용

 

 

카카오페이 매입 시스템 - 성능 개선 과정과 JOOQ 도입을 중심으로

. 카카오 페이의 성장으로 매입 시스템 HAWK 성능 개선이 필요
. JDBC, Hibernate ItemReader 비교, Hibernate Paging 형 나가 있어 ㅋㅋㅋㅋ
   복잡하고 대용량이면 JDBC 기반 ItemReader를 추천
. JDBC ItemReader 적용은 좋은데 문자열로 SQL 하는 건 보기에도 별로이고 실수할 여지가 있다. 그래서 JOOQ를 도입
. JOOQ를 도입한 이유들을 설명