새로운 기능 — AWS Systems Manager Change Manager 출시

여러분은 고객의 피드백에 지속적으로 귀를 기울이기 때문에 애플리케이션 및 인프라를 반복, 혁신 및 개선하고 있습니다. 또한 클라우드에서 IT 시스템을 지속적으로 수정하고 있습니다. 그런데 작업 시스템에서 무언가를 변경하면 때로는 예측할 수 없는 부작용을 일으킬 위험이 있습니다. 얼마나 많은 테스트를 수행하든 상관 없이 그런 위험은 늘 있습니다. 반면에, 변화하지 않는다면 정체가 발생하며, 그다음에는 업계 동향과의 무관함 그리고 사망 선고가 뒤따릅니다.

이것이 바로 모든 규모와 유형의 조직들이 변화를 통제하는 문화를 수용하는 이유입니다. 일부 조직에서는 ITIL v4에 정의된 것과 같은 변경 관리 프로세스를 채택합니다. 일부는 DevOps의 지속적인 배포 또는 기타 방법을 채택했습니다. 어떤 경우이든 변경 관리 프로세스를 지원하려면 도구가 있어야 합니다.

오늘 AWS는 AWS Systems Manager의 새로운 변경 관리 기능인 AWS Systems Manager Change Manager를 출시합니다. 이 기능으로 운영 엔지니어는 애플리케이션 구성 및 인프라에 대한 운영 변경 사항을 추적, 승인 및 구현하는 방식을 간소화할 수 있습니다.

Change Manager를 사용할 경우 얻을 수 있는 두 가지 주요 이점이 있습니다. 첫째, 애플리케이션 구성 및 인프라 변경의 안전성을 개선하여 서비스 중단 위험을 줄일 수 있습니다. 승인된 변경 사항만 구현되고 있음을 추적하여 운영 변경 사항을 더 안전하게 만듭니다. 둘째, AWS Organizations 및 AWS Single Sign-On과 같은 다른 AWS 서비스와 긴밀하게 통합되거나 Systems Manager 변경 일정 및 Amazon CloudWatch 경보와 통합됩니다.

Change Manager는 조직 전반에 걸친 변경 사항, 의도 그리고 승인 및 구현한 사람을 보고하고 감사할 수 있는 일관된 방법을 제공합니다.

Change Manager는 AWS 리전 및 여러 AWS 계정에 걸쳐 작동합니다. Organizations 및 AWS SSO와 긴밀히 협력하여 중앙 지점에서 변경 사항을 관리하고 글로벌 인프라 전체에 걸쳐 제어된 방식으로 배포합니다.

용어
단일 AWS 계정에서 AWS Systems Manager Change Manager를 사용할 수도 있지만 대부분의 경우 다중 계정 구성에서 사용합니다.

여러 AWS 계정의 변경 사항을 관리하는 방법은 이러한 계정이 서로 연결되는 방식에 따라 다릅니다. Change Manager는 AWS Organizations에 정의된 계정 간의 관계를 사용합니다. Change Manager를 사용할 때 다음과 같은 세 가지 유형의 계정이 있습니다.

관리 계정 – “기본 계정” 또는 “루트 계정”이라고도 합니다. 관리 계정은 AWS Organizations 계층 구조의 루트 계정입니다. 이러한 사실만으로도 관리 계정입니다.
위임된 관리자 계정 — 위임된 관리자 계정은 Organizations의 다른 계정을 관리할 수 있는 권한이 부여된 계정입니다. Change Manager 컨텍스트에서 이 계정은 변경 요청이 시작되는 계정입니다. 일반적으로 이 계정에 로그인하여 템플릿 및 변경 요청을 관리합니다. 위임된 관리자 계정을 사용하면 루트 계정에 대한 연결을 제한할 수 있습니다. 또한 변경에 필요한 특정 권한 하위 집합을 사용하여 최소 권한 정책을 적용할 수 있습니다.
구성원 계정 – 구성원 계정은 관리 계정이나 위임된 관리자 계정이 아니지만 여전히 Organizations에 포함된 계정입니다. Change Manager에 대한 제 가상의 모델에서 변경 사항이 배포된 리소스를 보유하는 계정입니다. 위임된 관리자 계정이 구성원 계정의 리소스에 영향을 주는 변경 요청을 시작합니다. 시스템 관리자는 이러한 계정에 직접 로그인하지 않는 것이 좋습니다.

