QCon 2016 첫 날 이야기

처음으로 영어로 진행하는 컨퍼런스 참가의 충격이 꽤 컸나보다. 저녁 리셉션도 마다하고 숙소에 돌아와 바로 쓰러져서 7시에 잠들어서 이제야(새벽 4시..) 일어났다. 후닥 정리하고 아침먹고 이틀째 들으러 출발해야겠다.

영어로 세션 내용을 듣다 보니 제가 오해를 하거나 이해를 제대로 못한 내용이 담겨 있을 수 있습니다. 참고해서 봐주세요^^

사전등록

컨퍼런스 당일 등록하는 시간을 줄이기 위해 일요일 오후에 사전 등록을 받았다. 참석하는 사람들도 그걸 잘 아는지 사전등록 시작인 오후 4시부터 십 여명이 줄을 서 있었다. 1등 하려고 3시 30분쯤 도착했는데 1등 실패;

enroll

아무튼 사전 등록하니 뱃지와 QCon 로고가 프린팅된 텀플러 하나를 준다.

뱃지

텀블러사진

옆에서 티셔츠를 주길래 나는 왜 안주냐고 가서 물으니 지난해 듣고 다시 들으러 온 사람들만 준단다. 아.. 그럼 내년에 와서 받을게 라고 말하고 부끄럽게 퇴장.

컨퍼런스 당일 아침

9시 시작인데 8시쯤 컨퍼런스가 진행되는 하야트 호텔에 도착했다. 내 숙소와는 지하철(바트)로 4 정거장 거리인데, 덕분에 샌프란시스코 출근길을 경험했다. 지하철에서 빡빡하게 타고 핸드폰을 보며 각자 하루를 준비하는 모습이 왠지 익숙하고 편안하더라…^^

도착해보니 이미 사람들이 많았다.

아침

일찍히 도착했으니 커피 마시며 스폰서 부스를 돌아다니며 구경을 했는데, 관심이 크게 가는 부스가 없어서 좀 아쉬웠다. 평소에 관심가는 솔루션이나 회사가 있었으면 영어 공부도 할 겸 이것저것 물어보려고 했는데..

그나마 레고를 노트북 받침대로 쓰는 부스가 있어서 저걸 언제 준다는 건지 하고 주의깊게 본게 그나마 기억에 남는다.

lego

키노트

9시부터 본격적으로 시작. QCon을 만들었다는 Floyd씨가 나와서 이번 컨퍼런스를 소개했고,

floyd

오늘 진행하는 트랙 6개의 Host(라 부르네..)가 나와서 트랙별 내용을 소개해줬다. 2분 시간 제한으로 하라고 했다고 웃으며 다들 부랴부랴 설명을 했는데 이 순서가 꽤 좋았다.

자, 드디어 첫 번째 세션인 키노트.

keynot

하버드 대학에서 VR 연구하는 분이라는데 연구실에서 진행하는 VR 영상(Job Simulator 등)을 보여주며 재미있게 진행을 했다. 솔직히 PS VR을 경험해본 나로서는 꽤 시시한 이야기 였는데(ㅋㅋ), 동영상이 재밌었고 말을 워낙 재미있게 해서 금방 시간이 지나갔다.

다른 컨퍼런스에 비하면 키노트가 상당히 수수(?) 했는데, 개인적으로는 분위기가 정말 좋았다. 요즘 잘나가는 AWS나 오라클 컨퍼런스 가면 키노트에서 이런저런 발표를 하면서 우리가 이렇게 잘나가고, 이제 이런 것도 할거에요 하며 무언가 대단함을 느끼기를 강요 받는 분위기인데, 이번 키노트는 대학교 한 연구원의 연구기록을 공유하는 이야기에 모인 사람들이 하하호호 웃으며 즐기는 분위기였다. (이분이 이쪽 분야에 얼마나 유명하신 분이지는 잘 모르겠다..)

세션1. HOW SLACK WORKS(Keith Adams,Slack)

처음으로 들은 세션은 모두 다 아는 슬랙에서 치프 아키를 한다는 Keith Adams의 세션.

session1-intro

