모니터링
모니터링을 하는 이유
운영 상태
리소스 활용
애플리케이션 성능
보안 감사
Amazon Cloud Watch 를 통한 모니터링
1) 지표 - 지표 데이터는 15 개월 동안 보관됩니다.
지표는 시스템 성능에 대한 데이터입니다. 많은 AWS 서비스가 리소스에 대한 지표를 기본적으로 제공합니다(예:Amazon EC2 인스턴스, Amazon EBS 볼륨, Amazon RDS DB 인스턴스). 또한 Amazon EC2 인스턴스 같은 일부 리소스에 대해 세부 모니터링을 활성화하거나 자체 애플리케이션 지표를 게시할 수도 있습니다. AmazonCloudWatch는 검색, 그래프 처리 및 경보를 위해 계정에 모든 지표(AWS 리소스 지표 및 사용자가 제공한 애플리케이션 지표 모두)를 로드할 수 있습니다.
2) CloudWatch Logs를 사용하면 소스(예: EC2 인스턴스, Amazon Route 53, AWS CloudTrail 및 기타 AWS 서비스)의 로그 파일을 모니터링, 저장 및 액세스할 수 있습니다.
예를 들어 Amazon EC2 인스턴스의 로그를 실시간으로 모니터링할 수 있습니다. 애플리케이션 로그에서 오류 발생 횟수를 추적하고 해당 비율이 사전에 정의된 수준을 초과할 경우 알림을 보낼 수 있습니다.CloudWatch Logs는 로그 데이터 자체를 모니터링하기 때문에 코드 변경이 필요하지 않습니다. 또한 CloudWatch Logs Insights를 사용하여 몇 초 만에 로그를 분석하면 빠른 대화형 쿼리 및 시각화를 얻을 수있습니다. 선 또는 누적 영역형 차트를 사용하여 쿼리 결과를 시각화할 수 있으며, CloudWatch 대시보드에서 해당 쿼리를 추가할 수 있습니다.
3) 경보를 사용하여 작업을 자동으로 시작할 수 있습니다. 경보는 지정한 기간에 단일 지표를 감시하고 시간에따른 임계값 대비 지표 값을 기준으로 지정된 작업을 하나 이상 수행합니다. 작업이란 Amazon SNS 주제 또는Auto Scaling 정책으로 전송되는 알림을 말합니다. 대시보드에 경보를 추가할 수도 있습니다.경보는 지속되는 상태 변경에 대해서만 작업을 호출합니다. CloudWatch 경보는 특정 상태가 되었다고 해서 작업을 호출하지는 않습니다. 상태가 변경되어야 하고 지정된 기간 동안 변경된 상태가 유지되어야 합니다.이 예에서는 경보가 트리거되면 Auto Scaling 정책 실행, 알림 전송(인스턴스에 대한 알림을 운영팀에 전송) 등 다른 작업이 시작됩니다.
4) Amazon CloudWatch Events는 AWS 리소스의 변경 사항을 설명하는 시스템 이벤트의 스트림을 거의 실시간으로 제공합니다.AWS 리소스는 상태 변경 시 이벤트를 생성할 수 있습니다. 예를 들어, Amazon EC2는 EC2 인스턴스의 상태가 보류에서 실행으로 변경될 때 이벤트를 생성하며, Amazon EC2 Auto Scaling은 인스턴스가 시작 또는 종료될 때 이벤트를 생성합니다.
신속하게 설정할 수 있는 단순 규칙을 사용하여 일치하는 이벤트를 검색하고 하나 이상의 대상 함수 또는 스트림으로 이를 라우팅할 수 있습니다.CloudWatch Events는 운영 변경 시 이를 알아차립니다. CloudWatch Events는 환경에 응답하기 위한 메시지를 전송하고, 함수를 활성화하고, 변경을 수행하고, 상태 정보를 기록하는 등 이러한 운영 변경에 응답하고 필요에 따라 교정 조치를 취합니다. 또한 CloudWatch Events를 사용하여 cron 또는 rate 표현식을 통해 특정 시간에 자체 트리거되는 자동 작업을예약할 수 있습니다.
5) 규칙은 들어오는 이벤트에서 일치하는 것을 찾아서 대상으로 라우팅하여 처리합니다. 단일 규칙으로 여러 개의 대상으로 라우팅을 할 수 있으며, 이들은 모두 병렬 처리됩니다. 규칙이 처리되는 특정한 순서는 없습니다. 따라서 한 조직의 서로 다른 파트들이 자신이 관심 있는 이벤트를 찾아서 처리할 수 있습니다. 규칙은 특정 부분만 전달하거나 상수로 덮어쓰기를 해서 대상에 전송되는 JSON을 사용자 지정할 수 있습니다.
6) 대상은 이벤트를 처리합니다. 대상에는 Amazon EC2 인스턴스, AWS Lambda 함수, Kinesis 스트림, Amazon ECS작업, Step Functions 상태 시스템, Amazon SNS 주제, Amazon SQS 대기열 및 기본 제공 대상이 포함될 수 있습니다. 대상은 JSON 형식으로 이벤트를 수신합니다.
자동화
아키텍처 측면에서의 자동화의 필요성
지속적 성장을 위해서는 자동화가 필요. 조직에 있는 다양한 아키텍처를 일관되게 배포, 관리, 업데이트할 방법이 필요함.
자동화가 필요한 이유
1) 대규모 컴퓨팅 환경을 구축하려면 상당한 시간과 에너지가 필요합니다. 다음과 같은 몇 가지 사항을 고려해야 합니다.
• 설계 또는 구현, 어디에 노력을 투입할 것인가? 또한 수동 구현의 위험은 무엇인가?
• 어떻게 프로덕션 서버를 업데이트할 것인가? 어떻게 배포를 여러 지리적 리전에 롤아웃할 것인가? 장애가 발생할 경우 어떻게 롤백을 관리할 것인가?
• 배포에 대한 디버깅은 어떻게 할 것인가? 어떻게 오류를 발견하고 수정하며 수정을 확인할 것인가?
• 어떻게 다양한 시스템과 및 하위 시스템에 대한 종속성을 관리할 것인가?
• 마지막으로, 이 모든 작업을 수동으로 할 수 있는가?
2) 수동 프로세스의 위험
수동으로 개별 구성 요소를 생성하여 환경에 추가할 경우 확장이 불가능합니다. 여러분이 대규모 기업 애플리케이션을 담당하고 있는 경우 수동으로 이러한 작업을 처리할 인력은 충분하지 않습니다.아키텍처 및 애플리케이션을 처음부터 생성하면 내재된 버전 관리가 없습니다. 비상시, 프로덕션 스택을 이전 버전으로 롤백하는 것이 유용하지만, 수동으로 환경을 생성할 경우 이것이 불가능합니다. 감사 추적 기능은 많은 규정 준수 및 보안 상황에서 매우 중요합니다. 사람들이 수동으로 환경을 제어하고 편집하도록 허용하는 것은 위험합니다.
마지막으로, 위험을 최소화하려면 일관성이 매우 중요합니다. 자동화는 일관성을 유지할 수 있게 해줍니다.
코드형 인프라( IAC )의 제공
인프라를 코드형으로 구축하는 경우, 환경을 구축하면서 반복성과 재사용성의 이점을 활용할 수 있다.템플릿 하나(또는 템플릿의 조합)로 복잡한 동일 환경을 반복해서 구축할 수 있다.
AWS에서 이를 사용하는 경우, 조건에 따라 다른 환경을 생성할 수도 있다. 즉 생성했던 환경의 컨텍스트에 맞게 환경이 구축되도록 할 수 있다. 예를 들어 템플릿이 개발 환경 또는 프로덕션 환경에서 시작되었는지에 따라 서로 다른 AMI가 사용되도록 템플릿을 설계할 수 있다.
강의를 배우면서 제일 편리해보였던 서비스 json과 yaml 파일만으로 기존에 있던 모든 인스턴스, 네트워크, 개인 설정을 한 번에 해결할 수 있다. 이런 서비스가 있다면 정말 앞으로 온프레미스 서버는 얼마 못 갈 것이라고 생각한다.
가상 프라이빗 게이트웨이(VGW)
Amazon VPC와 다른 네트워크 사이에 프라이빗 연결(VPN)을 설정할 수 있다.
- 온프레미스 서버와 클라우드 서버를 연결해주는 서비스.
- 모든 서버를 클라우드 서버에 맡길 수 없는 중요한 비밀이 있는 회사에서 큰 메리트를 느낄 것이다.
- 클라우드를 배우면 배울수록 그 압도적인 편의성에 감탄하게 된다. 대한민국의 70~80%는 아직 온프레미스 서버를 사용하고 있지만, 그런 날도 얼마 남지 않았다는 걸 체감하게 된다.
마이크로 서비스 아키텍처
모놀리식 아키텍처, 쉽게 말하면 어플리케이션이 통짜로 짜여져 있어 이를 확장하거나 변경하려면 기존의 모든 서비스를 변경해야해 불편함이 컸다면, 마이크로 서비스 아키텍처는 이런 어플리케이션이 제공하는 서비스를 하나씩 분리하여 제공하기 때문에 기존 모놀리식과 비교하면 그 확장성과 편리함이 압도적으로 유리하다. 마이크로 서비스 아키텍처는 지금 IT업계의 화두로 떠오르고 있다.
