본격적인 백엔드 엔지니어로 일하기 시작한 지 1년이 넘었습니다.

점차적으로 시스템 아키텍처에 익숙해지면 스스로 컷(설계 및 개발)할 수 있습니다.

그러나 이로 인해 문제가 발생하는 경우가 종종 있습니다.

올해 초에는 그런 경우가 많았다.

회사가 갑자기 커지면 많은 기능이 바뀌고 추가되기 때문에 그런 경우가 많은 것 같다.

나는 그에게서 배울 수 있는 것들을 되돌아보았다.

1. 규모의 문제

제가 다니는 회사는 동시접속자가 많지는 않지만.. 그래도 TPS 자체는 꽤 부수적이라고 생각합니다.

따라서 들어오는 데이터의 양이 중요합니다.

경우에 따라 처음에는 문제가 없던 설계가 시스템 설계에서 데이터 양이 급격히 증가하면 문제가 발생할 수 있습니다.

예를 들어 처음에는 TPM 1000에서만 정상적으로 작동하는 시스템이 있습니다.

처음에 1000개 이상 만들면 당연히 비용 문제!
그것은 손실이다 사용자 수가 증가함에 따라 트래픽이 1000 이상으로 증가합니다.

예를 들어 1500개 정도를 쌓으면 처리되지 않은 나머지 데이터 500개를 얻게 됩니다.

이것은 쌓이고 쌓여 나중에 시간 초과 및 배고픔과 같은 문제를 일으킵니다.

이러한 문제가 되는 상황을 피하기 위해 무엇을 할 수 있습니까? 아마도 설계 문서를 작성할 때 “제약” 또는 “위험”으로 잘 정리되어야 한다고 생각합니다.

이를 통해 상황이 문제가 되기 전에 CS 또는 엔지니어링 측면에서 미리 대응할 수 있습니다.

또한 지속적인 모니터링 수단도 미리 준비해야 합니다.

(바로 아래 섹션에서 설명)

2. 감시 문제

앞서 언급했듯이 이것은 규모 문제와 일치합니다.

본질적으로 “정보 유형”과 “정보 비용”에 관한 것입니다.

우선 정보의 종류에 관해서는 물론 의미 있는 정보를 모니터링할 수 있는 장치를 찾습니다.

예를 들어 어떤 수치가 있는데 변동이 심하면 문제가 있는 상황이라고 합시다.

또는 간단한 알람 로그가 있고 해당 로그의 스파이크가 문제의 전조로 간주된다고 가정해 보겠습니다.

이 경우 해당 메시지를 모니터링하여 차트로 표시하여 훨씬 이해하기 쉬우며 동시에 메시지가 일정 횟수 이상 발생하면 알람을 트리거할 수 있습니다.

분당 횟수(스니칭).

그리고 그 모든 작업을 수행하는 것은 비용(cost)의 문제입니다.

감시를 통해 많은 의미 있는 정보가 드러날 수 있다는 것은 대단한 일입니다.

그러나이 정보가 실제로 사용됩니까? 메트릭이 너무 많은 차원을 생성합니까? 메트릭이 너무 많이 생성하지 않습니까? 등을 확인해야 합니다.

모니터링은 추가 정보를 생성하는 데 비용이 많이 들기 때문에 최소화하는 것이 도움이 됩니다.

3. 웃는 얼굴로 당신을 스토킹하는 혼돈 (+ 조기 복귀)

니알라토뎁… 실수가 아닙니다!

일반적으로 버그는 발생하자마자 문제가 됩니다.

퍼프!
팝핑은 친구를 의미합니다.

그리고 일반적으로 문제의 원인에 가까울수록 문제를 찾고, 재현하고, 해결하기가 더 쉽습니다.

(예를 들어, nullptr… 보너스로 무언의 압력을 더 많이 받습니다…)

그러나 인생은 그렇게 단순하지 않습니다.

문제가 발생한 곳에서는 정상적으로 작동하다가 나중에 데이터가 다른 곳에서 심각한 문제를 일으키는 경우(Dirty Bit와 같이 처음에는 잘 작동하다가 나중에는 프로그램 경화부터 일관성이 깨질 때까지… ) 더 아파요.

더 멀리 발생하여 재현할 수 없는 버그도 있습니다.

즉, 한두 달 동안 작동한 후에야 알아차리는 문제도 있습니다.

이 섹션의 제목을 의미합니다.

실제로 오류가 발생합니다.

이러한 오류를 찾을 때 가장 좋은 점 중 하나는 모니터링 도구그렇지 않다고 생각합니다.

문제가 바로 나타나지는 않지만 특정 메트릭이 지속적으로 변경되는 경우 미리 상황을 확인할 수 있습니다.

참고로 문제는 “조기 복귀”메서드를 조기에 반환하여 불필요한 코드 중첩을 줄여 가독성을 높이기 위해 자주 사용됩니다.

마지막으로 실행해야 하는 지연된 메서드 (예: 청소) 등을 해서는 안 됩니다.

이 문제도 그런 이유로 쓰레기가 쌓여서 생기는 문제였습니다.

비싼 강의입니다.

조심합시다.

4. 오탐지

가양성(유형 I 오류)이라는 것이 있습니다.

현실에서는 정상이 아니지만 겉으로나 지표로 보면 정상으로 보인다.

그리고 그것은 실제로 직장에서 일어났습니다.

프로세스의 최종 결과는 세부 작업이 실패했기 때문에 실패해야 했지만 어떤 이유로 오류가 누락되어 정상적으로 나왔습니다.

다행히 다른 모니터링 지표에서 문제가 확인되어 큰 피해는 없었지만 이러한 오탐을 방지하기 위한 노력이 필요한지 고민해야 할 것 같습니다.

그래서 제가 좋아하는 것은 의도적으로 테스트에 실패하고 검증하는 것입니다.

성공 사례에 너무 집중하면 이러한 문제를 간과할 수 있습니다.