4. 운용지원 서비스

AWS 운용을 지원하는 서비스

시스템은 개발이 끝이 아니다. 오히려 런칭한 이후부터기 시작이다.

시스템 운용을 안정적으로 행하기 위해선 이용자의 목소리를 듣는 것 뿐만 아니라, 제대로된 운용 페이즈에 들어가는 것도 중요하다. 이 운용 페이즈를 지원하는 서비스가 AWS에도 존재한다. 이번에는 아래 2가지의 서비스에 대해 알아보자.

• Amazon CloudWatch
• AWS CloudTrail

CloudWatch

정기적인 AWS 리소스의 상태를 취득하여 문제가 있을 경우 그것을 운용자에게 통지하는 서비스이다. 무엇이 문제가 된다 로 설정할 지는 이용자측에서 정의하는 것도 가능하다. 또한 미들웨어나 애플리케이션 로그를 감시하는 기능이다. 독자적인 트리거를 정의하여 해당 트리거가 발생할 경우 연이은 처리를 행하는 기능도 제공한다.

CloudTrail

AWS 리소스의 작성이나, 매니지먼트 콘솔의 로그인 등 조작을 기록하는 서비스이다. 일부 조작에 대해서는 기본적으로 기록을 하지만, 설정을 변경하는 것으로 모든 조작을 기록하는 것도 가능하며, 또한 S3에 로그를 남기는 기능도 제공하고 있기 때문에 해당 로그를 그대로 감시 로그로 이용하는 것도 가능하다.

 

운용을 위한 기능들은 굉장히 중요한 기능들이다. 하지만 비즈니스 차별화 보다 중요한 것은 아니기 때문에 가능한 시간을 들이고 싶지 않다는 읜견도 빈번히 발생할 수 있다. AWS에서 제공하고 있는 이러한 매니지드 형 서비스를 사용하는 것으로 이 딜레마를 해소하는 것도 가능할 것이다. 솔루션 아키텍처로 시스템을 움직이는 것 뿐만 아니라 안정적으로 동작하는 설계를 하기 위해선 아래 서비스들을 제대로 익혀 둘 필요가 있다.

CloudWatch

운용 감시를 지원하는 매니짖드 서비스이다. 시스템은 구축하고 론칭하는 것으로 끝나는 것이 아니며, 론칭 후 안정적인 운용을 하는 것으로 이용자의 만족도를 높여 나갈 수 있기에 굉장히 중요한 일이기도 하다. 운용이 제대로 이뤄지지 않을 경우 새로운 기능 개발에 무게를 두기는 어려울 것이다. 이 안정적인 운용을 서포트 하는 것이 CloudWatch라고 할 수 있다.

CloudWatch에는 굉장히 중요한 3가지 기능과 비교적 최근에 초가된 4가지 기능이 있다. 

중요기능

• CloudWatch
• CloudWatch Logs
• CloudWatch Events

최근 추가 기능

• CloudWatch Synthetics
• CloudWatch ServiceLens
• Container Insight
• Contributor Insight

CloudWatch

각 AWS 리소스의 상태를 정기적으로 취득하며, 이 상태를 메트릭스이라고 부른다. 예를 들어 EC2 인스턴스의 CPU 사용률이라던지 Lambda함수의 에러 횟수 등이 정의 되어 있다. 이렇듯 AWS가 새롭게 정의한 메트릭을 표준 메트릭스 이라고 하며, 표준 메트릭의 리스트에 대해선 AWS 공식 도큐먼트를 알아보자.

반면 사용자가 정의한 값을 CloudWatch에 전달하여 독자적인 메트릭을 만드는 것도 가능하다. 이런 메트릭 들을 커스텀 메트릭스 이라고 한다.

CloudWatch에는 이런 메트릭들을 선택하여 알림을 설정할 수 있다. 예를 들면 아래와 같은 조건 알람을 설정할 수 있다.

• 웹 서버용 EC2 인스턴스의 CPU 사용량이 80%를 상회하는 경우
• 정기적으로 실행하는 Lambda함수가 일정기간 3회 이상 에러가 날 경우

이런 알람의 조건을 만족할 때에는 다른 서비스인 SNS에 통지하도록 설정하는 것도 가능하다. SNS는 통지를 받아 들여 메일을 보내거나 Lambda함수를 호출하거나, 할 수 있다. 이것들의 기능을 조합하여 CPU의 이용률이 높아지는 것이 확인되면 운용 담당자에게 메일을 보내거나, 호출된 Lambda 함수로 부터 AWS의 리소스의 설정을 변경할 수 있다.

 

CloudWatch에 의한 감시 흐름은 시스템의 좋지 않은 상황을 빠르게 캐치업 하는 것, 이것이 Cloudwatch의 본래 유즈케이스 이기도 하다.

CloudWatch의 이용 흐름

CloudWatch Logs

애플리케이션 로그나 Apache의 로그등 로그를 모니터링 하는 서비스이다. CloudWatch Logs를 이용하기 위해선 독자의 에이전트를 설치할 필요가 있다. 이 에이전트를 이용하여 각 EC2 인스턴스 로그를 CloudWatch Logs에 수집한다. 이 때 송신처의 인스턴스에 CloudWatch 의 IAM 권한을 부여할 필요가 없기 때문에 IAM 권한 설정을 해야 한다.

