AWSで開発運用する上での基本が学べる【Developing on AWS】を受講してみた

ちゃあこ

2023.12.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

皆さんこんにちは、AWS事業本部オペレーション部の清水です。

AWSで開発運用する上での基本について学習するべく、「Developing on AWS」を受講してきました！

本コースの受講をお考え中の方へ、お役に立てば幸いです。

AWS認定トレーニングとは？

以下のブログに、弊社AWS認定トレーニング講師の平野のほうで執筆した各トレーニングの詳細が記載されています。

私が今回受講したのは、以下の図の赤枠に入るコースになります。AWS SDK/CLIを使用して、AWS を活用したアプリケーションを開発する方法を学びたい方におススメのコースになります。

事前準備

知識レベル

「AWS認定クラウドプラクティショナー」レベルの知識習得/構築経験
Pythonの基礎知識（入門レベルでOK）
Cloud9の基礎体験

１日目

モジュール３：AWSで開発を開始する

※モジュール１・２は、コースの概要とラボ環境の設定だったため本ブログでは割愛

AWS REST API

CLI、SDK、マネージメントコンソールでも、すべて裏側にはこれがある
普段気にする必要はないが、デバックをすると、REST APIを意識する必要がある
HTTPステータスコード
- 100番台：情報
- 200番台：成功
- 300番台：リダイレクト
- 400番台：クライアントエラー
- 500番台：サーバーエラー

SDK

Ruby,JavaScript,PHP,.NET,Java,Python,C++など様々な言語に対応
APIを直接使うとコードのボリュームがとんでもない量に！
- プログラムを実行するときは、SDKの中で準備してくれるのでこれを利用する
エラーやタイムアウトにも対応してくれる
- 低レベルAPI
- 高レベルAPI（出来る限りこっちを利用する）

CLI

コンソールからコマンドを打って、実行
- ローカルで呼び出し（Linuxシェル・Windows・MacOS）
- クラウドで呼び出し（Cloud9・CloudShell・System Managerセッションなど）

AWS IDE（統合開発環境）

自分が使いやすいツールキットを使えばいい
EditorとTerminalの機能がセットになっている。以下一例
- AWS Cloud9
- Visual Studio Code
- Azure DevOps
- PyCharm

Amazon CodeWhisperer

コード生成
- AWS SDKを使ったサンプルが多数出てくる
コードを書いてる途中でも、作成したコードのセキュリティスキャンをしてくれる

モジュール４：アクセス許可を開始する

IAMの用語と概念

ユーザー
- Tanaka.Ichiro
- Yamada.Jiro
ユーザーグループ
- 管理者
- 開発者
ポリシーとアクセス許可
- AdminAccess
- Billing
- DatabaseAdmin
ロール
- AWSのサービスロール
- EC2インスタンス

セキュリティ認証情報：優先順位

コードまたはCLI
環境変数
1. AWS_ACCESS_KEY_ID
2. AWS_SECRET_ACCESS_KEY_ID
認証情報ファイル内のデフォルト認証情報
1. 1. ～/.aws/credentials
インスタンスプロファイル

ラボ１：開発環境を設定する

開発環境に接続
IDE および AWS CLI がインストールされ、プロファイルを使用できるよう設定されていることを確認
AWS CLI のコマンドを実行するために必要なアクセス許可が付与されていることを確認
IAM ポリシーをロールに適用して Amazon S3 のバケットを削除

モジュール６：ストレージオぺレーションを処理する

※モジュール５はS3のストレージ概要だったため、本ブログでは割愛

HeadBucket APIアクション

バケットが存在しているか、アクセス権を得ているかどうか確認できる
- コマンドが成功すると、バケットはアカウントにすでに存在していることを表す
- 404エラー：その名前のバケットは、AWSに存在しない
- 403エラー：その名前のバケットは、別のAWSアカウントに存在

データを取得：GETとHEAD

オブジェクトのメタデータのみを取得
- Headを使う
- なるべくGETは使わない

署名付きURL

一時的なアクセスを許可できる
相手を制限して発行ができないため、個人情報などが入ったコンテンツでは使ってはいけない

CORS

違うドメインに対しても、APIのアクセスが可能になる仕組み

ラボ２： Amazon S3 を使用してソリューションを開発する

AWS SDK や AWS CLI を使用して、プログラムから Amazon S3 を操作
waiter 機能を使用してバケットを作成し、サービス例外コードを確認
メタデータが添付された Amazon S3 オブジェクトを作成
バケットからオブジェクトをダウンロードして処理を行い、処理結果をバケットにアップロード
バケットにウェブサイトホスティング設定を行い、AWS CLI を使用してソースファイルをアップロード

2日目

モジュール７：データベースを開始する

リレーショナルDBと非リレーショナルDB

