2019년 7월 말에 출시된 TOAST Service Monitoring 서비스에 대해 소개합니다.

서비스 개발자에게 중요한 도구 중의 한 가지는 모니터링 도구일 것입니다. 서비스가 안정적으로 동작하는지 상시적으로 감시하여, 정상적으로 동작하지 않을 때는 장애라고 판단하여 장애를 관련 담당자들에게 전파하는 기능이 필요합니다.

모니터링 도구 기능은 크게 다음의 세 가지 기능으로 구성되어 있습니다.

• 감시 대상이 되는 서비스를 계층적인 구조로 관리하는 기능
• 모니터링 시나리오를 작성하여 장애 판정 기준을 정하는 기능 - 모니터링 설정
• 장애를 전파할 수 있도록 설정하는 기능

서비스 계층구조 설정

개발팀이나 개발자는 여러 서비스 또는 시스템들에 대한 개발 및 최소한의 운영 업무를 맡게 됩니다. 예를 들어, 포털 서비스를 여러 개 운영하는 부서에서는 계층적인 서비스 구조를 등록해두고 관리할 필요가 있습니다.

예를 들어, 다음과 같이 가상적인 서비스가 있다고 가정합니다.

• TOAST 메일
• TOAST 뉴스
• TOAST 블로그

"TOAST 뉴스" 서비스 하위에는 다시 작은 규모의 서비스가 존재할 수 있습니다.

• 뉴스 메일링 서비스
• 뉴스 믹싱 서비스
• 뉴스 수집 서비스
• 뉴스 큐레이션 서비스

다음 그림과 같이 왼쪽 "서비스 트리" 영역에서 "추가" 버튼을 클릭하고 서비스 이름이나 설명, 상위 디렉터리 등을 지정하고 "서비스 등록" 버튼을 클릭하여 계층적인 서비스 구조를 정의할 수 있습니다.

"디렉터리" 체크박스가 체크되어 있으면 하위에 서비스를 포함할 수 있으며, "디렉터리"가 체크되어 있지 않은 서비스에 대해서만 모니터링 시나리오를 작성할 수 있습니다. 그러므로 "TOAST 뉴스" 서비스는 다른 하위 서비스를 포함할 수 있을 뿐 모니터링 시나리오를 추가할 수 없습니다. 모니터링 시나리오는 "뉴스 메일링 서비스"에 추가할 수 있습니다.

이렇게 상위 서비스인 "TOAST 뉴스"의 하위에 여러 서비스를 만드는 이유는 다음과 같습니다. 사용자에게는 동일한 서비스로 보이지만 내부에서는 "뉴스 메일링 서비스"와 "뉴스 큐레이션 서비스"의 중요도가 다를 수 있고, 발생한 장애를 전파하는 방법에 있어서도 전파 대상자나 전파 채널이 다를 수 있습니다. 이렇게 서비스 운영 관점에서 세분화하여 작은 규모의 서비스들을 관리할 수 있도록 계층적인 서비스 구조를 정의하는 게 편리합니다.

모니터링 설정

모니터링 설정은 다음의 3가지로 나뉩니다.

• 웹 서비스를 대상으로 하는 "웹 모니터링"
• TCP/UDP/ICMP 서비스를 대상으로 하는 "TCP 모니터링"
• 서비스에서 주기적으로 자체 작업의 성공 여부를 Service Monitoring 쪽으로 알려주는 배치 모니터링

상단 탭에서 "웹 모니터링" 또는 "TCP 모니터링", "배치 모니터링"을 클릭하여 특정 탭으로 이동하여 시나리오를 추가할 수 있습니다. 시나리오 버튼이 활성화되어 있지 않다면 왼쪽 "서비스 트리" 영역에서 최하위 서비스를 클릭하면 "시나리오 추가" 버튼이 활성화되어 시나리오를 추가할 수 있습니다.

각각의 모니터링 설정에 대해 좀 더 자세히 살펴보겠습니다.

웹 모니터링 설정

우선 시나리오 타입을 "API"나 "브라우저"나 "모듈" 중 한 가지로 선택해야 합니다. 일반적으로는 API 모니터링이나 브라우저 모니터링을 선택하면 되는데, 동일한 로그인 기능을 반복적으로 설정하기 번거로운 경우에는 "모듈"을 선택하여 시나리오를 공유할 수 있습니다.

간단한 웹페이지나 API 모니터링 사례

시나리오 이름과 설명을 입력하고 실행 방법에 반복 주기를 60초로 지정합니다. 일정한 반복 주기가 아닌 경우에는 년/월/일/시/분 단위로 스케줄을 직접 입력할 수도 있습니다.

(매년 3개월마다 1일 0시 5분에 한 번 모니터링이 실행되도록 스케줄링)

