JJ BLOG

Ruby on Rails로 웹개발을 하고있는 웹개발자입니다.

DEVIEW DAY2 2019 후기

31 Oct 2019 »

intro

DEVIEW?
지식을 나누고 탁월함을 추구하며, 함께 성장하는 대한민국 대표 개발자 컨퍼런스 내일을 향한 개발자들의 시선이라는 의미를 담은 DEVIEW (Developer’s View). 개발자들이 축적한 지식과 경험, 노하우를 공유하여 대한민국 개발자들의 성장을 이끌어가기 위해, 매년 가을 개최되는 대한민국 대표 개발자 컨퍼런스입니다.


2019 DEVIEW가 코엑스 그랜드볼룸에서 열렸습니다. DAY 1에는 주로 AI에 대한 세션이 많았습니다. 저는 웹과 클라우드에 관심이 있었기 때문에 DAY2에 참가하게 되었습니다.

TimeTable 참가자 스케줄


1. Multi-Tenancy Kubernetes on Bare-Metal Servers (네이버 컨테이너 클러스터)

첫번째 세션으로 이종현님의 Multi-Tenancy Kubernetes을 들었습니다. 아직 쿠버네티스를 제대로 사용해보지 못했고 궁금해서 몇번 찾아보고 관심을 갖고 있었던 중이라 세션을 듣게 되었습니다. 세션의 내용은 네이버의 컨테이너 플랫폼 팀에서 쿠버네티스를 어떤 식으로 구현했고 운영하는 중이며 어떤 방향으로 나아갈 것인가를 다루었습니다.

“네이버 컨테이너 클러스터”는 네이버의 서비스/플랫폼을 서빙할 수 있는 컨테이너 인프라스트럭처를 제공하는 프로젝트입니다. 네이버와 같은 대규모 서비스의 경우 많은 수의 컨테이너를 관리하기 위해서 Multi-Tenancy Kubernetes를 도입합니다. 이는 단점과 장점이 있는데 제가 이해한 바로는 대규모의 쿠버네티스를 하나의 팀에서 관리하고, 이를 이용하는 나머지 팀과 다양한 리소스들을 공유합니다. 때문에 나머지 팀은 이 쿠버네티스를 이용하는 서버를 보유할 필요가 없으며, 이를 위한 여유 리소스를 확보하지 않아도 됩니다. 하지만 이러한 공유가 잘 이루어지기위해서는 모두가 쿠버네티스에 대한 지식이 있어야하며 공유하는 컨테이너에 신뢰성이 확보되어야합니다. 물론, 운영하는 팀은 큰 쿠버네티스를 운영하기에 힘들것입니다.

대규모 서비스에서 모두가 고민하는 예상치못한 실시간 트레픽을 오토 스케일링을 통해 대응하는 방법을 설명해주었습니다. 또한 여유 리소스를 보유하는 서버를 각 컨테이너들이 공유하여 리소스를 최소화하고 효율적으로 이를 활용하는 방법을 볼 수 있었습니다. 이후 클러스터가 커지면서 발생한 여러가지 이슈들에 대해 공유하였고 이를 해결하기위해 시도한 방법, 해결 방안 등을 공유해주었습니다.


2. Pinpoint는 어떻게 observability를 강화했는가

두번째 세션으로 구태진님의 ‘Pinpoint는 어떻게 observability를 강화했는가’를 듣게 되었습니다. PINPOINT란 대규모 분산 시스템의 성능을 분석하고 문제를 진단, 처리하는 java 플랫폼입니다. 네이버에서 개발한 오픈소스로 STAR 수가 굉장했습니다. 실제로 세계적으로 큰 기업에서도 사용하고 있습니다. MSA에 대해 공부한지 얼마 지나지 않아 MSA에서의 모니터링 방법에 대한 설명을 듣게되어 반가웠습니다. 세션은 Pinpoint팀이 해왔던 고민들과 이 고민들을 해결하기 위해서 해왔던 몇몇 작업들을 보여주었습니다.

