티스토리 시스템 장애 관련

출처  : http://notice.tistory.com/

• 4월 11일 토요일 새벽 장애 발생 (41분간) : 갑작스러운 'Forbidden' 이라는 페이지가 발생한 것은 블로거 분께서도 지적해 주신바 있지만 새벽 DB 점검 작업을 마치고 서비스를 정상화하기 위한 최종 작업을 하는 과정에서 실수가 발생하였기 때문입니다. 서비스 장애가 발생하고 난 후, 마지막 작업 과정에서 실수가 있었다는 것을 확인하였으며 장애 발생 후 42분 후 정상화되었습니다. 다시 한번 실수로 인하여 피해를 드리게 된 점 진심으로 사과의 말씀드립니다. 개발팀에서 최종 배포 작업 시에 더 꼼꼼하게 확인 목록을 작성하여 실수가 일어나지 않도록 프로세스 및 모니터링 시스템을 강화해 나갈 예정입니다.

• 4월 12일 일요일 오후 및 자정 장애 발생 (10분간) : 갑작스럽게 DB 부하가 발생하면서 일시적으로 페이지 로딩을 하는 과정에서 실패가 발생한 것으로 파악되었습니다. 다만 11일 정상화 작업을 진행하는 도중 안내 페이지를 기존 버전으로 돌려놓지 않아 10일 점검 작업 메시지가 노출되었는데, 잘못된 안내 메시지로 인하여 혼란을 겪으셨을 여러분들께 사과의 말씀드립니다.

• 4월 13일 월요일 오전 장애 발생 (10분간) : 일요일에 발생하였던 유형과 유사한 패턴의 DB 부하로 인하여 일시적으로 페이지 로딩 실패하는 건 수가 갑자기 증가하여 공지 블로그를 비롯하여 많은 개별 블로그 접속이 원활하지 않은 문제가 발생하였습니다. 이에 따라 DB 부하를 초래하는 모든 요소들을 모두 모니터링하였으며, 일부 직접적인 문제가 될 수 있는 부분들을 제거함에 따라 정상화 되었습니다.

• 4월 16일 오후 DNS 서버 장애 (약 50분간): 일부 블로그 이용자의 지역 환경에 따른 접속 문제로 인하여 DNS 서버를 확장하는 과정에서 일부 블로거분들께서 DNS 서버에 접근이 어려워 블로그에 따라 접속이 되었다가 되지 않았다가 하는 모습을 보였습니다. DNS 서버 복구를 통하여 해결하였습니다.

• 4월 17일 새벽 권한 설정 장애 (약 1시간) : 팀블로그 및 몇 가지 권한설정과 관련하여 정책을 정리하고 배포하는 과정에서 일부 오류가 발생함에 따라 공지블로그 및 일부 블로그의 비밀댓글이 로그인을 한 상태인 다른 티스토리 이용자들에게 보였습니다. 고객센터 및 공지의 신고에 따라 오류 처리가 되었사오나, 이 오류로 인하여 피해를 입으신 분들이 없도록 더욱 주의를 기울이도록 하겠습니다.
  

이렇게 공지가 올라왔다. 이렇게 투명하게 공지를 올려준 티스토리 담당자 여러분께 깊은 감동을 우선 보내고 싶다. 이렇게 투명하게 쓰는 것이 쉽지는 않았으리라.
과거 내 경험을 가지고 이런 문제를 어떻게 해결해보았나.. 생각해 본다.



1. Forbidden 문제
이 문제는 apache 설정과 밀접한 연관이 있다. 보통 403 apache error를 의미하는데, 바로 Forbidden이 나왔다는 것은 아파치 설정에 문제가 있음을 의미한다. 보통 Alias를 주어서 아파치 디폴트 페이지 (Forbidden)이 나오지 않도록 하고, 일반적인 접근 에러 페이지를 나오게 하도록 하는 것이 좋다.
개발자가 아파치단을 막으면서 배포단계에서 문제가 있지 않나 싶다. 또한 40분 넘게 넘게 나왔다는 것은 개발자가 테스트를 안했다는 뜻이 된다. 이건 결국 모니터링과 밀접한 연관이 있다.
이 문제를 해결하기 위해서는 아파치 설정에 대해서 Source Repository를 두어서 따로 관리하고, 소스-배포-실배포될 서버의 설정이 모두 같이 되도록 하는 것이 좋다. 그래야 일반적으로 실수가 적게 할 수 있다.

