[백엔드 모의면접] 서버의 모니터링 설정은 어떻게 할까?
안녕하세요.
인프랩에서 모의면접 서비스를 개발/운영하고 있는 약풍이라고 해요.
11월 13일은 무슨 날일까요?
바로 모의면접 할인이 시작되는 날입니다. 🚀
단풍과 푸른 잎들이 섞여있는 날입니다.
오늘도 좋은 하루 보내세요 🙇
오늘의 백엔드 질문
운영 중인 서비스에서 문제가 생겼을 때를 대비해, 모니터링 설정은 어떻게 해두셨나요?
주니어 개발자 채용 면접에서 진행했던 프로젝트를 설명할 때, 기능과 구조를 설명하는 지원자는 많아요. 하지만 장애 대응이나 모니터링 설정까지 명쾌하게 답하는 지원자는 흔하지 않아요.
같은 프로젝트라도 관찰 가능성(Observability)에 대한 이야기를 꺼낸다면, 같은 경험으로도 면접에서 더 좋은 인상을 남길 수 있어요.
결제 기능이 정상적으로 수행되지 않는 장애가 생겼다고 가정해 볼게요.
서버가 두 대고 외부 API와 비동기 처리가 섞여 있다면, 특정 유저의 요청 하나를 추적하기가 생각보다 어려워요.
이 질문은 서버의 동작을 나중에 추적할 수 있도록 모니터링 환경을 설정할 수 있는지 검증하는 질문이에요.
답변 키포인트
한 요청에서 발생한 로그를 묶어줄 식별자가 있는지
그 식별자로 비동기 처리나 외부 호출 구간까지 추적할 수 있는지
로그 레벨과 남기지 말아야 할 값에 대한 기준이 있는지
요청이 어느 구간에서 느려졌는지 확인할 방법이 있는지
에러 로그만으로는 아쉬운 이유
"에러가 나면 로그를 남겼습니다"라는 답변이 틀린 답은 아니에요.
다만 동시에 들어온 요청들의 로그가 섞이면, 문의한 유저의 요청 흐름만 골라내기 어려워요.
로그를 남기는 것과 그 로그를 통해 특정 요청을 빠르게 추적할 수 있는 것은 다른 차원의 이야기예요.
면접에서는
면접에서는 "특정 요청을 쉽게 추적할 수 있는 형태로 로그를 남기겠습니다"로 시작하면 좋아요.
또한 로그는 자연어 문장 대신 JSON, Logfmt 같은 구조화된 형태로 남기는 것이 좋아요.
레벨, 요청 식별자, 사용자 ID, 상태 코드, 소요 시간을 필드로 두면 검색과 집계가 가능해지거든요.
이처럼 구조화된 형태로 로그를 남기면, 사용 중인 모니터링 도구에서 로그를 분류하고 통계를 내기도 쉬워져요.
요청이 들어올 때 고유한 ID를 만들어 컨텍스트에 담고, 해당 요청에서 발생하는 모든 로그에 포함시키는 흐름까지 말하면 좋아요.
Spring이라면 MDC처럼 스레드에 묶인 방식은 비동기 처리로 넘어갈 때 그대로 전파되지 않으니, 그 한계도 함께 짚는 게 좋아요.
로그와 트레이스의 차이
로그와 트레이스의 차이도 질문으로 나올 수 있어요.
로그는 특정 시점에 무슨 일이 있었는지 남긴 기록이고, 트레이스는 하나의 요청이 거쳐 간 구간들을 부모와 자식 관계로 연결한 기록이에요.
"DB 조회에 1.2초가 걸렸다"처럼 어느 구간에서 시간이 오래 걸렸는지 보려면 트레이스가 필요해요.
반대로 그 구간이 어떤 값 때문에 실패했는지 확인하려면 로그를 봐야 하고요.
두 기록에 같은 trace ID를 넣어두면 기록들을 쉽게 묶어서 볼 수 있어요.
다만 트레이스를 전부 수집하면 비용이 많이 들어 샘플링을 하게 되는데, 이때 정작 문제가 된 요청이 수집되지 않을 수 있다는 점은 감안해야 해요.
꼬리질문
다음의 꼬리질문도 생각해보세요.
로그를 구조화해서 남기면 어떤 이점을 얻을 수 있나요?
한 요청에서 나온 로그를 묶으려면 로그의 구조를 어떻게 설계해야 할까요?
요청 식별자를 비동기 처리나 다른 서버로는 어떻게 전달하시겠어요?
로그와 트레이스는 각각 어떤 상황에서 보게 되나요?
트레이스를 샘플링한다면 기준을 어떻게 정하시겠어요?
로그에 남기면 안 되는 값은 어떻게 걸러내시겠어요?
AI 모의면접으로
나의 면접 스킬을 체크해보세요
프론트엔드,백엔드,FDE 기술면접부터 문화면접까지,
개발자 면접 준비를 실전처럼 연습해 보세요.
답변 0