■サービス
- Auto Scaling
- CloudFormation
- CloudFront
- DynamoDB
- EC2
- Elastic Beanstalk
- OpsWorks
- Route53
- SQS
- VPC
Blue/Greenデプロイメントでもう1セット環境を構築する
Blue/GreenデプロイメントでELBとEC2インスタンスとRoute53の環境でもう1セットを構築するパターンがあります。
- 2番目のELBとAuto Scaling グループを作成する。
- Route53で新環境用のエイリアスレコードを作成して新旧2つのレコード間で重みづけをしたルーティングポリシーを割り当てる。
- 新環境のEC2インスタンスも同じRDSにアクセスするように設定する。
CloudFrontとELBとRoute53の組み合わせ
読み取りが多いWebアプリケーションの場合、CloudFrontディストリビューションを作成してRoute53をディストリビューションに割り当てELBをオリジンとします。
キャッシュの設定をします。
CloudFront キャッシュ動作の設定
セキュリティグループだけでなくVPCネットワークACLもある
VPC には、変更可能なデフォルトのネットワーク ACL が自動的に設定されます。デフォルトでは、すべてのインバウンドおよびアウトバウンドの IPv4 トラフィックと、IPv6 トラフィックが許可されます。
通常ではあまり意識することがないかもしれませんが、VPCにはネットワークACLがあり、デフォルトで全部許可されています。
■インバウンドルール
■アウトバウンドルール
DynamoDBのデータをストレージに移動する
DynamoDBのデータをS3などのストレージAmazon Kinesis Data Firehose を利用してデータをS3等に送信します。
Automatically Archive Items to S3 Using DynamoDB Time to Live (TTL) with AWS Lambda and Amazon Kinesis Firehose
参考資料
Overview of Deployment Options on AWS
https://d0.awsstatic.com/whitepapers/overview-of-deployment-options-on-aws.pdf
Blue/Greenデプロイメントの方法
Blue/Greenデプロイメントは、アプリケーションの2つの同一のスタックを独自の環境で実行する方法です。
さまざまな戦略を使用して、トラフィックを現在のアプリケーションスタック（青）から新しいバージョンのアプリケーション（緑）に移行します。
これは、ダウンタイムがゼロのアプリケーションをデプロイするための一般的な手法です。
Elastic Beanstalk、CloudFormation、OpsWorksなどのデプロイサービスは、実行中のアプリケーションスタックのクローンを作成する簡単な方法を提供するため、特に便利です。
アプリケーションの現在のバージョン（青）のクローンを作成するだけで、アプリケーションの新しいバージョン（緑）をセットアップできます。
セッションレスウェブアプリケーションの場合、更新プロセスは非常に簡単です。
アプリケーションの新しいバージョンをアップロードし、デプロイサービス（Elastic Beanstalk、CloudFormation、OpsWorks）に新しいバージョン（緑色）をデプロイさせるだけです。
新しいバージョンに切り替えるには、DNSレコードのELBのURLを置き換えるだけです。
Elastic Beanstalkには、スワップ環境URLより簡単なカットオーバープロセスを容易にするための機能があります。
Amazon Route53 DNSレコードを管理するには、ELBエンドポイントをCloudFormationまたはOpsWorksデプロイサービスと交換する必要があります。
セッション状態のアプリケーションの場合、カットオーバープロセスは複雑になる可能性があります。
更新を実行するときに、エンドユーザーにダウンタイムが発生したりデータが失われたりしないようにする必要があります。
特定のデプロイメントサービスで新しいスタックを作成するとセッションデータベースが再作成されるため、デプロイメントサービスの外部にセッションを保存することを検討する必要があります。
特に、RDSデータベースまたは使用している場合は、デプロイメントサービスとは別にセッションの格納を考えます。
Amazon Route53を使用してDNSレコードをホストしている場合はライトラウンドロビン（WRR） 機能を使用して青から緑のデプロイメントに移行することができます。
この機能は、トラフィックを瞬時にではなく徐々に駆動するのに役立ちます。
アプリケーションにバグがある場合、この方法は少数のユーザーにしか影響しないため、爆風半径を最小限に抑えるのに役立ちます。
この方法では、必要になった場合のロールバックも簡素化されます。
さらに、緑でスケールアップし、青のデプロイメントでスケールダウンしている間は、必要な数のインスタンスのみを使用します。
たとえば、トラフィックの90％を青に保ちながら、トラフィックの10％が緑の展開に進むことを許可するようにWRRを設定できます。
完全なカットオーバーを達成するまで、グリーンインスタンスの割合を徐々に増やします。
DNSキャッシュをクライアント側でより短いTTLに維持することで、クライアントが迅速なリリースサイクルでグリーン展開に接続できるようになり、DNSキャッシュの不正な動作を最小限に抑えることができます。
コメント