AWS DevOps エンジニア プロフェッショナル 受験記
これまで・今回の結果
- 2019/6/8 CLF 合格 830点
- 2019/7/6 SAA 不合格 630点
- 2020/1/4 SAA 合格 771点
- 2020/2/9 DVA 合格 845点
- 2020/2/14 SOA 合格 801点
- 2020/7/24 SAP 不合格 730点
- 2020/8/8 SAP 不合格 723点
- 2020/8/23 SAP 不合格 730点 ※システム不具合により試験スコア無効
- 2021/1/3 SAP 不合格 730点
- 2021/2/13 SAP 合格 862点
- 2021/6/5 DOP 合格 845点 ※今回分
受験理由・モチベーション
ここまでやったら取りたいなの精神で。
今回分の勉強計画
合格記を見ていると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に一通りみる。
- CodeStar & CodePipeline
- CodeCommit & CodeArtifact
- CodeBuild
- CodeDeploy
- CloudFormation
- CloudWatch
- Systems Manager
- EC2 Auto Scaling and AWS Auto Scaling
- Deployment on AWS
覚えたこと
主に 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年後の更新はそのとき考えます・・・
2021年3月 振り返り
結果
ブログ
目標:月 8 回(週2回)更新
結果:月 10 回 更新
読書
目標:月 1 冊
結果:月 3 冊
反省点など
満遍なくインプットできました。
来月に向けて
AWS資格と並行しつつフロントエンド領域もとなると難しいですがなんとかやっていきたいです。
【読書メモ】ポケットスタディ AWS認定 デベロッパーアソシエイト

ポケットスタディ AWS認定 デベロッパーアソシエイト (アソシエイト試験ポケットスタディ)
- 作者:山下光洋
- 発売日: 2021/03/09
- メディア: 単行本
DOP資格対策として、今月発売のDVA対策本を読みました。
目次
- SECTION1 AWS認定デベロッパーアソシエイト
- SECTION2 展開(デプロイ)
- SECTION3 セキュリティ
- SECTION5 リファクタリング
- SECTION6 モニタリングとトラブルシューティング
- SECTION7 本試験想定問題集
SECTION1は試験概要。
SECTION2〜6が各カテゴリーに準じたサービスや機能の解説+章末のサンプル問題。
SECTION7は50問の問題集です。
ボリュームとしてはかなり豊富で細かく各サービスの機能やAPIまで網羅されている印象です。
章末のサンプル問題(復習用の問題)も数が豊富で、各章読み込まないと答えられないものになっているので基礎知識の習得に向いていると感じます。
良かった点
- DVA試験に必要と思われるサービスや解説が網羅されている
- 章末のサンプル問題で解説されていた知識の定着ができる
- 重要な機能説明には設定・構築手順がマネジメントコンソールのキャプチャ付きで解説されている
- API名、メトリクス名、ポリシー、コードなど細かく記載されている
悪かった点
- ポケットスタディシリーズ共通かもしれませんが、見出しが分かりづらい
- キャプチャの一部が低解像度になっている
感想
網羅範囲としては値段に相反してかなり広くボリュームも多く感じました。
DVA→SAPの順で受験済みですが、SAPの際に知った移行の6つのRなども掲載されているので、むしろDVAの範囲にとどまっていない印象です。
試験対策本ですが、開発系サービスの基礎知識の向上や概要を知りたいためのリファレンスにも使えるのではないかと思います。
今回に限らずですが、AWSでできることが多すぎる分どこまで勉強しても果てしないな..という感想。
設定手順がキャプチャ付きで掲載されているので、CloudWatchエージェントはSystems Managerでインストールするんだなど新しい発見も多々ありました。
特にアーキテクト試験の設計系とデベロッパー試験の開発系で扱う範囲や覚えることの粒度みたいなものも変わるので、その頭の切り替えにはとても良い本でした。
Nuxt.js + AWS ECS Fargate その4(まとめ)
GitHub
https://github.com/yuheijotaki/nuxt-fargate_app
これまでの記事
構成
- Nuxt.js(SSR)のコードを GitHub にプッシュするとCodePipelineが走る。
- CodeBuild でイメージをビルド。ECRへイメージを登録
- CodeBuild の成功を受けてタスク・サービスの更新。
- ECS(Fargate)が ECR からイメージ取得。
- CodeDeploy が ECS(Fargate)へデプロイ。
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のCodePipelineを使用してCI/CD環境を作成しようと思います。
アプリケーションコードのリポジトリはGitHubを使用しているので、GitHub Actionsでもできるようですが、そちらは一度触ったことがありAWSサービスの理解を深めたいので今回はAWSサービスを使用してみます。
ECS → CodeDeploy だけでECRリポジトリにプッシュされた際にデプロイ実行をできますが、CodePipeline を使って少し実戦的にやってみました。
参考にしたのは下記の記事などです。
- AWS CodePipelineを使用してgit pushでAmazon ECSをデプロイする | SEEDS Creators' Blog | 株式会社シーズ
- Aws Code PipelineでReactjs/Nextのデプロイを自動化!ECSへ展開してみました | Ragate ブログ
- ECSのCI/CD環境をCodePipelineに変えた話 | 株式会社CAM
- 【AWS】GithubからCodePipelineでECS/Fargateにデプロイする方法 - Qiita
- 【備忘録】AWS ECS Blue / Green Deploy 実現のために学んだこと - Qiita
- AWS_CICD_ECS_Handson.pdf
パイプラインを作成
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
設定ファイルの準備
- 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側の設定を行っていきます。
コンテナのタスク、サービスについては改めて理解するため下記が参考になりました。
基礎から応用までじっくり学ぶ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
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/***
を入力
クラスターの作成
ECS > クラスター > クラスターの作成 > FARGATE を選択
# クラスターの設定 クラスター名: nuxt-fargate-cluster
サービスの作成
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
確認
EC2 > ロードバランサー > 該当のELB選択 > DNS名
http://nuxt-fargate-load-balancer-*******.ap-northeast-1.elb.amazonaws.com/ にアクセスするとサイトが無事表示されました。
表示されない場合は、
- ECS > クラスター > タスク > ステータスが
RUNNING
になっている - EC2 > ターゲットグループ > 該当のターゲットグループ選択 > Targets > Statsが
healthy
になっている
かを確認して unhealthy
などになっていればトラブルシューティングを行う。
最初、ALBのターゲットの種類をインスタンスで設定してしまい、unhealthy でサイトも表示されないままになってしまいました。
ALBの作成、ECSの設定を再度Qiitaの記事参考にやり直して2回目で無事表示できました。
VPCやセキュリティグループも触るの試験勉強のハンズオン以来でしたが、とりあえず表示させる所までできてよかったです。
Nuxt.js + AWS ECS Fargate その1(Nuxt.jsアプリ作成〜ECRリポジトリへのプッシュ)
トレンドのVuejs/NuxtをAws ECS, FargateでSSR、詳細解説します🚀 の記事を参考に進めてみる。
ローカル環境 使用バージョン
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
以上でイメージをプッシュできました。
AWSのコンソールやCLI最近あまり触る機会がなかったですが、CLIのバージョンアップやプロファイルの切り替え等々つまづくところが多かったです。
正直あまり分かってない部分も多いですが、次回以降はECSの設定になりそうですので引き続き更新できたらと思います。