장애의 원인이 확인되었습니다. : 클리앙

고객지원

모두의공원

장애의 원인이 확인되었습니다. 110

466

2023-02-23 22:12:53 112.♡.46.225

최근 유사한 증상이 있었다는 국내 대형 쇼핑몰 두곳의 관련자들에게 확인해보니.

저희가 세션을 저장하고 있는 레디스가 한계 이상의 부하를 받으면 인덱스가 깨지는 증상이 발생했다고 합니다.

이번에 작업했던 여러 작업 중에 레디스 통신 최적화작업도 진행했으므로 다시 재발하지는 않을 것입니다.

또한 추가적인 최적화 여지가 있어 바로 작업에 들어갈 예정입니다.

님의

댓글 • [110]

nizakikaoru

고생하십니다 ㄷㄷㄷ

달려라쑈바

고생하셨습니다 그리고 정보 공유해주셔서 감사합니다

삭제 되었습니다.

위민

수고 하셨습니다.

고갱

확인감사합니다

King_Of_Snake

수고하셨습니다

nh1236

감사합니다. 고생 많으시네요... ㅠㅠ

하늘기억

모공인들이 부하를 일으켰군요.
접속을 좀 자제합시다. 읭?!?!

후레디

헐 레디스가.. 고생하셨습니다

everblue

수고많으십니다 -0-

삭제 되었습니다.

정말 다행이네요.

은비령

감사합니다. 고생 많으셨습니다.

하우디

원인파악이 되어 다행입니다.
한시름 놓으셨겠네요.
고생많으셨습니다.

여긴누구나는어디

고생하셨습니다

papi

흠 뭔지 모르지만 그렇군요

삭제 되었습니다.

@ 시민님
어렵지 않은데요?

걱정했어요 많이요 ~~

삭제 되었습니다.

서울촌놈

Redis를 세션 스토리지로 쓰는 곳이 많을텐데 타 사이트에서도 이슈가 많이 되겠네요

Naleo_

@서울촌놈님
보통은 그러니까 노드를 엄청나게 분산하지않던가요...

서울촌놈

@Naleo_님 네 그렇죠. 사전에 부하 예측을 하고 분산을 적정 케파시티로 적절하게 잘해야 하는데.... 음.. 뭐 이번 기회에 더욱 잘 개선하셨을거라고 생각합니다-! :)

bigegg

@Naleo_님
단순 데이타 저장을 위한 레디스가 아닌 세션을 위한 레디스입니다. 정합성 효율과 가용성 측면에 적정한 갯수를 정하지 무한정 늘리지 않아요..

시슬리아

고생허셧어요~~! 이제 안아프겠죠?

09120

고생하셨습니다.
원인을 찾았으니 홀가분하시겠네요. ㅎ

삭제 되었습니다.

오 원인을 찾아서 다행이네요!

삭제 되었습니다.

now_

https://n.news.naver.com/article/008/0004855017?cds=news_edit
비슷한 일이 올리브영에서 있었군요.

수달요정

분산 작업이 잘 된걸로 알겠습니다. 고생 많으셨습니다

그런일이 생길 수 있군요?

Varadero

누구보다도 가장 많이 답답하셨을텐데 원인 파악이 되어 한시름 놓으실 수 있겠네요. 며칠간 고생 많으셨습니다. 감사합니다.

화이팅입니다!

전국INFP협회

원인이 밝혀져서 다행입니다. 올영 이슈랑 같은 원인이었나보네요.

istD_어토

고생하셨습니다!

삭제 되었습니다.

80ted

오.. 하나 배워갑니다.. 그럴수도 있군요;;

abelkang

원인이 밝혀져서 다행이네요

복춘이

원인파악 되었다니 천만다행입니다!
순조롭게 처리 되길 바래요!!

eluxyl

사고 수습은 신속히 마무리됐지만 후속 조치와 관련해서는 문제가 제기된다. 개인정보 유출 발생한지 6일 뒤인 22일 오후에서야 올리브영이 한국인터넷진흥원에 신고해서다. 개인정보보호법에 따르면 개인 정보 유출 인지시 24시간 안에 개인정보보호위원회나 한국인터넷진흥원에 신고하고 유출 피해 당사자들에게 통지해야 한다. 올리브영이 피해 고객 1만명에게 사과문을 보낸 시점은 사건발생 7일 뒤인 23일 오전이다. 심지어 해당 문자를 받은 고객조차 본인의 피해 사실을 인지하지 못하고 있다.

우선 수고하셨습니다. 다만... 우리도 해당하는거 아닌가요....?

잘 모릅니다만 해킹이 아니니까 개인정보 유출과는 상관없을거 같습니다만…? @eluxyl님

lowsugar