CloudWatch Logs에는 수집한 로그에 대하여 알람을 설정할 수 있다. 예를 들어 애플리케이션 로그에 ERROR로 시작하는 행이 있을 경우 WARN으로 시작하는 행이 일정 기간 3행 이상 연달아 발생하거나 할 경우 알람이 발생하도록 설정할 수 있다. CloudWatch 와 같이 이 알람을 트리거로 설정하여 무언가 처리를 행할 수 있다. CloudWatch Logs를 사용하는 것으로 애플리케이션 레이어의 감시도 가능하며, 시스템을 보다 안정적으로 운용할 수 있다.

CloudWatch Logs의 흐름

CloudWatch Events

독자적인 트리거와 무언가 후속 액션으로 조합을 정의하는 서비스이다. 독자적인 트리거를 이벤트 소스라고 부르며, 후속 액션을 타깃 이라고 부른다. CloudWatch Events를 이용하는 것으로 AWS의 각 서비스를 보다 심리스 적으로 운용할 수 있다.

 

이벤트 소스에는 크게 2종류로 나눠져 있으며, 하나는 스케줄 이며 또 하나는 AWS 리소스의 이벤트이다. 스케줄은 이름대로 3시간마다 금요일 아침 과 같은 기간, 시간을 베이스로 트기러를 정의할 수 있다. 후자인 AWS 리소스 이벤트는 Auto Scaling이 인스턴스를 증감 시킬 경우 Code Build의 상태가 변할 경우 와 같은 AWS리소스의 상태 변화를 트리거로 이용한다.

 

타깃에는 기존의 AWS 리소스에 대한 액션을 정의한다. Lambda 함수를 킥한다. code pipeline을 실행한다 등과 같은 액션을 설정할 수 있다. 하나의 이벤트 소스에 대하여 복수의 타깃을 설정할 수 있다. 또한 시간이 흐른 뒤에 타깃을 추가하는 것도 가능하며, 보다 탄탄한 형태의 서비스간의 연계를 실현할 수 있다.

CloudWatch Events의 이용 흐름

또한 CloudWatch Events와 같은 API를 사용하며, 기능은 더욱더 추가된 EventBridge가 등장하였다. 장래에는 CloudWatch Events는 EventBridge에 통합될 예정이다.

 

이렇듯 CloudWatch 에는 다양한 기능이 있다. 시스템이 위험한 상태가 되었을 경우 통지해주는 것 뿐만 아니라. 그것에 대한 액션까지 정의할 수 있다는 것이 CloudWatch 시리즈의 메리트이다. 서비스를 론칭한 뒤 아무 트러블도 발생하지 않는 서비스는 없다. CloudWatch 를 이용하여 트러블이 발생했을 때 자동적으로 복구한다. 또는 장애를 최소한으로 억제할 수 있는 유연한 서비스 설계가 가능해지도록 설계해 나가는 것이 중요하다.

CloudTrail

AWS에 관한 조작 로그를 자동적으로 취득하는 서비스이다. AWS 에는 매니지먼트 콘솔을 조작하거나 CLI나 SDK를 이용하여 API를 이용하여 AWS 리소스를 조작하거나 리소스로 부터 데이터를 취득하는 것이 가능하다. 서비스를 운용하는 흐름에 의도적인 행동인지, 그렇지 않은 행동인지는 모르겠지만, 리소스를 잘못해서 삭제하거나, 데이터를 부정 사용 한다거나 하는 상황은 언제든지 발생할 수 있다. 그것이 중요한 장애나 세큐리티 인시던트 문제로 이어질 수 있으며, 「누가」 「언제」 「어떤 조작」 을 하였는가 와 같은 감시 로그를 기록해두는 것은 매우 중요하다.

CloudTrail을 사용하는 것으로 이러한 감시 정보를 간단히 취득할 수 있다.

CloudTrail로 취득할 수 있는 로그의 종류

취득 가능한 조작(이벤트)에는 관리 이벤트와 데이터 이벤트가 있다.

• 관리 이벤트 : 매니지드 콘솔의 로그인, EC2 인스턴스의 작성, S3 버킷을 작성하는 것 등
• 데이터 이벤트 : S3 버킷 상의 데이터 조작, Lambda 함수를 실행하는 것

CloudTrail에는 관리 이벤트의 취득만 기본적으로 유효화 되어 있으며, 과거 90일간의 로그를 매니지드 콘솔상에서 확인할 수 있다.  90일 보다 더 과거의 정보도 보관하고 싶을 경우에는 S3에 저장하도록 설정할 수 있다.

데이터 이벤트의 취득은 기본적으로 우효화 되어 있지 않지만, 설정을 변경하는 것으로 관리 이벤트도 같이 S3에 로그를 저장할 수 있다.

CloudWatch Logs와의 연계

CloudTrail의 감시 로그를 취득하는 것으로 무언가 문제가 발생할 경우 각 유저의 조작을 추적하는 것이 가능하다. 이것 만으로도 충분할 수 있으나, 가능하다면 유저가 부정한 조작을 했을 경우, 자동적으로 검지하고 싶을 경우도 있다. 이런 경우에 이용가능한 것은 CloudWatch Logs와의 기능 연계이다.

 

CloudWatch Logs에 대해서는 앞서 설명했지만, 간단히 말하자면 사전에 키워드를 설정해두고 로그에 해당 문자열이 나타날 경우 빠르게 검지할 수 있는 기능이다.

 

이 기능을 휴효화 하는 것으로 사전에 부정한 조작 ( 로그 메시지/ 문자열 )을 등록해두고 유저가 해당 조작을 행할 경우 알람이 발생하도록 할 수 있다. 인시더트에 부합하는 조작을 빠르게 발견하는 것도 가능하기 때문에 유용한 기능이라 할 수 있다.