이전 글에서 효과적인 모니터링을 위해 로그와 매트릭을 동시에 수집해야 한다고 했다. 이를 위해 Log 수집에 특화된 Flunent Bit, FileBeat 등이나,Metric 수집에 특화된 Telegraf, Prometheus Exporter 등을 함께 사용해볼까 했다. 하지만 이렇게 되면,초반 세팅과 유지보수가 힘들고 비교적 벤더에 의존적이라고 판단했다. 그렇게 해서 선택한 것이 과거에 가볍게 써본적 있는 Opentelemetry Collector이다. 🙋🏻Opentelemetry 란?OpenTelemetry는 메트릭, 추적, 로그를 포함한 모든 원격 측정 데이터를 수집하고 표준화하며,이를 다양한 백엔드로 내보낼 수 있는 포괄적인 관찰 프레임워크이다. 주요 특징은 크게 다음과 같다. - 원격 측정 ..

개인적인 사정으로 애플리케이션 모니터링을 위한 파이프라인을 설계해야했다. 🙋🏻 애플리케이션 모니터링"애플리케이션 모니터링"은 소프트웨어 애플리케이션 내의 성능, 가용성 및 오류에 초점을 맞춥니다. 이러한 유형의 모니터링은 애플리케이션이 원활한 사용자 경험을 제공하는 데 필수적입니다.성능: 애플리케이션 성능 모니터링에는 응답 시간, 트랜잭션 속도 및 처리량 추적이 포함됩니다. 이는 사용자 경험에 영향을 줄 수 있는 병목 현상과 성능 문제를 식별하는 데 도움이 됩니다. New Relic 및 AppDynamics와 같은 도구는 애플리케이션 성능에 대한 자세한 통찰력을 제공합니다.가용성:애플리케이션을 사용자가 사용할 수 있고 액세스할 수 있도록 하는 것이 가장 중요한 관심사입니다. 애플리케이션 모니터링 도구..

MSA 수강신청 프로젝트를 진행할 때,시스템 가용성을 유지하기 위해 오토 스케일링을 적용해보게 되었다.(애초에 오토 스케일링을 위해 MSA로 배포했다) 쿠버네티스는 Load Balancing, Persistance Volume 등 오케스트레이션에 도움이 되는 기능들을 제공한다. 이번에는 그 중 Horizontal Pod Autoscaler(HPA)를 사용했다.  HPAHPA는 CPU, Memory와 같은 리소스 사용량에 따라 Pod의 개수를 조절하는 기능이다. 제한 리소스량을 yaml 파일을 통해 지정하면 해당 제한을 넘칠 경우 Pod이 늘어나고,다시 제한 아래로 일정시간 내려갈 경우 Pod이 줄어든다.(트래픽 분산의 경우 알아서 일어난다) 실제 사용했던 yaml 파일을 살펴보자.apiVersion: a..

기본적으로 Envoy AccessLog는 IP주소를 기반으로 생성된다. 한 번의 통신이 발생 했을 때 통신의 주체의 각 Envoy가 로그를 생성하기 때문에 2개의 로그가 만들어진다. 이때 생성 된 로그의 IP 주소가 깔끔하게 나오는 게 아니라 매우 난해하게 생성된다. 로그 내 필드와 실제 로그를 분석해 보면서 알게 된 Upstream, DownStream에 대해 정리해보겠다. UpStream? DownStream?두 개념은 트래픽의 방향성이 중요하다. 일반적으로UpStream이란 클라이언트에서 목적지로의 데이터 트래픽을 의미하고,DownStream는 서버에서 요청지로 보내는 데이터 트래픽을 의미한다. Envoy에서는UpStream이란 Envoy에게 요청을 받고, 응답을 보내주는 호스트 즉, 서버를 의미하..

로그와 매트릭을 수집하는 Pod에 문제가 발생하여 스트림이 끊긴 이후에Pod이 회복되면 알아서 스트림을 다시 연결하고 전송하는 것을 본 경험이 있다. 내가 경험하기론 재연결 로직을 따로 구현하지 않으면 스트림을 다시 열지 않았기 때문에Envoy Proxy는 어떻게 구현되어 있을 지 궁금해졌다.(참고로, Stream의 경우 연결이 끊어진 순간 사라지기 때문에 재사용이 불가능하다고 한다)  먼저, Envoy Proxy의 AccessLogs 패키지 문서를 봤다.(https://pkg.go.dev/github.com/envoyproxy/go-control-plane/envoy/service/accesslog/v3) 재연결의 경우 클라이언트 측에서 시도할 것이기 때문에 클라이언트 코드를 주로 살펴봤다. Envoy..

저번 글에서 gRPC를 이용해 Envoy Proxy의 로그 및 매트릭을 전송 받는 기반을 다졌다. 이제 길을 닦아놨기 때문에 당연히 문을 열어야 된다. Envoy Proxy가 gRPC 클라이언트 입장이기 때문에 서버를 구성해야 했다. go언어로 AccessLog서버를 구성해봤다. 먼저 protobuf와 서비스 정의를 필요하기 때문에 공식 패키지를 임포트했다."github.com/envoyproxy/go-control-plane/envoy/service/accesslog/v3"(accesslogs로 alias했다) gRPC 구성 과정추후 정리할 예정이지만, 간단하게 과정을 살펴보자면1. tcp 리스너 생성2. gRPC 서버, gRCP 서비스 생성3. gRPC 서버에 서비스 등록 (컴파일된 protobuf ..

이스티오 소개Istio는 오픈 소스 서비스 메시이다. 여기서 서비스 메시란 서비스 간 모든 통신을 처리하는 소프트웨어 계층을 의미한다. 구현체인 Istio는 마이크로서비스 간의 트래픽 관리, 보안 강화, 정책 적용, 모니터링 및 관찰 기능을 제공한다. Istio의 핵심 프록시 엔진이자 이번 글에서 주로 다룰 Envoy Proxy라는 놈이 있다. Envoy는 마이크로서비스가 Pod으로 배포시 함께 배포되는 사이드카 프록시 형태로 동작한다. 다양한 기능을 제공하는데, 그 중 데이터 수집과 관련된 기능은 [분산 추적, 매트릭 수집, 로그 수집]이 있다. Envoy Proxy의 수집 데이터를 가져와보자이 글은 Istio가 설치되어 있고 sidecar injection이 설정되었다는 전제하에 이루어진다. 배포된 ..

개요요즘 자주 보이는 용어인 Serverless. 처음 들었을 때 전공 강의 시간에 배운 PaaS와의 차이가 애매모호 해서 정확히 알고 싶어졌다.   PaaS란?서비스로서의 플랫폼(Platform-as-a-service, PaaS)은 애플리케이션 소프트웨어 플랫폼이 제3사를 통해 제공되는 클라우드 컴퓨팅의 한 형식보통 해당 프로세스와 관련된 인프라 또는 플랫폼을 구축하고 유지관리할 필요 없이 자체 애플리케이션을 개발, 실행 및 관리 할 수 있도록 함Java, Ruby, Python 등의 프로그래밍 언어와 같은 애플리케이션 실행 환경DB 등서버, 네트워크, 보안 부분 → 클라우드 사업자에게 위임클라우드와 온프레미스 인프라 환경에서 모두 실행 가능장점서버 유지 관리의 부담 완화인프라 소프트웨어를 최신 상태로..