この記事の概要
2022/07/03
AWS認定DevOpsエンジニア – プロフェッショナル
(AWS Certified DevOps Engineer - Professional (DOP-C01))
を受験したので、その時の記録
復習用ノートとして、また後で見返して今後の資格試験受験時の参考用にまとめます。
試験の概要
プロフェッショナルレベルの試験で、CI/CDなど短い周期でリリースを繰り返すアジャイルな開発のインフラ環境の構築や運用などに関する知識が問われます。
この試験では「AWSインフラストラクチャとアプリケーションのテストとデプロイを自動化する能力が認定されます。」とのこと。
AWS公式より引用：引用元
また、この試験は「AWS Certified Developer - Associate」と「AWS Certified SysOps Administrator - Associate」の上位試験のため、この試験に合格することで下位2資格の期限も更新されます。
参考: https://aws.amazon.com/jp/certification/recertification/
◼︎ 試験要項
問題数 ：75問
試験時間 ：180分
受験料 ：¥30,000(税別)
合格ライン：100~1000点中750点(約72%)
受験資格 ：なし
有効期限 ：3年
◼︎ 出題範囲
| 分野 | 出題割合 |
|---|---|
| 第 1 分野: SDLC のオートメーション | 22% |
| 第 2 分野: 構成管理と Infrastructure as Code | 19% |
| 第 3 分野: モニタリングとロギング | 15% |
| 第 4 分野: ポリシーと標準のオートメーション | 10% |
| 第 5 分野: インシデントとイベントへの対応 | 18% |
| 第 6 分野: 高可用性、耐障害性、災害対策 | 16% |
2022/07時点の最新バージョン(Ver.2.1) のものです。
バージョンアップで範囲等は変更されるので、受験時は公式で確認してください。
AWS Certified DevOps Engineer - Professional 認定 | AWS 認定 | AWS
勉強開始前の状態
AWSで動いているアプリの保守開発/運用の業務を5年程度、現在も継続中
AWS認定はこれまで5個取得済み
- AWS認定ソリューションアーキテクトを受験した時の話
- AWS認定デベロッパーアソシエイトを受験した時の話
- AWS認定SysOpsアドミニストレーターアソシエイトを受験した時の話
- AWS認定ソリューションアーキテクトプロフェッショナルを受験した時の話
- AWS認定セキュリティ - 専門知識を受験した時の話
ここまできたら今年度はAWS認定12冠を目指したくなったので、そのまとめも別の記事として書こうと思います。
勉強に使ったもの
1. Exam Readiness: AWS Certified DevOps Engineer – Professional (Japanese)
AWS Skill Builderで無料で提供されている「AWS認定DevOpsエンジニア–プロフェッショナル試験」対策のAWS公式トレーニング、練習問題を解きながら試験範囲についてすごく丁寧に動画で教えてくれる学習教材です。基本的に公式がこういったウェビナーやホワイトペーパーなどで謳っていることが正解なので、まずはじめに受講することをおすすめします。
Exam Readiness: AWS Certified DevOps Engineer – Professional (Japanese) (日本語字幕版)
Exam Readiness: AWS Certified DevOps Engineer – Professional (Japanese) (日本語実写版)
※「日本語字幕版」は英語音声に日本語字幕、「日本語実写版」は日本人による日本語音声（内容は同じ）
2. オンライン問題集(非公式)
AWS認定受験時に毎回購入している「Whizlabs」
DevOpsのコースは最新のバージョンの問題が 520問(75問×5パターン+セクション問題が130問+お試し問題が15問) 用意されています。
15.95USDからクーポン利用で30%offの11.16USD(日本円で¥1,444) でした。
いつもどおり、Google翻訳で翻訳しながら日本語が怪しい部分は原文とあわせながら利用。
AWS Certified DevOps Engineer Professional | Whizlabs
4. AWS Black Belt Online Seminar過去動画
AWS サービス別資料 | AWS クラウドサービス活用資料集
練習問題で理解度が怪しいと感じたサービスの過去動画を視聴。
5. AWSアカウント
練習問題の回答/解説やBlack Beltで学習したものを実際にマネコンで触ってみる。
触ったことがあるのとないので理解度が大きく変わります。
6. AWS公式模擬試験(Skill Builder)
AWS Skill Builderで20問の模擬試験を無料で受けられます。
AWS Certified DevOps Engineer - Professional Official Practice Question Set (DOP-C01 - Japanese)
※2022/07現在Skill Builderのリンクから開始すると何故かDatabase Specialityの模試に飛ばされます、このURLを直接開くと受験できます。
昨年までは公式の模擬試験は有料で、試験合格時に次回無料バウチャーが配布されていましたが、2021/11より公式模擬試験は無料で何度でも受けられるようになっています。去年のバウチャーがあったので試しにPSIの方も受けてみましたが、問題内容は全く同じでした。
勉強開始前にちょっと探してみたんですが、現時点(2022/07)で日本語の対策本は発売されていないようでした。代わりにExam ReadinessやBlack Belt過去資料で体系的に学びながら、CodeシリーズやBeanstalkなどあまり触れてきていないAWSサービスにどんどん触っていきます。
実務である程度の知識はついているので問題集をやりながら覚えておきたいことや新しく知ったことをノートに書き出して、翌日学習開始時に一度なぞる、を繰り返していきます。このページの後半はノートとして使った内容です。
勉強時間
約65時間
Exam ReadinessとWhizlabsは全て実施し、
復習や追加でBlack Beltのスライドを見ながら触って1ヶ月程度
受験後
結果はスコア877で合格、全問解き終わるのに150分、チェックを付けた問題の見直しに30分で時間いっぱいまで使って提出。
チェックを付けた問題も日本語が怪しかったりしてどちらとも取れる問題や、試験範囲に書かれていないサービスが回答に登場する問題(スコアに影響しない問題？)が多く、ある程度自信を持って終了できました。
スコアパフォーマンスも「改善が必要」はなく満足😊
証明書のデザインもいつのまにかダークカラーに変わったようです。過去に取得した資格の証明書もいまDLするとこのデザインになっていました。
DevOpsということでダウンタイムを減らしたり、少ない管理コストでCI/CDパイプラインを維持していくのに必要な知識を中心に、他のAWS認定と同様Well-Architectedに沿ったサービスの組み合わせを選定する問題が出題されます。
CloudFormation, Codeシリーズ, Elastic Beanstalk, OpsWorks, CloudWatch, AWS Configなど、開発ツールと監視/運用ツールの出題が多く、試験の立ち位置通り「AWS Certified Developer - Associate」と「AWS Certified SysOps Administrator - Associate」を足したような内容でした。
また、Git, Docker, JenkinsなどのAWS以外の技術に関連する出題もあるので、このあたりの知識があると少し合格しやすくなると思います。
例: 「Gitでマスターと検証用ブランチを作成してマスターへのマージは上級エンジニアの承認を必須にしたい」など
勉強ノート
試験のために勉強しながらまとめたノート
※ここに書いてあることは、あくまで私が理解が足りないと感じ、覚えたかったことだけです。試験範囲を網羅はしていません。
デプロイ戦略
デプロイ戦略とデプロイ方式はさまざまだが、この試験においてはAWSの公式トレーニングで提示されている6つを頭に入れておけば良い。
インプレースデプロイ
最もシンプルでコストと時間のかからない方式、ダウンタイムを許容できるCI/CD環境やワーカーなどの場合、選択肢に入る。
ローリングデプロイ
一部のインスンタンスに対して順にデプロイする、デプロイ中は一時的にInServiceなインスタンス数が減るが、ダウンタイムは発生しない。
カナリアリリース
インスタンス一つだけ、や一定のパーセンテージだけ更新し、正常性確認が取れたら全体に適用する。
ブルー/グリーンデプロイ
ダウンタイムを発生させず、InServiceな台数も減らさずに更新する。旧環境もすぐに停止(+削除)するので追加のコストもほとんど発生しない。可用性やロールバックのことを考えると、この方式が最も推奨される。AWS公式教材によるとA/Bデプロイも同義としている。
レッド/ブラックデプロイ
ブルー/グリーンとよく似ているが、新旧の環境が混在するタイミングを作らない。ブルー/グリーンと同義とする場合もあるが、AWS公式教材では別物としている。
イミュータブルアップグレード
上記のブルー/グリーンデプロイも旧ASG等を削除する場合、イミュータブルデプロイに属すると思うが、AWSでは環境全体を作り直す場合にこの言葉を使っている？
まとめ
※資料はExam Readinessより引用
AWS CloudFormation
CloudFormationおさらい
AWS CloudFormation再入門
↑に書いていなかったので追加↓
- ドリフト検出：CloudFormation以外で加えられた変更を検出する機能
- 変更セット(Change set)：適用前に差分を確認する機能
- デザイナー：テンプレートをGUIで作成/確認する機能
-
AWS::AutoScaling::AutoScalingGroupリソースのUpdatePolicy属性でAutoScalingRollingUpdateポリシーを指定することで、ローリングアップデートができる
ヘルパースクリプト
スタックポリシー
スタックポリシーを利用するとスタックのリソースに対する意図しない更新や削除を防ぐことができる
リソースタイプやリソースの論理IDなどを指定し、更新のみ/削除のみ拒否などの定義ができる
保護されたリソースを更新したくなった場合、スタックポリシーをオーバーライドする一時ポリシーを作成することで一時的に保護を無効にさせることができる
CreationPolicy
CreationPolicy属性を定義するとインスタンス作成後、一定の条件を満たさないと作成完了のステータスにならないようにすることができる
これにより、インスタンス上のデーモン立ち上げなどのブートストラップ動作完了を待って、次のリソース作成に進ませるなどができる
作成完了のシグナル送信にはヘルパースクリプトのcfn-signalまたはSignalResource APIを利用する
テンプレートの検証
AWS CLIでテンプレートの構文チェックができる
$ aws cloudformation validate-template --template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/S3_Bucket.template
{
"Description": "AWS CloudFormation Sample Template S3_Bucket: Sample template showing how to create a publicly accessible S3 bucket. **WARNING** This template creates an S3 bucket.
You will be billed for the AWS resources used if you create a stack from this template.",
"Parameters": [],
"Capabilities": []
}
$ aws cloudformation validate-template --template-body file:///home/local/test/sampletemplate.json
{
"ResponseMetadata": {
"RequestId": "4ae33ec0-1988-11e3-818b-e15a6df955cd"
},
"Errors": [
{
"Message": "Template format error: JSON not well-formed. (line 11, column 8)",
"Code": "ValidationError",
"Type": "Sender"
}
],
"Capabilities": [],
"Parameters": []
}
A client error (ValidationError) occurred: Template format error: JSON not well-formed. (line 11, column 8)
StackSets
複数アカウント/複数リージョンをまたいだ組織でのリソース管理
- StackSetsを利用すると1つのCloudFormationテンプレートで複数のリージョン/複数のアカウントに同一のリソースを一括で作成できる
- 複数のアカウントへのリソース作成は「管理者アカウント」で行う
- ターゲットアカウント(リソース作成先)と管理者アカウントの間に信頼関係を事前に設定する
- 特定のアカウントや特定のリージョンのみリソースを削除することもできる
コスト配分タグ(Cost Allocation Tags)
コスト配分タグを利用することで、リソースにかかっている利用料を細かく追跡できる
コスト配分タグは下記の2種類に分けられる
| 種類 | キー | 概要 | 例 |
|---|---|---|---|
| AWS生成のタグ | aws:から始まる | AWSまたはマーケットプレイスのベンダーに定義されている | aws:createdBy=Root:123456789 |
| ユーザ定義タグ | user:から始まる | ユーザが定義/作成/運用する | user:Stack=prd |
- それぞれのタグはコスト管理コンソールでアクティブにすることで、その後自動付与される
- AWS生成のタグはOrganizationsの場合管理アカウントのでのみアクティブにできる
- ユーザ定義タグはタグエディターでの作成が推奨
AWS Elastic Beanstalk
アプリケーションを実行するインフラの管理(構築/更新/監視など)を簡潔化するサービス
ELB、ASG、EC2、その上で動くOS、ミドルウェア、ランタイム、コードのデプロイ戦略などまとめて管理する
Java、.NET、PHP、Node.js、Python、Ruby、Go、Dockerに対応
構成要素
| 要素 | 説明 |
|---|---|
| アプリケーション | Beastalkのリソース定義の一番大きなくくりでバージョン、環境、環境設定が含まれる ランタイムなどはアプリケーション単位で設定 アプリケーションは複数のバージョンを作成することができる |
| バージョン | S3上のアーティファクト単位、環境ごとにバージョンを切り替えられる |
| 環境 | 同一アプリケーション内で複数作ることができる |
| 環境設定 | 環境ごとの設定パラメータ、商用環境とほぼ同じ設定でサイズを小さくした検証環境を作成するなどに利用 |
2つの環境タイプ
| タイプ | 説明 |
|---|---|
| 高可用性 | ELBやSQLとASGを組み合わせた環境、複数インスタンスで冗長化 トリガーにできるメトリクスはCPUUtiliztion, NetworkIn, Latency, DiskReadOps 統計はMax, Min, Sum, Average |
| 単一インスタンス | min/max両方1のASG、ただインスタンス1台ではない ASGによりInServiceでなくなった場合作り直され、1台起動した状態が維持される |
EB CLI
通常のAWS CLIコマンドだけでなく、より高級なElastic Beanstalk専用のCLIが用意されている
aws elasticbeanstalk create-environment --application-name hoge
eb create
環境設定と.ebextensions
- 環境ごとに複数の項目で設定を行える
- 起動中の環境で使用している設定はS3に保存し再利用できる
- .ebextensionsを利用することでファイルのDLやサービスの実行など高度なカスタマイズができる
- Beanstalkの設定の優先順位は「CLI/SDK/マネコンでの変更 > .ebextensionsの設定 > デフォルト値」の順なのでCLIやマネコンで設定変更後.ebextensionsで値を変更しても反映されない
~/workspace/app/
├── .ebextensions
│ ├── environmentvariables.config
│ └── healthcheckurl.config
├── .elasticbeanstalk
│ └── config.yml
├── index.php
.ebextensionsで実行可能な操作(Linux)
| 操作 | 内容 |
|---|---|
| packages | yum/rubygems/python/rpmを利用したパッケージのインストール、インストール順序は保証されない |
| sources | 外部からアーカイブをDLして指定した場所に展開 |
| files | 指定した場所にファイルを作成 |
| services | serviceを起動したり、起動設定を変更したりする |
| users/groups | 任意のユーザ/グループを作成 |
| commands | デプロイ処理前に実行するコマンドやスクリプト |
| container_commands | 新バージョンの展開後に実行するコマンドやスクリプト |
| option_settings | 環境変数の設定 |
| Resources | 追加のAWSリソースを作成 |
packages:
yum:
libmemcached: []
ruby-devel: []
gcc: []
rpm:
epel: http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
rubygems:
chef: '0.10.2'
環境枠
環境は作成時に「Webサーバ環境」と「ワーカー環境」から選択することになる
Webサーバ環境: https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/concepts-webserver.html
ワーカー環境: https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/concepts-worker.html
DBレイヤーの分離
Elastic Beanstalkでは環境内でRDSインスタンスを実行することもできるが、DBインスタンスのライフサイクルがアプリケーションに結びついてしまうため、データを永続化する必要がある本番環境の場合は環境の外部にRDSインスタンスを作成し、追加する方式が推奨される
参考: https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.managing.db.html
ECSマネージドDocker
- Elastic BeanstalkではECSを利用したDocker環境のデプロイに対応している
- ECSマネージドDockerの定義は
Dockerrun.aws.jsonに記述する - マルチコンテナの場合
Dockerrun.aws.jsonv2を利用する
デプロイポリシー
Elastic Beanstalkでは5つのデプロイポリシーを設定できる
| デプロイポリシー | 説明 | 環境による制限 |
|---|---|---|
| 1回にすべて(All at Once) | 全てのインスタンスを一括更新 | 制限なし |
| ローリング(Rolling) | バッチごとにELBから切離し、更新していく ここでいう「バッチ」とは「バッチサイズ」として指定した割合の既存インスタンスのこと |
ELBとASGが必要 |
| 追加バッチとローリング(Rolling with additional batch) | 更新対象のバッチを事前に追加してからデプロイする アクティブなインスタンス数が100%を下回らないよう、指定したバッチサイズ分追加される |
ELBとASGが必要 |
| 変更不可(Immutable) | 新規のASGを作成し、更新後インスタンスを立ち上げる | 制限なし |
| トラフィック分割(Traffic splitting) | 新規のASGを作成し、一部のクライアントからのリクエストのみ新しいバージョンに振り分ける いわゆるカナリアデプロイ |
ALB(NLB/CLBはNG)とASGが必要 |
ローリングデプロイは「ヘルスにもとづく更新」と「時間にもとづく更新」が選べる
いずれも、インプレース更新(公開中の一部インスタンスへ更新をかける)ため、新旧のバージョンが混在するタイミングが存在する
これを避けたい場合クローンを作成し、CNAMEをつけかえるというブルーグリーンデプロイが公式でも推奨されている
Elastic Beanstalk参考リンク：
AWS再入門ブログリレー2022 AWS Elastic Beanstalk編
AWS Elastic Beanstalkで使えるデプロイポリシーを理解する
AWS OpsWorks
サーバの構成管理/運用を自動化する
OpsWorksは下記の3つに分かれている
- AWS OpsWorks Stacks
- AWS OpsWorks for Chef Automate
- AWS OpsWorks for Puppet Enterprise
OpsWorks Stacks
管理対象のインスタンス内にエージェントがインストールされ、このエージェントがChefレシピなどを実行する
そのため専用のサーバが必要ない
構成要素
スタック＞レイヤー＞レシピ
| 要素 | 説明 |
|---|---|
| スタック | 複数のレイヤーを含む1環境 |
| レイヤー | LBやアプリケーション、DBなどの単位で分かれる |
| レシピ | 各レイヤーの構成定義 |
OpsWorksスタックのインスタンス
OpsWorksスタックのサーバインスタンスの管理方法は3種類ある
ワークロードに合わせこれらを組み合わせ、最適化する
| 管理方法 | 概要 |
|---|---|
| 24/7インスタンス | ユーザーが手動で起動し、ユーザーが手動で停止するまで実行される |
| 時間ベースのインスタンス | ユーザーが指定したスケジュールでAWS OpsWorksスタックによって自動的に起動および停止される |
| 負荷ベースのインスタンス | ユーザーが指定した負荷メトリクス(CPU、メモリ使用量など)のしきい値を超えたときに、AWS OpsWorksスタックによって自動的に起動および停止される |
AWS OpsWorks for Chef Automate
「Chef Automate」をマネージドで利用できる
下記のサーバ部分がAWS管理
引用元：https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-aws-opsworks
外部クックブック
Gitリポジトリでホストされているオープンソースのクックブックを利用したい場合、依存関係を管理するBerkshelfというクックブックを実装する
参考: https://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/cookbooks-101-opsworks-berkshelf.html
AWS Codeシリーズ
AWS CodeCommit
Gitリモートリポジトリをホスティングする
GitオブジェクトはS3、GitインデックスはDynamoDBに保存される
IAMによる認証やSNSトピックへのイベント通知など、いくつかのAWSサービスと統合されている
VPCエンドポイントによる接続も可能
基本的にはGitHubなどの一般的なGitリモートリポジトリと同じ
認証情報
IAMコンソールからユーザを選択し、ユーザごとにSSH公開鍵またはユーザ/パスワードの認証情報を登録することができる
ユーザごとの権限
上記の方法でIAMユーザとローカルのGitユーザを紐付ける
リポジトリごとのアクセス権限をする場合、リポジトリにタグを付与し、IAMユーザやグループのアイデンティティベースポリシーで特定のリソースへの操作を拒否する
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "codecommit:*",
"Resource": "*",
"Condition": {
"StringEquals": {"aws:ResourceTag/Department": "BigData"}
}
}
]
}
テンプレートのコミット
CodeCommitでリポジトリ作成時にテンプレートなどを追加する方法としてCloudFormationで指定したファイルを初期コミットとして含める方法がある
MyRepo:
Type: AWS::CodeCommit::Repository
Properties:
RepositoryName: MyDemoRepo
RepositoryDescription: This is a repository for my project with code from MySourceCodeBucket.
# Code属性でコミットさせるファイルの場所を指定する
# 初期コミット専用のため、作成済みのリポジトリに後からCode属性を追加しても反映されない
Code:
BranchName: development
S3:
Bucket: MySourceCodeBucket
Key: MyKey
ObjectVersion: 1
AWS CodeArtifact
Maven, Gradle, npm, yarn, twine, pipなどのビルドツール、パッケージマネージャで利用するパッケージリポジトリを自身のAWSアカウント内に作成できる
VPCエンドポイントによる接続も可能
| 単位 | 説明 |
|---|---|
| ドメイン | 複数のリポジトリを集約する、1環境につき1つ作成が推奨、複数のリポジトリに含まれるパッケージもドメインごとに1つだけ |
| リポジトリ | パッケージバージョンのセット、ドメインに格納されたパッケージにアクセスするためのエンドポイント |
パッケージバージョンの更新などをトリガーにCI/CDパイプラインを形成できる
引用元：https://www.youtube.com/watch?v=rqy_wluHDe0
AWS CodeBuild
アプリケーションのビルドやUT実行などをマネージドの環境で行える
ビルド処理は都度新しいDockerコンテナで実行される
ビルド環境
ビルドを実行する環境としてAWS管理のイメージまたはカスタムイメージを指定できる
AWS管理のイメージはUbuntuまたはWindows Server
カスタムイメージはECRやDockerHubなどのレジストリを指定しDockerイメージを利用
buildspec.yml
ビルド処理などの設定はYAMLで定義する
buildspec.ymlの例
buildspec.ymlの構成
ビルドコマンド/スクリプトの記述
buildspec.ymlの中でも実際のビルドコマンドやスクリプトを記述するphasesについては理解しておく必要がある
引用元：https://www.youtube.com/watch?v=rqy_wluHDe0
AWS CodeDeploy
デプロイを自動化するマネージドサービス
EC2, ECS, Lambda, オンプレ環境へのデプロイが可能
デプロイの失敗を検知した際やアラームの閾値を超えた際に、自動的にロールバックさせることもできる
構成要素
| 名前 | 説明 |
|---|---|
| アプリケーション | デプロイするアプリケーション、デプロイ先のプラットフォーム(EC2/Lambdaなど)を1つ定義する |
| デプロイグループ | デプロイ環境の定義、dev/stg/prdなど環境ごとにわける |
デプロイタイプ
EC2の場合In-PlaceまたはBlue/Greenからデプロイ方式を選択できる
Lambda/ECSの場合Blue/Greenのみ
デプロイ設定
デプロイする割合やデプロイ成功/失敗の条件を決める
独自のデプロイ設定(Healthyなインスタンスが最低75%など)も作成可能
EC2またはオンプレ
| 名前 | 説明 |
|---|---|
| CodeDeployDefault.OneAtATime | 1インスタンスずつデプロイする、デプロイグループ全体へのデプロイで成功、ただし最後のインスタンスのみ失敗は無視される |
| CodeDeployDefault.HalfAtATime | デプロイグループ全体の半分(端数切捨て)ずつデプロイする、半分以上のデプロイで成功 |
| CodeDeployDefault.AllAtOnce | デプロイグループ全体に対し同時にデプロイする、1つでもデプロイできれば成功 |
デプロイ設定選択画面
ECS
ECSの場合、更新後のECSタスクセットへのトラフィック移行方法が異なる
Canary(カナリア),Linear(線形),AllAtOnce(一括)の3種類がある
| 名前 | 説明 |
|---|---|
| CodeDeployDefault.ECSAllAtOnce | 全てのトラフィックを一度に移行 |
| CodeDeployDefault.ECSLinear10PercentEvery1Minutes | 毎分トラフィックの10%を移行 |
| CodeDeployDefault.ECSLinear10PercentEvery3Minutes | 3分ごとにトラフィックの10%を移行 |
| CodeDeployDefault.ECSCanary10Percent5Minutes | まずトラフィックの10%を移行、5分後に残り90%を移行 |
| CodeDeployDefault.ECSCanary10Percent15Minutes | まずトラフィックの10%を移行、15分後に残り90%を移行 |
デプロイ設定選択画面
Lambda
Lambdaの場合、更新後のLambda関数バージョンへのトラフィック移行方法が異なる
Canary(カナリア),Linear(線形),AllAtOnce(一括)の3種類がある
ECSより少し細かく設定できる
| 名前 | 説明 |
|---|---|
| CodeDeployDefault.LambdaAllAtOnce | 全てのトラフィックを一度に移行 |
| CodeDeployDefault.LambdaLinear10PercentEvery1Minute | 毎分トラフィックの10%を移行 |
| CodeDeployDefault.LambdaLinear10PercentEvery2Minutes | 2分ごとにトラフィックの10%を移行 |
| CodeDeployDefault.LambdaLinear10PercentEvery3Minutes | 3分ごとにトラフィックの10%を移行 |
| CodeDeployDefault.LambdaLinear10PercentEvery10Minutes | 10分ごとにトラフィックの10%を移行 |
| CodeDeployDefault.LambdaCanary10Percent5Minutes | まずトラフィックの10%を移行、5分後に残り90パーセントを移行 |
| CodeDeployDefault.LambdaCanary10Percent10Minutes | まずトラフィックの10%を移行、10分後に残り90パーセントを移行 |
| CodeDeployDefault.LambdaCanary10Percent15Minutes | まずトラフィックの10%を移行、15分後に残り90パーセントを移行 |
| CodeDeployDefault.LambdaCanary10Percent30Minutes | まずトラフィックの10%を移行、30分後に残り90パーセントを移行 |
デプロイ設定選択画面
公式Docs: https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/deployment-configurations.html
リビジョンとターゲットリビジョン
EC2の場合、ソースコード等のデプロイ対象+appspecファイルをまとめたアーカイブ、Lambda, ECSの場合、appspecファイルがリビジョンとなる
デプロイグループへデプロイする対象をターゲットリビジョンと呼ぶ
デプロイの動作
デプロイグループにASGを指定することで、スケールアウト時にリビジョンが自動でデプロイされる
ライフサイクルイベントにHookを指定し、スクリプトを実行できる
Hookが失敗した時やCloudWatchアラームを検知した場合、数秒でロールバックできる
appspec.yml
EC2/オンプレの場合のファイル構成
EC2/オンプレの場合のappspec.ymlの例
Lambdaの場合のappspec.ymlの例
Lambda(SAM)の場合のappspec.ymlの例
ECSの場合のappspec.ymlの例
AWS CodePipeline
CodeCommit, CodeBuild, CodeDeployなどのAWSサービス、またはJenkinsなどのサードパーティツールを組み合わせて一連のCI/CDパイプラインを作成、管理するサービス
構成要素
| 名前 | 説明 |
|---|---|
| ステージ | ソース, ビルド, テスト実行などのパイプライン内のステップ |
| アクション | 各ステージ内の処理、ステージには1つ以上のアクションを必ず定義する |
| アーティファクト | ステージ間で受け渡す成果物、S3(アーティファクトストア)に保存する、デフォルトではバケット名codepipeline-{region}-{12345EXAMPLE}で自動作成される |
| トランジション | ステージの成功により次のステージに処理が移ること |
| パイプライン | 上記の一連の要素をまとめて1パイプライン |
利用可能なプロバイダ
AWS CodeシリーズやJenkins、GHEなど複数のプロバイダをサポートしている
また、LambdaやStep Functionsなどで自由度の高いアクションを定義することもできる
承認(Approval)アクション
SNSやChatbotでE-mailやSlackへ通知し、次のアクションへ進むために手動の承認を必要とすることもできる
引用元: https://www.youtube.com/watch?v=31-w23SdOAs&feature=youtu.be
AWS CodeStar
多数の言語の様々なプロジェクトテンプレートからアプリケーションを簡単に作成できる
テンプレートを選択するとCI/CDパイプラインも自動で作成され、デリバリーパイプラインの管理を簡潔にする
CodeCommit, CodeDeploy, CodePipelineのリソースを自動的に作成してくれる
ダッシュボード
プロジェクトを管理するためのダッシュボードが作成される
このダッシュボードはJiraと統合されており、連携を設定することでダッシュボード上でチケットを確認できる
ユーザごとの権限管理
CodeStarは自動的に役割ごとのIAMポリシーを作成する
"Owner", "Contributor", "Viewer"などの役割を割り当てることで簡単に権限を制限することができる
AWS Control Tower
複数アカウントをまとめて管理するプロセスを簡潔化するためのサービス
AWS Organizations、AWS Service Catalog、AWS Single Sign-Onなどをオーケストレーションできる
AWS Service Catalog
AWS Service Catalogは組織としてのガバナンスが適用された製品を、AWS利用者であるユーザー部門が早く簡単に立ち上げる事ができるサービス
管理アカウントで作成したCloudFormationテンプレートを「ポートフォリオ」に「製品」として登録し、その他のアカウントからこの「ポートフォリオ」を選択し「製品の起動」を行うことで自アカウント内にリソースを作成する
ポートフォリオごとに利用を許可する対象となる、IAMユーザ/グループ/ロールを指定できる
AWS Server Migration Service(SMS)
- ViatualBoxはサポートしない
AWS Data Lifecycle Manager(DLM)
- EBSスナップショットとEBS-backed AMIの作成、保持、削除を自動化できる
- 特定のタグの付いたリソースをターゲットとする
- DLMで作成されたスナップショット/AMIには専用のタグが付与され、このタグにより他のスナップショット/AMIと区別される
- ライフサイクルポリシーとして対象やスケジュールを定義する
Amazon QuickSight
- AWSサービスやJira, SalesForceなどの複数のソースに対しクエリできるマネージドのBIサービス
- IAMやSAMLによるユーザ認証ができる
- iFrameのURLを埋め込むことでSaaSなどでQuickSightの情報を表示可能
DAX
- キャッシュによりDynamoDBの読み込みパフォーマンスを10倍に高める
- 読み込みの多いワークロードに向いている、書き込みが多い場合には適さない
- リージョン内での冗長化、フェイルオーバーなど自動で行ってくれるフルマネージドサービス
CloudWatch
CloudWatchイベントバス
イベントバスを利用することで他のAWSアカウントとイベントを送受信する事ができる
イベントバスに許可できる対象
- 特定のアカウント
- 特定のOrganizations
- 全てのアカウント
※アカウント内のIAMユーザなどの単位で許可はできない
クロスアカウントのログ共有
宛先アカウントでKinesisデータストリームを作成し、送信元アカウントでCloudWatch Logsにクロスアカウントサブスクリプションを作成する
クロスアカウントサブスクリプションの宛先に指定できるのはKinesisデータストリームのみ
AWS Compute Optimizer
EC2やASGのメトリクスと設定データを機械学習で分析して、コスト削減とパフォーマンス向上のための推奨事項を生成
Amazon EC2 Auto Scaling
Auto Scalingグループはパフォーマンス/コストの最適化や復旧の自動化、デプロイサイクル最適化に役立つため、細かい設定についても知っておく必要がある。
ライフサイクルフック
ASGではインスタンスの起動/終了時にカスタムアクションを実行できるように、ライフサイクルフックを設定できる
例： タスク実行中に終了させないために、タスクが終わるまで「Terminationg:Wait」ステータスにする
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/ec2-auto-scaling-lifecycle.html
プロセスの中断と再開
ASGの各プロセスは個別に中断および再開できる
例：スケーリング自体を停止、スケーリングによって増えたインスタンスのELBへのアタッチを停止など
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-suspend-resume-processes.html
終了ポリシー
ASGでは終了ポリシーによってスケールイン時に優先して終了するインスタンスの条件を指定できる
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-instance-termination.html#common-scenarios-termination
https://dev.classmethod.jp/articles/auto-scaling-termination-policy/
アクティビティ通知
アクティビティ通知を設定することにより、対象のASGでアクティビティが発生した際にSNSへ通知させられる
AWS License Manager
ソフトウェアベンダー（Microsoft、SAP、Oracle、IBMなど）が提供するソフトウェアライセンスを、AWSとオンプレミス環境との間で一元的に管理することを容易にするサービス
Lambda@Edge
Lambda@Edgeを利用することでエッジロケーションでコンピューティングを行わせることできる
フロントエンド/バックエンドの処理を書き換えずにCDNのみでA/Bテストのロジックも実現できる
具体的な方法は下記URL参照
参考: https://medium.com/@lorenzo.nicora/a-b-testing-on-aws-cloudfront-with-lambda-edge-a22dd82e9d12
AWS Data Pipeline
- DynamoDB, S3などの相互のデータ複製ができる
- スケジュールを設定し、定期的に実行させることもできる
- スケジュールには繰り返しの終了を設定できる（n回後や何月何日何時）