이 분은 나름 QCon 단골 발표자로 페이스북에 근무할 때부터 여러 발표를 했다. (예전 동영상 보기)

세션은 슬랙의 아키텍처를 간단히 소개하고 슬랙에서 스케일 확보를 위한 문제 해결 과정을 설명했다.

slack-scale

시작하자마자 나온 “Slack House Style”. 이 중 ‘Minimalism’이라는 표현이 참 마음에 들었다.

slack-house-style

이어서 ‘PHP is Good’ 얘기를 한참했는데 (ㅋ), 예전 직장이 페이스북이라 그런지 PHP에 대한 상당한 애정이 느껴졌다. 나는 PHP와는 전혀 관계가 없는 삶을 살아서 그런가보다 하고 지나감..

slack-php

카툰 아키텍처라고 부르며 간단한 아키텍처 다이어그램으로 설명을 시작했다.

여담으로 세션을 진행할 때는 정말로 조용히 집중하는 분위기였다. 그러다보니 내가 사진을 찍을 때마다 나는 ‘‘삐롱삐롱’ 소리가 내가 듣기에도 정말 거슬렸다. 정말로!! 그래서 세션 중에 부랴부랴 무음 카메라 앱을 검색해 설치했다. 그래서 소중한 첫 번째 세션 초반부 사진이 모두 날라갔다는 슬픈 경험을 했다 ㅠㅠㅠㅠ

다시 세션으로 돌아가면,

슬랙은 CAP 중 ‘A(Availability)’를 선택했다고 한다. 데이터 불일치(쫑, Consistency)은 당연히 발생할 수 있는데, 대부분 자동으로 해결되고, 그래도 안되는 건 직접 맞춰주면 되니 큰 문제가 아니라 생각한다고 한다. 슬랙이란 서비스 특징을 고려한 얘기라 생각하면 될듯. (그런데 여기서 MMR은 무슨 뜻인지를 잘 모르겠다.. 찾아보야 할듯.)

MMR Complications

P(Partitioning)는 팀 별로 구성을 했다고 한다. 이 내용을 포함해서 이번 세션에서 가장 인상 깊었던 내용은 MySQL를 사용해 데이터 처리를 구성한 방법이었다. 정리해보자면 이렇다.

팀 파티셔닝(Team-partitioning)이 자기들이 생각해도 잘 했다고 생각한다고. 아키텍처 상으로 이렇게 하나의 중요한 관리 단위를 가지고 간다는 게 참 좋아보였다.

Slack Today:Good parts

그리고 메세지 처리 Scale을 위해서 지연 처리를 하는데 여기서는 Redis 큐를 사용한다고 한다.

deferring work

마지막으로 좀더 복잡한 3가지 경우에 대한 처리 방법을 설명했다.

첫 번째로 메인이 실패했을 때, 두 번째로 큰 팀의 회원이 rtmstart를 할 때, 마지막으로 커넥션이 엄청 몰렸을 때를 들었다.

첫 번째 내용은 놓쳤고^^, 두 번째는 팀을 기준으로 움직이다보니 크기가 큰 팀의 회원이 접속 할 때 시스템 부하가 꽤 크다고 한다.(‘membership is O(n2)’) 그래서 로그인 후에 rtmstart를 지연 로딩을 처리한다고 한다. (lazily 로딩) 마지막으로 커넥션이 몰릴 때 문제를 해결하기 위해 flannel이라고 부르는 Application-Level Edge Cache를 운영한다고 한다. 메시징 서버에 바로 접속하는 게 아니라 flannel를 통해서 접속하는 방식이라고 한다.

이건 집중해 듣다보니 사진을 못 찍었다; 자료가 올라오면 다시 듣고 정리해봐야겠다.

세션2. DESIGNED FOR DEPLOYMENT(Badri Janakiraman,ThoughtWorks)

두 번째 세션은 ThoughtWorks에 Badri Janakiraman라는 분이 진행했다.

문제의 그분

MESOS 세션(애플)을 들을까 마지막까지 고민을 하다가 동영상을 제공하지 않는 세션을 들어보자 해서 들어간 세션인데 결론적으로 망했다 @@

