AWS上での DevOps の基本的な哲学、プラクティス、ツールの理解を学べる【DevOps Engineering on AWS】を受講してみた

皆さんこんにちは、AWS事業本部オペレーション部の清水です。

AWS Certified DevOps Engineer - Professional 認定を取得するべく、「DevOps Engineering on AWS」を受講してきました。以下に、学習した内容や参考ブログをご紹介したいと思います。

本コースの受講をお考え中の方へ、お役に立てば幸いです。

AWS認定トレーニングとは？

以下のブログに、弊社AWS認定トレーニング講師の平野のほうで執筆した各トレーニングの詳細が記載されています。

私が今回受講したのは、以下の図の赤枠に入るコースになります。

このトレーニングは、先にAWSの開発の基本を学習できるDeveloping on AWSを受講後、DVAを取得してからのほうが、理解がスムーズではないかなと思います。

内容

1. AWSのDevOps CI/CDの基本
   1. DevOpsの概要
   2. インフラストラクチャの自動化
   3. AWSツールセット（ラボ１）
   4. 開発ツールを使用したCI/CD（ラボ２，３）
2. DevOpsの幅を広げる
   1. マイクロサービスの概要
   2. DevOpsとコンテナ
   3. DevOpsとサーバーレスコンピューティング（ラボ４）
   4. デプロイ戦略
3. DevOpsを深める
   1. テストの自動化
   2. セキュリティの自動化
   3. 構成管理（ラボ５）
   4. オブザーバビリティ（ラボ６）

１日目

モジュール１：DevOpsの概要

• モノリスの課題
  • 年月の経過とともに・・・マイクロサービスとTwo Pizzaチーム（7-10人）
• DevOpsの最適化：マイクロサービス
  • 独立した小さなサービスからなるアーキテクチャおよび組織のアプローチ

DevOps の文化

• DevOpsとは障壁を取り除くこと
• Devの生産性とOpsの信頼性の両方が最適化される
• ツールよりプロセス
• プロセスより人

DevOps の手法

1. 継続的インテグレーション（CI)
2. 継続的デリバリー（CD)
3. マイクロサービス
4. Infrastructure as Code
5. モニタリングとロギング
6. コミュニケーションと連携

モジュール２：インフラストラクチャの自動化

インフラストラクチャのプロビジョニングを自動化

1. ヒューマンエラーが減る
2. リリースと応答時間を高速化
3. Policy as Code を使用してコンプライアンスを維持

Infrastructure as Code の利点

• アプリケーションのソースコードと同様に、バージョン管理が可能
• 信頼性の高い方法で、繰り返し作成、削除、再生成が出来る
• 必要に応じて環境を作成（ステージング環境など）し、テストが出来る
• 複数の環境の作成
• 複数顧客に同一の環境を作成

CloudFormation と DevOps

• テンプレートからスタックを自動的に作成
• パラメータ検証によりエラーを排除
• スタックの連鎖とネストを使用、複雑なシステムを構築
• カスタムリソースを使用
  • CloudFormationが対応していないリソースを、テンプレートに組み込んで使いたいとき
  • 使うのが大変なため、どうしてもという場合にのみ利用

テンプレートをデプロイ

• スタックの更新
  • リソースが置き換わるか
• 変更セット（ドライランのようなイメージ）
  • どんな変更がされるのか、スタックが更新される前に確認することが出来る
  • これにより、リソースが全て置き換わってしまうのかどうか、リリース前に確認が可能
  • スタックのドリフトを検出（スタックの実際の設定と、想定される設定を比較）

ヘルパースクリプト

• スタック作成時に、EC2インスタンスにソフトウェアをインストールしたり、サービスが開始できる

モジュール３：AWS ツールセット

AWS CLI

• ターミナルのコマンドプロンプトから AWS のサービスを管理・統合
•  コマンドライン：Wait
  • 特定の条件が満たされるまで、CLIを待機させることが出来る

AWS CDK

• 複数のプログラミング言語で、クラウドリソースを定義できる

AWS Cloud9

• ブラウザのみを使ったコーディング
• ターミナルへの直接アクセス
• 共同でコーディング

AWS CodeWhisperer

• コード生成・補完
• セキュリティスキャン（これは便利！）

ラボ１：AWS CloudFormation を使用してインフラストラクチャをプロビジョニングおよび管理する

1. YAML で AWS CloudFormation テンプレートを作成、インフラストラクチャリソースを定義
2. CloudFormation スタックを作成、インフラストラクチャをプロビジョニングし、出力を確認
3. リソースに加えられた変更を検出、ドリフトレポートを生成
4. CloudFormation 変更セットを使用し、インフラストラクチャを更新

モジュール４：開発ツールを使用した CI/CD

CodeCommit

• Git リポジトリをホスト、Git ベースのツールで動作するマネージド型のソース管理システム
  • S３によるバックアップ
  • ポリシーでアクセス制御が可能
  • 暗号化にはKMSと組み合わせて利用ができる
  • CodeGuru Reviewerを使用してコードレビューも可能（しかし値段が高め）

