장애란 무엇인가
장애는 서비스를 제공함에 있어 결함이 발생해 서비스를 원할히 이용할 수 없는 경우를 말합니다.
장애에는 사용자가 눈치채기 힘든것 부터 서비스가 제공되지 않은 것 까지 다양한 레벨의 장애가 있습니다.
장애에 대응하는 마음가짐
당황하지 않기
장애를 마주하는 가장 첫번째 마음가짐은 당황하지 않는 것 입니다.
장애는 웹 개발자에 있어서 재난과도 같은일 입니다.
재난에서 살아남는 첫번째는 당황하지 않는 것 입니다.
저 역시 잘못된 DELETE 문으로 라이브 데이터 베이스를 날렸을때 머리속도 같이 날아가 버리는 줄 알았습니다만...
당황한다고 해결되는 것은 없습니다. 물론 자책한다고 해결되는것도 없습니다.
장애 없는 서비스는 없다.
완벽한 프로그램은 없듯이 장애 없는 서비스는 없습니다.
장애는 긍정적으로 보면 서비스를 좀더 완벽히 만들수 있는 기회 입니다.
장애 대응에만 집중하기
장애의 원인이 본인이라면 장애의 책임 때문에 많은 생각이 순식간에 지나갑니다.
첫번째로 장애보고서 부터 해서 징계까지도 생각나지만 중요한건 장애를 처리하는 것입니다.
사후에 격게될 일을 지금 생각한다고 해결되는 것은 없습니다.
웹개발자를 키우는 것은 장애
몬스터를 잡아 레벨업을 하는 기사처럼 웹 개발자들은 장애들을 경험치로 성장하게 됩니다.
지금까지 많은 개발자들이 걸어온 길이며 앞으로도 걸어갈 길입니다.
장애 대응 순서
어찌되었건 첫번째는 장애가 발생하지 않는것
장애에서 많은 것을 배울 수 있지만 첫번째는 장애가 발생하지 않는 것 입니다.
그것을 위해 테스트 및 꼼꼼한 QA, 정확한 예외처리가 선행이 되어야 합니다.
장애 원인은 범죄자를 찾듯이
장애 원인은 다양합니다. 웹서버의 물리적 문제부터 사용자의 악의적 행위까지 예상할수 없는 경로로 장애는 발생합니다.
그러면 어떻게 찾아야 빠르고 정확하게 찾을수 있을까요?
범죄자를 찾듯이 장애가 남긴 흔적들을 쫒아가면 그 끝에 원인이 있습니다.
응답코드
HTTP의 응답코드에는 장애 관련 4xx와 5xx가 있습니다.
일단 클라이언트의 문제인지 서버의 문제인지 그리고 대략적으로 어떤 부분이 문제인지 확인할 수 있습니다.
따라서 상황에 맞는 응답코드를 내려주도록 개발하도록 합니다.
하지만 응답코드가 항상 장애의 원인과 맞는 것은 아니므로 참고로만 사용합시다.
로그
많은 WAS에서는 표준 엑세스 로그를 제공합니다.
표준 엑세스 로그가 담고 있는 정보는 장애 대응의 많은 도움이 됩니다.
표준 엑세스 로그를 분석하는 방법을 익히도록 합시다.
자바를 비롯해 많은 언어들에서 오류 로그를 남길 수 있습니다.
어플리케이션이 문제라면 오류 로그가 많은 도움이 됩니다.
하지만 오류 로그에 남겨진 곳이 원인이 아닐 가능성도 있으므로 오류 로그에서 원인을 찾는 방법을 익히도록 합시다.
데이터베이스에서는 슬로우 쿼리를 로그로 남길수 있습니다.
DB가 장애의 원인일 경우 많은 도움이 됩니다.
슬로우 쿼리를 파악할줄 아는 방법을 익히도록 합니다.
장애원인을 찾기위해서는 로그가 거의 필수적입니다. 중요한 흐름에서는 로그를 남기는 습관을 들입시다.
장애복구에서도 로그는 많은 도움이 됩니다. 로그를 보고 복구를 할수 있는 데이터들도 있습니다.
AMP
서버 상태나 트래픽을 확인할수 있는 모니터링 툴 또한 장애 원인 파악에 도움이 됩니다.
간단히는 리눅스의 ps,top 명령어 부터 ELK의 AMP 까지 현재 서버 상태를 파악하는 방법을 익히도록 합시다.
사용자의 흐름중에 원인이 있다
당연하게도 사용자의 흐름을 따라가다보면 장애 원인이 있습니다.
브라우저 - 네트워크 - 서버 - WAS - 어플리케이션 - 데이터베이스
1. 브라우져
1.1 브라우져의 오류는 개발자 도구의 콘솔 화면을 이용하면 쉽게 찾을수 있습니다.
1.2 서버로 보내지는 데이터 및 서버에서 받아오는 데이터도 개발자 도구로 확인을 합시다.
1.2.1 서버로 동일 데이터를 보내 장애를 재현해볼수 있습니다.(curl,post man 이용)2. 네트워크
2.1 네트워크 장애인경우에는 아래 현상들이 나타납니다.
2.1.1 타임아웃
2.1.2 도메인을 찾지 못함 (DNS 문제)
2.1.3 아무 응답이 없음
2.2 네트워크 연결이 되는지 확인하는 방법에는
2.2.1 ping - 패킷이 전송되는지 확인가능 하지만 ping 포트가 열려있어야함
2.2.2 telnet - 특정포트가 열려있는지 확인가능 하지만 설치가 필요할수 있음3. 서버
3.1 서버 확인은 일단 서버가 살아 있는지 부터 체크 합니다.
3.1.1 ssh 접근이 가능한지 명령어가 정상적으로 실행되는지 확인합니다.
3.1.2 ssh 접근이 안되거나 서버가 기계적인 응답이 없으면 재시작을 고려합니다.
3.1.3 재시작 후에도 동일 문제 발생시 하드웨어 문제를 의심 해봅니다.
3.2 CPU나 메모리의 상태도 확인해봅니다.
3.2.1 CPU나 메모리 부족으로 ssh가 접근이 안되는 경우 재시작을 고려합니다.
3.3 좀비 프로세스가 있는지 특정 프로세스의 점유율이 높은지도 확인합니다.(ps,top 이용)
3.3.1 점유율이 높은 프로세스를 죽여 안정화 되는지 확인해봅니다.4. WAS
4.1 WAS의 에러로그를 확인합니다. 로그 위치는 설정파일을 참조합니다.
4.1.1 엑세스 로그를 확인합니다. 웹페이지를 호출해보고 엑세스로그나 에러로그가 찍히는지 확인합니다.
4.1.1.1 엑세스 로그나 에러로그가 찍히지 않는다면 네트워크나 WAS가 트래픽을 받지 못하는 이유를 생각해봅시다.5. 어플리케이션
5.1 어플리케이션이 실행중인지 확인합니다.
5.1.1 어플리케이션이 실행도중 중지된다면 디버그나 인포 레벨의 로그를 찍어봅시다.
5.1.2 환경변수나 실행 프로파일이나 yml 설정도 확인해봅니다.
5.2 어플리케이션 로그를 확인해봅니다.
5.1.1 프레임워크 클래스가 아닌 서비스 클래스의 어디서 오류가 나는지 부터 확인합니다.
5.1.2 오류 발생 앞뒤로 어떤 데이터가 들어오는지 로그를 찍어보고 데이터 문제가 아닌지 확인해봅니다.
5.1.3 로직 문제 확인은 상황이 된다면 로직을 하나씩 넣고 빼보면서 체크를 하거나 최소한 앞뒤로 로그를 찍어봅니다.6. 데이터베이스
6.1 데이터 베이스 서버가 동작중인지 확인합니다.
6.1.1 mysql 명령어를 사용할수 있다면 어플리케이션의 접속정보를 이용해 접속되는지 확인해봅니다.
6.1.1.1 해당 계정에 권한이 있는지 확인합니다.
6.1.2 telnet을 이용해 3306 포트가 열렸는지 확인해봅니다.
6.2 데이터 베이스 서버의 상태를 확인합니다.
6.2.1 서버 장애시 체크사항을 확인합니다.
6.2.2 process list를 확인해 락이 걸린 명령어가 있는지 체크해 중단 시켜줍니다.
6.2.2.1 왜 락이 걸렸는지 생각해봅시다.이외의 동작들도 하나 하나씩 제대로 동작하는지 흐름을 따라서 확인해봅시다.예상가는 곳이 있다면 그 부분부터 앞 뒤로 확인해봅시다.
장애의 상황을 재현해보자
장애 상황을 정확히 재현 가능하면 장애상황을 재현하여 사용자 흐름을 따라가면 쉽게 찾을수 있습니다.
디버깅과 중단점을 사용할 수 있다면 예상가는 지점에 우선 중단점을 설정하고 잘못된것이 없는지 확인해봅시다.
리눅스 환경은 도커나 윈도우용 우분투를 사용하여 구축할 수 있습니다.
장애처리는 중요도에 따라
장애 원인에 따라 처리 방법도 다양합니다.또한 당장 처리 할 수 없는 장애도 있습니다.
이때 중요한 것은 서비스를 사용자에게 제공할수 있는 것을 목표로 합시다.
데이터 때문에 생긴 장애인경우 복구가 오래걸립니다. 하지만 이 복구 때문에 서비스가 안되면 안됩니다.
일단 없는 데이터라도 서비스를 할수 있는 부분은 처리를 하여 사용자가 이용 가능하게 해야합니다.
중요한것은 오류 수정이나 데이터 복구가 아닌 서비스의 이용입니다.
개발자는 개발적인면을 중요시 하기 때문에 오류수정에 포커스를 맞추는 경우가 있습니다만
당장 오류가 수정되지 않아도 서비스를 할수 있는 방법이 있다면 그쪽이 우선입니다.
새로 만드는 것도 방법
장애의 원인이 너무 복잡하거나 오래된 시스템이 문제인경우 리펙토링이 답이 될수도 있습니다.
대응의 규모가 커질수 있으니 이부분은 서비스의 중요도와 장애가 자주일어나는 지에 따라 판단하여 진행하도록 합시다.
장애 대응후
기록하기
같은 장애를 다시 겪지 않으려면 원인과 해결방법을 기록해둡시다.
나 뿐만아니라 동료도 같은 장애시에 빠른 대응을 할수 있게 됩니다.
장애 대응의 기록은 본인에게는 누구에게도 없는 자산이 될 것 입니다.
마지막으로
너무 당연한 말만 써 놓았으나 장애는 웹개발자면 언제든 마주해야 하는 존재입니다.
당연하다고 생각되는 만큼 중요한 부분이므로 장애시에 한번쯤 생각해봐야 하는 것들 이므로 당황하지 않고 처리해보도록 합시다.
