CloudWatch, Lambda, CloudFront, API Gateway

이상훈·2023년 5월 20일
0

aws

목록 보기
5/7

CloudWatch

  • AWS 리소스 사용의 실시간 모니터링 기능 지원
  • 다양한 이벤트들을 수집하여 로그파일로 저장
    • ex) S3 버킷 파일 업로드 & 삭제
    • ex) S3 버킷 접근 시 접근거부 발생
    • ex) RDS 데이터베이스에 접속 시도
  • 이벤트&알람 설정을 통해 SNS, AWS Lambda로 전송 가능
  • [CloudWatch 사용 가능 서비스들] : EC2, RDS, S3, ELB, 등등!

모니터링 종류

  • Basic Monitoring
    • 무료
    • 5분 간격으로 최소의 Metrics 제공
    • CPU 사용량, 디스크 사용량, 네트워크 I/O
  • Detailed Monitoring
    • 유료
    • 1분 간격으로 자세한 Metrics 제공

사용 용례

  • Use Case : 특정 시간대에 웹서버 상태를 점검하여 비용 절감 목표
  • Potential Issue : 똑같은 비용을 내며 AWS 리소스들을 사용하지만, 낮 시간대와 밤 시간대에 필요한 서버의 성능은 달라질 수 있기 때문에 금전적 손실이 생길 수 있음 (주로 밤 시간대가 낮 시간대보다 서버가 오랫동안 idle)
  • Solution : 알람 설정을 통하여 특정 threshold에 도달했을 때 개발자에게 상황을 보고해줌으로써 서버 management를 할 수 있음

Alarm

  • 임의로 정해놓은 값에 도달할 시 Alarm을 울림
  • Alarm이 울릴 시 특정 이벤트들을 작동시킬 수 있음

State

  • Alarm : 어떤 매트릭스가 임의로 정해놓은 threshold 값을 벗어났을 때 생기는 현상
  • Insufficient : 불충분하다는 뜻
    • ex) EC2의 메모리 관련 알람을 만들었는데 EC2 인스턴스를 잊고 생성하지 않았고 그 상태로 오랜 시간 지속되게 되면 Insufficient로 분류함
  • OK : 알람이 울리지 않고 원하는 범위 내에서 리소스들이 정상 동작하고 있다는 뜻

Billing Alarm

  • 정해놓은 지출 임계 값을 초과할 경우 SNS를 통하여 경고함
  • 현재 N.Virginia(us-east-1) 지역에서만 이 기능이 지원됨

Lambda

  • Serverless의 주축을 담당
    • serverless : 클라우드가 직접 서버를 돌리고 생성하며 리소스들을 서버의 사용량에 따라 직접 할당, 사람의 간섭 없음
  • Events를 통하여 Lambda를 실행시킴
    • event : 주어+동사에서 동사에 해당
  • NodeJS, Python, Java, GO 등 다양한 언어 지원
  • Lambda Function

비용

  • Lambda Function이 실행될 때만 돈 지불
  • 매달 1.000.000 함수 호출 시 무료 (그 후로는 유료)

기타

  • 최대 300초(5분) 런타임 시간 허용
  • 512MB의 일시적인 디스크 공간 제공 (/tmp/)
    • Lambda 함수로 들어오는 input을 일시적인 공간에 저장할 때 코딩을 통하여 임시 저장소에 두었다가 꺼내올 수 있음
  • 최대 50MB Deployment Package 허용
    • 50MB가 초과될시 S3 버킷 사용

사용 용례

S3 버킷에 파일 업로드 -> PutObject 이벤트 발생 -> Lambda 함수 실행
Lambda는 데이터를 읽어오고 불필요한 데이터 삭제, 변환 작업, DB로 깨끗한 데이터를 업로드


CloudFront

  • Edge Location : edge Location을 사용하여 정적, 동적, 실시간 웹사이트 컨텐츠를 유저들에게 전달, 특정 유저가 요청했을 때 Edge Location을 통해 웹사이트에 컨텐츠가 딜리버리되어 퍼포먼스를 극대화

    Edge Location (엣지 지역) : 컨텐츠들이 캐시(Cache)에 보관되어지는 장소

  • Content Deliverty Network(CDN) : 웹페이지가 현재 어디서 불려지는지, 불러오려 하는 사용자의 지역에 근거하여 컨텐트 웹페이지에 내용물들(html, js, 이미지 등)을 딜리버리해주는 해줌으로써 속도를 비약적으로 향상시켜줌

기존
한국에서 웹 사이트 호스팅(Origin) -> 전 세계 유저들의 위치에 따라 컨텐츠 딜리버리 시간이 달라진다.

Origin (오리진) : 원래 컨텐츠들이 들어있는 곳, 웹서버 호스팅이 되어지는 곳. S3, EC2인스턴스가 오리진이 될 수 있음

CDN
한국에서 웹 사이트 호스팅 -> CDN은 직접 한국에서 모든 컨텐츠들을 전달하려 하는 게 아닌 edge location을 통해 유저들에게 컨텐츠를 전송, 그리고 캐시를 사용하는데 만약 첫 사용 시 컨텐츠가 캐시에 없다면 Origin과 연결 후 그 정보를 Edge Location에 넣고 유저들에게 컨텐츠를 전송한다. 컨텐츠들은 캐시에 등록되어 나중에 사용자들이 요청하면 더이상 Origin이 아니라 Edge Location을 이용해 뿌려서 딜리버리 속도를 향상시킨다.

Distribution(분산) : CDN에서 사용되어지며 Edge Location들을 묶고 있다는 개념


API Gateway

대부분의 애플리케이션은 RESTful API 기반으로 운용된다.

API Gateway가 없다면

  • 매우 힘든 RESTful API 관리
    • Authentication & Authorization
    • API 요청을 모니터링 해야함
    • 더 나은 성능을 위해 API 요청 캐시 시스템 필요

API Gateway

  • 뛰어난 확장성 제공 및 API를 만들고 운영하고 모니터링 가능
  • Back-end 서비스 (웹 애플리케이션, EC2)에 들어있는 데이터 접근 허용
  • Pay As You Go : API를 사용할 때 쓴 만큼 비용 지불
profile
Problem Solving과 기술적 의사결정을 중요시합니다.

0개의 댓글