AWS Monitoring Service

cloud monitoring 이유

: 불필요한 서비스가 있고, 과도한 비용이 청구되는지 확인하기 위해서 모니터링 한다. -> 이윤 대비 비용을 파악

• 운영 상태
  : 시스템 전반
• 애플리케이션 성능
  : 처리 속도(응답시간)
• 리소스 활용
  : 기준 지표(임계값) 초과 여부 파악 -> 일시적인 현상인지 지속적인 현상인지 분석한다.
• 보안 감사
  : 규정 준수 여부 확인
• 비용 검사
  : 비용 효율적/절감 서비스 설계해 비용 최적화 설계 유무를 판단한다.

=> 안정성(신뢰성)을 보장하기 위해 사용된다.

AWS 분야
: 개발, 설계, 분석, 시스템

비용을 위한 monitoring

: 유연하고 탄력적인 클라우드 아키텍처를 만들려면 어떤 서비스에서 비용을 지출하는지 파악해야 한다.

• AWS Cost Explorer -> Machine Learning
  : 비용 보고서 생성
  : 향후 예측 데이터 생성
  : 13개월 데이터를 활용한 패턴 분석
  : 서비스 별 비용 지출 패턴 확인, region 별로도 확인 가능
  : Tag를 이용한 연관서비스 추정치 제공 -> tag로 그룹핑하여 확인

클라우드 비용을 줄이는 기본적인 방법

비용에 대한 가시성 확보

• Trusted Advisor
  : 현재 사용중인 계정의 리소스를 스캔하여 전반적인 현황을 알려주는 도구

  비용 절감, 성능 개선 및 보안 강화에 도움이 되는 지침을 제공한다.

• cost explorer

서버 모니터링

: 안정적인 서비스 운영을 위해 한다.

장애 발생 전에 미리 징후를 찾아 예방하고, 장애가 발생하더라도 바로 원인 분석을 통한 해결이 필요하다.

서버 모니터링 영역

• Infrastructure 모니터링
  : Application이 실행되는 인프라에 장애가 발생하거나 징후를 확인한다.

• Client 요청에 대한 모니터링
  : 클라이언트에서 의도한 대로 올바른 요청을 보내는지 확인한다. 공격 시도가 있는지와 시간당 요청량을 확인한다.

• Application 모니터링
  : 배포한 코드가 잘 동작되는지 확인하고 병목현상으로 인한 성능 저하를 확인한다.

• Data 모니터링
  : 데이터가 설계한 대로 저장되고 있는지, 데이터 저장 및 읽기 속도는 기준치에 적합한지 확인한다.

CloudWatch

: AWS내 자원/서비스들에 대한 모니터링 및 관리 서비스. AWS의 가장 큰 모니터링 도구이다.

IAM 일반 계정에서도 모든 로그를 수집한다.
모든 로그와 지표(metric, 자원사용) 정보들을 수집하여 시각화 한다. => dashboard

수집된 값들을 이용한 자동화된 작업 수행을 위한 관리 서비스를 제공한다.

ASG의 자동 조정은 cloudwatch에 쌓인 지표에 따라 이루어진다.

• CloudWatch의 지표
  : "언제" 어떤 "항목"의 "값"이 무엇이었는지 기록한 값이다.
  -> EC2 인스턴스의 CPU 사용량, 네트워크 전송량, ASG가 관리하는 인스턴수, 사용자 지표(회원수, 비동기 작업 수, ...)

CloudWatch 응답 방식

• 지표(metric) -> 자원소비량 추척(cpu utilization)
  : 시간 결과에 따른 데이터 변화 요소를 추적한다.
  월/년 기준의 이전 시점과 비교한다.

• 로그
  : AWS 서비스가 추적하는 텍스트 로그의 자동 및 수동 수집을 한다.
  로그를 즉시 탐색,분석 및 시각화 할 수 있다.
  -> log insight 제공
  S3에 보관한다.(빠르고 저렴하기 때문)

• 경보
  : 추적 중인 지표가 일정 기간 동안 임계값을 넘는 경우에 발생한다.

• logs insights query
  : 완전 통합된 대화형 종량 요금제 로그 분석 서비스
  로그를 즉시 탐색, 분석 및 시각화 할 수 있다.
  쿼리를 통해 조회, 필터링 한다.

• 이벤트
  : 특정 API 호출을 기반으로 수행되는 기능
  -> 트리거를 통해 이벤트를 연결한다.
  EventBridge, 애플리케이션을 다양한 소스의 데이터와 연결하는데 사용할 수 있는 서버리스 이벤트 버스 서비스

• 규칙(=조건)
  : 규칙을 정한다.
  ex) 언제든 누군가 EC2 인스턴스를 종료해서 상태가 바뀐다면 어떻게 할 건가요?

• 대상
  : 규칙에 의해 지정되는 대상

한 회사가 Amazon EC2 Linux 인스턴스에서 웹 사이트를 운영합니다. 일부 인스턴스가 실패하고 있습니다. 실패한 인스턴스의 스왑 공간이 부족하다는 문제 해결 지점 운영 팀장은 이를 모니터링 할 솔루션이 필요합니다. 솔루션 설계자는 무엇을 권장해야 합니까?

A. swapusage(지표확인)

swap(프로세스가 대기하는 곳)
증설은 돈이 많이 들기 때문에 마지막 최후의 수단으로 사용한다.

개발자는 사용자가 이전에 수동으로 실행한 일일 보고서를 생성하는 스크립트를 가지고 있다. 스크립트는 10분 이내에 일관되게 완료된다. 개발자는 이 프로세스를 비용 효율적인 방식으로 자동화 해야한다. 개발자는 어떤 조합의 서비스를 이용하면 좋을까요?

A. Event Bridge