혹시 일시적인 네트워크 오류로 인해 오탐지가 발생하더라도 한 번 더 모니터링을 실행해보고 실패가 반복되는 경우에만 장애로 판정하게 하려면 "허용 에러 횟수"를 1로 지정하면 됩니다.

가장 중요한 정보는 "URL"과 "검증 타입"인데, URL을 입력하고 검증 타입으로 "응답 코드"와 "텍스트 검증"을 한 번씩 선택하여 응답 코드가 200으로 반환되는지, 응답의 JSON 데이터가 "result": "ok"라는 텍스트를 포함하고 있는지 검증하도록 시나리오를 작성합니다.

모든 작성이 끝나면 하단의 "테스트" 버튼을 클릭하여 시나리오가 정상적으로 수행되는지 확인한 다음 이상이 없다면 "확인" 버튼을 클릭하여 저장합니다. 저장이 완료되면 시나리오 목록에 이번에 새로 추가한 시나리오가 노출됩니다.

브라우저 모니터링 사례

자바스크립트로 화면을 렌더링 하는 경우에는 단순히 서버의 응답 내용만을 모니터링해서는 정상적인 결과인지 확인하기 어렵습니다. 이런 경우에는 "시나리오 타입"을 "브라우저"로 선택하여 자바스크립트 렌더링 결과를 HTML로 응답받아서 중요한 요소가 잘 렌더링 되었는지 확인하는 것이 필요합니다.

"브라우저"는 "CHROME"으로 선택하고, "스크립트 에러 무시"와 "이미지 다운로드 제외"를 체크합니다. 자바스크립트의 에러가 발생하거나 일부 이미지가 제대로 표시되지 않더라도 화면의 주요 요소가 잘 렌더링 되어 정상적으로 기능을 제공하는 것과는 상관없을 수 있기 때문에 필요에 따라 체크박스를 선택하면 됩니다.

"URL"을 입력하고 "검증 타입"으로 "텍스트 검증"을 선택하여 "홍길동님 안녕하세요"와 "마이 뉴스 보러가기"라는 텍스트가 정상적으로 렌더링 되어 노출되는 것을 확인하면 됩니다.

마찬가지로 테스트 후 확인을 하면 저장됩니다.

모듈 작성하기

동일한 서비스에 여러 시나리오를 작성하다 보면 동일한 과정을 거쳐야 하는 경우가 있습니다. 예를 들면, ID와 패스워드를 입력하여 로그인을 한 다음에 각각의 페이지로 이동하여 그 페이지가 정상적으로 접근되는지를 확인하는 시나리오가 여러 개 존재하는 경우가 있습니다.

로그인 과정이 반복되는데 이걸 매 시나리오마다 작성하는 것은 상당히 번거롭습니다.

상단의 "시나리오 타입"에서 "모듈"을 선택하여 로그인 모듈을 작성하여 공유해 둔 다음, 각각의 브라우저 모니터링 시나리오에서 로그인 모듈을 선택하면 번거로운 로그인 과정의 시나리오를 반복적으로 작성할 필요가 없습니다.

위와 같이 로그인 스크립트를 실행되는 모듈을 미리 작성해 둡니다. "SSO 로그인 모듈"이라는 이름의 시나리오로 저장해두면 다른 시나리오에서 공유해서 사용할 수 있습니다.

시나리오는 동료 개발자와 공유할 가능성이 높은데, 로그인에 사용되는 ID와 패스워드가 노출되면 보안 상 위험할 수 있습니다. 이런 경우 secret() 함수로 감싸두면 본인에게는 ID와 패스워드가 정상적으로 노출되지만 다른 동료 개발자에게는 마스킹 처리되어 *로 표시됩니다.

로그인 모듈을 선택하여 브라우저 모니터링 시나리오에 포함할 수 있습니다. 그러면 로그인 과정이 진행되고 나서 이 시나리오에서 지정한 URL의 페이지에 접근하여 결과를 검증할 수 있습니다.

TCP 모니터링 설정

인터넷 서비스의 통신 프로토콜을 따르는 IP 패킷을 직접 정의하여 서비스를 모니터링할 수도 있습니다.

위와 같이 SMTP 서비스가 정상적으로 동작하는지 확인하기 위해 IP 주소와 PORT 번호를 지정하고, 아래와 같이 SMTP 패킷을 작성해서 전송하면 됩니다. 정상적인 경우에 받게 될 응답 메시지를 마찬가지로 입력해두면 검증 가능합니다.

16진수 값을 입력하거나 텍스트를 작성하는 방식으로 편집할 수 있습니다.

자주 사용하는 ping 패킷을 손쉽게 사용할 수 있도록 "프로토콜"로 "ICMP"를 기본으로 제공하고 있습니다. "ICMP"를 선택하면 "전송 데이터"와 "결과 검증"을 직접 입력할 필요가 없습니다.

