RedisConf18 발표 후기

안녕하세요, LINE의 Redis팀의 최종열(Jongyeol Choi)입니다. LINE에서는 각 서비스별로 다양한 스토리지 시스템을 사용하고 있습니다. 그 중에서 메시징 서비스에서는 Redis, HBase, Kafka 등의 오픈 소스 스토리지 시스템을 많이 사용하고 있는데요, 저는 그중에서 특히 Redis와 관련된 부분들의 개발을 담당하고 있습니다. 그래서 그 연장으로, 지난 4월 26일에, 미국 샌프란시스코에서 열린 RedisConf18 컨퍼런스에 발표자로 참가해서, “Redis at LINE, 25 Billion Messages Per Day”라는 주제로 발표를 했습니다. 발표 준비부터, 컨퍼런스의 분위기, 발표에 대한 반응 등을 소개하겠습니다.

RedisConf란?

RedisConf는 RedisLabs라는 회사에서 주관하고 있는 컨퍼런스입니다. RedisLabs는 Redise라고 하는 엔터프라이즈 버전을 만들고 있고, 오픈 소스 Redis의 창시자인 Salvatore Sanfilippo씨가 일하고 있는 회사이기도 합니다. RedisLabs에서는 매년 ‘RedisConf’라는 이름의 공식 Redis 컨퍼런스를 샌프란시스코에서 개최하고 있는데요, 이는, Redis 사용자층을 확장하고, 여러 회사와 서비스간 서로의 노하우를 공유하는 목적의 기술 컨퍼런스입니다.

저는 Redis팀의 멤버로서, 작년에도 Redis 컨퍼런스에 참가했는데, 이때는 참관자로서만 참여를 했습니다. RedisConf17에서는 어떻게 하면 Redis를 더 잘 사용할 수 있을지와 다른 회사나 서비스에서는 Redis를 어떻게 사용하고 있는지 등을 조사하는 것에 관심이 있었습니다. 바람대로, 컨퍼런스를 통해 여러 회사들의 다양한 Redis 사용 방식과 노하우에 대해서 배울 수 있었습니다. 또한, 많은 발표들을 보고 들으면서, 우리의 사례를 발표해도 괜찮겠다는 생각을 하게 되었습니다. 그 배경에는, LINE의 사용자 수나 사용하는 트래픽이 다른 어떤 발표의 내용과 비교해도 상당히 높은 편이라는 점에 있었습니다. 서버 개발이라는 분야에서는 사용자가 많을수록, 또한 트래픽이 많을수록, 훨씬 다양한 문제가 발생합니다. 따라서 서비스를 유지하고 성장하려면, 더 정교하고 다양한 기술과 노하우가 필요합니다. 이러한 상황을 고려했을 때, LINE의 스케일과 노하우에 대해 발표하면 전 세계의 개발자가 흥미있게 들어줄 것이라는 생각을 갖게 되었습니다.

Call for paper, 그리고 발표 준비

많은 IT 컨퍼런스가 주로 미국에서 4월과 6월 사이에 개최됩니다. RedisConf도 매년 비슷한 시기인 4~5월 중에 열리고 있습니다. 저는 작년, 2017년 12월, RedisConf18에 대한 Call for paper에 대한 공지를 보게 되었습니다. 컨퍼런스 등에서의 발표자를 모집하는 것을 call for paper라고 하는데, 신청한다고 모두 발표하게 되는 것은 아닙니다. 정확한 경쟁률은 알 수 없지만, 심사를 거쳐서 일부 신청자만 발표자로 선정됩니다.