eluxyl님//
장애의 종류가 유사할수 있는거지
개인정보를 담고 있느냐는 다른 문제죠.

선명

@모아레스님 '새로운 기기 로그인 알람 받기' 기능이 기본 설정이라서 이메일 주소가 노출되긴 했죠
이외 쪽지나 회원메모 같은 민감정보도 접근가능 했다고 봤습니다

내부적 오류니까 “접근가능”의 주체가 “운영자” 아닌가요 무식해서요 ㅠ @선명님

선명

@모아레스님 그냥 타인 계정에 로그인 된거라 비밀번호 한번 더 입력해서 볼수 있는 페이지 제외하고 다 볼 수 있었습니다.
그래도 로그인이 계속 풀려서 오래는 못했겠지만요

회사 인트라넷에는 방어벽같은게 있는데…그럼 음모론쪽으로 넘어가야하나요 누군가 유도했다? 의도를 가지고? @선명님

삭제 되었습니다.

헉…이제 그간 시나리오가 이해되네요
저 모아레스는 다른 닉넴으로 접속된 적이 전혀 없었습니다 ㅠ @잡일전문가님 @

bigegg

@잡일전문가님
크게 보면 개인정보 유출일수 있으나, 이 현상을 격은 고객만 한정되어 있습니다. 대량 유출이나 해킹사태는 아니면, 필요시 아이디가 유출된 사람들이 확인되면 거 안에서 진행하면 됩니다.

삭제 되었습니다.

bigegg

@잡일전문가님
내부자가 개인정보를 유출했던 해커가 유출했던, 버그로 인해 유출됐던간에 개인정보가 유출되면 해당정보를 보관하고 있던 회사는 책임을지고 조치를 치해야하는게 맞는것 같습니다.

물론 원인에 따라 책임소재에 대해 더 따져봐야 하지만요.

이번 클리앙 사건은 타인의 로그인한 사례가 잠깐 동안 일어나고 바로 시스템을 내려서 피해 확산을 막았으니 잘 넘어갈수 있을듯 합니다.

그리고 해결할려고 고생한 운영자 분들 감사의 마음 전합니다.

삭제 되었습니다.

다행이네요~고생하셨어요~ 포항항 ꉂꉂ(ᵔᗜᵔ)

선명

"레디스가 한계 이상의 부하를 받으면 인덱스가 깨지는 증상"
한계 이상의 부하가 왜 걸렸는지 원인은 파악하셨나요?
그날 있었던 디도스 대피소 오류 때문인지 아니면 다른 이유 때문인지 원인이 궁금하네요.

공팔은실이

언제나 수고 많으십니다!

고생 많으십니다. 화이팅임다!

빅웨이브

장애원인 찾기가 쉽지 않았을 것 같은데, 대단하십니다.
수고 많으셨습니다.

또하나의가족

문송합니다

레드핏클

헐 레디스가 상대적으로 비싼데.. 그런 오류가 발생하는군요 ㄷㄷㄷ

시간금방간다

고생이 많으십니다.

낮은바다

고생 많으셨습니다.

힘내십시오.

도마도

수고하셨습니다

paperless

수고하셨습니다.

ANALOG

수고하셨습니다!

ssongpoa

고생 많으십니다. 감사합니다

크로론

레디스가 시계열 데이터 쌓을때도 미묘하게 몇초 어긋나게 저장되기도하고...그렇드라구요...수고하셨습니다~!

삼알배엽바척

고생 많으셨습니다

miracle2021

수고 많으셨습니다.
덕분에 오늘 볼 수 있습니다. 감사합니다.

수고하셨습니다

??? : 레디스 부하 시킨놈 나와.
요.

회색말

고맙습니다. 최고 ~~~

lazyzeus

2019년에 쿠팡에서 발생했던 주문오류도 레디스 때문이었는데 이번에도 관련이 있군요.

수고하셨습니다~

야호호야

고생 많으셨습니다.

열매맺는나무

레디스 세션.. 정말 해결하기 까다로운 상황이었을 텐데, 다행히 원인 분석이 잘되셨나봐요. 고생 많으셨습니다!!

반건조우주오징어

고생 많으셨습니다.
알려주셔서 감사합니다.

marvelous

노고가 많으십니다!!!

songinnight

레디스 클러스터 모드로 5샤드 사용 중인데, 눈여겨 볼 부분이네요.
버전 상의 문제점은 없었을까요?
얼마 전 7.0.4 버전에서 7.0.5 권장 업데이트 했는데요

레이어마스크

와 컴백ㄷㄷ

배드문

아니니 외부의 공격없이 얼마나 접속을 많이하길래
부아를 받아 장애가 생기나요?
접속을 줄여 보겠습니닷 ㅋ

