brunch

라이킷 2 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by chan Feb 01. 2017

돈주고 겪어봐야할 소중한 장애

대국민급 장애 유발자 입장에서 쓴 경험하나 올려요~!

브런치를 만든지.. 어언.. 몇년..째.. 쿨럭.

블로그(http://gywn.net)를 제대로 관리하고 있지 않은 상황에서 브런치를 시작한 이유는.. 그냥 편하게 글을 쓸 수 있는 장소가 있으면 참으로 좋겠다는 생각으로 시작했지만.. 정말 너~무 편하게 방치만 한 듯.

사실은 바빴어..진짜로..

그래서. 요새 수다가 필요한 야심한 이 밤에. 기억에 남는 장애 한두개를 편하게 읊어보도록 할께.

장애이야기 1

언제였더라. 아마도 2014년 12월 중순즈음이었던 것 같은데. 멀쩡하던 서비스에 올-스톱! 장애 발생. 그것도 20분정도나.. 다들 멘붕에 빠졌었지. 나역시 멘탈은 안드로메다로.ㅋㅋ

원인은..??

pt-online-schema-change의 잔재로 남은 OLD테이블을 정리 작업을 하고 있었는데.. 그중, READ가 굉장한 서비스군의 용량 작은(아마도 3G였던 것으로 기억) 테이블을 하나 DROP하였고. 이후 대국민 사과급의 장애가 발생!

InnoDB adaptive hash index 경우에는 테이블 DROP시 캐싱된 Hash Index들을 한땀한땀 구조체에서 제거를 하는데.. 그것도, 그냥 지우지 않고 Lock을 걸고 지운다는..;;;

http://gywn.net/tag/innodb-hash-index/ (슬쩍)

그래서 이 작업이 끝날때까지 READ장애로 이어진.. 무시무시ㅜㅜ

이해가 어렵겠지만.. 말도 안되는 이야기지만..

32G 메모리에 20G 버퍼 환경에서 3G정도 사이즈의 OLD 테이블을 DROP했을 뿐인데.. 전면 장애가 났다는 말이지. 그것도 몇달전 테이블을.. 이걸 예측 가능이나 하겠어? ㅜㅜ 게다가 메모리에서만 서비스 하는 상황이었고.

20분동안 지속된 이유는.. 이 서비스군 특성 상 READ가 굉장히 필요한지라.. 1마스터/2슬레이브로 구성하였고, "유일하게" 슬레이브까지 묶어서, "유일하게" Adaptive Hash Index를 켜고 서비스를 하는 샤드군이었어. 아래 순서로 연달아 서비스 장애가 발생했던 것이지.

1) 마스터의 OLD테이블이 정상적으로 DROP <= 이 순간에는 마스터 유입 쿼리만 블록킹

2) 슬레이브로 해당 DROP 구문 전달/수행 연달아 빠방~~ 크항~!

그때 심장은 쫄깃쫄깃 술안주로 딱이었는데. 그때 생각해도 지금 생각해도. 내게는 정~말로 값진 장애였어.

(얄밉~)

장애이야기 2

뭐. 장애라기보다는.. 아래 글을 쓰게된 동기가 된 장애지.

http://gywn.net/2015/02/linux-cronjob-makes-disk-issue/

뭐 어찌보면 얻어걸린.. 값진 경험~

새벽이기도 하고, 서비스 오류까지는 크게 지속된 것 같지는 않지만.. 암튼.. 카카오와 다음이 합병된 이후 특정 서비스에 특정 시간에 주기적으로 디스크 유틸이 튀면서 서비스 타임아웃이 발생하는 케이스가 있었는데. 찾기가 꽤나 찾기 어려운 상황이었어.

위 블로그를 봤으면 알 수 있듯이, DB 쪽 이슈는 아니었어.

단지 뭔가 운이 나쁘게도.. 디스크 성능이 좋지도 않았고, 기본 리눅스의 스케줄을 써왔고.. 암튼 앞선 것처럼 엎친데 덮친격!