CodeBuild

• ソースコードのコンパイル、テスト、 パッケージの生成、フルマネージドのビルドインテグレーションサービス
  • 外部サービスを呼び出して、利用可能（Jenkins,Bambooなど）

CodeDeploy

• 複数のコンピューティングプラットフォームにデプロイ
• デプロイ時のダウンタイムを回避
  • 集中制御
  • 調整が容易
• デプロイグループ

CodePipeline

• 顧客とビジネスに影響を及ぼすことなく安全にデプロイ
• コードの検証とテストを行う
• アクション
  • ソース
  • ビルド
  • テスト
  • デプロイ
  • 呼び出し
  • 承認
• ソース
  • ブランチの指定
    • AWS CodeCommit
    • GitHub
    • GitHub Enterprise
    • Bitbucket
  • オブジェクト or プレフィックスの指定
    • S3
  • dockerタグの指定
    • AWS ECR

ラボ２：AWS CodeDeploy を使用して EC2 フリートにアプリケーションをデプロイする

1. CodeDeploy を使用して複数の EC2 サーバーにデプロイ
2. CodeDeploy エージェントが Windows サーバーにインストールされ、実行されているかを確認
3. CodeDeploy のデプロイアプリケーションとデプロイグループを作成
4. CodeDeploy でインストールするデプロイパッケージを準備
5. CodeDeploy のデプロイターゲットのステータスを監視

２日目

ラボ３：AWS CodePipeline を使用してコードのデプロイを自動化する

1. AWS Cloud9 を使用してアプリケーションコードをパッケージ化し、そのリビジョンを Amazon S3 バケットにアップロード
2. Amazon S3 をソースステージ、AWS CodeDeploy をデプロイステージとして、マルチステージの AWS CodePipeline を構築
3. デプロイ設定を確認し、AWS CodeDeploy を使用して自動コードデプロイを実行
4. AWS Systems Manager セッションマネージャーを使用して、自動デプロイが成功したことを確認

モジュール５：マイクロサービスの概要

特徴

• 多言語
• 分散型
• 独立性
• 単一責任
• ブラックボックス
• 自分で構築、実行

利点

• 保守と改善が容易
• とにかくスピードが上がる
• 短時間で、新機能が追加できる
• テクノロジーが自由

モジュール６：DevOps とコンテナ

管理（デプロイ、スケジューリング、スケーリング）

• ECS
  • 初めて使う人は、こちらを使うほうがハードルが低い
• EKS
  • Kubernetesは、すでに内容を知っている人向け

ホスティング（コンテナが実行される場所）

• EC2
• Fargate

イメージレジストリ（コンテナイメージのリポジトリ）

• ECR
  • イメージの圧縮、暗号化、アクセス制御

モジュール ７： DevOps と サーバーレスコンピューティング

サーバーレス

• プログラムコードのみでOK
• 自動でスケーリング
• プログラムの実行時間で、課金される

Lambda

• 関数
  • 同期（プッシュ）
    • API Gateway
  • 非同期（呼び出したら終わり）
    • SNS
    • S3
  • ストリームベース
    • DynamoDB
    • Kinesis
• ランタイム：プログラムの実行環境
• イベント：イベントドリブン（何らかのトリガーによって実行される）

ユースケース

• データ処理（バッチ処理など）
• リアルタイムのストリーム処理
• バックエンド（アプリケーションとサービス）
• ITオートメーション

SAM

• サーバーレスアプリケーションの構築に使用されるオープンソースのフレームワーク
  • 単一のデプロイ設定
    • プログラムコードも書きながら、CloudFormationのコードも触れる
    • Lambda関数のソースコードと紐づけ

ラボ４：AWS SAM と CI/CD パイプラインを使用してサーバーレスアプリケーションをデプロイする

1. アプリケーションをビルドしてローカルでテスト
2. アプリケーションをパッケージ化してデプロイ
3. CI/CD パイプラインを自動化して、トラフィックシフトによるデプロイを設定
4. トラフィックシフトによるデプロイを実施

モジュール 8：デプロイ戦略

継続的デプロイ戦略

• インプレース
  • 今あるバージョンを置き換える
  • 置き換えるときにトラブルが発生した場合に備えて、ロールバック出来るようにしておかないと本番環境に影響がある
  • ただしデプロイまでが、他の手法に比べて早い
  • ダウンタイムが最小限
  • トラブルがなければ、一番安価で早くデプロイが可能な手法！
• ローリング
  • 一部を新バージョンへ更新、段階的に拡大
  • ダウンタイムなし
  • インプレースだと起こりえるリスクが軽減できる
• イミュータブル
  • 新バージョンのインフラを新規に立ち上げ
• ブルー・グリーン
  • 今あるバージョン（ブルー）
  • 新バージョン（グリーン）
  • 並列で新バージョンを入れ替え
    • ELB、Route53、Auto Scallingを使って行う

機能フラグを使ったダークローンチ