Call for paper의 마감은 2017년 12월이었습니다. LINE의 사용 사례를 궁금해하는 개발자들이 많을 것이라고 생각했기 때문에, 내용에 대해서는 크게 걱정하지 않았지만, 영어로 발표를 해야 하는 점이 고민이 되었습니다. 제 영어 스피킹 능력이 부족하지만, 오랜 기간 동안 준비하면 내용을 잘 전달할 수 있을 것이라는 생각에 call for paper에 응하게 되었습니다. 주제는 LINE 메시징 서비스에서의 Redis 사용 사례 및 여러 가지 노하우로 정하고, 이에 대한 abstract를 작성했습니다. 신청 양식에는 abstract 이외에도 여러 항목이 있었는데, 그중에 특이했던 것은 “Diversity”라는 항목이었습니다. 발표자의 성별, 인종 부문에서의 다양성을 추구하고자, 발표자가 여성이거나, 유색인종이거나, 장애인인지를 묻는 항목인데, 다양성을 존중한다는 점이 매우 인상적이었습니다.

2017년 12월 말에, 제가 제출한 발표 신청이 승인되었다는 메일을 받았습니다. 기쁘기도 했지만, 몇 달간의 길고 긴 준비의 시작이었습니다. 세션마다 주어진 시간은 45분이고, Q&A 시간은 5~10분이니, 발표 내용은 35~40분이 되어야 했습니다. 발표 날짜는 4월 25일 또는 26일이 될 예정이었습니다. 실제 준비는 1~2월이 되어서 시작했고, 시간이 날 때마다 발표 자료를 준비하고, 팀원들 앞에서 리허설을 하고, 의견을 받아 계속 수정을 해나갔습니다. 또한, 내용을 자연스럽고 부드럽게 전달할 수 있도록 사내 테크니컬 라이터의 도움을 받았습니다. 주어진 발표 시간을 고려해서 스크립트를 준비하고, 샌프란시스코에 도착해서 발표 전날까지도 계속 녹음을 하면서 연습했습니다. 제 발표는 둘째 날이었기 때문에, 발표 전에 컨퍼런스 분위기나 발표 장소를 확인하는 기회가 있었습니다.

첫째 날

RedisConf18은 4월 25일 수요일과 26일 목요일로, 이틀의 일정으로 구성되어 있습니다. 참가 등록자는 약 1,000 여명으로, 약 60개 정도의 발표가 이틀간 여섯 개의 컨퍼런스룸에서 나누어져 진행되었습니다. 아래는 RedisConf18이 열린 Pier27의 모습입니다. RedisConf18이라고 써있는 깃발이 걸려있는 모습을 보실 수 있습니다.

RedisConf18 Venue

몇 가지 간단한 기념품을 받고, 1층의 Expo Hall을 둘러봤습니다. 컨퍼런스에 대한 전반적인 정보와 일정을 제공하는 “Redisconf”라는 아이폰 앱과 안드로이드 앱이 제공되었는데, 제가 발표할 세션도 다음과 같이 앱에서 확인할 수 있었습니다.

Venue App

전시 공간 중에는 스티커를 가져갈 수 있도록 마련된 공간이 있었는데, 제가 미리 준비해간 LINE의 스티커를 놓아도 되는지 물어보고, 이곳에 LINE 스티커를 올려두었습니다. 브라운 캐릭터를 보고는 “The bear is cute!”이라며 좋아했고, 불과 한두 시간만에 LINE 스티커는 모두 사라졌습니다.

Stickers

키노트

행사는 Redis의 창시자인 Salvatore Sanfilippo씨의 키노트로 막을 열었습니다. 아직 릴리스 전인 오픈 소스 Redis 5.0의 주요 기능들에 대해서 이야기했습니다. 그리고, 5.0이 곧 릴리스된다는 이야기를 하고, 5.0의 주요 기능 중 하나인 Streams에 대한 설명도 했습니다. Sanfililippo씨의 이야기가 끝난 후, 다른 발표자들이 순서대로 나와 엔터프라이즈 버전인 Redise와 다양한 내용들을 소개하였습니다. Joel on Software라는 책과 Stackoverflow 사이트의 CEO로 유명한 Joel Spolsky가 나와서 인터뷰하는 시간도 있었습니다.

Keynote

첫째 날 세션

