블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 


문제 정의 

프로메테우스가 좋은 모니터링 시스템이긴 하지만 두가지 결정적인 문제점을 가지고 있다. 결정적으로 클러스터링 구조를 지원하지 않기 때문에, 확장성과 가용성 문제를 가지고 있다. 

확장성 측면에서는 디스크를 증설하거는 것과 같은 하드웨어 스펙 증설로 어느정도는 해결이 가능하지만 데이타 볼륨이 늘어나고 모니터링 대상이 늘어나면 하나의 프로메테우스 인스턴스로는 감당이 어렵다. 


이런 문제를 해결하는 방법으로는 Federation 이라는 방법을 사용한다. 프로메테우스 인스턴스를 여러개를 기동한 다음에, 중앙에 다른 프로메테우스로 부터 메트릭을 수집하는 다른 프로메테우스를 놓는 방식이고, 데이타 양에 대한 문제는 데이타의 해상도 (예를 들어 전면에 데이타 수집 서버가 10초 단위로 수집 했다면, 중앙 서버에서는 1분 단위로 수집 한다는 등)를 줄이거나 평균이나 합과 같은 대표값을 사용해서 해결할 수 있다. 




다른 문제로는 가용성 문제를 들 수 있다. 프로메테우스는 하나의 서버로 기동되기 때문에 그 서버가 장애로 내려가거나 또는 패치나 서버 리스타트와 같은 유지보수 업무에 의해서 프로메테우스 서버가 내려가더라도 그 시간동안에는 매트릭을 수집할 수 없다는 단점을 가지고 있다. 클러스터링 기능이 없기 때문에 이를 해결하기 위해서는 프로메테우스 인스턴스를 두개 이상 띄운 다음에 같은 대상 시스템으로 부터 매트릭을 수집하는 방식인데, 이렇게 하면, 한 서버가 내려가더라도 다른 서버에 매트릭정보가 수집이 된다.



그러나 역시 불편하고 아키텍쳐가 왠지 제대로 되어 보이지는 않는다.


Thanos (타노스)

그래서 이런 문제를 해결하기 위한 오픈소스가 타노스이다.

기본적인 구조는 다음과 같은 컨셉이다.


여러개의 프로메테우스로 부터 매트릭을 조합해서 타노스에서 전체 프로메테우스의 메트릭을 볼 수 있도록 해주고, 수집된 메트릭을 스케일이 가능한 스토리지에 저장해서 특정 프로메테우스 인스턴스가 다운이 되더라도 그 인스턴스가 담당하는 메트릭을 조회할 수 있도록 해준다. 


개념 이해를 돕기 위해서 아키텍쳐를 살펴보자

Thanos Side car & Querier

먼저 데이타 수집과 쿼리 방식을 보면, 프로메테우스 서버에 타노스 에이전트가 인스톨 되서 데이타를 조회할 수 있게 해준다. 프로메테우스는 데이타를 로컬 디스크에 저장하기 때문에 타노스 에이전트 (Thanos Sidecar : 마이크로 서비스 아키텍쳐 패턴중 사이드카 패턴을 사용하기 때문에, 타노스 사이드카라고 부른다.)는 디스크에 저장된 내용을 읽어서 필요시에 쿼리 엔진 (Thanos Querier)에 전달한다. 

여러개의 프로메테우스 인스턴스가 있더라도, 각 프로메테우스 마다 사이드카 에이전트가 설치되서 쿼리 엔진에 전달하기 때문에 사용자 입장에서는 하나의 타노스 쿼리 엔진(UI)만 가지고도 전체 프로메테우스를 통해서 모든 모니터링 대상의 메트릭을 조회할 수 있도록 되는 것이다. 


HA 지원

기본적인 HA 지원 방식은 기존 방식과 다르지 않다. 아래 그림과 같이 프로메테우스 인스턴스를 동시에 두개를 띄워서 같은 모니터링 대상을 모니터링 해서 각각의 지표를 저장하는 방식이다.


그러면 타노스로 인해 오는 장점은 무엇인가? 기존 방식의 경우에는 프로메테우스 인스턴스 각각의 메트릭으로 모니터링 해야 하지만 타노스는 특정 그룹의 프로메테우스 인스턴스들의 지표들의 하나의 인스턴스로 처리해서 메트릭을 보여준다. 즉 두개의 인스턴스에서 수집된 메트릭을 합쳐서(merge) 해서 볼 수 있도록 해주고, 당연히 같은 모니터링 대상을 모니터링 하기 때문에 중복되는 메트릭 값이 있을 수 있는데, 이 중복 값을 제거 해주는 De-duplication 기능을 가지고 있다. 

오랜된 값 저장

앞에서 언급은 하지 않았지만 프로메테우스의 다른 문제점 중의 하나는 로컬 디스크를 사용하기 때문에 일정 기간이 지난 오래된 데이터는 삭제가 된다. 그래서 오래된 데이터에 대한 조회가 불가능하다. 

