들어가며 이 문서는 Apache 2.0 License인 Grafana v7.5.0 을 기준으로 작성했습니다. Grafana v8.0 이후부터는 AGPLv3를 사용합니다. Create Alerts Grafana Alert을 통해 대시보드 패널에 룰을 첨부할 수 있습니다. 룰을 지정하고 대시보드를 저장하면, Grafana는 alert rules을 별도의 alert rules storage로 추출하고 이를 관리합니다. Grafana v7.5 기준으로 그래프 패널의 Alert 탭에서만 알럿을 구성할 수 있습니다. v8.0 이후부터 구성 파일, cli로 알럿을 구성하는 것이 가능합니다. 알럿 구성 세부사항은 공식 문서 참고 https://grafana.com/docs/grafana/v7.5/alerting/cre..
들어가며 Prometheus는 Federation을 통해 샤딩된 프로메테우스 메트릭을 통합하여, 수평적 확장을 이뤄낼 수 있습니다. 이 문서를 통해 Prometheus Federation에 대해 정리하고, 핸즈온을 진행합니다. FEDERATION 프로메테우스는 federate configuration을 통해 특정 타임 시리즈 데이터를 다른 프로메테우스 서버로부터 스크랩할 수 있습니다. Use cases Scalable Prometheus Monitoring Moving Prometheus Metric Hierarchical federation 프로메테우스를 계층적으로 결합함으로써 수십 개 데이터센터, 수백만 개 노드로 확장 가능 트리 형태로, 상위 계층의 프로메테우스 서버는 더 많은 하위 프로메테우스에서..
들어가며 Apache License 2.0인 Grafana v7.5 기준으로 Grafana panel을 png image로 렌더링하고, 이를 외부 저장소에 저장하여, 알럿으로 전송하는 워크플로우에 대해 이야기합니다. Image rendering Grafana는 공식 Image renderer 플러그인을 통해 알럿 발생 시 대쉬보드 패널을 png image로 자동 변환하는 기능을 지원합니다. 이를 통해 Grafana는 자동으로 패널 이미지를 생성하여 alert에 추가할 수 있습니다. 패널과 대쉬보드를 png 파일로 변환하기 위해서는 Grafana Image Renderer 플러그인을 필수적으로 설치해야 하는데요. Grafana v7.5 기준에서 image renderer 최신 호환은 v3.5.0 입니다. ..
들어가며 영속성은 데이터베이스에 커밋된 쓰기 작업이 영구적으로 유지되도록 보장하는 데이터베이스 시스템의 중요한 속성입니다. MongoDB 에서는 단일 멤버 인스턴스의 영속성을 넘어 클러스터(레플리카 셋) 수준의 영속성 또한 고려해야 하는데요. 이 문서를 통해 레플리카 셋의 영속성에 대해 정리해보도록 하겠습니다. journal 단일 멤버 수준에서, 서버 오류 발생으로 데이터베이스가 다운되더라도 데이터 영속성은 보장되어야 합니다. MongoDB는 데이터 영속성을 보장하기 위해 journal 저널 이라는 로그 선행 기입 write-ahead log(WAL)을 사용하는데요. WAL은 데이터베이스 시스템의 영속성 보장을 위해 사용되는 일반적인 개념입니다. WAL을 사용하면 데이터베이스 자체에 변경 사항을 적용하기..
들어가며 Truth is not determined by a majority vote - Pope Benedict XVI 진실은 다수결로 결정되지 않는다는 말이 있죠. 그러나 DDIA에서 마틴 클레프만이 말했듯이 분산 시스템의 합의 Consensus는 이야기가 다른데요. 노드 간 선거에 의해 quorum 정족수 이상의 득표를 했을 때, 시스템의 어떠한 문제에 대해 합의하는 Raft Consensus Algorithm 뗏목 합의 알고리즘 에 적용되는 이야기입니다. 물론 이 외에도 많은 합의 알고리즘이 있습니다. Raft Consensus Algorithm에 대해서 잘 정리한 블로그가 있네요. Raft에 대한 자세한 설명은 링크로 갈음하겠습니다 :) 모든 노드가 어떤 문제에 동의하는 합의는 분산 시스템에서 ..
들어가며 트랜잭션을 말할 때 ACID 얘기를 하지 않을수가 없죠. 개인적으로 ACID의 다른 어떤 요소보다도 가장 중요한게 Isolation이 아닐까 하는데요.Isolation을 이해해야 비로소 트랜잭션에 대해 말 할 수 있다고 생각합니다. Isolation을 처음 이해하고 설레였던(!) 기억이 있네요. 이 문서를 통해 MySQL InnoDB 엔진과 함께 격리 수준을 달리 하며, 각 수준에서 볼 수 있는 현상을 확인하는 hands-on을 진행합니다. Transaction Isolation Level 트랜잭션 개념이 잘 정리된 자료는 어렵지 않게 찾아볼 수 있는데요. 개념과 특징에 대해 나열하는 것이 이 문서의 목적은 아니기에, 간단히만 다루고 넘어가겠습니다. Transaction Isolation Lev..
결론 Redis pub/sub은 scale out 시에 주의해서 사용해야합니다. Kafka vs Redis Kafka와 Redis의 주된 차이점은 다음과 같습니다. 이벤트의 저장 여부 한 이벤트를 받을 수 있는 Subscriber(Consumer) 개수 이벤트의 저장 여부 Kafka는 발행된 이벤트(토픽)가 각 partition에 저장됩니다. 하지만 Redis는 발행된 이벤트(메시지)를 저장하지 않기 때문에, 구독자가 없다면 해당 이벤트는 사라집니다. 휘발. 따라서, 이벤트의 구독과 발행이 실시간으로 이루어져야 되는 상황인지, 혹은 언제든 발행된 이벤트를 읽으면 되는 상황인지 에 따라 선택이 달라질 수 있습니다. 한 이벤트를 받을 수 있는 Subscriber(Consumer) 개수 Redis pub/su..
들어가며 Redis도 pub/sub을 지원합니다. 일반적으로 많이 사용되는 pub/sub인 Kafka 와는 그 특징이 조금 다른데요. 그에 대한 비교는 다음에 다루도록 하고, 이 문서를 통해 Redis pub/sub 에 대해 이야기합니다. hands-on practice를 통해 사용 방법을 정리합니다. Redis pub/sub 레디스는 메시지(topic)를 주고, 받는 기능을 pub/sub 기능을 제공합니다. PUBLISH 커맨드로 메시지를 발행하고, SUBSCRIBE 커맨드로 channel 을 구독하여 메시지를 수신하는 식입니다. 웹 소켓을 통해 메시지를 전송하는 경우 추가 네트워크 통신이 필요하지만, In-Memory 기반의 Redis는 메시지를 빠르게 주고 받을 수 있는 것이 장점입니다. 현재 Co..
