1. 장애 탐지
2022.04.16
서비스 장애로 사용자들의 CS 문의가 빗발치기 시작했다.
백엔드에서는 몇가지 작은 에러 로깅이 있었고, 슬랙 알림이 발생했다. 이후에는 심각한 징후도 발견되지 않았다.
QA를 진행한 동료들의 일부는 앱은 서비스가 되고, 웹은 안된다고 하였고, 또 일부는 서비스가 모두 정상적으로 된다고 하였다.
이전에 발생했던 장애와 다른 형태의 장애가 발생한 것이다.
일반적으로 대규모 장애인 경우에 백엔드가 우선적으로 알아차릴 수 있었다.
하지만 이번 장애는 백엔드에서 선제적으로 알아차리지 못했다.
나열된 단서들을 가지고, 장애 전파와 해결에 활용해야한다.
2. 장애 전파
백엔드에서 발생하는 기본 장애 알림은 Slack 채널을 통해 자동화되어 있었다.
그리고 서비스의 전반적인 장애가 발생하였기 때문에 서비스 관련자가 있는 Slack 채널에 @Channel 알림으로 장애에 대한 상황을 전파했다.
그리고 탐지한 이슈 관련자들과 DM을 만들어서 Huddle 을 시작했다.
3. 장애 해결
도메인의 만료를 확인하고, 도메인을 구입한 벤더에서 구매하여, 장애를 해결하였다.
4. 장애 보고
4.1. 요약
도메인 구입 벤더가 서비스 도메인마다 달랐기에 도메인 연장이 관리되지 않아 만료되어 발생한 장애
4.2. 장애 탐지 시간
2022.04.16 18:34:05
4.3. 영향받은 서비스
회사 특정 도메인에 관련된 모든 CNAME과 연결된 서비스 (특히 API, 결제, …)
4.4. 장애 원인
서비스 도메인 만료
4.5. 타임라인과 해결 과정
정보 수집
1.
문제를 찾기 위해서 일단 사용자와 같은 경험을 진행해야한다고 판단했다.
2.
실제 앱과 웹의 서비스가 정상적으로 제공되고 있는 지 확인했다.
3.
나에게 앱은 정상적으로 서비스가 제공되고 있었고, 웹도 서비스가 정상적으로 제공되었다.
4.
다른 동료들의 QA 내용을 전달 받았다.
서비스 확인
5.
웹에서 SSL 인증서 만료를 발견했고, 앱에서 CDN이 이미지를 제공하지 못하고 있었다.
6.
크롬을 통해서 SSL 인증서를 확인했다. 하지만 만료일이 아직 여유가 있었고, 인증서는 유효하지 않았다.
중간 결론
•
SSL 인증서에는 문제가 없었고, 인증서의 유효함을 도메인이 인증하지 못했던 것을 확인했다.
•
이제 도메인을 볼 차례이다.
정보 수집
7.
도메인에 대한 정보를 확인했다.
$ whois domain.com
Bash
복사
8.
도메인 소유 정보가 회사 정보가 아닌 것을 확인했다.
9.
도메인을 구입하여 관리하고 있는 서비스 웹 페이지에서 도메인 활성 여부를 확인했다.
장애 원인 파악
10.
도메인 갱신일이 지나서 도메인이 만료되었음을 확인했다.
11.
사용자별 서비스의 장애가 다르게 나타나는 이유는 사용자에게 가장 가까운 DNS Server의 Cache TTL이 다르기 때문이었다.
처리
12.
도메인을 구입 갱신하여, DNS Server에 정상적으로 현태 호스팅 정보들이 반영되게 하였다.
최종 결론
•
도메인 관리 주체인 우리 회사에서 도메인을 갱신을 해야했지만, 갱신하지 않았고, 임시로 도메인 관리 호스팅 업체의 소유로 도메인이 이전된 상황이었다.
•
도메인을 다시 구입 갱신하여 장애의 원인을 해결했다.
•
조치 이후에 도메인 DNS Cache TTL과 도메인 정보 전파 문제로 약 1시간 정도 장애는 부분 유지되었다.
•
약 1시간 이후에 장애는 해결되었다.
4.6. 예방책
•
도메인 만료일을 전사 캘린더에 등록하였다.
•
도메인 구입 벤더의 정보 이메일을 개발자 그룹 이메일로 포워딩 등록을 하였다.
4.7. 관련 문서 및 추가 정보(선택 사항)
내용 무. (필요하면 기타 정보를 추가한다.)
5. 장애 회고
5.1. 팀 내 회고
•
서비스 전체 도메인의 관리는 관리가 용이한 벤더에서 구매 활용하여 통합하는 방향성
•
도메인의 만료의 알림에 대해서 수동적인 판단보다, 선제적으로 알 수 있게 일정 관리
5.2. 개발자 회고
•
시스템 에러 발생 시, 비정상적인 트래픽에 대해서 에러 메시지의 디테일화
•
슬랙을 활용하여 커스텀 에러를 자세하게 핸들링