실수를 하더라도 모니터링이 된다면, 바로 수정을 하고, 40분을 시간을 짧게 할 수 있다.
* 모니터링
모니터링 서버의 중요성은 바로 이럴 때 드러난다. 먼저 문제를 빨리 발견하게 한다. 일반적으로 토파즈나 내부 모니터링 서비스가 각 서브 도메인별로 모니터링을 하도록 한다. 또는 내부 개발용으로 만든 웹 어플리케이션 모니터링 서버가 있으면 참 좋다.
apache, tomcat, 기대값 충족 필터링 이렇게 단계별로 테스트하는 것이 좋다.
한편 네트웍단에서 L7 체크을 이용하면, 충분히 이런 문제를 해결할 수도 있다.


2. DB 부하
서비스가 인기를 끌면서 데이터량은 많아지면서 많은 웹 서버들이 DB에 붙게 된다. 과거에는 한두개 DB로는 붙을 수 있었지만, 집중화되면서 DB의 성능을 저하시킨다.
 특히 blob과 같은 데이터들은  DB속도를 느리게 한다. 이때 너무 많은 DB connection을 한두개의 DB와 붙지 않도록 한다. oracle 10g의 경우는 한 connection당 9~10mb를 차지하기 때문에 connection 비용을 비싸게 지불해야 한다.
또한 DB의 특정 파라미터는 문제를 또한 야기시킬 수 있다. DB를 업그레이드 하거나 특정 IDC로 이전하면서 OS 버젼업을 하면서 DB 설정 파라미터에 따라서 (아주 사소하더라도) 크게 영향을 미칠 수 있다.
그리고, 제일 중요한 것은 배치성 쿼리이다. 이 배치성 쿼리가 사실 제일 큰 문제를 야기시킬 수 있다. 특히 티스토리의 경우는 어드민에서 유입 경로등 다양한 정보를 보여주는 부분이 있어서 이런 배치성이 문제가 없도록 해야 한다.
만약 특정 시간마다 DB cpu 증가나 장애가 나타나면, 거의 90%다.
쓸 때없이 full indexing하는 쿼리나 indexing이 없는 테이블들.. 그리고 쓸 때없이 돌아가는 배치들을 다 정리해야 한다..
배치 한녀석 킬했더니. DB가 정상화된 적이 있다. ㅡ.ㅡ;


3. DNS 관리
시스템 이나 인프라 관련 담당자들이 자주 실수하는 부분이기도 하다.
DNS 설정시 간단하게 리눅스 데몬형태로 설정파일을 가지고 돌리는데. 이 도메인을 제대로 syntax checking이 되지 않는다. 처음엔 잘 돌아가나 싶더니. 갑자기 서비스 장애가 되서 보았더니. 도메인을 제대로 못적었다는.. DNS 서버에 도메인 추가할 때는 pair로 하는 게 가장 좋다..
결정적인 버그인데. 요즘은 이걸 어떻게 하나 모르겠다.이런 문제를 쉽게 해결하기 위해서는 서비스쪽 도메인과 개별 서버의 도메인은 분류를 해야한다. 서버 증설시 분류된 DNS 서버를 사용해서 서비스와 개별 도메인 서비스 도메인을 분류해서 문제가 없도록 해야 한다.
또한 DNS 알고리즘도 영향을 미칠 수 있으니. 최대한 L4(vip)로 돌리는 것이 좋다. 역시 문제가 생기면 l4체크 및 l7체크를 통해서 잘못된 서버를 빨리 찾아낼 수 있고, 복구가 가능하다.


4. 서비스 배포하기 전
반드시 beta 테스트를 진행하도록 한다. 아무리 좋은 서비스라도 반드시 QA를 통해서 서비스가 진행되도록 해야한다. 능력없는 개발자의 무모한 자신감은 결국은 신뢰를 깨게 된다. 근거없는 자신감은 망신의 지름길이다.
반드시 QA와의 협력, 어떤 서비스를 오픈하는지를 QA와 알려주고, 리얼 서비스가 닫히더라도 사용자가 볼 수 없는 beta나 개별 서비스 도메인으로 접근하여 꼼꼼히 테스트하는 것이 좋다.
잘못하면?? 다음 메일 꼴 난다.