타노스 입장에서는 오래된 데이터 저장 문제 뿐만 아니라 여러 프로메테우스를 동시에 모니터링 하게 되면 마찬가지로 메모리와 로컬 디스크의 용량 문제로 인해서 여러 프로메테우스를 모니터링 할 수 없는 문제가 발생하는데, 이를 해결하기 위해서 타노스는 외부 스토리지를 사용한다. 


프로메테우스에서 수집된 데이타는 2시간 정도 메모리에 저장이 되었다가 로컬 디스크로 덤프가 된다. 저장된 파일을 타노스 에이전트가 수집해서 외부 스토리지에 저장한다. 외부 스토리지는 Ceph와 같은 분산형 파일 시스템이나 Google Cloud Storage, AWS S3와 같은 클라우드 오브젝트 스토리지를 사용한다. 


그리고 쿼리 엔진에서 근래의 데이타를 조회할때는 프로메테우스 인스턴스에 설치된 타노스 사이드카 에이전트를 통하지만 오래된 데이터는 스토리지에 저장된 데이터는 Thano Storage Gateway라는 컴포넌트를 통해서 조회된다. 이 컴포넌트는 스토리지에 저장된 데이타를 Storage API를 통해서 쿼리엔진과 통신 하는 역할을 한다. Gateway는 단순 쿼리를 API로 저장하는 역할뿐만 아니라 중간에 캐쉬를 제공하여, 빠른 응답 시간을 제공한다. 


이 구조를 이용함으로써 메트릭 데이터의 보관 주기를 늘릴 수 있게 된다. 


스토리지에 저장된 메트릭을 장기 보관하게 되면, 디스크 용량에 대한 문제도 있지만 아주 오래된 데이타(1~2년전)의 데이터를 조회하고자 하면, 많은 데이터를 스캔해야하기 때문에 성능에 있어서 많은 문제가 생길 수 있다. 그래서 스토리지에 저장된 데이타를 관리하는 컴포넌트로 Compactor 라는 컴포넌트가 있다. 기본적으로 데이타 파일을 압축할 뿐만 아니라, 다운 샘플링을 하는데, 다운 샘플링이란, 매트릭이 1분 단위로 샘플링 되었다면, 10분이나 1시간 단위로 샘플링 기준을 다운해서 (해상도를 낮춰서) 전체 데이타 저장 용량을 낮추는 방법이다. 


이외에도 Alert과 룰 관리, UI를 관리하는 Thanos Ruler 라는 컴포넌트가 있으나 여기서는 자세히 설명하지 않는다. 상세한 설명은 타노스 공식 문서를 참고하기 바란다. https://thanos.io


사실 프로메테우스의 한계를 해결하기 위해서 오픈소스 쪽에서 타노스가 좋은 솔루션이기는 하지만, 개인적으로 운영환경에 올린다면 이렇게 복잡한 설정 대신 프로메테우스를 앞에 놓고 (구글 클라우드 엔지니어니까는) 뒤에 타노스 대신 구글 스택 드라이버를 놓는 것이 여러모로 편하겠다는 생각은 좀 든다. https://cloud.google.com/monitoring/kubernetes-engine/prometheus


타노스 온라인 튜토리얼 https://katacoda.com/bwplotka/courses/thanos


참고 자료 : https://www.youtube.com/watch?v=Fb_lYX01IX4



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

다음글은 페이스북 서버사이드 아키텍트 그룹 세미나에서 강대명씨가 발표한 내용을 정리한 글입니다.



Redis는 Single Thread Model이다. (중요)

이로 인해서 긴 Transaction이 들어 오면, 그 Tx를 처리하기 위해서 다른 request를 처리 못하는 현상이 발생한다.

대표적으로

  • Flushall이나 Keys는 List 전체를 Scan하는 구조로, 100만개 처리시 1초, 1000만개 10초,1억개 100초가 소요된다.
  • 이를 예방하기 위해서, 데이타를 전체 하나의 Collection에 넣는 것이 아니라 여러개의 Collection에 나눠서 처리하는 방안이 좋다. 각 Collection당 보통 10,000개 정도의 데이타를 저장하는 것이 좋다