Pinpoint는 대규모 분산환경을 이해하기 쉽도록 보여줍니다. 때문에 이를 이용하면 거대한 서비스 구조를 한눈에 파악하기 쉽고 문제의 원인을 빠르게 찾도록 도와줍니다. Pinpoint의 코어에 대한 내용은 ‘DEVIEW 2015’에 자세히 설명이 되어있다고합니다. 구태진님은 리얼타임기능을 구축하는 과정을 발표했는데 흥미로운 점은 pinpoint 내에서 데이터를 주고 받을 때 Handshake 방식을 사용한다는 것이었습니다. 이후 데이터 분산 모듈화를 위해 주키퍼를 사용하는 방식을 설명해주고 성능개선, 병렬처리등 많은 이야기를 해주셨습니다. Pinpoint를 사용해보지 못해서 내용을 이해하는데 조금 어려움이 있었지만 문제를 인지하고 해결하기까지의 과정이 흥미로웠습니다. Pinpoint는 더욱 많은 언어들을 지원하기위해 노력하고 있다고하니 기대가됩니다.


3. Fail Fast, Learn Faster SRE (실패에서 배워나가는 SRE)

세번째 세션은 SRE(Site Reliability Engineering)에 대한 세션이었습니다. SRE는 어떻게 하면 대규모 시스템에서 신뢰성을 보장할지 고민하는 기술 분야이자 방법론입니다. 네이버 검색의 SRE는 대한민국에서 발생하는 온갖 종류의 이벤트들에 대응하면서 성장하고 있었습니다.

세션 전 밖에서 여러 스타트업과 네이버 서비스팀의 부스를 돌아다니다가 그만 앞부분을 놓쳤습니다… 나중에라도 들어갔는데 세션이 너무 재미있어서 정말정말 아쉬웠습니다.

24시간 이상없이 운영이 되어야하는 서비스라면 규모가 커질수록 SRE를 도입해야할 것입니다. SRE라고 하지 않아도 이미 이러한 대응을 하는 곳도 많을 것 같습니다. 네이버에서 SRE의 필요성을 느낀 사건은 이전에도 많았겠지만 ‘2016년 경주 지진’이라고합니다. 지진이 발생하자 많은 트래픽이 특정 시간대에 몰리면서 네이버 검색 시스템은 약 10분간 마비되었습니다. 이러한 비상상황에 대응할 수 있는 체계가 없었기 때문에 본격적으로 대응 체계를 만들기 시작했습니다. 여러 예상되는 상황을 설정하고 대응 체계를 마련하며, 사후 비슷한 상황에 대한 대처를 할 수 있도록 기록합니다.

SRE의 목적은 서비스 장애에 대응하고 이를 방지하는 것입니다. 이러한 과정에서 소요되는 시간을 줄이기 위한 방법들에 대해서 발표해주었습니다. 또하 그 과정에서 발생한 경보의 빈도, 거짓 경보 등에 대해서 이야기해주었고 이런 이슈들을 어떤 방식으로 해결했는지 알 수 있었습니다.


4. 속도의, 속도에 의한, 속도를 위한 몽고DB (네이버 컨텐츠검색과 몽고DB)

다음은 몽고DB에 대한 세션이었습니다. 주로 몽고DB의 성능개선에 대한 이야기들이었습니다. 저는 평소에 RDB를 많이 사용하며 개발중인 서비스 또한 RDB를 사용합니다. NoSQL은 사용해본적이 없고 이에대한 글과 이야기를 많이 접해서 궁금하여 한번 들어보았습니다. 몽고DB는 문서(document)형 데이터베이스이며, hBase에 대한 이야기도 많이 해주셨는데 hBase 같은 경우는 빅데이터 처리를 한다고 하면 누구나 한번쯤은 들어봤을 법한 DB입니다.

세션에서는 Index의 용도와 목적에 맞는 사용법을 설명해줍니다. 또 너무 큰 Document에 대해서는 Thread를 이용해 작성하여 Upsert 한다고합니다.
저 또한 콘텐츠를 다루는 서비스다보니 주의깊게 들을 수 있었습니다.
* Upsert: 업데이트를 진행할 때, 만족하는 로우가 있다면 업데이트를 하고 없다면 INSERT 하는 것을 의미