リレーショナルDB（SQL）のほうが、検索性に関しては優れている
非リレーショナルDB（NoSQL）のほうが、検索性に関しては柔軟に出来ない
- ただしデータのスキーマ（保存）が柔軟
- 水平スケーリングが可能！

DynamoDB

同じリージョン x 同じアカウント：同じテーブル名は使用できない
JSON形式で保存
- パーテーションキー：必須！ソースコード内「KeyType：HASH」と表示される
- ソートキー：任意。ソースコード内「KeyType：RANGE」と表示される
- パーテーションキーとソートキーの組み合わせが一意の状態で、保存される
以下の容量単位で、課金される値段が変わる
- ※Auto Scallingで需要に合わせて、利用する容量単位を決めないで利用もできるが、課金対象の料金が読めなくなる
- 読み取り容量単位（RCU）
- 書き込み容量単位（WCU）
セカンダリインデックス
- ※メインのテーブルとは独立しているため、テーブル２つ分の料金がかさむ（沢山使わないといけない場合は、リレーショナルDBのほうがいい）
- ローカル：パーテーションキーが同じ。テーブル作成時に一緒に作成が必要！追加不可！
- グローバル：パーテーションキーが違う。テーブル作成後、後から追加可能

NoSQL Workbench

マネージメントコンソールでも、DynamoDBへアクセス可能だがこのような便利ツールも

モジュール８：データベースオペレーションを処理する

DynamoDB のテーブル設計

NoSQLを使う上で大事なこと：検索に制限がある
- 全てのアクセスパターンを特定しておく
- キーの選択：高いカーディナリティ

項目読み取り

同じパーティションキー x ソートキーで存在している組み合わせのデータ：二回以上作成されず、データが上書きされる
読み取りは二種類の方法
- クエリ：制限された検索キーの中で、利用
- スキャン：検索キーでは解決できない場合に活用。データが大きい場合は利用できない

項目の更新

条件付き書き込みオペレーションが、可能

項目削除

項目削除にも、条件付きオペレーションを利用するといい

キャッシュ

DynamoDB Accelerator
- 結果整合性のあるDynamoDBの読み取りワークロードを削減できる
- 読み取りが数ミリ秒→マイクロミリ秒に！

ラボ３： Amazon DynamoDB を使用してソリューションを開発する

プログラム内の低レベル API 、ドキュメント、高レベル API を使用して、DynamoDB をプログラムで操作
パーティションキー、ソートキー、プロビジョンドスループットを持つテーブルを Waiter を使用して作成
ファイルから JSON オブジェクトを読み取ってテーブルへロード
キー属性、フィルター式、ページ分割を使用して、テーブルから項目を取得
項目に新しい属性を追加したり、条件付きでデータを変更
PartiQL を使用して DynamoDB データにアクセス

モジュール９：アプリケーションロジックを処理する

コンピューティングサービス

インスタンス（仮想マシン）
- EC2
- 個別のOSを起動できる、そのため起動が遅い。数分といったイメージ
- OSの管理もユーザーがしなければいけない
コンテナ（Docker)
- ECS
- EKS
- OSは全て共通。そのため起動が早い！10何秒といったイメージ
- OSの管理は不要
- CI/CDを利用したい場合、コンテナを利用する
サーバーレス

Lambda

関数を呼び出す方法
- 同期：API Gateway（直接呼出し、再試行なし）
- 非同期：S3,SNS（プッシュ、組み込み再試行２回）
- ポーリングベース：Kinesis,DynamoDB（プル、再試行はイベントソースに依存）
ハンドラ関数
- イベントオブジェクト
- コンテキストオブジェクト

Lambda API

- CreateFunction
  - 関数作成
- UpdateFunctionCode
  - 関数のコード更新
  - コード未公開
- UpdateFunctionConfiguration
  - 関数のバージョンの設定変更
- Invoke
  - 同期的、非同期的に関数を呼び出す

テスト

関数を呼び出して、テストしていく
- マネージメントコンソール
- CLI
- SDKもできるけど、あまりやってるケースは多くない

デプロイ

関数の制限
- どのサイズのメモリを設定するかで、料金が決まる。小さなメモリのほうが安価になる
- タイムアウト：１５分（これに関しては上限緩和不可！）
- 同時実行数：詳細はサポートに問い合わせ。１つのアカウント内の、すべてのLambdaの同時実行数

ラボ４：AWS Lambda を使用してソリューションを開発する

AWS Lambda 関数を作成し、AWS SDK と AWS CLI を使用して、プログラムから AWS を操作
環境変数を使用し、他のサービスと連携する Lambda 関数を設定
AWS SDK を使用して Amazon S3 の署名付き URL を生成し、バケットオブジェクトへのアクセスを検証
zip ファイルを使用した Lambda 関数のデプロイを行い、必要に応じてテスト
AWS マネジメントコンソールと AWS CLI を使用して AWS Lambda 関数を呼び出す

