AWS KMSとCloudHSMについて勉強
AWS 認定ソリューションアーキテクト ? アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書
- 作者: ??部昭寛,宮?光平,菖蒲淳司,株式会社ソキウス・ジャパン
- 出版社/メーカー: インプレス
- 発売日: 2019/01/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
AWS KMSとCloudHSM
似たような機能なので一緒に確認する。AWS KMS
AWS上で鍵管理を提供するマネージドサービス。主に暗号化鍵の作成や鍵の有効・無効の管理、鍵のローテーション、削除などを行える。
鍵自体はAWS上に保存される。
ユーザが作成した鍵をKMSに保管することで、S3のサーバサイド暗号化や、データ送信前にクライアント側で暗号化も行える。
KMSと連携した暗号化処理が可能なAWSサービス
S3、EBS、RDS、Redshiftなどのストレージやデータベースサービス
CloudHSM
AWSデータセンター内に配置されるユーザ占有のハードウェアアプライアンスのこと。Applianceは「機器」「装置」などの意味だが、IT用語としては機能や用途に特化した機器や装置を指す。
つまり、アプライアンスサーバーは、特定の用途向けに設計・開発されたサーバー製品のこと。
具体的には、ファイル共有の機能だけを提供するファイルサーバーや、インターネット接続の機能だけを提供するプロキシサーバーなど、用途に応じてさまざまな種類がある。
アプライアンスサーバー | IT用語辞典 | 大塚商会
不正防止機能を持つ。
VPC内に配置され、他のネットワークからは隔離されるためコンプライアンス的に重視される場合に使用される。
CloudHSMと連携した暗号化処理が可能なAWSサービス
RedshiftRDS for Oracle
AWS Lambdaについて勉強
AWS 認定ソリューションアーキテクト ? アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書
- 作者: ??部昭寛,宮?光平,菖蒲淳司,株式会社ソキウス・ジャパン
- 出版社/メーカー: インプレス
- 発売日: 2019/01/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
- Lambdaとは
- Execution Role
- ロギング
- Lambdaのパフォーマンス、レイテンシー対策
- 機密情報を保存するために、環境変数を使用して Lambda 関数を作成する
- Lambdaのスロットリング防止
Lambdaとは
サーバなどのコンピューティングリソースを意識することなく、アプリケーションコードをデプロイしただけで実行することができるサーバーレスなサービス。アプリケーションを実行するインフラはAWSが管理。
実行時のメモリ容量と実行時間に対して課金される。高可用性と低コストを期待できる。
Lambdaは実行時間に制限がある（15分）。同時実行数は1000まで。
Lambdaは様々なAWSサービスと連携できる。S3にputされたことでキックして実行することもできる。時間起動も可能。
検証環境・本番環境で複数環境が存在する場合、Lambda上でエイリアス情報を付与することでステージ別で分けることができる。
Execution Role
LambdaにアタッチされたIAMロールのこと。LambdaはIAMロールの権限に従って各AWSサービスへアクセスするため、IAMロールによるアクセス制御設計が必要。
ロギング
処理結果のログはCloudWatch Logsに保存される。Lambdaのパフォーマンス、レイテンシー対策
コンテナ上で動いているため、初回起動はコンテナの起動時間を考慮する必要がある。起動後一定時間は起動したままとなるので、低レイテンシーを維持できる。
だが、停止した後再度起動するとコンテナの起動時間がかかってしまう。
使用頻度の低い処理は毎回遅くなってしまう。
またLambdaはVPC上に配置することができるが、VPCエンドポイントでElastic Network Interfaceを確立する必要がある。
VPC外にLambdaを構築する場合と比較するとレイテンシーが大きくなる。
レイテンシーを低くするためには Amazon SQSを用いてほっとスタンバイを維持する必要がある。
機密情報を保存するために、環境変数を使用して Lambda 関数を作成する
AWS Key Management Serviceと組み合わせることで、認証キーを暗号化することができる。
Lambda 関数の構成設定の指定に加えて、環境変数を使用して、データベースパスワード、AWS Key Management Service および Lambda コンソールの暗号化ヘルパーを使用して機密情報を保存できます。
機密情報を保存するために、環境変数を使用して Lambda 関数を作成する - AWS Lambda
リージョン内で環境変数を使用する Lambda 関数を初めて作成または更新すると、AWS KMS 内で自動的にデフォルトのサービスキーが作成されます。
このキーは環境変数の暗号化に使用されます。
ただし、暗号化ヘルパーを使用し、Lambda 関数の作成後に KMS を使用して環境を暗号化する場合は、独自の AWS KMS キーを作成し、デフォルトキーの代わりにそのキーを選択する必要があります。
デフォルトキーを選択すると、エラーが表示されます。独自のキーを作成すると、アクセスコントロールを作成、使い回し、無効化、定義できるほか、データの保護に使用される暗号化キーを監査できるなど、より高い柔軟性が得られます。
AWS Lambda 環境変数 - AWS Lambda
Lambdaのスロットリング防止
ある関数で同時実行数が急増すると実行制限で隔離した機能がスロットリングされることを回避する。
つまり、関数は実行されなくなってしまう。
・同期呼び出し: 関数が同期的に呼び出され、スロットリングされた場合、Lambda は 429 エラーを返し、呼び出し元のサービスで再試行が必要になります。
・非同期呼び出し: 非同期的に呼び出された Lambda 関数がスロットリングされると、AWS Lambda はスロットリングされたイベントを最大 6 時間自動的に再試行します (再試行間には遅延があります)。
DynamoDBについて勉強
AWS 認定ソリューションアーキテクト ? アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
- DynamoDBとは
- ユースケース
- DynamoDBのデータ保存
- オンデマンドバックアップ
- DynamoDB Accelerator(DAX)
- DynamoDB Auto Scaling
- DynamoDB Streams
- グローバルテーブル
- 一時的なアクセス集中に耐えるために
DynamoDBとは
マネージドであり、キーバリュー型でデータを簡易に操作することができる機能。リージョンサービスのため、特定のAZ内で利用等はできない。（DynamoDBをマルチAZ構成するというものがそもそも不可能）
NoSQLデータベースサービス
NoSQLとは非DBMSの総称。通常のテーブルデータなどの構造データに加え、以下もサポートしている。
テスト的にはDynamoといえば非構造データ・半構造データであるということがメイン且つ、ユーザIDの情報が格納されるという話でよく出るイメージ。
逆にできないこと（向かないこと）は
- JOINやCOMMITなどの通常のRDBSで可能なもの
- 検索や結合など詳細な処理
- 大量のデータ読み書き（読み書きに対してコストがかかる）
キーバリューストア型
「数値」と「文字」でワンセットで保存される。文字は、単純に文字列だけではなく、JSONのような半構造データもいける。
ユースケース
DynamoDBのメリットは高い信頼性とパフォーマンスを維持できる点。主なユースケースは
- 大量データの収集・蓄積・分析するためのデータベースや、Hadoopとの連携などのビッグデータ
- データの高速処理が必要なアプリケーション
- 多数のユーザが一度にアクセスするようなアプリケーション処理
- ユーザ情報やゲーム、広告などのユーザ行動向けデータベース
- ユーザIDごとの複数の行動履歴管理などの単純に情報を蓄積するもの
- モバイルアプリのバックエンドや、バッチ処理時のロック、フラッシュマーケティング、ストレージのインデックスなど、バックエンドのデータ管理
モバイルゲームや広告配信システム、IoTのセンサーデータのデータベースなど可用性、大量データ処理（構造データ以外）に向いている。
ただし、複数テーブルの結合等通常のDBMSが得意なことは、DynamoDBは得意ではないので注意。
またアクセス頻度の低い古いレコードの保存は設計パターン上推奨されていない。
通常、データ取り込みシステムには以下が必要です。
・現在の時間に関連する新しいレコードを取り込むための高い書き込みスループット。
・最近のレコード用の低いスループット。
・古いレコード用の非常に低いスループット。
このようなイベントをすべて単一の DynamoDB テーブルに格納する場合、ホットパーティション (最新のレコード) とアクセス頻度の低いパーティション (古いレコード) があります。
アクセス頻度の低いパーティションは、プロビジョニングされた書き込み容量を、新しいレコードを保存しておきたいホットパーティションから逸らしてしまうため、最適ではありません
Amazon DynamoDB の大量の時系列データの設計パターン | Amazon Web Services ブログ
DynamoDBのデータ保存
3ヶ所のアベイラビリティゾーンで保存される。*1結果整合性モデル
S3と同様に結果整合性モデルを採用している。結果整合性とは、途中で整合性が崩れた状態になるが、十分な時間がたったら最終的には整合性が取れた状態になる。
即時反映はされない。
何故なら上で書いているように3ヶ所のアベイラビリティゾーン書き込みに行くため、処理完了までに多少なりとも時間差が発生する。
また、書き込み成功判断はアベイラビリティゾーン2ヶ所に書き込みが成功した場合のため、データのreadとwriteが多数行われると、情報の一貫性が取れていないアベイラビリティゾーンから取得しに行く可能性があるため、一貫性を取っていない。
ただし、それだとDBとして使い勝手が悪いので、一貫性を保ちたいのであれば、「Consistent Read」（読み取り一貫性）オプションが提供されている。
このオプションを利用することで書き込みが反映された最新データを参照するようになる。
使用するインデックス
ハッシュキーやレンジキー（複合キー）では検索条件を満たさない場合に利用する。インデックスを使用することで検索速度は上がるがその分課金も増える。
オンデマンドバックアップ
バックアップを取得する方法として、AWS Data Pipelineを使ったデータのエクスポート、インポートを使用することで実施が可能となる。任意のタイミングで利用叶おうな長期間データ保存用のバックアップとなる。
AWS Data Pipeline を使用して、DynamoDB テーブルから Amazon S3 バケット内のファイルにデータをエクスポートできます。
コンソールを使用して、Amazon S3 から同じまたは異なる AWS リージョンにある DynamoDB テーブルにデータをインポートできます。
AWS Data Pipeline を使用して DynamoDB データをエクスポートおよびインポートする - Amazon DynamoDB
異なるリージョンからでもインポートができるというのがポイントだと思う。
DynamoDB Accelerator(DAX)
DynamoDB用のインメモリキャッシュ。DynamoDBの間にDAXというキャッシュクラスターを設置することができるため、DynamoDBへのアクセスを行う前にキャッシュから情報を取得するということが可能になる。
キャッシュを置くことで1秒当たり100万回単位のリクエストの応答時間を数ミリ秒に短縮することが可能。
運用上アプリケーションの複雑性を減少させて容易に導入可能。
DynamoDB Auto Scaling
今回対応したDynamoDBのAuto Scalingは負荷に応じてwrite capacity units（書き込み容量ユニット）とread capacity units（読み込み容量ユニット）のスループットを上下できるものとなります。
[新機能] Amazon DynamoDBでAuto Scalingが可能に！ | Developers.IO
読込と書込の負荷をスケールできる機能。
読取（書込）の負荷が高い場合にどうするべきかというときに考え付く選択。
あるデータにアクセス集中するみたいな感じだとDAXを採用したほうが良い。
DynamoDB Streams
DynamoDBに対して追加、変更、削除の履歴をキャプチャできる機能。過去24時間以内のデータ変更履歴を保持。24時間を経過すると削除される。
操作が実施された順番でデータがシリアライズ（並ぶ）される。
ハッシュキーに基づいた変更は正しい順番で保存されるが、ハッシュキーが異なる場合は順番が前後する可能性がある。
inputはS3やKinesisやユーザのアプリケーションが多い。
DynamoDB のテーブルに対するすべての更新(Put, Update, Delete)が直近の24時間保持され、API 経由でアクセスできるようになります。
DynamoDB のテーブルの更新などのイベントがフックできるため、これをきっかけに別なテーブルに更新をかけたり、SNS で通知したり、用途に応じてさまざまな処理を行うことができます。
AWS Lambda と Amazon DynamoDB Streams を連係する | Developers.IO
ユースケース
データ更新をトリガーとしたアプリケーション機能やレプリケーションに活用が可能。DynamoDB Sreamsの使い所は、クロスリージョンレプリケーションやゲーム・ソーシャルサイト等でのユーザの集計・分析などのための非同期処理などとなります。
あるいはユーザが新しい写真をアップロードするとすぐにサークル内のすべての友人のモバイルデバイスに自動的に通知するモバイルアプリケーションの構築などが考えられます。
DynamoDB Streams - Qiita
クロスリージョンレプリケーション
DynamoDB Streamsによる変更のキャプチャをトリガーとして、クロスリージョンレプリケーションを実現する。
AWS リージョン間で自動的にレプリケートされるテーブルを作成できます。複数書き込みの完全にサポートされます。これにより、レプリケーションプロセスを管理することなく、グローバルユーザーベース用に高速かつ大規模にアプリケーションを構築できます。
クロスリージョンレプリケーション - Amazon DynamoDB
データ更新をトリガーとしたアプリケーション機能
データ更新に応じて通知処理などアプリケーション処理の実行などができる。
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern from Amazon Web Services Japan
グローバルテーブル
リージョン間で同期されるマルチマスターテーブルを作成可能。クロスリージョンレプリケーションに該当するもの。強い整合性モデルは使用不可となる。
一時的なアクセス集中に耐えるために
DynamoDBに対して一時的なアクセス集中が発生する場合対応できるケースとしては、- DynamoDB Accelerator(DAX)を利用
- ElastiCache を利用
- SQS→DynamoDBの構成にする
- AutoScaling→DynamoDBの構成にする
DAXとElastiCacheは基本的に高いため、費用対効果を求めるのであればSQSとAutoScalingで対応する。
SQS→DynamoDBの構成にする
大量データ処理時に知っておきたいAmazon DynamoDB活用テクニック4選 (2/3)：大規模プッシュ通知基盤大解剖（2） - ＠IT より引用
上記のようにDynamoDBの前にSQSをセットすることで、キューイング処理されて負荷を下げることが可能になる。
AutoScaling→DynamoDBの構成にする
次のステップは、前の図に示された Auto Scaling のプロセスをまとめたものです。
- DynamoDB テーブルの Application Auto Scaling ポリシーを作成します。
- DynamoDB は消費されたキャパシティーメトリクスを Amazon CloudWatch に発行します。
- テーブルの消費されたキャパシティーが一定期間中にターゲット使用率を超える（または下回る）と、Amazon CloudWatch はアラームをトリガーします。コンソールのアラームを表示し、Amazon Simple Notification Service (Amazon SNS) を使用して通知を受けることができます。
- CloudWatch アラームは Application Auto Scaling を呼び出してスケーリングポリシーを評価します。
- Application Auto Scaling は UpdateTable リクエストを発行し、テーブルのプロビジョニングされたスループットを調整します。
- DynamoDB は UpdateTable リクエストを処理してテーブルのプロビジョンドスループット性能を動的に増減し、ターゲット使用率に近づけます。
上記のようにCloudWatch AlermからAutoScalingを呼び出して、DynamoDBの読み込み・書き込みキャパシティを一時的に上げたり下げたりする（UpdateTable リクエスト）ことが可能。
RDSについて勉強
AWS 認定ソリューションアーキテクト ? アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書
- 作者: ??部昭寛,宮?光平,菖蒲淳司,株式会社ソキウス・ジャパン
- 出版社/メーカー: インプレス
- 発売日: 2019/01/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
- RDSについて
- パッチをいつ適用するのか
- バックアップと復元
- マルチアベイラビリティゾーン
- リードレプリカ
- 障害発生時の挙動
- データベース内のレコードの破損
- Amazon RDS データベースインスタンスに接続できない場合
- RDSのボトルネックを防ぐ
RDSについて
Amazon Relational Database Service(RDS)はマネージド型のリレーショナルデータベースサービス。
サポートしているデータベースエンジンは以下
・Amazon Aurora
・PosgreSQL
・MySQL
・MariaDB
・OracleDB
・Microsoft SQL Server
Amazon Aurora
AWSが開発したリレーショナルデータベース。PosgreSQLやMySQLと互換性があるので、アプリケーションをほとんど変更せずデータを移行することができる。
スループットはPosgreSQLの3倍やMySQLの5倍のスループット。
データは3ヶ所のアベイラビリティゾーンに格納される。
ひとつのアベイラビリティゾーンにつき2ヶ所のディスクに書き込みに行くため、結局6ヶ所に保存されます。
そのためほとんどダウンタイムなく使うことができる。
Aurora含めDBの流れはこのポッドキャストが詳しい。
fukabori.fm
パッチをいつ適用するのか
RDSでは曜日や時間帯をメンテナンスウインドウで指定するだけで、AWSが自動的にパッチを適用する。マルチアベイラビリティゾーンを利用している場合、まずスレーブデータベースのメンテナンスを行う。
完了後、スレーブデータベースをマスターデータベースに昇格する。
最後に、メンテナンス前マスターデータベースをメンテナンスする。この旧マスターデータベースはスレーブデータベースのままになる。
バックアップと復元
標準設定の場合、バックアップは1日1回自動で行われる。データベースとトランザクションログを取得する。スナップショットと自動バックアップは S3 に保存される。
データベースのバックアップはストレージボリュームのスナップショットをとりデータベース全体のバックアップを取得する。
保存期間は最大35日分。手動でバックアップを取ることも可能。
データベースを復元するためには、バックアップからデータベースインスタンスを作成して起動する。
トランザクションログも取得しているので、バックアップ取得時点に近い復元が可能。これをポイントタイムリカバリという。
RDSはデータベースインスタンスのトランザクションログを5分ごとに取得している。
マルチアベイラビリティゾーン
RDSを複数のアベイラビリティゾーンに構築すること。Aurora以外のRDSデータベースは、マルチアベイラビリティゾーンインスタンスを作成すると、同時に異なるアベイラビリティゾーンにスレーブのインスタンスにもデータを複製する。
この構成にすることで、耐久性と可用性があがる。
なぜならマスターのアベイラビリティゾーンが障害になっても、スレーブがアベイラビリティゾーンに昇格させることができるから。
ただし、複数のアベイラビリティゾーンにデータを複製しているのでコストがかかる。
マルチアベイラビリティゾーン構成にしない場合、障害発生時のデータ切り戻しが直近5分以内までしか戻せないので、どうしても戻せない箇所が発生する。
データの欠損がおこらない点でマルチアベイラビリティゾーン構成に利がある。
リードレプリカ
マスターデータベースと同じデータベースを複製し、複製したほうを読み取り専用とすること。読み取りスループットを増やすことでパフォーマンスを向上できる。
リードレプリカは、MySQL、MariaDB、PosgreSQL、Auroraで利用することができる。
マルチアベイラビリティゾーンや異なるリージョン間で構築できる。
マスターデータベースと異なるインスタンスタイプやストレージで構築することも可能。
マスターデータベース側との同期は非同期で行われる。
障害発生時の挙動
シングルアベイラビリティゾーン構成時
障害発生時、自動的に再起動する機能があるのでユーザ側で再起動のオペレーションは不要。データはトランザクションログを使用したポイントタイムリカバリでの復元等行う。その場合5分単位での取得なので、どうしても戻せない箇所ができるので注意。
マルチアベイラビリティゾーン構成時
マスターデータベースに障害が発生した場合、自動的にスレーブへフェールオーバーを行う。具体的には、
そのため、RDSのエンドポイントを変えず何も考えずシームレスに切り替えられる。だが、若干のダウンタイムが存在する。
また、マスターデータベースとスレーブデータベースは同期されているので、リカバリの必要はない。
データベース内のレコードの破損
オペレーションミスなどによってデータベースが破損した場合、バックアップからのリストアになる。
- 障害が発生したRDSのエンドポイント名を控える
- 別のエンドポイント名に変更する
- バックアップから変更前のエンドポイント名でリストアする
- 別のエンドポイント名にしたRDSを削除する。
Amazon RDS データベースインスタンスに接続できない場合
こちらを参考。
aws.amazon.com
まだデータベース構築中
DB インスタンスのサイズに応じて、インスタンスがネットワーク接続に利用可能になるまで 20 分ほどかかる場合があります。
DB インスタンスで接続が受け入れられることを確認します。
そのためには、RDS のコンソールで DB インスタンスの正常性と RDS DB インスタンスのライフサイクルを確認します。
焦らずに作成完了するまで待とう。
セキュリティグループの設定をしていない
デフォルトでは、DB インスタンスはアクセスを許可していません。
アクセスはセキュリティグループを介して許可されます。
アクセスを許可するには、特定の Ingress ルールと Egress ルールを設定した独自のセキュリティグループを作成する必要があります。
ネットワークACLの設定がおかしい
接続に使用しているソースからの接続を許可するように、RDS DB インスタンスの VPC セキュリティグループが設定されていることを確認します。
IP アドレス、IP アドレスの範囲、または別の VPC セキュリティグループを指定できます。
DB インスタンスに接続できるが、認証エラーが発生する場合は、「接続認証のトラブルシューティング」で説明しているように、DB インスタンスのマスターユーザーパスワードをリセットできます。
RDSのボトルネックを防ぐ
以下を実施することでRDS遅い問題を解決していく。
- リードレプリカで読み取りスループットを増やすことでパフォーマンスを向上する。
- ElastiCacheを使用して、メモリキャッシュをすることでデータベースへの負荷を減らす。
S3について勉強する
AWS 認定ソリューションアーキテクト ? アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
- Amazon S3(Simple Storage Service)について
- S3の各用語とファイル構造
- ストレージ
- S3 intelligent-tiering
- S3の結果整合性モデル
- バージョニング機能
- アクセス制御
- 暗号化
- 監視
- クロスリージョンレプリケーション
- クロスリージョンリソースシェアリング(CORS)
- AWS Storage Gateway
- ログ保存
- ライフサイクルルールの適用
- AWS Transfer Acceleration
- Glacier
- Glacier Deep Archive
- 静的Webサイトホスティング時の注意点
- 複数のユーザがアクセスするS3をまとめて管理する場合
Amazon S3(Simple Storage Service)について
高耐久・大容量のオブジェクトストレージサービスで、マネージド型で提供されている。利用可能容量に制限がなく、利用した分だけ料金が発生するシステム。
リージョンサービスとなる。
S3の特徴は以下に記載する通り
高耐久性
デフォルトで同一リージョン内の3ヵ所のAZに自動的に格納するため高い耐久性を持つサービスとなる。またAZ間は低遅延のプライベートネットワークで接続されている。
SLA上、耐久性は99,999999999%。
ただ可能性の側面では耐久性には劣る。SLA上は99.99%。
安価
容量単価は月額１GBで約3円ほど。S3のサービスとしては、Readなどで課金するタイプ。
S3の各用語とファイル構造
S3は大きく分けてバケットとオブジェクトに分類される。バケット
オブジェクトが格納される場所。ディレクトリに近い。名前はグローバルでユニークてある必要性があるため、「test」とか安直なものは使用されていて使えない可能性が高いので注意。
オブジェクト
S3に格納されるファイルでURLが付与されている。バケット内オブジェクト数は無制限。
ひとつのオブジェクトサイズは0バイト～5TBまで。
ただし1回のPUTでアップロード可能なオブジェクトのサイズは最大5GBまでなので、それを超過する場合はマルチパートアップロードを使用する。
S3のファイル構造
S3のファイル構造はURLを見る限りは階層構造があるよう見えるが、階層構造ではなくすべてフラットに格納されている。（ファイルの上部階層もディレクトリではない）階層構造があるように見えるのは人間が見てわかりやすいため。
マルチパートアップロード
大容量ファイルを分割して送ることで1回のPUTできるサイズ5GB以上のファイルを格納できる。100MB以上のファイルをPUTする場合はこちらが推奨される。
5GBあるファイルをPUTするときのパフォーマンスあげるにはというような問題の場合はこれを選択するのがよさそうか。
ストレージ
利用意図にあわせて数種類存在する
STANDARD（スタンダード）
デフォルトのストレージクラス。上で書いた同一リージョン内の3ヵ所のアベイラビリティゾーンに自動的に格納する。
通常使用する場合はこれを使用する。
耐久性：99,999999999%、可用性：99.99%
STANDARD-IA（標準低頻度アクセス）(Standard-Infrequent Access)
スタンダードと同様に3ヵ所のアベイラビリティゾーンに保存するため、STANDARDと同等の耐久性を持っているストレージクラスで、STANDARDよりも安価。STANDARDと違う点は、読み出し容量に対して課金を実施する点。
そのため頻繁にアクセスするような場合は結果的にSTANDARDよりも高くなるというケースがあり得るので、頻繁にアクセスるデータはSTANDARDにしたほうがよい。
主にバックアップ用。
耐久性：99,999999999%、可用性：99.99%
ONE ZONE-IA(1ゾーン低頻度アクセス)(One Zone-Infrequent Access)
基本的にはSTANDARD-IAと同様のユースケースだが、耐久度をSTANDARD-IAより求めない場合に利用。耐久度を求められない理由は、このストレージクラスは3ヵ所ではなく、1ヶ所のアベイラビリティゾーンのみにデータを保存するため。
コストはSTANDARD-IAよりも少ないため、後述するGlacierよりもすぐに取り出したいけど、そんなに重要ではないデータに利用する。
バックアップデータや、一時的に格納するデータ、消えても大丈夫なログ用となる。
耐久性：99,999999999%、可用性：99.95%
S3 Glacier
ONE ZONE-IAよりも低コスト。ただしビジネスモデルとしてデータ取出で課金をするモデルのため、データ取出コストや、取出時間もかかる機能となる。
通常直接S3 Glacierに対してデータを投入することはない*1ので、S3のライフスタイルによって格納されることになる。
ボールドロック機能で、データの削除を防止したりもできる。
詳細は後述。
耐久性：99,999999999%、可用性：復元後99.99%
S3 Glacier Deep Archive
S3 Glacierよりももっと低コストでデータをアーカイブしたい場合に使用する機能。ただし、データの取出しも一番かかるので、データを取出しに時間がかかってもいいから安く補完したいというときに使用する。
耐久性：99,999999999%、可用性：-
S3 intelligent-tiering
バケットに保存されたオブジェクトが長時間アクセスがなかった場合に、より低価格なストレージ（低頻度ストレージ）に移動させることでコストを削減しようという設定。
Amazon S3 のライフサイクルを使用したオブジェクトの移行 - Amazon Simple Storage Service
30日間アクセスがないものを低頻度ストレージにもっていくのがよい。
また低頻度ストレージからアクセスされた場合は、高頻度アクセスに戻るためデータの活用が不明なものもコスト削減しながら運用することが可能となる。
S3の結果整合性モデル
S3の更新や削除は結果整合性モデルを採用している。
結果整合性とは、途中で整合性が崩れた状態になるが、十分な時間がたったら最終的には整合性が取れた状態になる。
即時反映はされない。
www.slideshare.net
問題的にはPUTがうまくいくと200が返却されるという点、
結果整合性上、すぐには確認するとデータが残りっぱなし。
最終的には整合性取れる。「最終的に」というワードが重要。
バージョニング機能
オブジェクトの世代管理ができる。バージョンはオブジェクト単位でバージョンIDが採番される。同名オブジェクトをuploadすると上書きされる
バケット上に古いージョンのデータが残りっぱなしになり、容量を食うためライフサイクル管理で古いバージョンを削除する必要がある。
アクセス制御
大きく分けて3種類あり、アクセス制御の強度としては、
となる。
S3はほかの機能とは違い、インターネットからのアクセスができる設定を実施することができる。（静的Webサイトホスティングのため）
IAMポリシー
IAMユーザやIAMロールからのS3やバケットへのアクセス権限制御をする。S3やそれ以外の機能も含めて一元的に管理したい場合に使用。
バケットポリシー
バケット自体に制御をかける。JSONコードを直接記載する。S3リソースにだれがアクセスできるのかを定義する。
ほかのアカウントからのアクセス制御も実施することができる。
CloudFrontなどでCDN経由の場合のみアクセスを許可するなどの場合に使用する（OAI）
ACL(アクセスコントロールリスト)
バケット・個々のオブジェクトに対してのAWSアカウントレベルの制御。ACLでパブリックアクセスの設定をすると、不特定多数のユーザに公開できる。
安易的にアクセス管理したい場合に使用する。
通常はバケットポリシーを使用する。
バケットがパブリックアクセスになっている問題
意図せずバケットが全公開になっている場合、S3コンソール上や、AWS Config上でチェックするマネージメントルールが提供されている。
BlockPublicAccess上でアカウントレベル、アカウントレベルで全公開になるのを抑制できる。
新規で作成されるバケットにはデフォルトで適用される。
ACLの単位で、パブリックなオブジェクトをアップロードさせない、無力化させる。
パブリックなアクセスを許可するバケットポリシーを使用させないようなことができる。
署名付きURL
AWS CLIやAWS SDKを利用して、署名付きURLを発行することができる。※署名付きURLはS3上のデータに対して一定時間だけアクセス許可するためのURLを発行するもの。アクセス可能な時間を自由に決められるので、ファイル授受をよりセキュアにできる。
これをやることで、ACL上でフルオープンになっているから直接リンクされて困るみたいなときに、防ぐことができる。
（ACL上でのフルオープンもやめたほうがいいよね……）
静的Webサイトホスティング
CloudFrontと組み褪せて、静的なサイトをS3で用意することができる。メンテナンス時のWebページ。暗号化
サーバサイド側暗号化
S3はサーバサイトの暗号化を以下3種類持っている。
キーの管理を極力実施したくない場合、SSE-S3（S3でのデフォルトのサーバサイド暗号化）を利用するのがよい。
AWS CLIやAWS SDKを利用することでサーバサイドの暗号化指定も可能。
SSE-KMSはKMS上で暗号化キーを作成し管理する。（自分のキーも使用できる）
SSE-KMSとSSE-S3の違い
以下がわかりやすかったので引用
ktrysmt.github.io
SSE-KMSの特徴
・キーポリシーでCMK(カスタマーマスターキー)への個別のアクセス制御ができる
・KMSに対するAPIコールに当たるため、監査証跡(CloudTrail)を残すことが可能
・暗号化キーの作成および管理ができる
・当該AWSアカウントのリージョンごとに一意に作成されるデフォルトサービスキーを使用することもできる
・KMS利用分の追加料金が発生
・S3に対するPut/Getが非常に多くなる場合には KMS の APIコールの制限 の考慮が必要
SSE-S3の特徴
・キーに対する個別アクセス制限は不可、実質的なアクセス制限は署名バージョン4による当該AWSアカウントID以外の拒否のみとなる
・監査証跡(CloudTrail)には残らない
・KMSに比べキーの選択肢は無く提供されるもののみ使用できる
・SSE-S3のための追加料金は発生しない
・APIコールの制限に関して考慮は不要
CloudTrailに残せるか残せないか、鍵のバリエーションがあるかないか、追加料金の有無、APIコールの制限が大きな違い。
KMSのほうが監査にのる点と、鍵のバリエーションでよいが、APIコールの制限と料金を考えるとS3のほうが良いという感じだろうか。
クライアント側暗号化
AWSへデータを送信・保存する前にユーザー環境でデータの暗号化を行う。
クライアント側で暗号化する場合、ユーザ側でファイルに対して暗号化、パスワード処理を施してからアップロードを行う。
AWS SDKを使用することでプログラムからS3アップロード時にファイル暗号化も可能。
監視
S3アクセスアナライザー
S3アクセスアナライザーを使用し、不正なアクセスが発生していないかアクセスポリシーを監視する機能。
バケットポリシー、ACLのモニタリング。
どのバケットがどのような権限がセットされているのかを見ることができる。
またバケットの実際のアクセス状況の確認も可能
クロスリージョンレプリケーション
異なるリージョン間のS3バケットオブジェクトのレプリケーションを実施する。バケットに対するオブジェクトの作成、更新、削除をトリガーに非同期レプリケーションする。
マネージドサービスとして、AZにまたがって堅牢な構成にもともとなっているが、それに加えてさらにリージョン間でもデータを保持したいという要望の場合に使用する。
対象元のバケットに対し、バージョニングの機能を有効にする必要がある。
また対象元<-->対象先で双方向でレプリケーションをしたい場合は、両方のバケットに設定が必要。
異なるアカウントが所有するバケットにも設定できる。
クロスリージョンリソースシェアリング(CORS)
CloudFrontで使用される、特定のドメインにロードされたアプリケーションが異なるドメイン内のリソースと通信する方法を定義。sample.a,comとsample.b.comのドメインは基本的にはどちらかしかアクセスができないが、この機能を使用すると複数のドメインも通信することが可能になる。
AWS Storage Gateway
オンプレミスとAWSを接続するためのサービス。
AWS Storage Gatewayでできること、使いどころのポイント (1/2)：CodeZine（コードジン） より引用
オンプレミスからバックアップをS3に置きたいというの基本的なユースケースとなる。
具体的には
AWS側の機能や性能をオンプレミス側が活用できるのが大きな利点。
- シームレスにオンプレミス側から機能を使用できる。
- キャッシュを活用した低レイテンシーなアクセスが可能
- 堅牢性・低コスト・拡張性も得ることができる
- 効率的なデータ転送
- AWSのモニタリング・管理・セキュリティも使用できる
AWS Storage Gatewayのタイプ
ファイルゲートウェイ
Storage Gatewayを経由してファイルデータを格納するものボリュームゲートウェイ
VTLを除くボリューム型のStorage Gatewayでは、Storage GatewayはiSCSIターゲットとして動作する。保管型ボリューム、キャッシュ型ボリューム
ログ保存
CloudTrailやELBのログ出力先として利用可能。S3へのアクセスログを取得することも可能。
ライフサイクルルールの適用
ライフサイクルルールを適用することで、オブジェクト生成から設定日付経過したオブジェクトを削除するように設定できる。30日よりも前のデータが要らなければ30を指定する。
スタンダード上に生成したファイルを30日後にGlacierにアーカイブしたい場合は、ライフサイクルルールを使用するとよい。
スタンダード -> 標準低頻度アクセス(Standard-Infrequent Access) -> Glacierの順番でアーカイブする場合、スタンダードで30日以上、Standard-IAで30日以上経過する必要がある。（計60日以上）
www.slideshare.net
AWS Transfer Acceleration
クライアントとS3バケット間で長距離にわたるファイル転送を高速、簡単、安全に実行できる。ユースケースとしては
- 世界中にファイルをアップロード、ダウンロードする場合
- 大陸間で定期的にギガバイトからテラバイト単位のデータ転送がある場合
- S3へのアップロード時にインターネット経由で利用可能な帯域を十分に活用できていない場合
Glacier
大容量データを安価で保存できるのが、データへのアクセスに時間がかかる。機能のモデル上、保存はS3よりも安くなるが、データの取出しで取出しのGB単位で課金＋リクエスト件数でも課金されるため、データ取出しにより課金するモデルとなっている。
Glacierはデータをアーカイブという形で保存される。
アーカイブした場合のマスターはS3ではなくGlacierになる。
ひとつのアーカイブの最大サイズは40TB。保存可能なアーカイブ数とデータ量に制限はない。
AES-256で自動的に暗号化している。
S3と違って直接アップロードする取得するという手段ができない。
主にデータアーカイブ用としてめったに触らないファイルを格納するのが良い。
ボールドロックを行うことでデータの削除を防ぐことができる。
Glacierでアーカイブしたデータを復元したい場合、以下のオプションを設定することで復元可能
迅速(Exprdited)
1～5分で復元可能。通常はオンデマンド。成功する保証がないタイプ。
プロビジョニングタイプだとリクエストはすぐに処理されるが、費用が高価
標準(Standard)
3～5時間で復元可能。大容量(Bulk)
5～12時間で復元可能。最も低価格で、大量データ（ペタバイトのデータを含む）を取得できるのが特徴。
上記にもあるけどレイテンシの観点でGlacierとそれ以外がかなり違う。他はミリ秒なのにGlacierは分時間単位なので。
データの削除
Glacierは最低90日間保持しなければデータを削除できない。もし少しの期間だけ格納して削除したいという場合は、S3に格納して削除したほうが値段が安くなる可能性がある。
また、S3上のデータを削除するとGlacier側のデータも削除される。
Glacier Deep Archive
Glacierよりも値段が安くデータ保存が可能だが、データ取得がさらに遅くなる中長期保存用ストレージタイプ。データは3つ以上のAZにまたがって保存される（S3と同様の耐久性）
標準取出しで12時間以内
大量取出しで48時間以内
静的Webサイトホスティング時の注意点
403エラーが出る場合
403エラーつまり接続先のサイトがなくて、アクセスできなかった場合になる。HTTP 403、またはエラーメッセージ Forbidden（「閲覧禁止」「禁止されています」の意）は、HTTPステータスコードの一つ。ページが存在するものの、特定のアクセス者にページを表示する権限が付与されず、アクセスが拒否されたことを示すもの。また、サイトの制作者側の設計ミスによる障害やサイトが非常に混雑している時、URLが間違っている場合にも表示されることがある。
HTTP 403 - Wikipedia
S3においてちゃんと置いたはずなのにつながらないパターンのやつだが、原因はアクセス制限がかかっていて見られないというものになる。
つまりバケットポリシーが設定されていない場合でのエラーになる。
503エラーが出る場合
503エラーつまり接続先がダウンしてしまっている場合になる。
HTTP 503、またはエラーメッセージ Service Unavailable（「サービス利用不可」「サービスが利用できません」の意）は、HTTPステータスコードの一つ。一時的にサーバーにアクセスできないことを示す。
HTTP 503 - Wikipedia
その場合は、パーティショニングに問題があるので確認する。
複数のユーザがアクセスするS3をまとめて管理する場合
S3アクセスポイントを利用することで、あるユーザはアクセスしないがあるユーザはアクセス可能にするなどの対応が可能。S3 Access Points によって、お使いのアプリケーションセットから S3 上の共有データセットへのデータアクセスの管理がシンプル化されます。たった 1 つの複雑なバケットポリシーを管理するのに、数百におよぶアクセス許可ルールの書き込み、読み取り、追跡、監査をする必要はなくなりました。S3 Access Points を使用すると、特定のアプリケーション向けに用意されたポリシーを使用して共有データセットへのアクセスを許可するアクセスポイントをアプリケーションに合わせて作成できます。
Amazon S3 Access Points - アマゾン ウェブ サービス
バケットポリシーが煩雑になるならこちらを使用するのがよさそう。
Auto Scalingについて勉強
AWS 認定ソリューションアーキテクト – アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
- Auto Scalingとは
- 希望する容量（Desired Capacity）を目標とする
- スケールの具体的な方法
- オートスケールできる機能
- CloudWatch×Auto Scalingによる最適化の実現
- スケールイン時にどの Auto Scaling インスタンスを削除するかを制御
- よくある質問
Auto Scalingとは
リソースの使用状況をモニタリングし、その使用状況に応じてEC2インスタンスを自動でスケールアウトしたり、スケールインするサービス。あらかじめ設定したAMIからEC2を起動するので、AMIを最新化しておかないと、断面ずれが起きる可能性がある。
ユーザデータを利用してS3やGitからソースやスクリプトを取得することで、EC2インスタンスを最新の状態にすることができる。
特徴は、スケーラビリティの確保になる。
ELBでトラフィックの分散をして可用性を担保していたとしても、その分散を超えるアクセスが来た場合に対処ができないため、大量アクセスなどが発生した場合にそれに合わせてEC2を台数の増減などを行うことができる。
希望する容量（Desired Capacity）を目標とする
希望容量は、現実のEC2などの軌道台数との差を監視し、常に希望台数と合致するようにインスタンス数などを増減する仕組みのこと。
20191002 AWS Black Belt Online Seminar Amazon EC2 Auto Scaling and AWS Auto Scaling from Amazon Web Services Japan
Auro scaling group
スケールするインスタンスの最大数などの基本情報を設定する。- 起動インスタンスの最大数と最小数を設定する
- 希望容量になるようにインスタンスを起動・終了を調整する
- 軌道台数をAZ間でバランシングする
- AZ障害時に障害のないべつのAZにその分のインスタンスを起動する（AZの障害も見れる）
Auro scaling groupを利用することで、スケールアウトさせるときにAZを判断して最も少ないAZに新規起動させるなどもできる。
AZ間で偏りが発生しないように均等に配置することができる。
ミックスインスタンスグループ
オンデマンドインスタンスとスポットインスタンスをひとつのAutoScalingGroupで管理することが可能：オンデマンド：スポット＝９：１といった指定ができる。
オートスケーリングの起動設定
起動時のEC2インスタンス情報の定義。・使用するAMI
・インスタンスタイプ
・セキュリティグループ
・キーペア
などEC2を構築するときの必要なパラメータを設定してスケールアウトのインスタンス内容を決める
スケーリングプラン
以下でAuto Scalingを実行する条件を定義。サイズの維持：固定された希望容量に対し、障害などで停止するとの固定容量になるように維持する
- 手動スケーリング：希望容量を手動で変更して、スケールアウト/インを行う
- 自動スケーリング：CloudWatch Alarmなどが実行するとスケーリングポリシーに準じて自動で希望容量が変更されてスケールアウト/インを行う
- 予測スケジュール：予測された需要増時期に合わせたスケジューリングポリシーに準じてスケールアウト/インを行う
また、予測スケジュールと自動スケーリングを組み合わせることによって、アクセスされるピーク時までスケールさせて（予測スケジュール）さらに想像以上の台数が来た場合に、動的に希望容量を変えるということも可能になる。
スケールの具体的な方法
スケーリングのプランについては上に記載の通りだが、具体的にどのようにスケーリングするのかについては以下となる。
- 動的なスケーリング
- 予測スケーリング
- スケジュールスケーリング
動的なスケーリング
簡易スケーリング
EC2のみに使用できる。ひとつのCloud Watchメトリクスに対しひとつのスケーリング条件を指定する。
（CPU使用量50%超えたら1台追加など）
現在は非推奨。ステップスケーリングに切り替えることがおすすめされる。
ステップスケーリング
ひとつのCloud Watchメトリクスに対し複数のひとつのスケーリング条件を指定する。（CPU使用量50%超えたら1台追加、60%超えたら2台、70%超えたら3台など、複数設定可能）
CPU使用量によって台数を変化させるため、急激にCPU使用量が増加した場合、設定した台数よりも多く（少なく）スケールされる可能性がある。
（具体例としてはCPU50％超えたのでインスタンスを起動させていているが、70%を超えたので3台追加すると計4台追加してしまうため、想定の3台よりも1台多く起動されてしまう）
その問題に対応するためウォームアップ期間を設定して対応する。
その間は次のスケーリングの条件に合致して場合、立ち上げ中のものをカウントしてくれる仕組み。
デフォルト300秒。
ターゲット追跡スケーリング
ひとつのCloud Watchメトリクスに対し目的地を指定する。（CPU使用量を40％に維持し続けるなど）
この設定値を実施することでAutoScalingで自動でリソースが調整するようになる。
予測スケーリング
EC2のみに使用できる。2週間分のCloudWatchメトリクスを分析し、次の2日間のピークの需要予測をしてくれる。
24時間ごとに次の48時間の予測値を作成する。
予測するための基準時刻は毎時0分。そのため、10時に負荷のピークがくる場合に、10時ちょうどだと間に合わないため、その前に実行するように調整ができる。
デフォルトは5分前。
ただしこの機能はAutoScalingGroupを作成してすぐに実行することができない。
最低24時間分のデータが必要になる。
スケジュールスケーリング
一度限り、もしくは定期的なスケジュールを指定可能。ある程度事前にアクセスのピークなどがわかっている場合はスケジュールを事前に実施することでその時間前にスケールしてくれる。
具体的には設定上でMaxキャパシティとMinキャパシティを設定することによってその時点の容量が希望容量でなかった場合にスケールアウト/インする。
ケース１：ある時刻での希望容量にMinキャパシティに超えていない場合、スケールアウトして希望容量に併せる。
ケース2：ある時刻での希望容量がMaxキャパシティを超過している場合、スケールインして希望容量に併せる。
ケース3：ケース１とケース２両方やる。
20191002 AWS Black Belt Online Seminar Amazon EC2 Auto Scaling and AWS Auto Scaling from Amazon Web Services Japan
オートスケールできる機能
20191002 AWS Black Belt Online Seminar Amazon EC2 Auto Scaling and AWS Auto Scaling from Amazon Web Services Japan
EC2がメインだがその以外にも以下についても管理することができる。
CloudWatch×Auto Scalingによる最適化の実現
上記スケーリングプランに記載されているCloudWatchのメトリクスを利用することで、理興コストを抑えたシステム構築が可能。
例えばCPU使用率のメトリクスの閾値を超過したことをトリガーにAuto Scalingを起動し、スケールアウト・インを実施することが可能。
またピークがある程度予測できるのであれば、ピーク時の処理に合わせてリソースを拡張。過ぎたらリソースを縮小する。
業務上、新しいサービス展開した初日等、想定できるのであれば最適化を行うことで最適化することができる。
スケールイン時にどの Auto Scaling インスタンスを削除するかを制御
デフォルトの終了ポリシーでは、Auto Scaling グループの動作は以下のようになります。
1.インスタンスが最も多く、スケールインから保護されていないインスタンスが最低 1 つあるアベイラビリティーゾーンを決定します。
インスタンスが最も多いアベイラビリティーゾーンから選択する保護されていないインスタンスが複数ある場合は、以下の条件に基づいて (示されている順に適用)、終了するインスタンスが選択されます。2.[複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ のみの場合]
残りのインスタンスが、終了するオンデマンドインスタンスまたはスポットインスタンスの配分戦略、現在選択されているインスタンスタイプ、N 個の最低価格のスポットプールへの分散に合うように、終了するインスタンスを決定します。このようなインスタンスが 1 つある場合、そのインスタンスを終了します。それ以外の場合は、次の条件を適用します。3.[起動テンプレートを使用する Auto Scaling グループの場合]
いずれかのインスタンスが最も古い起動テンプレートを使用しているかどうかを判断します。このようなインスタンスが 1 つある場合、そのインスタンスを終了します (例外が 1 つあります。グループがもともと起動設定を使用していた場合です。Amazon EC2 Auto Scaling は、その起動設定を使用するインスタンスを終了してから、最も古い起動テンプレートを使用するインスタンスを終了します)。4.[起動設定を使用する Auto Scaling グループの場合]
いずれかのインスタンスが最も古い起動設定を使用しているかどうかを判断します。このようなインスタンスが 1 つある場合、そのインスタンスを終了します。5.2 から 4 のすべての基準を適用した後で、終了する保護されていないインスタンスが複数ある場合は、どのインスタンスが次の課金時間に最も近いかを判別します。このようなインスタンスが 1 つある場合、そのインスタンスを終了します (次の課金時間に最も近いインスタンスを終了すると、時間単価のインスタンスを最大限に活用できます)。
スケールイン時にどのAuto Scalingインスタンスを終了するかを制御する - Amazon EC2 Auto Scaling (日本語)
基本的にAZで偏らないようにスケールインする。
例えばインスタンス3台を2AZで設定している場合、デフォルト終了ポリシー上で1台終了させると、2台存在するAZからスケールインする。
またスケールインするうちの2台は古いもの。
ターミネーションポリシー
スケールインでインスタンスを削除するときなどどういうルールで実施するかを設定できる。①：OldesrInstance/NewestInstance：最も古いor最新起動時間のインスタンスの終了
②：OldestLaunchConfiguration：最も古い起動設定（AutoScaling側）のインスタンスの終了
③ClosestToNextInstanceHour：次の課金まで一番短いものを削除
④デフォルト：②と③の順に適用。その結果希望容量よりも多ければランダムに1台終了する
よくある質問
スポットインスタンスを使用して安く済ませたい
ミックスインスタンスグループを活用する。速やかにスケールアウト/インしてくれなくて困っている
インスタンスのCloudWatchの詳細モニタリングを有効にして、メトリクスと1分程度にすることで速やかにスケールすることが可能。（ただし有料）正常動作しない（起動に失敗した）インスタンスを自動で置き換えたい
AutoScalingではふたつのヘルスチェックにて確認することが可能。- EC2ヘルスチェック
- ELBヘルスチェック
EC2ヘルスチェック
デフォルトで有効。ELBヘルスチェック
ELBヘルスチェックはELBとEC2の組み合わせをしているときに有効にすることで確認可能になる。デフォルトのEC2ヘルスチェックに加えて、ELBに備わっているEC2へのヘルスチェックに応答しない場合も速やかに入れ替える。
スケールアウト/インを繰り返していつまでたってもインスタンスが追加されない
ヘルスチェックの猶予期間の設定を見直す。起動したばかりでまだELBやAutoScalingのヘルスチェックに対して応答できない場合ある（簡単に言うとOSが立ち上がっているときにマウス操作しても何の応答もないと同じ）
その場合はAutoScaling側で失敗とみなすので、立ち上げ中であることを知らせるためにヘルスチェックの猶予時間を設定する。
デフォルトは5分。
一時的にスケールアウト/インをやめたい
スケーリングプロセスの中断することで一時的に動作を停止することができる。動作のおかしいインスタンスがいるから止めたいという場合は、AutoScalingグループから外す。
AutoScalingから外す方法は主にふたつ
- スタンバイ
- デタッチ
スタンバイ
トラブルシューティングを行うために一時的に外す（生きている扱いとなる）。この場合、ヘルスチェック対象からも外れるため、その間に原因を特定して修正することが可能。
デタッチ
トラブルシューティングを行うために一時的に外す（死んだ扱いとなる）。Elastic Load Blancingについて勉強
AWS 認定ソリューションアーキテクト – アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
- Elastic Load Blancing(ELB)とは
Elastic Load Blancing(ELB)とは
EC2や特定IPアドレスへの通信トラフィックを分散するロードバランシングサービス。
ELBを使用することでスケーラブルで高い可用性持ったシステムを構築できる。
ELBの特徴
- スケーラブル
- 安価な従量課金
- マネージドサービスのため運用管理が楽
- 豊富な連携機能
スケーラブル
ELB自体も負荷に応じてキャパシティを自動増減（スケール）する。NLB以外のALBやCLBがスケールする場合は、IPアドレスが変更されるためDNS名でELBへアクセスることが必要
豊富な連携機能
AutoScalingやRoute53、CloudFormationなどと連携ができるのに加え、ロードバランシング機能に複数のEC2インスタンスやECSコンテナに対してもロードバランシング機能を使用して負荷分散をすることができる。
高可用性
可用性とは
システムが正常に継続して動作し続ける能力を指す。可用性の指数はパーセンテージで表す。いわゆる稼働率。稼働率を高めるにはいかにシステムやサーバを単一ではなく複数で構成する冗長化を行っていくか。障害が発生しても別のサーバなどにフェイルオーバーするかを考えたアーキテクチャを考えるのが一般的。
リソースの冗長化
障害が発生するとシステム全体が使用不能なる単一障害点をなくすための冗長化。2台以上で構成されるEC2をELBで負荷分散することで冗長化する。
RDSをマスタースレーブ構成にする。
地理的に離れた場所で冗長化
リソースの冗長化でインスタンス等分散していても、データセンター規模で障害が発生してしまっては元も子もない。そのため、複数アベイラビリティゾーン構成にすることで、片方のアベイラビリティゾーンでデータセンター規模で障害が起こったとしても可用性を維持することができる。
システムを疎結合で構成する
単一障害点にならないためにそれぞれシステムやコンポーネントを独立させることが重要。ELBとSQSを利用した疎結合構成。
ELBで負荷分散しつつ、SQSでバッファリングして処理を並列化させることで大量データの処理が可能になる。
ELBとSQSはAWS内部で冗長化されているので意識する必要はない。
ELBの種類
種類は大きく分けて3種類存在する。
Classic Load Blancer(CLB)
OSI参照モデルのL4とL7のロードバランサー。プロトコルはHTTPとHTTPS、TCP、SSL。
初期に提供されたELBであり、現在は新規に作成する場合はこちらは推奨されていない。
標準的なロードバランシングを提供。
TCPリクエストをバックエンドインスタンへ振り分け、指定されたポートへ通信トラフィックを転送する。
Application Load Blancer(ALB)
OSI参照モデルのL7のコンテントベースのロードバランサープロトコルとしてはHTTPとHTTPS
CLBでできなかったものができるようになっているELB。
URLパスに応じたルーティングが可能なパスベースルーティングが可能になった。（URLに応じてどこにアクセスするのかを決めることができるようになった）
1インスタンスに対して複数ポートを登録可能になった。
EC2をターゲットグループに割り当てるときに複数ポートを個別のターゲットとして登録することが可能。
これにより複数ポートを利用するコンテナサービス（ECS）をロードバランシング可能になった。
ターゲットグループでのヘルスチェックが可能になる。
任意のセキュリティグループを指定することが可能。
Webにおいて双方向通信を低コストで行うWebSoketはALBのみ対応している。
AWS Lambda関数をターゲットに指定することも可能
Network Load Blancer(NLB)
OSI参照モデルのL4のコンテントベースのロードバランサー
プロトコルとしてはTCP、UDP、TLS。
揮発性ワークロードを処理し、毎秒数百万リクエストに対応できる能力を持つ。
これによりALBなどはPre-warning申請が必要な大規模アクセスに対しても適用することができる。
VPC外のターゲットを含めたIPアドレスや静的IPアドレスでの登録が可能。
フォールトレランス機能を内蔵している。
低レイテンシで高いスループットを実現するときに利用する。
送信元アドレスを保持するため、レスポンスはクライアントへ直接返す。
NLBはセキュリティグループをは関連付けることができないので注意
負荷分散
複数のアベイラビリティゾーンへの分散
配下のEC2（EC2をターゲットグループとしてまとめた）の負荷に応じて、複数のAZにまたがるEC2インスタンスの負荷分散を行うことができる。クロスゾーン負荷分散
ELBは複数のAZに登録されたすべてのインスタンスに対してリクエストを均等に分散することが可能。ALBとCLBはデフォルトで有効だが、NLBはデフォルト無効となっている。
例えば「A」「B」という2種類のAZがあり、それぞれ10台、2台のインスタンスが動作しているとします。
A-AZ:10台のインスタンス
B-AZ:2台のインスタンス「クロスゾーン負荷分散」が無効の場合はA、Bそれぞれ50%ずつ負荷が分散されるため、2台しかないBのインスタンスには負荷がかかります。
一方でAのインスタンスは負荷が低くなります。結果としてもし12台すべて同じスペックの機器の場合効率が悪くなります。「クロスゾーン負荷分散」を有効にすると、ELBがA,B上のインスタンスに関して負荷が「平等に」かかるよう振り分けます。要するに100%÷12=約8% の均等な負荷が12台にかかることになります。
AWS | ELBの「クロスゾーン負荷分散」はどのようなケースで有効化するのか
有効しないと片方のインスタンスに負荷が異常にかかるようになる。
IPアドレスをターゲットに設定する
ALBとNLBのみの機能。オンプレミスのサーバなどのIPアドレスを使用してオンプレミスサーバーに対して負荷分散させることも可能。
スケールするときの注意点
ELBは負荷に応じて自動スケールを行うが、ALB（CLB）は急激なリクエストが発生した場合にスケーリングが間に合わない場合がある。その場合はHTTP503を返却する。
- 新サービス
- TVやメディアによるサービス紹介
- 負荷テスト
回避方法
事前にALB（CLB）をスケールしておくことが必要。
監視
ELBは正常なターゲットのみにトラフィックをルーティングする。設定値にもどつきターゲットに対してヘルスチェックを定期的に行い、正常かどうかを判断する。
モニタリングサービスを使用しての運用
CloudWatch メトリクスAmazon CloudWatch を使用して、ロードバランサーとターゲットのデータポイントに関する統計情報を、メトリクスと呼ばれる時系列データの時間順のセットとして取得できる
アクセスログ
ロードバランサーに対して行われたリクエストの詳細情報をキャプチャし、Amazon S3 でログファイルとして保存できる。
リクエストのトレース
リクエストのトレースを使用して HTTP リクエストを追跡できる
CloudTrail ログ
Elastic Load Balancing API に対して行われた呼び出しに関する詳細情報をキャプチャし、Amazon S3 でログファイルとして保存できる
NLBとの違いはVPCフローログが適応していない点と、HTTPとHTTPSをプロトコルとして利用できるのでHTTPリクエストの追跡がある。
Connection Draining（登録解除の遅延）
スケールインの異常が発生した場合、リクエスト中のEC2インスタンスがELBから解除される場合やヘルスチェックで失敗になった場合に、急に接続を切るとアクセスできなくなる。
そのため、一定期間（5分～60分）は接続を切らず、処理中のリクエストが終わるまで待ってくれる機能。
スティッキーセッション
ALB（CLB）の機能。同じユーザから来たリクrストをすべて同じEC2インスタンスに送信する。
アプリケーション上でセッション情報や一時ファイルを同じEC2インスタンス側で保持したいという場合に使用する。
デフォルトで無効のため、有効にする。
セキュリティ機能
SSL復号の機能を持っている。
SSL復号をELBが担うことで、バックエンドインスタンスの負荷軽減や証明書の一元管理が可能になる。
HTTPS/SSL利用時のTSLサーバ証明書
AWS Certification Manager（ACM）を使用することで証明書のリクエスト、管理、更新、プロビジョニングが可能。
SSL/ TLS ターミネーション
クライアント→ELBまではHTTPSでアクセスするが、
ELB→EC2はHTTPでアクセスるなどの対応が可能
認証
ALBのコンテンツベースのルーティングには、Cognito認証アクションと、OIDC認証アクションの二つが存在する。
Cognito認証アクションは初めてのログインの場合に、Amazon Cognitoでの認証画面にリダイレクトされる。
OIDC認証アクションはAmazonやFacebookやGoogleなどのプロバイダーの認証を使用することができる。
AWS WAFとの連携
AWS WAFを使用することで以下が可能- リクエストレートによるアクセス権限
- 特定のIPアドレスや地域からのアクセスを制限
- クロスサイトスクリプティングやSQLインジェクションからの保護
- HTTPヘッダ、HTTP本文、URI文字列に対するサイズ制限や正規表現でのマッチング
Global Accelerratorとの連携
Global Accelerratorを使用することで、複数あるリージョンからより近いリージョンにアクセスすることが可能。
外部ELBと内部ELB
インターネット向けの外部ELBであるInterner-facingか、内部ELBとして利用するInternalのいずれかで動作する。外部ELBはパブリックサブネットに配置されている。バックエンドインスタンス（EC2)をパブリックサブネットに配置する必要なく、プライベートサブネット上に配置することができる。
内部ELBはプライベートサブネットのみ利用することができる。
両方ともプライベート上に配置してもOKだが、内部ELBはプライベートのみ。
