Amazon Web Services ブログ

AWS Systems Manager Change Manager のご紹介

皆様の元には、お客様からのフィードバックが日常的に届いていることでしょう。それを基に、アプリケーションやインフラストラクチャをくり返し修正し、イノベーションのための改善をされていると思います。クラウドに置いた IT システムの変更は継続的なものです。ただ、現実を見てみると、稼働中のシステムで何かを変えることは、何かを壊すことでもあります。この結果、時には予測できない副作用を引き起こす危険があるのです。テストを何回行ったのかは重要ではありません。一方、変化を加えないということは停滞を意味します。その後に続くのは的外れのサービス提供、そして、その終了という結末です。

そのため、あらゆる規模とタイプの組織が、変更を上手に継続するための文化を、内部に醸成しています。一部の組織では、ITIL v4 で定義されている変更管理プロセスなどのシステムを採用しています。DevOps や、継続的デプロイを導入していたり、他の方法を採用している組織も存在します。いずれの場合にしても、変更管理プロセスを上手く運用するのに大切なのは、ツールを用意することです。

今回、AWS Systems Managerの新しい変更管理機能である、AWS Systems Manager Change Manager がリリースされました。このサービスにより、アプリケーションの構成やインフラストラクチャに対し運用エンジニアが行う、運用的な変更の追跡、承認、実装が簡素化されます。

Change Manager の使用には、主に 2 つの利点があります。第 1 の利点は、アプリケーションの構成やインフラストラクチャに加えられた変更の安全性を向上させ、サービスの中断のリスクを軽減することです。変更内容を追跡し、承認されたもののみが実装されるようにすることで、運用的な変更をより安全に実施できます。第 2 の利点は、AWS Organizations や AWS Single Sign-On などの他の AWS のサービスと緊密に統合されていることです。さらに、Systems Manager の変更カレンダーや Amazon CloudWatch アラームとも連携しています。

Change Manager では、組織全体で行われた変更、その目的、それらを承認および実施した人物などについて一貫性のある監査を行いレポートを作成することで、変更に対する責任を担保できます。

Change Manage は、AWS リージョン間、あるいは、複数の AWS アカウント間で機能します。Organizations、あるいは、AWS SSO と緊密に連携しているので、一元的なポイントからの変更の管理や、グローバルインフラストラクチャ全体に対する制御された方法でのデプロイが可能になります。

関連用語
AWS Systems Manager Change Manager は、単一の AWS アカウントで使用可能ですが、ほとんどの場合は、マルチアカウント設定で使用します。

複数の AWS アカウント間で変更を管理する方法は、これらのアカウントが相互にリンクされている形式によって異なります。Change Manager は、AWS Organizationsで定義されているアカウントの相互関係を参照して動作ます。Change Manager を使用する場合には、次のような 3 タイプのアカウントが関係してきます。

  • 管理アカウント – これは、「メインアカウント」 または 「ルートアカウント」とも呼ばれます。 管理アカウントは、AWS Organizations の階層構造におけるルートアカウントであり、そのため、管理を行うアカウントとなります。
  • 委任された管理者アカウント – 委任された管理者アカウントは、Organizations 内の他のアカウントを管理するためのアクセス権限が付与されたアカウントです。Change Manager の文脈では、このアカウントは、変更リクエストの開始元となるアカウントのことです。通常、テンプレートや変更リクエストの管理を行うユーザーは、このアカウントにログインします。委任された管理者アカウントを使用することで、ルートアカウントへの接続頻度を制限できます。また、変更に必要なアクセス権限を特定のサブセットにより定義することで、最小権限ポリシーを確立することもできます。
  • メンバーアカウント – メンバーアカウントは、含まれているOrganizations は同じですが、管理アカウントまたは委任された管理者アカウントではないアカウントを指します。Change Manager の考え方では、変更がデプロイされるべきリソースを保持するアカウントが、これらのアカウントになります。メンバーアカウントのリソースに影響を与える変更リクエストは、委任された管理者アカウントで開始されることになります。システム管理者が、メンバーアカウントに直接ログインすることは推奨されません。

それでは、簡単な解説用のデモにより、AWS Systems Manager Change Manager の使用方法を見ていくことにしましょう。

ワンタイム設定
ここでは、Organizations により相互にリンクされた複数の AWS アカウントで、Change Manager を使用するシナリオについて説明します。ワンタイム設定について知る必要がない方は、以降に示す変更リクエストの作成セクションに飛んでください。

Change Manager を使用する前に、ルートアカウントで 1 つ、委任された管理者アカウントで 3 つの合計 4 つの設定アクションを、それぞれ 1 回だけ実行する必要があります。ルートアカウントでは、クイックセットアップを使用して、委任された管理者アカウントを定義します。必要なアカウントへのアクセス許可は、初期状態で付与しておきます。委任された管理者アカウントでは、ユーザー ID のソース、変更テンプレートを承認するアクセス許可を持つユーザー、および変更リクエストのテンプレートを、それぞれ定義します。