DB장애의 원인이 꼭 DB이어야할 필요는 없다는 소중한 경험이었어. 즉. DBA라면.. DB를 감싸고 있는 모든 것들을 봐야한다는..것이제~ ㅎ

(생각보다 3D직업이여~ DBA란. -_-;;)

장애이야기 3

한.두개는 뭔가 서운하니.. 한개 더. 나의 시야를 한단계 넓혀준 귀중한 장애인지라. ㅋ

이 장애를 겪기 전에는 IDC는 거의 대부분 IN SEOUL 혹은 NEAR SEOUL~ 수십 km 정도에서 서비스를 해왔었지. 그래서 늘 DB혹은 서버 이슈가 아니면 이상한 현상을 겪을 기회는 많지가 않았었어.

근데. 모서비스 오픈 당일. 두둥. 굉장히 느려진 것이지. 서비스 전반적으로.

결론적으로 말하면.. 네트워크 레이턴시가 원인이었어.

어이없는 결론이기는 한데. 이 서비스의 IDC는 데이터는 IN-SEOUL, 어플리케이션 서버는 남동쪽 제일 먼 도시에.. 두둥.. 대충 계산을 해보면.. 왕복 1000km라고 봐야하나.

왕복 1000km를 빛이 속도 30만 km/s로 따져본다면, 대략 아우토반 광라인으로 따져봐도 3~4ms 정도의 네트워크 지연이 발생하지. 머 중간중간 거치는 홉을 거쳐서 그런지는 몰라도.. 실제 ping 결과 레이턴시는 대략 7ms정도가 나오더군. 이게 별로 안커보이지?

근데.. DB 뿐만 아니라.. 어플리케이션에서 사용하는 캐시마저 서울에 있어버린다면.. ㅋㅋ 무시무시한 캐시 비효율이 발생할 것이지. (사실 내 입장에서 캐시없는 서비스는 상상도 할 수 없거든.)

일반적인 서비스라면 SET보다는 GET 메쏘드가 굉장히 많이 호출될텐데. DB의 부담을 줄이기 위한 GET메쏘드의 성능이 매 오퍼레이션마다 7ms라.. 특정 쓰레드의 최대 캐시 READ 처리량은 100gets/sec 정도이고. 캐시 사용 패턴 상 특정 트랜잭션당 여러 건의 GET이 있다는 것을 가정한다면.. OTL

서버는 죽어라고 일을 했건만.. 물리적인 제약을 넘지못해 장애로 이어진..

뭐.. 당시 기억으로는 DB와 캐시 모두 빠르게 남동쪽 나라로 이동시키면서 일단은 불을 껐던 것 같은..;; (사실 지금 생각해보면.. 캐시만 남동쪽 도시로 넘겨봤으면 어땠을까 하는 생각도. ㅋ)

오늘 얘기는 여기까지야. 뭐 이것저것 재미나고 귀중한 사례도 많았지만.. 더 쓰기에는.. ㅋㅋ

반드시 발생할 수밖에 없는 것이 장애라고 생각을 하는데.. 겪었던 장애로부터 값진 교훈을 얻었다면, 그보다 귀중한 장애는 없다고 생각해. 한번 겪었으니, 그 다음부터는 이런 일이 없도록 방지하면 될테니. ㅋㅋ

단지.. 가장 부끄러운 장애는.. 영혼없이 일을 하다 발생한 "손까락 부러뜨리고싶은 장애"와 이미 한번 겪은 문제를 간과하고 또다시 "동일 장애로 서비스에 문제가 발생"한 경우 두 가지라고 생각을 해. 내가 하든.. 남이 하든 이 두가지는 정말 이성을 잃게 만듬. ㅋㅋ

이모티콘 써보니 중독성 있네. -_-; 값진 장애 경험이 있으면.. 나에게도 알려주숑~ ㅎ