はじめに
先日、AWS Certified Developer - Associate (DVA-C02) に合格しました！
他のAWS資格勉強をしていたので、ある程度のAWSサービスや仕組みを知っていたものの、
改めて学習してみたらちょっと理解が追い付いていない部分がありました、、、悲しい、、、
なので、自分の知識定着のためにAWSのDeveloper関連のネタを備忘録的な感じでまとめてみました！
DVA合格を目指す方の参考になれば幸いです。
この記事で学べること
- AWS CI/CD の 4 サービス（Code 4 兄弟）の役割と流れ
- CI/CDに含めている単体テストとは何か
- デプロイ戦略（Blue/Green・Canary など）の違い
- Lambda のセキュリティ（KMS と
/tmp領域） - DynamoDB のエラーハンドリング（エクスポネンシャルバックオフ）
- AppConfig と動的設定の仕組み
1. CI/CD を支える「Code 4 兄弟」とは？
AWS には、コードの管理からデプロイまでを自動化する 4 つのサービスがあります。
これらをまとめて 「Code 4 兄弟」 と呼ぶことが多いです。
| サービス名 | 役割 | ひとことで言うと |
|---|---|---|
| CodeCommit | ソース管理 | コードの保管庫・履歴管理 |
| CodeBuild | ビルド・テスト | コードを動くものに変換し、品質チェックする |
| CodeDeploy | デプロイ | サーバーへ安全にファイルを届ける |
| CodePipeline | 連携・自動化 | 上記 3 つを一本のラインで繋ぐ |
これらは単独でも使えますが、CodePipeline で繋ぐことで「コードを書いたら自動で本番反映」という CI/CD パイプラインが完成します。
2. CodeBuild の役割：「ビルドとテスト」とは何か？
「コードを書いたらそのままサーバーに置けばいいのでは？」と思うかもしれません。
しかし現代のアプリ開発では、それだけでは動きません。CodeBuild には大きく 2 つの役割があります。
① コンパイルとパッケージング
人間が書いたソースコードを、コンピュータが実行できる形式に変換します。また npm install や pip install などで必要なライブラリを集め、デプロイできる「完成品」にまとめます。
② 単体テストの実行
これが特に重要です。
「単体テスト」とは、プログラムの最小単位である「関数」が正しく動くかを自動で確認することです。
具体例
テストコード（検査表）：
送料計算関数に「購入金額 5000 円」を入れたとき、
戻り値は「0 円（送料無料）」になるはずだ
実際の動作 → 0 円 → テスト合格 ✅
実際の動作 → 500 円 → テスト失敗 ❌ → デプロイを止める
なぜ自動テストが必要か？理由はシンプルで、「人間は必ず間違える」 からです。
コードを 1 行直したせいで、別の計算がおかしくなる「デグレ（先祖返り）」を、本番に出す前に自動で発見するのが目的です。
設定ファイルは buildspec.yml
CodeBuild の手順は buildspec.yml というファイルに記述します。テスト結果は CodeBuild の reports 機能で可視化できます。
3. デプロイ戦略：安全な本番反映の 4 パターン
作ったアプリをどうやって本番環境に届けるか。目的とコストに応じて 4 つの戦略があります。
① All-at-once（一斉入れ替え）
全サーバーを同時に更新します。速くて安いですが、更新中はサービスが止まります（ダウンタイムあり）。影響が少ない内部システムや開発環境向けです。
② Rolling（順次入れ替え）
サーバーを 1 台ずつ順番に更新します。サービスを止めずに済みますが、更新中は新旧バージョンが混在します。
③ Blue/Green（別環境切り替え）
現行環境（Blue）とは別に新環境（Green）を丸ごと作り、ロードバランサーの向き先を一気に切り替えます。
最も安全な手法ですが、一時的にサーバー費用が 2 倍になります。問題が起きたときに即座に Blue へ戻せる点も大きなメリットです。
④ Canary（カナリア）
最初は全ユーザーの 5% だけに新バージョンを配信し、問題がなければ徐々に比率を広げます。
リスクを最小限に抑えられる高度な手法で、大規模サービスでよく使われます。
🚉 例え話：電車の路線切り替え
| 戦略 | 電車に例えると |
|---|---|
| All-at-once | 全路線を一斉に工事。早く終わるが全線止まる |
| Rolling | 1 路線ずつ順番に工事。他は動いているが混雑する |
| Blue/Green | 新しい路線を並行して作り、完成したら一気に乗客を移す |
| Canary | 新路線に最初は 1 編成だけ走らせて様子を見る |
設定ファイルは appspec.yml
CodeDeploy の手順は appspec.yml に記述します。buildspec.yml（ビルド）と appspec.yml（デプロイ）を混同しないよう注意しましょう。
4. Lambda のセキュリティ：/tmp 領域を暗号化するには？
Lambda には /tmp という一時ストレージ領域の暗号化について、AWSの標準機能を利用するか、アプリ側でAWS KMS（Key Management Service） を使った「エンベロープ暗号化」が必要です。
※以前はアプリ側の暗号化しか対応してなかったみたいですが、2024年ごろにAWSのアップデートがあり、標準機能としての暗号化も可能になりました。
エンベロープ暗号化の仕組み
- KMS に「データキー」の発行を依頼する
- そのデータキーで実際のデータを暗号化する
- 暗号化されたデータと暗号化済みデータキーをセットで保管する
🏦 例え話：銀行の貸金庫
空港の荷物ロッカー（
/tmp）はそのままでは誰でも中を見られます。
そこで、**銀行（KMS）から特製の鍵付きボックス（データキー）**を借りて、その中に大切なものを入れてからロッカーに預けます。
銀行カード（IAM ロール）を持っている人しかボックスを開けられないので、ロッカー自体に鍵がなくても安全です。
5. DynamoDB のエラー処理：スループット超過にどう対応するか？
DynamoDB でスループット制限を超えると、ProvisionedThroughputExceededException というエラーが発生します。
このとき、ただ即座にリトライし続けるのは逆効果です。エクスポネンシャルバックオフ（指数的待機） が正しい対処法です。
エクスポネンシャルバックオフとは？
失敗するたびに、リトライまでの待機時間を指数関数的に増やす手法です。
1 回目失敗 → 1 秒待つ
2 回目失敗 → 2 秒待つ
3 回目失敗 → 4 秒待つ
4 回目失敗 → 8 秒待つ … （上限まで続ける）
AWS SDK を使えば自動で対応できる
AWS SDK を利用すると、このバックオフ処理が標準で組み込まれています。
HTTP API を直接叩く実装よりも、SDK を使う方がはるかに簡単で確実です。
🚦 例え話：混雑した道路
渋滞（スループット超過）で進めないとき、すぐにクラクションを鳴らし続けても（即時リトライを繰り返しても）状況は悪化するだけです。
「少し待ってから様子を見よう。それでもダメならもう少し長く待とう」と間隔を開けていくのが賢い行動です。
6. AppConfig：再起動なしで設定を動的に変更する
アプリの設定値（接続数の上限、機能フラグなど）を変えるためだけにデプロイや再起動をするのは手間がかかります。
AWS AppConfig を使うと、アプリを止めずにリアルタイムで設定変更が可能です。
サイドカーパターン
ECS などの環境では「サイドカー」という仕組みを活用します。
┌────────────────────────────┐
│ メインアプリコンテナ │ ← 実際のビジネスロジック
│ │
│ AppConfig エージェント │ ← AppConfig から最新設定を取得し続ける
│ （サイドカー） │
└────────────────────────────┘
エージェントが定期的に AppConfig から最新の設定を取得してきてくれるため、メインアプリは再起動不要で新しい設定値を使えます。
🎛️ 例え話：生放送中の音量調節
ラジオの生放送（メインアプリ）中に音量を変えたい場合、放送を止めて（再起動して）から再開するのは現実的ではありません。
横に立つアシスタント（サイドカー）がディレクター（AppConfig）の指示を受け取り、放送を続けたまま音量つまみを調整してくれます。
まとめ：DVA-C02 で押さえるべきキーワード
| テーマ | 覚えること |
|---|---|
| CI/CD | CodeCommit → CodeBuild（buildspec.yml）→ CodeDeploy（appspec.yml）→ CodePipeline の流れ |
| 単体テスト | CodeBuild で実行し、reports 機能で可視化。デグレをデプロイ前に検知する仕組み |
| デプロイ戦略 | Blue/Green は安全だがコスト 2 倍。Canary は段階的リリースでリスク最小化 |
| Lambda セキュリティ | AWS標準機能またはKMS でエンベロープ暗号化が必要 |
| DynamoDB エラー |
ProvisionedThroughputExceededException → エクスポネンシャルバックオフ。SDK を使えば自動対応 |
| 動的設定変更 | AppConfig ＋ サイドカーパターンで再起動なしに設定を反映 |
おわりに
いかがでしたでしょうか。
個人的にひっかかった部分を取り上げてまとめたので、ちょっと前後関係がなかったかもしれないですが、備忘録なのでご容赦ください、、、
Discussion