[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Managing Your AWS Infrastructure at Scale(2015, 영문)내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
본 문서는 총 2부로 구성되어 있으며 이 글은 2부입니다.
1부 링크 : 대규모로 AWS 인프라 관리하기 1/2
AWS 서비스를 사용하여 환경 관리
앞 섹션에서는 시스템 관리자와 개발자가 EC2 인스턴스를 자동화되고 예측 가능하며 반복 가능한 방식으로 프로비저닝하는 데 사용할 수 있는 툴과 기술에 대해 논의했습니다. 또한 AWS는 이 프로세스를 보다 단순하고 생산적으로 만드는 데 도움이 되는 다양한 애플리케이션 관리 서비스를 제공합니다. 다음 그림에서는 필요한 제어 수준에 따라 애플리케이션에 적합한 서비스를 선택하는 방법을 보여 줍니다.
이러한 서비스는 EC2 인스턴스를 프로비저닝하는 것 외에도 자동 확장 그룹, 로드 밸런서 및 네트워킹 구성 요소와 같이 시스템에 필요한 다른 관련 AWS 구성 요소를 프로비저닝하는 데 도움이 될 수 있습니다. 이러한 서비스의 사용 방법에 대한 자세한 내용은 다음 섹션을 참조하시기 바랍니다.
AWS Elastic Beanstalk
AWS Elastic Beanstalk를 사용하면 웹 개발자가 기본 인프라 구성 요소를 관리하거나 구현할 염려 없이 코드를 쉽게 업로드할 수 있습니다. Elastic Beanstalk는 구축, 용량 프로비저닝, 로드 밸런싱, 자동 확장 및 애플리케이션 상태 모니터링을 담당합니다. Elastic Beanstalk는 블랙박스 서비스가 아닙니다. EC2 인스턴스 및 로드 밸런서와 같이 배포된 기본 AWS 리소스를 완벽하게 파악하고 제어할 수 있습니다.
Elastic Beanstalk는 Java의 배치를 지원합니다. Apache, Nginx, Passer 및 IIS와 같은 친숙한 서버에서 NET, Ruby, PHP, Python, Node.js 및 Docker를 사용할 수 있습니다. Elastic Beanstalk는 기본 구성을 제공하지만 필요에 따라 구성을 확장할 수 있습니다. 예를 들어 yum 저장소에서 추가 패키지를 설치하거나 애플리케이션이 종속된 구성 파일(예: httpd.conf를 대체하여 특정 설정을 재정의하려는 경우)을 복사할 수 있습니다.
구성 파일을 YAML 또는 JSON 형식으로 작성하고 다음을 사용하여 파일을 생성할 수 있습니다.
.config 파일 확장자입니다. 그런 다음 이름이 지정된 응용 프로그램 루트의 폴더에 파일을 배치합니다.
.ebextension입니다. 구성 파일을 사용하여 패키지 및 서비스를 관리하고, 파일을 작업하고, 명령을 실행할 수 있습니다.
Elastic Beanstalk 사용 및 확장에 대한 자세한 내용은 AWS Elastic Beanstalk 설명서를 참조합니다.
AWS OpsWorks
AWS OpsWorks는 애플리케이션 및 필요한 AWS 리소스를 쉽게 배포 및 관리할 수 있는 애플리케이션 관리 서비스입니다. AWS OpsWorks를 사용하면 하나 이상의 계층으로 구성된 애플리케이션 스택을 구축할 수 있습니다. AWS OpsWorks 구성, 사용자 지정 구성 또는 두 가지 구성 모두를 사용하여 계층을 구성합니다. AWS OpsWorks는 오픈 소스 구성 관리 도구인 Chef를 사용하여 AWS 리소스를 구성합니다. 이를 통해 맞춤형 또는 커뮤니티 셰프 레시피를 제공할 수 있습니다.
AWS OpsWorks에는 각 인스턴스에서 적절한 시간에 적절한 레시피를 자동으로 실행하는 Setup, Configure, Deploy, Undeploy 및 Shutdown 등의 라이프사이클 이벤트 집합이 있습니다. AWS OpsWorks는 일반적인 응용 프로그램 스택에 대해 일부 AWS 관리 계층을 제공합니다. 이러한 계층은 열려 있고 사용자 지정이 가능합니다. 즉, AWS OpsWorks에서 제공하는 계층에 추가 사용자 지정 방법을 추가하거나 기존 레시피를 사용하여 처음부터 사용자 지정 계층을 생성할 수 있습니다.
올바른 레시피가 올바른 라이프사이클 이벤트와 연관되어 있는지 확인하는 것이 중요합니다. 수명 주기 이벤트는 다음 시간 동안 실행됩니다.
· 설정 — 성공적으로 부팅된 후 새 인스턴스에서 발생합니다.
· 구성 — 인스턴스가 온라인 상태로 전환되거나 종료될 때 스택의 모든 인스턴스에서 발생합니다.
· 배포 — 앱을 배포할 때 발생합니다.
· 배포 취소 — 앱을 삭제할 때 발생합니다.
· 종료 — 인스턴스를 중지할 때 발생합니다.
예를 들어, 이 구성 이벤트는 분산 시스템을 구축할 때 또는 스택에서 새 인스턴스를 추가하거나 제거할 때를 알아야 하는 모든 시스템에 유용합니다. 이 이벤트를 사용하여 스택에 새 웹 서버를 추가할 때 로드밸런서를 업데이트할 수 있습니다.
AWS OpsWorks는 일반적인 서버 구성 외에도 애플리케이션 배포를 관리하고 애플리케이션의 코드 저장소와 통합됩니다. 이를 통해 필요한 경우 애플리케이션 버전을 추적하고 배포를 롤백할 수 있습니다.
AWS OpsWorks에 대한 자세한 내용은 AWS OpsWorks 설명서를 참조합니다.
AWS CloudFormation
AWS CloudFormation은 개발자 및 시스템 관리자에게 관련 AWS 리소스 컬렉션을 손쉽게 생성하고 관리하여 질서 있고 예측 가능한 방식으로 프로비저닝 및 업데이트할 수 있는 방법을 제공합니다. Elastic Beanstalk 및 AWS OpsWorks에 비해 AWS CloudFormation은 리소스를 프로비저닝할 때 가장 많은 제어력과 유연성을 제공합니다.
AWS CloudFormation을 사용하면 광범위한 AWS 리소스 집합을 관리할 수 있습니다. 이 백서에서는 EC2 인스턴스를 부팅하는 데 사용할 수 있는 기능에 초점을 맞춥니다.
사용자 데이터
이 백서 앞부분에서는 사용자 데이터를 사용하여 EC2 인스턴스를 구성하고 사용자 지정하는 프로세스를 설명합니다(자체 솔루션 스크립팅 참조). 또한 사용자 데이터를 생성하면 인스턴스에서 실행되는 AWS CloudFormation 템플릿에 포함할 수도 있습니다. 단일 EC2 인스턴스를 지정할 때와 시작 구성을 지정할 때 사용자 데이터를 포함할 수 있습니다. 다음 예에서는 PHP 웹 서버로 구성된 인스턴스를 프로비저닝하는 실행 구성을 보여 줍니다.
"MyLaunchConfig" : {"Type" : "AWS::AutoScaling::LaunchConfiguration", "Properties" : {"ImageId" : "i-123456","SecurityGroups" : "MySecurityGroup", "InstanceType" : "m3.medium", "KeyName" : "MyKey","UserData": {"Fn::Base64": {"Fn::Join":["",[ "#!/bin/bash\n","yum update -y\n","yum -y install httpd php php-mysql\n", "chkconfig httpd on\n", "/etc/init.d/httpd start\n"]]}}}}
cfn-init
cfn-init 스크립트는 보다 선언적인 방식으로 EC2 인스턴스의 종료 상태를 지정하는 데 사용할 수 있는 AWS CloudFormation 도우미 스크립트입니다. cfn-init 스크립트는 기본적으로 Amazon Linux 및 AWS에서 제공하는 윈도우즈 AMI에 설치됩니다. 관리자는 다른 Linux 배포에 cfn-init를 설치한 다음 필요한 경우 이를 자신의 AMI에 포함할 수도 있습니다.
cfn-init 스크립트는 AWS CloudFormation 템플릿에서 메타데이터를 구문 분석하며 메타데이터를 사용하여 인스턴스를 적절하게 사용자 지정합니다. cfn-init 스크립트는 다음을 수행할 수 있습니다.
· 패키지 리포지토리에서 패키지를 설치합니다(예: yum 및 apt-get).
· .zip 및 .tar 파일과 같은 아카이브를 다운로드하고 압축을 풉니다.
· 디스크에 파일을 씁니다.
· 임의 명령을 실행합니다.
· 사용자 및 그룹을 생성합니다.
· 서비스를 활성화/비활성화하고 시작/중지합니다.
서비스를 활성화/비활성화하고 시작/중지합니다.AWS CloudFormation 템플릿에서 cfn-init 도우미 스크립트는 사용자 데이터에서 호출됩니다. 호출되면 요청에 전달된 리소스와 연결된 메타데이터를 검사한 다음 그에 따라 작동합니다. 예를 들어 다음 시작 구성 메타데이터를 사용하여 cfn-init에 EC2 인스턴스를 PHP 웹 서버로 구성하도록 지시할 수 있습니다(이전 사용자 데이터 예와 유사).
"MyLaunchConfig" : {"Type" : "AWS::AutoScaling::LaunchConfiguration", "Metadata" : {"AWS::CloudFormation::Init" : { "config" : {"packages" : {"yum" : { "httpd" : [],"php" : [],"php-mysql" : []}},"services" : {"sysvinit" : {"httpd" : {"enabled" : "true","ensureRunning" : "true"
}}}}}},"Properties" : { "ImageId" : "i-123456","SecurityGroups" : "MySecurityGroup", "InstanceType" : "m3.medium", "KeyName" : "MyKey","UserData": {"Fn::Base64": {"Fn::Join":["",[ "#!/bin/bash\n","yum update -y aws-cfn-bootstrap\n", "/opt/aws/bin/cfn-init --stack ", { "Ref" :"AWS::StackId" }, " --resource MyLaunchConfig "," --region ", { "Ref" : "AWS::Region" }, "\n",]]}}}}
서비스를 함께 사용
서비스를 별도로 사용하여 새 인프라 구성 요소를 프로비저닝할 수 있지만 이러한 구성 요소를 결합하여 단일 솔루션을 생성할 수도 있습니다. 이 접근 방식은 분명한 이점을 가지고 있습니다. 예를 들어 네트워킹 및 데이터베이스 구성을 포함한 전체 아키텍처를 AWS CloudFormation 템플릿으로 직접 모델링한 다음 AWS Elastic Beanstalk 또는 AWS OpsWorks를 사용하여 애플리케이션을 배포 및 관리할 수 있습니다. 이 접근 방식은 리소스 및 애플리케이션 관리를 통합하여 전체 아키텍처에 버전 제어를 더 쉽게 적용할 수 있도록 합니다.
애플리케이션 및 인스턴스 상태 관리
새 인프라 구성 요소를 자동으로 프로비저닝하는 적절한 프로세스를 구현하면 시스템은 빠르고 반복 가능하며 예측 가능한 방식으로 새 EC2 인스턴스 및 전체 환경을 생성할 수 있습니다. 그러나 동적 클라우드 환경에서는 환경에서 EC2 인스턴스를 제거하는 방법과 이 인스턴스가 사용자에게 제공하는 서비스에 어떤 영향을 미칠 수 있는지 고려해야 합니다. 시스템에서 인스턴스를 제거할 수 있는 여러 가지 이유는 다음과 같습니다.
· 하드웨어 또는 소프트웨어 오류로 인해 인스턴스가 종료됩니다.
· 인스턴스는 오토스케일링 그룹에서 인스턴스를 제거하기 위한 “스케일 다운” 이벤트에 대한 응답으로 종료됩니다.
· 블루-그린 배포를 사용하여 새 버전의 소프트웨어 스택을 배포했기 때문에 인스턴스가 종료됩니다(이전 버전의 애플리케이션을 실행 중인 경우에는 배포 후 종료됨).
서비스에 영향을 주지 않고 인스턴스 제거를 처리하려면 애플리케이션 인스턴스가 상태 비저장 상태인지 확인해야 합니다. 즉, 모든 시스템 및 애플리케이션 상태가 인스턴스 자체 외부에 저장되고 관리됩니다. 다음 표와 같이 시스템을 설계할 때 고려해야 할 다양한 형태의 시스템 및 애플리케이션 상태가 있습니다.
상태 비 저장 응용 프로그램 인스턴스를 실행하면 집합의 인스턴스가 다른 인스턴스와 다르지 않으므로 여러 가지 이점이 있습니다.
· 강력한 서비스 제공 — 인스턴스는 언제든지 모든 사용자의 요청을 처리할 수 있습니다. 인스턴스가 실패하면 실패한 인스턴스가 교체되는 동안 후속 요청을 대체 인스턴스로 라우팅할 수 있습니다. 이는 사용자의 서비스를 중단하지 않고 달성할 수 있습니다.
· 더 빠르고 덜 복잡한 부트스트랩 — 인스턴스에 동적 상태가 포함되어 있지 않기 때문에 부트스트래핑 프로세스는 시스템을 애플리케이션 계층까지 프로비저닝하는 작업에만 관여해야 합니다. 상태와 데이터를 복구할 필요가 없습니다. 이 경우 대개 크기가 크므로 부트스트래핑 시간을 크게 늘릴 수 있습니다.
· 배포 단위 인 EC2 인스턴스 — 모든 상태는 EC2 인스턴스 자체를 벗어나 유지되므로 애플리케이션 배포를 조정하는 동안 인스턴스를 교체할 수 있습니다. 이를 통해 배포 프로세스를 간소화하고 Blue-green 배포와 같은 새로운 배포 기술을 사용할 수 있습니다.
다음 섹션에서는 각 애플리케이션 및 인스턴스 상태 유형에 대해 설명하고 애플리케이션 인스턴스 자체와 별도로 독립적으로 저장하기 위해 사용할 수 있는 몇 가지 도구와 기법을 간략히 설명합니다.
구조화 된 애플리케이션 데이터
대부분의 응용프로그램은 주문 관리 시스템의 고객 주문 또는 CMS의 웹 페이지 목록과 같은 구조화된 텍스트 데이터를 생성합니다. 대부분의 경우 이러한 종류의 콘텐츠는 데이터베이스에 가장 잘 저장됩니다. 데이터 구조와 액세스 속도 및 동시성에 대한 요구 사항에 따라 관계형 데이터베이스 관리 시스템 또는 NoSQL 데이터 저장소를 사용할 수 있습니다. 어느 경우든 응용 프로그램을 실행하는 인스턴스에서 멀리 떨어진 내구성이 뛰어나고 가용성이 높은 시스템에 이 콘텐츠를 저장하는 것이 중요합니다. 이렇게 하면 인스턴스에 장애가 발생한 경우에도 사용자에게 제공하는 서비스가 중단되거나 데이터가 손실되지 않습니다.
AWS는 애플리케이션의 지속성 계층으로 사용할 수있는 관계형 및 NoSQL 관리 형 데이터베이스를 모두 제공하며 다음 섹션에서 이러한 데이터베이스 옵션에 대해 설명합니다.
Amazon RDS
Amazon RDS(Amazon Relational Database Service)는 클라우드에서 관계형 데이터베이스를 쉽게 설정, 운영 및 확장할 수 있는 웹 서비스입니다. MySQL, Oracle, Microsoft SQL Server 또는 Postgre 등 익숙한 관계형 데이터베이스 엔진을 계속 사용할 수 있습니다.SQL. 이것은 사용자가 이미 사용하고 있는 코드, 애플리케이션 및 운영 도구를 Amazon RDS와 함께 사용할 수 있음을 의미합니다. Amazon RDS는 데이터 백업, 복구 및 패치 관리와 같은 시간이 많이 소요되는 데이터베이스 관리 작업도 처리하므로 데이터베이스 관리자가 더 높은 가치를 지닌 애플리케이션 개발 또는 데이터베이스 리피넴을 추구할 수 있습니다.ents입니다.
또한 Amazon RDS Multi-AZ를 구축하면 데이터베이스 가용성이 향상되고 예상치 못한 운영 중단으로부터 데이터베이스를 보호할 수 있습니다. 이를 통해 서비스 복원력이 한층 향상됩니다.
Amazon DynamoDB
Amazon DynamoDB는 문서(JSON)와 키 값 데이터 모델을 모두 제공하는 완전히 관리되는 NoSQL 데이터베이스 서비스입니다. DynamoDB는 어느 규모에서나 일관된 단일 자리 수 밀리초 지연 시간을 제공하도록 설계되었으므로 대기 시간이 짧은 데이터 액세스가 필요한 트래픽이 많은 애플리케이션에 이상적입니다. DynamoDB는 사용자를 대신하여 인프라의 확장 및 파티셔닝을 관리합니다. 테이블을 생성할 때 필요한 요청 용량을 지정합니다. 처리량 요구 사항이 변경되면 서비스에 영향을 주지 않고 필요에 따라 이 용량을 업데이트할 수 있습니다.
비정형 애플리케이션 데이터
대부분의 애플리케이션에서 생성된 구조화된 데이터 외에도 일부 시스템에는 문서, 이미지 및 기타 이진 데이터와 같은 구조화되지 않은 리소스를 수신하고 저장해야 하는 요구 사항도 있습니다. 예를 들어 CMS의 경우 편집자가 웹 사이트에서 호스팅할 이미지 및 PDF를 업로드할 수 있습니다.
대부분의 경우 데이터베이스는 이러한 유형의 컨텐츠에 적합한 저장 메커니즘이 아닙니다. 대신 Amazon Simple Storage Service(Amazon S3)를 사용할 수 있습니다. Amazon S3는 이러한 종류의 데이터를 저장하는 데 매우 적합한 고가용성 및 내구성의 객체 저장소를 제공합니다. 데이터가 Amazon S3에 저장되면 이러한 요청을 응용 프로그램 인스턴스로 이동할 필요 없이 HTTP(S)를 통해 이러한 파일을 Amazon S3에서 최종 사용자에게 직접 제공할 수 있습니다.
사용자 세션 데이터
많은 애플리케이션이 애플리케이션 내에서 사용자의 현재 위치와 관련된 정보를 생성합니다. 예를 들어, 사용자가 전자 상거래 사이트를 검색할 때 다양한 항목을 쇼핑 바구니에 추가하기 시작할 수 있습니다. 이 정보를 세션 상태라고 합니다. 바구니에 들어 있는 항목이 예고 없이 사라지면 사용자에게 답답할 수 있으므로 세션 상태를 애플리케이션 인스턴스 자체로부터 멀리 저장하는 것이 중요합니다. 이렇게 하면 사용자의 요청이 로드 밸런서 뒤의 대체 인스턴스로 이동되거나 현재 인스턴스가 어떤 이유로든 서비스에서 제거되는 경우에도 바스켓이 채워진 상태를 유지할 수 있습니다.
AWS 플랫폼은 고가용성 세션 저장소를 제공하는 데 사용할 수 있는 여러 서비스를 제공합니다.
Amazon ElastiCache
Amazon ElastiCache를 사용하면 AWS에서 메모리 내 데이터 저장소를 쉽게 배포, 운영 및 확장할 수 있습니다. 메모리 내 데이터 저장소는 이러한 기술이 제공하는 짧은 지연 시간으로 인해 임시 세션 데이터를 저장하는 데 이상적입니다. ElastiCache는 두 가지 오픈 소스, 메모리 내 캐싱 엔진을 지원합니다.
· Memcached — 널리 사용되는 메모리 개체 캐싱 시스템입니다. ElastiCache는 Memcached를 준수하는 프로토콜로, 이미 많은 오픈 소스 애플리케이션에서 메모리 내 세션 스토리지 플랫폼으로 지원되고 있습니다.
· Redis — 정렬된 세트 및 목록과 같은 데이터 구조를 지원하는 널리 사용되는 오픈 소스, 메모리 내 키 값 저장소입니다. ElastiCache는 마스터/슬레이브 복제 및 Multi-AZ를 지원하므로 AZ 간 이중화를 달성할 수 있습니다.
ElastiCache에서 Memcached 및 Redis가 제공하는 메모리 내 데이터 저장소 외에도 일부 애플리케이션에는 세션 데이터를 위한 내구성이 높은 스토리지 플랫폼이 필요합니다. 이러한 애플리케이션을 위해 Amazon DynamoDB는 대기 시간이 짧고 확장성이 뛰어나며 내구성이 뛰어난 솔루션을 제공합니다. DynamoDB는 AWS 영역의 3개 시설에 걸쳐 데이터를 복제하여 서버 장애 또는 가용성 영역 중단 시 내결함성을 제공합니다.
고객이 애플리케이션 내의 세션 저장소로 DynamoDB를 쉽게 통합할 수 있도록 AWS는 Tomcat 기반 Java 애플리케이션과 PHP 애플리케이션 모두에 대해 사전 구축된 DynamoDB 세션 처리기를 제공합니다.
시스템 지표
운영 팀은 프로덕션 시스템을 적절하게 지원하려면 시스템의 전반적인 상태와 현재 운영 중인 상대 로드를 나타내는 시스템 메트릭에 액세스할 필요가 있습니다. 기존 환경에서는 인스턴스 중 하나에 로그인하고 시스템 로드 또는 CPU 사용률과 같은 OS 수준 메트릭을 확인하여 이 정보를 얻는 경우가 많습니다. 그러나 여러 인스턴스가 실행되고 있고 이러한 인스턴스가 언제든지 표시되거나 사라질 수 있는 환경에서는 이 접근 방식이 곧 비효율적이고 관리하기 어려워집니다. 대신 수집 및 분석을 위해 외부 모니터링 시스템에 이 데이터를 푸시해야 합니다.
Amazon CloudWatch
Amazon CloudWatch는 AWS 리소스와 위에서 실행되는 애플리케이션을 완벽하게 관리하는 모니터링 서비스입니다. Amazon CloudWatch를 사용하면 자체 인프라와 독립적으로 독립적으로 유지되는 내구성이 뛰어난 플랫폼에서 메트릭스를 수집하고 저장할 수 있습니다. 즉, 인스턴스 자체가 종료된 경우에도 운영 팀에서 메트릭을 사용할 수 있습니다.
메트릭 추적 외에도 Amazon CloudWatch를 사용하여 메트릭이 특정 임계값을 통과할 때 메트릭에 경보를 트리거할 수 있습니다. 경보를 사용하여 팀에게 알리고 문제를 처리하고 시스템을 정상 작동 허용 범위 내에서 되돌리기 위한 추가 자동화 작업을 시작할 수 있습니다. 예를 들어 자동화된 작업은 자동 크기 조정 그룹의 인스턴스 수를 늘리거나 줄이기 위해 자동 크기 조정 정책을 시작할 수 있습니다.
기본적으로 Amazon CloudWatch는 AWS 리소스 전반에서 광범위한 메트릭을 모니터링할 수 있습니다. 즉, AWS는 EC2 인스턴스에서 실행되는 OS 또는 애플리케이션에 액세스할 수 없습니다. 이 때문에 Amazon CloudWatch는 메모리 및 디스크 볼륨 활용률과 같이 OS 내에서만 액세스할 수 있는 메트릭을 자동으로 모니터링할 수 없습니다. Amazon CloudWatch를 사용하여 OS 및 애플리케이션 메트릭스를 모니터링하려는 경우 간단한 API 요청을 통해 자체 메트릭스를 CloudWatch에 게시할 수 있습니다. 이 방법을 사용하면 경보 및 관련 작업 구성을 포함하여 다른 기본 메트릭을 관리하는 것과 동일한 방법으로 이러한 메트릭을 관리할 수 있습니다.
EC2Config 서비스를 사용하면 CloudWatch API를 기반으로 수동으로 코드화할 필요 없이 추가 OS 레벨 운영 메트릭스를 CloudWatch에 적용할 수 있습니다. Linux AMI를 실행하는 경우 AWS에서 제공하는 샘플 Perl 스크립트 세트를 사용하여 Amazon CloudWatch 사용자 지정 메트릭스를 생성하고 사용하는 방법을 시연할 수 있습니다.
CloudWatch 외에도 AWS의 타사 모니터링 솔루션을 사용하여 모니터링 기능을 확장할 수 있습니다.
로그 관리
로그 데이터는 운영 팀이 시스템의 성능을 더 잘 이해하고 발생할 수 있는 문제를 진단하는 데 사용됩니다. 로그 데이터는 애플리케이션 자체에서 생성될 수 있지만 스택의 아래쪽에 있는 시스템 구성 요소에서도 생성할 수 있습니다. 여기에는 웹 서버에서 생성된 액세스 로그부터 운영 체제 자체에서 생성된 보안 감사 로그까지 모든 항목이 포함될 수 있습니다.
운영 팀에서는 원래 로그를 생성한 인스턴스가 아직 존재하는지 여부에 관계없이 항상 이러한 로그에 대한 안정적이고 적시에 액세스할 수 있어야 합니다. 따라서 로그 데이터를 인스턴스에서 최대한 실시간으로 보다 내구성이 뛰어난 스토리지 플랫폼으로 이동하는 것이 중요합니다.
Amazon CloudWatch Logs
Amazon CloudWatch Logs는 EC2 인스턴스 자체에서 중앙 집중식 내구성 높은 스토리지 플랫폼(Amazon S3)으로 시스템 및 애플리케이션 로그를 빠르고 쉽게 이동할 수 있는 서비스입니다. 이렇게 하면 인스턴스 자체가 종료된 경우에도 이 데이터를 사용할 수 있습니다. 또한 모든 로그가 지정된 기간 동안 유지되도록 로그 보존 정책을 제어할 수 있습니다. CloudWatch Logs 서비스는 EC2 인스턴스에 설치하여 로그 관리 서비스로의 로그 수집을 관리할 수 있는 로그 관리 에이전트를 제공합니다.
CloudWatch Logs 서비스를 사용하면 로그를 내구성 있는 스토리지로 이동하는 것 외에도 특정 문구, 값 또는 패턴(메트릭)을 거의 실시간으로 모니터링할 수 있습니다. 이러한 메트릭스는 다른 CloudWatch 메트릭스와 동일한 방식으로 사용할 수 있습니다. 예를 들어 애플리케이션에서 발생하는 오류 수에 대해 또는 확실할 경우 보안 감사 로그에서 의심스러운 작업이 탐지되는 CloudWatch 경보를 생성할 수 있습니다.
결론
이 백서에서는 다음 작업을 수행하는 방법을 보여 주었습니다.
· 자동화되고 반복 가능하며 예측 가능한 방식으로 새로운 인프라 구성 요소를 신속하게 프로비저닝합니다.
· 사용자 환경에서 고유한 EC2 인스턴스가 없으며 모든 인스턴스가 상태 비저장 상태이므로 쉽게 교체되어야 합니다.
이러한 기능을 갖추면 기존 환경과 비교하여 인프라 구성 요소를 프로비저닝하고 관리하는 방법에 대해 다르게 생각할 수 있습니다.
각 인스턴스를 수동으로 구축하고 운영 점검 및 균형을 통해 일관성을 유지하는 대신 인프라를 소프트웨어처럼 처리할 수 있습니다. 이 백서에 설명된 소프트웨어 기반 툴 및 프로세스를 통해 인프라의 원하는 최종 상태를 지정하면 인프라 관리 방식을 근본적으로 변경할 수 있으며, AWS 클라우드의 동적이고 탄력적이며 자동화된 특성을 최대한 활용할 수 있습니다.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