키노트가 끝난 후, 여섯 개의 컨퍼런스룸에서 각 세션이 진행되었습니다. 첫 번째 세션으로는, Salvatore Sanfilippo씨의 The Design of Redis Streams라는 세션을 들었습니다. 앞서 언급한 Redis Streams에 대해 조금 더 자세하게 소개되었습니다. 기존의 Redis를 queue 서비스로 사용하는 회사나 서비스도 상당히 많이 있는데, 이런 상황에서 Redis의 List 구조에 BLPOP, RPUSH 등의 커맨드를 사용합니다. 하지만, Redis의 List를 큐로 사용하기에는 부족한 기능이 많아서, Kafka를 사용하기도 합니다. LINE에서도 유사한 요구사항에 대해서 Redis 또는 Kafka를 사용하고 있습니다. 그런데, Redis 5.0에서는, Queue 등의 용도로 사용하기에 더 적합하도록 Streams라는 새로운 데이터 타입과 새로운 커맨드를 추가했습니다. 아직 릴리스되진 않았지만, Redis가 다른 데이터베이스보다 빠르다는 것을 고려하면, 유용한 부분이 많이 있을 것이라고 생각됩니다.

오전 세션 후에는 여러 대의 푸드트럭이 동원되어 참가자들에게 맛있는 점심을 제공하였습니다.

Foodtruck

오후에도 이어서 몇 가지 발표를 들었습니다. 그중, Slack에서 발표한 “Scaling Slack’s Job Queue Using Kafka and Redis”이라는 세션과, LyftRedis at Lyft: 2,000 Instances and Beyond라는 세션이 인상 깊었습니다. 업무용 메신저로 많이 사용되는 Slack에서는 Redis를 Queue로 사용하다가, 여러 가지 제약이나 신뢰성으로 인해서 Kafka를 Redis와 함께 사용하게 된 사례를 공유하였습니다. Slack은 LINE과 같은 메시징 분야에 있기 때문에 그들의 사례는 LINE과 비슷한 점도 있었고 상당히 다른 점도 있었습니다. Lyft의 발표자는 작년 RedisConf17에서도 발표를 했던 Daniel Hochman씨였습니다. Lyft는 Envoy Proxy라는 오픈 소스를 이끌고 있는 회사이기도 한데, 온디맨드 교통 서비스를 제공하고 있습니다. 예를 들어, 택시 운전사와 승객을 매칭해주는데, 승객이 원하는 시간이 지나면 매칭을 하는 것이 의미가 없어지는 서비스 특성상, 신뢰성보다는 반응 속도에 신경 쓴 부분이 인상적이었습니다. 이외에도 다른 발표들도 들었지만, 다음날 예정되어 있는 제 발표로 인해 긴장했기 때문에 좀처럼 집중할 수가 없었습니다. 첫째 날 일정이 모두 끝나고 난 뒤, 맥주와 먹거리가 제공되는 네트워킹 시간이 있었지만, 저는 긴장되는 마음에 호텔에 돌아가서 다시 발표 연습을 했습니다.

Sessions

둘째 날, D-day

드디어 발표 당일이 왔습니다. 듣고 싶은 세션이 많이 있었지만 오전에도 호텔에서 발표 연습을 했기 때문에 다른 세션에 들어가지 못했습니다. 둘째 날도 전날과 마찬가지로 여섯 개의 컨퍼런스룸에서 여러 세션이 동시에 진행되었고, 제 발표는 2시에 Van Ness홀로 예정되어 있었습니다.

Second Day

드디어 시간이 다가와 발표 준비를 하고, 마이크를 달고, 행사장 앞에 섰습니다. 감사하게도 많은 분이 들어오셨습니다. 발표 전 행사장과 저의 모습입니다.

Before Presentation

