AWS CloudFormation の新機能 — 障害ポイントからスタックオペレーションをすばやく再試行する

この記事は、Danilo Poccia による寄稿の New for AWS CloudFormation – Quickly Retry Stack Operations from the Point of Failure を翻訳したものです。

クラウドコンピューティングの大きな利点の 1 つは、プログラム可能なインフラストラクチャにアクセスできることです。これにより、Infrastructure as Code を管理し、インフラストラクチャのプロビジョニングに同じアプリケーションコード開発のプラクティスを適用できます。

AWS CloudFormation は、関連する AWS およびサードパーティーのリソースのコレクションをモデル化し、それらを迅速かつ一貫してプロビジョニングし、ライフサイクル全体を通じて管理するための簡単な方法を提供します。CloudFormation テンプレートは、目的のリソースとその依存関係を記述し、それらをスタックとしてまとめて起動して設定できるようにします。テンプレートを使用して、リソースを個別に管理するのではなく、スタック全体を 1 つのユニットとして作成、更新、および削除できます。

スタックを作成または更新すると、さまざまな理由でアクションが失敗することがあります。例えば、テンプレート内に、またはテンプレートのパラメータ内にエラーがある場合や、AWS Identity and Access Management (IAM) のアクセス許可エラーなど、テンプレート外に問題がある場合があります。このようなエラーが発生すると、CloudFormation はスタックを以前の安定した状態にロールバックします。スタックの作成では、それはエラーのポイントまでに作成されたすべてのリソースを削除することを意味します。スタックの更新では、それは以前の設定を復元することを意味します。

この以前の状態へのロールバックは、本番環境では最適ですが、エラーの理由を理解することは容易ではありません。テンプレートの複雑さと関連するリソースの数によっては、適切な設定でテンプレートを更新してオペレーションを再試行する前に、すべてのリソースがロールバックされるまで多くの時間を費やすことがあります。

本日、CloudFormation では、自動ロールバックを無効にし、エラーが発生する前にリソースを正常に作成または更新されるように維持し、障害のポイントからスタックオペレーションを再試行できるようになったことをお知らせでき、大変嬉しく思います。このようにして、エラーを迅速に反復処理して修正および修復し、開発環境で CloudFormation テンプレートをテストするのに必要な時間を大幅に短縮できます。スタックの作成の際、スタックの更新の際、および変更セットの実行の際に、この新しい機能を適用できます。以降のセクションでは、どのように機能するかを見てみましょう。

CloudFormation スタックの修正と修復を迅速に反復処理する
いずれかのアプリケーションでは、 Amazon Simple Storage Service (Amazon S3) バケット、Amazon Simple Queue Service (SQS) キュー、およびAmazon Kinesis データストリームへのアイテムレベルの変更をストリーミングしている Amazon DynamoDB テーブルをセットアップする必要があります。この設定では、CloudFormation テンプレートの最初のバージョンを書き留めます。

AWSTemplateFormatVersion: "2010-09-09"
Description: 修正および修復するためのサンプルテンプレート
Parameters:
  ShardCount パラメータ:
    Type: Number
    Description: Kinesis ストリームのシャードの数
Resources:
  MyBucket:
    Type: AWS::S3::Bucket
  MyQueue:
    Type: AWS::SQS::Queue
  MyStream:
    Type: AWS::Kinesis::Stream
    Properties:
      ShardCount: !Ref ShardCountParameter
  MyTable:
    Type: AWS::DynamoDB::Table
    Properties:
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: "ArtistId"
          AttributeType: "S"
        - AttributeName: "Concert"
          AttributeType: "S"
        - AttributeName: "TicketSales"
          AttributeType: "S"
      KeySchema:
        - AttributeName: "ArtistId"
          KeyType: "HASH"
        - AttributeName: "Concert"
          KeyType: "RANGE"
      KinesisStreamSpecification:
        StreamArn: !GetAtt MyStream.Arn
Outputs:
  BucketName:
    Value: !Ref MyBucket
    Description: S3 バケットの名前
  QueueName:
    Value: !GetAtt MyQueue.QueueName
    Description: SQS キューの名前
  StreamName:
    Value: !Ref MyStream
    Description: Kinesis ストリームの名前
  TableName:
    Value: !Ref MyTable
    Description: DynamoDB テーブルの名前

ここで、このテンプレートからスタックを作成したいと思います。CloudFormation コンソールで、[スタックの作成] を選択します。次に、テンプレートファイルをアップロードし、[次へ] を選択します。

