本連載では、以下のイメージの構成にあるAWSリソース基盤自動化環境の構築を実践しています。
前回は、バックエンドサブネットからのアクセスを想定したRDS(RelationalDatabaseService)を構築するCloudFormationテンプレートを実装しました。続く今回は、DynamoDBを構築するテンプレートを作成します。
なお、実際のソースコードはGitHub上にコミットしています。以降のソースコードでは本質的でない記述を一部省略しているので、実行コードを作成する場合は、必要に応じて適宜GitHub上のソースコードも参照してください。
DynamoDBスタック構築テンプレート
DynamoDBは連載「AWSで作るクラウドネイティブアプリケーションの基本」の第16回で実施した要領と同等のものを構築します。と言っても、CloudFormationで構築する場合、リソースタイプが「AWS::DynamoDB::Table」となるテーブル定義を作成するだけです。プロパティとして設定可能な属性は、各リンク先の通りですが、加えて、Conditions要素を使って、DynamoDBを商用環境、ステージング環境、開発環境という3つのパターンに分けて作成するようにします。
前回のRDSでは、Conditionsを定義した上で、Resources配下にCondition要素を設定することにより、各パターンごとに切り替えて作成しましたが、今回はConditions定義と条件関数を使って、作成するリソースを切り替えるかたちで実装してみます。
Conditionプロパティと条件関数の使い分け
Conditionプロパティによって有効化された条件に応じてリソースの生成を切り替える方法と、今回のように条件関数を使う方法は、いずれもConditionsで記載した条件によって生成するリソース定義を切り替えるものですが、双方メリット/デメリットがあります。
前者のConditionプロパティによる切り替えは、シンプルでわかりやすい反面、重複した定義が比較的多く出現する点がデメリットです。後者の条件関数による方法は最小限の記述でリソース定義を切り替えることが可能ですが、条件の数が多くなってくるとテンプレートに記述する条件式が複雑になり可読性が低下します。適宜状況に応じて、使い分けるようにしましょう。
なお、2019年の7月から、複数のプログラム言語でCloudFomationテンプレートを生成するAWSクラウド開発キット(AWS CDK)がGA(Generally Available)となっています。条件に応じた複雑な記述はこうしたツールキットを利用したほうが、より高い可読性を得られます。AWS CDKの使用方法については、別の機会で触れたいと思います。
テンプレートのサンプルは以下の通りです。
AWSTemplateFormatVersion: '2010-09-09'
// omit
Parameters:
// omit
EnvType: #(A)
Description: Which environments to deploy your service.
Type: String
AllowedValues: ["Dev", "Staging", "Production"]
Default: Dev
Conditions: #(B)
ProductionResources: {"Fn::Equals" : [{"Ref":"EnvType"}, "Production"]}
StagingResources: !Equals [ !Ref EnvType, "Staging"]
DevResources: {"Fn::Equals" : [{"Ref":"EnvType"}, "Dev"]}
Resources:
DynamoDBSampleTable: #(C)
Type: AWS::DynamoDB::Table
Properties:
TableName: !If ["ProductionResources", "sample-table", !If ["StagingResources", "staging_sample-table", "dev_sample-table"]] #(D)
BillingMode: PROVISIONED
SSESpecification: !If ["ProductionResources", { "SSEEnabled" : true }, !Ref "AWS::NoValue"] #(E)
AttributeDefinitions:
- AttributeName: samplePartitionKey
AttributeType: S
- AttributeName: sampleSortKey
AttributeType: S
KeySchema:
- AttributeName: samplePartitionKey
KeyType: HASH
- AttributeName: sampleSortKey
KeyType: RANGE
ProvisionedThroughput:
ReadCapacityUnits: 5
WriteCapacityUnits: 5
Outputs:
EnvironmentRegion: #(F)
Description: Dev Environment Region
Value: !Sub ${AWS::Region}
Export:
Name: !Sub MynaviSampleDynamoDB-${EnvType}-Region
DynamoDBServiceEndpoint: #(G)
Description: DynamoDB service endipoint
Value: !Sub https://dynamodb.${AWS::Region}.amazonaws.com
Export:
Name: !Sub MynaviSampleDynamoDB-${EnvType}-ServiceEndpoint
DynamoDBProduction: #(H)
Condition: "ProductionResources" #(I)
Description: DynamoDB SampleTable for Production
Value: !Ref DynamoDBSampleTable
Export:
Name: !Sub ${VPCName}-DynamoDBProductionSampleTable
DynamoDBTableStaging: #(J)
Condition: "StagingResources"
Description: DynamoDB SampleTable for Staging
Value: !Ref DynamoDBSampleTable
Export:
Name: !Sub ${VPCName}-DynamoDBStagingSampleTable
// omit
DynamoDBのテンプレートの記述の基本となるポイントは下表の通りです。
記述 | 説明 |
---|---|
A | DynamoDBを商用環境、ステージング環境、開発環境用に分けるよう、EnvTypeパラメータとして指定可能にします。このパラメータに応じて、Conditionsを設定し、作成するリソースを切り替えます |
B | Conditionsとして、EnvTypeパラメータの値に応じて3つの論理名を定義します。定義方法の詳細は、前回紹介したRDSスタック構築テンプレートと同様なので適宜参照してください |
C | DynamoDBテーブルのリソース定義を行います。定義するプロパティの詳細はAWS::DynamoDB::Tableを参照してください |
D | DynamoDBはリージョンサービスのため、同一リージョンで同じ識別子をもつテーブルを作成することはできません。各環境に応じて、条件関数を使って識別子を変更して作成します。条件関数の詳細は、AWS公式サイトの「条件関数」も参照してください。ここでは、”Fn::If”を2回組み合わせて、3つのパラメータの値に応じてテーブル名を切り替えています |
E | SSESpecificationは、テーブルの暗号化オプションでConditionが”ProductionResources”の場合のみ、有効化されるように設定します。擬似パラメータ”AWS::NoValue”関数を使用することにより、このパラメータが有効になると対応するリソースプロパティは削除されます(擬似パラメータについては、表下の囲み記事「擬似パラメータについて」を参照してください) |
F | DynamoDBを構築するリージョンを出力します |
G | DynamoDBのサービスエンドポイントを出力します |
H | DynamoDBのテーブル名を出力します |
I | 前回と同様、Conditionsの論理名が”ProductionResources”だった場合に、リソース定義が有効化するよう、Condition要素を定義します |
J | 前回と同様、Conditionsの論理名が”StagingResources”だった場合に、リソース定義が有効化するよう、Condition要素を定義します |
【擬似パラメータについて】
擬似パラメータはCloudFormationであらかじめ定義されたパラメータ群で、”!Ref”により参照することができます。事前定義されているパラメータは以下の通りです。詳細は、AWS公式サイトの「擬似パラメータ参照」をご覧ください。
パラメータ | 説明 |
---|---|
AWS::Region | リージョン名を取得します |
AWS::StackId | スタックIDを取得します |
AWS::StackName | スタック名を取得します |
AWS::AccountId | AWSアカウントIDを取得します |
AWS::NotificationARNs | notification Amazon Resource Namesを取得します |
AWS::NoValue | 指定したリソースプロパティを削除した形でテンプレートを実行します |
AWS::Partition | リソースが存在するパーティションを返します。標準のAWSリージョンの場合、パーティションは”aws”です |
AWS::URLSuffix | ドメインのサフィックスを返します。標準のAWSリージョンの場合、サフィックスは”amazonaws.com”です |
作成したテンプレートに対して、以下のようにスタック名とテンプレートパスを変更してヘルパースクリプトを実行します。
#!/usr/bin/env bash
stack_name="mynavi-sample-dynamodb"
template_path="sample-dynamodb-cfn.yml"
parameters="EnvType=Production"
aws cloudformation deploy --stack-name ${stack_name} --template-file ${template_path} --parameter-overrides ${parameters} --capabilities CAPABILITY_IAM
実行が正常に終了すると、DynamoDBが作成されます。
以上、今回はConditions要素や条件関数、擬似パラメータ参照を使いながら、DynamoDBを構築するCloudFormationテンプレートを実装しました。次回は、ElastiCacheを構築するテンプレートを作成します。
著者紹介
川畑 光平(KAWABATA Kohei) - NTTデータ 課長代理
金融機関システム業務アプリケーション開発・システム基盤担当を経て、現在はソフトウェア開発自動化関連の研究開発・推進に従事。
Red Hat Certified Engineer、Pivotal Certified Spring Professional、AWS Certified Solutions Architect Professional等の資格を持ち、アプリケーション基盤・クラウドなどさまざまな開発プロジェクト支援にも携わる。2019 APN AWS Top Engineers & Ambassadors選出。
本連載の内容に対するご意見・ご質問は Facebook まで。