리트리셈

레디스는 트랜잭션 성격의 데이터 보관에 사용하면 안되겠더군요. 과부하 조건에서 무결성 보장이 안됩니다.
그냥 컨텐츠 캐시 딱 그정도 용도로만 써야될듯 해요.

elief

HA구성으로 replication 하고 계시다면 그에 따른 부하도 생각을 해봤으면 좋겠습니다.

elief

만일 HA구성이시라면 replication 상호 ack 주기 몇 네트워크 밴드위스 를 확인 해봤으면 좋겠습니다

삭제 되었습니다.

북극산펭귄

저도 레디스로 세션 주로 갖고 가는데, 사실 얼마나 강한 스트레스를 받으면 인덱스가 깨지는지 아직 감이 안잡혀요

예체

헐 쇼핑몰은 문제가 좀 더 심각하네요

jesusplus21

멋지다. 운영자님 요

삭제 되었습니다.

jiny7885

수고많으십니다

좋은하루하루

고생 많으시네요. 감사합니다.

운영자 분들 모두 고생하셨습니다. 감사합니다.

elfhazard

사실 레디스에 왜 목매는지…
이렇게 큰 저장소로 컸음에도 개발자가 제대로 확인할 수 있는 클라이언트도 제대로 없어요.
빨리 아파치 이그나이트가 대안으로 떴으면 좋겠는데.

삭제 되었습니다.

days

수고하셨습니다.

이리온jr

아하! 스프링 시큐리티에 래디스 세션 쓰시는군영 그럴 수 있져.. 그럼..

dain2001

노고가 많으셨습니다👏👏👏

neopage

개발에서 손땐지 오래지만 원인 분석 굉장히 어려웠겠단 생각이 드네요. 특히 오픈소스쪽 이슈니... 고생 많으셨어요.
제로보드 기반 시절이던 클리앙이 떠오르는군요. 그때도 많은 사용자들 수용하기 위해 여러가지 최적화 했던걸로 어렴풋이 기억이 나네요.

야웅이

원인분석 하시느라 고생하셨습니다. 잘 모르는 분야지만 참 원인 찾기 막막했을 거 같네요.

아보카도바나나

레디스에 그런 문제가 있었군요. 참고해야겠어요.

warugen

쉬운 설명 감사합니다.

부하는 시스템 용량의 문제고 세션의 내용이 다른 곳으로 보여지는 건 기능의 정합성문제인듯 한데요 어떻게 둘이 연관될 수 있을까요? 무슨 해쉬테이블에서 해쉬키 사이즈가 충분히 크지 못해서 충돌이 났는데 충돌 처리를 제대로 안 한 건가요? 이해가 되질 않네요. 오픈소스시스템이니 관련된 이슈트래커 페이지는 없나요?

@님

redis는 nosql이기 때문에 충분히 그럴 가능성이 있어 보입니다.

어떻게 보면 버퍼오버플로우가 발생될 수 있는 구조이기도 하고요.

@님 결국 key-value store인데 해쉬테이블에 키를 넣었는데 다른게 나올 수 있다.. 뭐 그런 말씀 하시는건가요? Buffer overflow는 key-value store와 어떻게 관련이 되죠?

삭제 되었습니다.

@잡일전문가님 C++ 코드 리뷰를 매일같이 하는 입장에서 죄송하지만 이해가 안 됩니다. 보통 buffer overflow는 입력값 처리가 잘 안될 때 생기는데 부하에 의해 생기는게 일반적이지 않을 것 같고요, 혹 그렇더라도 availability에 영향을 주지 consistency에 영향을 주진 않으리라 봅니다. DB쪽 전문가는 아니라, 혹시 관련된 이슈 페이지를 알려주시면 참조해보겠습니다.

삭제 되었습니다.

@잡일전문가님 일단 올려주신 이슈가 buffet overflow와 연관되는지도 불명확하고 단지 한 유저의 "우리 문제있어요 고쳐주세요"수준의 리포트에 실제 레디스 개발자의 원인분석은 전혀 없는 오픈 이슈인지라 어떻게 받아들여야할지 모르겠네요.

삭제 되었습니다.

양철북

레디스 부하라는 것이 용량을 말씀하시는 걸까요 아님 요청량을 말씀하시는 걸까요? 아예 실패를 하면 모를까 엉뚱한 value를 내보낸다는 것이 듣기만해도 참 오싹하네요.

삭제 되었습니다.

@잡일전문가님 여기도 유저의 리포트이지 실제 레디스 개발자의 원인 분석은 없네요. 부하가 data corruption과 어떤 연관이 있는지 설명이 없습니다. 또 그 corruption의 결과로 key-value query가 다른 값을 보내는지에 대한 얘기도 없고요.