IF Kakao 참관기 Day01

Posted on | In

다른 회사들의 컨퍼런스는 어떤 식으로 내부 인원 수용이 이뤄지는지 확실하지는 않지만, 카카오는 내부 인원 또한 외부 참석자와 같이 무작위 추첨을 한다. 어떤 면에서는 매우 공정한 시스템일지도..? 그래서 카카오 내부의 많은 분들이 카카오 컨퍼런스임에도 아쉬움을 삼키며 참석하지 못하는 경우가 많다. 나는 운 좋게 하루도 아니고 이틀 모두를 참석할 수 있는 기회를 얻었고, 참석한 것에 대한 책임감으로 (물론 영상과 자료가 공개될 것이라 의미가 없을지도..) 참관기를 간단히 적어보려고 한다.

먼저 ifkakao 1회도 참석했던 나의 입장에서 1회보다는 더욱 나아진 진행이였다는 총평을 내렸다. 작년에는 처음으로 카카오에서 주최하는 컨퍼런스이기도 한만큼 다소 미숙한 진행 (정확히 기억은 안나지만, 스탭도 허둥지둥했던 기억이..) 이였다면, 올해는 공동체 모두 참석한 만큼 좀 더 성숙한 진행이 되었다고 개인적으로 생각한다.

그 외적으로 기억에 남는 것이라면, 파이콘과 같이 후원사를 받는 행사 같은 경우에는 각 사들이 부스를 열어서 세션 참가 외적으로 재미를 주는 부분이 있었다면, 아무래도 카카오 자체 행사이다보니 휑한 느낌이 있긴 했다. 물론 그렇다고 해서 컨퍼런스 참가자가 적었다거나 그런 뜻은 아니다. (실제로 한 세션이 끝나고나면 그랜드볼룸 앞이 꽉 차서 너무 정신이 없을 정도..) 그래서 따로 후원사를 받는 행사로 진행할 것이 아니라면 내부에서 간단한 코딩행사와 같이 부스를 열어서 세션 외적인 네트워킹이 활발하게 일어나게 하면 좋지 않을까라는 생각을 했다.

전반적인 소감은 여기서 각설하고, 참석했던 세션 별로 간단히 정리한 점과 느낀 점을 공유하려 한다.

1. 카카오에서 컨테이너를 활용하는 방법

발표자 : Hardy.Jung (카카오)

Link

카카오 컨테이너 플랫폼 현황

  • 컨테이너 서비스에서 필요한 것은 무엇일까?
  • 사내의 다양한 서비스들이 컨테이너 플랫폼을 사용하고 있음 (사내 서비스, 공동체 서비스 포함)
  • 컨테이너 오케스트레이터만 있으면 될까? 쿠버네티스 만으로도 가능할까?
    • 클러스터를 생성하기 위한 서버가 필요하다 → OpenStack (VM)
      • 장점 : 클릭만으로도 생성 가능, VM을 사용하면 자원을 효율적으로 사용할 수 있음 (하나의 물리 서버에 VM들을 여러대 모아놓음)
      • But, 항상 자원을 많이 사용하는 서비스는? → 간섭현상이 일어나기 때문에 이런 애들은 VM이 아니라 물리서버로 옮기고 있다.
  • 오케스트레이터는 모니터링을 안해주기 때문에 모니터링 서비스를 사용하고 있다 (Grafana 등)
  • 트래픽 처리는? Kubernetes Ingress, HA 구성 , LoadBalancer
  • 보안은요?
    • 컨테이너 이미지 보안
    • 출시전 서비스 보안
    • 주기적인 취약점 점검
    • 클러스터 외부로의 접근 제한 관리

컨테이너 이미지를 가지고 있는 것 : D2HUB

내부 도커 이미지 registry : DKOS

D2Hub

컨테이너 오케스트레이터

D2Hub 기능

  • 이미지 저장
  • 인증/ 권한 관리
  • Mirror 제공
  • 보안검수 → 이미지 들어오면 보안 검수를 함. 이미지가 들어올 때 백신 탐지나, 중요 취약점을 검출하는 그런 기능을 함

과연?

  • 기본이미지를 어떻게 할 것인가? : 시스템 엔지니어들의 오랜 경험으로 필요한 것들을 모음
  • 자동 빌드
    • 깃헙에 이벤트 발생하면
    • 빌드 완료 되고 쿠버네티스에 배포할 때 자동으로 카톡 알림 오게끔
  • 이미지 저장은 kage 사용

