LoginSignup
36
41

More than 1 year has passed since last update.

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

Last updated at Posted at 2022-07-04

この記事の概要

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

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

試験の概要

aws_devops_professional.png

プロフェッショナルレベルの試験で、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認定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) (日本語実写版)
※「日本語字幕版」は英語音声に日本語字幕、「日本語実写版」は日本人による日本語音声(内容は同じ)
スクリーンショット 2022-07-02 23.59.12.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
スクリーンショット 2022-07-02 23.55.41.png

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-06-19 19.50.39.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

スコアパフォーマンスも「改善が必要」はなく満足😊
スクリーンショット 2022-07-04 20.31.14.png

証明書のデザインもいつのまにかダークカラーに変わったようです。過去に取得した資格の証明書もいまDLするとこのデザインになっていました。
スクリーンショット 2022-07-04 20.32.23.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

ローリングデプロイ

一部のインスンタンスに対して順にデプロイする、デプロイ中は一時的にInServiceなインスタンス数が減るが、ダウンタイムは発生しない。
スクリーンショット 2022-06-17 23.51.32.png

カナリアリリース

インスタンス一つだけ、や一定のパーセンテージだけ更新し、正常性確認が取れたら全体に適用する。
スクリーンショット 2022-06-17 23.51.58.png

ブルー/グリーンデプロイ

ダウンタイムを発生させず、InServiceな台数も減らさずに更新する。旧環境もすぐに停止(+削除)するので追加のコストもほとんど発生しない。可用性やロールバックのことを考えると、この方式が最も推奨される。AWS公式教材によるとA/Bデプロイも同義としている。
スクリーンショット 2022-06-17 23.52.26.png

レッド/ブラックデプロイ

ブルー/グリーンとよく似ているが、新旧の環境が混在するタイミングを作らない。ブルー/グリーンと同義とする場合もあるが、AWS公式教材では別物としている。
スクリーンショット 2022-06-17 23.54.48.png

イミュータブルアップグレード

上記のブルー/グリーンデプロイも旧ASG等を削除する場合、イミュータブルデプロイに属すると思うが、AWSでは環境全体を作り直す場合にこの言葉を使っている?
スクリーンショット 2022-06-17 23.52.56.png

まとめ

スクリーンショット 2022-06-17 23.53.50.png

※資料はExam Readinessより引用

AWS CloudFormation

CloudFormationおさらい
AWS CloudFormation再入門

↑に書いていなかったので追加↓

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

ヘルパースクリプト

スタックポリシー

スタックポリシーを利用するとスタックのリソースに対する意図しない更新や削除を防ぐことができる
リソースタイプやリソースの論理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でテンプレートの構文チェックができる

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": []
}
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

要素 説明
アプリケーション 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 CLIの例
aws elasticbeanstalk create-environment --application-name hoge
EB CLIの例
eb create

環境設定と.ebextensions

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

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レシピなどを実行する
そのため専用のサーバが必要ない

構成要素

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

スクリーンショット 2022-06-19 7.28.02.png

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

OpsWorksスタックのインスタンス

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

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

AWS OpsWorks for Chef Automate

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

スクリーンショット 2022-06-19 7.37.47.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

ユーザごとの権限

上記の方法で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エンドポイントによる接続も可能

スクリーンショット 2022-06-19 20.40.21.png

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

パッケージバージョンの更新などをトリガーにCI/CDパイプラインを形成できる
スクリーンショット 2022-06-19 20.49.55.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

buildspec.ymlの構成
スクリーンショット 2022-06-19 21.19.27.png

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

buildspec.ymlの中でも実際のビルドコマンドやスクリプトを記述するphasesについては理解しておく必要がある
スクリーンショット 2022-06-19 21.19.51.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

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

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

公式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

EC2/オンプレの場合のappspec.ymlの例
スクリーンショット 2022-06-19 22.31.22.png

Lambdaの場合のappspec.ymlの例
スクリーンショット 2022-06-19 22.35.10.png

Lambda(SAM)の場合のappspec.ymlの例
スクリーンショット 2022-06-19 22.35.54.png

ECSの場合のappspec.ymlの例
スクリーンショット 2022-06-19 22.38.48.png

AWS CodePipeline

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

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

スクリーンショット 2022-06-19 23.54.36.png

利用可能なプロバイダ

AWS CodeシリーズやJenkins、GHEなど複数のプロバイダをサポートしている
スクリーンショット 2022-06-20 0.09.49.png
スクリーンショット 2022-06-20 0.11.17.png

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

スクリーンショット 2022-06-20 0.16.56.png

スクリーンショット 2022-06-20 0.17.06.png

承認(Approval)アクション

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

スクリーンショット 2022-06-20 0.17.54.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などをオーケストレーションできる

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

スクリーンショット 2022-06-26 1.39.06.png

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

宛先アカウントで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へ通知させられる
スクリーンショット 2022-06-21 22.25.56.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回後や何月何日何時)
36
41
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
36
41