제가 레디스한테 전화하면요?😱

Honeybadger에서 우리는 자주 Redis를 사용한다.이것은 우리의 스위스 군도이다.그것은 캐시, 단일한 진실의 출처, 백엔드 작업 등을 저장한다.기본적으로, Redis는 영원히 실패하지 않을 서비스 중의 하나이다.
나 요즘 드워스 계시록을 생각하고 있어. 한 사람처럼. (레디스가 네 명의 기사 중 하나일까?)이것은 나로 하여금 우리의 #ops 채널에 뛰어들어 간단한 질문을 하게 했다.

josh [13:58]

what are the risks if someone executed flushall on our redis instances?

Ben [13:58]

you just gave me a micro heart attack

josh [13:59]

rofl

Sorry :)

I didn’t do it, for the record

Ben [14:00]

all kinds of badness would happen... the job queues would be flushed, there would be a potential for duplicate notifications, timeline charts would start hitting ES instead of being cached, and more :)

it would make for a very bad day :)

걱정하지 마라, 벤은 몇 시간 후에 회복되었는데, 기본적으로 다시 원래의 상태를 회복하였다.나는 먼저 나의 질문에 대답해야 한다.내가 정말로 우리 레디스 집단을 갱신했다고 말하는 건 아니야.그럼에도 불구하고 이것은 나의 관점을 증명했다.아마도 당신의 SRE를 끌고 그들의 땀을 측정하는 것은 재난을 계획하는 좋은 방법일 것이다...

그래서나는 잠재적인 문제를 발견했다.레디스 얼굴 빨개지면 큰일 나.이런 상황이 발생할 위험은 무엇입니까?

우리의 Redis 클러스터는 AWS의 여러 가용성 영역에 마스터 인스턴스와 보조 인스턴스를 배치하고 마스터 인스턴스에 장애가 발생하면 자동으로 보조 인스턴스로 페일오버합니다.상당히 견고한 리디스 배치다.우리는 데이터를 잃어버리지 않고 심지어 다른 서비스에 영향을 주지 않는 상황에서 전체 실례를 잃어버릴 수 있다.
불행하게도, 인위적인 오류를 방지하는 것은 훨씬 어려울 뿐만 아니라, 어떤 이유에서든지, Redis는 모든 데이터를 삭제하는 것을 매우 간단하게 하고, 잘못된 컨트롤러에 명령을 입력하기만 하면 된다.우리 건물은 이런 상황을 방지하지 않았다.우리 팀은 이 점을 의식하고 있지만 미래의 개발자들은 이 실수를 범할 가능성이 높다.

사실 제 친구 모리 스트루프(Molly Struve)는 케나 보안회사(Kenna Security)의 고급 SRE입니다. 비슷한 상황을 기억하고 있습니다.

We made a change to some code that caused the old cache values in Redis to break with the new code. So we would request the old value and it was not what the code was expecting. Rather than rollback the code, one of our engineers thought it would be fine to run Rails.cache.data.flushdb and just start with a fresh cache.

Honeybadger와 마찬가지로 Kenna는 Redis를 사용하여 몇 가지 일을 했다. 하나는 그들의 루비 온 레이스 프로그램의 캐시 백엔드였다.Molly가 언급한 명령Rails.cache.data.flushdb은 Ruby on Rails의 명령으로, Redis 콘솔을 열고 호출FLUSHDB(현재 데이터베이스에 있는 모든 데이터를 삭제)하는 것과 같다.
불행하게도, Redis는 Elasticsearch의 보고 데이터를 캐시하는 데도 사용된다. (참고로, 우리는 Honeybadger에서도 이렇게 할 것이다.) 이것이 문제다.Redis 데이터베이스를 새로 고칠 때, 처음부터 캐시를 다시 만들어야 합니다. 이로 인해 Elasticsearch 클러스터는 어찌할 바를 몰랐습니다.

We have a "Dashboard" page where clients can load part of ALL their reports (think hundreds), and when clients started to hit that without the cache, Elasticsearch lit up like a Christmas Tree. CPU maxed out on all nodes across the board. In the end it was a mad scramble to open multiple consoles to re-cache the reports.

케네의 시스템이 회복된 후, 모리는 개발팀과 협력하여 그들이 장래에 같은 일이 발생하지 않도록 어떤 조치를 취할 수 있는지 확정했다.그들은 Rails 캐시를 제거하는 것이 파괴적인 행위라는 것을 깨닫지 못했을 수도 있는 새로운 개발자에게 창조적인 보호 조치를 제공했다. they made all production application consoles read-only by default
다행히도 케네의 사고는 재난적인 것이 아니었다. 그들은 짧은 정지 후에 그 속에서 회복될 수 있었다.불행한 개발자가 의외로 호출하면 FLUSHALL 모든 Redis 데이터베이스를 새로 고칠 것이지 FLUSHDB 상황이 더 나빠질 것이다.압력 아래에서, 이것은 틀리기 쉽다. 특히 이상 보고가 굴러오는 상황에서 (그것들도 Honeybadger를 사용한다고 말한 적이 있습니까?)

당신의 Redis 컨트롤러에서 FLUSHALL을 호출하는 사람이 있다면 무슨 일이 일어날까요?

