AWS DevOps エンジニア プロフェッショナル 受験記

AWS

f:id:jotaki:20200105065609p:plain

これまで・今回の結果

受験理由・モチベーション

ここまでやったら取りたいなの精神で。

今回分の勉強計画

合格記を見ているとSAP取れればDOPも取れる風潮がありますが、SAA → DVAのときになかなか苦戦したので、そこは信じずこれまで通り公式リソース + koiwaclub で行こうと思いました。
またSAPはダラダラやってしまったので、今回は2ヶ月で仕留められるように予定を組みました。
※ 結果は約3ヶ月

やったこと

  • 【公式】Exam Readiness: AWS Certified DevOps Engineer – Professional
  • 【公式】サンプル問題の受験・復習
  • 【読書】ポケットスタディ AWS認定 デベロッパーアソシエイト
  • 【問題集】koiwaclub の DOP問題集
  • 【公式】模擬試験の受験・復習
  • 【公式】BlackBelt Online（YouTube中心に）

【公式】Exam Readiness: AWS Certified DevOps Engineer – Professional

SAPのときのおじさんではなくて残念でしたが、DOPのほうが細かく動画での説明されていました。
ただ量も多いので誤訳などもちょくちょくあり頭に入りづらかった印象です。
だいたいの範囲はここで把握しました。

【公式】サンプル問題の受験・復習

4月の中旬に最初に解いてみて3/10。
おそらく今までで一番取れていないので長くなりそうだな・・・と思いました。

試験当日にもう一度解いてみて8/10。
ちょっといけるかもと思いました。

【読書】ポケットスタディ AWS認定 デベロッパーアソシエイト

感想
DVAのときこんなに覚えたかなというくらいには細かく載っているので、DOP対策にもなるんじゃないかと思いました。

3ヶ月だいたい寝る前に読んで3周。

【問題集】koiwaclub の DOP問題集

7問1セットの計47セットを2周。

【公式】模擬試験の受験・復習

koiwaを1周した5/9に受けてみる。

総合スコア: 55%
1.0 SDLC Automation: 75%
2.0 Configuration Management and Infrastructure as Code: 33%
3.0 Monitoring and Logging: 66%
4.0 Policies and Standards Automation: 66%
5.0 Incident and Event Response: 0%
6.0 High Availability, Fault Tolerance, and Disaster Recovery : 100%

難しくスコアもひどいものでしたが、DOPはそんなもんという記事を見ていたので平静を装いました。
Incident and Event Response は CloudWatch Events あたりが主なのでその後は少し意識して勉強。

【公式】BlackBelt Online（YouTube中心に）

受験前日6/4に一通りみる。

覚えたこと

主に Exam Readiness や koiwaclub で頻出するものなどは公式ドキュメントなど見て復習。
NRIネットコムさんの AWS 認定 DevOps エンジニア – プロフェッショナル(AWS Certified DevOps Engineer – Professional)の学習方法 も参考にしました。

  • AMI
    • 事前作成のAMI
    • ゴールデンイメージ
  • AutoScaling
    • AMI の起動設定
    • ライフサイクルフック
  • Beanstalk
  • API Gateway
    • リリース手法
    • エラーシューティング
  • CloudFormation
    • テンプレート構文（Parameters, Conditions, Mappings, Outputs..）
    • DeletionPolicy
    • カスタムリソース
    • デプロイ対象（Auto Scaling Group, Lambda）
    • デプロイ手法とロールバック
    • CodePipeline を使ったデプロイ
  • CodePipeline
    • CloudWatch Events との連携
    • カスタムアクション
  • CodeCommit
    • IAMポリシー
    • ブランチとステージ
  • CodeDeploy
    • デプロイ対象（Auto Scaling Group, Lambda）
    • デプロイ手法とロールバック
    • CodePipeline を使ったデプロイ
  • CloudWatch
    • Logsのカスタムメトリクス
    • Eventsでできること
  • Systems Manager
    • Automation
    • Run Command
    • Patch Manager
  • Trusted Advisor
    • CloudWatch Events との統合
    • サービス制限
    • キー漏洩時の対応
  • その他
    • ECS/ECR
    • Config + Lambda, GuardDuty, Inspector
    • Health Dashboard
    • Service Catalog