그리고, 제가 발표를 시작했습니다. 내용을 간단히 소개해 드리면, LINE에서는 메시징 서비스를 위해 Redis와 HBase, Kafka를 사용하고 있습니다. 매일 250억건 이상의 메시지를 배달하기 위해서, 약 10,000개 이상의 Redis 노드를 운영하고 있습니다. 많은 회사가 Redis 클러스터링을 위해서 프록시 방식을 사용하지만, 메시징 서비스는 응답 속도가 빨라야 하기 때문에, LINE에서는 프록시 방식 대신 Redis를 클라이언트측에서 샤딩을 하는 방식의 자체 Redis 클러스터를 주로 사용하고 있습니다. 샤드의 정보는 ZooKeeper에 저장을 하고, 각 애플리케이션이 이 정보를 동기화합니다. Redis 클러스터에서 특정 마스터 서버가 다운되서 오토 페일오버가 발생하거나, 호스트를 교체하는 등의 상황에서는 Cluster Manager Server라는 모듈에서 이 정보를 관리합니다. 수많은 Redis 노드를 초 단위로 모니터링하기 위해서 Scala와 Akka로 개발한 Redis Cluster Monitor라는 모듈을 만들어서 사용하고 있습니다. 그 밖에, Redis 3.0에서 새로 추가된 오픈 소스 버전의 공식 Redis Cluster를 도입하기 위해서 시행착오를 겪었던 몇 가지 문제를 공유하고, 비동기 Redis 클라이언트인 Lettuce의 도입에 관한 경험도 공유했습니다.

Presentation

발표 영상과 자료

제 발표 자료와 녹화 영상이 다음과 같이 모두 공개되었습니다. 관심있는 분은 확인해 보시기 바랍니다.


Q&A

주어진 발표 시간이 정신없이 지나가고, 샌프란시스코 또는 다른 나라의 여러 회사에서 온 다양한 배경을 가진 개발자, 비슷한 고민을 하고 있는 개발자, 다른 세션 발표자, 오픈 소스 커미터 등의 여러 분으로부터 많은 질문을 받았습니다. Q&A 시간이 끝난 뒤, 녹화가 종료되고 마이크가 꺼진 이후에도 많은 분들이 따로 질문을 하셨고, 장소를 옮겨서 대화를 이어나갔습니다.

QnA

제가 받았던 주요 질문들과 드린 답변들을 여러분과도 나누고 싶습니다.


Q. Dual Write와 Read HA 설명 관련, Kafka에서 write operation의 retry를 시도하면 얼마나 걸리나요?

Write operation의 재시도는, 현재는 애플리케이션 서버와 같은 박스에 설치된 로컬 Redis queue를 이용하고 있는데, 이 부분도 Kafka로 옮기는 것을 고려하고 있습니다. Kafka로 사용하면 몇백 micro seconds인 Redis보다는 좀 더 걸리지만, 그래도 몇 milli seconds 수준에서 가능합니다. HBase로의 write의 경우는, multi version이기 때문에, delay가 조금 있어도 괜찮습니다.

Q. Automatic bursting detection에서, Redis operation bursting이 너무 짧은 시간 동안 지나가면, 탐지할 수 있나요?

1초마다의 INFO 커맨드의 결과 내용으로 bursting을 판단하는데, 그 후에 MONITOR 커맨드를 보내기 때문에, 그 bursting이 매우 짧으면 탐지를 못할 때도 있습니다. 하지만, 많은 경우에 bursting의 중반 이후의 일부분은 탐지를 할 수 있기 때문에, 거기에서 어떤 코드와 관련이 있는지 추적할 수 있습니다. 또한, CPU가 100%이면, MONITOR 커맨드를 보내는 것이 상황을 더 악화시킬 수 있으므로, 특정 기준 이상일 때에는 automatic bursting detection을 시도하지 않습니다.

Q. Hot key와 replicated cluster 내용에서, read performance를 늘리는 것은 알겠는데, write performance를 늘릴 수 있는 방안이 있나요?