간단한 데모를 통해 AWS Systems Manager Change Manager를 사용하는 방법을 살펴보겠습니다.

일회성 구성
이 시나리오에서는 Organizations와 함께 연결된 여러 AWS 계정에서 Change Manager를 사용하는 방법을 보여 줍니다. 일회성 구성에 관심이 없는 경우 아래의 변경 요청 생성 섹션으로 이동하세요.

Change Manager를 사용하기 전에 수행할 4가지 일회성 구성 작업이 있습니다. 루트 계정의 작업 하나와 위임된 관리자 계정의 세 가지 작업입니다. 루트 계정에서 빠른 설정을 사용하여 위임된 관리자 계정을 정의하고 계정에 대한 사용 권한을 처음으로 구성합니다. 위임된 관리자 계정에서 사용자 ID 소스를 정의하고, 변경 템플릿을 승인할 권한이 있는 사용자를 정의하고, 변경 요청 템플릿을 정의합니다.

먼저 조직을 갖추고 있고 AWS 계정이 조직 구성 단위(OU)로 구성되어 있는지 확인합니다. 이 간단한 예의 목적을 위해 루트 계정, 관리 OU의 위임된 관리자 계정, 관리되는 OU의 구성원 계정의 세 가지 계정을 사용합니다. 준비가 되면 루트 계정에서 빠른 설정을 사용하여 계정을 구성합니다. 빠른 설정으로 갈 수 있는 경로에는 여러 개가 있습니다. 이 데모에서는 빠른 설치 콘솔 위에 파란색 배너를 사용하고 [Change Manager 설정](Setup Change Manager)을 클릭합니다.

빠른 설정 페이지에서 위임된 관리자 계정의 ID를 아직 정의하지 않은 경우 입력합니다. 그런 다음 저 대신 변경을 수행할 위임된 관리자 계정에 부여할 사용 권한 경계를 선택합니다. 이는 Change Manager가 변경하기 위해 받는 최대 권한입니다. 잠시 후에 변경 요청을 생성할 때 이 사용 권한 집합을 추가로 제한하겠습니다. 이 예에서는 모든 ec2 API를 호출할 수 있는 Change Manager 권한을 부여합니다. 이를 통해 Change Manager에 EC2 인스턴스와 관련된 변경 사항만 실행할 수 있는 권한을 효과적으로 부여할 수 있습니다.

화면 하단에서 변경 사항의 대상이 되는 계정 집합을 선택합니다. [전체 조직] 또는 [사용자 지정] 중에서 선택하여 하나 이상의 OU를 선택합니다.

잠시 후 빠른 설정 프로그램에서 AWS 계정 권한 구성을 완료하면 일회성 설정의 두 번째 부분으로 이동할 수 있습니다.

둘째, 위임된 관리자 계정으로 전환합니다. Change Manager에서 조직의 사용자를 어떻게 관리할지 묻습니다. 즉, AWS Identity and Access Management(IAM) 또는 AWS Single Sign-On을 사용할지 묻습니다? 승인자를 선택할 때 Change Manager에서 사용자 ID를 가져올 위치를 정의합니다. 이것은 일회성 구성 옵션입니다. Change Manager 설정 페이지에서 언제든지 이 구성을 변경할 수 있습니다.

셋째, 동일한 페이지에서 템플릿 검토에 대한 알림을 수신할Amazon Simple Notification Service(SNS) 주제를 정의합니다. 템플릿 승인자가 템플릿을 검토하고 승인할 수 있도록 템플릿을 생성하거나 수정할 때마다 이 채널에 알림이 전송됩니다. 또한 변경 템플릿을 승인할 수 있는 권한이 있는 IAM(또는 SSO) 사용자를 정의합니다. 자세한 내용은 잠시 후에 다루겠습니다.

필요에 따라 기존 AWS Systems Manager Change Calendar를 사용하여 마케팅 이벤트나 휴일 영업과 같이 변경 사항이 승인되지 않는 기간을 정의할 수 있습니다.