배치 모니터링 설정

앞서 설명드린 "웹 모니터링"과 'TCP 모니터링"은 TOAST Service Monitoring이 능동적으로 모니터링을 수행하는 기능이라면, 이번에 설명드릴 "배치 모니터링"은 사용자의 서비스나 배치 프로그램이 능동적으로 모니터링 정보를 전송하여 서비스의 장애 여부를 판단하는 기능입니다.

앱키를 신규로 생성하고 시나리오 이름과 설명을 입력합니다. 사용자의 서비스나 배치 프로그램에서 주기적으로 전송할 모니터링 정보에 포함되는 JSON 데이터의 주요 필드의 값을 지정하여 검증합니다.

위의 예에서는 "is_successful" 필드의 값이 "yes"이고 "count" 필드의 값이 10 이상이면 정상이라고 판정합니다.

5분마다 사용자의 서비스나 배치 프로그램에서 전송될 JSON 메시지를 수신하는데, 정해진 기한보다 조금 먼저 도작해야 하기 때문에 2분 전에 도착하더라도 유효한 메시지로 간주합니다. 정해진 기한보다 늦게 도착하면 정상적으로 메시지를 받지 못한 것으로 판단하여 장애로 판정하게 됩니다.

전파 설정

모니터링 시나리오를 통해 장애를 감지하더라도 전파 설정이 되어 있지 않다면 실질적인 효과가 없습니다. 장애가 발생하면 누가 받아볼 것인가, 어떤 통신 수단을 이용하여 장애 메시지를 보낼 것인가에 대한 설정이 필요합니다.

"서비스 관리" 탭 하단의 "전파 설정" 영역에서 전파 대상자와 전파 채널을 설정할 수 있습니다.

"저장" 버튼을 클릭하여 저장하는 것을 잊지 마시기 바랍니다.

웹훅 설정

전파 채널로서 웹훅(webhook)을 호출하도록 설정할 수도 있는데, 웹훅은 "서비스 관리" 탭 중앙의 "웹훅 정보" 영역에서 설정할 수 있습니다.

JSON 메시지나 텍스트 메시지를 정의하여 HTTP/HTTPS 프로토콜로 전송을 할 수 있습니다. 간편 설정을 이용하면 Slack으로 메시지를 보낼 수도 있고 Github에 이슈를 신규 생성할 수도 있습니다.

기타 기능

전파 현황 조회 및 전파 처리

"전파 현황" 탭에서 발생했던 장애 목록을 살펴보고 장애를 후 순위 그룹으로 전파하거나 전파를 중지할 수 있습니다. 완료되지 않은 장애 전파는 3시간 후에 자동으로 후 순위 그룹에 전파되므로 유의할 필요가 있습니다.

장애가 발생했는데 일시적인 오류라서 장애가 전파되지 않도록 전파를 중지해야 하는 경우에는 "중지" 버튼을 클릭하면 됩니다. 1차 그룹에서는 장애 메시지를 수신했으나 2차 그룹에는 장애 메시지가 전달되지 않습니다.

후 순위 전파 그룹이 존재하지 않는 경우에는 자동으로 전파가 완료 처리됩니다.

점검 설정 (전파 중지)

일정 기간 동안 장애가 발생하더라도 장애를 전파하지 않도록 점검 기간을 설정할 수 있습니다. "웹 모니터링" 등의 모니터링 설정 탭에서 "전파 중지" 버튼을 클릭하여 기간을 설정할 수 있습니다. 해당 서비스는 이 기간 동안 발생하는 장애를 전파하지 않습니다.

모니터링 이력

개별 시나리오의 모니터링 이력을 살펴볼 수도 있습니다. "웹 모니터링" 등의 모니터링 설정 탭으로 이동하여 개별 시나리오의 "성공"/"실패" 버튼을 클릭하면 모니터링 이력을 조회할 수 있습니다.

"탐지 결과" 조건을 "전체" 대신 "실패"로 변경하면 모니터링이 실패하여 장애로 판정된 경우만 선별해서 조회할 수 있습니다.

개별 이력 항목을 클릭하면 어떤 서비스 리소스에 접근하다가 실패했는지 알 수 있는 디버깅 정보를 확인할 수 있습니다.

맺음말

서비스 모니터링은 안정적인 서비스 운영에 있어서 핵심적인 도구입니다. 다양한 기능을 제공하는 TOAST Service Monitoring을 활용하여 빠르게 장애에 대응할 수 있다면 서비스 고객이 겪는 불편함을 최소화할 수 있습니다.

장애의 원인이 되는 서비스 단위 요소를 나눠서 모니터링 설정을 해두면 모니터링은 자동으로 동작하기 때문에 서비스 개발자와 운영자의 부담을 줄여주며 장애 원인 분석에 도움을 받을 수 있습니다.