まず、組織が存在すること、そして、AWS アカウントが組織単位 (OU) の中で編成されていることを確認します。ここでは、簡単なサンプルを示すために、次のような 3 つのアカウントだけを作成しています。それらは、ルートアカウント、管理 OU 内の委任された管理者アカウント、管理対象となる OU のメンバーアカウントです。準備ができたら、ルートアカウントでクイックセットアップを使用して、それぞれのアカウントを設定します。クイックセットアップを開くには複数の方法がありますが、このデモでは、クイックセットアップコンソールの上部にある青いバナーから、[Setup Change Manager (Change Manager を設定)] をクリックします。

Change Manager のクイックセットアップ

 

Quick Setup (クイックセットアップ) ページが開いたら、(まだ定義していない場合は) 委任された管理者アカウントの ID を入力します。次に、自分の代わりに変更を実行させるため、委任された管理者アカウントに付与すべきアクセス許可の境界を選択します。この段階では、変更を行うための最大限の許可が、Change Manager に付与されます。このアクセス許可セットをさらに制限するための設定は、変更リクエストを作成するときに数分で作成できます。今回の例では、任意の ec2 API を呼び出すためアクセス許可を、Change Manager に付与します。これにより、EC2 インスタンスに関連する変更のみを Change Manager が実行するように確実に許可できます。

Change Manager のクイックセットアップ

画面の下で、変更の対象となるアカウントのセットを選択します。[Entire organization (組織全体)] または [Custom (カスタム)] のいずれかを選択し、OU が 1つであるか複数であるかを指定します。

Change Manager のクイックセットアップ 2

しばらくすると、クイックセットアップによる AWS アカウントのアクセス許可の設定が完了します。これで、ワンタイム設定の第 2 段階に移行できます。

Change Manager のクイックセットアップ 3

次に、委任された管理者アカウントでの作業に移ります。組織のユーザーを管理する方法を、AWS Identity and Access Management (IAM)、もしくは AWS Single Sign-On のどちらにするか、Change Manager が尋ねて来ます。 この設定では、選択された承認者のユーザー ID を取得する場所を、Change Manager に対し定義します。これは、ワンタイム設定用のオプションで、Change Manager の Settings (設定) ページで、いつでも変更することができます。

Change Manager Settings ページ

次に、この同じページで、テンプレートのレビューに関する通知を受信するための、Amazon Simple Notification Service (SNS) トピックを定義します。このチャネルは、テンプレートが作成または変更されるたびに通知されます。これを受けた承認者は、テンプレートのレビューと承認を行います。さらに、変更用のテンプレートを承認する権限を付与しながら、IAM (または SSO) ユーザーを定義します (これらの詳細についても 1 分ほどで終了します) 。

Change Manager の Template Reviewers ページ

必要に応じ、既存の AWS Systems Manager 変更カレンダーを使用することで、マーケティングイベント中や祝日セール中などの、変更が承認されない期間を定義できます。

最後に、変更用テンプレートを定義します。すべての変更リクエストはテンプレートを基に作成されます。変更リクエストの承認者、実行すべきアクション、進捗状況を通知する SNS トピックなどは、すべての変更リクエストに共通のパラメータとして、テンプレートにの中に定義されます。テンプレートを使用する前に、そのテンプレートについての確認と承認を、強制的に行わせることができます。異なるタイプの変更を処理するために、複数のテンプレートを作成することは理にかなっています。たとえば、標準の変更用に 1 つのテンプレートを作成しておき、緊急時に変更カレンダーを上書きするテンプレートを、別にもう 1 つ作成します。または、Automation Runbook (ドキュメント) の種類ごとに異なるテンプレートを作成できます。

ここでは、使用を開始していただく方のために、“Hello World” というテンプレートを作成しました。このテンプレートは、変更リクエストを作成し、承認フローをテストするための、開始点としてご使用いただけます。

いつでも、独自のテンプレートを作成していただくことができます。たとえば、システム管理者チームが、頻繁に EC2 インスタンスを再起動しているとします。このような場合は、テンプレートを記述することで、1 つまたは複数のインスタンスを再起動するための変更リクエストを作成させることができます。委任された管理者アカウントから、Change Manager の管理コンソールに移動し、[Create template (テンプレートを作成)] をクリックします。

Change Manager コンソールの テンプレートの作成

簡単に言えば、テンプレートでは、承認されたアクション、通知の送信先、変更リクエストを承認できるユーザーに関するリストが定義されています。アクションとは、AWS Systems Managerの Runbook のことです。ここで、emergency change templates (緊急変更テンプレート)に [Yes] を選択すると、変更リクエストは、先に記述した変更カレンダーをバイパスするようになります。[Runbook Options (Runbook オプション)] から、実行を許可する Runbook を 1 つまたは複数選択します。この例では、AWS EC2RestartInstance という Runbook を選択しています。

コンソールを使用してテンプレートを作成しますが、テンプレートは内部的に YAML として定義されています。YAML を編集するには、[Editor (エディタ)] タブを使用するか、AWS コマンドラインインターフェイス (CLI) または API を使用します。これは、インフラストラクチャの他の部分と同じように、(コードを記述することで) バージョン管理できることを意味します。Change Manager 作成テンプレートパート 1