スタックの名前を入力します。次に、スタックのパラメータを入力します。テンプレートファイルには、Kinesis データストリームのシャード数を設定するために使用される 1 つのパラメータ (ShardCountParameter) があります。シャードの数は 1 以上でなければならないことはわかっていますが、間違えてゼロを入力して [次へ] を選択します。

スタック内のリソースを作成、変更、または削除するには、IAM ロールを使用します。このようにして、CloudFormation がスタックオペレーションに使用できるアクセス許可には明確な境界があります。また、同じロールを使用して、標準化された再現可能な環境でスタックのデプロイを後で自動化することもできます。

[アクセス許可] で、スタックオペレーションに使用する IAM ロールを選択します。

これで、新機能を使う時となりました！ [スタック失敗] オプションで、[正常にプロビジョニングされたリソースを保持] を選択して、エラーが発生した場合にすでに作成されたリソースを維持します。障害が発生したリソースは、常に最後の既知の安定な状態にロールバックされます。

その他のオプションはすべてデフォルトのままにして、[次へ] を選択します。次に、設定を確認し、[スタックを作成] を選択します。

スタックの作成は数秒間進行中であり、エラーのために失敗します。[イベント] タブで、イベントのタイムラインを確認します。スタックの作成の開始が一番下にあります。最新のイベントは一番上にあります。シャード数 (ShardCount) が最小値を下回っているため、ストリームリソースのプロパティの検証に失敗しました。このため、スタックは CREATE_FAILED ステータスになりました。

プロビジョニングされたリソースを保持することを選択したので、エラーの前に作成されたすべてのリソースはまだ残っています。[リソース] タブでは、S3 バケットと SQS キューは CREATE_COMPLETE ステータスになり、Kinesis データストリームは CREATE_FAILED ステータスになります。DynamoDB テーブルの作成は、テーブルがプロパティの 1 つ (KinesisStreamSpecification) でデータストリームを使用するため、利用可能な Kinesis データストリームによって異なります。その結果、テーブルの作成はまだ開始されておらず、テーブルはリストに含まれていません。

ロールバックが一時停止されており、いくつかの新しいオプションがあります。

Retry – スタックオペレーションを変更せずに再試行します。このオプションは、テンプレート外の問題によりリソースのプロビジョニングに失敗した場合に便利です。問題を解決してから、障害のポイントから再試行できます。

Update – スタックの作成を再試行する前に、テンプレートまたはパラメータを更新します。スタックの更新は、最後のオペレーションがエラーによって中断された場所から開始されます。

Rollback – 最後の既知の安定な状態にロールバックします。これは、デフォルトの CloudFormation の動作に似ています。

パラメーターの問題を修正する
シャード数のパラメータ入力中に行った間違いにすぐに気付いたので、Update を選択します。

このエラーを修正するためにテンプレートを変更する必要はありません。 パラメータで、以前のエラーを修正し、シャード数の正しい量 (1 シャード) を入力します。

その他のオプションはすべて現在の値のままにして、[次へ] を選択します。

変更セットのプレビューで、更新が Kinesis ストリーム (現在 CREATE_FAILED ステータス) を変更し、DynamoDB テーブルを追加しようとすることがわかります。他の設定を確認し、[スタックを更新] を選択します。

これで更新が進行中です。すべての問題は解決しましたか? まだです。しばらくすると、更新は失敗します。

テンプレート外の問題を修正する
Kinesis ストリームが作成されましたが、CloudFormation が引き受ける IAM ロールには DynamoDB テーブルを作成する権限がありません。

IAM コンソールで、DynamoDB テーブルを作成できるように、スタックオペレーションで使用されるロールに権限を追加します。

CloudFormation コンソールに戻り、[再試行] オプションを選択します。新しい権限を使用すると、DynamoDB テーブルの作成が開始されますが、しばらくすると別のエラーが発生します。

テンプレート内の問題を修正する
今回は、DynamoDB テーブルを定義するテンプレートにエラーがあります。AttributeDefinitions セクションには、スキーマで使用されていない属性 (TicketSales) があります。

DynamoDB では、テンプレートで定義された属性は、プライマリキーまたはインデックスのいずれかに使用する必要があります。テンプレートを更新し、TicketSales 属性定義を削除します。

テンプレートを編集しているため、MinValue プロパティと MaxValue プロパティをシャード数パラメータ (ShardCountParameter) に追加することもできます。このようにして、CloudFormation はデプロイを開始する前に値が正しい範囲内にあるかどうかをチェックでき、それ以上の間違いを回避できます。

