-
-
Notifications
You must be signed in to change notification settings - Fork 21
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat : 2024-02-06-Pinpoint_홍주광 (#46)
- Loading branch information
Showing
1 changed file
with
221 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,221 @@ | ||
| --- | ||
| layout: post | ||
| title: APM(feat.Pinpoint) | ||
| author: 홍주광 | ||
| categories: 기술세미나 | ||
| banner: | ||
| image: https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0206/2_pinpoint.png | ||
| background: "#000" | ||
| height: "100vh" | ||
| min_height: "38vh" | ||
| heading_style: "font-size: 4.25em; font-weight: bold; text-decoration: underline" | ||
| tags: [APM, Pinpoint, LGTM, 모니터링] | ||
| --- | ||
|
|
||
| 안녕하세요. APM 그리고 핀포인트에 대해 발표하게 된 홍주광입니다. | ||
|
|
||
| ## LGTM | ||
|
|
||
| 여러분 LGTM 이라는 말을 들어보셨나요? | ||
|
|
||
|  | ||
|
|
||
| 코드리뷰 때 들어보셨을 것 같은데요. 제가 소개드릴 LGTM 은 코드리뷰 때가 아닌 | ||
|
|
||
| 그라파나에서 밀고 있는 기술스택을 의미합니다! | ||
|
|
||
| > L : Limit(로그 수집 저장소) | ||
| > | ||
| > G : Grafana(시각화) | ||
| > | ||
| > T : Tempo(분산 추적 저장소, APM) | ||
| > | ||
| > M : Mimir(시계열 메트릭 저장소) | ||
| ## LGTM을 미는 이유 | ||
|
|
||
| 그렇다면 그라파나에서는 왜 LGTM 을 밀고 있을까요? | ||
|
|
||
| 보통 시스템 모니터링, 로깅, 애플리케이션 성능 모니터링을 구성하기 위해 대부분의 회사에서는 여러가지 오픈소스와 SaaS를 구성하여 사용하고 있습니다. | ||
|
|
||
| 시스템 모니터링 | ||
| * 프로메테우스, 그라파나, Zabbix, DataDog 등 | ||
|
|
||
| APM | ||
| * Scouter, Elastic APM, Pinpoint 등 | ||
|
|
||
| 로깅 | ||
| * ELK, Loki, CloudWatch 등 | ||
|
|
||
| 위처럼 정말 여러가지 오픈소스와 SaaS 가 있습니다. | ||
|
|
||
| CPU, Memory, Disk, Network Bytes 등의 리소스를 확인하기 위해서는 A 에서 확인하고, | ||
|
|
||
| Application Log 를 확인하기 위해서는 B 에서 확인하고 | ||
|
|
||
| APM 을 확인하기 위해서는 C 에서 확인해야 하는 상황이 생깁니다. | ||
|
|
||
| 이를 해결하기 위해 그라파나에서는 단일 대시보드에서 시스템 메트릭과 로그, 분산 트레이싱을 모두 확인할 수 있도록 | ||
|
|
||
| LGTM(Loki, Grafana, Tempo, Mimir) 를 밀고 있습니다. | ||
|
|
||
| ## APM | ||
|
|
||
| APM 은 | ||
|
|
||
| > Application Performance Management | ||
| > | ||
| > Application Performance Monitoring | ||
| 입니다. 애플리케이션의 성능을 관리, 모니터링을 뜻합니다. | ||
|
|
||
| APM 도구를 사용하면 서버에서 발생하는 메트릭(CPU, Memory, Thread, Transaction, ...), 이벤트, 로그, 트랜잭션 등을 모니터링할 수 있습니다. | ||
|
|
||
| ## APM 주요기능 | ||
|
|
||
| * 성능 문제를 예측하고 방지 | ||
|
|
||
| * 고객 기대 성능 보장, 고객 경험 향상 | ||
|
|
||
| * 응답 시간 보장 | ||
|
|
||
| * 가용성 증대, 다운타임 감소 | ||
|
|
||
| ## APM 도구의 핵심 지표 | ||
|
|
||
| * 응답시간 | ||
|
|
||
| * 요청 비율 | ||
|
|
||
| * 에러율 | ||
|
|
||
| * 리소스 사용률 | ||
|
|
||
| * 운영중인 시스템 수 | ||
|
|
||
| ## 핀포인트 | ||
|
|
||
|  | ||
|
|
||
| 핀포인트는 대규모 분산 시스템, 특히 Java로 구축된 시스템의 성능을 모니터링하고 분석하도록 설계된 | ||
|
|
||
| 오픈 소스 애플리케이션 성능 관리(APM) 도구 입니다. | ||
|
|
||
| ## 핀포인트 특징 | ||
|
|
||
|  | ||
|
|
||
| 이 중에서 가장 장점으로 꼽히는 것은 아무래도 | ||
|
|
||
| `Bytecode instrumentation` 입니다. 즉, 코드 수정없이 없는 것이죠. | ||
|
|
||
| 그 외에도 여러가지 특징이 있으니 한번 읽어보시면 좋을 것 같습니다. | ||
|
|
||
| ## 프로메테우스랑 그라파나가 있는데 굳이 써야할까? | ||
|
|
||
| 보통 프로젝트를 하시다보면 프로메테우스랑 그라파나로 모니터링을 설정하신 팀들이 많으실 텐데요. | ||
|
|
||
| 저희 팀 또한 그랬고 추가적인 모니터링 도구가 필요할까에 대한 의문을 가지고 있었습니다. | ||
|
|
||
| 결론부터 말씀드리자면 하는 모니터링 역할이 달라서 추가해도 좋다인데요. | ||
|
|
||
| 지금부터 핀포인트로 그 이유를 설명해 드리겠습니다. | ||
|
|
||
| 1. 핀포인트는 트레이싱을 통해 요청을 추적할 수 있고, 어느 지점에서 문제가 되었는지 정확히 파악하고 알려줍니다. | ||
| 2. 데이터 수집 방식에 따른 확장성 차이 | ||
| - 프로메테우스는 Exporter 가 주기적으로 메트릭 데이터를 Pull 방식으로 수집하지만 핀포인트는 Push 방식으로 Collector 에 전달합니다. | ||
|
|
||
| -> 이는 곧 프로메테우스보다 핀포인트가 분산 서버에 적합하다는 뜻이기도 합니다. | ||
|
|
||
| ## 핀포인트를 알아보자 | ||
|
|
||
|  | ||
|
|
||
| 위에 보이는 사진은 ServerMap 입니다. | ||
|
|
||
| ServerMap 지표를 활용하면 서버의 전체적인 시스템 아키텍처와, 각 End-point에 대한 요청 비율 등을 쉽게 파악할 수 있습니다. | ||
|
|
||
| 1번을 보시면 시스템 전체 구조를 파악할 수 있고 어디로 요청이 얼만큼 가는지, 평균 응답속도는 얼마인지를 알 수 있습니다. | ||
|
|
||
| 2번을 보시면 그래프로 지표를 볼 수 있고 2번 박스의 위쪽 그래프의 점들은 하나의 트랜잭션을 의미합니다. | ||
|
|
||
| * 분산 시스템의 연결된 상황과 트랜잭션을 시각화 | ||
|
|
||
| * 각 요청의 성공, 실패 지표 제공 | ||
|
|
||
| * 각 end-point에 대한 요청 수 제공 | ||
|
|
||
| * 각 요청의 응답 시간 제공 | ||
|
|
||
|  | ||
|
|
||
| 위 사진은 멀티모듈 프로젝트의 핀포인트 사용 사례 사진입니다. | ||
|
|
||
|
|
||
|  | ||
|
|
||
| 핀포인트도 그라파나처럼 힙 사용량과 CPU 사용량도 같이 제공하고 있습니다. | ||
|
|
||
|
|
||
|  | ||
|
|
||
| 위 사진은 부하테스트(스트레스 테스트)를 진행한 모습인데요. | ||
|
|
||
| 점점 응답 시간이 오래 걸리다가 빨간 점들이 생기면서 Fail 이 나고 있는 모습입니다. | ||
|
|
||
| 이처럼 실패가 났을 때 추적하는 방법을 말씀드리겠습니다. | ||
|
|
||
|  | ||
|
|
||
|  | ||
|
|
||
| 빨간 박스만 따라가면서 보시면 되는데요. | ||
|
|
||
| 첫번째 사진에서 드래그라고 적힌 박스처럼 빨간 점이 생긴 부분을 드래그하면 아래 사진처럼 트랜잭션이 나오게 됩니다. | ||
|
|
||
| Call Tree 로 되어있어서 타고 들어가면 어떤 사유로 에러가 발생했는지 추적이 가능합니다. 또한 응답속도와 정확히 어느 지점에서 에러가 났는지 알 수 있습니다. | ||
|
|
||
| ## 핀포인트 설치 | ||
|
|
||
| 핀포인트 설치는 정말 간단한데요. | ||
|
|
||
|  | ||
|
|
||
| * 터미널에서 단 4줄만 입력하시면 설치가 끝납니다. | ||
|
|
||
|  | ||
|
|
||
| * 프로젝트를 여시고 빨간 박스부분에 아래처럼 입력하시면 됩니다. | ||
|
|
||
|  | ||
|
|
||
|
|
||
|  | ||
|
|
||
|  | ||
|
|
||
| 설정이 완료되고 프로젝트를 실행하시면 평소 뜨던 SPRING 글자보다 PINPOINT 글자가 먼저 나오는 걸 볼 수 있습니다. | ||
|
|
||
| 그러면 성공입니다. | ||
|
|
||
| ## 핀포인트 도입 팁 | ||
|
|
||
| 저희 팀도 프로젝트에 핀포인트를 사용하려고 백엔드 서버에 설치를 했는데요. 생각보다 많은 메모리를 사용하는 것을 확인했습니다. | ||
|
|
||
| 당시, 백엔드 서버는 t2.micro EC2 였으며 도커로 핀포인트를 돌렸을 때 메모리가 7~8GB 나왔었습니다. 그래서 서버가 죽는 현상이 발생했습니다. | ||
|
|
||
| 서버 스펙을 올리기에는 배보다 배꼽이 큰 상황이여서 다른 방법을 찾아보았습니다. | ||
|
|
||
|  | ||
|
|
||
| 위 사진은 분산 서버시에 핀포인트 적용한 구조인데요. 위에 보시다 싶이 서버 옆에는 Agent 만 두고 나머지는 다른 별도의 서버에 두는 방식입니다. | ||
|
|
||
| 핀포인트 서버를 별도로 만들어 혼자 사용하거나, 혹은 로컬에서 돌리는 방법을 찾게되었습니다. | ||
|
|
||
| ## 결론 | ||
|
|
||
| 그라파나가 숲을 본다면 APM은 나무를 본다고 말 할 수 있습니다. 어느 지점에서 실패가 났고 어느 지점에 병목 현상이 일어났는 지 APM 도구를 사용한다면 더 빠르게 대처하고 | ||
|
|
||
| 성능 개선에 도움이 될 것 이라고 생각됩니다. | ||
|
|
||
| 여러분도 관심있으시다면 한 번쯤 도입해보는 것을 추천합니다. |