[レポート]DEV317: 高度で継続的デリバリーのベストプラクティス #reinvent

こんにちは、坂巻です。

本記事はAWS re:Invent 2018のセッション「Advanced Continuous Delivery Best Practices」のレポートです。

概要

Continuous delivery (CD) enables teams to be more agile and quickens the pace of innovation. Too often, however, teams adopt CD without putting the right safety mechanisms in place. In this talk, we discuss opportunities for you to transform your software release process into a safer one. We explore various DevOps best practices, showcasing sample applications and code with AWS CodePipeline and AWS CodeDeploy. We discuss how to set up delivery pipelines with nonproduction testing stages, failure cases, rollbacks, redundancy, canary testing and blue/green deployments, and monitoring. We'll discuss continuous delivery practices for deploying to Amazon EC2, AWS Lambda, and Containers (such as Amazon ECS or AWS Fargate).

スピーカー

スピーカーは以下の二名です。

• Felipe Almeida - Senior Software Dev Engineer, AWS
• Curtis Rissi - Sr. Solutions Architect

レポート

AWSで継続的な配信始める前に

基本的な継続的デリバリーのベストプラクティス

• バージョン化されたソース
• 自動ビルド
• 自動導入
• 1つのインスタンスにデプロイ
• ユニットテスト
• 統合テスト
• 継続的なデプロイ
• 操作ダッシュボード

このセッションで使用したツール

• Amazon CloudWatch
• Amazon SNS
• AWS Lambda
• AWS CodeDeploy
• AWS CodePipeline

コンテナとサーバレスでこれを行うにはどうしたらいいですか？

• セッションカタログかYoutubeをチェック
• DEV309-R CI/CD for serverless and Containerized Applications

ステップ1 自動化を可能にする

自動化されたパイプラインは...

• コードとして定義される
• AWS Commitなどのリポジトリにチェックイン
• 他のAWSのサードパーティツールやサードパーティのツールによる拡張性を可能にする
• パイプライン実行の成功と失敗に関するフィードバックを提供できる

オートメーションの機会

• 継続的な統合のプロセス：ビルド、統合テスト、UIテスターなど
  • ヘルスチェック
  • アプリケーションテスト
  • ユーザーテストとアプリケーションパフォーマンスの監視
  • 通知とアラート
  • AWS CloudWatch Alamsおよび3rdパーティツール（Splunk、Datadogなど）
  • Amazon SNS、Slack、Pagerduty、その他

ステップ1:Build and unit tests

ステップ2:Notify on failed build and test

ステップ2 ベストプラクティスとしてのデプロイの健全性

デプロイの状態を管理

• オートメーションの基盤上に構築
• デプロイの後にサービスが動作していることを検証するために構築
• 手動での実施を回避する

ローリングデプロイに安全性を追加

1. 各ホストの状態を確認する
2. フリートの最低パーセンテージが健全であることを確認する
3. デプロイが失敗した場合のロールバック

ステップ1:Deployment validation - AppSpec.yml

ステップ1:Working tests raises more issues

ステップ2: Use minimum health hosts

ステップ2:Use minimum health hosts - CodeDeploy

ステップ3:Rollback when a deployment fails

デモ

• 会場ではBlue/Greenデプロイのデモがありました

ステップ3 1つのセグメントにデプロイ

セグメント化によるデプロイリスクの低減

• デプロイメント障害の影響を最小限に抑える
• 実際のユーザーが行う前に問題を潜在的にキャッチ
• 影響の少ない迅速なロールバックが可能

セグメンテーションの概要

1. 実装を複数のセグメントに分割する
2. 各セグメントに展開する
3. 展開後にセグメントをテストする
4. 完了するまで2＆3を繰り返す

実装を複数のセグメントに分割

• セグメントごとにAuto Scaling groupを作成する
  • タグ
  • Auto Scaling group

各セグメントにデプロイ

1. 最小セグメントにデプロイ
2. デプロイ後のテスト
3. 1つのアベイラビリティゾーンにデプロイ
4. デプロイ後のテスト
5. 残りのアベイラビリティゾーンゾーンにデプロイ

ステップ4 マルチリージョンへの展開

マルチリージョンデプロイ

• 2018年11月の新機能
• 単一のパイプラインから複数のリージョンに展開
• 低レイテンシーと高い可用性を実現

デモ

• 会場ではカナリアリリースのデモがありました

ステップ5 パイプラインガバナンスの実装

非準拠のパイプラインをブロックする

• 変更を導入したり、新しいパイプラインを導入すると、深刻な問題が発生する可能性がある
• AWS Configを活用して、本番環境へのデプロイを許可する前にパイプラインを保証する

AWS Configルールによる安全性の追加

• AWS Configルールを作成する
  • 企業のベストプラクティスまでパイプラインが構成されていない場合の警告
• 実装をブロックするパイプラインを構築することは、非準拠のパイプラインをプッシュ
  • 承認を使用して運用環境のデプロイを一時停止する
  • Lambdaはいつ実行されるのかを自動的に承認する

デモ

• 会場ではAWS Config含めたデプロイについてのデモがありました

さいごに

すごくテッキーなセッションでした。普段はあまり触ることのないサービスでしたが、設計しがいがありそうで業務でつかってみたい！！機会があったらブログにしていけたらなと思います。