우선 프로메테우스는 Pulling이기 때문에 Exporter들과 통신할 수 있는 장비에 설치하는 것이 좋다.
즉, 아무 곳이나 설치해서 Exporter들과 하나씩 통신을 다시 뚫는 불상사는 없어야 할 것이다.
너무 많은 곳과 통신을 하면 성능이 안좋아지므로.. Prometheus를 다시 Pulling 하는 구조 또한 고려할 수 있다.
기본적으로 프로메테우스 오피셜 사이트에서 설명하는 프로메테우스는 아래와 같다.
고성능이 요구되는 분야 중 게임을 예로 들자
-> 물론 클라이언트의 성능이 높아야 되는 경우가 더 많지만 오히려 MMORPG와 같이 대규모 온라인 게임은 Server side도 고려해야할 것들이 많다.
Naver Cloud Platform이 제공하는 그림을 보자
여기서 프로메테우스로 메트릭을 모니터링 해야할 부분은 어디일까?
물론 DB 성능도 측정할 수 있겠지만 주로 Application의 성능을 측정하고 싶다.
즉, Game Server들에 대해서 메트릭을 수집하고 싶을 것이다.
그렇다면 프로메테우스는 어디 위치해야 가장 효율적일까?
Game Server에 접근하는 방식에 따라 다르겠지만 Game Server를 관리하는 장비가 존재할 것이다.
Game Server는 Fail Over, Auto Recovery, Auto Scale 등과 같이 여러가지 강인성을 지녀야 하는 서버이다.
즉, Game Server 바라보고 있는 장비가 존재해야 한다는 것인데 주기적으로 헬스체크를 하든, 무엇을 하든 그런 장비가 존재한다.
다시 말해서 프로메테우스도 이 장비 위에서 게임서버의 각 익스포터에 대해 메트릭을 수집하는 것이 좋다.
물론 새로운 장비를 띄우고 그것을 게임서버 전체와 통신이 가능하게끔 하는 것도 상관은 없다.
다시 말해서 프로메테우스가 /metric 을 날려서 메트릭을 가져오기 위해선 통신이 되어야 한다는 것이다.
하지만 게임의 운영 특성 상 여러가지 케이스가 존재한다.
즉, 운영 상 필요한 작업을 하기 위해 통신이 되어야 한다는 것이다.
예를 들어
불법적인 유저가 존재한다고 하자.
유저를 제재하기 위해서는 유저의 상태를 알기 위해 DB를 조회할 수 있어야 하고
현재 유저의 상태에 대해서 알 수 있어야 하고 유저를 게임서버로부터 킥할 수 있어야 한다.
즉, 여러가지 통신이 종합적으로 필요하다.
이러한 운영을 위해서 인하우스 툴을 만드는 것이 보통이다.
어떤 과정을 거칠지는 블랙박스지만 맨 위에서 DB와 통신, 각종 서버와 통신이 가능한 장비가 존재할 것 같다는 합리적인 생각이다.
아래 빨간 동그라미와 같은 장비가 존재할 것이고 그 곳에 프로메테우스를 띄워놓아도 무방하다고 생각한다.
계속 반복되는 일이지만
프로메테우스는 Pull이기 때문에 프로메테우스가 서버들을 알고 있어야 한다.
Kubernetes 처럼 Service Discovery가 주기적으로 일어나지 않는 한 말이다.
프로메테우스는 유지 보수 측면에서 위와 같은 장비에 띄우는 것이 좋으며
모든 것에 접근하려는 성질이 있기에 더욱 보안을 철저히 해야할 것이다.
아마존의 게임리프트도 참고하면 구조가 비슷하다.
당연히 돈을 받고 팔기 때문에 오픈소스 프로메테우스를 쓰진 않겠지만
Cloud Watch도 마찬가지다.
Push인지 Pull인지는 모르겠지만 여튼 모든 곳과 통신이 되기 때문에.. 우리가 모니터링 가능한 것이다.
https://docs.aws.amazon.com/gamelift/latest/developerguide/monitoring-cloudwatch.html
참고링크
'DevOps > Prometheus' 카테고리의 다른 글
| Exporter 연동 (0) | 2023.01.13 |
|---|---|
| Prometheus_ (0) | 2023.01.13 |
| 프로메테우스, Prometheus Up & Running - ch.1 (0) | 2022.11.07 |
| Prometheus, 프로메테우스 기본 개념 (0) | 2022.10.02 |