はじめに
AWSCertifiedDeveloper–Associate取得に向けて勉強したことのメモです。
やったこと
- whizlab
メモ
Cloud Front
- Lambda@Edge
Route53
- GSLB
EC2
- EBS暗号化
- 何に対して暗号化されるのか
- -> ドキュメントには以下のタイプが暗号化されると書いています。
- ボリューム内の保存データ
- ボリュームとインスタンスの間で移動されるすべてのデータ
- ボリュームから作成されたすべてのスナップショット
- それらのスナップショットから作成されたすべてのボリューム
ELB
- ELBだけではなく一般的なロードバランサは、アクセスされたHTTP内のCookieを見て、特定のクライアントからのアクセスは常に同じサーバに返すSticky Session と呼ばれる仕組みが用意されています。
Elastic Beanstalk
- 移行
- オンプレからのコンテナ移行も、EC2よりこっちがラク
- コンテナじゃないがEBのデフォルトのAMIだとハマらないとき
- カスタムプラットフォームにより、Elastic Beanstalk に最適な独自 AMI を容易に作成することが可能となりました。簡単に言うと、ベースとなる AMI から Packer を使って、Elastic Beanstalk に最適な AMI（カスタムプラットフォーム）を作成してくれます。
- （参考）Packer とは
- 設定ファイル
- デプロイ
- 従来のElastic Beanstalk アプリケーションのデプロイは 既存のインスタンスに対し上書きされる形で実施されていたため、デプロイ中にサービス影響が及ぶなどの 問題になる事がありました。
- 新たに追加されたデプロイメントポリシー「immutable」、AWSの日本語コンソール上で 「変更不可」と表示されているポリシーを利用すると、 新しいバージョンのアプリケーション環境用として新規のEC2インスタンスが用意され、 クリーンな環境に対するデプロイが実施されるようになりました。
- blue/greenも可能
- ローリングデプロイの仕組み
- バッチを処理する際、Elastic Beanstalk はバッチ内のすべてのインスタンスをロードバランサーからデタッチし、新しいアプリケーションバージョンをデプロイしてから、再アタッチします。
- Connection Drainingが有効になっていると、Elastic Beanstalk は、デプロイを開始する前に、Amazon EC2 インスタンスから既存の接続をストリーミングします。
- ライフサイクル
- Elastic Beanstalk コンソールまたは EB CLI を使用して新しいバージョンのアプリケーションをアップロードするたびに、Elastic Beanstalk はアプリケーションバージョンを作成します。
- 使用しなくなったバージョンを削除しないと、最終的にはアプリケーションバージョンクォータに到達し、そのアプリケーションの新しいバージョンを作成できなくなります。
Lambda
- ログ
- ログはCloudWatchLogsで確認
- バージョニング
- バージョニングは基本的には直線の形で更新されていき、過去のバージョンについてはエイリアスという機能を使って別名を与えることができます。
- 各バージョンのスクリプトにはそれぞれARNが割り当てられます。
- バージョンは一度発行された後、そのARNが指し示す内容の変更はできませんが、一方でエイリアスは指し示すバージョンを自由に変更することができるという特徴を持っています。
- このため、エイリアスが指し示すスクリプトは様々なバージョンのものに変更可能となっています。
- エイリアスを利用すると、開発ワークフローに合わせたバージョンの切り替えが可能となります。
- 例えば、本番環境用にエイリアスを安定した古いバージョンに設定しておき、ある程度開発やテストが進んだ段階で新しい安定バージョンのものに切り替えるといったことが可能になります。
- 環境変数
- ベストプラクティス
- https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/best-practices.html
- Lambda 関数内で、任意の条件が満たされるまでその関数自身を自動的に呼び出すような再帰的なコードを使用しないでください。これを行うと意図しないボリュームで関数が呼び出され、料金が急増する可能性があります。
- 関数
- イベントをトリガーに、handler関数が呼ばれる
- VPC
- LambdaをVPC内に配置すると、Lambda実行時にENI（仮想ネットワークインターフェース）が付与されるようになります。それに伴い考慮すべきことがあります。
- セキュリティグループ
- サブネット
- LambdaをVPC内に配置すると、Lambda実行時にENI（仮想ネットワークインターフェース）が付与されるようになります。それに伴い考慮すべきことがあります。
- Kinesis Data Firehose
- 実行時間
- デフォルト3秒だが変えられる
- リトライ
- アプリ側でリトライの実装したり
- Lambda関数には呼び出しタイプ(同期、非同期、ストリーム)があるのですが実行トリガーによって呼び出しタイプが異なり、それによってAWS側でリトライが実行されるのか、ユーザー側でリトライを実装する必要があるかが変わってきます。
- エラー監視
- LambdaにDLQを設定することにより、呼び出し元に成功応答しか返さない非同期呼び出しの場合でも、関数実行の失敗をSQS queueやSNS topicに送信してエラー監視をできるようになる！
- CloudWatchLogsに書き込むためのIAM Roleが必要
- SAM
- AWS Serverless Application Model (以降 AWS SAM) は、AWS が公式で提供しているサーバーレスアプリケーションを構築するためのフレームワーク (モデル) です。
- Lambda, API Gateway, DynamoDB のリソースをひとまとめに管理 (作成 / 更新 / 削除) することができます。
- AWS SAM は AWS CloudFormation の拡張である
- パッケージ
- サーバーレスアプリケーションを段階的にデプロイする
- AWS SAM を使用してサーバーレスアプリケーションを作成する場合、CodeDeploy が組み込まれているため、Lambda を安全にデプロイできます。わずか数行の設定で、AWS SAM によって以下の処理が実行されます。
- Lambda 関数の新しいバージョンをデプロイし、新しいバージョンを参照するエイリアスを自動的に作成します。
- 期待どおりに動作するか、更新をロールバックするまで、顧客のトラフィックを徐々に新しいバージョンに移行します。
- 事前トラフィックおよび事後トラフィックのテスト関数を定義して、新しくデプロイしたコードが正しく設定されていること、およびアプリケーションが期待どおりに動作していることを確認します。
- CloudWatch アラームがトリガーされた場合は、デプロイをロールバックします。
- デプロイ
- サーバーレスアプリケーションを段階的にデプロイする
- デプロイパッケージのサイズ
API Gateway
- セキュリティ
- バージョン管理
- API Gatewayには1つのAPIを複数のステージにデプロイし、エンドポイントを複数作成することができます。
- Lambda関数も1つの関数で複数のバージョンを持つことができます。
- また、バージョンと対応するエイリアスを設定することができます。
- 例としては、バージョンを1, 2のような形で作成していき、そのバージョンと紐づくdev, prodエイリアスを設定する事ができます。
- また、$LATESTというバージョンが常に最新の状態を指しているため、devエイリアスを＄LATESTに当てることも多いです。
- API GatewayのstageVariablesを使って、LambdaのAliasと連携させる
- 環境だけでなく、バージョンも下記
- API ステージ
- ステージ変数は、次の例に示すように、HTTP 統合 URLの一部として使用できます。
- プロトコルのない完全な URI – http://${stageVariables.<variable_name>}
- 完全なドメイン – http://${stageVariables.<variable_name>}/resource/operation
- サブドメイン – http://${stageVariables.<variable_name>}.example.com/resource/operation
- パス – http://example.com/${stageVariables.<variable_name>}/bar
- クエリ文字列 – http://example.com/foo?q=${stageVariables.<variable_name>}
- -> 段階的な移行にも、stageを使う
- API (例: 'dev'、'prod'、'beta'、'v2' など) のライフサイクル状態への論理的な参照。API ステージは API ID とステージ名によって識別されます。
- Lambdaへの連携
- DynamoDBへの連携
- Method Request
- （参考）Method Requestとは
- （参考）https://wa3.i-3-i.info/word11405.html
- リソースに対して実行したいアクションを示す一連のリクエストメソッド
- ホームページを見るソフト（Webブラウザ）からホームページのファイルが置いてあるコンピュータ（Webサーバ）に対して出されるお願いの種類
- １．GET：ページをくれよ（HTTP1.0/1.1）
- ２．POST：このデータをくれてやるよ（HTTP1.0/1.1）
- ３．PUT：このデータ（ファイル）をくれてやるよ（HTTP1.0/1.1）
- ４．DELETE：このデータを消しちゃって（HTTP1.0/1.1）
- ５．HEAD：ヘッダ情報だけくれ（HTTP1.1）...
- HTTPリクエストは3つの部品から成り立っています。
- 「リクエストライン」「ヘッダ」（空行【CR＋LF】）「メッセージボディ」
- Method Requestで、許可するパラメータ、リクエストヘッダーを登録する
- その中からMethod Requestを選択して、
- Query String Parametersにpathを登録
- Request Header に Content-Typeを登録する
- （参考）Method Requestとは
CloudWatch
- 解像度
- 既存の PutMetricData API を使用して、カスタムメトリクスを 1 秒の解像度まで発行することができます。
- エラー
S3
- マルチパートアップロードAPI
- CORS
- バケットポリシー
- バケットポリシーで x-amz-server-side-encryption ヘッダーのチェックを行えば、S3 へのオブジェクト保存時に暗号化を強制することができます。
- Webサーバ
- 静的なコンテンツはS3だけでよい
- パフォーマンス
RDS
- 暗号化
- Amazon RDS は、透過的なデータ暗号化 (TDE) を使用して、Microsoft SQL Server を実行する DB インスタンスのデータの暗号化をサポートします。
- TDE は、ストレージへの書き込み前に自動的にデータを暗号化し、ストレージからのデータの読み取り時に自動的にデータを復号します。
- リードレプリカ
- 「リードレプリカ」とは、読み出し専用のDBで、レプリケーション機能でマスターDBから作成されたレプリカ（複製）DBのことです。
- 読み込み専用なのでDBへの書き込みやマスターDBへの反映は行われませんが、複数のリードレプリカDBを作成することができます。
- リードレプリカを使用する最大のメリットは、柔軟にスケールアウトが実現できる点です。
- 非同期レプリケーション：マスターDBとリードレプリカは非同期なので、同期のタイミングに注意が必要。トラブル時に最新の変更が残らない可能性あり。
- 準同期レプリケーション：マスターDBを更新すると、変更点がスレーブに転送される。このときの転送待ちにより処理速度が低下する可能性あり。
- ユースケース
- レポーティングのアプリなどで使ったり
DynamoDB
- DAX
- DAXはDynamoDBのメモリキャッシュサービスで、アプリ開発者がキャッシュのクリアを気にすること無く利用できるとされるサービスです。
- 書き込みよりも読み込みの多いテーブルがあれば、プロビジョニング済みキャパシティを減らすことができるので、コスト削減を見込めます。
- DynamoDBの前にインメモリ型キャッシュクラスタを組み込んで管理する必要があり、そのためにはアプリケーションをリライトし、クラスタを実装、運用する専門的なスキルが求められるといった課題があった。
- DAXは、こうした課題を解決するサービスで、顧客は別途キャッシュクラスタを設置することなく、Amazon DynamoDBの性能を最大10倍に高めることができるフルマネージドのキャッシュにより、応答時間を数ミリ秒からマイクロ秒に短縮できる。
- （参考）https://dev.classmethod.jp/articles/dax-preview/
- ユースケース
- ユーザセッション管理といえばこれ
- キャパシティ設計
- 読込キャパシティーユニットで、最大サイズ 4KB の項目について、1秒あたり1回の強力な整合性のある読み込み 又は 1秒あたり2回の結果整合性のある読み込みが可能
- DynamoDBでは読み込みと書き込みのキャパシティをそれぞれユニットと呼ばれる単位で設定できる。
- １ユニットの性能は以下である。
- 書き込み（WCU）：１秒間に最大1KBのデータを１回書き込むことが可能
- 読み込み（RCU）：１秒間に最大4KBのデータを２回読み込むことが可能
- なお、強い整合性の読み込みを利用すると、 ２回が１回に半減する。
- １ユニットの性能は以下である。
- DynamoDB Streams
- ほぼリアルタイムでDynamoDBになされた更新をストリーミング的に受けられる機能がある
- DynamoDB Streamを使うことで、項目が追加・変更された時にプッシュ通知を飛ばしたりといった実装が可能になります。今回は、そのイベントをLambdaで受け取ってみたいと思います。
- 読み込みアクティビティの急激な増大 (スパイク) を回避する
- scan
- ページサイズを小さくする
- スキャンオペレーションではページ全体（デフォルトでは 1 MB）を読み込むため、設定するページサイズを小さくすることで、スキャンの影響を軽減させることができます。
- Global Tables
- https://qiita.com/blackcat5016/items/c2af7d3d55093134bac3
- 別リージョンにテーブルの複製を作成して、最終的に同期してくれる機能。ただし、さすがにタイムラグがあるため、テーブルに強い整合性の読み取りを設定していても、リージョン間では結果整合性となる。書き込みに関しても最終的には更新時刻の遅いほうが適応される。
- -> 一時的であるがリージョン間で不整合が発生することはあり得るということを意識しないといけない。
- また制約として「空のテーブルである」ということが必要であり、後から変更することができないので、最初の設計が大事である。なお、もう一つの要件として「DynamoDB Streamsを有効化する必要あり」があるが、つまり、裏ではStreamsを利用して別リージョンのテーブルに変更を加えるだけと予想される。（それでも自分で設定しなくてよくて助かるのだが。。。）
- 並列スキャン
- 複数のワーカースレッド/プロセスを同時に実行し、各ワーカーはテーブルの別のセグメントを他のワーカーと同時にスキャンすることができます。
SQS
- キューからのメッセージを処理するプロセスは、ショートポーリング使用するか、ロングポーリングを使用するかによって異なります。
- Amazon SQS はデフォルトでショートポーリングを使用して、サーバーのサブセットだけに対して (重み付けされたランダム分散に基づいて) クエリを実行し、レスポンスに利用できるメッセージがあるかどうかを調べます。
- ロングポーリング を使用すると、コンシューマーがキューに到着するとすぐにメッセージを受信できるようにすると共に、コストを削減できます。
- Long polling
- キューが空の時、ポーリング間隔を最大20秒にする。（不必要なポーリングを減らすことで、コストを最小限に抑える）
- 空なことが多いなら、無駄な負荷下げるために設定しておく
- FIFOキュー
Cognito
- 自社でもっている認証基盤に対して、ユーザーIDとパスワードを使ってログインしてもらう という方式があります。AWS においては Amazon Cognito がその要件をかなえる筆頭サービスです。
- Amazon Cognito ユーザープールは、何億人ものユーザーにスケールするセキュアなユーザーディレクトリを作成できます。
- Amazon Cognito を使用すれば、Google、Facebook、Amazon などのソーシャル ID プロバイダーや、SAML による Microsoft Active Directory などのエンタープライズ ID プロバイダーを通してサインインすることができます。
- Amazon Cognito は、お客様のアプリのバックエンドリソースに対するアクセスをコントロールするソリューションです。ロールを定義してユーザを異なるロールにマッピングすることで、各ユーザに対して許可されているリソースにのみアプリがアクセスできるようにすることができます。
- Amazon Cognito ID プールは、AWS リソースにアクセスするための、権限が制限された一時的な認証情報を、認証されたユーザーに割り当てます。各ユーザーの権限は、作成する IAM ロールを介して制御されます。ユーザーの ID トークンのクレームに基づいて、各ユーザーのロールを選択するルールを定義できます。認証されたユーザー用のデフォルトのロールを定義できます。また、認証されていないゲストユーザーの制限付き権限を持つ別の IAM ロールも定義できます。
- ルールは順に評価され、順序をオーバーライドするために CustomRoleArn が指定されない限り、最初の一致するルールの IAM ロールが使用されます。
- Amazon Cognitoではユーザー認証機能だけでなく、ユーザデータの保管が可能な同期ストアが提供されます。
- 先日リリースされたAmazon Cognitoストリームを利用する事で、Cognito同期ストアの更新情報をKinesisに流し込む事が可能になりました。
- ロールの割り当て
- トークンを使用してロールを割り当てる際に、ユーザーに割り当てることができる複数のロールがある場合、Amazon Cognito ID プール (フェデレーテッドアイデンティティ) は次のようにロールを選択します。
- 設定されていて、cognito:roles クレームのロールに一致する場合は GetCredentialsForIdentityCustomRoleArn パラメータを使用します。このパラメーターが cognito:roles のロールと一致しない場合は、アクセスを拒否します。
- cognito:preferred_role クレームが設定されている場合は、それを使用します。
- cognito:preferred_role クレームは設定されずに、cognito:roles クレームが設定されている、GetCredentialsForIdentity への呼び出しで CustomRoleArn が設定されていない場合は、コンソールまたは AmbiguousRoleResolution フィールドの [ロールの解決] 設定 (SetIdentityPoolRoles API の RoleMappings パラメータ) を使用して、割り当てるロールが決定されます。
- トークンを使用してロールを割り当てる際に、ユーザーに割り当てることができる複数のロールがある場合、Amazon Cognito ID プール (フェデレーテッドアイデンティティ) は次のようにロールを選択します。
STS
- AWS Security Token Serviceの略称で、一時的な認証情報を発行します。
- 発行される認証情報は、「アクセスキー」、「シークレットキー」、「セッショントークン」の3つが発行されます。
- スイッチロールの際にもSTSを使用してスイッチ先の各種リソースにアクセスしてるので、認証情報さえ取り出せばうまいことアクセスキーが使えそうですね。
- 「AssumeRoleはRoleArnを入力するとCredentialsを返すAPIだ
ElastiCache
- https://dev.classmethod.jp/articles/elasticache-is-very-good-lets-review/
- ElastiCacheはデータをノードのメモリに保存するので非常に高速でデータの出し入れが可能です。ですがメモリにデータを保存しているのでノードが落ちてしまう（再起動を含む）と中のデータが無くなってしまいます。なのでElastiCacheには無くなっても良いデータを保存するようにしましょう。
- セッション情報をElastiCacheに保存してサーバがスケールしても共通のセッション情報を参照できるようにしたり、データストアに保存したデータをElastiCacheに保存してアプリケーションのキャッシュとして利用したりしましょう。
- キャッシュは揮発性のあるデータです。消えてしまうと大変なデータの保存は避けて、キャッシュにデータが無いならデータストア（DBなど）を参照しにいく設計が良いでしょう。
- 最近ElastiCacheのアップデート（機能追加や改善）はRedisの方が多いです。いろんな機能を利用したい場合にはRedisを選択して、単一ノードの性能を上げたい場合にはMemcachedを利用すると良いでしょう。
- DynamoDBじゃダメ？
- ElastiCacheに比べるとやや書き込みが遅くなります
- 高速な通信がしたい、保存するデータは書き込みと読み込みが頻繁に発生するためコストが心配
- ->ElastiCache
- データの永続化がしたい
- ->DynamoDB
- ユーズケース
- AWSでは、RDSのクエリ結果をキャッシュとして利用する方法は2種類ある
- Lazy Loading(遅延読み込み)
- キャッシュ有効期限が切れるまで古いキャッシュを読み込んでしまう
- キャッシュミス時にElastiCache, RDSとのやり取り回数が3回に増え、server <-> clientへのレスポンスが悪くなる
- Write Through(ライトスルー, 書き込みスルー)
- 読み込まれない無駄なデータがキャッシュされる可能性がある
- Lazy Loading(遅延読み込み)
Kinesis
- Kinesisストリームの暗号化は大きく以下の2方針があります。
- パーティションキー
- 例えば、2 つのシャード (シャード 1 とシャード 2) で構成されるデータストリームがあるものとします。2 つのパーティションキー (キー A とキー B) を使用し、キー A のレコードはすべてシャード 1 に追加され、キー B のレコードはすべてシャード 2 に追加されるように、データプロデューサーを設定できます。
- Firehose
- S3に直接入れたかったら、Firehose
Codeシリーズ
- CI（継続的インテグレーション）を行うためのサービスです。
- アプリケーションのコンパイルやテスト、デプロイなどを自動化することができます。
- ソースコードのトップディレクトリにbuildspec.yml を設置しておくことでビルド時に実行してくれます。
- ユーザがプロジェクトにアクセスできないようにしといて、これだけ返信させる
- 上書きするには
- 別のビルド仕様を使用するには、[Override build specification (ビルド仕様の上書き)] を選択します。
- AWS CodeStar
- 一言で言えば、CodeCommit, CodePipeline, CodeBuild, CodeDeployとそれらに付随する実行環境を一撃で構築・管理できます
- AWS CodeStarが何者か、一言で言えば、一時期に流行ったスキャホールドの類です。
- ベース部分をスキャホールド（足組）として作り、肉付けをしていくというスタイルが流行ったかと思います。
- AppSpec file
- Application Specification File (AppSpec file) は、CodeDeploy があなたの EC2 インスタンスに対して、Amazon S3 または GitHub にあるアプリケーションのリビジョンをどのようにインストールするか決定する、YAML フォーマットのファイルです。また同様に、デプロイの様々なライフサイクルイベントをフックして処理を実行するか決定します。
- AppSpec ファイルの名前は必ず appspec.yml とし、ルートディレクトリに配置しておかなればいけません。この要件を満たしていない場合、デプロイは失敗します。
- また、AppSpec ファイルが存在する場合は、これを含めたデプロイ用のコンテンツを .zip (Windows Server 以外は .tar および .tar.gz も可能) 形式の圧縮ファイルにすることができます(詳しくは Prepare a Revision を参照)。
KMS
- https://dev.classmethod.jp/articles/10minutes-kms/
- マスターキーとデータキー
- 解決策は、鍵の鍵をどこか安全な場所に保管することです。この「安全な場所」がAWSです。
- なお、KMSでは、鍵の削除はサポートしていません。マスターキーを削除すると、マスターキーで暗号化したデータキーで暗号化したデータ（ややこしいですね）を復号できなくなってしまうためです。
- 暗号化されていないデータキーは、暗号化/復号に使ったら、すぐに捨てましょう
- クォータ
- KMS APIにはクォータあり
WAF
Secrets Manager
- AWSのParameter StoreとSecrets Manager、結局どちらを使えばいいのか？
- シンプルな3-Tierの小規模WebシステムやDWH等、DBへの接続情報がプーリングされ、パラメータへのアクセスが少ない環境であれば、アプリの利用する情報の外部化にはParameter Storeの利用がコスト的にもリーズナブルである。
- パラメータやシークレット情報に対するスパイクアクセスが予想されるEC2やECSのAuto Scaling環境、Labmda等では、Parameter Storeではパラメータ情報取得のAPIリクエストを捌ききれない可能性がある。
- シークレット情報の取得リクエストが700 Req/secに収まるのであれば、Secrets Managerを試してみる価値あり。ただし有料なのでコスト試算を。
X-Ray
- 今まで AWS Lambda のパフォーマンス解析を行う時、CloudWatch やログ出力の実装である程度可能でしたが、あくまでもある程度の解析しか行うことができませんでした。
- -> それが今回のアップデートにより、AWS X-Ray により AWS Lambda のパフォーマンス解析を詳細に行うことができるようになりました。
- AWS X-Ray サポートにより、Lambda ファンクションのオーバーヘッド、初期化（コールドスタート）、処理実行時間を計測できるようになり、AWS Lambda 側なのか、ソースコード側なのか、ボトルネックを特定できるようになりました。
- EC2インスタンス上で動作するアプリケーションも
IAM
- ウエブ ID フェデレーション
- ウェブ ID フェデレーションを使用すると、カスタムサインインコードを作成したり独自のユーザー ID を管理したりする必要はありません。
- その代わりに、アプリのユーザーは、よく知られている外部 ID プロバイダー (IdP) (例: Login with Amazon、Facebook、Google などのOpenID Connect (OIDC)互換の IdP) を使用してサインインすることができます。
- 認証トークンを受け取ったら、そのトークンを AWS アカウントのリソースを使用するためのアクセス許可を持つ IAM ロールにマッピングし、AWS の一時的セキュリティ認証情報に変換することができます。
- IdP を使用すると、アプリケーションで長期的なセキュリティ認証情報を埋め込んで配布する必要がないため、AWS アカウントの安全性の維持に役立ちます。