DKOS

  • 초반에는 mesos 사용
    • 사용자에게 개별 클러스터를 제공해주자
    • 운영서버가 따로 있었음
    • 운영서버가 모든 클러스터를 관리하는 것 같음 (그림상으로는)
  • but, openstack 네트워크 장애로 운영 클러스터 장애 → 전체 클러스터 장애로 전파
  • 그래서
  • 가운데에 API 서버를 두고, 설치 할 때만 API를 이용, 클러스터는 독립적으로 이용하도록 함
  • DKOSV3가 맞닥뜨린 기술적인 이슈
  • DSR : 클라 → 로드밸런서 → 쿠버네티스 ingress → (로드밸런서 안타고) 클라
  • 근데 그당시 상태로는 안됐기 때문에 Cilium을 사용하게 됨

Cilium은 잘됐을까?

  • vxlan을 사용하기 때문에 성능 저하가 발생하게 됨
  • 로드 밸런싱 이슈 : 버전 업그레이드로 해결할수 있었음

Ingress-Controller 로그 수집?

  • 이슈 발생시 분석에 필요
  • 컨테이너 오케스트레이터를 사용할 경우에는 컨테이너가 동적으로 옮겨다니는 특성 때문에 기존 보안 체계 적용이 어려움
  • 모든 걸 수집할 수 없었기에 로그 분류를 하게 되었음
    • Transaction : 전반적인 트랜잭션 관련
    • Request
    • Response 관련
    • Audit data 관련
  • 컨테이너는 stateless, 데이터 저장이 필요한 경우?
    • VM: Openstack Provider
    • 물리서버: NFS
  • 접근 제한이 걸린 외부 자원에 대한 접근 처리
    • 방화벽에 접근할 수 있는 IP를 따로 관리
    • 그러면 새로 워커 노드가 추가됐을 때는? → ACL관리를 위해서 보안담당자가 승인을 하게 되면 그 때 워커 노드를 추가하도록 함

K2Hub

  • 차트 관리
  • 사용중인 차트 관리에 필요한 정보를 제공 (차트버전 등등)

Cloud App Launcher

  • 소스만 등록하면 빌드해서 컨테이너를 실행해주는 서버리스 서비스
  • DKOS가 있긴 하지만 너무 많은 자원을 사용 (웹 페이지 하나를 띄우는 데에도 쿠버네티스 등등이 뜨게 됨 기본 3개가 뜸)
  • Knative → 구글에서 제공하는거. 서버리스 관련
  • 그럼 빌드는 어떤걸로 하나? buildpacks.io
  • 시연

이미 사용하고 있는 서비스이기도 했던만큼, 좀 더 이해가 쉬웠던 것 같다. 다만, 제대로 알지 못했던 부분도 있었던 만큼 위키를 뒤져보며 조금 더 이해를 해가면서 써야겠다는 생각.

2.초당옥수수의 취소를 막아라! : 수만 건의 주문을 1초내에 처리하는 기술

발표자: Sally, Dwayne (카카오 커머스)

LINK

첫 날에 들었던 세션들 중에서 제일 흥미로웠던 세션이였던 것 같다. 지연 배송이라는 액션의 중요성과 그에 대한 현업에서의 고민 등이 흥미로웠다. 두 분 다 말씀도 잘하셔서 더욱 그렇게 느껴졌을 지도.. 다만, 가장 넓은 R3룸이였음에도 자리가 없어서 서서 듣느라 제대로 필기를 못해서 아쉬웠던 세션.

03.Practical Microservices in gRPC Go

발표자: 모빌리티 5명의 개발자..

LINK

  • GraphQL, Kafka 활용

01. 서포터즈 기사

  • 대리기사 → 안정적인 수입 확보할 수 있도록
  • 강제 배정을 통해서 유저의 서비스 편익을 증대
  • 90개의 사용자 스토리를 가지고 있음.

02. 정리부터

  • 설계부터 단순하게
  • RFC (Request for comments)

03. 프로그래밍 언어

  • Java의 장단점
    • 익숙, os 독립, spring이 다해준다는 장점
    • 스프링 내부 보기가 힘듬, JVM 튜닝은 힘듬, os 독립이 크게 장점이 아님
  • 고를 쓰자 (자바에 대한 내부 의견 대립 후)
  • 25: 고의 키워드 숫자
  • 56: 자바의 키워드 숫자
  • 고루틴: 쓰레드와 비슷하지만, 기능이 적음. 대신, 훨씬 가벼움
  • 스프링의 가장 큰 장점은 의존성 주입
  • 고의 FX로 모두 달성 가능

04. 서비스 구조

  • 기존의 시스템 구조가 매우 복잡함
  • Microservice Architecture로 변경
    • 병렬적으로 간섭없이 개발하고 싶고, 독립적으로 배포하고 싶다는 니즈
    • 자주 작은 배포를 원함
    • DKOSv3를 잘 활용하려면 MA가 적절
    • 각 부분이 단순화되어 의사소통이 쉬워짐.
  • MA 단점
    • API 게이트웨이를 둠 → API호출이 MA에서는 다수로 늘어남.