本試験

オンラインで受験。
2回目の再受験が無料キャンペーン をしていたので、最近そこまで身が入ってなかったけど1回受けてみようと考えました。

2hちょっとで一通り完了してトイレ行きたくてすぐに終了。
手応えは、

30%: 正解
20%: たぶん正解
40%: 微妙
10%: 不正解

のような感じ。

結果スコアは845点とのこと。思ったより取れてました。
分野ごとの成績がPDFに入ってなかったけどまだ処理中なのかもです。

まとめ

振り返ってみると4月頭から勉強していたのでそれなりの勉強量だったのですが、ここ何週間かサボってしまっていたので、合格と出たときは受かっちゃったなーという感想。これまでで一番手応えない内容でした。

プラクティショナー → アソシエイト → プロフェッショナルの順で6個目とれました。
SAP取れたときにも感じましたが取る前にイメージしていた理解度には到底及んでいなく、勉強すればするほど分からないことも増えていきます。

調子乗ってSCSとか受けるとまた沼にハマるので、本当にここでAWS資格はおしまいです。
3年後の更新はそのとき考えます・・・

【読書メモ】ポケットスタディ AWS認定 デベロッパーアソシエイト

読書メモ AWS

ポケットスタディ AWS認定 デベロッパーアソシエイト (アソシエイト試験ポケットスタディ)

ポケットスタディ AWS認定 デベロッパーアソシエイト (アソシエイト試験ポケットスタディ)

  • 作者:山下光洋
  • 発売日: 2021/03/09
  • メディア: 単行本

DOP資格対策として、今月発売のDVA対策本を読みました。

目次

SECTION1は試験概要。
SECTION2〜6が各カテゴリーに準じたサービスや機能の解説+章末のサンプル問題。
SECTION7は50問の問題集です。

ボリュームとしてはかなり豊富で細かく各サービスの機能やAPIまで網羅されている印象です。
章末のサンプル問題（復習用の問題）も数が豊富で、各章読み込まないと答えられないものになっているので基礎知識の習得に向いていると感じます。

良かった点

  • DVA試験に必要と思われるサービスや解説が網羅されている
  • 章末のサンプル問題で解説されていた知識の定着ができる
  • 重要な機能説明には設定・構築手順がマネジメントコンソールのキャプチャ付きで解説されている
  • API名、メトリクス名、ポリシー、コードなど細かく記載されている

悪かった点

  • ポケットスタディシリーズ共通かもしれませんが、見出しが分かりづらい
  • キャプチャの一部が低解像度になっている

感想

網羅範囲としては値段に相反してかなり広くボリュームも多く感じました。
DVA→SAPの順で受験済みですが、SAPの際に知った移行の6つのRなども掲載されているので、むしろDVAの範囲にとどまっていない印象です。
試験対策本ですが、開発系サービスの基礎知識の向上や概要を知りたいためのリファレンスにも使えるのではないかと思います。

今回に限らずですが、AWSでできることが多すぎる分どこまで勉強しても果てしないな..という感想。
設定手順がキャプチャ付きで掲載されているので、CloudWatchエージェントはSystems Managerでインストールするんだなど新しい発見も多々ありました。

特にアーキテクト試験の設計系とデベロッパー試験の開発系で扱う範囲や覚えることの粒度みたいなものも変わるので、その頭の切り替えにはとても良い本でした。

Nuxt.js + AWS ECS Fargate その4（まとめ）

フロントエンド AWS Nuxt.js

f:id:jotaki:20210321165648p:plain

GitHub

https://github.com/yuheijotaki/nuxt-fargate_app

これまでの記事

構成