마지막으로 변경 템플릿을 정의합니다. 모든 변경 요청은 템플릿에서 생성됩니다. 템플릿은 변경 요청 승인자, 수행할 작업, 진행 상태 알림을 보내는 SNS 주제 등을 기반으로 모든 변경 요청에 대한 공통 파라미터를 정의합니다. 템플릿을 사용하기 전에 템플릿을 검토하고 승인할 수 있습니다. 다른 유형의 변경 사항을 처리하기 위해 여러 템플릿을 생성하는 것이 좋습니다. 예를 들어 표준 변경 사항에 대한 템플릿 하나와 Change Calendar를 재정의하는 긴급 변경에 대한 템플릿을 생성할 수 있습니다. 또는 다양한 유형의 자동화 런북(문서)에 대해 서로 다른 템플릿을 생성할 수 있습니다.

시작하는 데 도움이 되도록 “Hello World” 템플릿을 생성했습니다. 이를 시작점으로 사용하여 변경 요청을 생성하고 승인 흐름을 테스트할 수 있습니다.

언제든지 자신만의 템플릿을 생성할 수 있습니다. 시스템 관리자 팀에서 EC2 인스턴스를 자주 다시 시작한다고 가정해 보겠습니다. 하나 또는 여러 인스턴스를 다시 시작하기 위한 변경 요청을 생성할 수 있는 템플릿을 만들겠습니다. 위임된 관리자 계정을 사용하여 Change Manager 관리 콘솔로 이동한 다음 [템플릿 생성]을 클릭합니다.

간단히 말해 템플릿은 승인된 작업 목록, 알림을 보낼 위치 및 변경 요청을 승인할 수 있는 사용자를 정의합니다. 작업은 AWS Systems Manager 런북입니다. 긴급 변경 템플릿을 사용하면 변경 요청이 이전에 생성된 변경 일정을 무시할 수 있습니다. 런북 옵션(Runbook Options)에서 실행이 허용된 하나 또는 여러 개의 [런북](Runbook)을 선택합니다. 이 예에서는 [AWS AWS EC2RestartInstance] 런북을 선택합니다.

콘솔을 사용하여 템플릿을 생성하지만 템플릿은 내부적으로 YAML로 정의됩니다. 편집기 탭을 사용하거나 AWS Command Line Interface(CLI) 또는 API를 사용할 때 YAML을 편집할 수 있습니다. 즉, 나머지 인프라(코드 형식)와 마찬가지로 버전을 관리할 수 있습니다.

바로 아래에서 마크다운 형식으로 포맷된 텍스트를 사용하여 템플릿을 문서화합니다. 이 섹션에서는 템플릿의 정의 특성을 문서화하고 철회 절차와 같은 필요한 지침을 요청자에게 제공합니다.

해당 페이지 아래로 스크롤하고 [승인자 추가]를 클릭하여 승인자를 정의합니다. 승인자는 개별 사용자 또는 그룹일 수 있습니다. 승인자 목록은 템플릿 수준 또는 변경 요청 자체에서 정의됩니다. 또한 승인이 필요한 요청이 생성되면 승인자에게 알리기 위해 SNS 주제를 생성하도록 선택합니다.

모니터링 섹션에서, 활성 상태일 때 이 템플릿을 기반으로 한 변경 사항을 중지하고 롤백을 시작하는 경보를 선택합니다.

알림 섹션에서 다른 SNS 주제를 선택하거나 생성하여 이 템플릿의 상태가 변경될 때 알림을 받습니다.

완료되면 템플릿을 저장하고 검토를 위해 제출합니다.

템플릿을 사용하기 전에 검토하고 승인해야 합니다. 템플릿을 승인하기 위해 이전에 정의한 template_approver 사용자로 콘솔을 연결합니다. template_approver 사용자에게 개요 탭에 보류 중인 승인이 표시됩니다. 또는 템플릿 탭으로 이동하여 검토할 템플릿을 선택합니다. 검토가 끝나면 [승인]을 클릭합니다.

이제 이 템플릿을 기반으로 변경 요청을 생성할 수 있습니다. 앞의 모든 단계는 일회성 구성이며 언제든지 수정할 수 있습니다. 기존 템플릿을 수정하면 변경 사항이 검토 및 승인 프로세스를 다시 거치게 됩니다.

