Prometheus는 CNCF의 몇 안되는 graduate 프로젝트 중 하나인 시계열 모니터링 시스템입니다. 이런 Prometheus는 일반적인 VM 환경에서도 사용할 수 있지만 Kuberenetes에서 사용하는 MSA 구성에도 사용할 수 있다는 장점 이 있는데요. 하지만 Kubernetes 환경은 비영구적이고 임시적인 Pod를 기반으로 이루어져 있기 때문에 Prometheus를 구성하는 요소와 Prometheus의 메트릭 수집 대상들을 관리하기가 힘들다는 특징이 있습니다. 게다가 Prometheus는 시스템 내부의 yaml Config 파일을 기준으로 설정을 유지하는데, 이는 컨테이너 내부의 파일을 변경하기가 번거로운 Kubernetes 환경에서 Prometheus 관리를 더 힘들게 하는 원인이었습니다..
이 글을 작성하는 2022년 3월은 내가 지금 다니는 회사에 들어온 지 정확히 1년이 되는 날이다. 그리고 이런 기념비적인 날에 나는 회고록을 한 편 작성하고자 한다. 2021년 회고록을 3월이 되어서나 작성하는 것이 이상할 수 있지만 회고, 즉 다시돌아보기 위해서는 먼저 돌아볼만한 경험들이 쌓여야 한다고 생각하기 때문에 입사한지 1년이 되는 지금 회고록을 작성하게 되었다. 또 내가 지난 한해 경험했던 것들을 단지 휘발성 메모리인 내 두뇌 안에 파편적이고 희미하게 가지고 있는 것보다는 영구적 메모리인 블로그에 작성하는 것이 더 단단한 지성적 지층을 만들어 줄 것이라 생각해 회고를 적게 되었다. 작년 한 해에 내가 세웠던 목표는 다음과 같다. 새로운 것을 도전하는데 주저하지 말기 해보고자 했던 것은 어떻게..
Apache beam은 Streaming 및 Batch성 데이터 작업을 지원하는 오픈소스 엔진입니다. "beam"이라는 이름이 Batch에서 "B"를, Streaming에서 "eam"을 가져와 합친 단어라는 데서 Apache beam이 지향하고자 하는 바가 명확히 보입니다. Apache beam은 단일 프로그래밍 모델로 Batch 와 Streaming 데이터 작업을 지원하며, 이렇게 작업한 모델은 다양한 런타임에서 구동할 수 있다는 다양한 활용성이 장점입니다. 현재 데이터 파이프라인 생성을 지원하는 언어는 Python, Java 및 Go가 있습니다. 간단히 Apache beam을 사용해보고자 한다면 아래 링크의 Beam Playground에서 웹 인터렉티브 환경을 이용해볼 수도 있습니다. https://..
Kubernetes는 컨테이너 오케스트레이션을 구현하기 위해 독특한 네트워킹 구조를 가지고 있습니다. 이런 Kubernetes의 네트워킹 구조에서 단연 중요한 것은 Service라는 개념입니다. Service는 외부 네트워크와 격리되어 있으며 임시적이라는 특성을 가진 Pod들을 외부와 통신할 수 있도록 고정적인 주소로 노출하는 방법을 말합니다. 이 Service의 가상 IP를 구현하기 위해서는 kube-proxy라는 컴포넌트가 전적으로 맡게 되며, 각 node에 위치해 netfilter라는 linux 패킷 조작 툴을 사용해 패킷의 생명주기를 조작합니다. 예를 들어 kube-proxy가 Service의 구현을 위해 사용하는 mode 중 iptables 모드는 패킷이 node로 들어오면 kube-proxy에..
Gradle은 여러 언어를 지원하는 빌드 자동화(build automation) 도구입니다. 기존에는 Ant나 Maven과 같은 여러 빌드 도구가 있었지만, Gradle은 이 중 가장 최근에 출시한 빌드 도구로써 성능이나 이용성 면에서 더 진보한 도구이기도 합니다. 이번 포스팅에서는 Gradle을 이용해서 GCP API를 연동한 Springboot 웹 애플리케이션을 빌드해보고, 이를 통해 생성된 Jar 아티팩트를 GCP의 아티팩트 레포지토리인 Artifact registry에 배포하는 과정을 step by step으로 알아보도록 하겠습니다. 1. GCP 리소스 구성 우선 Google Cloud Platform에서 준비해야 할 리소스들을 구성합니다. 이번 포스팅에서는 Gradle을 이용해 생성한 Jar 아..
우리가 관측 가능성(Observability)에 대해서 말할때, 보통 시계열의 수치 데이터를 뜻하는 메트릭(Metric)이나 인간이 읽을 수 있는(human-readable) 형태로 상태를 출력하는 로그(Log)를 떠올릴 것입니다. 하지만 관측 가능성의 3개 기둥(Three pilars of observability)라고 하는 3개 주요 관측 가능성 요소 중에는 메트릭,로그와 함께 트레이스(Trace)가 존재합니다. 이 트레이스가 무엇인지, 또 어떻게 트레이스에 대한 관측 가능성을 확보할 수 있는지 대표적인 트레이싱 OSS 도구인 Grafana tempo와 함께 알아보겠습니다. 1. 트레이스가 뭐지? 트레이스는 메트릭, 로그와 함께 관측가능성의 3개 주요 요소 중 하나입니다. 하지만 트레이스에 대해서는 ..
EFK stack이란 Elasticsearch, Fluentd, Kibana를 얹은 스택을 말합니다. 기존의 ELK stack과는 로그 파이프라인 역할을 하던 Logstash를 Fluentd로 대체했다는 차이점이 있습니다. 그럼 Fluentd를 사용한 EFK stack은 ELK stack과 어떤 점이 다른지, 각자 어떤 장단점이 있는지 살펴보겠습니다. 그리고 Kubernetes 환경에서 EFK stack을 구축해 컨테이너 로그를 중앙화하는 실습도 함께 보도록 하겠습니다. 1. Fluentd란? 우선 Fluentd가 어떤 툴인지 먼저 알아봐야 겠습니다. 가장 먼저 Fluentd를 만나볼 수 있는 곳은 CNCF 프로젝트인데요. fluentd는 몇 안되는 CNCF의 graduated project 중 하나입니..
AWS, GCP, Azure 등의 퍼블릭 클라우드를 사용하다보면 마주하게 되는 꼭 난감한 상황이 있습니다. 내가 어떤 클라우드 리소스를 생성했는지, 어디에 어떤 리소스를 추가했는지 파악하지 못하는 경우가 있다는 것입니다. 특히 관리해야 하는 퍼블릭 클라우드 리소스의 규모가 크고 방대할수록 이 문제는 심화되는데, 퍼블릭 클라우드는 리소스의 사용량만큼 비용을 지불해야 하는 구조이기 때문에 이는 재정적으로 큰 문제로 다가올 수 밖에 없습니다. 이같은 문제는 보통 내가 관리하는 퍼블릭 클라우드 리소스의 Observability, 즉 관측가능성을 확보하지 못할 때 발생하게 됩니다. 즉 관측가능성이 어플리케이션이나 인프라에서 말하는 메트릭, 로그, 트레이스 뿐만 아니라 클라우드 리소스에도 통용될 수 있다는 말입니다..
멀티 클라우드 환경이 점점 대세가 되어가면서 자연스럽게 다양한 클라우드 플랫폼의 로그 및 메트릭을 중앙화하려는 시도들이 많아지고 있습니다. 각 클라우드 벤더마다 사용하는 로깅, 혹은 모니터링 환경(AWS의 Cloudwatch, GCP의 Operations)이 다르기 때문에 각기 다른 환경을 통일해야만 통합된 관측 가능성을 확보할 수 있기 때문입니다. 이런 각기 다른 관측 가능성 환경을 통합하는 도구로 주로 사용되는 것이 Elastic 사의 Elasticsearch입니다. Elasticsearch는 주로 데이터 처리 파이프라인인 Logstash와 데이터 시각화를 이용한 대쉬보드 도구인 Kibana와 같이 사용되어 이 세 가지 도구를 ELK Stack이라고도 부릅니다. ELK Stack은 OSS이고 컨테이너..
언젠가부터 빅데이터에 대한 언급이 많아지고 있습니다. 거대한 데이터를 수집하고 분석하는 작업에 대한 수요가 늘면서 이를 수행할 수 있는 툴들이 하나둘씩 나타나고 있습니다. 가령 요즘은 빅쿼리, 데이터브릭, 스노우플레이크와 같은 SaaS형태의 종합 빅데이터 분석도구가 수요를 충족하려 하고 있습니다. 하지만 이런 최근의 SaaS 툴 이전에 빅데이터 분석의 원조격으로 불리는 시스템이 존재했습니다. 그것이 바로 Apache hadoop 입니다. Apache hadoop은 분산 환경에서 빅 데이터를 처리하기 위한 Open-source 프레임워크입니다. 그리고 Apache hadoop을 중심으로 HDFS,YARN 및 연관 도구들을 일컬어 Apache Hadoop Ecosystem(아파치 하둡 생태계)라고 합니다. ..
