👆 개요
모니터링은 굉장히 중요합니다. 아무리 배포가 잘되고 자동화가 잘 되어도 이후에 발생하는 에러나 문제점을 인식하는데에 많은 도움을 주기 떄문입니다.
즉 사용자가 불만을 제기하여 개발진들에게 문제를 제기 하는 것 보다는 개발진들이 미리 문제를 인식하여 해결을 하는 것이 사용자 측면에서 더 유리하기 떄문입니다.
모니터링에는 대표적으로 3가지가 있습니다.
1. CloudWatch
지표를 수집하는데에 주로 사용되는 서비스 입니다.
이벤트 및 로그에 실시간으로 반응해서 알람을 보내는 역할을 합니다.
2. X-Ray
비교적 새로운 서비스라 인기는 없지만 많은 기능을 제공합니다.
애플리케이션의 성능과 오류에 대해서 트러블 슈팅을 수행하는 데 지연 시간을 살펴보고 오류 분식이 가능합니다.
3. CloudTrail
API호출에 대한 모니터링을 수행합니다.
이로 인해 AWS리소스 변경을 감지 가능하며 감사를 수행 할 수 있습니다.👆 CloudWatch
지표를 확인할떄 사용이 됩니다.
보통 지표의 일믕르 보며 인식을 하며 어떻게 동작하는지 그 원리를 파악합니다.
트러블 슈팅 또한 이러한 정보를 기반으로 가능합니다.
기본적으로 EC2는 5분마다 지표를 가지게 되며 더 빠르게 하고자 한다면 추가적인 비용을 지출해야 합니다.
사용자 지정 지표라는 방식으로 커스텀마이징 가능합니다.
- 커스텀 마이징은 API콜을 통해서 추가 가능합니다.
사용자 지정 지표는 특이하게도 푸시하는 시간이 과거든 미래든 상관이 없습니다.
2주전 또는 2시간 앞으로 푸시를 하든 오류가 발생을 하지 않고 지표 데이터를 그대로 수용합니다.
🐾 로그
아마 AWS에서 로그 저장을 하는데에 최적화된 장소는 CloudWatch Logs라고 할 수 있을 겁니다.
로그를 그룹으로 나누어서 이름을 지정하게 되는데 보통 애플리케이션 이름으로 나누게 됩니다.
각 그룹내에는 로그 스트림이 있고 이들은 애플리케이션 내의 인스턴스 또는 다른 로그 파일 이름 등을 의미합니다.
AWS 리소스 마다 다른 방식으로 로그를 CloudWatch에게 전송을 하는 데 다음과 같습니다.
1. ECS : 컨테이너에서 바로 CloudWatch로 로그를 전송합니다.
2. Lambda : 함수 자체에서 로그를 전송합니다.
3. VPC Flow Logs : VPC 메타데이터 네트워크 트래픽과 관련된 로그를 전달합니다.
4. API Gateway : 들어온 모든 요청을 전달합니다.또한 CloudWatch에서는 필터 기능을 제공하기 떄문에 원하는 로그를 빠르게 확인 가능합니다.
🐾 CloudWatch Agent
말 그대로 지표를 따와서 CloudWatch에 전송을 하는 서비스를 말합니다.
기본적으로 EC2인스턴스에서 자체적으로 로그를 CloudWatch에 전송을 하는 것은 불가능 합니다.
그러기 떄문에 해당 기능을 구현하기 위해서는 기본적으로 EC2인스턴스에서 작은 프로그램인 CloudWatch Agent를 구현해야 합니다.
이떄 EC2 인스턴스에 IAM역할이 있어야 합니다.
해당 서비스에는 두가지 버전이 있습니다.
CloudWatch Logs Agent,CloudWatch Unified Agent
Log Agent는 단순히 로그만을 전송을 하지만, Unified Agent는 추가적으로 시스템 수준의 지표를 제공합니다.
- 대표적으로 RAM, 프로세스 등이 있습니다.
🐾 CloudWatch Logs 지표 필터
앞서 말했던 것처럼 필터 기능을 활용 가능합니다.
그러기 떄문에 경보를 트리거 할떄 사용하거나 알람을 사용하는데에 유용합니다.
- 예를들면 필터를 활용하여 Error라는 키워드가 10회 이상 넘어가면 트리거를 작동 시키는 방향으로 사용 가능합니다.
이와 같은 필터는 한번 생성이 되면 이전에 참고했던 데이터는 더이상 고려하지 않습니다.
- 예를들면 10개이상 에러가 발생하여 트리거가 작동을 하면 다시 0으로 초기화 하고 이후의 에러를 카운트 하는 방식입니다.
문제는 패턴 즉 조건을 추가하는 것은 굉장히 방대하기 떄문에 이러한 구문에 대해서 공식 문서가 존재 하기도 합니다.
🐾 CloudWatch 경보
경보는 모든 지표에서 알림을 트리거 하는데 사용하고 복잡한 경보도 정의가 가능합니다.
상태는 총 3가지로 구성이 되어 있습니다.
Ok : 트리거 되지 않습니다.
INSUFFICIENT_DATA : 경보 상태 결정에 데이터가 불충분합니다.
ALARM : 임곗값을 위반하였습니다 -> 트리거 발생경보에 타깃으로 삼는 서비스는 대표적으로 세가지 정도가 있습니다.
1. EC2 인스턴스에서의 작업
- 중지, 종료 등등 인스턴스를 복원하는 작업입니다.
2. 오토스케일링 작업을 트리거
- 스케일 아웃이나 스케일 인을 말합니다.
3. SNS 서비스
- SNS에 알람을 전송하는 겁니다.
- 예를들면 SNS 서비스에서 Lamda함수를 연결하여 위반하는 경보를 기반으로 작업을 수행합니다.👆 EventBridge
CloudWatch Events의 차세대 버전입니다.
기본적으로 CloudWatch Event와 동일하게 사용 되지만 추가적으로 소프트 웨어 공급자같은 데이터 또한 받을 수 있습니다.
또한 커스텀마이징이 가능하며 Bridge를 통해 이벤트를 전송 가능합니다.
CloudWatch와 동일하게 규칙을 통해 이벤트를 처리하며 처리된 이벤트를 리디렉션할 서비스 또한 지정 가능합니다.
EventBridge에는 유용한 기능으로 Schema Registry가 있습니다.
해당 기능은 만약 이벤트가 전송이 되면 서비스 자체에서 이벤트를 분석하고 스키마를 추론합니다.
해당 스키마는 레지스트리 라는 곳에서 코드를 생성하고 앱은 코드를 통해 데이터의 구조를 인식합니다.
👆 X-Ray 개요
전체 아키텍처나 서비스 맵을 한번에 볼 떄 사용합니다.
성능을 트러블 슈팅하고, 병목 현상을 식별 가능합니다.
또한 모든 서비스가 어떻게 동작하는지 알 수 있으며, 요청을 기반으로 오류와 예의를 찾게 됩니다.
호환성 또한 높기 떄문에 다양하게 활용 가능합니다.
그냥 거의 모든 데이터를 추적 가능하며 굉장히 유용한 서비스 이지만 이상하게도 잘 사용되지 않는다고 합니다.
X-Ray의 활성화 방법에는 두가지가 있습니다.
- 반드시
AWS X-Ray SDK를 활용해야 합니다.
- 필요하다면 살짝 수정이 가능합니다.
- X-Ray데몬을 설치하거나 X-Ray Aws통합을 활성화 합니다.
- 데몬은 저용량 UDP 패킷 인터셉터의 역할을 하며 이를 설치해야하며, 각 애플리케이션은 X-Ray에 데이터 작성을 위해 IAM권한을 가져야 합니다.
- 중요한 저은 X-Ray애플리케이션이 실행될때는 Ec2에서 실행이 되지 않는다는 것 입니다.
-- 이유는 머신에서 데몬을 실행하며 EC2인스턴스로 배포할 떄 X-Ray데몬을 사용하지 않아서 호출이 포착되지 않기 떄문입니다.
👆 X-Ray 개요
X-Ray로 애플리케이션을 계측하려면 코드를 수정하여 SDK를 이용해야 합니다.
계측이라는 뜻은 제품의 성능을 측정하고 오류를 진한다고, 추적 정보를 쓰는 것을 의미합니다.
예를들면 이와같이 코드를 수정합니다.
express 기준
app.use(AWSXRay.express.closeSegment());이런식의 코드를 추가하면 X-Ray가 계측을 사용 할 것입니다.
하지만 SDK를 사용하는 경우는 매우 미미합니다.
X-Ray가 동작하는 방식을 사용자가 정의할 수도 있습니다.
1. 세그먼트
- 각각의 애플리케이션이 직접 보냅니다.
2. 서브세그먼트
- 세그먼트를 더 세분화 할 떄 사용합니다.
3. 추적
- 모든 세그먼트를 함께 모았을 떄로 종단 간 뷰를 형성합니다.
- 종단 간 추적을 의미합니다.
4. 샘플링
- X-Ray로 보내지는 요청의 양을 줄여 비용을 감소시킬 떄 사용합니다.
5. 주석
- 추적을 인덱싱하고, 필터와 함께 사용하기 위해 키-값 쌍 데이터를 추가합니다.
- 메타데이터 또한 활용가능하지만 인덱스가 아닙니다.
- 그러기 떄문에 필터, 검색을 할 떄에는 주석을 사용해야 합니다.