• ある条件のユーザーにのみ、本番環境で新機能をテスト
• 新しい機能を自由に、ON/OFF出来る方法でデプロイ
• 新機能のプレスリリースまでの時間

３日目

モジュール １０：セキュリティの自動化

DevSecOps

• セキュリティは、人ではなく、チーム・コミュニティの取り組み
• CI/CDのプロセスの一環
• コードを監査することではない
• ライフサイクルに影響を与えずに、構成要素を検証する

パイプライン自体のセキュリティ

• AWSの一般的なセキュリティのお話
• ユーザー管理
  • 誰がコミットできるか
  • 誰がビルドできるか
  • 誰がテスト・本番にデプロイできるか
• 最小権限
  • 条件・タグを使用
• 検出制御
  • 結果はセキュリティ警告として、メッセージに表示される
• インフラの制御

パイプライン内のセキュリティ

• セキュリティテストを自動化する

モジュール１１：構成管理

ツール

1. AWS Config
2. AWS Systems Manager
3. AWS CloudFormation
4. AWS OpsWorks（廃止予定）
5. AWS Service Catalog
6. Elastic Beanstalk
7. マシンイメージ

AWS Config

• 継続的監査とコンプライアンス
  • コンプライアンスフレームワーク
  • イミュータブルルール
  • サンプルコンフォ－マンスパックテンプレート

Systems Manager

• パッチマネージャー
  • セキュリティパッチの適用を自動化
  • Linuxの代替リポジトリを指定
  • パッチベースライン
  • 計画的なパッチ適用、アドホックなパッチ適用
• Automation
  • ランブックを作成（YAML or JSON）

マシンイメージ（AMI）

• EC2 Image Builderで自動化
• CodePipelineとCodeBuildを使用して、AMIの構築を自動化

ラボ５：CI/CD パイプラインと Amazon ECS を使用して Blue/Green デプロイ

1. AWS CodeBuild を使用してカスタムコンテナイメージを作成し、Amazon ECR に保存
2. AWS CodePipeline を使用してアプリケーションコンテナイメージの作成とビルドを自動化
3. Amazon ECS と AWS Fargate を使用してコンテナ化されたウェブアプリケーションをホストし、実行
4. Blue/Green デプロイを実行するように AWS CodeDeploy を設定
5. コンテナ Web アプリケーションのビルドとデプロイを自動化

モジュール 12: オブザーバビリティ

オブザーバビリティとモニタリングは別物

• オブザーバビリティ：日頃からデータを計測して、将来問題が起きないように先手の対策をするもの
  • Feedbackを受信し、データ分析を可能にする
  • カスタマーエクスペリエンス
• モニタリング：異常が起きてから、調査結果に基づいて対策するもの
  • メトリクス
    • CloudWatchメトリクス
    • 一定時間内に測定されたデータの数値表現
  • ログ
    • CloudWatchLogs
    • イベントのタイムスタンプ付きのイミュータブルな記録
    • 緊急で予測不可能な動作を発見するために使用
  • トレース
    • X-Rayトレース
    • 複数のサービスがあって、全体からどこに原因があるのか特定する場合に使用
    • エンドツーエンドのリクエストフローをエンコードする一連の分散イベントを表したもの
    • リクエストのパスと後続の両方を可視化

CloudWatch

• １５か月データが保存される
• デフォルトは標準のメトリクスが有効化される
• CloudWatch Logs
  • ログイベント
  • ログストリーム
  • ロググループ
• CloudWatch Logs Insights
  • ログの調査、分析、可視化
  • 従量制料金のログ分析サービス

X-Ray

• アプリケーション全体における、影響を具体的に特定
• AWSおよびAWS以外のサービスで機能

Amazon DevOps Guru

• 課題を自動で検出できる、機械学習を使用したサービス
• 機械学習の経験は不要
• 高価なダウンタイムの削減
• 現状のシステムで問題があるのかどうかわからない状態から、分析してもらって対応が出来る

ラボ６：CI/CD パイプラインの自動化に AWS DevOps ツールを使用する

最後のラボは、所用時間がなんと２時間になります！

1. リリースパイプラインのアーキテクチャを理解
2. AWS CodePipeline で失敗したステージの基本的なトラブルシューティングを行う
3. パイプラインのテスト結果に基づいて AWS インフラストラクチャの構成を調整
4. パイプラインのステージ間の変更を検証し、手動で承認
5. 既存の AWS CodePipeline ステージに新しいアクションを追加
6. AWS X-Ray コンソールで AWS Lambda 関数からのトレースイベントがないか調べる

おわりに

このトレーニングでは、ラボの時間がかなり多め、座学だけの時間が少なく、開発者向けの内容になっています。CloudFormation、CodeCommit/Buid/Deploy/Pipelineまで、一通り自動化の処理は、普段触ったことがない方もいるのではないでしょうか。

Cloud9とCodePipelineを駆使したハンズオンは楽しいです！開発者ではない私でもハンズオンは出来ましたので、気になる方はぜひ受講してみてください。

この記事がどなたかのお役に立てば幸いです。