Query Planner로 인해 발생한 이슈에 대해서 이야기해주었는데 재미있게 들었고, Query Planner라는 것에 대해 새롭게 알 수 있었고 한번쯤은 사용하는 DB의 Query Planner를 찾아보는 것도 재미있을 것 같습니다.


5. 쿠팡 추천 시스템 2년간의 변천사 (상품추천에서 실시간 개인화로)

5번째 세션은 가장 재미있게 들었던 세션입니다. 쿠팡의 추천 시스템에 대한 이야기로 어떤 방향으로 추천 시스템을 개발해 왔는지에 대한 이야기를 해줍니다. 서비스가 조금씩 성장함에 따라 더 많은 유저를 유치하고 활동하게 하기 위해 추천 시스템은 필수라고 생각합니다. 물론 쿠팡과 같이 e-commerce는 아니지만 쿠팡에서 다루는 상품(=아이템)에 어떤 것들을 대입해도 좋은 추천 시스템이 될 수 있을 것이라는 생각을 할 수 있었습니다.

쿠팡에서는 이러한 추천 시스템을 구축하기 위해 추천 모델과 서비스를 분리합니다. 이렇게 분리된 추천 모델은 서비스와 분리되어 있기 때문에 빠르게 개발 할 수 있으며, 다른 서비스에 적용하기도 수월합니다. 쿠팡의 추천 모델이 아이템을 추천할 때는 자연어 검색과 유사한 과정을 거칩니다. 쿼리를 통해 후보를 찾고 랭킹을 통해 아이템을 정렬합니다. 이후 실시간 로그를 관리하는 방식, 개인화 추천을 위해 사용되는 방식 등을 비교하여 잘 설명해주었습니다. 쿠팡의 세션을 통해 추천 시스템에 대해 더욱 관심이 생겼습니다. 특히 Item과 Item의 관계에서 Input과 Output을 통해 비유하여 설명해 주어 많은 영감을 얻을 수 있었던 것 같습니다.


6. 스케일아웃없이 순간 급증하는 주문 처리하기 (Microservice with Kafka)

마지막 세션으로 11번가에서 발표한 MSA로의 전환기 & Kafka 도입기에 대한 세션을 들었습니다. 세션 초반에 11번가가 MSA로 전환되기 전 서비스의 상태에 대해서 이야기해 줄 때 모두들 재미있게 들었습니다. 상품을 주문하기위한 대기열이 34913명이라고 표시되던 창을 없애고 싶었던 개발자 분들은 Kafka 기반의 MSA를 모색합니다. MSA의 게이트웨이를 이용하면서 만나게된 이슈들에 대해서 설명해 주었고 Kafka를 도입하게 된 계기, 도입하면서 생긴 이슈와 해결법들에 대해 공유해주었습니다. 물론 서비스 별로 어울리는 방식이 다르겠지만 다른 서비스의 구조를 볼 수 있고 설명을 들을 수 있다는 것이 정말 뜻깊었습니다.


이번 DEVIEW 2019는 제게 좋은 동기부여가 되었습니다. 항상 사용하는 기술만 사용하고, 매번 같은 서비스를 바라보니 생각이 이전보다 많이 닫혀있다는 느낌을 받았습니다. 같은 방식으로 개발하기를 고수하고 해오던 방식과 사용하던 기술만 사용하려고했습니다. 클라우드와 같은 많은 개발자들이 관심을 가질만한 기술들을 기웃기웃 해보기는 했지만 실제로 튜토리얼을 진행해보거나 깊게 알아보려는 노력을 하지 않았던 것 같습니다.

앞으로 많은 컨퍼런스를 다녀볼 예정이지만 컨퍼런스에 가기 전에 해당 기술에 대한 지식이 없다면 들어도 이해하기 힘들 것이라는 생각이 들었습니다. 이번에는 운이 좋게도 컨퍼런스 전에 공부했던 내용들이 많이 나와서 이해하기 어려운 부분이 많지는 않았지만 다른 컨퍼런스에서는 준비를 조금 해야겠다는 생각을 했습니다.


컨퍼런스에 대한 자세한 내용은 해당 홈페이지를 참고하세요!
DEVIEW 2019