f:id:jotaki:20210325162129p:plain

  1. Nuxt.js（SSR）のコードを GitHub にプッシュするとCodePipelineが走る。
  2. CodeBuild でイメージをビルド。ECRへイメージを登録
  3. CodeBuild の成功を受けてタスク・サービスの更新。
  4. ECS（Fargate）が ECR からイメージ取得。
  5. CodeDeploy が ECS（Fargate）へデプロイ。

f:id:jotaki:20210325161454p:plain

VPC内はコンテナタスクを各サブネットに配置しALBで分散する。

感想

当初AWSサービスを使ってアプリを公開するところまでしてみたいなという気持ちから、 Nuxt.js + Ruby on Rails + AWS Fargate の開発・デプロイチュートリアル を本の内容通りに構築することを検討していました。
ただ最初のRubyのDB設定のところでつまづきまくり、バックエンド構築を理解したいわけでもないしなぁ..と考え直し、今回の Nuxt.js + ECS + CodePipeline という構成でやってみる形になりました。

大枠の感想としては、資格勉強はあまり役には立っていないかもなというのという気持ち半分、意外と何日か触れば一通りはできるものだなという気持ち半分と言った所です。

実際には考慮するべき点が多くあると思っています。

  • サービスのスケール面
    • ALBのターゲットグループの設定内容
    • DockerのCPU,メモリ等の設定内容
  • アプリケーション設定
    • DNS設定
    • nuxt.config.js
  • ビルド&デプロイ設定
    • テスト
    • ステージングや本番環境などステージごとのデプロイ
  • セキュリティ
    • ググりながらやってみたものの、特にタスク定義ロールなどの理解が乏しい

このようなことをやってみると、インフラエンジニアや開発エンジニアの方はこれらの考慮点なども含め構築されていると思うので、改めてすごいなということでした。
特にCodeDeployの権限周りをかなりググりながら進めましたが、AWSのドキュメントで日本語訳が追いついていないものやエラー内容が引っかからないなどあり検索能力や基礎知識が足りていないなと実感もしました。

ただほんわりとしか分かっていなかったコンテナというそのものであったり、CodePipelineの設定などを実際にやってみて、多少は理解は進んだという感触もあるので次回また何かしらに生かしていきたいと思います。

Nuxt.js + AWS ECS Fargate その3（CI/CD環境作成）

フロントエンド AWS Nuxt.js

f:id:jotaki:20210321165648p:plain

前回に続いてAWSのCodePipelineを使用してCI/CD環境を作成しようと思います。

アプリケーションコードのリポジトリはGitHubを使用しているので、GitHub Actionsでもできるようですが、そちらは一度触ったことがありAWSサービスの理解を深めたいので今回はAWSサービスを使用してみます。

ECS → CodeDeploy だけでECRリポジトリにプッシュされた際にデプロイ実行をできますが、CodePipeline を使って少し実戦的にやってみました。

参考にしたのは下記の記事などです。

パイプラインを作成

ECS > クラスター > 該当のサービスを選択 > 「デプロイメント」タブ > パイプラインを作成

# Step1 パイプラインの設定を選択する
パイプライン名: nuxt-fargate-pipeline
サービスロール: 新しいサービスロール
ロール名: AWSCodePipelineServiceRole-ap-northeast-1-nuxt-fargate-pipeline

# Step2 ソースステージを追加する
ソースプロバイダー: GitHub（バージョン2）
接続 → 接続名: 任意のもの
リポジトリ: 該当リポジトリ
ブランチ名: master
ソースコードの変更時にパイプラインを開始する: チェック

# Step3 ビルドステージを追加する
プロバイダーを構築する: AWS CodeBuild
リージョン: アジアパシフィック（東京）

## ビルドプロジェクト
プロジェクト名: nuxt-fargate-build
オペレーティングシステム: Amazon Linux
ランタイム: Standard
イメージ: 最新のもの
イメージのバージョン: 最新のもの
環境タイプ: Linux
Docker権限付与: チェック
サービスロール: 新しいサービスロール
ロール名: codebuild-nuxt-fargate-build-service-role

