Developing on AWS 振り返り
==

- AWSのメリットを活かし、モダンなWebアプリケーションの開発と改善に集中するためのポイントを学ぶ

## 前提知識
### グローバルインフラストラクチャ
#### リージョン
- AWSのデータセンターのある地域。2025/10時点で38リージョン。日本には東京と大阪にあり
#### アベイラビリティゾーン（AZ)
- リージョン内のデータセンターのグループ。同じリージョン内でも電力の供給元が別になっていたり、地理的に分散している
- S3やDynamoDBなどのリージョンサービスは、自動的に複数のAZを利用しているのでデータ耐久性が高い

### サービスとリソース
#### サービス
- AWSの提供する機能のこと
- EC2、S3、Lambda、、
#### リソース
- サービスの実体のこと
- EC2インスタンス、S3バケット、Lambda関数、、、
### 主要サービス　
#### SNS
- メッセージの配信サービス(push型)
- 機能間の連携が必要な時に、メッセージを配信してくれる。1対多の配信も可能
- 配信先（サブスクライバ）の増設が容易なので、機能拡張がしやすい（ファンアウト）
#### SQS
- メッセージを保持するサービス。SNSと違い、自ら配信はしない(pull型)
- 明示的に削除されるまでメッセージを保持するため、障害発生時の復旧が楽で安全性を高められる
#### EventBridge
- AWSの内外で発生したイベントと、それに対応するアクションを紐づけるサービス
- CloudWatchEventの進化版
- 時間をトリガーにしたアクションも起こせる（時間になったらEC2を起動する、など）

---

# mod.3
- AWSの全リソースはAWSの提供するRESTAPIでコントロールできる
- APIの直接呼び出し認証やエラーハンドリングの自力での実装が必要となるため、通常はSDKやマネコン、CLIを使う
- SDKには、抽象化された高レベルインターフェースと、より元のAPIに近い低レベルインターフェースがある
- APIのレスポンスには同期と非同期がある。リソースの生成に時間がかかる場合は非同期レスポンスが多い（S3バケット生成、DyanamoDBのテーブル作成など）
- Waiterを使って、非同期レスポンスを同期的に扱うことができる。例えばバケットが作成されてからでないと次のステップに進んでも意味がない場合は、Waiterを使ってバケット作成の完了を待たせることができる

### 確認問題
#### APIを直接呼び出すのではなくSDKを使う理由はなんでしょうか
##### A. エラーハンドリングが楽になるため
##### B. 認証（署名v4）のコードを書かなくてよいため
##### C. 補完が効くなど、IDEで扱いやすいため
<details>
<summary>回答</summary>
A,B,C
</details>

# mod.4
- AWSのAPIはIAMにより権限が管理されている。APIを呼びだすにはIAMで認証と認可を設定する必要がある
- SDKやCLIでの認証はプリンシパル（IAMユーザーなど）の持つクレデンシャル（アクセスキーとシークレットキー）で行う
- マネジメントコンソールの場合はIAMユーザーのパスワード
- AWSのサービスや開発環境にもクレデンシャルの設定が必要。開発環境で参照されるクレデンシャルには優先順位がついている
- EC2インスタンスはインスタンスプロファイルで設定したIAMロールの権限が自動的に付与され、優先度は一番低い
- 主要な言語のSDKがAWSから無償で提供され、外部ライブラリとしてインポートしてコードから利用する
- SDKからAPIを呼び出す時に認証情報が参照され、APIを呼び出すためのオブジェクトを生成できる
- サービスクライアント、リクエストクライアント、サービスリクエストなど様々な呼称がある
- SDKの提供するサービスクライアントには、低レベルと高レベルがある。低レベルは直のAPI呼び出しに近く、データ構造を意識する必要がある。高レベルは抽象化されていて、オブジェクトとして扱える
- client()メソッドは低レベルAPIを、resource()メソッドは高レベルAPIを提供する（Pythonの場合）
### 確認問題
#### SDKやAWSCLIの認証情報として利用できるのはどれですか？
##### A. STSが発行した一時的なアクセスキーとシークレットキー
##### B. IAMユーザーのアクセスキーとシークレットキー
##### C. IAMユーザー名とパスワード
<details>
<summary>回答</summary>
A,B
</details>

# mod.5
- S3は容量無制限、高い耐久性を持つオブジェクトストレージ
- ストレージ上でファイルの編集はできない
- バケットにファイルを格納する。ファイル（オブジェクト）はURLで示され、S3のAPIで操作する
- URLでオブジェクトにアクセスできるので、Webアプリケーションとの相性が非常に良い
### 確認問題
#### S3で可能なことはどれですか？
##### A. Python製フレームワークで構成されたWebアプリケーションの展開
##### B. Reactで構成されたWebアプリケーションの展開
##### C. アプリケーション内で生成されたファイルの配信
<details>
<summary>回答</summary>
B,C
</details>

