쿼카러버의 기술 블로그

리더 선출이란 여러 대의 동일한 코드로 동작하는 어플리케이션 인스턴스들 중에서 특정 인스턴스를 '대표'로 선정하는 과정을 말한다. 리더 선출의 주된 목적은 시스템 내에서 중요한 결정이나 작업을 담당할 ‘리더’를 선정하는 것이다. 이 과정은 특히 분산 시스템이나 클러스터 환경에서 중요하다. 본 글에서는 그 중에서도 쿠버네티스에서의 리더 선출에 대해 다룬다. 다시 말해 쿠버네티스에 의해 조정되고 관리되는 리더 선출 메커니즘에 대해 다루려고 한다. 쿠버네티스는 Distributed Lock을 활용해 다수의 인스턴스 중 한 인스턴스를 리더로 선출할 수 있게 하여, 오직 그 인스턴스만이 특정 작업을 수행할 수 있도록 보장한다. 참고로 블록체인에서도 리더를 선출한다. 하지만 이 글에서 말할 리더 선출과는 다른 개념..

앞 글에서 prometheus의 기본 개념에 대해 알아보았다. 이미 솔루션들에서 제공해주는 exporter이 있는 경우에는 왠만하면 exporter에서 제공해주는 정보만으로 모니터링이 가능하지만, 직접 웹 어플리케이션을 동작하고, 이 어플리케이션에 대한 모니터링을 수행해야 하는 등의 경우에는 custom exporter를 구현해야한다. 기본으로 제공되는 exporter들을 활용할 때도 물론이지만, custom exporter를 구현하기 위해서는 prometheus에서 수집하고 있는 메트릭이 어떤 종류가 있는지에 대해 알아둘 필요가 있다. 따라서 본 글에서는 프로메테우스에서 수집할 수 있는 메트릭의 종류들에 대해 알아보고자 한다. 메트릭 종류 프로메테우스에서 제공하는 메트릭 종류는 크게 아래와 같다. (1..

prometheus는 오픈 소스 기반의 모니터링 시스템이다. (그리스 로마 신화에서 최초로 인간을 창조했다는 그 프로메테우스가 말고..ㅎ) SoundCloud사에서 만들었지만 지금은 독립형 오픈소스 프로젝트이고, 현재 필자가 속해 있는 회사는 prometheus를 사용하여 쿠버네티스 환경에 동작하는 어플리케이션들의 메트릭을 수집하고 있다. 모니터링은 로깅과는 성격이 약간 다르다. 로깅은 어플리케이션 로직 내에서 발생하는 일들에 대한 것이라면, 모니터링은 response latency, RPM, 컨넥션 갯수와 같은 모니터링 지표들을 수집하여 저장하고 검색하는 것을 의미한다. prometheus는 기본적으로 pull model을 사용해 메트릭을 수집한다. 이를 간단하게 설명하자면 메트릭 대상이 되는 타겟 서..

Ansible 시리즈 1탄을 작성한다. 본 시리즈의 목적은 다음과 같다 (1) Ansible 기본 개념 및 설치 진행 (2) Ansible를 활용해 여러 노드들에 동시에 명령어 실행 (패키지 설치 등) (3) Ansible를 활용한 부하테스트 진행 (locust) 사실 시리즈 2탄 까지만 봐도 Ansible를 활용도가 충분하다. 예를 들어 여러 대의 노드에 카프카를 설치한다든지 할 때 각 서버에 ssh로 접근해서 동일한 커맨드를 계속 반복하는 것보다는 Ansible를 활용하면 한번에 여러 노드에 설치할 수 있고, 이후에도 동일한 세팅을 설정할 수 있기 때문이다. 하지만 필자는 이번에 10대의 노드를 활용해 부하테스트를 진행해보았고, Ansible를 활용하면 간단하게 부하테스트도 세팅할 수 있기 때문에, ..

쿠버네티스는 container orchestration, 즉 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 툴이다. 쿠버네티스를 활용하면 다수의 컨테이너화된 어플리케이션을 쉽게 배포할 수 있다. 쿠버네티스를 활용한 어플리케이션 배포에 가장 기본이 되는 것은 yaml파일이다. 쿠버네티스의 오브젝트를 정의하고 생성할 때 yaml파일 형식을 활용하기 때문이다. 쿠버네티스를 통해 어플리케이션을 배포하기 위해서는 많은 object들이 필요하다. 대표적인 예가 deployment, pod, configmap secret, service, persistent volume, persistent volume claim 등이 있다. 위와 같은 쿠버네티스 object(리소스)들을 정의하고 다루는데 활용되는 yam..

앞 시리즈에서는 다음의 내용을 다루었다. 1) Github Action의 Core 개념 https://etloveguitar.tistory.com/74 2) 내 레포에 Github Action에 간단한 CI 적용해보기 https://etloveguitar.tistory.com/75 그러면 이번 시리즈에서는 남들에게 노출되면 안되는 정보를 Secret, Environment(시크릿, 환경변수)에 담아 Github Action에 적용하는 법을 알아보자 Secret등록 레포의 Settings에 들어가보면 아래처럼 Secret을 설정할 수 있음 여기서 내가 원하는 Key이름을 정해주고 Value에 원하는 값을 담아주면 Github에서 암호화해서 정보를 보관하고 있다가 Github액션에서 해당 키로 Secret을..

앞 글에서는 github action의 core 개념에 대해서 알아보았다. Github액션을 최대한 쉽게 이해시켜주기 위해 간단히 정리했으니, 바로 실습에 들어가기전에 아래 글에서 Core개념을 간단하게나마 익히는 것을 추천한다. https://etloveguitar.tistory.com/74 [Github Action] Github Action 시리즈 1탄 : Core 개념 (Workflow, Event, Job, steps, runner, step, action 개념 쉽게 정 앞으로 간단하게 Github Action을 사용해서 CI/CD를 구현해보려고 한다. 시작하기에 앞서 Github Action의 Core개념을 익혀보고 다음 시리즈에서는 실제로 Github Action을 실행시켜보도록 하겠다. C..

앞으로 간단하게 Github Action을 사용해서 CI/CD를 구현해보려고 한다. 시작하기에 앞서 Github Action의 Core개념을 익혀보고 다음 시리즈에서는 실제로 Github Action을 실행시켜보도록 하겠다. Core Workflow 최상위 개념 여러 개의 Job으로 구성되고, Event에 의해 트리거될 수 있는 자동화된 프로세스 Workflow파일은 YAML으로 작성되고, Github Repository의 .github/worflows폴더 아래에 저장된다. Event Workflow를 Trigger하는 특정 활동이나 규칙을 의미한다. 특정 브랜치로 push 특정 브랜치로 Pull Request 특정 시간대에 반복 (Cron) Release Webhook이나 API를 통한 실행 Job 하..