Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

Contents

미완성

모니터링은 중요하다

모니터링 정보는 서비스 가용성과 효율적인 자원 투입을 위한 기본 자료가 된다. 당연히 중요하다.

모니터링을 위한 VPC 환경 구성

Global VPC 환경이다. 글로벌한 서비스이며, 지역마다 최적의 서비스를 제공하기 위해서 AWS Region 별로 Service VPC가 구성된다.

멀티 VPC로 구성될 경우 모니터링 정보와 같은 관리 트래픽을 수집하는데 어려움이 있을 수 있다. VPC로 구성하면, 모든 EC2 인스턴스가 인터넷으로 부터 격리되기 때문이다. 데이터베이스는 물론이고 웹 서버도 사설 IP만을 기지고 ELB를 통해서 서비스하도록 구성된다. 웹 서버같은 서비스 종단 인스턴스는 [wik:Site/cloud/AWS/EIP EIP]를 가지게 할 수 있지만, 그렇게 구성하더라도 주요 서버는 인터넷으로 부터 격리가 될건데, 이 경우 모니터링 정보 수집이 어려워 진다.

NAT 구성

정보수집을위한 모든 instance에 EIP를 두는 건 제껴두고, NAT instance를 구성하는 방법이 있다. 인터넷에 있는 모니터링 서버가 고정된 IP를 가지고 있다면, 모니터링 트래픽을 NAT 인스턴스로 향하게 VPC 라우팅 테이블을 설정하면 된다.

이 방식의 특징은 다음과 같다.
  1. VPC안에 있는 instance에서 모니터링 정보를 모니터링 서버로 push 해야 한다. 일반적으로 모니터링 서버에서 데이터를 (pull 방식으로)수집하는 방식이 좀더 명확하다.(어플리케이션 개발/설계가 수월하다.)
  2. RDS같은 내부 자원을 모니터링 하려면, VPC안에 RDS의 모니터링 정보를 수집하는 별도의 소프트웨어를 둬야 한다.
  3. 메트릭 수집에 제한이 있다. (ICMP, SNMP, Service port 등...)

VPN 구성

별도의 관리 네트워크를 구성하는 방법이 있다. Multi region VPC의 자원을 관리하기 위한 MGMT VPC를 구성한다. 회사에 직접 구축할 수도 있다.

이 방식의 특징은 다음과 같다.
  1. VPN을 이용해서 네트워크를 통합할 수 있다.
  2. 관리(모니터링 포함) 트래픽을 위한 독립적인 네트워크를 구성할 수 있다.
  3. VPN Gateway에 대한 관리가 필요하다. NAT gateway도 관리를 해줘야 하겠지만, NAT 보다 손이 더 많이 간다.
  4. 메트릭 선택에 제한이 없다. Monitering server에서 pull 하건, VPC instance에서 push 하건 어느 방법이든 사용할 수 있다.
나는 VPN 구성을 하기로 했다.

모니터링 단계

모니터링은 인프라와 서비스 두 단계에서 서로 독립적으로 이루어진다.

인프라 모니터링

인프라 모니터링은 instance 자체에 대한 모니터링이다. instance의 port, health check, cpu, memory, process 등이다. 이 정보는 즉각적인 대응관점이 아닌 중/장기적인 관점에서 자원의 사용추이를 확인하기 위해서 사용한다.

서비스는 ELB를 통해서 혹은 다른 방식을 통해서 고가용성을 확보 할 것이다. 예컨데, 인스턴스 하나가 죽더라도 가용 자원이 줄어들 뿐 서비스는 문제없이 진행 될 것이다. 인프라에 대한 모니터링 정보는 자원이 효율적으로 사용되는지, 가용성을 확보할 수 있는지, 언제 scale-out 해야 하는지, 아키텍처나 아키텍처를 구성하는 컴포넌트들의 개선사항이 없는지 등에 대한 정보를 수집하기 위함이 목적이다.

서비스 모니터링

클라이언트 입장에서 서비스 자체를 모니터링 한다. 인프라 모니터링과 반드시 분리되야 한다. 인프라에는 문제가 없지만 서비스는 안될 수 있기 때문이다.

웹 서비스의 경우 HTTP 클라이언트를 이용해서 (마치 유저가 웹 브라우저를 통해서 접근하는 것처럼) ELB를 통해서 모니터링을 하게 된다. 여기에서 얻는 정보는 다음과 같다.
  1. 인터넷을 통한 서비스 가용성 확인
  2. 유저 시나리오에 따른 서비스 확인. 예) 웹 문서를 이루는 정보들을 모두 접근할 수 있는지, login / logout 과정이 제대로 진행되는지 등..
  3. 유저입장에서의 네트워크 지연, 페이지 전송 속도등의 정보
관리자가 즉각적으로 반응해야 하는 정보다. 200 OK 대신 404 Not found가 떨어진다거나, login 실패 등은 유저 서비스와 직접 관련된 것이기 때문이다.

CloudWatch & Zabbix

CloudWatch가 지원하는 EC2 매트릭은 다음과 같다.
  • CPU 사용율
  • Disk read/write bytes
  • Network In/Out
  • Instance 상태
따로 모니터링 애플리케이션을 설치할 필요가 없다는 장점이 있긴하지만, 인스턴스 내부의 상태 즉 운영체제 레벨에서의 정보는 수집할 수 없다는 한계가 있다. 그리고 모니터링 통계 정보도 그다지 쓸만해 보이지 않는다. 데이터도 2주치만 보관한다. 설정주기를 5분 이내로 하려며 추가적인 비용도 내야 한다. 현재 인스턴스의 상태를 빠르게 확인하고, Auto scaling을 위한 기초정보로 사용하기에는 충분하지만 중/장기적인 모니터링 정보를 수집하기에는 부족하다. 중/장기적으로 안정적인 모니터링 정보가 필요하다면, 따로 모니터링 환경을 구축하는걸 권한다.

모니터링 솔류션

Zabbix

Zabbix를 선택했다. 처음 써보는 툴이니 딱히 이거다 싶어서 쓰는 툴은 아닌 셈이다. 그렇다고 딱히 사용하기 싫었느냐 하면 그것도 아니다. 이전에 zenoss를 쓴 경험이 있지만 5년 전의 일이니, 기억나는 것도 별로 없어서 zenoss를 선택한다고 해도 어차피 처음부터 하는 것이나 마찬가지다.

Zabbix에 대한 내용은 zabbix wiki page에서 자세히 다루기로 하고 중요한 것들만 다루겠다.

히스토리

  • 작성일 :