# mod.6
- バケットの作成はサービスクライアントの持つCreateBucketメソッドを使う。レスポンスは非同期なので、バケットの作成を待ちたい場合はwaiterを利用できる
- オブジェクトのアップロードにはマルチパートアップロードが利用できる。5GBより大きなオブジェクト（ファイル）では必須。ファイル分割はOSのコマンドなどを使い、S3へのアップロード後に結合作業が必要
- 署名付きURLを使うと、プライベートなオブジェクトであっても限定公開したURLを発行できる
- 有効期限を付けられる。スイッチロールしているときはロールの有効期限（デフォルトでは1時間）になるので注意
- バケット内のオブジェクト一覧は大量であることが多いので、リスト取得時はページ分割するとよい。SDKのpagenatorで実装可能
- CORSは、異なるオリジン(*)にあるコンテンツを共有できる仕組み。S3はCORSに対応しているので、自社のドメインなどへもコンテンツを提供できる
- オリジン・・・ドメイン名に、HTTPスキームとポート番号を加えたもの。http://domain.com:8080など
# mod.7
- DynamoDBは、ストレージ容量無制限で負荷に関係なく1桁ミリ秒での応答を維持できる高性能NoSQL（Key-Value)データベース
- 3つのAZに展開した分散データベースのため、可用性とスケーラビリティに優れるが、AZ間でのデータ同期タイムラグのため一時的なデータの不整合を許容する必要がある（結果整合性）
- パーティションキー（旧称ハッシュキー）は、単独もしくは複合のプライマリキーとなる。パーティションは独立した物理ストレージで、DynamoDBはパーティションを分散することでパフォーマンスを発揮する
- ソートキー（旧称レンジキー）はオプション。パーティションキーと組み合わせて複合プライマリキーとして利用でき、範囲検索が可能となる。パーティション内でデータを並べ替えするために利用されている
- 行列の概念はなく、プライマリキーごとに独立した「カード」のようなデータ形態
- データベース側でデータ構造を把握していないので、カードごとに持つ属性（情報）を自由に定義できる
- プライマリキー以外での検索はできない
- セカンダリインデックスを使うとテーブルとは別のプライマリキーを持てる
- ローカルセカンダリインデックスはテーブル作成時に5個まで作成可能。ソートキーを複数設定できるので、範囲検索条件を増やすことができる
- グローバルセカンダリインデックスは随時、20個まで作成可能。テーブルとは別のパーティションキーを持った、別のテーブルとして利用する（データは非同期でテーブルと連動）
- テーブル作成後に、検索パターンの追加ができる
- DynamoDBの性能は、1秒間あたりのアクセス単位(Unit)で決める
- 1Unitあたり、読取時1秒間に4KBまで1回（強整合性）、書込時1KBまで1回
- デフォルトは「オンデマンド」で、消費したRRU/WRUに課金
- 性能を見積できる場合は「プロビジョンド」で、設定したRCU/WCUに課金
### 確認問題
#### DynamoDBのユースケースとして正しいものはどれか？
##### A. テーブル間連携や複雑なクエリを取り扱うデータベースとして
##### B. ショッピングカートなどユーザビリティに関わる可用性を維持する必要がある機能に
##### C. データの増加量の予測がつかないようなワークロードに
<details>
<summary>回答</summary>
B,C
</details>

# mod.8
- DynamoDBはデータの出し入れを含めた全ての操作をAWSのAPIで行う
- RDSはSQLデータベースのため、データの出し入れはSQLを使い、AWSの管理範囲外
- データ読み取りはプライマリキーを指定しての1項目限定取り出し（GetItem)か、ソートキーがある場合はパーティションキーのみ指定の範囲検索（Query)で実施
- 読み取り時にConsistencyReadオプションをつけると、強整合性読み取りとなる。この場合はDynamoDB側でAZ間のデータ収束が終わっていることを保証するが、パフォーマンス劣化のリスクがある
- コストは結果整合（デフォルト動作）だと半額になるため、基本は結果整合で使う
- プライマリキー以外で検索したい場合は全件スキャン（Scan)するか、グローバルセカンダリインデックスを作成してプライマリキーを別に用意するしかない

# mod.9
- Lambdaは、イベントドリブンのコンピュート基盤。イベント発報時のみサーバが起動しコードを実行、コードの実行時間にのみ課金される
- トリガーに使えるイベントは多彩。APIGWからは同期、SNSやS3からは非同期で呼び出される。SQSやKinesisにはLambdaが自らメッセージをポーリングしにいく
- Lambdaの実行時に実行コンテナ（マイクロVM）が作成される。実行コンテナは起動済みの場合は使い回しされるが（ウォームスタート）、実行コンテナがない場合はVMの起動から始まる（コールドスタート）ため、タイムラグが発生する
- LambdaSnapStartを使うと、ウォームスタート状態のスナップショットから実行コンテナを作成するため、コールドスタートの時間を短縮できる。Java11,Python3.12,.NET8以降で利用可能
- Lambdaを呼び出すリソースのためのリソースベースポリシーと、Lambda自身がAWSサービスを利用するためのアイディンティティベースポリシーをIAMロールとして設定する必要がある
- Lambdaのプラットフォームが関数を動かすために、関数名をプラットフォームに設定する必要がある（ハンドラ関数）
- ハンドラ関数の外にある関数は実行コンテナに保存されるため、ハンドラ関数の外にサービスオブジェクトを書くと、実行コンテナが再利用された時の時短になる（テキスト390ページ）
- コードは任意の時点でバージョンを付けられる。バージョンはARNに含まれるのでイベントソースから関数を呼び出すときにバージョンの指定ができる
- イベントソース側でバージョン番号を変更したくないときは、エイリアスを使う。エイリアスはバージョン番号の別名で、prodなど環境名を付けておき、イベントソース側では環境名のみを意識できるようにする。エイリアスとバージョンの紐付けはLambda側で行う
### 確認問題
#### Lambdaの用途として正しいものはどれか？
##### A. API呼び出しなどのイベントをトリガーとして単発的な処理を繰り返すワークロード
##### B. 大容量のメモリとストレージを必要とするバッチ処理基盤
##### C. OSやインフラの設定のカスタマイズが必要なオンプレミスからの移行基盤
<details>
<summary>回答</summary>
A
</details>