그 때에 필요한 것은 시스템을 관찰하는 툴입니다.

그 중, 서비스를 제공하는 것은 Application으로, 아무리 서비스가 동작하는 인프라가 정상적이어도,

Application이 정상적이지 않으면, 서비스를 정상적으로 제공할 수 없습니다.

그때, Application이 정상적인지 아닌지 확인하기 위해서는 APM ( Application Performance Management) 을 이용하여야 합니다.

자신이 만든 코드 중, 어느 것이 느린지 파악하기 위해서 APM 이 필요할 것입니다.

개발 환경에서는 정상적이고, 빠르게 응답을 하였으나, 운영 환경에서는 그렇지 않을 수도 있습니다.

그 때에 어느 부분이 느린지, Code level로 성능을 측정할 수 있게 해 주는 것이 APM 입니다.

(1) 자신의 코드 중 어느 메서드 느린지 파악하기 위하여.

(2) 자신의 코드가 JIT, garbage collection 등의 이유로 느려지는지 파악하기 위하여. 

해당 사항을 파악하기 위해선, APM에서 code level performance profiling이 가능하여야 한다.

(3) 자신이 작성한 쿼리문 중 어느 쿼리문이 느린지 파악하기 위하여.

해당 사항을 파악하기 위해선, APM에서 code level performance profiling이 가능하여야 한다.

서비스에 장애가 발생하였을 때에, APM 이 없다면, 어떤 부분이 장애인지 파악조차 할 수가 없게 될 가능성이 높습니다.

운영자는 APM 을 통해 시스템의 디스크, 네트워크, Application 등 어느 부분이 문제인지 빠르게 파악하고, 문제가 있는 부분에 관련된 사람과 객관적인 자료를

이용하여 커뮤니케이션을 할 수 있습니다.

(1) 모니터링 대상 서버가 정상 작동 중인지 파악하기 위하여.

(2) 서비스가 정상적이지 않을 경우, 구체적이진 않아도, 어느 부분에서 문제가 있는지 파악하기 위하여.

해당 사항을 파악하기 위해선, Transaction traces, basiic server monitoring, metrics(CPU, memory, etc) 등을

모니터링 할 수 있어야 한다.

서비스 전체에 대한 책임을 가지고 있는 사람으로서, 장애가 나지 않게 서비스를 제공하는 책임이 있습니다.

서비스에 장애가 발생하였을 때에, 빠르게 해결하기 위해선, 문제를 빠르게 파악할 수 있어야 되고,

구체적으로 파악한 문제를 바탕으로 복구를 진행하여야 합니다.

이 때에, APM 이 없다면 담당자들은 전체를 보지 못하고, 책임을 떠넘기다 서비스 복구에 엄청난 시간이

소모될 수 있습니다.

(1) 전체적인 서비스에 대한 책임을 가지고 있음.

(2) APM 이 없으면, 각 부분을 담당하고 있는 사람들이, 장애가 났을 때에 장애를 처리하는 시간이

늘어나기 때문에, 서비스를 책임지는 사람으로서, 목이 날아갈 수 있음.