## 環境変数
AWS_ACCOUNT_ID: <アカウントID>
AWS_DEFAULT_REGION: ap-northeast-1
REPOSITORY_NAME: nuxt-fargate_app
REPOSITORY_URI: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com
IMAGE_TAG: latest

# Step4 デプロイステージを追加する
デプロイプロバイダー: Amazon ECS（ブルー/グリーン）
リージョン: アジアパシフィック（東京）
入力アーティファクト: BuildArtifact
AWS CodeDeploy アプリケーション名: nuxt-fargate-deploy
AWS CodeDeploy デプロイグループ: nuxt-fargate-deploy-group
Amazon ECS タスク定義: BuildArtifact
AWS CodeDeploy AppSpec ファイル: BuildArtifact
入力アーティファクトを持つイメージの詳細: BuildArtifact
タスク定義のプレースホルダー文字: IMAGE1_NAME

サービスロールの設定

ECRにアクセスできるようにCodeBuildのサービスロールを設定する。

CodeBuild > ビルドプロジェクト > 該当のプロジェクト > 「ビルドの詳細」タブ > 環境 > サービスロール
のARNをクリックし、 AmazonEC2ContainerRegistryPowerUser ポリシーをアタッチする。

参考： 【備忘録】CodeBuildでaws ecr get-loginコマンド実行時にエラーが発生する - Qiita

設定ファイルの準備

GitHub

  • buildspec.yml: ビルド設定ファイル
  • appspec.yaml: ECSサービスに含めるタスク定義の設定ファイル
  • task-definition.json: デプロイするタスク定義の設定ファイル

ビルドしてみて、エラー参考にググってみたいにしてなんとかビルド成功しました。
雰囲気はGitHub ActionsやNetlifyと同じですが、コンソール内の権限周りが悪いのか、コードの記述が分からなくてハマってしまいました。
10回もしないうちにDockerのRate Limitに引っかかったので、下記の対策を行うなどを推奨します。

参考： Docker Hub の Rate Limitに引っかかったのでdocker loginで対策した - fu3ak1's tech days

確認

以上の手順でパイプライン作成。
masterにプッシュしたら、ECRリポジトリにプッシュされ、ビルドしたイメージがALBにデプロイされる。
次回はこれまでのまとめを兼ねて構成図等で振り返りをして終わりにしようと思います。

Nuxt.js + AWS ECS Fargate その2（ALBとECS Fargate展開）

フロントエンド AWS Nuxt.js

f:id:jotaki:20210321165648p:plain

前回に引き続きAWS側の設定を行っていきます。
コンテナのタスク、サービスについては改めて理解するため下記が参考になりました。
基礎から応用までじっくり学ぶECS Fargateを利用したコンテナ環境構築 #Fargate | DevelopersIO

構築手順の参考にした記事は Amazon Fargate でコンテナを動かす - Qiita になります。

ALB の構築

Application Load Balancer を作成。
関係ないですが、ALBがEC2のメニューの中にあること、Gateway Load Balancer という新しい種類のロードバランサーがあるのを初めて知りました。

# ロードバランサーの設定
名前: nuxt-fargate-load-balancer
スキーム: インターネット向け
リスナー: HTTP:80
VPC: デフォルトVPC
AZ: ap-northeast-1a, ap-northeast-1c のサブネット

# セキュリティグループの設定
セキュリティグループ名: nuxt-fargate-sg
タイプ: カスタムTCP
プロトコル: TCP
ポート範囲: 80
ソース: カスタム 0.0.0.0/0, ::/0

# ルーティングの設定
ターゲットグループの名前: nuxt-fargate-target-group
ターゲットの種類: IP
プロトコル: HTTP
ポート: 80

f:id:jotaki:20210322130752p:plain

ECS Fargate設定

タスク → クラスター → サービスの順で作成。
認定試験勉強でもごっちゃになるやつですが、クラメソさんの下記の説明が個人的には一番しっくりきます。

  • ECS クラスタ → 以下のサービスとタスクの器、かたまり
  • ECS サービス → タスク（以下）を指定し、何個起動するのか指定、ALBと関連付けするもの
  • ECS タスク → CPU/メモリの割り当て、ポート設定などDockerコンテナの起動方法を指定する設定書みたいなもの