다른 문제로, Redis의 경우 메모리의 내용을 파일로 저장할 수 있다. 두 가지 방식이 있는데,
  • RDB (메모리 덤프 방식) -:순간적으로 메모리의 내용을 덤프 떠서 디스크에 저장한다. 이때 Fork (& copy on write)방식으로, Fork 된 프로세스에서 full scan을 해서 디스크에 저장한다. 이때 문제점은 fork가 되기 때문에, 순간적으로 메모리 사용량이 증가한다. 예를 들어 4G짜리 redis 프로세스가 돌고 있으면 fork되는 순간 worst case 똑같이 4G 메모리를 차지하는 Child Process가 생성된다. 그래서, 시스템 메모리가 넉넉하지 않은 경우, Swap이 발생하고 전체적인 box의 성능을 떨어뜨려서, parent process에도 성능 영향을 줄 수 있다. 이를 해결하기 위해서는 하나의 box에 큰 redis instance 하나를 띄우는게 아니라 여러개로 잘게 나눠서 띄우는게 좋다. 예를 들어 시스템 메모리가 8G일때, 6G짜리 하나를 띄우는 것보다 1G짜리 6개, 또는 1.5G 짜리 4개를 띄우면, RDB로 덤프할때도 추가로 사용되는 메모리는 worst case 1.5이기 때문에 시스템 메모리 내에서 커버가 
  • AOF(Append on File - 일종의 DB Commit Log와 같은 개념) - AOF는 write tx를 매번 파일에 저장하는 방식이다. 그래서, 매번 write 시마다 disk io가 발생한다. 대신, 매 tx를 logging하기 때문에, 최신 데이타를 항상 디스크에 백업할 수 있다. AOF 파일이 무제한으로 커지는 것을 막기 위해서 AOF 파일이 일정 크기 이상이 되면, 현재 메모리를 RDB처럼 DUMP하고, AOF 파일을 지우고 새로 쓰기를 시작한다. (마찬가지로 이 과정에서 fork 방식을 사용한다.)
이런 성능 저하나 문제를 막기 위해서는 master node에서 rdb나 aof를 사용하지 않고, slave 노드를 만들어서 slave 노드에서 qordjqdmf wlsgodgksms rjtdl whgek.

Master/Slave 구조시 Master 노드 장애
  • Master 노드가 장애가 나면 클라이언트는 Slave로 붙어서 write를 하는데, redis는 특성상, master 노드가 다시 살아나면, master 노드의 데이타를 최신 데이타로 생각하고, slave 의 데이타를 지우고, master 노드의 데이타를 복제한다. 이 구조 때문에, master노드가 장애시 slave 노드에 쓰여진 데이타는 유실 될 수 있다.
  • 이런 현상을 막기 위해서 "Slave of no one" 이라는 옵션을 지정하면,, Slave가 master로 격상되고, 원래 master가 올라오더라도 데이타를 복제 받지 않는다.
Master/Slave 구조에서 또 주의해야할점 중 하나는, Slave를 새로 만들면, Slave는 Master로 부터 데이타를 복제해와야 하는데, 이 과정이 RDB dump를 떠서 이뤄진다. (성능에 영향을 줄 수 있다.)

이렇게 HA 쪽에 문제가 있어서 여러가지 Configuration 방법이 있다. Pub/Sub을 사용하지 않는다면, TwemProxy 를 사용하는 것이 좋다.

※ 결론적으로 이야기 하자면, memcached에 비해서 많은 기능을 제공하지만, 대단히 sensitive한 솔루션으로 보이고, 특히 복제나 HA Replication에서 장애 유발할 수 있는 가능성이 있으니, 대용량 데이타 저장시에는 반드시, 맞는 구조로 데이타 모델 및 파티셔닝 그리고 ㅗ드 분산을 해야 한다. (이게 아마 대명씨가 이야기 하는 cell architecture 인듯)


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

AWS의 Zone은 같은 지역에 있는 물리적으로 다른 데이타 센터의 개념을 이야기 함.

RDS의 Multi Zone replication은 한 데이타 센터가 고장 나더라도 다른 데이타 센터에서 서비스가 가능한 구조.

기본적으로  Active-Stand by 형태로 복제하다가, 장애가 나면 stand by 서버로 fail over하는 구성


중요한 것중 하나는 MySQL RDS의 경우 자동 Back 시, 시스템이 일시적으로 멈추는 현상이 보이는데, Multi AZ deploy의 경우, back up시에, 자동 fail over하여, 멈추는 현상 없이 서비스가 가능함


http://aws.amazon.com/ko/about-aws/whats-new/2010/05/18/announcing-multi-az-deployments-for-amazon-rds/

Announcing Multi-AZ Deployments for Amazon RDS

We are excited to announce Multi-Availability Zone (Multi-AZ) deployments for Amazon Relational Database Service (Amazon RDS). This new deployment option provides enhanced availability and data durability by automatically replicating database updates between multiple Availability Zones. Availability Zones are physically separate locations with independent infrastructure engineered to be insulated from failure in other Availability Zones. When you create or modify your DB Instance to run as a Multi-AZ deployment, Amazon RDS will automatically provision and maintain a synchronous “standby” replica in a different Availability Zone. In the event of planned database maintenance or unplanned service disruption, Amazon RDS will automatically failover to the up-to-date standby so that database operations can resume quickly without administrative intervention.

The increased availability and fault tolerance offered by Multi-AZ deployments are well suited to critical production environments. To learn more, visit the Amazon RDS product page.


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요