AWS CDK を使用してクラウドインフラストラクチャを開発およびデプロイするためのベストプラクティス

ほとんどのベストプラクティスの指針となる原則は、物事をできるだけシンプルにすることですが、よりシンプルにすることはできません。要件によってより複雑なソリューションが必要となる場合のみ、複雑さを追加します。 AWS CDK を使用すると、新しい要件をサポートするために、必要に応じてコードをリファクタリングできます。考えられるすべてのシナリオを事前に設計する必要はありません。

AWS Well-Architected フレームワークは、コンポーネントを、要件に対して一緒に提供するコード、設定、 AWS リソースとして定義します。コンポーネントは多くの場合、技術的所有権の単位であり、他のコンポーネントとは切り離されています。ワークロードは、ビジネス価値を実現する一連のコンポーネントを特定するために使用します。ワークロードの詳細レベルは通常、ビジネスリーダーとテクノロジーリーダーが話し合いで決定します。

AWS CDK アプリケーションは、 AWS Well-Architected Framework で定義されているコンポーネントにマッピングされます。 AWS CDK アプリケーションは、 Well-Architected クラウドアプリケーションのベストプラクティスを体系化して提供するためのメカニズムです。 AWS CodeArtifact などのアーティファクトリポジトリを使用して、再利用可能なコードライブラリとしてコンポーネントを作成および共有することもできます。

1 つのパッケージは AWS CDK アプリのエントリポイントです。ここでは、アプリケーションのさまざまな論理ユニットをデプロイする方法と場所を定義します。また、アプリケーションをデプロイする CI/CD パイプラインも定義します。アプリのコンストラクトは、ソリューションの論理単位を定義します。

複数のアプリケーションで使用するコンストラクトには、追加のパッケージを使用します。(共有コンストラクトには、独自のライフサイクル戦略とテスト戦略も必要です)。同じリポジトリ内のパッケージ間の依存関係は、リポジトリのビルドツールによって管理されます。

