[レポート] DevOps のための AWS Well-Architected ベストプラクティス #DOP207 #reinvent
アノテーション テクニカルサポートの川崎です。
本記事は AWS re:Invent 2022 のセッションレポートとなります。
概要
このセッションでは、DevOps プラクティスを AWS Well-Architected フレームワークの柱に合わせるために必要なすべてのコンポーネントについて学びます。 組織導入、開発ライフサイクル、品質保証、自動化されたガバナンス、オブザーバビリティを確認します。
セッション動画
アジェンダ
- 最新の DevOps と AWS Well-Architected フレームワークの概要
- サンプル DevOps パイプラインのアーキテクチャ
- DevOps のベストプラクティス
- 組織導入
- 開発ライフサイクル
- 品質保証
- 自動化されたガバナンス
- オブザーバビリティ
- DevOps のベストプラクティスを使用した最終的なアーキテクチャ
- 結びの言葉
Currently, DevOps is more like a philosophical movement, not yet a precise collection of practices, descriptive or prescriptive. Gene Kim
(日本語訳) 現在のところ、DevOps は哲学的なムーブメントのようなもので、まだ明確なプラクティスの集合ではなく、記述的プラクティス、もしくは規範的プラクティスです。
- DevOps
- 哲学的なムーブメントのようなもの
- 記述的プラクティス
- 規範的プラクティス
モダンな DevOps: 具体的にはどういうことか?
- 過去
- 開発者は、インフラストラクチャがプロビジョニングされるまで数日または数週間待ちます
- ソフトウェアは、1 回限り手動で展開されます
- セキュリティは、アプリケーションごとに 1 回構成されます
- 開発者は、本番環境で実行されているアプリケーションを把握できません
- ツールは、チームやビジネス ユニット間で一貫性がありません
- 現在
- 開発者はインフラストラクチャをオンデマンドでプロビジョニングし、数分で展開します
- ソフトウェア配信は、継続的配信パイプラインによって自動化されています
- セキュリティのベストプラクティスは、すべてのアプリケーションとサービスに含まれています
- アプリケーションは、メトリックおよびログ収集用に完全に装備されています
- 組織は、ツールとベストプラクティスを標準化します
重荷を下ろす: DevOps は 4 つのベスト プラクティスに単純化できる
- 説明責任 (Accountability)
- 開発と運用をより緊密にすることで、「壁を越えて投げる」サイロ化された文化はなくなる
- 自動化 (Automation)
- デリバリーをスピードアップし、人とのやり取りとエラーを減らすために自動化する
- 気づき (Awareness)
- 常にシステムの状態について認識している
- 自律性 (Autonomy)
- 一元的に実施される基準とガバナンスを介して自走する
DevOps パイプラインのサンプル
- 典型的なパイプラインはスライドのようになる
- 左側で開発者がコードをコードリポジトリにチェックインする
- GitHub や類似のサービス
- パイプラインがコードをピックアップし、依存関係と共にビルドする
- ビルドサービスがイメージを作成
- イメージは、コンテナイメージのリポジトリにチェックインされる
- デプロイ準備ができたら、手動プロセスかツールを使用し、プリプロダクション環境やプロダクション環境へデプロイされる
- 本セッションでは、DevOps パイプラインのそれぞれのステップで、Well-Architected フレームワークのベストプラクティスに適合させる方法を紹介する
Well-Architected フレームワーク とは何か?
- 柱 (Pillars) は基盤
- 設計原則
- 質問
Well-Architected の柱
- オペレーショナルエクセレンス
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- 持続可能性
組織導入 (Organization adoption)
- DevOps への移行は、組織の観点から最も重要なことである
- そのオプションと、AWS ツールを使用して最新の Devops を実行することによってものを理解することが重要であるため、このセクションで取り上げる
なぜモダンなDevOpsのためにAWSのツールを使用するのか
- 簡単に始めてすぐに始められるようにするエンドツーエンドのソリューション
- セキュリティが最優先事項であり、可用性はその次です
- 競争力のある価格と低 TCO
- 専門知識は必要ありません
- 開発者と組織のために構築されています
- AWS 以外の最も一般的なツールと統合されています
エンドツーエンドのソリューションは、開発組織の迅速化を支援する
- 組織導入の観点
- 一連のAWSの製品を使用したソリューションをエンドツーエンドで構築できる
- AWS の開発ツールのエコシステム
- コードをソース(用意)する
- ECR
- CodeCommit
- CodeArtifact
- コードをビルド
- CodeBuild
- デプロイ
- CodeDeploy
- 監視
- コードをソース(用意)する
AWS においてセキュリティが最優先事項
- セキュリティは明らかに最優先事項
- ジョブ ゼロ
- 制限されたアクセス/最小限の特権
- クラウドに安全に保管
- issueをスキャン
- プライベート VPC で実行
- AWS がすべてのパッチ適用を処理
専門知識は不要: Al を使用して DevOps を改善
- 回復までの時間 (TTR) を短縮
- ML を活用したインサイトを使用して、issueを迅速に診断して修正
- コードの品質をプロアクティブに改善
- 見つけにくいバグ、重大な問題、およびセキュリティの問題を高精度で特定し、インテリジェントな推奨事項を使用してそれらを修正
- 最もコストのかかるコード行を捕捉
- ML 向けに最適化された統合機能を使用して、カスタム統合コードを作成するコストを削減
開発者と組織のために作られている
- 組織が必要とするセキュリティと可用性に加えて
- ガバナンスとコンプライアンスを容易に
- 開発者は、好みのツール、言語、およびフレームワークを介して利用可能
-
数百または数千のアカウントを使用しているマルチアカウントシナリオであっても、AWS で構成を使用できる
- ランディング ゾーン
- セキュリティ ハブ
TCO の削減
- 価格競争力
- 使用した分だけ支払い
- フルマネージド
- 基盤となるインフラストラクチャのパッチ適用とスケーリングは AWS が処理するため、お客様が行う必要なし
- AWS 移行の根本的理由
- CAPEX (Capital Expenditure: 設備投資) から OPEX (Operating Expense: 運用費)へ移行し、総所有コストを削減したい
ノン AWS の最も人気のあるツールとも緊密に統合
開発ライフサイクル
デプロイメント: モノリス開発ライフサイクル
- モノリス アプリケーション
- エンタープライズ組織
- これらのアプリケーションのいずれかのモジュールに小さな変更を加えると、アプリケーション全体がダウンする可能性がある
デプロイメント: マイクロサービス開発ライフサイクル
- モノリシック アーキテクチャをマイクロサービスに分割
- ストラングラー パターン
- モノリスをマイクロソースに変換するために使用できるパターン
CI/CD
- アプリケーション開発ライフサイクルにおける CI/CD のベストプラクティス
- 継続的インテグレーション
- 主に、テストフレーズで実施される
- できるだけ早期に、迅速にコミットする
- 以降の統合の問題を減らすことが可能
- 単体テストの作成
- 100% のコード カバレッジを目標にする
- テストが最新の状態に保たれていることを確認
- 単体テストの失敗
- 無視されるべきではない
- バイパスされるべきではない
- 常に修正されるべき
- 常に最新の状態に保たれるべき
- コード カバレッジ
- DevOps の指標
- ベストプラクティスの一部としてインプリメントするべき
- 継続的インテグレーション
- ベストプラクティスの推奨事項
- 組織全体の開発およびテストフェーズでイメージを構築するときに、Maven や Gradle などのツールを採用すること
- これらのツールセットを標準化すること
- 自動化すること
- この時点で重要なことは導入すること
- 機能テスト
- 非機能テスト
- パフォーマンステスト
- 負荷テスト
- 悲観的テスト
- ネガティブテスト
- ベータテストを実施する
- 少人数のユーザーに参加してもらう
CodeDeploy: Amazon ECS blue/green デプロイメント
- デプロイメント戦略に関する AWS のベスト プラクティス
- 「resiliency: 回復力」の柱 (信頼性の柱)
- 何があっても顧客にサービスを提供し続けたい
- CodeDeploy について
- EC2 へのデプロイを自動化
- オンプレ
- Lambda 関数
- ECS
- EKS
- blue/green デプロイメント
- 同一環境を2つ作成するデプロイ戦略
- blue 環境
- 本番環境
- green 環境
- 新しい変更を導入する環境
- green 環境の準備が整い、テストが完了したら
- 本番のトラフィックは blue から green にリダイレクトされる
- 問題が発生した際は、blue 環境にロールバックされる
- ここで構成の変更は、常に導入される変更に関係なく、アプリケーションが常に利用可能であることを保証する
コンセプト: Blue/Green カナリア デプロイメント
- Blue/Green 戦略の新機軸
- カナリア デプロイメント
- 小規模トラフィックを新しい環境に公開する
- 段階的に徐々に増やして完全に切り替える
- 実装
- 加重 DNS
- 加重 ELB ターゲットグループ
DevSecOps: セキュリティ チェックポイントの統合
- DevSecOps
- コードリポジトリ (Code repository)
- シークレットのスキャン
- ビルドとコンテナ化 (Build and containerize)
- SCA (Software Composition Analysis: ソフトウェアコンポジション解析)
- SBOM (Software Bill of Materials: ソフトウェア部品表)
- SAST (Static Application Security Testing: 静的アプリケーションセキュリティテスト)
- IaC linting
- 検証とテスト環境へのデプロイ (Validate and deploy to test)
- ECR scan
- イメージ署名
- DAST (Dynamic Application Security Tesing: 動的アプリケーションセキュリティテスト)
- 本番環境へのデプロイ (Deploy to production)
- イメージ署名
- DAST (Dynamic Application Security Tesing: 動的アプリケーションセキュリティテスト)
- コードリポジトリ (Code repository)
- 静的分析
- 無限ループ
- スタイル上のエラー
- Amazon CodeGuru
- 機械学習により強化した、静的分析ツール
品質保証
品質保証
- Amazon CodeGuru
- Amazon DevOps Guru
- 運用上の問題を自動的に検出
- ML を活用したインサイトで問題を迅速に解決
- ベストプラクティスを実装するための実行可能な手順を提供
継続的なコードの改善
- Amazon CodeGuru Reviewer
- コーディング
- 実用的な推奨事項を備えた組み込みのコードレビュー
- コーディング
- Amazon CodeGuru Profiler
- ビルドとテスト
- コストのかかるプリプロダクションのコードを検出して最適化
- デプロイ
- 計測
- 本番環境でのパフォーマンスとコストの改善を簡単に特定
- ビルドとテスト
Amazon DevOps Guru を始める
- カバレッジを選択
- アカウント全体または特定の CloudFormation スタックを選択
- インサイトを生成
- DevOps Guru は、指標/ログの分析を開始して洞察を生成
- ワークフローと統合
- AWS Systems Manager の機能である OpsCenter
- Amazon SNS
- サードパーティのプラットフォーム
継続的アセスメント
- AWS Fault Injection Simulator (AWS FIS) は、さまざまな AWS サービスにわたって制御された障害注入実験をセットアップして実行するプロセスを簡素化し、チームがアプリケーションの動作に自信を持てるようにします
-
回復力とパフォーマンスを向上
- 隠れた問題を明らかにする
- 死角をさらけ出す
- 監視、オブザーバビリティ、およびアラーム
自動化されたガバナンス
あらゆる組織向けの 1 つのツール セット
- CloudFormation という単一のツールを使用してインフラストラクチャを展開および管理する
- ガバナンスの観点
- ガバナンスを大規模に維持するための非常に重要なベストプラクティス
IaC のプロビジョニングと管理
1 コード 2 コミット、Git プッシュ/PR 3 Cl/CD テストと展開を開始 4 CloudFormation を通じてプロビジョニングされたリソース
AWS GitOps スタック
- 一貫した GitHub スタックを持つこと
- ガバナンスの観点から、組織にとって非常に重要
AWS クラウド開発キット (AWS CDK)
- クラウドインフラストラクチャ開発の観点から、強くお勧めする
- CDK を使いインフラストラクチャを構築
- コードを CloudFormation に合成する
- CloudFormation を使い、インフラストラクチャを管理する
オブザーバビリティ
- Well-Architected フレームワークの「オペレーショナルエクセレンス」の柱の観点
- アプリケーションを監視することは、非常に重要
アプリケーションの状態を監視
- オブザーバビリティとは
- メトリクス
- さまざまな時間間隔で測定された数値データと SLI (Service Level Indicator: サービスレベル指標)
- ログ
- 不連続イベントのタイムスタンプ付きレコード
- トレース
- 複数のアプリケーションやシステムを横断するユーザー・ジャーニー
- メトリクス
AWS オブザーバビリティツール
- インフラストラクチャ監視
- アプリケーション監視
- 合成監視 (Synthetic monitoring)
AWS オブザーバビリティの選択
- 組織の成熟度に応じて、ツールを選択可能
- AWS ネイティブ (左側)
- オープンソースツール (右側)
継続的なオブザーバビリティ
- Amazon DevOps Guru
- 開発者とオペレーターが問題を自動的に検出し、アプリケーションの可用性を向上させ、コストのかかるダウンタイムを削減することを容易にする ML を利用したサービス
- 複数のソースからの運用データを統合
- ML を活用したインサイトを使用
- アラームを自動的に構成
- 最小限のノイズで最も重大な問題を検出
- 開発者とオペレーターが問題を自動的に検出し、アプリケーションの可用性を向上させ、コストのかかるダウンタイムを削減することを容易にする ML を利用したサービス
ベスト プラクティスを含む最終的なアーキテクチャ
- 現在の DevOps に関連するアーキテクチャのベストプラクティス
- 最終的なアーキテクチャ パイプライン
- SDL (Secure Development Lifecycle: セキュア開発ライフサイクル) に関するベストプラクティス
- モノリスをマイクロサービスに分割
- CI/CD に関連するベストプラクティス
- DevSecOps
- セキュリティをパイプラインに組み込む
- SAST (Static Application Security Testing: 静的アプリケーションセキュリティテスト)
- DAST (Dynamic Application Security Tesing: 動的アプリケーションセキュリティテスト)
- 脅威に関連する通知と軽減策を確認するメカニズム
- 品質保証 (Quality assurance)
- 機能テスト
- 非機能テスト
- 負荷テスト
- パフォーマンステスト
- Code Guru
- DevOps Guru
- ガバナンス
- オブザーバビリティ
- デプロイメント戦略
まとめ
DevOps のための AWS Well-Architected ベストプラクティス、ということで、DevOps のベストプラクティスが、5つの観点で整理されておりました。
- 組織導入
- 開発ライフサイクル
- 品質保証
- 自動化されたガバナンス
- オブザーバビリティ
ぜひみなさまの DevOps 環境でも、取り入れてみていただけたら幸いです。