작성한 질문수 31

1

보키님 안녕하세요~

ㅠ 이미 확인하셨다시피 Push, Pull 모델에 대한 내용은 나오지 않지만, 여기서 간단히 설명드리자면

Push 모델은 일반적으로 ELK 스택처럼 로그를 수집하는 환경에서 사용됩니다. 왜냐하면 애플리케이션에서 발생하는 로그는 수시로 발생하겠죠? 이걸 주기적으로 중앙에서 Pull 해가면 실시간성도 떨어지고 수집전까지 애플리케이션에 로그가 잔뜩 쌓일 수도 있습니다.

그리고 Pull 모델은 일반적으로 메트릭 수집 같은 시스템/애플리케이션의 정보를 수집할 때 활용되는데요, 보통 이런 데이터는 실시간성보다는 주기적으로 시스템/애플리케이션의 상태를 파악하고 전반적인 추세를 알아내기 위한 용도입니다. 로그와는 분명 성격이 다르겠죠?

따라서 정리하면 Push 모델, Pull 모델을 선택하기보단 용도에 맞게

• 메트릭 수집은 Pull 모델로 스프링부트 액츄에이터+ 프로메테우스+ 그라파나 같은 스택을 활용

• 로그 수집은 Push 모델로 ELK 같은 스택을 활용

한다고 보시면 되겠습니다. 위에 제가 이야기드린 내용 외에도 비교해서 정리한다면 아래와 같이 정리해볼 수 있겠습니다.

Push vs Pull 모델 선택 기준

• 실시간성

  • Push 모델: 높음 (이벤트 즉시 전송)

  • Pull 모델: 낮음 (폴링 주기에 의존)

• 네트워크 환경

  • Push 모델: 아웃바운드 통신만 가능하면 OK

  • Pull 모델: 인바운드 접근 허용 필요

• 확장성

  • Push 모델: 수집 서버 병목 가능성 증가

  • Pull 모델: 수집 서버 확장으로 병목 해결 가능

• 유지보수

  • Push 모델: 에이전트 관리 부담 증가

  • Pull 모델: 중앙 서버에서 통제 용이

• 적합한 사례

  • Push 모델: 로그, 이벤트 기반 데이터

  • Pull 모델: 주기적 메트릭, 대규모 분산 시스템

그리고 제가 강의에서는 ELK 스택을 다루긴 했지만, ELK 스택의 단점으로 리소스 사용량이 높은 문제가 있습니다. 특히 쿠버네티스에 띄워 여러 파드에서 Logstash가 실행되어야하는경우 이 부분의 단점이 더 부각되는데요, 이런 경우 Logstash 대신 Fluentd를 사용하는 경우도 많이 있습니다.

위 내용은 프로젝트 규모에 무관하게 활용된다고 보셔도 될 것 같아요.

그리고 보통 이런 메트릭 수집, 로그 수집은 팀 단위보다는 회사 차원에서 의사결정이 되는 경우가 많습니다. 프로젝트별로 서로 다른 곳, 다른 UI/UX로 로그를 보거나 메트릭 정보를 보면 아주 불편하겠죠? 그래서 동일한 스택을 활용하는 경우가 많습니다.

혹시 추가로 궁금한 내용 있으면 질문 남겨주시고, 새해 복 많이 받으세요.

감사합니다.

1

ㅠ 완강했는데 나오지는 않는군요....음

그러면 혹시

• 스프링부트 액츄에이터+ 프로메테우스+ 그라파나 대시보드

• ELK: ElasticSearch / Logstash / Kibana 대시보드

이 두개의 차이점과 장단점이 어떤게 있는지 고견을 듣고싶습니다

그리고 현업에서, 프로젝트 규모별로 어느쪽을 더 많이 사용하는지도 알고싶어요~!