デプロイのベストプラクティス 山本 直弥 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の質問によってチェック項目の数は変わる

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

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

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

OPS 6. どのようにデプロイメントリスクを軽減するのですか? 13 チェック項目 必要なアクション例 アクションがない場合のリスク例 OPS06-BP01 変更の失敗に備える ・失敗時の復旧/修正の計画を立てる ・変更の適用範囲を限定する ・失敗時にロールバックするか、修正するか判断 するまでの時間だけユーザ影響が出る ・平均復旧時間(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