デプロイのベストプラクティス

デプロイのベストプラクティス山本直弥 2025年1月7日 JAWS-UG 朝会

自己紹介名前：山本直弥所属：株式会社シーイーシー 2023-2024 Japan AWS All Certifications Engineer
好きなAWSサービス： AWS Lambda AWS Step Functions Amazon Redshift 今年もよろしくお願いします 1 X：@Nao_Engineer_AC Qiita:https://qiita.com/Nana_777

今日話すこと ⚫Well-Architected Frameworkにおけるデプロイに関するベストプラクティスの話 ”ベストプラクティス”の必要性 W-Aにおけるデプロイのベストプラクティスとは？ OPS 6 デプロイ戦略 ロールバック戦略
デプロイ/ロールバック戦略試してみた(CodeDeploy) 2

“ベストプラクティス”の必要性ベストプラクティスとは・・・・特定の業務やプロセスにおいて最も効果的で効率的な方法や手法・設計原則 3

AWSのデプロイ方法の選択肢は様々 4 AWSマネジメントコンソールを操作して一つずつ手動デプロイ CloudFormation、CDK などIaCツールを使って一括デプロイ CodeDeployを使って
ロールバックも考慮したより複雑なデプロイ例えば・・・いろんなツール、機能、使い方があり、どれを選んでもデプロイはできる

デプロイ方法を選ぶ基準は？ 5 作業が楽で早いから今まで経験があり、安心して作業できるから教科書や有名な人のブログでこれが最先端だと紹介されていたからユーザからの指定例えば・・・
担当者の経験や知識、価値観によって、どの方法を選ぶかは変わるかも

設計原則を学んで客観的に評価しよう 6 ユーザの要求 ※要望を実現するだけで良い？担当者の経験や知識 ※担当者によって価値観に差が出るのでは？ベストプラクティス ※大局的に何が大切か、
原則を参考に考えよう ※ただし原則に当てはめすぎるのは注意ベストプラクティスはどうやって得ればよい？＋＋

Well-Architected Framework • クラウド上でワークロードを設計および実行するための主要な概念、設計原則、アーキテクチャのベストプラクティス集 • 質問とそれに関連するいくつかのチェック項目からなる • ベストプラクティスとの差異の確認とリスクの把握ができる 7
https://aws.amazon.com/jp/blogs/mt/streamline-change-processes-and-improve-governance-with-aws-well-architected/ 6本の柱・運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性

W-A Framework におけるデプロイのベストプラクティスとは？ 8

OPS 6. どのようにデプロイメントリスクを軽減するのですか? 9 チェック項目必要なアクション例アクションがない場合のリスク例 OPS06-BP01 変更の失敗に備える・失敗時の復旧/修正の計画を立てる
・変更の適用範囲を限定する・失敗時にロールバックするか、修正するか判断するまでの時間だけユーザ影響が出る・平均復旧時間(MTTR)を最小限に抑えられない・一度に全ユーザーに失敗の影響が出る OPS06-BP02 デプロイをテストする・デプロイ前に本番環境と同様の環境でテストする・Infrastructure as Code (IaC) のコードの正確性が判断できない・未知の問題が発生する・ユーザからの報告により初めて問題を発見する OPS06-BP03 安全なデプロイ戦略を使用する・デプロイ失敗の影響範囲を制限するための仕組み作り・復旧/修正までに時間がかかる・一度に全ユーザーに問題の影響が出る OPS06-BP04 テストとロールバックを自動化する・不具合の発見、ロールバックを素早く行える仕組みづくり・デプロイ結果をモニタリングして成功基準に照らして検証する・手動での確認が多く、問題発見とシステム復旧が遅れることでユーザ影響が長引く・システムの状態をモニタリングしていないので、ロールバックの要否を判断できない 1つの質問と、4つのチェック項目 ※W-A Fの質問によってチェック項目の数は変わる