次に、マークダウン形式で記述されたテキストによるテンプレートを示します。このセクションを使用して、テンプレートに定義すべき特性を記述します。このドキュメントでは、変更のリクエスト元に伝える必要がある手順 (取り消し手順など) を指定できます。

Change Manager テンプレートの記述

ページを下にスクロールし、[Add Approver (承認者の追加)] をクリックして承認者を定義します。個々のユーザーまたはグループを、承認者として定義できます。承認者のリストは、テンプレートレベルで定義するか、変更リクエスト自体で定義します。さらに、承認が必要なリクエストが作成されたときにそれを承認者に通知するための、SNS トピックの作成を選択します。

[Monitoring (モニタリング)] セクションがアクティブになっている場合には、このテンプレートに基づいて変更を停止しロールバックを開始させるアラームを選択します。

[Notifications (通知)] セクションでは、このテンプレートの状態が変更されたときに通知を受け取れるようにするため、既存の SNS トピックを選択するか、新しいトピックを作成します。

Change Manager のテンプレートの作成パート 2

完了したら、テンプレートを保存してレビュー用に送信します。

Change Manager のレビュー用テンプレートの送信

テンプレートは、その使用前にレビューと承認が必要です。テンプレートを承認するには、先に定義してある template_approver ユーザーとしてコンソールに接続します。template_approver ユーザーの [Overview (概要)] タブで、保留中の承認を確認します。または、[Templates (テンプレート)] タブに移動し、レビューするテンプレートを選択します。レビューが完了したら、[Approve (承認) ] をクリックします。

Change Manager のテンプレートの承認

これで、このテンプレートに基づいて変更リクエストを作成する準備ができました。上記の手順はすべて 1 回限りの設定であり、いつでも修正できることは銘記しておいてください。既存のテンプレートが変更されるたびに、変更内容のレビューと承認のプロセスが再実行されます。

変更リクエストの作成
組織にリンクされているアカウントに対し変更リクエストを作成するには、委任された管理者アカウントから AWS Systems Manager Change Manager コンソールを開き、[Create request (リクエストの作成)] をクリックします。

Change Manager のリクエストの作成

使用するテンプレートを選択し、[Next (次へ)] をクリックします。

Change Manager のテンプレートの選択この変更リクエストの名前を入力します。変更は、すべてのリクエストが承認された直後に開始されます。あるいは、オプションでスケジュールされた時刻を指定することもできます。テンプレートで許可されている場合には、この変更の承認者を選択します。この例では、承認者はテンプレートによって定義されており変更できません。[Next (次へ) ] をクリックします。

Change Manager の CR の作成パート 1

次の画面には、変更を実際に実行する際に関連してくる、構成上の重要なオプションが複数表示されます。

  • ターゲットの場所 – 変更を実行するターゲット AWS アカウントと AWS リージョンを定義できます。
  • デプロイターゲット – 変更のターゲットとなるリソースを定義できます。対象は 1 つの EC2 なのか、 あるいは、タグで識別される複数のインスタンスなのかの選択に加え、含まれるリソースグループごとか、インスタンス ID のリストを参照するか、全 EC2 インスタンスが対象なのか、などにより指定できます。
  • Runbook パラメータ – Runbook にパラメータを渡したい場合は、それを定義します。
  • 実行ロール – この変更をデプロイするシステムマネージャに付与するアクセス許可のセットを定義できます。アクセス許可のセットには、信頼ポリシーのプリンシパルとして、サービス 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"
    }
  ]
}

準備ができたら、[Next (次へ) ] をクリックします。最後のページで、入力したデータを確認し、[Submit for approval (承認のために送信する)] をクリックします。

この段階で、承認者は、テンプレートで設定された SNS トピックに基づいて通知を受信します。このデモを続けるには、一度コンソールからサインアウトし、変更リクエストを表示および承認する権限が付与された (先に作成済みの) cr_approver ユーザーとして、再度サインインします。

cr_approver ユーザーとして、コンソールに移動し、変更リクエストをレビューした上で、[Approve (承認)] をクリックします。

Change Manager の変更リクエストのレビュー

変更リクエストのステータスが Scheduled に変化した後、最終的に緑色の Success に切り替わります。変更リクエストをクリックすれば、いつでもステータスを取得し、エラー内容を収集できます。

リクエストが成功した Change Manager のダッシュボード

各変更リクエストをクリックすると、その詳細が表示されます。特に、[Timeline (タイムライン)] タブには、この CR の履歴が表示されます。

変更管理の CR タイムライン

利用可能なリージョンと料金
AWS Systems Manager Change Manager は、現在、中国本土を除くすべての商用 AWS リージョンでご利用いただけます。使用料金は、送信した変更リクエストの数と、実行された API 呼び出しの合計数という、2 つのディメンションに基づき決定されます。送信した変更リクエストの数が、主な料金決定のファクタです。変更リクエストごとに 0.29 USD が課金されます。詳細については、価格体系のページを参照してください。

Change Manager は、最初の変更リクエストから 30 日間無料でご試用いただけます。

いつものように、お客様からのお声をお待ちしております。早速、この機能をお試しください。

– seb