AWS認定DevOpsエンジニアプロフェッショナルを受験した時の話

## この記事の概要
2022/07/03
**AWS認定DevOpsエンジニア – プロフェッショナル**
(AWS Certified DevOps Engineer - Professional (DOP-C01))
を受験したので、その時の記録

復習用ノートとして、また後で見返して今後の資格試験受験時の参考用にまとめます。

## 試験の概要

![aws_devops_professional.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/2bd20a37-a797-da8e-80bc-77e913231d60.png)

**プロフェッショナルレベル**の試験で、**CI/CD**など短い周期でリリースを繰り返す**アジャイルな開発のインフラ環境の構築や運用**などに関する知識が問われます。
この試験では「AWSインフラストラクチャとアプリケーションの**テストとデプロイを自動化**する能力が認定されます。」とのこと。
AWS公式より引用：[引用元](https://aws.amazon.com/jp/certification/certified-devops-engineer-professional/)

また、この試験は「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](https://aws.amazon.com/jp/certification/certified-devops-engineer-professional/)

## 勉強開始前の状態
AWSで動いているアプリの保守開発/運用の業務を5年程度、現在も継続中
AWS認定はこれまで5個取得済み

- [AWS認定ソリューションアーキテクトを受験した時の話](https://qiita.com/aminosan000/items/24c6dff9532658a5c4d5)
- [AWS認定デベロッパーアソシエイトを受験した時の話](https://qiita.com/aminosan000/items/89bc76f77626314f3182)
- [AWS認定SysOpsアドミニストレーターアソシエイトを受験した時の話](https://qiita.com/aminosan000/items/b1765260e8ad1435a366)
- [AWS認定ソリューションアーキテクトプロフェッショナルを受験した時の話](https://qiita.com/aminosan000/items/f172b7add8303926bddc)
- [AWS認定セキュリティ - 専門知識を受験した時の話](https://qiita.com/aminosan000/items/435fc411a4d10cf6ba43)

ここまできたら今年度は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) (日本語字幕版)](https://explore.skillbuilder.aws/learn/course/117/exam-readiness-aws-certified-devops-engineer-professional-japanese-ri-ben-yu-zi-mu-ban)
[Exam Readiness: AWS Certified DevOps Engineer – Professional (Japanese) (日本語実写版)](https://explore.skillbuilder.aws/learn/course/11332/exam-readiness-aws-certified-devops-engineer-professional-japanese-ri-ben-yu-shi-xie-ban)
※「日本語字幕版」は英語音声に日本語字幕、「日本語実写版」は日本人による日本語音声（内容は同じ）
![スクリーンショット 2022-07-02 23.59.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/fd3ba90a-4f30-2d3b-b653-7db725ad2c38.png)

**2. オンライン問題集(非公式)**
AWS認定受験時に毎回購入している「Whizlabs」
DevOpsのコースは最新のバージョンの問題が **520問(75問×5パターン+セクション問題が130問+お試し問題が15問)** 用意されています。
15.95USDからクーポン利用で30%offの11.16USD(日本円で¥1,444) でした。
いつもどおり、Google翻訳で翻訳しながら日本語が怪しい部分は原文とあわせながら利用。
[AWS Certified DevOps Engineer Professional | Whizlabs](https://www.whizlabs.com/aws-devops-certification-training/)
![スクリーンショット 2022-07-02 23.55.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/73c77bd2-4a69-a14a-92b8-616836f2bce2.png)

**4. AWS Black Belt Online Seminar過去動画**
[AWS サービス別資料 | AWS クラウドサービス活用資料集](https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/)
練習問題で理解度が怪しいと感じたサービスの過去動画を視聴。

**5. AWSアカウント**
練習問題の回答/解説やBlack Beltで学習したものを**実際にマネコンで触って**みる。
触ったことがあるのとないので理解度が大きく変わります。

**6. AWS公式模擬試験(Skill Builder)**
AWS Skill Builderで**20問の模擬試験を無料**で受けられます。
[AWS Certified DevOps Engineer - Professional Official Practice Question Set (DOP-C01 - Japanese)](https://explore.skillbuilder.aws/learn/course/12514/aws-certified-devops-engineer-professional-official-practice-question-set-dop-c01-japanese)
※2022/07現在Skill Builderのリンクから開始すると何故かDatabase Specialityの模試に飛ばされます、[このURL](https://awscertificationpractice.benchprep.com/app/aws-certified-devops-engineer-professional-official-practice-question-set?locale=ja-jp#exams)を直接開くと受験できます。

昨年までは公式の模擬試験は有料で、試験合格時に次回無料バウチャーが配布されていましたが、2021/11より公式模擬試験は無料で何度でも受けられるようになっています。去年のバウチャーがあったので試しにPSIの方も受けてみましたが、問題内容は全く同じでした。
![スクリーンショット 2022-06-19 19.50.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/7119ff83-bd41-d98f-a7a8-4733e84f545c.png)

勉強開始前にちょっと探してみたんですが、現時点(2022/07)で**日本語の対策本は発売されていない**ようでした。代わりにExam ReadinessやBlack Belt過去資料で体系的に学びながら、CodeシリーズやBeanstalkなどあまり触れてきていないAWSサービスにどんどん触っていきます。
実務である程度の知識はついているので問題集をやりながら覚えておきたいことや新しく知ったことを**ノートに書き出して、翌日学習開始時に一度なぞる**、を繰り返していきます。このページの後半はノートとして使った内容です。

## 勉強時間
**約65時間**
Exam ReadinessとWhizlabsは全て実施し、
復習や追加でBlack Beltのスライドを見ながら触って1ヶ月程度

## 受験後
結果は**スコア877で合格**、全問解き終わるのに**150分**、チェックを付けた問題の見直しに**30分**で時間いっぱいまで使って提出。
チェックを付けた問題も日本語が怪しかったりしてどちらとも取れる問題や、試験範囲に書かれていないサービスが回答に登場する問題(スコアに影響しない問題？)が多く、ある程度自信を持って終了できました。

![スクリーンショット 2022-07-04 20.30.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/4cca3972-ad1c-ed8b-2da9-3bc08e9457ac.png)

スコアパフォーマンスも「改善が必要」はなく満足😊
![スクリーンショット 2022-07-04 20.31.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/dc025685-b08e-773c-1a29-fbd940a73d2a.png)

証明書のデザインもいつのまにか**ダークカラー**に変わったようです。過去に取得した資格の証明書もいまDLするとこのデザインになっていました。
![スクリーンショット 2022-07-04 20.32.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/fe03a9bd-dc77-20f4-8f02-7619ed3e7b51.png)


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環境やワーカーなどの場合、選択肢に入る。
![スクリーンショット 2022-06-17 23.51.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/1bd6b73e-612b-3977-4455-48b7c826c9a0.png)

#### ローリングデプロイ
一部のインスンタンスに対して順にデプロイする、デプロイ中は一時的にInServiceなインスタンス数が減るが、ダウンタイムは発生しない。
![スクリーンショット 2022-06-17 23.51.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/c2f48351-affb-ec7b-6fc0-d7876b82ce76.png)

#### カナリアリリース
インスタンス一つだけ、や一定のパーセンテージだけ更新し、正常性確認が取れたら全体に適用する。
![スクリーンショット 2022-06-17 23.51.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/bff38153-80df-4da9-7b75-1efa05746d61.png)

#### ブルー/グリーンデプロイ
ダウンタイムを発生させず、InServiceな台数も減らさずに更新する。旧環境もすぐに停止(+削除)するので追加のコストもほとんど発生しない。可用性やロールバックのことを考えると、この方式が最も推奨される。AWS公式教材によるとA/Bデプロイも同義としている。
![スクリーンショット 2022-06-17 23.52.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/e03212fc-91c1-dcc6-f279-dedc03d2de02.png)

#### レッド/ブラックデプロイ
ブルー/グリーンとよく似ているが、新旧の環境が混在するタイミングを作らない。ブルー/グリーンと同義とする場合もあるが、AWS公式教材では別物としている。
![スクリーンショット 2022-06-17 23.54.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/083377e7-a00c-44cf-b93e-e2e5e38d1169.png)

#### イミュータブルアップグレード
上記のブルー/グリーンデプロイも旧ASG等を削除する場合、イミュータブルデプロイに属すると思うが、AWSでは環境全体を作り直す場合にこの言葉を使っている？
![スクリーンショット 2022-06-17 23.52.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/c9535895-87a2-d3d4-9817-28b234628ef1.png)

#### まとめ
![スクリーンショット 2022-06-17 23.53.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/d954cb58-ec32-526e-467d-4b88f6d67af3.png)

※資料はExam Readinessより引用

### AWS CloudFormation
CloudFormationおさらい
[AWS CloudFormation再入門](https://qiita.com/aminosan000/items/6a45d649f721bac988f8)

↑に書いていなかったので追加↓
- ドリフト検出：CloudFormation以外で加えられた変更を検出する機能
- 変更セット(Change set)：適用前に差分を確認する機能
- デザイナー：テンプレートをGUIで作成/確認する機能
- `AWS::AutoScaling::AutoScalingGroup`リソースの`UpdatePolicy`属性で`AutoScalingRollingUpdate`ポリシーを指定することで、ローリングアップデートができる

#### ヘルパースクリプト

https://dev.classmethod.jp/articles/cfn-helper-scripts/

#### スタックポリシー

スタックポリシーを利用するとスタックのリソースに対する意図しない更新や削除を防ぐことができる
リソースタイプやリソースの論理IDなどを指定し、更新のみ/削除のみ拒否などの定義ができる
保護されたリソースを更新したくなった場合、スタックポリシーをオーバーライドする一時ポリシーを作成することで一時的に保護を無効にさせることができる

参考: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/protect-stack-resources.html#stack-policy-intro-example

#### CreationPolicy

CreationPolicy属性を定義するとインスタンス作成後、一定の条件を満たさないと作成完了のステータスにならないようにすることができる
これにより、インスタンス上のデーモン立ち上げなどのブートストラップ動作完了を待って、次のリソース作成に進ませるなどができる
作成完了のシグナル送信にはヘルパースクリプトの`cfn-signal`またはSignalResource APIを利用する

参考: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-attribute-creationpolicy.html

#### テンプレートの検証
AWS CLIでテンプレートの構文チェックができる

```bash:example1
$ 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": []
}
```

```bash:example2
$ 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に対応

#### 構成要素

![スクリーンショット 2022-06-19 6.19.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/6880a3a2-e27f-573a-826b-994bd04533eb.png)

| 要素 | 説明 |
|:-|:-|
| アプリケーション | Beastalkのリソース定義の一番大きなくくりでバージョン、環境、環境設定が含まれる<br>ランタイムなどはアプリケーション単位で設定<br>アプリケーションは複数のバージョンを作成することができる |
| バージョン | S3上のアーティファクト単位、環境ごとにバージョンを切り替えられる |
| 環境 | 同一アプリケーション内で複数作ることができる |
| 環境設定 | 環境ごとの設定パラメータ、商用環境とほぼ同じ設定でサイズを小さくした検証環境を作成するなどに利用 |

#### 2つの環境タイプ

| タイプ | 説明 |
|:-|:-|
| 高可用性 | ELBやSQLとASGを組み合わせた環境、複数インスタンスで冗長化<br>トリガーにできるメトリクスはCPUUtiliztion, NetworkIn, Latency, DiskReadOps<br>統計はMax, Min, Sum, Average |
| 単一インスタンス | min/max両方1のASG、ただインスタンス1台ではない<br>ASGによりInServiceでなくなった場合作り直され、1台起動した状態が維持される |

#### EB CLI
通常のAWS CLIコマンドだけでなく、より高級なElastic Beanstalk専用のCLIが用意されている

```bash:AWS CLIの例
aws elasticbeanstalk create-environment --application-name hoge
```

```bash:EB CLIの例
eb create
```

#### 環境設定と.ebextensions

- 環境ごとに複数の項目で設定を行える
- 起動中の環境で使用している設定はS3に保存し再利用できる
- .ebextensionsを利用することでファイルのDLやサービスの実行など高度なカスタマイズができる
- Beanstalkの設定の優先順位は「CLI/SDK/マネコンでの変更 > .ebextensionsの設定 > デフォルト値」の順なのでCLIやマネコンで設定変更後.ebextensionsで値を変更しても反映されない

```bash:.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リソースを作成 |

```yaml:例: .ebextensions/packages.config
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サーバ環境」と「ワーカー環境」から選択することになる
![スクリーンショット 2022-07-03 0.15.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/e490c0ff-c17c-59d0-7738-b7801fa956c6.png)

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.json`v2を利用する

#### デプロイポリシー
Elastic Beanstalkでは5つのデプロイポリシーを設定できる
| デプロイポリシー | 説明 | 環境による制限 |
|:-|:-|:-|
| 1回にすべて(All at Once) | 全てのインスタンスを一括更新 | 制限なし |
| ローリング(Rolling) | バッチごとにELBから切離し、更新していく<br>ここでいう「バッチ」とは「バッチサイズ」として指定した割合の既存インスタンスのこと | ELBとASGが必要 |
| 追加バッチとローリング(Rolling with additional batch) | 更新対象のバッチを事前に追加してからデプロイする<br>アクティブなインスタンス数が100%を下回らないよう、指定したバッチサイズ分追加される | ELBとASGが必要 |
| 変更不可(Immutable) | 新規のASGを作成し、更新後インスタンスを立ち上げる | 制限なし |
| トラフィック分割(Traffic splitting) | 新規のASGを作成し、一部のクライアントからのリクエストのみ新しいバージョンに振り分ける<br>いわゆるカナリアデプロイ | ALB(NLB/CLBはNG)とASGが必要 |

ローリングデプロイは「ヘルスにもとづく更新」と「時間にもとづく更新」が選べる
いずれも、インプレース更新(公開中の一部インスタンスへ更新をかける)ため、新旧のバージョンが混在するタイミングが存在する
これを避けたい場合クローンを作成し、CNAMEをつけかえるというブルーグリーンデプロイが[公式](https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)でも推奨されている

Elastic Beanstalk参考リンク：
[AWS再入門ブログリレー2022 AWS Elastic Beanstalk編](https://dev.classmethod.jp/articles/2022_elasticbeanstalk_introduction/)
[AWS Elastic Beanstalkで使えるデプロイポリシーを理解する](
https://dev.classmethod.jp/articles/elastic-beanstalk-deploy-policy/)

### AWS OpsWorks

サーバの構成管理/運用を自動化する
OpsWorksは下記の3つに分かれている

- AWS OpsWorks Stacks
- AWS OpsWorks for Chef Automate
- AWS OpsWorks for Puppet Enterprise

#### OpsWorks Stacks

管理対象のインスタンス内にエージェントがインストールされ、このエージェントがChefレシピなどを実行する
そのため専用のサーバが必要ない

##### 構成要素

スタック＞レイヤー＞レシピ

![スクリーンショット 2022-06-19 7.28.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/d467e6e8-de5b-6b8f-93ee-877f8477865c.png)

| 要素 | 説明 |
|:-|:-|
| スタック | 複数のレイヤーを含む1環境 |
| レイヤー | LBやアプリケーション、DBなどの単位で分かれる |
| レシピ | 各レイヤーの構成定義 |

#### OpsWorksスタックのインスタンス
OpsWorksスタックのサーバインスタンスの管理方法は3種類ある
ワークロードに合わせこれらを組み合わせ、最適化する

| 管理方法 | 概要 |
|:-|:-|
| 24/7インスタンス | ユーザーが手動で起動し、ユーザーが手動で停止するまで実行される |
| 時間ベースのインスタンス | ユーザーが指定したスケジュールでAWS OpsWorksスタックによって自動的に起動および停止される |
| 負荷ベースのインスタンス | ユーザーが指定した負荷メトリクス(CPU、メモリ使用量など)のしきい値を超えたときに、AWS OpsWorksスタックによって自動的に起動および停止される |

https://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/best-practices-autoscale.html

#### AWS OpsWorks for Chef Automate

「Chef Automate」をマネージドで利用できる
下記のサーバ部分がAWS管理

![スクリーンショット 2022-06-19 7.37.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/c0da07ec-8cb5-c407-b291-eaee59d53898.png)

引用元：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公開鍵またはユーザ/パスワードの認証情報を登録することができる
![スクリーンショット 2022-06-19 20.31.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/0d166c89-25b8-5edf-b424-11a7eb25c182.png)

##### ユーザごとの権限

上記の方法でIAMユーザとローカルのGitユーザを紐付ける
リポジトリごとのアクセス権限をする場合、リポジトリにタグを付与し、IAMユーザやグループのアイデンティティベースポリシーで特定のリソースへの操作を拒否する

```json:ポリシー例
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "codecommit:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {"aws:ResourceTag/Department": "BigData"}
      }
    }
  ]
}
```

##### テンプレートのコミット

CodeCommitでリポジトリ作成時にテンプレートなどを追加する方法としてCloudFormationで指定したファイルを初期コミットとして含める方法がある

```yaml
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エンドポイントによる接続も可能

![スクリーンショット 2022-06-19 20.40.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/ce5986fd-134a-9604-ab3c-2261c54b8896.png)

| 単位 | 説明 |
|:-|:-|
| ドメイン | 複数のリポジトリを集約する、1環境につき1つ作成が推奨、複数のリポジトリに含まれるパッケージもドメインごとに1つだけ |
| リポジトリ | パッケージバージョンのセット、ドメインに格納されたパッケージにアクセスするためのエンドポイント |

パッケージバージョンの更新などをトリガーにCI/CDパイプラインを形成できる
![スクリーンショット 2022-06-19 20.49.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/69dff673-98d8-3190-c2d6-70fa1c51eca4.png)

引用元：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の例**
![スクリーンショット 2022-06-19 21.19.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/80eb7c8b-d152-cbfb-908a-d78299cb4fb1.png)

**buildspec.ymlの構成**
![スクリーンショット 2022-06-19 21.19.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/5f022d16-1435-8f17-ed2f-f73cc5b5d023.png)

**ビルドコマンド/スクリプトの記述**

buildspec.ymlの中でも実際のビルドコマンドやスクリプトを記述する`phases`については理解しておく必要がある
![スクリーンショット 2022-06-19 21.19.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/e2817635-999c-2706-8bb2-9f51233ba095.png)

引用元：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つでもデプロイできれば成功 |

:point_down: デプロイ設定選択画面
![スクリーンショット 2022-06-19 21.48.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/a6a51ec5-3d28-0b17-2ad0-a37506f8f943.png)

###### 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%を移行 |

:point_down: デプロイ設定選択画面
![スクリーンショット 2022-06-19 21.56.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/584be1f6-9c1e-7901-804b-9af89bba6d98.png)

###### 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パーセントを移行 |

:point_down: デプロイ設定選択画面
![スクリーンショット 2022-06-19 22.01.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/4681aa42-facd-4fc8-6217-fffc79d57e3f.png)

公式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/オンプレの場合のファイル構成
![スクリーンショット 2022-06-19 22.31.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/85baf393-9407-5034-4f56-3a591edbe481.png)

EC2/オンプレの場合のappspec.ymlの例
![スクリーンショット 2022-06-19 22.31.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/610f58d3-ee7c-4bc3-30fb-7a3d03fb8b22.png)

Lambdaの場合のappspec.ymlの例
![スクリーンショット 2022-06-19 22.35.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/76aa62d1-072d-14aa-46a8-0bf991539054.png)

Lambda(SAM)の場合のappspec.ymlの例
![スクリーンショット 2022-06-19 22.35.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/8702ba9b-c117-a845-ae75-95bfb65747da.png)

ECSの場合のappspec.ymlの例
![スクリーンショット 2022-06-19 22.38.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/da58c7e8-7193-f9ec-7fa3-16f9d86a8765.png)

#### AWS CodePipeline
CodeCommit, CodeBuild, CodeDeployなどのAWSサービス、またはJenkinsなどのサードパーティツールを組み合わせて一連のCI/CDパイプラインを作成、管理するサービス

##### 構成要素

| 名前 | 説明 |
|:-|:-|
| ステージ | ソース, ビルド, テスト実行などのパイプライン内のステップ |
| アクション | 各ステージ内の処理、ステージには1つ以上のアクションを必ず定義する |
| アーティファクト | ステージ間で受け渡す成果物、S3(アーティファクトストア)に保存する、デフォルトではバケット名`codepipeline-{region}-{12345EXAMPLE}`で自動作成される |
| トランジション | ステージの成功により次のステージに処理が移ること |
| パイプライン | 上記の一連の要素をまとめて1パイプライン |

![スクリーンショット 2022-06-19 23.54.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/ce9892fa-a7d3-3ba1-ebe2-dfccbf85695e.png)

##### 利用可能なプロバイダ

AWS CodeシリーズやJenkins、GHEなど複数のプロバイダをサポートしている
![スクリーンショット 2022-06-20 0.09.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/77b18dcd-0486-4caa-6157-0c053027c1a3.png)
![スクリーンショット 2022-06-20 0.11.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/70a9bab9-8fc5-36dd-38d4-018e25f86798.png)

また、LambdaやStep Functionsなどで自由度の高いアクションを定義することもできる

![スクリーンショット 2022-06-20 0.16.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/a8d9ddab-fa8a-5cbc-033f-cf3f5e86e879.png)

![スクリーンショット 2022-06-20 0.17.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/798e848a-b0ed-8161-bc44-38f9ca625add.png)

##### 承認(Approval)アクション
SNSやChatbotでE-mailやSlackへ通知し、次のアクションへ進むために手動の承認を必要とすることもできる

![スクリーンショット 2022-06-20 0.17.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/57db6e8d-826f-258a-3510-b984ce2f1f7d.png)

引用元: 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などをオーケストレーションできる

https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/what-is-control-tower.html

#### AWS Service Catalog
AWS Service Catalogは組織としてのガバナンスが適用された製品を、AWS利用者であるユーザー部門が早く簡単に立ち上げる事ができるサービス
管理アカウントで作成したCloudFormationテンプレートを「ポートフォリオ」に「製品」として登録し、その他のアカウントからこの「ポートフォリオ」を選択し「製品の起動」を行うことで自アカウント内にリソースを作成する
ポートフォリオごとに利用を許可する対象となる、IAMユーザ/グループ/ロールを指定できる

https://dev.classmethod.jp/articles/serca/

#### 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ユーザなどの単位で許可はできない

![スクリーンショット 2022-06-26 1.39.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/f0eda18c-25dc-300c-9c33-fd75a3bacd27.png)

##### クロスアカウントのログ共有

宛先アカウントでKinesisデータストリームを作成し、送信元アカウントでCloudWatch　Logsにクロスアカウントサブスクリプションを作成する
クロスアカウントサブスクリプションの宛先に指定できるのはKinesisデータストリームのみ

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/Cross-Account-Log_Subscription-New.html

#### 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へ通知させられる
![スクリーンショット 2022-06-21 22.25.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140013/117d6970-faef-24b3-2550-2d67e38eb6dd.png)

#### 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回後や何月何日何時）