만약 답이 '모든 것이 붕괴될 것' 이라면 예방 조치를 고려할 수 있다.다음은 우리가 한 일이다.물론, 이것이 바로 우리 (나는 좀 의심스럽다) 이다. 너의 이정은 다를 수 있다.
우선, 클라이언트를 통해 Redis에 접근하는 것은 FLUSHALL 명령과 FLUSHDB 명령을 완전히 금지해야 한다.개발자는 생산 과정에서 이 명령을 실행할 필요가 없다.이렇게 하면 심각한 문제를 초래할 수 있는데, 왜 이런 문제가 생겼을까?
Ruby/Rails 사용자라면 언제든지 사용하십시오steal this gist.더 전면적인 것을 원한다면see Molly's gist.만약 네가 다른 프로그래밍 언어를 사용한다면, 이 명령들을 사용하지 않는 방법이 있기를 바란다. 그러나 설령 없다 하더라도, 걱정하지 마라. 알겠다.

모든 사람이 사용할 Redis 구성

Mike Perham은 Sidekiq(지금까지 가장 인기 있는 루비 백엔드 작업 시스템, 보유awesome business model)의 창립자로서 레드스에 대해 조금 알고 있다.Sidekiq는 Redis 위에 구축되어 매우 신뢰할 수 있고 효율적인 작업 시스템을 제공합니다.
나는 마이크에게 그의 고객에게 어떤 최선의 실천을 추천했는지 물었다. 그 중 많은 고객들이 관건적인 임무인 Redis (예를 들어 넷플릭스와 Oracle) 를 배치했다.그는 Redis 데이터가 안전할까 봐 걱정하는 사용자disable destructive commands entirely가 Redis 프로필을 통과해야 한다고 말했다.
이 방법은 redis-cli 컨트롤러에 포함된 명령이 어느 곳에서든 비활성화되는 추가 장점도 있다.다음 구성을 에 추가해야 합니다redis.conf.

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command SWAPDB ""

위의 명령을 빈 문자열로 이름 바꾸면 해당 명령이 더 이상 Redis 명령으로 존재하지 않습니다.만약 당신이 여전히 보기 드문 (의도적) 상황에서 그들에게 전화를 하려고 한다면, 당신은 그들을 비밀로 이름을 바꿀 수 있습니다.

rename-command FLUSHALL SUDO_FLUSHALL_222ed15a
rename-command FLUSHDB SUDO_FLUSHDB_2a3bdd5e

예를 들어, 당신은 이 명령들을 세계말일행동계획 수첩에 넣을 수 있으며, 당신의 행동팀만 이 수첩을 방문할 수 있다.회사의 핵 코드를 대하는 것처럼 그것들을 대하다.

물론 경고가 하나 있다🤦

우리는 아마존의 ElastiCache 서비스를 이용하여 우리의Redis 집단을 위탁 관리한다. 몇 가지 연구를 통해 ElastiCache는 redis.conf에 대한 직접 방문도 제공하지 않고 rename-command에 제공하지 않는다는 것을 알게 되었다Redis configuration parameter.그래서 불행하게도, 비록 우리의 응용 프로그램 컨트롤러는 안전하지만, 우리는 여전히 조심스럽게 처리해야 한다. redis-cli마지막으로 내부 Redis playbook에 이 점에 대한 설명을 추가했고, 간혹 Elasti Cache 문서를 다시 보면서 아마존이 접근을 허용하는지 확인합니다. rename-command

실패는 피할 수 없는 것이다

만약 고장이 발생하기 전에 100% 예방할 수 있다면 우리의 일은 훨씬 쉬워질 것이다.우리는 대기하거나 부검을 번갈아 할 필요가 없다. 우리는 모두 전담으로 코드를 작성할 수 있다.불행하게도, 우리는 현실 세계에서 생활하는데, 혼돈의 규칙과 엔트로피는 우리의 시스템이 끊임없이 악화되는 것을 확보한다.
우리가 하는 모든 일에는 내재된 위험이 있다.안정적인 응용 프로그램을 제공하기 위해서 우리는 위험을 최소화하는 조치를 취해야 한다.이렇게 함으로써 우리는 실패의 가능성을 줄였다.

당신의 행동과 관련된 위험을 평가할 수 있다면 개발자로서의 가치를 크게 높일 수 있다.

모리와 다른 사람들의 이야기는 나로 하여금 같은 일이 우리에게 쉽게 일어난다고 믿게 한다.위험이 매우 높다.잠재적으로 파괴적인 명령을 사용하지 않거나 실행하기 어려운 해결 방안은 비교적 쉽다.
고가치와 저노력의 결합에는 낮은 열매라는 이름이 있다.소프트웨어 방면에서 만약 당신이 작은 변화를 통해 많은 것을 얻을 수 있다면 이것은 가치가 있을 것이다.이것은 소량의 노력으로 큰 위험을 없애는 가장 좋은 상태에 처해 있음을 느끼게 한다.내가 처음 설치한 것 같아Honeybadger...;)
이 이야기는 최근 지역 사회 통신인 업그레이드에 보낸 이메일을 각색한 것이다.만약 당신이 좋아한다면, feel free to subscribe.