CloudWatch 동작 흐름

CloudTrail

: 계정의 규정 준수, 운영 감시, 위험(위협) 감사 지원 서비스

IAM 계정에서 발생하는 API 호출을 기반으로 log를 수집한다. 수집된 로그는 S3 bucket에 저장된다.

Amazon Opensearch를 이용한 cloudtrail query가 가능하다. 이 정보를 로그화 해서 감사정보로 활용한다.
-> 장애 원인 파악, 보안 측면에서 외부 침입 흔적 확인용으로 활용한다.

실제 수집된 로그는 json 형태이기 때문에 elastic search와 연동이 가능하다.

• 사례
  MSA app의 경우, cloudtrail을 통해 수집된 메트릭, 로그 등을 중앙화하여 Amazon opensearch를 이용한 cloudtrail query가 가능하다.
  -> Amazon opensearch에는 키바나 대시보드가 있다. 하지만 완전 관리형이어서 커스텀이 어렵다.
  -> EC2에 EFK를 설치해 사용한다.(public az)

Amazon Config

: 지속적인 구성 감사 도구로 구성을 지속적으로 모니터링 및 기록한다.

AWS 리소스 간 구성 및 관계 변경 사항을 검토한다. 내부 지침에 지정된 구성을 기준으로 전반적은 규정 준수를 확인한다.
=> 규정 준수 감사, 보안 분석, 변경 관리 및 운영 문제 해결 작업이 간소화 된다.

Amazon VPC Flow logs

: VPC 내에서의 네트워크 흐름(패킷)에 대한 로그를 수집한다.
VPC 뿐만 아니라 서브넷, EC2, 네트워크 인터페이스 단위에서 확인 가능하다.

Deny, Allow에 대한 트래픽을 수집한다. AWS Network 관련 서비스들에 대한 선택적 활성화가 가능하다.

수집된 로그는 CloudWatch에 push 되어 만료일 설정을 통한 cloudwatch group을 설정한다.
수집된 정보는 S3로 저장된다.

지원
: 지나치게 제한적인 보안 그룹 규칙을 진단
: 인스턴스에 연결되고 있는 트래픽을 모니터링
: 네트워크 인터페이슬 오가는 트래픽 방향 결정

monitoring 실습

• 인바운드 규칙에 아무것도 추기하지 않은 보안 그룹을 생성한다.
  
• 인스턴스를 생성한다.
  
• CloudWatch 로그그룹 탭으로 이동
  
• CloudWatch 로그 그룹을 생성한다.
  
• 로그를 수집할 S3 버킷을 생성한다.
  
• EC2의 네트워크 인터페이스 탭으로 이동
  
• ENI에 플로우로그를 생성한다.
  
• 선택한 리소스 확인
  
• 이름과 집계 간격, 로그를 저장할 곳 설정
  
• 설정
  
• 태그
  
• 플로우 로그가 생성되었다.
  
• 인스턴스에 접속해서 활동을 한다.
  
• 좀 기다린 후, S3 버킷을 활동해보면 .log.gz 파일이 생성된다.

Amazon Route 53 & CloudFront

CloudFront

: AWS에서 제공하는 콘텐츠 전송 네트워크 서비스(CDN)

캐싱을 통해 사용자에게 좀 더 빠른 전송 속도를 제공함을 목적으로 한다. 전 세계 이곳저곳에 Edge ocation(server)를 두고 client에 가장 가까운 Edge Server를 찾아 Latency를 최소화시켜 빠른 데이터 액세스를 제공한다.

• Origin Server
  : 원본 데이터를 가지고 있는 서버
  보통 AWS에서의 Origin Server는 해당 region의 S3, EC2 instance이다.

• Edge Location
  : AWS에서 실질적으로 제공하는 전 세계에 퍼져 있는 서버
  요청 받은 데이터에 대해서 같은 요청에 빠르게 응답해주기 위해 cache 기능을 제공한다.

CloudFront process

1) 클라이언트로부터 Edge Server로의 요청 발생

2) Edge Server는 요청이 발생한 데이터의 캐싱 여부 확인

3.1) 사용자의 근거리에 위치한 Edge Server중 캐싱 데이터가 존재하면 사용자의 요청에 맞는 데이터를 응답.

3.2) 사용자의 요청에 적합한 데이터가 캐싱 되어 있지 않은 경우 Origin Server로 요청이 포워딩

4) 요청 받은 데이터에 대해 Origin Server에서 획득한 후 Edge Server에 캐싱 데이터를 생성하고, 클라이언트로 응답이 발생

CloudFront caching

: 기본적으로 한번 발생한 요청에 대해서는 Edge Server에 캐싱된 상태로 저장된다.

Edge Server의 기본 TTL은 24시간이고, 사용자의 설정에 따라 변경이 가능하다.

각 개별 데이터에 대해서 invalidation API(무효화 명령. 특정 파일을 캐시에서 삭제하는 기능)를 통해 삭제할 수 있다.
Invalidation API는 동시에 최대 3개의 요청을 발생시킬 수 있다. Edge Node에 반영되기 까지 5~10분 정도의 시간이 소요된다.

signed URL

: CloudFront로 배포되는 파일의 사용을 제한한다.
: 특정 날짜, 특정 IP만 가능하도록 제한한다.

반드시 버킷 이름=도메인 이름이어야 라우팅이 가능하다.

도메인 등록 실습

• 도메인 등록
  

• 도메인 이름과 동일하게 버킷 생성
  
• 프로젝트 업로드
  
• 버킷 정책 수정
  

• 정적 웹 사이트 호스팅 설정
  
• 인덱스 문서 설정
  
• cloudfront 배포 생성
  
• 배포 생성
  
• 배포 도메인 이름으로 접속하면 된다.