어제 Stripe 엔지니어들이 Redis에서 겪은 문제의 원인을 상세히 다룬 리포트를 썼다. 정말 감사한 일이다. Hacker News 스레드에서 나는 이제 diskless replication(http://antirez.com/news/81)이 있기 때문에 마스터-슬레이브 복제본 세트를 운영하는 사람들에게 persistence가 더 이상 필수가 아니라고 설명했다. 이는 설계상의 제약을 바꾼다. 이제 diskless 복제본 동기화가 가능해진 만큼, persistence를 끈 복제본 세트라는 Stripe의 (과거의?) 유스케이스를 더 안전한 방식으로 더 잘 지원하는 것이 가치 있는 일이 되었다. 이는 현재 진행 중인 작업이다.

같은 글에서 Stripe 엔지니어들은 Redis에서 문제가 있었던 유스케이스에 대해서는 PostgreSQL로 전환할 예정이라고 밝혔다. PostgreSQL은 정말 훌륭한 데이터베이스이며, SQL 데이터 모델과 온디스크 데이터베이스로 해결할 수 있다면 Redis 대신 그쪽을 쓰는 편이 나을 때가 많다. Redis는 초당 수많은 복잡한 연산을 확장해야 할 때를 위해 설계된 것이기 때문이다. Stripe 엔지니어들은 또한 99번째 백분위수를 측정했는데 PostgreSQL이 Redis보다 더 좋았다고 했고, 그래서 트윗에서 @aphyr는 이렇게 썼다:

“동기식 Postgres 복제가 AZ 간에서 비동기식 Redis보다 더 낮은 99번째 백분위수 레이턴시를 제공한다”

그리고 나는 이렇게 답했다:

“무슨 일이 일어나고 있는지 더 잘 이해하려면 평균 레이턴시도 함께 살펴보는 것이 도움이 될 수 있다. EC2에서 실행되는 Redis에서 발생할 수 있는 레이턴시 스파이크에 99번째 백분위수가 크게 영향을 받는다고 생각하기 때문이다.”

내 말의 뜻은, 평균값도 함께 보면 99번째 백분위수가 레이턴시 스파이크 때문에 망가졌는지 아닌지를 알 수 있고, 그런 스파이크는 대체로 해결 가능하다는 것이다. 보통은 아주 단순하다. 평균은 매우 낮은데 99번째 백분위수가 나쁘다면, Redis가 느리게 동작하는 이유가 예컨대 수행되는 연산이 매우 오래 걸리거나 블로킹되기 때문일 가능성은 낮고, 대신 EC2의 고질적인 문제들, 즉 특정 인스턴스에서의 fork 시간, 원격 디스크 I/O 등으로 인해 일부 쿼리만 느리게 처리된 것일 가능성이 높다. 이런 문제들은 충분히 해결할 수 있다. 예를 들어 fork 레이턴시 문제가 없는 인스턴스 타입도 있기 때문이다.

트위터 IT 커뮤니티의 절반에게 내 발언은 99번째 백분위수보다 평균 레이턴시를 올바른 지표로 옹호하는 것처럼 들렸다:

“평균은 레이턴시를 측정하는 최악의 지표다. 내가 본 어떤 레이턴시도 정규분포를 따르지 않는다. 평균은 nonsense다.”

“당신은 수학이 어떻게 작동하는지, 왜 분산 시스템에서 꼬리 레이턴시가 중요한지 분명히 이해하지 못했다. 여기서 끝내자.”

“맞다. 문제는 평균이 이상치가 있을 때 견고하지 않다는 것이다”

어, 누가 평균이 좋은 지표라고 했나? 나는 큰 이상치가 있는지 없는지를 감지하기 위해 평균을 보자고 제안한 것이다. 원래는 평범한 의견 교환이 될 예정이었는데, 10분 뒤 내 트위터는 내가 평균을 세상의 새로운 레이턴시 지표로 옹호하는 바보라고 말하는 사람들로 가득 찼다. 첫 리트윗이 나오자마자 점점 더 늘어났다. 심지어 다른 NoSQL 데이터베이스를 만든 유명한 개발자까지 시간을 내 트위터로 나에게 몇 가지를 훈계했다. 나는 내가 쓴 글의 요지는 99번째 백분위수에 평균까지 함께 보면 곡선에 대해 더 잘 파악할 수 있고 문제가 EC2에서의 Redis 스파이크 때문인지 이해할 수 있다는 것이었다고 답했지만, 마법처럼 원본 트윗이 삭제되면서 내 트윗들은 더욱 맥락에서 벗어나 버렸다. 내가 쓴 세 개의 트윗은 이렇다:

1. “내 요점은, 인터넷의 소음 속에서 이제는 유용할지 확신할 수 없지만, 평균이 왜 (…) 이해하는 데 도움이 된다는 것이었다”
2. “99번째 백분위수가 나쁜 이유를. 평균은 매우 좋은데 99번째 백분위수가 나쁘다면, 아주 나쁜 샘플이 몇 개 있다고 의심해 볼 수 있다”
3. “이건 Redis에서 유용하다. 제대로 설정하면 때때로 나쁜 레이턴시 샘플들을 크게 개선할 수 있기 때문이다.”

결과가 어땠겠는가? 심지어 누군가는 두 번째 트윗을 따로 떼어냈는데, 그 트윗은 “99번째 백분위수가 왜 나쁜지 이해하기 위해”(여기서 나쁘다는 건 좋은 수치를 제공하지 못한다는 뜻이다)라는 문장의 이어지는 부분이었는데, 그냥 맥락 없이 이렇게 읽어버렸다: “99번째 백분위수는 나쁘다”.

옛날에는 사람들이 유즈넷에서 며칠씩 논쟁하곤 했지만, 적어도 대부분은 주장에 대한 반박이 이어지는 식으로, 정상적인 대화를 할 만큼 충분한 텍스트와 맥락이 있었다. 하지만 지금 이건 그저 증오와 엔지니어링 기초 상식 101의 증폭일 뿐이다. 99번째 백분위수 레이턴시가 올바른 지표이고 평균은 형편없는 지표라고? 그렇다면 설령 평균을 언급하는 것이 타당한 맥락이라 해도 평균에 대해서는 입도 뻥긋하지 마라. 그렇지 않으면 쓸모없는 답글 1만 개를 받게 될 테니까.

이걸 어떻게 해야 할까? 다행인 점은 나는 개인적으로 이런 일에 크게 영향을 받지 않는다는 것이다. 하지만 동시에 나는 업무상 트위터를 사용해 Redis에 무슨 일이 일어나고 있는지 사람들에게 알리고 있기 때문에, 지금의 환경은 지속 가능한 작업 환경이 아니라는 것도 분명하다. 예를 들어 레이턴시만 해도 나는 레이턴시를 매우 중요하게 생각해서, 그동안 이를 개선하기 위해 많은 노력을 기울여 왔다(diskless replication을 포함해). 우리는 레이턴시 스파이크가 있는지, 왜 있는지를 파악하기 위한 모니터링도 갖추고 있다. Redis는 다양한 실행 경로를 모니터링해 내부에서 무슨 일이 일어나고 있는지에 대한 사람이 읽을 수 있는 리포트를 제공할 수 있다. 이 모든 작업을 해놓고 돌아오는 것은 백만 번 리트윗된 잘못된 메시지뿐이고, 이는 아무 도움이 되지 않는다. 대부분의 사람들은 스스로 판단하기 위해 트윗을 끝까지 따라가 보지 않는다. 현실은 이 시점에서 이미 재작성되었다. 내가 평균 백분위수가 좋다고 말했고 긴 꼬리(tail)를 봐야 한다는 걸 이해하지 못한다는 식으로 말이다. 다음에 내가 레이턴시에 대해 이야기할 때, 많은 사람들에게 나는 그 주제에 대해 생각이 그다지 명확하지 않은 사람이 되어 있을 것이고, 그러면 내가 무슨 말을 하는지, 무슨 작업을 하는지 누가 알겠는가?

동시에 트위터는 사람을 위한 RSS다. 내가 사랑하는 일, 즉 지금까지 정성을 들여 개발해 온 오픈소스 프로젝트에 대해 많은 사람들에게 소식을 전하는 데 극도로 유용하다. 그래서 지속 가능한 방식이 무엇일지 고민 중이다. 아마도 블로그 글을 더 많이 쓰고, Redis 메일링 리스트를 더 많이 활용하고, 트위터는 관심 있는 사람들이 읽을 수 있도록 링크를 공유하는 용도로만 쓰는 것이 방법일지 모른다. 그러면 관심 있는 사람들이 진짜 유용한 논의를 나눌 수 있을 것이다.

나는 Redis와 관련해 할 일이 많다. Redis를 잘 쓰고 있는 사용자들을 위해서도, 문제를 겪고 있는 사용자들을 위해서도 할 일이 많다. 트위터에서 불통인 대화를 나누기보다는 해킹에 시간을 쓰는 편이 낫다고 느낀다. 나는 논쟁하는 것을 좋아하지만, 이건 그저 부질없는 일일 뿐이다.