서버 한 대의 성능은 한정되어 있고, 같은 키에 대해서 write 성능을 향상시키기는 어렵기 때문에, 키의 데이터를 여러 키로 분산하는 식으로 비즈니스 로직을 다시 설계하는 방식으로 접근하고 있습니다.

Q. Redis Cluster 3.2 내용에서, 왜 used memory를 더 많이 사용하나요?

Redis Cluster 3.2는 키와 슬롯 번호를 매핑하기 위해 Sorted Set을 사용하는데, 해당 클러스터에 키가 많으면 매핑에 메모리가 많이 사용될 수 있습니다. LINE에서 사용하는 일부 클러스터에서는 이 부분으로 인해 standalone Redis를 사용할 때보다 메모리 사용량이 두 배가 되었습니다. Redis Cluster 4.0은 이 매핑을 위해 radix tree를 사용하기 때문에, Redis Cluster 3.2 보다는 메모리를 적게 사용하지만, 여전히 standalone Redis보다는 메모리를 많이 사용합니다.

Q. Asynchronous Task Processor에서 백그라운드로 write operation을 하면, Redis와 HBase 간에 inconsistency가 발생할 수 있지 않나요?

순간적으로 inconsistency가 발생할 수 있습니다. 하지만, ReadHA에서 대부분은 Redis에서 읽기 때문에, HBase에서 읽는 경우는 많지 않습니다. 또한, 메시징 서비스이기 때문에, 순간적인 inconsistency보다는 availability가 조금 더 중요합니다.

네트워킹 시간

컨퍼런스 둘째 날의 모든 발표가 종료된 후에, 사람들이 서로 모여서 네트워킹을 하는 시간이 있었습니다. 많은 사람들이 바로 떠나지 않고 여러 장소에서 이야기를 나누었습니다. 사진에는 다 나오지 않았지만, 뒷편에는 식당처럼 꾸며진 공간도 있었고, 바로 앞에 바다가 보이는 야외에서 맥주를 마시면서 대화를 나누는 사람도 많았습니다. 저녁에는 다른 장소에서 발표자들만 참가하는 소규모 스탠딩 파티가 있었습니다. 이 파티에서 저는 다른 발표자들과 이야기를 나누고, 관련된 기술에 대해 공유하고, LINE을 소개하기도 하고, 몇 가지 새로운 아이디어도 얻으면서 무척 의미있는 시간을 가졌습니다. 이렇게, 몇 달간 준비한 긴 발표 과정이 마무리되었습니다.

After party

글을 마치며

전 세계의 개발자들이 서로 노하우와 의견을 교환하고, 질문과 토론을 하는 것은 재밌는 일이었습니다. 해외 컨퍼런스에 단순하게 참가자로 참석하는 것과 발표자로 참석을 하는 것은 여러 방면에서 다름을 확실하게 체험하기도 하였습니다. 많은 개발자들이 관심을 가지고 질문을 하고, 서로 조언도 해주고, 저에겐 자극이 많이 되는 경험이었습니다. 준비 과정은 고통스럽고 끝나지 않을 것 같은 긴 시간이었지만, 그 결과는 달콤했습니다. 영어 발음에 대해서도 많은 걱정을 했었지만, 참석한 개발자들의 인종이나 출신지 등, 배경이 다양해서, 발음도 정말 다양했습니다. 물론, 제 발음이 듣기에 편한 발음은 아니었겠지만, LINE에서 다루고 있는 내용이 흥미롭기 때문에 많은 개발자들이 발음에 신경쓰지 않고 흥미롭게 들어주었습니다. 결국 중요한 것은 기술적인 내용이었습니다. 저희 팀은 여러분과 더 많은 내용을 공유할 수 있도록 계속해서 노력하고 있습니다. 또한, 이 여정을 함께 할 Storage Engineer도 일본과 한국에서 채용하고 있습니다. 저희 여정에 함께 참여하실 분들은 아래 채용 링크를 클릭해 주세요. 읽어 주셔서 감사합니다.

Related Post