05. 서비스계층

  • Restful vs gRPC
  • gRPB UI
    • Postmanㄹ과 유사한 인터베이스로 사용가능
  • gPRC gateway → gRPC를 Restful하게 노출 가능
  • IDL
    • npm install idl

06. 테스트

  • 부하테스트 → ghz
  • nGrinder → Load Test
  • 통합테스트
    • docker compose
    • postman
  • 배포 및 운영환경

07. if kafka

  • 메세지 흐름 단순화
  • 메세지의 영속성 보장, 유실방지
  • 패킷 오버헤드 감소
  • 자유로운 메세지 처리
  • 하나의 이벤트 메세지를 동시에 여러 서비스에서 소비
  • 메세지 버저닝

08. API 게이트웨이

  • graphQL → 하나의 엔드포인트
    • 클라이언트가 원하는 버전을 클라이언트가 선택
    • 문서를 따로 만들지 않아도 됨 (graphiQL)
  • nodejs 구현체 사용

09. 서비스 모니터링

  • 촉박한 출시일정으로 개발 완료 이전에 갖추지 못함.
  • 프로메테우스와 그라파나를 도입
    • 도커와 k8s에 최적화 되어 있음
  • zipkin 사용

10. legacies

  • traffic throttling(api server)]

11. 성과

  • 기사출근율, 운행완료비율, 배정후 취소율 모두 좋아짐.

어떤 과정을 통해서 문제를 해결했는지 설명해줘서 좋은 세션이였지만, 매 챕터마다 발표자를 바꾸면서 다소 산만해진 면이 있었던 것 같다. 각 챕터를 가장 잘 아는 사람이 발표한다는 취지였겠지만, 그렇게 자주 바꾼 것에 비해 과연 그 정도의 깊은 내용은 아니였다는 개인적인 생각.

04.Airflow를 활용하여 아름다운 파이프라인 만들기

발표자: Brandon.hg

LINK

01. 카카오페이지의 데이터 분석 문제

  • 2015년 대비 10배 성장
  • 크로스 데이터베이스 조인
    • Data Lake
      • 분산파일 시스템 기반
        • 싸고 확장성이 좋음, 안정성?
    • 데이터 레이크 구축 자체에 Airflow 사용

02. workflow management system

  • workflow
    • 작업 + 작업 간 의존성
  • DAG

03. Apache Airflow 시연

04. Airflow Architecture

  • scheduler
    • 실행주기가 되면 작업을 생성
    • 의존하는 작업이 모두 성공하면 broker에 넘김
  • worker
    • 실제 작업을 실행하는 주체
  • broker
    • 실행가능한 작업들이 들어가는 공간

  • meta DB

  • celery worker

  • HA broker

  • scheduler가 가장 취약함
    • failover controller
    • 공식적으로 지원하지는 않음

05. 카카오페이지의 Airflow 활용

  • DB 안에 테이블 개수가 많음.
    • pool and priority weight
      • pool: 동시성의 한계치 제어
      • weight: 풀 안의 순서를 제어 (priority)
    • 테이블 용량에 따라 두 개의 그룹으로 분리
  • 워커의 역할 분리 문제
    • impala, spark vs R
    • 큐분리
      • celery → airflow.cfg
      • worker → q option
      • task → queue 지정
  • DAG가 너무 커지는 경우
    • ExternalTaskSensor
      • poke_interval, timeout

팀에서 적용하고자 하는 개인적인 니즈가 있었기에 좀 더 주의해서 들었던 세션이였는데, 아마도 난도 조절 때문였겠지만 간단한 내용들만 다루어서 아쉬운 세션이였다. 때문에 같이 참석한 팀의 엔지니어 분과 세션 후 추가 질문을 했지만, 우리가 고민했던 포인트를 해결하지는 못함. 우리가 해당 문제를 잘 풀어서 해결해서 발표해도 좋겠다는 꿈?을 가지게 됨.

05.광고 데이터 처리 시스템 소개

발표자: k.ey

LINK

이전 세션 추가질문을 하느라 세션 시간을 놓쳐서 다소 늦게 참여하게 되었다. 이 세션 또한 서서 듣느라 + 늦게 들어간 탓에 완벽히 듣지 못했다는 아쉬움. 영상이 공개되면 다시 봐야지.

Day01 마무리

일부 세션에 대해서는 다소 비판적인 후기를 쓰기는 했지만, 발표 준비하는 것 자체가 얼마나 힘든지 뼈저리게 이해하고 있기에 다들 수고하셨다는 말씀을 랜선을 통해서 드리고 싶다. 이렇게 첫째 날에 대한 후기는 마무리!