<div id="readability-page-1" class="page"><div><p>
                    APM에서 엉뚱한 걸 찾았던 실수
                    
                    </p><p>
                        APM은 Application Performance Monitoring의 약자
                    </p>
                    
                    
                </div><div v-pre="">
                
                    <p>APM은 애플리케이션 성능 모니터링(Application Performance Monitoring)이다.
우리팀이 사용하는 모니터링 서비스 데이터독(Datadog)은 APM에서 많은 것을 확인할 수 있다.
(인프라, 로그, 호스트의 프로세스, JVM 런타임 메트릭, 각 리소스별 레이턴시 등등)</p>
<h2 id="문제">문제</h2>
<p><img src="https://markruler.github.io/images/web/apm-network-device-troubleshooting-mistakes/first.png" alt="First"></p>
<p>이용자에게 실제 체감이 될 정도로 레이턴시가 높아지고, 정각마다 스파이크 발생했다.
또한 서비스 전체에 영향이 있었다.</p>
<h2 id="분석-쉽게-간과했던-문제">분석: 쉽게 간과했던 문제</h2>
<p><a href="https://markruler.github.io/posts/db/oracle-dbms-session-diagnosis/">Oracle Session 히스토리</a>를 남겨서 확인했을 때
DB에 부하를 일으키면서 반복적으로 보이는 느린 쿼리가 없었다.
DB 문제는 아니었다.</p>
<p><img src="https://markruler.github.io/images/web/apm-network-device-troubleshooting-mistakes/oracle-session.webp" alt="Oracle Session 히스토리"></p>
<p>발생 시점에 반영된 소스 코드를 보니까 Public IP로 요청하던 내부 API를 Private IP로 요청하도록 변경했다.
이 시점에는 이게 문제라고 생각하지 않았다.</p>
<blockquote>
<p><strong>“Private IP로 요청하면 더 빠른 거 아냐?"</strong></p>
</blockquote>
<p>모니터링 할 수 있는 모든 지표를 확인했지만, 레이턴시가 높아지는 시점에 아무런 이상이 없었다.
혹시 몰라서 라우터 장비에 SNMP 모니터링을 추가했다.
IDC 매니저와 확인해보니 Private IP 망에 연결된 라우터의 UDP 케이블 전송 속도가 예상 속도 1Gbps가 아닌 10Mbps가 나오고 있었다.</p>
<p><img src="https://markruler.github.io/images/web/apm-network-device-troubleshooting-mistakes/network-router.webp" alt="Network Router"></p>
<h2 id="해결">해결</h2>
<p>정말 간단하게… 케이블을 교체해서 해결되었다.</p>
<p><img src="https://markruler.github.io/images/web/apm-network-device-troubleshooting-mistakes/solved.png" alt="Solved"></p>
<p>정각마다 발생하는 스파이크는 DB 백업 솔루션에서 정각마다 실행하는 프로그램이 있어서 발생한 것이다.</p>
<p><img src="https://markruler.github.io/images/web/apm-network-device-troubleshooting-mistakes/replace-udp-cable.webp" alt="Replace UDP Cable"></p>
<p>순간의 오판으로 시간을 허비했다.
익숙한 것도 의심하고, 모니터링의 한계점을 파악할 필요가 있다고 느꼈다.</p>

                    
                    <hr id="EOF">
		    <p>Last modified on 2024-07-25</p>
                    
                </div></div>

임창수 블로그

Changsu

임창수 블로그 https://markruler.github.io/posts/web/apm-network-device-troubleshooting-mistakes/ -
APM은 애플리케이션 성능 모니터링(Application Performance Monitoring)이다.
우리팀이 사용하는 모니터링 서비스 데이터독(Datadog)은 APM에서 많은 것을 확인할 수 있다.
(인프라, 로그, 호스트의 프로세스, JVM 런타임 메트릭, 각 리소스별 레이턴시 등등)
문제
이용자에게 실제 체감이 될 정도로 레이턴시가 높아지고, 정각마다 스파이크 발생했다.
또한 서비스 전체에 영향이 있었다.
분석: 쉽게 간과했던 문제
Oracle Session 히스토리를 남겨서 확인했을 때
DB에 부하를 일으키면서 반복적으로 보이는 느린 쿼리가 없었다.
DB 문제는 아니었다.
발생 시점에 반영된 소스 코드를 보니까 Public IP로 요청하던 내부 API를 Private IP로 요청하도록 변경했다.
이 시점에는 이게 문제라고 생각하지 않았다.
“Private IP로 요청하면 더 빠른 거 아냐?"
모니터링 할 수 있는 모든 지표를 확인했지만, 레이턴시가 높아지는 시점에 아무런 이상이 없었다.
혹시 몰라서 라우터 장비에 SNMP 모니터링을 추가했다.
IDC 매니저와 확인해보니 Private IP 망에 연결된 라우터의 UDP 케이블 전송 속도가 예상 속도 1Gbps가 아닌 10Mbps가 나오고 있었다.
해결
정말 간단하게… 케이블을 교체해서 해결되었다.
정각마다 발생하는 스파이크는 DB 백업 솔루션에서 정각마다 실행하는 프로그램이 있어서 발생한 것이다.
순간의 오판으로 시간을 허비했다.
익숙한 것도 의심하고, 모니터링의 한계점을 파악할 필요가 있다고 느꼈다.
- https://markruler.github.io/posts/web/apm-network-device-troubleshooting-mistakes/ - Im Changsu 2020 - 2024

APM에서 엉뚱한 걸 찾았던 실수

댓글