タスク実行ロールを作成（ない場合）

事前にロール ecsTaskExecutionRole がない場合は作成しておく。
※ Amazon ECS タスク実行 IAM ロール の「タスク実行 IAM ロールの作成」通りに作成する。

タスク定義の作成

ECS > タスク定義 > 新しいタスク定義の作成 > FARGATE を選択

# タスクとコンテナの定義の設定
タスク定義名: nuxt-fargate-task
タスクロール: ecsTaskExecutionRole
タスクメモリ (GB): 0.5GB
タスク CPU (vCPU): 0.25vCPU

## コンテナの追加
コンテナ名: nuxt-fargate-container
イメージ: <イメージURI>
ポートマッピング: 80

イメージURIはECRのイメージURI ***.dkr.ecr.ap-northeast-1.amazonaws.com/*** を入力

f:id:jotaki:20210322130807p:plain

クラスターの作成

ECS > クラスター > クラスターの作成 > FARGATE を選択

# クラスターの設定
クラスター名: nuxt-fargate-cluster

f:id:jotaki:20210322130819p:plain

サービスの作成

ECS > クラスター > 「サービス」タブ > 作成

# サービスの設定
起動タイプ: FARGATE
タスク定義: nuxt-fargate-task
クラスター: nuxt-fargate-cluster
サービス名: nuxt-fargate-service
タスクの数: 2
最小ヘルス率: 50
最大率: 200

# ネットワーク構成
クラスター VPC: デフォルトVPC
サブネット: ap-northeast-1a, ap-northeast-1c
ロードバランサーの種類: ALB
ロードバランサー名: nuxt-fargate-load-balancer

## ロードバランス用のコンテナ
プロダクションリスナーポート: 80:HTTP
ターゲットグループ名: nuxt-fargate-target-group

f:id:jotaki:20210322130832p:plain

確認

EC2 > ロードバランサー > 該当のELB選択 > DNS名
http://nuxt-fargate-load-balancer-*******.ap-northeast-1.elb.amazonaws.com/ にアクセスするとサイトが無事表示されました。

f:id:jotaki:20210322131341p:plain

表示されない場合は、

  • ECS > クラスター > タスク > ステータスが RUNNING になっている
  • EC2 > ターゲットグループ > 該当のターゲットグループ選択 > Targets > Statsが healthy になっている

かを確認して unhealthy などになっていればトラブルシューティングを行う。

最初、ALBのターゲットの種類をインスタンスで設定してしまい、unhealthy でサイトも表示されないままになってしまいました。
ALBの作成、ECSの設定を再度Qiitaの記事参考にやり直して2回目で無事表示できました。
VPCやセキュリティグループも触るの試験勉強のハンズオン以来でしたが、とりあえず表示させる所までできてよかったです。

Nuxt.js + AWS ECS Fargate その1（Nuxt.jsアプリ作成〜ECRリポジトリへのプッシュ）

フロントエンド AWS Nuxt.js

f:id:jotaki:20210321165648p:plain

トレンドのVuejs/NuxtをAws ECS, FargateでSSR、詳細解説します🚀 の記事を参考に進めてみる。

ローカル環境 使用バージョン

  • Node.js: 12.11.0
  • AWS CLI: 2.1.31

Nuxt.js アプリの作成

create nuxt-app で作成します。

$ yarn create nuxt-app nuxt-fargate_app
yarn create v1.13.0
create-nuxt-app v3.6.0
...

設定項目は下記のようにしました。
Fargateで動かすのでRendering modeはUniversalを指定。
しばらく触ってないと細々変わりますね。。

? Project name: nuxt-fargate_app
? Programming language: JavaScript
? Package manager: Npm
? UI framework: None
? Nuxt.js modules: (Press <space> to select, <a> to toggle all, <i> to invert selection)
? Linting tools: (Press <space> to select, <a> to toggle all, <i> to invert selection)
? Testing framework: None
? Rendering mode: Universal (SSR / SSG)
? Deployment target: Server (Node.js hosting)
? Development tools: (Press <space> to select, <a> to toggle all, <i> to invert selection)
? What is your GitHub username? yuhei jotaki
? Version control system: Git

Dockerfile を使用してイメージを作成

Docker 向けに package.json の scripts を調整する。

  ...
  "scripts": {
    "dev": "HOST=0.0.0.0 PORT=3000 nuxt",
    "build": "nuxt build",
    "start": "HOST=0.0.0.0 PORT=3000 nuxt start",
    "generate": "nuxt generate"
  },
  ...

Dockerfile をプロジェクトディレクトリに作成して下記のようにする。
Node.jsのバージョンは 公式のイメージ を参考にする。

FROM node:12

RUN mkdir -p /var/www/nuxt-fargate_app
WORKDIR /var/www/nuxt-fargate_app
COPY ./ /var/www/nuxt-fargate_app
RUN npm run build

EXPOSE 3000

ENTRYPOINT ["npm", "run", "start"]

次にDockerアプリをrunningにする。
その後ビルドしてイメージが作成できているか確認。

$ docker build -t nuxt-fargate_app .
...
Successfully tagged nuxt-fargate_app:latest
$ docker images
REPOSITORY                 TAG              IMAGE ID       CREATED          SIZE
nuxt-fargate_app           latest           XXXXX   39 seconds ago   1.03GB
...

起動してみる。
ここはあまり分かってないですが、 0.0.0.0:3000 でアクセスできたのでOKなのかな

$ docker run -d -p 3000:3000 nuxt-fargate_app
...
$ docker ps
CONTAINER ID   IMAGE              COMMAND           CREATED          STATUS          PORTS                    NAMES
61f86de41a7a   nuxt-fargate_app   "npm run start"   21 seconds ago   Up 19 seconds   0.0.0.0:3000->3000/tcp   amazing_yalow

ECRでリポジトリを作成してイメージをプッシュする

AWS ECR > リポジトリ作成をする。
今回は nuxt-fargate_app というリポジトリ名にしました。

その後コマンドで認証してイメージをプッシュする。
それぞれつまづきましたが、認証は get-login は現在非推奨のため get-login-password が良いとのことで Amazon ECR での AWS CLI の使用 - Amazon ECR を参考にしました。
※ 後々振り返ると、ECRコンソール内 > リポジトリ > 該当リポジトリを選択 > プッシュコマンドの表示 にもコマンドが書いてありました。

# <profile-name>: ~/.aws/credentials のプロファイルの名前
# <app-name>: nuxt-fargate_app
# <aws-region-name>: ap-northeast-1
# <aws-account-id>: アカウントID

# ユーザー切り替え
$ export AWS_DEFAULT_PROFILE=<profile-name>

# 認証トークンを取得し、レジストリに対して Docker クライアントを認証します。
$ aws ecr get-login-password | docker login --username AWS --password-stdin https://<aws-account-id>.dkr.ecr.<aws-region-name>.amazonaws.com

# Docker イメージを構築します。
$ docker build -t <app-name>:latest .

# 構築が完了したら、このリポジトリにイメージをプッシュできるように、イメージにタグを付けます。
$ docker tag <app-name>:latest <aws-account-id>.dkr.ecr.<aws-region-name>.amazonaws.com/<app-name>:latest

# 新しく作成した AWS リポジトリにこのイメージをプッシュします。
$ docker push <aws-account-id>.dkr.ecr.<aws-region-name>.amazonaws.com/<app-name>:latest

以上でイメージをプッシュできました。

f:id:jotaki:20210321165218p:plain

AWSのコンソールやCLI最近あまり触る機会がなかったですが、CLIのバージョンアップやプロファイルの切り替え等々つまづくところが多かったです。
正直あまり分かってない部分も多いですが、次回以降はECSの設定になりそうですので引き続き更新できたらと思います。