[更新] オプションを選択します。現在のテンプレートを更新することを選択し、新しいテンプレートファイルをアップロードします。パラメータの現在の値を確認します。次に、他のすべてのオプションを現在の値のままにして、[スタックを更新] を選択します。

今回は、スタックの作成は成功し、ステータスは UPDATE_COMPLETE です。[リソース] タブにすべてのリソースが表示され、その説明 (テンプレートの [出力] セクションに基づく) が [出力] タブに表示されます。

テンプレートの最終バージョンは次のとおりです。

AWSTemplateFormatVersion: "2010-09-09"
Description: 修正および修復するためのサンプルテンプレート
Parameters:
  ShardCount パラメータ:
    Type: Number
    MinValue: 1
    MaxValue: 10
    Description: Kinesis ストリームのシャードの数
Resources:
  MyBucket:
    Type: AWS::S3::Bucket
  MyQueue:
    Type: AWS::SQS::Queue
  MyStream:
    Type: AWS::Kinesis::Stream
    Properties:
      ShardCount: !Ref ShardCountParameter
  MyTable:
    Type: AWS::DynamoDB::Table
    Properties:
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: "ArtistId"
          AttributeType: "S"
        - AttributeName: "Concert"
          AttributeType: "S"
      KeySchema:
        - AttributeName: "ArtistId"
          KeyType: "HASH"
        - AttributeName: "Concert"
          KeyType: "RANGE"
      KinesisStreamSpecification:
        StreamArn: !GetAtt MyStream.Arn
Outputs:
  BucketName:
    Value: !Ref MyBucket
    Description: S3 バケットの名前
  QueueName:
    Value: !GetAtt MyQueue.QueueName
    Description: SQS キューの名前
  StreamName:
    Value: !Ref MyStream
    Description: Kinesis ストリームの名前
  TableName:
    Value: !Ref MyTable
    Description: DynamoDB テーブルの名前

これは簡単な例でしたが、障害のポイントからスタックオペレーションを再試行する新機能により、すでに多くの時間を節約しました。これにより、問題を迅速に修正して修復し、フィードバックループを減らし、同じ時間内に実行できる反復処理の回数を増やすことができました。デバッグにこれを使用するだけでなく、テンプレートのインクリメンタルなインタラクティブ開発にも最適です。より洗練されたアプリケーションでは、時間の節約は膨大になります！

AWS CLI を使用した CloudFormation スタックの修正と修復
スタックの作成、スタックの更新、または変更セットの実行時に--disable-rollback オプションを指定することで、AWS コマンドラインインターフェイス (CLI) で正常にプロビジョニングされたリソースを保持できます。以下に例を示します。

aws cloudformation create-stack --stack-name my-stack \
    --template-body file://my-template.yaml -–disable-rollback
aws cloudformation update-stack --stack-name my-stack \
    --template-body file://my-template.yaml --disable-rollback
aws cloudformation execute-change-set --stack-name my-stack --change-set-name my-change-set \
    --template-body file://my-template.yaml --disable-rollback

既存のスタックの場合、DisableRollback プロパティが describe スタックコマンドで有効になっているかどうかを確認できます。

aws cloudformation describe-stacks --stack-name my-stack

CREATE_FAILED または UPDATE_FAILED ステータスでスタックを更新できるようになりました。CREATE_FAILED または UPDATE_FAILED ステータスにあるスタックをマニュアルでロールバックするには、新しいロールバックスタックコマンドを使用します。

aws cloudformation rollback-stack --stack-name my-stack

利用可能なリージョンと料金
AWS CloudFormation が障害のポイントからスタックオペレーションを再試行できる機能は、次の AWS リージョンでは追加料金なしで利用できます: 米国東部 (バージニア北部、オハイオ州)、米国西部 (オレゴン、北カリフォルニア)、AWS GovCloud (米国東部、米国西部)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム)、アジアパシフィック (香港、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、中東 (バーレーン)、アフリカ (ケープタウン)、南米 (サンパウロ)。

JavaScript、TypeScript、Python、Java、C#、Go などの使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースを定義したいですか？ ここで、嬉しいお知らせです! AWS Cloud Development Kit (AWS CDK) チームは、今後数週間でこの記事で説明されている新機能のサポートを追加する予定です。

障害のポイントからスタックオペレーションを再試行する新機能により、CloudFormation スタックの修正と修復に費やす時間を短縮できます。

— Danilo

原文はこちらです。