시작할 때는 엄청난 로그가 올라가는 빌드하는 콘솔 화면을 보여주면서 기대감을 줬는데, 이걸로 무얼 설명하나 기대하고 봤더니, “자, 로그가 엄청 많고 안 보이시죠? 그렇습니다.” 하더니 자기 설명으로 넘어가더라;; 그리고 쭈욱 자기 말만 계속하다가 세션 끝.

각 세션이 끝날 때마다 좋음(초록), 별로(노랑), 망했다(빨강)를 뱃지로 체크하게 되어 있는데, 왠만하면 좋음을 주게 되는데 이 세션은 나 말고도 노랑과 빨강으로 투표하는 사람이 꽤 많았다. 나만 이렇게 느낀게 아니었나보다..

아무튼 남은 세션도 ‘우린 이렇게 했어요..’라는 내용을 다루는 세션을 듣자는 교훈으로 삼고 패스..

세션3. SCALING INSTAGRAM INFRASTRUCTURE(Lisa Guo,Instagram)

인스타그램의 13번째 직원이라는 Lisa Guo씨 발표.

SCALING INSTAGRAM INFRASTRUCTURE 시작

페이스북에 인수될 때 인스타그램 직원이 12명이었고, 본인은 그 뒤에 13번째로 입사한 사람이다라는 이야기로 시작했다^^. 세션 사전 인터뷰에서 페이스북 인수 전 AWS를 사용하다가 인수 후에 페이스북 데이터선테로 모두 이전한 경험을 얘기하던데 아쉽게도 세션에는 그런 내용을 포함해 설명되지는 않았다.

세션에서는 인스타그래에서 Scale을 확장을 위한 노력에 대한 이야기를 주로 했다. 흔히 우리가 알고 있는 ‘Scale-out’과 ‘Scale-up’에 더해서 ‘Scale-team’까지 3개의 축으로 삼았다. (오호!) (사진이 ㅠㅠ)

instagram-scale

기술 스택은 간단히 설명했고,

insta-tech-stack

스케일 아웃을 위해 gearman을 rabbitMQ로, redis를 cassandra로 바꿨고, PostgreSQL은 vertical partition&horizontal sharding(응?)한다고 했다.

insta-scale-out

그리고 나서 PostgreSQL과 Cassandra 역할과 구성에 대해 간단히 설명이 이어졌다.

scale-out-cassndra

인스타그램은 2개 (페이스북) 데이터 센터로 이중화 되어 있는데, PostgreSQL은 양쪽 마스터 Replication을 하고, Memcache는 데이터센터 별로 각각 운영한다고 한다. 그러다 보니 특히나 데이터센터 간의 Cache invalidate 문제가 자주 발생했고, 이걸 해결해 나가는 이야기가 이어졌다.

insta-cache-invalidate

첫 번째는 캐시를 안하는 것. 예를 들면, 카운트 부분은 SQL로 직접 처리한다고 한다. 100ms 밖에 걸리지 않기 때문에 Cache invalidate 문제를 해결하는 노력과 시스템 부담에 비하면 충분히 감내할만한 속도라 생각했다고 한다.

insta-counter

역시나 합리적인 생각에 박수를 보내고.. 이어서 중요한 부분인데 영어 듣기 미숙으로 내용을 놓쳐서 나중에 더 보강하기로..

insta-scaling-out

그중에 기억에 남는건 상시 부하 테스트를 진행하면서 진단하고 개선한다는 점이다. 파이선의 어떤 모듈은 사용한다던데 시스템 부하를 고려해 무언가 여러가지 내용을 한다는 이야기를 했다.. (역시 다시 정리를..)

insta-load-test

스케일 아웃은 강력한 메세지로 마무리^^

insta-dont-count-server

스케일업을 위해서 최적화를 진행한 얘기가 뒤를 이었다.

insta-요렇게분석해보니

CPU 덜쓰기, 서버 덜쓰기, 메모리 덜쓰기 등등..

insta-cpu-optimize

django의 Async IO를 사용한 이야기도 나오고,

insta-asyncio