변경 요청 생성
Organization에 연결된 계정에 대한 변경 요청을 생성하려면 위임된 관리자 계정에서 AWS Systems Manager Change Manager 콘솔을 열고 [요청 생성](Create request)을 클릭합니다.

사용할 템플릿을 선택하고 [다음]을 클릭합니다.

이 변경 요청의 이름을 입력합니다. 모든 승인이 이루어진 직후에 변경이 시작됩니다. 또는 예약 시간(선택 사항)을 지정할 수 있습니다. 템플릿에서 허용하는 경우 이 변경에 대한 승인자를 선택합니다. 이 예에서 승인자는 템플릿에 의해 정의되며 변경할 수 없습니다. [다음]을 클릭합니다.

다음 화면에는 변경의 실제 실행과 관련된 여러 가지 중요한 구성 옵션이 있습니다.

대상 위치 — 이 변경을 실행할 대상 AWS 계정 및 AWS 리전을 정의할 수 있습니다.
배포 대상 — 이 변경의 대상이 되는 리소스를 정의할 수 있습니다. 하나의 EC2 인스턴스가 될 수도 있고, 태그, 리소스 그룹, 인스턴스 ID 목록으로 식별되는 여러 개가 될 수도 있으며, 모든 EC2 인스턴스가 될 수도 있습니다.
런북 파라미터 — 런북에 전달할 파라미터(있는 경우)를 정의할 수 있습니다.
실행 역할 — System Manager에 이 변경 사항을 배포하도록 부여하는 권한 집합을 정의할 수 있습니다. 권한 집합에는 신뢰 정책의 보안 주체로 changemanagement.ssm.amazonaws.com 서비스가 있어야 합니다. 역할을 선택하면 Change Manager 런타임에 내가 가진 권한 집합과 다른 권한 집합을 부여할 수 있습니다.

다음은 Change Manager가 EC2 인스턴스를 중지하도록 허용하는 예입니다(특정 AWS 계정, 특정 리전 또는 특정 인스턴스로 범위를 지정할 수 있음).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "*",
        },
        {
            "Effect": "Allow",
            "Action": [ "ec2:DescribeInstances"],
            "Resource": "*"
        }
    ]
}

그리고 관련된 신뢰 정책은 다음과 같습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "changemanagement.ssm.aws.internal"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

준비가 되면 [다음]을 클릭합니다. 마지막 페이지에서 데이터 입력을 검토하고 [승인을 위해 제출](Submit for approval)을 클릭합니다.

이 단계에서 승인자는 템플릿에 구성된 SNS 주제를 기반으로 알림을 받습니다. 이 데모를 계속하려면 콘솔에서 로그아웃하고 변경 요청을 보고 승인할 수 있는 권한을 가진 cr_approver 사용자로 다시 로그인합니다.

cr_approver 사용자로서 콘솔로 이동하여 변경 요청을 검토한 다음 [승인]을 클릭합니다.

변경 요청 상태가 예약됨으로 전환되고 결과적으로 녹색이 [성공]으로 바뀝니다. 언제든지 변경 요청을 클릭하여 상태를 가져오고 오류를 수집할 수 있습니다(있는 경우).

변경 요청을 클릭하여 세부 정보를 확인합니다. 특히 타임라인 탭에는 이 CR의 기록이 표시됩니다.

가용성 및 요금
AWS Systems Manager Change Manager는 현재 중국 본토를 제외한 모든 상용 AWS 리전에서 사용할 수 있습니다. 요금은 제출한 변경 요청 수와 총 API 호출 수의 두 가지 차원을 기준으로 합니다. 제출하는 변경 요청 수가 주요 비용 요인이 됩니다. 변경 요청당 0.29 USD의 요금이 부과됩니다. 자세한 내용은 요금 페이지를 확인하세요.

변경 요청을 한 날로부터 첫 30일 동안 Change Manager를 무료로 평가할 수 있습니다.

여느 때와 마찬가지로 어떻게 생각하는지를 알려주시고 바로 시작하시기 바랍니다.

— seb

Amazon Web Services 한국 블로그

새로운 기능 — AWS Systems Manager Change Manager 출시

주요 링크 모음

팔로우하기