쿠팡의 서비스 오류 원인이 ‘레디스 DB’ 문제인 것으로 드러났다.
24일 오전 7시경부터 쿠팡 판매 상품의 재고가‘0’으로 표시돼, 소비자는 관련 상품의 주문 및 구매할 수 없었다. 이에 쿠팡 측은 “재고 데이터베이스와 관련된 기술적 문제”라고 밝혔다.
이커머스 및 IT업계 관계자에 따르면, 쿠팡 시스템이 ‘레디스 DB’를 통해 데이터를 불러오는 과정에서 버그가 발생했다.
‘레디스(Redis)’는 오픈 소스 기반 데이터베이스 관리 시스템(DBMS)으로, 데이터를 메모리로 불러와서 처리하는 메모리 기반 DBMS이다. 속도가 빠르고 사용이 간편해 트위터, 인스타그램 등 여러 웹, 모바일, 게임, 애플리케이션에서 사용되고 있다.
그러나 속도가 빠른 만큼 다량의 데이터를 처리하면 버그가 발생한 가능성이 커진다. 처리 데이터가 많아질수록 더 많은 메모리를 요구해, 결국 용량 부족으로 알 수 없는 오류와 장애가 생길 수 있다.
자세한 내용은 출처에서
http://www.kinews.net/news/articleView.html?idxno=212904
/ N☢︎ JAPAN,일베 그룹 싫어요(댓글 서명)
그럼 오라클, MS 같은거 쓰면 와서 직접 코드까지 짜주나요?
이슈는 오픈소스를 쓰던, proprietary software (한글로 뭔지 모르겠네요)를 쓰던 다 생기는거고,
마치 오픈소스 쓰려면 그 소스는 다 보고 이해할 정도는 되어야 한다는 식이면 곤란하죠.
오픈소스는 비용이 저렴한 대신에 일반적으로 불친절하고 위험성을 안고 가는 겁니다. 매뉴얼이나 API 문서도 부실한 경우가 많습니다. 그래서 코드를 보고서야 동작을 이해할 수 있는 경우가 많고 코드 컨트리뷰터가 많을 수록 버그의 가능성도 늘 안고 가는 거죠. 쿠팡 같은 대규모 시스템에 오픈소스를 도입하려 했으면 내부 동작 정도는 코드를 보고 어느 정도 이해할 수 있는 수준에 이르러야 하고 문제가 발생했을 때 자체적으로 대처할 수 있는 건 기본, 그것으로도 부족하면 유료 기술지원을 계약하기 마련입니다. 그런데 이번 쿠팡 사태 이후로 나오는 기사들을 보면 마치 레디스 자체가 문제여서 당했다는 식인데 이딴 식으로 언플하면 안되는 거죠. 쿠팡에서 알게 모르게 이런 말을 흘리기 때문에 나오는 기사입니다. 당장 위에 기사만 보더라도 기자는 레디스가 뭔지도 모르고 기사를 쓴 게 명확해 보이잖아요?
오픈소스가 그정도로 허접하지는 않습니다.
버그가 있을때 혹은 유사한 상황이 생겼을때
정당한 사용자에게 즉각적으로 조치(패치)를 해줄수 있느냐(책임)하는 부분입니다.
이건 그 제품이 허접하냐 안하냐의 문제하곤 다른 부분이죠.
사용 환경이 다 다르고
수천만 수억의 경우가 있을텐데요.
디비의 최고봉인 오라클도 버그패치는 수도 없이 나왔습니다.
중요한 시스템에서 오라클을 쓰는 이유는
고성능이나 안정성도 있지만
이런 오류에 대한 여러가지 해법이 있거나
없으면 대응을 해준다는것이겠죠.
오픈 소스는 당연히 그런 부분은 부족할수밖에 없는거구요.
일반적인 상황에서의 둘의 비교는 의미가 없습니다.
그리고. 이번 문제가 디비의 문제였다고해도 허접하다는 평가도 맞지 않는거구요
이맛클!
레디스 빨라서 랭킹에 주로쓰던데
판매순위 같은거 여러명 동시에 보는 일이 생겼나 보네요 ㄷㄷㄷ
근데 레디스는 메모리 프레그멘테이션이 심해지면 free memory 가 기하급수적으로 줄어드는 특성이 있다고... 이번에 카우치베이스로 가시는게 어떨까함.
인메모리디비는 저장된 데이터가 많을수록 많은 메모리를 사용한건 당연한 이야기 아닌가요? maxmemory 채우면 어떻게 할건지도 eviction policy로 제어할 수 있는데... https://redis.io/topics/lru-cache
레디스 잘못이건 쿠팡 잘못이건 결과는 그냥 장애가 있다 없다 두가지
redis 사용량을 체크 하지 않고 개발자가 남발하면서 메모리 풀 났을 가능성이 높네요..개발자의 무분별한 redis data set 사용, 인프라의 모니터링 소흘 , 앞을 대비해서 적절한 샤딩 or 클러스터링 준비를 안한 탓 일 가능성이 90%입니다.
ClienKit3 . iPXSMax
https://www.slideshare.net/AmazonWebServices/airbnbs-journey-from-selfmanaged-redis-to-elasticache-for-redis-dat319-aws-reinvent-2018
제가 보기엔 운영이나 개발에 문제가 있었을것 같네요.
문제 생겼을때 책임전가하는 느낌이 드는데 제 기분 탓이겠죠?
이게 사실이라면 레디스 자체 문제보다는 쿠팡의 실수일 가능성에 무게를 두는게 맞지 않나 싶습니다.
그리고 오픈소스인 레디스 쓴게 일종의 리스크인양 기사를 적어놨는데, 엄연히 기업용 라이센스도 있는 엔터프라이즈급 소프트웨어인걸요 ㅎ
일단 기사가 레디스 정도의 키워드 빼고는 블라인드에 나도는 것보다도 못한 찌라시 수준입니다.
“그러나 속도가 빠른 만큼 다량의 데이터를 처리하면 버그가 발생한 가능성이 커진다. 처리 데이터가 많아질수록 더 많은 메모리를 요구해, 결국 용량 부족으로 알 수 없는 오류와 장애가 생길 수 있다.”
-> 이런건 거의 서버 사용률이 높아지면 장애발생률을 높힌다 수준의 전문성없는 아무말이죠.
레디스를 너무 믿으시는 분들도 많은데 코어뱅킹 같은 미션크리티컬한 워크로드에 믿고 쓰는 Oracle RAC같은 상용 솔루션도 버그는 늘 있습니다. 운용하는 규모도 일반적으로 필드에서 경험하는 것보다 훨씬 클 것이고 특정 사이즈나 클러스터 수에서만 경험할수 있는 버그도 많구요.
물론 개별 솔루션의 가용성, known issue들을 충분히 검토하고 아키텍쳐에서 커버해주고 적절한 재해복구 전략을 가지고 가야하는 것은 도입한 조직의 책임이지만요.
그렇다고 찌라시 가지고 깔 필요 있을까요.
음.. 뭐랄까 이미 레디스로 뜨악했던 업체들이 몇있죠 ㅎㅎㅎ
그렇다고 레디스 문제라고만 보기엔 어렵습니다 사용하는 부분에서 좀 조심해야한달까한 부분이 많은거같아요
장애는 항시 날 수 있는 것이고, 데이터 유실을 막는 것은 잘 만들어진 아키텍쳐의 힘이죠.
특히, 미션 크리티컬한 작업을 메모리안에서 오랜기간 뒹굴게 만든 것 자체가 잘못되었네요.
비지니스 레벨에서는 Couchbase를 쓰라고 합니다..흠.. 요건 조심스럽네요. 영업사원아닙니다. -_-;;
https://github.com/antirez/redis/issues/4493
어쨋든 회사책임을 피할순없죠.
대용량 레디스 버그 잘못이라고 쓰는건 정말 책임 전가라고 할 수 없겠네요.
그럼 인스타그램, 트위터는...?
redis에 문제 생겼다고 서비스 자체에 문제 생기는걸 당연시하는게 문제죠.
장애를 낸 누군가를 죽일 놈으로 만들려고 할 필요가 없는게, 장애는 누구나 낼 수 있고 그걸 막든 해결하든 하는 경험을 나눠줄 수 있는 사람은 장애를 그래도 내 본 사람들입니다. 무책임은 막아야겠지만 장애를 비난하지 않고 배워야겠다는 문화가 신뢰성 있는 운영을 만듭니다.
애초에 쿠팡이 레디스 탓을 한 것도 아닌데 뭐... 기자의 개인 의견은 그냥 전문성도 없어 보이고요 (레디스에서 이 문제가 시작되었을 수는 있습니다. 그렇다면 그 장애가 핵심사업역량을 반나절 중단 시킬 정도가 된 것이 과연 그 DB때문?? 그것은 의문입니다.)
이번엔 레디스 이야기하고
뭐랄까 우리 문제는 아님의 뉘앙스를 띄고 있네요
쿠팡 대박이네요.... 원인은 모르지만 레디스는 캐시 서버로 제일 많이 쓰고 있는 인싸 캐시인데 이걸 레디스 탓이라니요 ㅋㅋㅋ
설마 기자가 쓴 글을 쿠팡 공식 의견이라고 생각하시지는 않으실꺼구요.
반말에 예의없음으로 신고합니다.
그리고 난독이라니요. 예의가 참 없으시네요. 가오가오님이 다시 읽어보세요.
근데 쿠팡 관계자도 아니고 이커머스 및 IT업계 관계자????
오픈소스에 대한 부정적 이미지만 쌓이겠네요.
한 두군데에서 쓰이는 것도 아닌데.
레디스 클러스터 뻗었다고 서비스가 멈추는 건
온전히 레디스에 100프로 의존이란 소리라
미션 트리티컬한 서비스는 이렇게 설계하면 안되여.
암튼 고생 좀 하겠네요.
문제: Redis는 상용 대체제가 없다. 솔루션 뿐 (AWS 등)
레디스가 100단위 처리하는거랑 10000단위 처리하는거랑 동작이 다를텐데 무작정 레디스가 그럴리 없어! 하시는 분들이 계신듯;
위에 얘기처럼 쿠팡이 백업플랜이 없는게 까이면 까일거리지만