이번 글에서는 API 헬스 체크 방법에 대해 설명 드려볼까 합니다. API 관리와 모니터링이 우수하게 잘 진행되지 않으면 규모가 있는 프로젝트일수록 예상치 못한 Critical Issue가 발생할 확률이 높은데요. 이번 글을 통해 API 헬스 체크 리스트를 확인하고 프로젝트 안정성 확보에 참고하시길 바랍니다.
API 상태 확인 가이드
API는 어디에나 있으며 광범위한 애플리케이션의 기능을 지원합니다. 잘 개발된 API를 사용하면 타사 개발자가 제품에 쉽게 통합할 수 있으므로 성장을 촉진하고 완전히 새로운 수익원을 창출할 수 있습니다. 그러나 이러한 장점을 모두 누리려면 API 상태와 성능을 모니터링해야 합니다.
기본적으로 API 상태 확인은 API를 확인하고 문제가 있음을 감지하면 알림을 보내는 API 모니터링 방법입니다. 문제가 필요 이상으로 심각해지기 전에 문제를 찾는 데 도움이 되는 코드베이스용 진단 도구라고 생각하세요.
API 헬스 체크 리스트
API 상태 확인 엔드포인트에서 확인할 수 있는 항목은 광범위합니다. 어떤 것이 포함되어야 하고 어떤 것이 누락되어야 할까요? 일반적으로 API 상태 확인 엔드포인트는 API가 들어오는 요청을 처리하는 것을 방해할 수 있는 모든 것을 확인해야 합니다. API마다 다르지만 API 상태 확인 엔드포인트에 포함할 가장 많은 항목 중 일부를 나열했습니다.
| 헬스 체크 리스트 | 설명 |
| 다운스트림 작업 상태 | 특정 API는 작동을 위해 다른 API에 의존할 수 있습니다. 의존하는 다운스트림 API의 작동 상태를 확인하세요. |
| DB 연결 | API에 데이터 소스에 대한 열린 연결이 있을 수 있습니다. 상태 확인 시 연결이 가능한지 확인하세요. |
| DB 응답 시간 | 일반적인 DB 쿼리에 대한 평균 응답 시간을 측정해야 합니다. |
| 메모리 사용량 | 메모리 사용량 급증은 메모리 누수로 인해 발생할 수 있으며 서비스를 중단시킬 수 있습니다. |
| In-flight 메시지 | 전송 중인 메시지가 너무 많으면 근본적인 문제의 징후일 수 있습니다. |
API 헬스 체크 vs. API Ping
API ping 엔드포인트는 기본 200 OK 메시지로 요청에 응답합니다. API ping 엔드포인트의 목적은 HTTP 요청이 API에 도달하는지 확인하는 것입니다. 또한 Dev-ops 엔지니어는 API 게이트웨이, SSL, 라우팅 및 기타 네트워크 수준 구성 요소가 함께 작동하여 API 프로세스에 요청을 전달하는지 확인하기 위해 API를 ping(ping 엔드포인트 사용)합니다.
앞에서 설명한 것처럼 API 상태 확인 엔드포인트는 여러 항목을 확인하고 API 및 해당 종속성의 상태로 응답합니다.
제 경력을 통해 저는 API에 문제가 있는 동안 200 OK를 반환하는 많은 API 핑 엔드포인트를 발견했습니다. API 상태 확인 엔드포인트는 API ping 엔드포인트보다 우수하고 API ping의 모든 사용 사례를 다루며 더 많은 이점을 제공합니다.
API 헬스 체크 우수 사례
매분마다 API 상태를 모니터링하고 API가 올바르게 작동하지 않는 경우 알림을 설정하는 것이 중요합니다. 다음은 API 상태를 모니터링하는 데 도움이 되는 몇 가지 모범 사례입니다.
API 상태 확인 자동화
내결함성 API 모니터링 시스템을 통해 전체 API 상태 확인을 자동화해야 합니다. 그 외에도 API 상태 확인을 위한 맞춤형 API 모니터링 솔루션을 배포하지 않아야 합니다. 전용 API 모니터링 솔루션을 사용하면 모니터링 도구 다운타임 및 버그와 관련된 위험을 최소화할 수 있습니다.
가능한 한 자주 API 상태를 확인하는 것이 좋습니다. 이상적으로는 API 상태 모니터링 도구가 매분 API 상태를 확인해야 합니다. 너무 많다고 느껴질 수 있는데 실제로는 그렇지 않습니다. API 상태 확인이 매시간 발생한다고 상상해 보세요. 마지막 상태 확인 직후 API가 다운되면 어떻게 될까요? API가 다운되었음을 깨닫는 데는 무려 60분 이상이 소요될 수 있습니다.
캐시 비활성화
API 프로세스는 Restful 또는 GraphQL(마이크로)서비스 API 상태 확인 엔드포인트에 대한 모든 요청을 제공해야 합니다. 상태 엔드포인트에서 캐싱을 비활성화하면 HTTP 캐싱이 요청을 처리하지 못하게 됩니다. 결과적으로 API 상태 확인 엔드포인트에 대한 모든 요청은 마이크로서비스의 최신 상태를 반환합니다.
캐시를 비활성화하려면 Cache-Control: no-cache를 엔드포인트에 추가하세요.
응답 시간 문제
API 상태 확인 엔드포인트가 응답하는 것뿐만 아니라 엔드포인트가 요청에 응답하는 데 걸리는 시간도 중요합니다. 예를 들어 엔드포인트가 30초 안에 응답하면 API에 문제가 있는 것입니다.
Testfully에서 고객은 API 테스트 및 모니터링에 대한 예상 응답 시간을 설정할 수 있습니다. API가 응답하는 데 시간이 오래 걸리면 Testfully에서 경고를 시작합니다.
JSON 응답
상태 확인 응답을 JSON 형식으로 반환하면 API 모니터링 도구를 사용하여 추가 검증이 가능합니다.
응답 상태 코드
응답 상태 코드를 활용하고 상태 점검 결과에 대해 모니터링 도구와 잘 통신하는지 확인해야 합니다. 성공적인 상태 확인은 200 OK를 반환해야 합니다. 500 내부 오류를 비롯한 다른 표준 HTTP 상태 코드를 사용하여 실패 신호를 보냅니다. 응답 상태 코드는 API의 전반적인 상태를 반영해야 합니다.
상태 확인 엔드포인트 보호 고려
대부분의 ping 엔드포인트는 내부 또는 민감한 정보를 많이 제공하지 않기 때문에 공개적으로 사용할 수 있습니다. 반면에 API 상태 확인 엔드포인트는 서비스에 대한 정보를 노출하므로 이 엔드포인트를 보호하는 것이 좋습니다. API 모니터링 도구가 API 액세스 키 전송을 지원하는지 확인하기만 하면 됩니다.
API 헬스 체크 Endpoint 유형
특정 목적을 위해 설계된 API 상태 확인 엔드포인트에는 적어도 세 가지 유형이 있습니다.
- 종종 /health/ready를 통해 사용할 수 있는 준비 끝점은 준비 상태를 반환하여 게이트웨이 또는 업스트림 프록시에서 들어오는 요청을 수락합니다. 준비 상태는 앱이 정상적으로 실행 중이지만 아직 요청을 받을 준비가 되지 않았음을 나타냅니다.
- 종종 /health/live를 통해 사용할 수 있는 활성 끝점은 마이크로 서비스의 활성을 반환합니다. 검사에서 예상 응답을 반환하지 않는 경우 프로세스가 비정상이거나 종료되었으며 가능한 한 빨리 교체해야 함을 의미합니다.
- 종종 /health를 통해 사용 가능한 일반 상태 검사 엔드포인트는 서비스 및 종속성의 상태를 반환합니다.
API 헬스 체크 시에는 아래의 상황들을 미리 고려하면 좋습니다. 경우에 따라 요청을 처리하기 위해 JSON 기반 데이터를 메모리에 로드하는 API들이 있습니다.
- /health/ready는 API가 JSON 파일을 로드하는 동안 NOT_READY 신호로 계속 응답합니다. API는 파일이 메모리에 없으면 요청을 처리할 수 없기 때문입니다. 따라서 API가 전체 파일을 처리하는 데 다소 시간이 걸릴 수 있습니다.
- /health/live는 앱이 준비되지 않았더라도 컨테이너 오케스트레이터 계층이 앱을 다시 시작하지 못하도록 즉시 LIVE 신호를 보냅니다.