これは可能ですが、特に自動デプロイパイプラインを使用する場合は、複数のアプリケーションを同じリポジトリに配置することはお勧めしません。そうすることは、デプロイ中の変更の「影響範囲」の増加につながります。リポジトリに複数のアプリケーションがある場合、1 つのアプリケーションへの変更は、他のアプリケーションのデプロイをトリガーします (他のアプリケーションが変更されていない場合でも）。さらに、あるアプリケーションが中断されると、他のアプリケーションまでデプロイされなくなります。

パッケージが複数のアプリケーションで使用を開始したら、独自のリポジトリに移動します。これにより、パッケージを使用するアプリケーションビルドシステムでパッケージを参照でき、アプリケーションのライフサイクルとは無関係にケイデンスで更新することもできます。ただし、最初は、すべての共有コンストラクトを 1 つのリポジトリに配置するのが理にかなっている場合があります。

また、異なるチームが作業している場合は、パッケージを独自のリポジトリに移動してください。これにより、アクセスコントロールを適用できます。

リポジトリの境界を越えてパッケージを使用するには、プライベートパッケージリポジトリが必要です。これは NPM、PyPi、Maven Central に似ていますが、組織内部にあります。また、パッケージを構築し、テストし、プライベートパッケージリポジトリに公開するリリースプロセスも必要です。CodeArtifact は、最も一般的なプログラミング言語のパッケージをホストできます。

パッケージリポジトリ内のパッケージの依存関係は、TypeScript または JavaScript アプリケーションの NPM など、言語のパッケージマネージャーによって管理されます。パッケージマネージャーは、ビルドが繰り返し可能であることを確認するのに役立ちます。これは、アプリケーションが依存するすべてのパッケージの特定のバージョンを記録することによって行われます。また、これらの依存関係を制御された方法でアップグレードすることもできます。

共有パッケージには別のテスト戦略が必要です。1 つのアプリケーションの場合、アプリケーションをテスト環境にデプロイし、変わらず動作することを確認するだけで十分かもしれません。しかし、共有パッケージは、あたかも一般に公開されているかのように、利用側アプリケーションとは独立してテストする必要があります。(組織は、実際に一部の共有パッケージを公開することを選択する場合があります)。

コンストラクトは、任意に単純にも複雑にもすることができることを念頭に置いてください。Bucket がコンストラクトであるように、CameraShopWebsite もまたコンストラクトである場合があります。

インフラストラクチャをデプロイするための AWS CloudFormation テンプレートの生成に加えて、 AWS CDK は Lambda 関数や Docker イメージなどのランタイムアセットをバンドルし、インフラストラクチャと一緒にデプロイします。これにより、インフラストラクチャを定義するコードとランタイムロジックを実装するコードを 1 つのコンストラクトにまとめることができます。これを行うのがベストプラクティスです。これら 2 種類のコードは、別々のリポジトリや別々のパッケージに存在する必要はありません。

2 種類のコードを一緒に進化させるには、インフラストラクチャやロジックなどの機能を完全に記述する自己完結型コンストラクトを使用できます。自己完結型コンストラクトを使用すると、2 種類のコードを個別にテストし、プロジェクト間でコードを共有して再利用し、すべてのコードを同期してバージョン化できます。

スタックはデプロイの単位です。スタック内のすべてのものが一緒にデプロイされます。したがって、アプリケーションの上位レベルの論理ユニットを複数の AWS リソースから構築する場合は、各論理ユニットをスタックとしてではなくコンストラクトとして表現します。スタックは、さまざまなデプロイシナリオに対してコンストラクトをどのように構成し、接続するかを説明するためにのみ使用します。

たとえば、論理ユニットの 1 つがウェブサイトである場合、それを構成するコンストラクト (Amazon S3 バケット、API ゲートウェイ、Lambda 関数、Amazon RDS テーブルなど) を 1 つの高レベルのコンストラクトに構成する必要があります。次に、そのコンストラクトをデプロイする 1 つ以上のスタックでインスタンス化する必要があります。

構築用のコンストラクトとデプロイ用のスタックを使用することで、インフラストラクチャの再利用の可能性が向上し、デプロイ方法の柔軟性が高まります。

コンストラクトやスタック内で環境変数を参照することは、一般的なアンチパターンとされています コンストラクトとスタックの両方は、コード内で完全な設定が可能となるように、プロパティオブジェクトを受け入れる必要があります。そうしないと、コードが実行されるマシンに依存関係が生じ、追跡および管理が必要な設定情報がさらに増えることになります。

一般的に、環境変数ルックアップは AWS CDK アプリの最上位レベルに制限する必要があります。また、開発環境で を実行するために必要な情報を渡すためにも使用する必要があります。詳細については、AWS 「CDK の環境」を参照してください。

すべての環境でビルド時にユニットテストのフルスイートを一貫して実行するには、合成中のネットワークルックアップを避け、コード内のすべての本番稼働段階をモデル化します。(これらのベストプラクティスについては、後で説明します)。1 つのコミットから常に同じテンプレートが生成されるのであれば、自分が作成したユニットテストを信頼して、生成されたテンプレートが想定どおりの形になっていることを確認できます 詳細については、AWS 「CDK アプリケーションのテスト」を参照してください。

リソースの論理 ID を変更すると、リソースは次回のデプロイ時に新しいリソースに置き換えられます。データベースや S3 バケットなどのステートフルリソース、または Amazon VPC などの永続的なインフラストラクチャの場合、これは通常望ましくない結果となります。ID が変更される可能性のある AWS CDK コードのリファクタリングには注意してください。ステートフルリソースの論理 ID が静的なままであることをアサートするユニットテストを作成してください。論理 ID は、コンストラクトをインスタンス化するときにid指定した と、コンストラクトツリー内のコンストラクトの位置から算出されます。詳細については、「論理 IDs」を参照してください。

多くのエンタープライズのお客様は、L2 コンストラクト (組み込みの正常なデフォルトとベストプラクティスを持つ個々の AWS リソースを表す「厳選された」コンストラクト) 用の独自のラッパーを記述しています。これらのラッパーは、静的暗号化や特定の IAM ポリシーなどのセキュリティのベストプラクティスを適用します。たとえば、通常の Amazon S3 Bucket コンストラクトの代わりにアプリケーションで使用する MyCompanyBucket を作成できます。このパターンは、ソフトウェア開発ライフサイクルの早い段階でセキュリティガイダンスを表示するのに役立ちますが、適用の唯一の手段としてそれに依存しないでください。

代わりに、サービスコントロールポリシーやアクセス許可の境界などの AWS 機能を使用して、組織レベルでセキュリティガードレールを適用します。Aspects や CloudFormation Guard などの AWS CDK またはツールを使用して、デプロイ前にインフラストラクチャ要素のセキュリティプロパティについてアサーションを行います。 CloudFormation 最善を尽くすには AWS CDK を使用します。

最後に、独自の「L2+」コンストラクトを記述すると、開発者がソリューションコンストラクトや AWS Construct Hub のサードパーティーコンストラクトなどの AWS CDK パッケージを利用できなくなる可能性があることに注意してください。これらのパッケージは通常、標準の AWS CDK コンストラクト上に構築されており、ラッパーコンストラクトを使用することはできません。

AWS CloudFormation ではデプロイ時に (Conditions、、および を使用してParameters) 決定を行うことができますが{ Fn::If }、 AWS CDK ではこれらのメカニズムにある程度アクセスできますが、使用しないことをお勧めします。使用できる値のタイプとそれらに対して実行できるオペレーションのタイプは、汎用プログラミング言語で利用できるものと比較して制限されます。

代わりに、プログラミング言語の ifステートメントやその他の機能を使用して、 AWS CDK アプリケーションでインスタンス化するコンストラクトなど、すべての決定を行います。たとえば、リストを反復処理し、リスト内の各項目の値を持つコンストラクトをインスタンス化する一般的な CDK イディオムは、 AWS CloudFormation 式を使用するだけでは不可能です。

Treat AWS CloudFormation は、言語ターゲットとしてではなく、 AWS CDK が堅牢なクラウドデプロイに使用する実装の詳細です。TypeScript または Python で AWS CloudFormation テンプレートを記述しておらず、デプロイに CloudFormation を使用する CDK コードを記述しています。

名前は貴重なリソースです。名前はそれぞれ 1 回のみ使用できます。したがって、テーブル名またはバケット名をインフラストラクチャとアプリケーションにハードコードした場合、そのインフラストラクチャを同じアカウントに 2 回デプロイすることはできません。（ここで説明する名前は、Amazon S3 バケットコンストラクトの bucketNameプロパティなど、 で指定された名前です）。

さらに悪いことに、置き換えが必要なリソースを変更することはできません。Amazon DynamoDB テーブルの KeySchema のように、プロパティがリソース作成時にしか設定できない場合、このプロパティは変更不可能です。このプロパティを変更するには、新しいリソースが必要です。　　　　　 ただし、真の意味での置き換えとするためには、新しいリソースが同じ名前を持つ必要があります。ただし、既存のリソースがその名前を使用している間は、同じ名前にすることはできません。

より適切な方法は、できるだけ指定する名前を少なくすることです。リソース名を省略すると、 AWS CDK は問題を発生させない方法でリソース名を生成します。たとえば、リソースとしてテーブルがあるとします。その後、生成されたテーブル名を環境変数として AWS Lambda 関数に渡すことができます。 AWS CDK アプリケーションでは、テーブル名を として参照できますtable.tableName。または、起動時に Amazon EC2 インスタンスに設定ファイルを生成するか、実際のテーブル名を AWS Systems Manager パラメータストアに書き込んで、アプリケーションがそこから読み取れるようにすることもできます。

必要な場所が別の AWS CDK スタックである場合は、さらに簡単です。1 つのスタックでリソースを定義し、別のスタックでそのリソースを使用する必要があると仮定すると、以下のようになります。

AWS CDK は、作成したものをすべて保持するポリシーをデフォルトで設定することで、データが失われないようにします。たとえば、データを含むリソース (Amazon S3 バケットやデータベーステーブルなど) のデフォルトの削除ポリシーは、スタックから削除されたときにリソースを削除しないことです。代わりに、リソースはスタックから切り離された状態になります。同様に、CDK のデフォルトはすべてのログを永続的に保持することです。実稼働環境では、これらのデフォルトにより、実際には必要のない大量のデータと、対応する AWS 請求がすぐに保存される可能性があります。

本番稼働用のリソースごとに、これらのポリシーをどうするかは慎重に検討し、適切に指定してください。アスペクトと AWS CDK を使用して、スタックの削除ポリシーとログ記録ポリシーを検証します。

アプリケーションが必要とするスタックの数には、確固たるルールはありません。通常、デプロイパターンに基づいて決定します。以下のガイドラインに留意してください。

決定論は、 AWS CDK のデプロイを成功させるための鍵です。 AWS CDK アプリは、特定の環境にデプロイされるたびに基本的に同じ結果になります。

AWS CDK アプリは汎用プログラミング言語で記述されるため、任意のコードを実行し、任意のライブラリを使用し、任意のネットワーク呼び出しを行うことができます。例えば、 AWS SDK を使用して、アプリの合成中に AWS アカウントからいくつかの情報を取得できます。そうすることで、認証情報のセットアップ要件が追加され、レイテンシーが増加し、cdk synth を実行するたびに、たとえわずかでも障害が発生する可能性があることを認識してください。

合成中に AWS アカウントまたはリソースを変更しないでください。アプリケーションの合成に副作用があってはなりません。インフラストラクチャの変更は、 AWS CloudFormation テンプレートが生成された後のデプロイフェーズでのみ行う必要があります。これにより、問題が発生した場合、 AWS CloudFormation は自動的に変更をロールバックできます。 AWS CDK フレームワーク内で簡単に変更できない変更を行うには、カスタムリソースを使用してデプロイ時に任意のコードを実行します。

厳密に読み取り専用の呼び出しでも、必ずしも安全とは限りません。ネットワークの呼び出しによって返される値が変更された場合にどうなるかを考慮してください。インフラストラクチャのどの部分に影響しますか? 既にデプロイされたリソースはどうなりますか? 以下は、値が突然変化して問題が発生する可能性がある 2 つの状況の例です。

これらの状況は、デプロイが成功してから数か月または数年後に AWSサイドチェンジが発生する可能性があるため、悪意がある可能性があります。デプロイが突然「理由もなく」失敗し、何をしたか、なぜそうしたかはとうの昔に忘れてしまっています。

幸い、 AWS CDK には、非決定的な値のスナップショットを記録するコンテキストプロバイダーと呼ばれるメカニズムが含まれています。これにより、将来の合成操作でも、最初にデプロイしたときとまったく同じテンプレートを生成できます。新しいテンプレートには、ユーザーがコードに加えた変更以外に変更はありません。コンストラクトの .fromLookup()メソッドを使用すると、呼び出しの結果は にキャッシュされますcdk.context.json。CDK アプリの今後の実行で同じ値が使用されるように、これを残りのコードとともにバージョン管理にコミットする必要があります。CDK Toolkit にはコンテキストキャッシュを管理するコマンドが含まれているため、必要に応じて特定のエントリを更新できます。詳細については、「コンテキスト値」と AWS 「CDK」を参照してください。

ネイティブ CDK コンテキストプロバイダーがない値 ( AWS または他の場所から) が必要な場合は、別のスクリプトを作成することをお勧めします。スクリプトは値を取得してファイルに書き込み、CDK アプリケーションでそのファイルを読み取る必要があります。スクリプトは、通常のビルドプロセスの一部としてではなく、保存された値を更新する場合のみ実行します。

AWS CDK コンストラクトライブラリのgrant()便利な方法を使用すると、最小限の範囲のアクセス許可を使用して、あるリソースへのアクセスを別のリソースに付与する AWS Identity and Access Management ロールを作成できます。たとえば、次のようなクエリを考えてみます。

amzn-s3-demo-bucket.grantRead(myLambda)

この 1 行は、Lambda 関数のロールにポリシーを追加します (これも自動的に作成されます）。そのロールとそのポリシーは CloudFormation の 12 行以上であり、記述する必要はありません。 AWS CDK は、関数がバケットから読み取るために必要な最小限のアクセス許可のみを付与します。

開発者がセキュリティチームによって作成された事前定義されたロールを常に使用する必要がある場合、 AWS CDK コーディングははるかに複雑になります。チームは、アプリケーションの設計方法における柔軟性を大幅に失う可能性があります。より良い代替策は、サービスコントロールポリシーとアクセス許可の境界を使用して、開発者がガードレール内に留まるようにすることです。

従来の AWS CloudFormation シナリオでは、パラメータ化された単一のアーティファクトを生成して、それらの環境に固有の設定値を適用した後にさまざまなターゲット環境にデプロイできるようにすることが目的です。CDK では、その設定をソースコードに組み込むことができ、またそうすることが必要です。本番環境用のスタックを作成し、他のステージごとに個別のスタックを作成します。次に、各スタックの設定値をコードに入れます。Secrets Manager や Systems Manager Parameter Store などのサービスは、これらのリソースの名前または ARNs を使用して、ソース制御にチェックインしたくない機密値に使用します。

アプリケーションを合成すると、cdk.out フォルダに作成されたクラウドアセンブリには、環境ごとに個別のテンプレートが含まれます。ビルド全体は確定的です。アプリケーションにout-of-bandの変更はなく、特定のコミットによって常にまったく同じ AWS CloudFormation テンプレートとそれに伴うアセットが生成されます。これにより、ユニットテストの信頼性が向上します。

人間の介入なしで完全な継続的デプロイの目標を達成するには、高度な自動化が必要です。この自動化を可能にするには、大量のモニタリングが必要になります。デプロイされたリソースのすべてのアスペクトを測定するには、メトリクス、アラーム、ダッシュボードを作成します。CPU 使用率やディスク容量などの測定を止めないでください。また、ビジネスメトリクスを記録し、これらの測定値を使用して、ロールバックなどのデプロイの決定を自動化します。 AWS CDK の L2 コンストラクトのほとんどには、 dynamodb.Table クラスの メソッドなど、メトリクスの作成に役立つ便利なmetricUserErrors()メソッドがあります。