‘도(TAO)’를 보여주며, 핵심적인 모델 간의 관계를 다룸으로서 최적화를 고려한다는 얘기를 하던데 이것 역시 다시 한 번 들어봐야겠다.

insta-tao

마지막으로 스케일링 팀. 노 브런치 정책이고 모두 다 마스터에서 개발한다고 한다.

insta-release

더 충격인건 릴리스 단위가 ‘diff’란다. (와우!!) 프로세스 설명을 해주던데, 단위테스트와 부하테스트를 거쳐 하루에 40~50번 정도 배포를 한다고 한다.

insta-ship-it-live

그 뒤에 문제가 발생하면 바로바로 ‘고친다’고..ㅎ

팀으로서 스케일 확보를 위한 노력이 중요하다고 얘기하며 마무리.

insta-takeways

세션4. Building Robust Web Applications With RxJS (Ben Lesh,Netflix)

RxJS를 개발하는 넥플릭스의 Ben Lesh 발표.

역시나 컨퍼런스 단골 발표자로 같은 주제로 발표하는 세션이 이미 많이 인터넷에 올라와 있다. (예전 발표 참조)

그래서 그런지 이번 발표는 무언가 새로운게 있지는 않고 웹소켓 얘기로 시작해서 왜 RxJS를 적용하고 어떻게 코드가 바뀌는 지를 주로 설명했다. 내용이 나쁘지는 않았는데, 새로운 것도 없어서 사진을 한 장도 찍지 않았다 ㅎㅎ.

끝나고 짜투리 시간을 활용해 RxJS 개발자랑 React 개발자 몇 명이 간단히 패널 토론을 했는데 두서 없이 진행하기도 했고 잘 못알아 들어 패스. 제대로 된 토론은 다음 세션에서 본격적으로 다뤄졌을텐니 동영상이 올라오면 봐야겠다.

다음세션

다음으로 들을 드롭박스 세션이 위 세션이 끝나는 장소에서 해서 갔더니만 끝날 시간인데도 끝내지 않고 계속 할정도로 역시나 인기가 많더라..

끝내라 좀!

나는 오히려 RxJS가 아니라 웹소켓의 Multiplexing에 대해 정확히 이해를 하게되어 유익한 시간이었다^^.

내 전문 분야가 아니라 lodash 등 이런저런 이야기를 하는데 감흥이 없었던 것도 아쉬웠던 점.

세션5. SCALING DROPBOX (Preslav Le,Dropbox)

드랍박스의 스케일링 확장에 대한 이야기를 주로 다룬 세션.

내용이 좋았지만 피로도가 정점에 달한 순간이었다. 발표하는 Preslav 목소리도 어찌나 평화롭던지 진짜 같은 음으로 노래를 처음부터 끝까지 부르는 기분? 이었다@@

전체적인 내용은 드랍박스 서비스의 스케일 확보를 위한 노력을 다뤘다.

Dropbox-scale-overview

이 세션은 통으로 다시 듣고 정리를 해봐야겠다. 슬랙 세션처럼 MySQL을 사용한 DB 스케일링 경험 내용도 나오니 꼭 들어봐야겠다.

Dropbox-scale-db1

Dropbox-scale-db2

세션6. STRANGER THINGS: THE FORCES THAT DISRUPT NETFLIX (Haley Tucker,Netflix)

오늘의 가장 듣고 싶던 세션. 재밌게 본 STRANGER THINGS 타이틀로 시작^^.

str-title

넥플릭스가 분산 시스템을 운영하면서 겪은 ‘이상한 3가지 경험’을 설명하는 방식으로 진행됐다. 특이한 점은 일부러 마이크로서비스라는 표현은 안 쓰고 ‘distributed system’이라는 표현을 사용한 점도 기억에 남았다.

str-dis-definition

심지어 모놀리틱 시스템을 분할(decomposing)했다고는 하는데 마이크로서비스라는 말은 안한다 ㅎㅎ.

str-decomposing-monolith

아무튼 오늘의 주제 3가지.

str-chapter-3

첫 번째는 비디오 카탈로그에서 장애를 겪은 일이다. (시스템 부하가 아니라 에러가 잔뜩 발생한 케이스)

str-err-ch1

