if Kakao 개발자 컨퍼런스 1일차
참석 후기
카카오 개발자 컨퍼런스인 "if Kakao developer 2019" 1일 차에 참석하고 작성하는 후기입니다. 공식적인 발표자료가 아직 공개되지 않아서, 부득이하게 제가 직접 찍은 사진으로 설명을 대체합니다. 다른 참석자들에게 방해가 되지 않도록 뒷자리에서 사진을 찍었는데, 그래서인지 사진 품질이 좋지 않습니다.
제 글은 재미 삼아 읽어주시고,
추후에, 공식적으로 발표자료가 공개되면 공식 발표 슬라이드 자료를 통해서 제대로 확인하시길 바랍니다.
수많은 세션 중에서 저는 5개의 세션에 참석하였는데,
개인적인 관심 주제 또는 업무 관련 주제를 선택하였습니다.
1.서비스 장애를 극복하는 게임플랫폼 구축하기 (Build a fault tolerant system)
2.초당옥수수의 취소를 막아라! : 수만 건의 주문을 1초내에 처리하는 기술
3.Practical Microservices in gRPC Go feat. GraphQL, Kafka(서포터즈 기사 개발기)
4.카카오톡 적용 사례를 통해 살펴보는 카카오 클라우드의 Kubernetes as a Service
5.광고서버 연대기
if Kakao Developer 2019, Keynote
행사 당일 사무실에 일찍 출근해서 업무를 하다가 10시 전후로 키노트 시간에 맞춰서 컨퍼런스 장소로 이동하였다. 행사장 입구에 "라이언"이 개발자들을 반겨주고 있다.
등록을 하면 에코팩에 웰컴킷(?)을 준다. 웰컴킷에는 생수 한병 과 노트, 티셔츠, 각종 스티커가 담겨있다.
키노트는 중간에 참석해서 전체 내용을 정리하지는 못했다.
간략하게 요약하면 아래와 같다.
새로운 모바일앱 표준을 선도하고 있다.
오픈소스 기반의 은행시스템을 구축하였다.
개발자의 의견이 품질에 영향을 미치게 된다.
개발자는 첫번째 고객이다.
카카오 뱅크에서는 개발자의 비율이 41% 이다.
모바일 시대에 혁신을 위해서 자기 주도적으로 문제 해결을 한다.
조직문화에 정답은 없고, 카카오뱅크의 문화가 무조건 좋다고 얘기할 수는 없지만, 기업 문화를 위해 많은 노력을 하고 있다.
서비스 장애를 극복하는 게임플랫폼 구축하기
(Build a fault tolerant system) - 카카오 게임즈
첫번째 세션은, 카카오 게임즈에서 플랫폼 개발을 하면서 경험한 장애에 대한 사례 중심의 발표였다.
시스템 장애가 발생하면,
예를 들어서, 서버 커넥션이 갑자기 끊기면 개발자는 무엇을 확인하는가?
1. 서버가 살아있는지 확인한다.
2. 서버 리소스 사용량이 괜찮은지 본다.
3. 에러 로그를 확인해본다.
4. 등등... 기타 파생되는 문제가 매우 골치 아프다.
이번 세션에서는, 이런 서비스 장애에 대한 안정적인 플랫폼 구축에 대한 내용이다.
장애 발생 과정
일반적으로 시스템의 장애 요인은 크게 하드웨어 측면과, 소프트웨어 측면으로 나눌 수 있다.
하드웨어 : 서버, 인터넷, 스위치 등
소프트웨어 : OS, JVM, 컨테이너, 소스코드 등
서비스 장애 발생 사례 중, API 에러가 발생을 했다고 가정해보자. 시스템 장애는 아주 빠르게 전파가 될 것이다. 아래와 같이 API 에러가 발생하면, 응답 처리 속도가 지연되고, 서버 장비가 먹통이 되고, 결국 전체 시스템에 장애가 전파될 것이다.
장애가 발생했을 때 중요한 점은, 전체 시스템 정지 까지 가지 않도록 하는 것이 중요하다.
장애 허용 시스템
특정 모듈에서 장애가 발생해도 크게 문제가 발생하지 않도록 이겨낼 수 있는 시스템을, "장애 허용 시스템" 이라고 부른다. 장애 허용 시스템은 아래와 같은 특징을 가진다.
모든 구성 요소의 문제 발생 가능성을 인정한다.
문제 발생을 최소화한다.
오류를 자동으로 해결한다.
전체 시스템 장애 전파를 차단한다. (가장 중요)
장애 허용 시스템 구축에 대한 사례를 소개하겠다.
시스템 이중화하기, 물리적인 인프라 장비의 이중화 사례
물리적인 인프라 장비의 이중화를 구축해서, 고가용성을 확보할 수 있다. 백엔드 아키텍처는 마이크로서비스 환경으로 구성하고, 각 서비시는 최소 2대 이상, 다중 커넥션으로 구성한다. 저장소 장비의 이중화를 한 경우 어떤 상황에서도 데이터 처리를 동작시킬 수 있다. MySQL HA 구성을 하거나, 레디스 클러스터를 구축한다.
레디스 클러스터의 경우, 마스터/슬레이브 노드로 구성하고, 마스터 노드 장애시 대응할 수 있도록 시스템을 구축한다.
물리장비 이중화 외, 기타 사례
우편함 메시지 발송 처리 사례, 로그인 인증 처리 사례 등
우편함 메시지 발송 처리 사례 : 원격 저장소 장애시 로컬 저장소에 임시 저장 후 자동 복구 처리 되는 아키텍처 구축, 메시지의 고유 ID 를 할당해서 결과 데이터를 전송. 메시지 고유 ID 는 "앱ID + 유저 ID + 이벤트 ID + 시간 기준값" 으로 구성
로그인 인증 처리 사례 : 네트워크 장애가 발생했을 때, 만료된 인증 토큰으로 요청하는 경우, 자체 인증 토큰 확인 방식으로 전환. 보안상에 문제가 될 수도 있지만 허용 가능한 범위. 단, 신규 가입한 유저는 필수 정보가 필요하기 때문에 대응하지 못하였음. 장애 발생 당시 95% 가 기존 가입 유저였기 때문에 크게 문제가 되지는 않았다고 함
장애 차단하기(1) - 쓰레드풀
API 처리 관련 사례 중심으로 소개. 기존 시스템은 모든 API 를 공용 쓰레드 풀에서 동작하는 상황인데, 이런 경우 특정 기능이 모든 쓰레드를 점유하게 되는 상황이 발생할 수 있다.
정작, 다른 중요한 기능이 동작안하게 될 수 있기 때문에 이런 경우에는, 쓰레드 풀을 기능별로, 중요도 별로 쓰레드 풀을 나누는게 효율적이다. 아래 캡쳐 화면과 같이, 특정 기능이 문제가 발생해도 다른 기능은 정상적으로 동작하게 된다.
중요한 점은, 장애 영향 범위를 최소화하는 것이다.
참고로, Hystrix 라이브러리를 사용중이고, 자체 구현 매핑한 구조가 있고, Hystrix 쓰레드 풀을 분리 하였음
장애 차단하기(2) - 비동기 서비스 로직
외부 통신 구간이 포함되어 있는 API 연동을 구현할 때, 특정 서버의 지연발생의 경우 처리중인 쓰레드는 계속 점유된 상태로 유지가 될 수 있다. 이런 상황을 방지하기 위해서, 비동기 서비스 로직을 추가해서, 처리 속도 지연으로 인한 쓰레드 풀 고갈을 방지할 수 있다. 아래 캡쳐 화면을 참고하자.
제일 뒷자리에서 사진을 찍어서 그런지, 사진이 많이 흔들렸다. 나중에 공식 발표자료를 확인하길 바란다.
장애 차단하기(3) - 데이터에 의한 문제 사례
동일한 토큰 값으로 요청을 하면 Write Lock 문제가 발생하는 사례. 비정상 토큰에 대한 체크 로직을 구현하였는데, 10초 동안 5회 이상 같은 토큰, 다른 계정으로 요청하는 경우 일반적인 상황이 아니라고 판단해서 추가 처리를 하였다.
장애 감지 시스템, 알람 시스템 구축
API 에 대한 알람을 최대한 잘 받아야 한다.
너무 많은 알람이 온다면, 알람의 그룹을 정리하고, 발송 빈도를 조절하고, 임계치 설정을 하는 것이 좋다.
API Health Check
세션 1, 참석 후기
주제 및 발표는 매우 유익하였고, 특히 강사님께서 발표를 정말 잘하셨다. 비록,이중화, 쓰레드풀 분리, 비동기 서비스 로직 처리, 동일 키 업데이트 문제 사례, 장애 감지 시스템 등 한번 쯤 경험해본 사례들이라서 반가웠다. 전반적인 세션 발표 내용은 매우 만족스러웠다.
초당옥수수의 취소를 막아라!
수만 건의 주문을 1초내에 처리하는 기술 - 카카오 커머스
두번째 세션은, "카카오 커머스"에서 수만 건의 주문을 단시간에 처리하는 비동기 처리에 대한 주제이다.
초당 옥수수??
초당옥수수에 대해서 오늘 처음 알게 되었다. 당분 함량이 높은 옥수수인데, 보통 수확과 동시에 택배 발생을 한다. 일반적으로 농작물은 배송하는 상품은, 배송이 지여되면 사유를 빠르게 알려야 하는데, 이때 배송 지연 처리 기능을 사용한다. 이번 세션에서는, 배송 지연 처리가 발생했을 때, 빠른 시간안에 수많은 처리를 실시간으로 처리할 수 있는 방법에 대한 세션이었다.
레거시 시스템 문제
레거시 시스템은 크게 두가지 문제를 갖고 있다.
배송 지연 안내를 위해 TMS 배치를 수행
너무 복잡한 비즈니스 로직
참고로 TMS 는 타겟 메시징 시스템이다. 배송 지연 안내에 대한 TMS 배치를 수행하는데, 배송 지연 알림을 좀 더 빠르게 수행하기 위해서, 레거시 시스템의 배치의 한시간 간격 주기를 5분으로 줄였지만 근본적인 해결책이 아니었다. 또한, 기존 레거시 시스템은 너무 복잡해서 실시간 처리 로직을 추가하기에도 좀 까다로운 상황이었다.
미션 1 - 실시간 TMS 발송
기존 시스템은 포크조인으로 병렬 처리를 하고 있었는데, 단일 머신에서 수행하기에는 너무 큰 한계에 직면한 상황이었다. 그래서, 카카오커머스에서는 실시간 메시지 발송을 위해서, 비동기 워커를 구성하였다. 메시지 브로커로 RabbitMQ 를 도입하였다.
미션 2 - 복잡한 비즈니스 코드 리팩토링
코드가 복잡해지면서, 불필요하게 반복적으로 수행하는 로직이 많았는데.. 해당 부분을 잘 개선하였다.
미션 3 - 처리 속도 개선
반복적인 테스트 수행 시 병목 현상이 발생한다. 그래서, 비즈니스 처리 역시 비동기 워커를 구헝하였고, 각 비동기 워커에서는 여러 개의 컨슈머로 처리해서 대량의 요청을 분산 처리할 수 있도록 해결하였다.
액터가 된 비동기 워커 - 분산처리
쉽게 분산처리를 할 수 있도록 개선하였는데, 스프링의 SimpleRabbitListenerContainerFactory 를 확장하였고, 리스너 별로 컨슈머 커스텀 설정을 하였다.
액터가 된 비동기 워커 - 자동 재처리 및 실패 감지
정상적으로 메시지 처리를 한 경우에는 아래와 같다.
get 은 메시지를 읽는 것이고, ack 는 정상처리를 뜻한다. non-ack 를 받은 경우에는 메시지 Dead 상태이다. 아래 캡쳐와 같이 메시지 처리 실패를 하면 자동 재처리를 수행하게 된다. RabbitMQ 의 큐와 헤더 특성을 활용하였는데, Queue-Retriable 는 재처리용 큐 이다.
어쨋든, RabbitMQ 의 메시지 헤더의 속성을 활용해 재처리 및 실패 전략을 수립하였는데, 결과적으로 비교할 수 없을만큼 성능이 향상되었다.
배포 없이 빠르게 롤백하는 전략
온오프 스위치 기능을 적용하였다.
세션 2, 참석 후기
주제 및 발표는 매우 유익하였고, 특히 연사님 두분께서 발표를 정말 잘하셨다. 개인적인 관심주제라서 매우 만족스러운 강연이었다. 개인적으로 RabbitMQ 로 시스템을 개선해본 경험이 있지만 기본적인 기능만 사용해봤는데, 발표 중 소개된 코드는 조금 이해하기 어려었다. RabbitMQ 및 Spring AMQP 를 심도있게 공부를 해야겠다는 자극을 받게 되었다.
Practical Microservices in gRPC Go feat.
GraphQL, Kafka(서포터즈 기사 개발기) - 카카오 모빌리티
세번 째 세션은, 카카오모빌리티에서 GO 언어를 도입해서 마이크로서비스를 구축한 사례이다.
팀 상황, 생각의 정리
"서포터즈 기사" 는 카카오모빌리티에서 제공하는 대리운전? 관련 서비스 인것 같다. (정확히는 아직 모르겠다...) 어쩃든, 해당 서비스는 90개의 사용자 스토리가 있었는데, 개선하기 전에는 개발 복잡도가 매우 높았다고 한다. 그래서, 먼저 생각을 정리하기 시작했다고 한다. 새로운 것을 개발하기 앞서 생각을 정리하여 계획을 세우고, 계획을 짧은 문서에 담는 등.. 이런 과정을 거쳐서 RFC 문서라는 포맷으로 문서를 작성하기 시작하였다.
프로그래밍 언어 선택 - GO
GO 언어를 선택하였다. 발표에서는 각종 장단점을 설명하였는데, 배우기 쉽고, 적은 메모리 사용 및 상대적으로 빠른 성능 등의 장점이 있다.
마이크로서비스 아키텍처, 서포트즈 기사 시스템 서비스 구조
처음부터 마이크로서비스를 고려한 것은 아니었다. 일단, 기존 시스템은 일체형 아키텍처로, 대리운전 사용자, 대리운전 기사, 운영 관련 주요 API 를 담고 있는 거대한 일체형 아키텍처로 구성되어 있었다. 또한, 테스트 커버리지가 낮았고, 구성요소가 유기적으로 얽혀있어서 전체를 파악하기 어려웠다. 이런저런 이유로 인해서, 마이크로서비스 아키텍처를 검토하기 시작하였는데...
마이크로서비스 아키텍처가 무조건 좋은 것은 아니다. 여러가지 단점이 존재하고, 해당 팀에서는 이런 단점을 보완하기 위해서 여러가지 개선 작업을 했다.
기존 하나의 API 호출이 다수로 증가 --> API 게이트 웨이 를 도입해서 개선
마이크로서비스 간 네트워크 통신 비용 증가 --> 대부분 DC 내부 비용으로, 벙렬 처리를 염두에 두고 개발
서비스 발견이 복잡 --> Consil 등 도입으로 개선
공통 기능에 대한 중복 발생 --> 라이브러리 도입
테스팅 및 운영 복잡도 증가 --> ???
서비스 시스템 구조는 아래와 같다. 빨간색 영역은 기존 시스템이고 나머지는 전부 신규 시스템이다.
이제, 시스템을 구축하는 과정에서 도입한 핵심 기술을 알아보겠다.
기술 1 - gRPC
경량의 이진 프로토콜이다. 네트워크 효율성이 증가하며, 효율적인 CPU 사용한다.
구글의 오픈소스 구현체이다.
서비스 호출 건수가 빠르게 증가함에 따라, 매호출마다 잘 정의된 인터페이스를 유지하는것이 필요
인터페이스를 유지하기 위해 IDL 이 필요하다는 것을 깨닫고, gRPC 를 사용하기로 결정
gRPC 는 서비스 소유자가 제약된 인터페이스 정의를 발행하는 걸 강제하는데, 이는 서비스 통합시 필수 사항
gRPC GateWay 도 있는데, Rest 를 선호하는 클라이언트를 위해서 간단한 설정만으로 Rest 프록시를 제공
단, gRPC 는 어떻게 테스트를 해야할지 어려웠다고 한다. 또한 인증, 로깅 등 검토해야할 사항은 많았음
기술 2 - Kafka
서비스는 매우 복잡해졌다. 수많은 콜백 패턴이 생겼고...
그래서, 메시지 브로커인 카프카를 도입하였다.
카프카를 도입하면서 얻은 이점은,
서비스 간 메시지 흐름이 단순해졌다.
메시지의 영속성을 보장한다.
패킷 오버헤드 감소
자유로운 메시지 처리
하나의 이벤트 메시지를 동시에 여러 서비스에서 소비
메시지 버저닝은 스키마 레지스트(?)를 도입
기술 3 - GraphQL
클라이언트에서 원하는 엔드포인트를 다 만들어야 하는지에 대해서 고민을 했다. 또한, 서버의 변경이 발생했을 때, 버저닝 이슈 및 API 문서 관리 등 일반적으로 Rest API 를 사용하면서 발생하는 여러 문제를 한번에 해결하기 위해서 GraphQL 을 도입하였다. GraphQL 구현체는 다양한다, 해당 팀에서는 Node.js 를 사용했다.
참고로, GraphQL 을 사용하면, 분산 모니터링을 위한 Zipkin, APM 인 New Rellic 등을 어렵지 않게 연동할 수 있다. (아마도..Node.js 에서 제공하는 수많은 라이브러리 때문인 것으로..)
서비스 오픈을 했으나, 예상하지 못했던 장애가...
출시일에 급하게 맞추다 보니 모니터링 시스템도 없이 오픈을 하게 되었는데, 장애가 발생하였다. API 타임아웃이 발생하거나, 데이터베이스 커넥션이 끊기거나, 해당 DB 를 사용하는 모든 API 가 지연되는 등. 모니터링 시스템을 도입하기로 했고, Prometheus 와 Grafna 를 도입하였음
Prometheus : 이벤트 모니터링과 알림에 사용되는 오픈소스 메트릭 수집 도구, Pull 방식의 메트릭 수집 방법이다. 대부분의 모니터링 도구는 클라이언트가 서버로 Push 하는 구조이지만, Prometheus 는 클라이언트에서 push 하지 않고, Prometheus 서버가 Pull 을 한다. 또한, 모든 데이터를 수집하는 것이 아니라, 일정 주기로 발생하는 메트릭 정보를 수집한다. 애플리케이션 퍼포먼스에 유리하지만, APM 과 같이 발생한 모든 로그를 추적하는 목적에는 부적합할수 있다.
Grafna : 시각화 기능을 제공하는 모니터링 플랫폼이고, Prometheus 가 권장하는 모니터링 시각화 도구이다. 데이터 플랫폼 고유의 Query Language 를 이용하여 데이터 소스로부터 정보를 조회하여 시각화한다.
레거시 시스템 전환
레거시 시스템을 신규 시스템으로 전환할 때는, 기존 시스템에 영향이 없어야 한다. 아래 캡쳐와 같이 traffic throttling 기능을 적용하였다. 신규 서버로의 트래픽을 조절하면서 안정적인 전환을 할 수 있도록 한다.
또한, nginx reverse proxy 를 활용해서 특정 도메인 또는 url 로 유입되는 경우 유입 전환을 할 수 있도록 한다.
추후에는, 서킷 브레이커를 도입하고 싶다고 한다. (아직 도입하기 전인 듯...)
세션 3, 참석 후기
주제 및 발표는 매우 유익하였고, 특히 연사님들께서 발표를 정말 잘하셨다. graphQL 을 저런 용도로 사용할수 있구나 하는 생각을 하게 되었다. 개인적으로는 GO 언어, Node.js 에 대한 관심이 많지는 않고, 너무 많은 기술 내용이 나와서 그런지 조금은 산만했던 발표였다. 그래도, 정말 만족스러운 발표였다.
카카오톡 적용 사례를 통해 살펴보는
카카오 클라우드의 Kubernetes as a Service - 카카오
네번째 세션은, 카카오 의 쿠버네티스 기반의 클라우드 환경에 대한 내용이다. 추가로, 카카오톡 서비스에서 쿠버네티스 클라우드를 어떻게 사용했는지에 대한 사례도 포함되었다.
저는, 쿠버네티스에 대해서 잘 모릅니다. 제가 잘못 이해한 내용이 있다면, 댓글로 피드백 부탁드립니다.
일체형 아키텍처
마이크로서비스 아키텍처 및 쿠버네티스의 등장
마이크로서비스 아키텍처는 역할과 책임으로 애플리케이션을 분리한다. 확장하기 쉬워지고, 단일 배포가 가능하다. 하지만, 여러가지 해결해야 하는 이슈가 있다.
하나의 서버 OS 환경에 다양한 언어와 버전의 애플리케이션을 설치하고 관리하기 어렵다.
애플리케이션 단위로 성능 분배 및 격리가 필요하다.
관리해야할 애플리케이션의 개수가 많아질수록 복잡해지고, 로드밸런싱 설정이 많아진다.
요런 이슈를 해결할 수 잇는 것이 바로 컨테이너의 등장!!!
현재, 업계에서는 쿠버네티스가 사실상의 표준으로 자리를 잡았다. (연사님이 한 말이고, 필자의 생각이 아닙니다)
카카오는 쿠버네티스를 어떻게 쓰고 있나?
쿠버네티스는 하나의 큰 쿠버네티스를 구축할 수도 있고, 멀티 클러스터를 구축할 수도 있다. 일단, 하나의 큰 클러스터 구축이 엔터프라이즈 환경에 적합한지에 대한 의문이다.
카카오에서는 멀티 클러스터 전략을 사용하고, 단점을 보완하기 위해서 여러가지 기능을 적용하였다.
쿠버네티스 관련 내용은 이정도로만 정리합니다. 세미나 막판으로 가면서 집중력이 많이 떨어졌고, 내용도 쉽지 않은 내용이라서 자세히 정리를 못했습니다..
카카오톡에서의 쿠버네티스(1) - 백엔드 서버 배포
카카오톡은 평소 동접자가 평균 45만 TPS 가 나오고, 최대 800만 TPS 까지 들어온다. 그래서, 배포시 트래픽 제어는 매우 중요하다. 트래픽이 충분히 빠졌을 때 배포를 해야 장애가 발생하지 않는다. 쿠버네티스를 통해서는 제어하지 못하기 때문에 직접 구현을 하였고, 시그널 핸들러를 직접 구현하였다.
서비스 디스커버리를 위해서 주키퍼를 사용하였는데, 주키퍼는 커넥션 관리도 할 수 있고, 직접 라우팅도 가능하였다. 어쩃든, 쿠버네티스 도입 전후 배포 시간을 비교해보니... 기존에 1.5 시간이 걸리던 배포 시간이 32분으로 단축 되었다.
카카오톡에서의 쿠버네티스(2) - 레디스
레디스를 사용하는데, 3500만 키를 사용하고, 마스터-슬레이브 에 센티널 인스턴스를 사용한다. 레디스 클러스터 환경은 아니다. (?) 센티널 인스턴스 Auto-FailOver 는 지원하지만 Automatic FailBack 은 지원하지 않는다. 이게 무슨얘기냐면... 레디스 노드가 죽었는데, 재시작을 어떻게 해줄 건인가? Sentinel 은 마스터 노드를 감지해서, 슬레이브 노드를 마스터 노드로 전환해주는 Fail Over 에 대한 역할은 수행하지만... 노드를 직접 재시작해줘야 하는 상황에서는 센티널 인스턴스로 해결할 수가 없다. 이런 기능을 적용하기 위해서 쿠버네티스에서 제공하는 기능으로 자동 재시작할 수 있도록 구성할 수 있다.
그래서...
추가로, 토폴로지 설정으로 하나의 호스트에는 하나의 노드만 실행할 수 있도록 설정이 가능하다... 라고 연사님이 설명하였다. (자세히 어떤 내용인지 조금 이해가 되지 않는다.)
개인적인 추가 질문
이번 컨퍼런스에서 처음이자 마지막으로 연사님께 찾아가서 몇개 질문을 하였다. (마이크를 잡는거는 부담스러워서 따로 찾아뵙고 문의드렸는데, 조금 죄송해서 질문을 한두개만 하고 바로 인사했다..)
1. (질문)레디스 클러스터 구조가 아니라, 마스터-슬레이브&센티널 인스턴스 를 사용 중이라고 하셨는데, 대용량 트래픽을 위해서, 클러스터 구조가 아니라 마스터-슬레이브 센티널 인프라가 괜찮은가요? (참고로 강연 중에서는 레디스 클러스터 환경이 퍼포먼스가 잘 나오지 않았다고 발표중에 말씀하심)
답변 - 레디스 인프라는, 여러 개의 그룹으로 나누어져 있고, 하나의 그룹에 마스터 노드 1 - 슬레이브 노드 2 로 구성됩니다. 센티널 인스턴스는 7개(?) 가 별도로 실행 중이구요....
2. (질문) 그렇다면, 클라이언트에서는 어떤 노드에 데이터를 쓰고, 읽어야 하는지 판단하나요? 또한, 어떤 클라이언트 라이브러리를 사용하나요?
답변 - 자체적으로 커스터마이징으로 구현한 해시룰을 적용합니다. Jedis 와 Lettuce를 사용합니다. (Lettuce 인지 Reddisson 이라고 하셨는지 정확히 듣지를 못했다...)
추가적인 질문이 몇개 더 있었지만... 발표하신다고 고생하신 연사님께 죄송하고, 소심한 마음에 더 질문하지 못했다. 클라이언트가 특정 키를 저장하는 노드를 판단하기 위한 해시룰을 어떻게 구현했는지에 대해서 좀 더 정확하게 알고 싶었고, 특정 그룹이 장애가 발생하게 되면 어떻게 되는지 등 고가용성 관련해서 궁금한 점이 많았지만, 질문하지 못해서 아쉬웠다.
세션 4, 참석 후기
주제 및 발표는 매우 유익하였고, 특히 연사님들께서 발표를 정말 잘하셨다. 단, 쿠버네티스에 대해서 잘 몰라서 조금 어려웠던 세션이었다. 또한, 막판에 레디스 관련해서 궁금한 점이 많았는데, 완벽하게 해결하지 못해서 아쉬운 마음이다. 레디스 인프라 공부를 열심히 해야겠다는 자극을 받게 되었다.
광고서버 연대기 - 카카오
마지막 세션은, 광고서버에 대한 연대기(?) 이다. 회사 업무 관련 주제라서, 매우 기대가 컸던 세션이었다. 하지만, 기술적인 내용은 전혀 없었고 광고 도메인에 대한 내용 및 카카오에서의 광고서버 연대기(?)에 대한 내용이었다.
세션 5, 참석 후기
주제 및 발표는 매우 유익하였고, 특히 연사님께서 발표를 정말 잘하셨다. 단, 조금 아쉬운 점은... 광고서버 기술, 아키텍처에 대한 내용을 기대했었는데, 기술적인 내용이 전혀 없어서 조금 아쉬웠다.
세미나를 참석 후기
작년에는 당첨이 되지 못해서 조금 아쉬웠는데, 올해는 운좋게 당첨이 되어서 유익한 시간을 보냈다고 생각한다. 대부분의 세션이 업무에 도움이 되는 내용들이라서, 매우 즐거웠다. 개발자의 기술 공유 및 소통에 대한 가치를 매우 중요하게 생각하는데, 이런 세미나들이 더 많았으면 하는 바램이다. 암튼, 참석 후기를 나름 열심히 작성하였는데, 세미나를 참석하지 못한 개발자들에게 조금이나마... (큰 도움은 못되겠지만) 아주 조금이라도 도움이 되었으면 하는 마음으로 늦은시간까지 후기를 작성해봤다.
2020 if Kakao 가 오는 그날을 기대하면서, 이상 후기를 마치겠다.
