API 요청 로그로 운영 환경 문제를 빠르게 진단하기

API 서버가 느려지거나 응답이 없으면, 원인이 무수히 많을 수 있다. 애플리케이션 코드부터 인프라까지 모든 계층에 문제가 있을 수 있기 때문이다. 이럴 때는 넓은 범위를 좁혀가는 체계적인 접근이 필요하다.

시스템의 기본 상태를 먼저 본다

문제를 크게 잡으면 모든 파일이 의심스러워져서 손대기 어려워진다. 먼저 큰 그림부터 확인한다.

sudo ss -lntp
df -h
sudo journalctl -n 80

ss -lntp 명령어는 열려 있는 포트와 프로세스를 보여준다. API 서버가 기대하는 포트에서 수신 대기 중인지 확인한다. df -h 명령어는 디스크 사용량을 보여준다. 저장소가 가득 찼으면 새로운 로그를 쓸 수 없어서 서버가 멈출 수 있다. journalctl 명령어는 시스템 로그를 보여준다.

애플리케이션 프로세스가 살아 있는지 확인한다

PM2나 Systemd 같은 프로세스 매니저를 사용한다면, 실제로 프로세스가 실행 중인지 확인한다. 혹은 ps 명령어로 직접 찾아본다.

ps aux | grep node

프로세스가 없다면 crash되었을 가능성이 높다. 로그에서 crash 메시지를 찾는다.

권한을 확인한다

API 서버가 필요한 파일이나 디렉토리에 접근할 수 있는지 확인한다. 로그 파일을 쓸 수 없거나, 데이터베이스에 연결할 수 없으면 권한 때문일 수 있다.

배포된 코드가 최신인지 확인한다

Git 리포지토리의 현재 상태를 확인하고, 실제 서버에 배포된 코드가 최신인지 비교한다. CI/CD 파이프라인이 제대로 작동했는지 확인한다.

API 요청 로그를 분석한다

요청이 서버에 도착했는지, 어느 엔드포인트에서 문제인지 확인한다. 특정 API만 느리면 그 API의 로직을 살펴본다. 모든 API가 느리면 인프라 문제일 가능성이 높다.

데이터베이스 연결을 확인한다

DATABASE_URL이 올바르게 설정되었는지 확인하고, 데이터베이스가 정상적으로 응답하는지 테스트한다. 연결 풀이 고갈되었거나, 쿼리가 느리면 API 응답도 느려진다.

환경 변수를 다시 검증한다

배포 후 환경 변수가 제대로 적용되었는지 확인한다. 특히 API 키나 데이터베이스 URL 같은 중요한 값을 실수로 빠뜨렸을 수도 있다.

시간대별 요청 패턴을 분석한다

특정 시간대에만 문제가 발생한다면, 배치 작업이나 정기적인 메인테넌스와 관련이 있을 수 있다. 요청 로그를 시간대별로 정렬해서 패턴을 찾는다.

운영 환경의 문제는 개발 환경에서 나타나지 않을 수 있으므로, 실제 로그를 읽고 분석하는 능력이 중요하다.