비디오 메타데이터 아키텍처를 보면,

str-video-meta-architecture

메타 정보를 S3로 서비스 하는데 S3가 전 세계 리전에 퍼져 있다보니 Consistency 문제가 발생해버린 것이다. (Staggered Rollout이란 표현은 링크를 참조.)

str-staggered-rollout

절대로 벌어지면 안될 이상한 일이 일어난 거라고..ㅎ

str-no..

이를 예방하기 위해서 Canary Release를 적용했다고 한다.

str-prevent-canary

전체 배포가 되기 전에 Canary 서비스를 통해 Consistency 확인을 한다는 것이다.

str-data-canary1

str-data-canary2

두 번째 얘기는 로그 데이터를 쌓다가 전체 서비스가 다운된 이야기였다.

요렇게 로그 서비스를 운영하는데,

str-ch2-logdata

로그 서비스가 메모리 풀이 나버리는 바람에,

str-ch2-env1

시스템 장애가 발생해서,

str-ch2-env2

시스템 크래시 현상이 발생해 시스템 전체에 전파(Cascading Failure)되어 45분간 서비스가 다운됐다고 한다.

str-ch2-cascading

str-ch2-oom

이어서 이 문제를 해결하고 예방하기 위한 여러 노력을 설명했다.

‘Reduce surface area’라는 타이틀로 설명을 했는데,

str-ch2-rsa

일단 JAR 정리부터 했다고 한다. 불필요한 의존성들을 찾아내 제거했다는 것. 정리 전에는 JAR 목록이 무려 4개 페이지에 달했다고 한다..

str-ch2-jar

두 번째로 Limit “MAGIC”이었는데 무슨 내용인지 기억이 안나고;;

str-ch2-limit-magic

세 번째로 시스템 중단 기능을 넣었다고 한다.

str-ch2-add-kill-switches

네 번째로는 배포 시 변경 사항을 최대한 없앴다고 한다.

str-ch2-immutability

마지막으로 Circuit Break와 Failure Testing을 적극 활용하게 됐다고 한다.

Circuit Breaker는 잘 알려진 Hystrix 이야기였고, Failure Testing은 내일 이야기 한다고 자세한 설명은 생략.

str-ch2-failure-testing

정리해보자면 문제가 일어날 영역을 최소화 해서 자원 제약을 관리하고, Circuit Breaker 활용하고, Failure Testing를 엄밀히 진행하기로 했다는 점.

str-ch2-oeverview

마지막 세 번째 문제는 무거운 폴백 로직때문에 발생했다고 한다. 모니터링을 하다보니 응답속도가 주기적으로 뛰는 현상이 발생했는데,

str-ch3-env1

확인해보니 폴백 로직이 돌아갈 때마다 이런 현상이 발생했던 것이었다고 한다.

str-ch3-env2

넷플릭스는 서비스 간의 호출을 관리하는 클라이언트 JAR를 만들어 활용하는데 폴백 로직을 여기에 담아 배포해 사용한다고 한다.

str-ch3-clientjar

이게 지나치게 무겁다보니 응답속도가 엄청 떨어진 것이다.

속도 테스트를 해봤더니 이정도 였다고 한다.

str-ch3-fallback-testing

그래서 폴백을 가볍게 가져가고,

str-ch3-503

핵심 서비스와 그렇지 않은 서비스를 구분해 처리하는 것도 중요했다고.

str-ch3-cri-noncri

폴백은 3개로 구분해 처리한다고 한다. static, cache, service.

str-ch3-dis3

휴우.. 마지막으로 정리해보면,

str-review

첫 날을 마무리하며…

첫 날이다보니 세션 내용도 내용이지만 어떻게 듣고, 기록하고, 배울지에 대해 배운 소중한 시간이었다.

점심 시간이나 세션 쉬는 시간에 다른 사람들과 (짧지만) 이런저런 이야기를 나누게 되는데.. 자신이 만들어가는 서비스와 사용하는 기술에 대해 흥겹게, 아니 흥분해서 얘기하고 나누는 모습이 많이 자극이 됐다.

더 많이 느끼고 배우고 돌아가야겠다.