소개

다양한 데이터를 가지는 방법이 가능하고 Read/Write도 고속.
캐시 DB로서 뛰어나고 편리한 Redis입니다만, 확실히 데이터 설계를 하지 않으면 아픈 눈을 본다고 하는 체험담을 자해의 마음도 담아 씁니다.

애플리케이션 속도가 심하고 느려졌습니다.

응용 프로그램 속도가 저하될 때 newrelic의 성능 결과입니다.
보통이라면 100~500ms로 가라앉고 있던 퍼포먼스가, 그림대로 액세스의 피크시에 대략 3000ms, 심한 때라면 4000ms를 넘어, 흔히 서비스 자체도 떨어지거나 하는, 매우 정신이 빠져나가는 상황에 빠져 버렸습니다.
원인으로서는, 서비스 자체가 스케일 해 단순하게 액세스량이 늘어난 것에 의한 것으로 그 자체는 상정내의 것이었습니다만, 지금까지의 인프라 구성에서도 견딜 수 있으면 고를 구르고 튜닝을 검토하지 않는다 그 일이 속이고 결과, 자신의 목을 좁혀 버렸습니다.

무엇을 했습니까?

실제로 응용 프로그램의 어떤 처리에서 병목 현상이 있는지 먼저 조사하기로 결정했습니다.
PHP제의 어플리케이션이었기 때문에 blackfire를 이용해 검증했는데, 이 시점에서는 예상외의 부분, Redis의 get가 처리의 대부분의 시간을 사용하고 있는 것을 알았습니다.

애플리케이션 성능이 저하된 원인과 대응

이유는 간단했다.
실제로 Redis의 Key를 확인한 결과 하나의 키로 나누고 있는 데이터가 1GB를 넘고 있는 것이 다수 있어, get로 취득하는 시간이 무거워져 있었기 때문이었습니다.
덧붙여서, Redis는 싱글 스레드로 움직이기 때문에 하나의 프로세스가 막히면 다른 프로세스가 막혀 정체해 버립니다.
즉, 액세스량이 증가함에 따라 프로세스가 쌓여 성능 속도가 나빠졌습니다.

그래서 비대화된 Key를 세분화해 1개의 Key로 나누는 데이터량을 줄이고 퍼포먼스가 얼마나 개선하는지를 시험하기로 했습니다.

결과

피크 시에 3000~4000ms였던 퍼포먼스가 50~75ms, 평상시에는 30ms 전후까지 내려간다는 경이적인 개선으로 이어졌습니다.

요약

편리한 미들웨어는 많이 있습니다.
다만, 무엇을 사용해도 이용할 때에는 장래를 바라보는 데이터 설계를 제대로 하려고 하는 것이 아파할 정도로 몸에 걸었습니다. .
운용을 하는데 있어서 비대화할 가능성이 있는 데이터 등은, 최초의 설계시에 고려하는지, 정기적인 재검토나 튜닝등을 실시하는 것을 추천합니다.