AWS System Manager OpsCenter – IT 운영 간소화를 위한 신규 기능 출시

KENNETH

5년 ago

AWS Systems Manager의 새로운 기능인 OpsCenter는 AWS 고객이 여러 서비스에 걸친 문제, 이벤트 및 경보를 집계할 수 있게 해 줍니다. 이를 통해 고객은 단일 위치에서 문제를 검토, 조사 및 해결할 수 있으므로 서로 다른 여러 AWS 서비스로 이동할 필요가 감소됩니다.

관리 콘솔에서 문제, 이벤트 및 경보 등의 정보는 OpsItem(운영 항목)으로 표시되며 컨텍스트 정보, 과거 기록에 기반한 안내 및 빠른 해결 단계를 제공합니다. 이 기능은 단일 위치에서 주요 조사 데이터를 제공함으로써, 해결에 소요되는 평균 시간을 단축하고, 엔지니어의 생산성을 향상하도록 설계되었습니다.

엔지니어는 OpsItem을 통해 다음과 같은 정보에 액세스할 수 있습니다.

이벤트, 리소스 및 계정 세부 정보
유사한 특성을 가진 과거의 OpsItem
관련 AWS Config 변경 사항 및 관계
AWS CloudTrail 로그
Amazon CloudWatch 경보
AWS CloudFormation 스택 정보
그 외에 로그 및 지표 액세스를 위한 빠른 링크
실행서 목록 및 권장 실행서
AWS 서비스를 통해 OpsCenter로 전달되는 추가 정보

이 정보를 사용하면 엔지니어가 운영 문제를 더 신속하게 조사하고 해결할 수 있습니다. OpsCenter를 사용하면 엔지니어가 Systems Manager 콘솔에서 또는 ystems Manager OpsCenter API를 사용하여 문제를 검토하고 해결할 수 있습니다.

이 블로그의 나머지 부분에서는 이 새로운 기능을 통해 수행할 수 있는 작업을 살펴보겠습니다. 먼저 Systems Manager 콘솔을 열고 원하는 리전에서 작업 중인지 확인한 다음 화면의 가장 왼쪽에 있는 [운영 관리] 메뉴에서 [OpsCenter]를 클릭합니다.

[OpsCenter] 화면을 처음 열고 [시작하기]를 클릭하면 [Configure sources] 화면이 표시됩니다. 이 화면에서는 특정 규칙이 트리거될 때 OpsItem을 생성하게 될 CloudWatch 규칙의 일부 예제를 통해 시스템을 설정합니다. 예를 들어, Auto Scaling EC2 인스턴스가 중지 또는 종료된 경우 경보를 표시하는 CloudWatch 규칙이 있습니다. 이 화면에서 OpsItem을 생성할 권한을 가진 IAM 역할의 ARN을 구성하고 추가해야 합니다. 이 보안 역할은 CloudWatch 규칙이 OpsItem을 생성할 때 사용됩니다. 물론, API를 통해서 또는 사용자 지정 CloudWatch 규칙을 생성하여 자체 OpsItem을 생성할 수도 있습니다.

이제 시스템에서 일부 CloudWatch 규칙을 설정했으므로 경보를 트리거하여 테스트를 수행해 보겠습니다. EC2 콘솔에서 의도적으로 Auto Scaling 그룹에 연결된 Amazon Machine Image를 등록 해제(삭제)하겠습니다. 그런 다음 Auto Scaling 그룹의 [원하는 용량]을 2에서 4로 증가시킵니다. Auto Scaling 그룹은 나중에 새 인스턴스의 생성을 시도하지만 AMI를 삭제했으므로 작업이 실패합니다.

예상대로 이 상황은 OpsCenter 콘솔에서 OpsItem을 생성하는 CloudWatch 규칙을 트리거합니다. 이제 [OpsItem status summary] 대시보드에 1개의 미처리 항목이 표시됩니다. 이 숫자를 클릭하면 처리되지 않은 OpsItem에 대한 세부 정보를 볼 수 있습니다.

