어제 Stripe 엔지니어들이 Redis에 문제가 발생한 이유를 자세히 설명한 보고서를 작성했습니다. 정말 고마운 일입니다. Hacker News 댓글에서 저는 이제 디스크리스 복제(http://antirez.com/news/81)가 가능하므로, 마스터-슬레이브 복제 세트를 사용하는 사람들에게 persistence가 더 이상 필수는 아니라고 설명했습니다. 이로 인해 설계상의 제약 조건이 달라집니다. 이제 디스크리스 복제본 동기화를 사용할 수 있으니, persistence를 꺼 둔 복제 세트라는 Stripe의 (이제는 아닐지도 모를) 사용 사례를 더 안전하게 지원하는 편이 가치 있습니다. 현재 작업이 진행 중입니다.

같은 글에서 Stripe 엔지니어들은 Redis 때문에 문제가 발생하는 사용 사례에는 PostgreSQL로 전환할 예정이라고도 했습니다. PostgreSQL은 정말 훌륭한 데이터베이스입니다. SQL 데이터 모델과 디스크 기반 데이터베이스를 사용할 수 있다면, 초당 매우 많은 복잡한 연산으로 확장해야 할 때를 위해 설계된 Redis보다 PostgreSQL을 사용하는 편이 더 나은 경우가 많습니다. Stripe 엔지니어들은 99번째 백분위수를 측정한 결과 Redis보다 PostgreSQL이 더 좋았다고도 했고, 그래서 트위터에서 @aphyr가 다음과 같이 썼습니다.

“AZ 간 동기식 Postgres 복제는 비동기식 Redis보다 99번째 백분위 지연 시간이 낮다는 점에 주목하세요.”

저는 이렇게 답했습니다.

“무슨 일이 일어나는지 더 잘 이해하려면 평균 지연 시간도 살펴보는 것이 도움이 될 수 있습니다. EC2에서 실행되는 Redis에서 발생할 수 있는 지연 시간 급증이 99번째 백분위수에 큰 영향을 준다고 생각하기 때문입니다.”

즉, 평균도 함께 확인하면 99번째 백분위수가 지연 시간 급증 때문에 나빠진 것인지 아닌지 알 수 있다는 뜻입니다. 이런 급증은 많은 경우 해결할 수 있습니다. 대개는 아주 단순합니다. 평균은 매우 낮은데 99번째 백분위수가 나쁘다면, 예를 들어 수행한 연산 자체가 시간이 많이 걸리거나 블로킹되어 Redis가 느리게 실행되는 것이 아니라, EC2에서 흔히 발생하는 문제 때문에 일부 쿼리만 느리게 처리되는 것일 가능성이 큽니다. 특정 인스턴스에서 발생하는 fork 시간, 원격 디스크 I/O 등이 그런 문제입니다. 예를 들어 fork 지연 시간 문제가 없는 인스턴스 유형도 있으므로, 이런 문제는 대체로 해결할 수 있습니다.

그런데 트위터 IT 커뮤니티의 절반은 제 말을 평균 지연 시간을 99번째 백분위수보다 더 적절한 지표라고 주장한 것으로 받아들였습니다.

“평균은 지연 시간에 사용할 수 있는 최악의 지표다. 내가 지금까지 본 지연 시간 중 종 모양 곡선을 따르는 것은 하나도 없었다. 평균은 말도 안 되는 결과를 낸다.”

“분산 시스템에서 수학이 어떻게 작동하는지, 왜 꼬리 지연 시간이 중요한지 전혀 이해하지 못한 게 분명하다. 여기서 대화는 끝내자.”

“맞다. 문제는 이상치가 있는 상황에서 평균이 강건하지 않다는 것이다.”

어, 누가 평균이 좋은 지표라고 했습니까? 저는 큰 이상치가 있는지 없는지를 감지하기 위해 평균을 함께 보자고 한 것입니다. 그래서 평범한 대화라고 생각했던 일이 진행되는 동안, 10분 뒤에 보니 제 트위터가 평균을 세상의 지연 시간에 대한 새로운 지표라고 옹호하는 멍청이라는 말을 하는 사람들로 완전히 도배되어 있었습니다. 리트윗이 한 번 시작되면 점점 더 많은 사람이 달려듭니다. 다른 NoSQL 데이터베이스의 유명한 개발자까지 시간을 내서 트위터로 제게 몇 가지를 가르치려 들었습니다. 저는 제가 쓴 글이 99번째 백분위수와 평균을 함께 보면 곡선을 더 잘 파악할 수 있고, 문제가 EC2에서 발생하는 Redis의 지연 시간 급증인지 이해할 수 있다는 뜻이었다고 답했습니다. 그런데 이상하게도 원래 트윗이 삭제되어 버렸고, 그 결과 제 트윗은 더욱 맥락에서 벗어나게 됐습니다. 제가 쓴 세 개의 트윗은 다음과 같습니다.

1. “내 요지는, 인터넷의 소음 속에서 이 말이 아직 유효한지 확신할 수는 없지만, 평균이 왜 그런지 이해하는 데 도움이 된다는 것이었다(…)”
2. “99번째 백분위수가 나쁘다. 평균은 매우 좋은데 99번째 백분위수가 나쁘다면, 매우 나쁜 샘플이 몇 개 있다고 의심할 수 있다.”
3. “적절하게 설정하면 나쁜 지연 시간 샘플을 크게 개선할 수 있는 경우가 있으므로, Redis에서는 이 점이 유용하다.”

무슨 일이 일어났을까요? “99번째 백분위수가 왜 나쁜지 이해하려면”이라는 문장의 뒷부분인 트윗 2번을 따로 떼어낸 사람까지 있었습니다. 그리고 맥락을 제거한 채 “99번째 백분위수가 나쁘다”라고만 읽었습니다.

예전에는 사람들이 유즈넷에서 며칠씩 논쟁하곤 했습니다. 그래도 대부분은 새로운 주장에 대한 반론이 나오고, 그 반론에 대한 또 다른 주장이 이어지는 식이었습니다. 정상적인 대화를 나눌 수 있을 만큼 충분한 글과 맥락이 있었던 셈입니다. 하지만 지금은 증오의 증폭과 공학의 기본 원칙을 한데 뒤섞은 것에 불과합니다. 99번째 지연 시간이 올바른 지표이고 평균은 형편없는 지표인가요? 그렇다면 평균을 언급해도 의미가 있는 맥락에서조차 평균에 대해 말하지 않도록 조심해야 합니다. 그렇지 않으면 형편없는 답글을 1만 개나 받게 되니까요.

이런 상황에서 어떻게 해야 할까요? 제 장점 중 하나는 이런 일에 개인적으로 크게 영향을 받지 않는다는 것입니다. 하지만 저는 업무를 위해, 즉 Redis에서 무슨 일이 일어나고 있는지 사람들에게 알리기 위해 트위터를 사용하고 있기 때문에, 이곳이 지속 가능한 업무 환경이 아니라는 점도 분명합니다. 예를 들어 지연 시간 말입니다. 저는 지연 시간을 매우 중요하게 생각하기 때문에, 이를 개선하기 위해 수년 동안 많은 노력을 기울였습니다. 디스크리스 복제도 그중 하나입니다. 지연 시간 급증이 발생하는지, 발생한다면 왜 그런지 파악할 수 있도록 모니터링 기능도 마련해 두었습니다. Redis는 여러 실행 경로를 모니터링해 내부에서 무슨 일이 일어나는지 사람이 읽을 수 있는 보고서를 제공할 수도 있습니다. 이 모든 작업을 해 놓고도 결국 얻는 것은 잘못된 메시지가 100만 번 리트윗되는 일이고, 이는 아무런 도움이 되지 않습니다. 대부분의 사람은 직접 트윗을 따라가며 스스로 판단하지 않습니다. 결국 현실은 다시 쓰입니다. 나는 평균 백분위수가 좋다고 말했고, 긴 꼬리를 살펴봐야 한다는 사실을 이해하지 못하는 사람이 됩니다. 다음에 제가 지연 시간에 대해 이야기하면, 많은 사람에게 저는 지연 시간에 대해 명확하지 않은 생각을 가진 사람, 그래서 무슨 말을 하는지 또는 무슨 일을 하는지 알 수 없는 사람이 되어 있을 것입니다.

동시에 트위터는 인간을 위한 RSS이기도 합니다. 제가 사랑하는 일, 즉 지금까지 정성을 다해 개발해 온 오픈 소스 프로젝트를 작업하고 있다는 사실을 많은 사람에게 알리는 데는 매우 유용합니다. 그래서 지속 가능한 사용 방식을 고민하고 있습니다. 블로그를 더 자주 쓰고, Redis 메일링 리스트를 더 많이 활용하고, 트위터는 링크를 공유하는 용도로만 사용하는 방법도 있을 것 같습니다. 관심 있는 사람은 링크를 따라가서 읽고, 관심 있는 사람들끼리 실제로 유용한 토론을 할 수 있도록 말입니다.

Redis에 대해서는 할 일이 아주 많습니다. Redis를 즐겁게 사용하는 사람들을 위해서도 할 일이 많고, 문제를 겪고 있는 사람들을 위해서도 할 일이 많습니다. 트위터에서 이런 무의미한 대화를 나누는 것보다 코드를 작성하는 데 시간을 쓰는 편이 훨씬 낫다고 느낍니다. 저는 논쟁을 좋아하지만, 이건 그저 헛된 활동일 뿐입니다.