モジュール１０：APIを管理する

API Gateway

REST API
HTTP API
- REST APIより利用料金が安い
- 自由度が高い、その分実装しないといけないものが増える
WebSocket API
- サーバー側から、フロントエンドに表示する

統合タイプ

プロキシ
非プロキシ
モック

テスト

REST APIを呼び出してテストする
- マネジメントコンソール
- CLI
- POSTMAN

3日目

ラボ５：Amazon API Gateway を使用してソリューションを開発する

RESTful API リソースを作成し、アプリケーションの CORS を設定
API メソッドを AWS Lambda 関数と統合し、アプリケーションのデータを処理
マッピングテンプレートを設定し、メソッドの統合時にパススルーデータを変換
API メソッドのリクエストモデルを作成し、パススルーデータの形式がアプリケーションのルールに準拠していることを確認
API をステージにデプロイし、API エンドポイントを使用して結果を検証

モジュール１１：モダンアプリケーションを構築する

モノリス
- 全ての機能を実行する
マイクロサービス
- - 単一の機能を実行する
  - ある程度大きな規模間のシステムで採用が必要

Amazon Culture of Innovationとマイクロサービスアーキテクチャ

サーバーレスコンピューティング

これ以外は管理しなくていい
- アプリケーションの構築とデプロイ
- アプリケーションのモニタリングと保守

モジュール１２：アプリケーションユーザーにアクセス権を付与する

Amazon Cognito

Web、モバイルアプリケーションの認証、認可、ユーザー管理
- ユーザープール「認証（サインアップ・サインイン）」
  - log inすると、Cognitoがトークンを発行し、アプリケーションで使用
- IDプール「認可（他のAWSサービスへのアクセスを付与）」
  - log inすると、JWTトークンをキーをもとに、APIレベルでCognitoでアクセス
  - IAMロールに関連する認証情報から、Cognito→アプリケーションへレスポンス
  - 認証情報を使用して、アプリケーション→S3などのサービスにアクセス

ラボ 6: キャップストーン - アプリケーション構築を完了する

Amazon Cognito を使用して、ウェブアプリケーション用のユーザープールとアプリケーションクライアントを作成
Amazon Cognito CLI を使用して、新しいユーザーを追加し、サインインできることを確認
Amazon Cognito をオーソライザーとして使用するよう API Gateway メソッドを設定
API コール時に JWT 認証トークンが生成されることを確認
Swagger のインポート戦略を使用して、API Gateway リソースをすばやく開発
Amazon Cognito と API Gateway の設定を使用できるようウェブアプリケーションのフロントエンドをセットアップし、アプリケーション全体の機能を検証

モジュール１３：アプリケーションをデプロイする

DevOps

なるべく小さく開発して、頻繁にリリースする
- CI（継続的インテグレーション）
- CD（継続的デリバリー・デプロイ）

SAM

サーバーレスアプリケーションのデプロイに使用される、オープンソースフレームワーク

モジュール１４：アプリケーションを観測する

オブザーバビリティの３つの柱

ロギング
メトリクス
トレース
1. X-RAYで全体をモニタリング、問題を特定
2. CloudWatchで詳細のログを、各サービスで確認

X-Ray

それぞれのサービスごとではなく、サービス全体をモニタリングして、問題が発生した切り分けができる
時間計測が可能（どのユーザーが、APIの呼び出しにどれだけ時間がかかっているかなど）

CloudWatch

それぞれのサービスごとに対してログが出て、問題が発生した切り分けができる
AWSリソース→集まってくるメトリクスやログを、アラームを使ってメールを飛ばしたりSlackで通知が出来る
メトリクス
アラーム
- 本当に問題があった場合にだけ、アラームを流す
- しきい値を決めておいて、３回しきい値が越えたら発生させるなど設定が可能

ラボ 7 : AWS X-Ray を使用してアプリケーションを監視する

AWS X-Ray の機能を使用するためにアプリケーションコードをインストルメント化
アプリケーションのデプロイパッケージがログを生成
AWS SAM テンプレートの主要コンポーネントについて理解し、アプリケーションをデプロイ
X-Ray サービスマップを作成して、アプリケーションのエンドツーエンドの処理動作を観測
X-Ray のトレースと注釈を使ってアプリケーションの問題を分析してデバッグ

終わりに

これまでに、私は以下の２つのトレーニングを受講してきました。

Architecting on AWS
Security Engineering on AWS

そちらと比較すると、このトレーニングはハンズオンの時間が長く、座学が少なかったように思います。（そのため本ブログの内容も、他に比べると量が少ないです）特にLambda関数を作成したり、DynamoDBを扱ったりなどが、このコースでは体験できます。

開発者ではない私のような役割の方だと、手を動かさないと理解できない部分が「Developing on AWS」の資格試験の領域でも多いため、ぜひ受講してハンズオンを体験されるのをお勧めします。