・変更の適用範囲を限定する・失敗時にロールバックするか、修正するか判断するまでの時間だけユーザ影響が出る・平均復旧時間(MTTR)を最小限に抑えられない・一度に全ユーザーに失敗の影響が出る OPS06-BP02 デプロイをテストする・デプロイ前に本番環境と同様の環境でテストする・Infrastructure as Code (IaC) のコードの正確性が判断できない・未知の問題が発生する・ユーザからの報告により初めて問題を発見する OPS06-BP03 安全なデプロイ戦略を使用する・デプロイ失敗の影響範囲を制限するための仕組み作り・復旧/修正までに時間がかかる・一度に全ユーザーに問題の影響が出る OPS06-BP04 テストとロールバックを自動化する・不具合の発見、ロールバックを素早く行える仕組みづくり・デプロイ結果をモニタリングして成功基準に照らして検証する・手動での確認が多く、問題発見とシステム復旧が遅れることでユーザ影響が長引く・システムの状態をモニタリングしていないので、ロールバックの要否を判断できない

安全なデプロイ戦略・デプロイ失敗時の影響を影響を最小限にするには？ 14

フェーズデプロイ 15 V1 V1.1 V2 読みだし機能:ver1 書き込み機能:ver1 読みだし機能:ver2 書き込み機能:ver1 読みだし機能:ver2
書き込み機能:ver2 機能を段階的にデプロイするテスト負荷の軽減や問題発生時のロールバックの影響範囲を制限する ※イメージ

時差デプロイ 16 1回目デプロイ 2回目デプロイ 3回目デプロイ 4回目デプロイ
5回目デプロイ ※イメージ地域やコンテナで範囲を分けるリージョン、AZ、コンテナの単位でデプロイすることで、ユーザ影響範囲を制限する

ブルー/グリーンデプロイ 17 同じ環境を二つ作り、片方に新バージョンをデプロイしてテスト問題なければトラフィックを切り替える新環境既存環境 100%→0% 0% → 100%
※イメージ

リニアデプロイ 18 トラフィックを一定の間隔、一定の割合でアクセスを新環境に切り替える 90%→80%→70%・・・→0% 10%→20%→30%・・・→100% 新環境既存環境 ※イメージ

カナリアデプロイ 19 少数の一部のユーザに新環境にアクセスさせてから全体公開する2段階デプロイ問題が無ければ全体公開、問題があれば既存環境に戻す 90%→0% or 100% 10%→100% or 0%
新環境既存環境 ※イメージ

ロールバック戦略 20

ロールバック戦略 21 V1 V2 デプロイ後テスト開始デプロイ開始経過観察時間 (ベイクタイム) 問題を検知した場合はロールバック
〇時間にX回エラー発生したら戻すなど計画例えばCloudWatch アラームでエラー検知ロールバック判定ベイクタイムをどの程度にするか、監視方法はどうするか自動ロールバックにするか、手動ロールバックにするか、判定基準等の検討が必要

デプロイ/ロールバック戦略試してみた 22

今回のデプロイ戦略実装試してみたで利用したAWSサービス 23 AWS CodeDeploy デプロイメントグループデプロイ設定 CodeDeployがデプロイ中に使用する一連のルールと成功条件と失敗条件デプロイ中に使用される設定と構成デプロイアプリケーション
デプロイの単位ソフトウェアのデプロイを自動化する、フルマネージド型のサービスエラーを検知すると自動的にロールバックを実行

バージョンアップデプロイイメージ 24 API Gateway Lambda (ver.1) Lambda (ver.1) Lambda
(ver.2) 90% 10% CloudWatch Alarm API Gateway エイリアス Lambda (ver.2) Lambda (ver.1) ↑エラー検出時ロールバック ↓エラー未検出時、100％新バージョンデプロイ中一定時間、新バージョンに一部のトラフィックを割り当てる CloudWatchアラームでエラーを監視するデプロイ完了デプロイ中にエラーが検知されるか否かでどちらのバージョンにトラフィックを100％割り当てるデプロイ前は100％のトラフィックを1つのバージョンのラムダで処理するAPI

CodeDeployによるデプロイの運用例 25 ・IaCのテンプレート管理することでインフラ定義とデプロイ戦略とロールバックの設定の定義が可能・IaC管理により、検証環境と本番環境で同じ構成と同じデプロイ戦略の実施ができる