이 화면은 모든 미처리 OpsItem의 목록을 표시하며, 여기에서는 Auto Scaling 그룹에 연결된 AMI를 제거했기 때문에 CloudWatch 규칙에 의해 생성된 “Auto Scaling EC2 instance launch failed”라는 제목의 항목을 볼 수 있습니다. 이 OpsItem을 클릭하면 해당 OpsItem에 대한 보다 자세한 정보가 표시됩니다.

이 [Overview] 화면에서 항목에 대한 탐색을 시작할 수 있습니다. 이 화면을 자세히 살펴보면 해당 OpsItem에 대하여 여러 서비스로부터 수집된 추가 정보가 한 위치에 모두 표시되는 것을 알 수 있습니다.

화면 하단의 [Similar OpsItems]에서는 다른 유사한 OpsItem를 보고 이를 탐색할 수 있습니다. 실제 상황에서, 이 화면은 과거에 유사한 문제가 어떻게 해결되었는지에 대한 컨텍스트 정보를 제공함으로써 운영팀이 이전 경험에서 얻은 지식을 활용할 수 있게 해 줍니다. OpsItem이 서로 연결되어 경우에는 항목 사이에 관계를 수동으로 추가할 수도 있습니다. 중요한 점은 [Operational data] 섹션이 문제의 원인에 대한 정보를 제공해 준다는 것입니다. [status-message]는 문제를 구체적으로 언급해 주므로 특히 유용합니다(이 예에서는 AMI가 존재하지 않는다는 메시지 표시).

[Related resource] 세부 정보 화면에서는 이 OpsItem에 대해 더 자세한 정보를 찾을 수 있습니다. 예를 들어, 관련 CloudWatch 경보와 함께 리소스에 대한 태그 정보를 볼 수 있습니다. AWS Config의 세부 정보를 탐색하거나 CloudTrail 로그를 드릴다운할 수 있습니다. 리소스가 CloudFormation 스택에 연결되어 있는지도 볼 수 있습니다.

앞에서, Auto Scaling 그룹의 인스턴스 수가 원하는 인스턴스 임계값(인스턴스 4개) 밑으로 내려갈 때 알림을 표시하는 CloudWatch 경보를 생성했습니다. 여기에서 볼 수 있듯이, 이 정보를 확인하기 위해 CloudWatch 콘솔로 이동할 필요가 없습니다. 이 화면에서 바로 상태가 “Booking App Instance Count Low”인 경보가 한 개 있는 것을 볼 수 있습니다.

[Runbooks] 섹션은 놀라운 기능을 숨기고 있습니다. 바로 자동화된 방식으로 문제를 해결할 수 있는 기능을 제공하고 있는 것입니다. 몇 가지 실행서가 내장되어 있지만, 다행스럽게도 바로 이 문제에 대한 수정을 자동화하는 사용자 지정 실행서가 준비되어 있습니다. 이 실행서는 해당 Auto Scaling 그룹에 있는 정상 상태의 인스턴스 중 하나를 기반으로 새 AMI를 생성한 다음, 인스턴스를 생성할 때 새 AMI를 사용하도록 AWS Config를 업데이트합니다. 이 자동화를 실행하려면 실행서를 선택하고 [Execute]를 클릭합니다.

실행서는 자동화 작업을 위한 일부 파라미터를 제공할 것을 요청합니다. 유일한 필수 파라미터인 Auto Scaling 그룹 이름(BookingsAppASG)을 붙여넣고 [Execute]를 클릭하겠습니다.

약 1분 후, 실행서의 [Latest Status] 열에 녹색 성공 표시자가 나타나면 로그를 볼 수 있으며, 어떤 작업을 수행했는지 다른 엔지니어가 명확하게 볼 수 있도록 출력을 OpsItem의 운영 데이터에 저장할 수도 있습니다.

OpsCenter OpsItem의 [Related resource] 세부 정보 화면으로 돌아가면, CloudWatch 경보가 녹색의 [정상] 상태로 표시되어, Auto Scaling 그룹에 현재 4개의 인스턴스가 실행 중이고 이제 OpsItem을 해결할 수 있음을 알려줍니다.