CodeDeployのデプロイ戦略の定義 26 const 【デプロイ設定定義名】 = new codedeploy.LambdaDeploymentConfig( this, '【デプロイ設定定義名】', {
trafficRouting: new codedeploy.TimeBasedCanaryTrafficRouting({ interval:Duration.minutes(5), percentage: 10, }), },); CDKの定義 ▪ codedeploy.TimeBasedCanaryTrafficRouting →トラフィックの分割方式を定義(今回はカナリアデプロイ) → その他、AllAtOnce、 Linear等の方式が利用可能 ▪interval:Duration.minutes(5),percentage: 10, →監視時間とその間の新バージョンへのトラフィック量 →今回は5分間監視、10%のトラフィックを新しいバージョンに送る ★デプロイ方法と、トラフィックの割合や監視時間等を柔軟に設定可能

CodeDeployのロールバック設定の定義 27 【デペロイメントグループ定義名】.addAlarm( new cloudwatch.Alarm(this, 'ErrorAlarm’,{ comparisonOperator:cloudwatch.ComparisonOperator. GREATER_THAN_OR_EQUAL_TO_THRESHOLD, threshold: 1,
evaluationPeriods: 1, metric: 【エイリアス定義名】.metricErrors(), }), ); CDKの定義・デプロイグループにアラームを追加する際にアラームの条件を設定可能・今回の例ではLambdaの新バージョンのエラーが 1件以上発生したらロールバックするようにしている

CloudFormationテンプレート定義(ApplicationComposer) 28 CodeDeploy管理前 CodeDeploy管理後追加

動作検証：デプロイ中の各コンソールの画面 29 新バージョンに10%のトラフィック割り当て新バージョンに10%のトラフィック割り当て

動作検証：デプロイ中のAPI実行 30 新バージョンでエラーが発生しても既存バージョンの結果取得に影響なしデプロイ中でも既存バージョンの結果が取得できる新バージョンの結果も取得できる

動作検証：デプロイ完了後orロールバック後のトラフィックデプロイ中エラーなし (新バージョン100%) デプロイ中エラーあり (既存バージョン100%(ロールバック)) エイリアスのバージョン (1つのバージョンに100％)

IaCとCodeDeployを使った場合のOPS6の回答例※個人的見解 32 チェック項目実施するアクション OPS06-BP01 変更の失敗に備えるデプロイ失敗時の対応は以下の計画とする・デプロイ後、10分以内にエラーが発生したら既存環境に戻す・エラー発生時に承認手順なしで即時自動ロールバックを利用する OPS06-BP02
デプロイをテストする・検証環境の構成を本番環境に移行するためIaCで構成管理する・同じテンプレートで本番環境と同様の定義の検証環境でテストを行う OPS06-BP03 安全なデプロイ戦略を使用する・新機能の問題の影響が一部のユーザに留まるようにするために CodeDeployで内容を定義したカナリアデプロイを採用する OPS06-BP04 テストとロールバックを自動化する・CloudWatchアラートを使用してエラーを自動検知する・CloudWatchアラートを元にCodeDeployの機能により自動ロールバックする ※実際の現場では様々なPJの制約があるため、必ずしもCodeDeploy＝ベストな選択にはならない

まとめ 33 ”ベストプラクティス” を含めてやり方を見直そう何がベストか大局的評価を IaC + CodeDeploy を使うことでベストプラクティスに沿った
デプロイが楽に実現できるかも ※PJの特性によるベストなデプロイを実施するにはより多くの知識や経験、事例、最新技術の獲得が必要 1つの方法にこだわらずに学び続けよう

ご清聴ありがとうございました 34

参考文献 ⚫Well Architected FrameworkのAWSドキュメント https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/ ops-06.html ⚫AWS BlackBelt CodeDeploy https://pages.awscloud.com/rs/112-TZM-
766/images/20210126_BlackBelt_CodeDeploy.pdf ⚫AWSクラウドネイティブデザインパターン https://direct.gihyo.jp/view/item/000000003465 35

デプロイのベストプラクティス

デプロイのベストプラクティス

NaoyaYamamoto

More Decks by NaoyaYamamoto

Featured

Transcript