【AWS認定(SAP-C02)ノート】パフォーマンス
はじめに
本記事は、AWS Certified Solutions Architect - Professional の下記の分野とタスクステートメントに関連するAWSサービスの特徴やポイントのまとめです
- 第 2 分野: 新しいソリューションのための設計
- タスクステートメント 5: パフォーマンス目標を満たすソリューションを設計する。
- 第 3 分野: 既存のソリューションの継続的な改善
- タスクステートメント 3: パフォーマンスを改善するための戦略を決定する。
対象知識
- AWS のストレージオプション
- インスタンスファミリーとユースケース
- 目的別データベース
- 高パフォーマンスのシステムアーキテクチャ (オートスケーリング、インスタンスフリート、プレイスメントグループなど)
• グローバルサービス (AWS Global Accelerator、Amazon CloudFront、エッジコンピューティングサービスなど)
EC2
ストレージ
Amazon FSx for Lustre
- Lustreを簡単に効率よく起動できる
- SSD、HDDからストレージを選択できる
- S3と統合されているので、S3のオブジェクトをインポートすることも、S3にエクスポートすることもできる
Amazon S3
マルチパートアップロード
オブジェクトを複数のパートに分けて並列アップロードして、完了すれば元のオブジェクトになる
-
プロセス
- マルチパートアップロードの開始:
CreateMultipartUpload
アクションを実行して、UploadId
(アップロードID、マルチパートアップロードの一意の識別子) が返される - パートのアップロード:
UploadId
に加えて、パート番号を指定して、UploadPart
アクションを実行する - マルチパートアップロードの完了:
CompleteMultipartUpload
アクションを実行して、パート番号に基づいて昇順に連結されたオブジェクトが Amazon S3 によって作成される
- マルチパートアップロードの開始:
-
不完全なマルチパートアップロードを削除するためのバケットライフサイクル設定
- 完了せず不完全な状態で残ってしまったパートもストレージ料金の対象になる
- ストレージコストを最小限に抑えるため、
AbortIncompleteMultipartUpload
アクションを使用してライフサイクルルールを設定することをお勧めする
この例のルールでは、
Prefix
エレメントの値を指定してないので、これはマルチパートアップロードを開始したバケット内のすべてのオブジェクトに適用される。開始されてから7日
以内に完了しなかったマルチパートアップロード、中止オペレーションのターゲットとなる。<LifecycleConfiguration> <Rule> <ID>sample-rule</ID> <Prefix></Prefix> <Status>Enabled</Status> <AbortIncompleteMultipartUpload> <DaysAfterInitiation>7</DaysAfterInitiation> </AbortIncompleteMultipartUpload> </Rule> </LifecycleConfiguration>
S3 Transfer Acceleration
- クライアントと S3 バケットの間で、長距離にわたるファイル転送を高速、簡単、安全に行える
- Amazon CloudFrontの世界中に分散したエッジロケーションを経由してアップロードを実行できる
Amazon DynamoDB
サフィックス
を使用したシャーディング
ランダムなパーティションキースペース全体に均等にロードを分散するための方法として、パーティションキーバリューの最後に乱数 (サフィックス
) を追加する
例えば、今日の日付を表すパーティションキーの場合は、1 と 200 の間の乱数を選択し、それをサフィックスとして日付に連結する
パーティションキーをランダム化しているため、毎日のテーブルへの書き込みは複数のパーティション間で均等に分散される
これにより、並列性が強化され、全体的なスループットが向上する
サフィックス
を使用したシャーディング
計算されたランダム化の方法は、項目を書き込むときに使用されたサフィックスの値がわからないため、特定の項目を読み込むのは困難なので、パーティション間で項目を分散させるには、乱数を使用せずに、クエリする項目に基づいて計算できる数値を使用
Amazon CloudFront
AWS Global Accelerator
パブリックアプリケーションの可用性、パフォーマンス、およびセキュリティの向上に役立つネットワークサービス
AWSリージョンへのネットワーク経路を最適化
- エラスティックIPなどのアプリケーションエンドポイントへの固定エントリポイントとして機能する2つのグローバル静的パブリックIPを提供され、BYOIPとしてIPアドレスを持ち込む
- 作成したアクセラレーターには、複数のエンドポイントを設定できる
- Application Load Balancer
- Network Load Balancer
- EC2インスタンス
- Elastic IPアドレス
トラフィックダイアル
- エンドポイントに重み付けできる
- デフォリト:100
- 各リージョン内に複数エンドポイントがある場合、そのエンドポイントごとにWeight設定で重み付けができる
アクセラレーターにアクセス
- 正常
- 最も近いエッジロケーションでリクエストが受け付けられる
- ヘルスチェックに合格したエンドポイントのうち、近い場所や重み付けした設定によってルーティングされる
- 異常 (ヘルスチェックに失敗)
- 即座に他のエンドポイントにルーティングされる
- IPアドレスは変わらないため、キャッシュなどに影響を受けない
リスナー設定
- ポート番号範囲とTCP/UDPを設定
- クライアントアフィニティ有効化:同じ送信先IPアドレスからは同じエンドポイントに継続的にリクエストを送信
Amazon ElastiCache
マネージドなインメモリのデータストアとしてMemcached、Redisを提供
MemcachedとRedis
Memcached | Redis | |
---|---|---|
水平スケーリング | ○ | |
マルチスレッドアーキテクチャ | ○ | |
永続性 | ○ | |
スナップショット | ○ | |
レプリケーション | ○ | |
トランザクション | ○ | |
Pub/Sub | ○ | |
構造化データ | ○(ソート済みセット型、ハッシュ型など) | |
アトミックオペレーション | ○(キャッシュ内のデータ値をINCR/DECRコマンドで増減可能) |
- Memcached
- 自動検出機能:ノードの追加、削除が行われ、自動的に再設定される
- フラットな文字列をキャッシュするように設計されている
- Redis
- プライマリデータストアとして使用可能
- チャットやメッセージングサービスに使用
Amazon RDS
リードレプリカ
- 読み取り専用のリードレプリカを最大5~15まで作成
- それぞれのリードレプリカには個別のエンドポイントが生成される
- 非同期にレプリケーションされる別のインスタンスなので、インスタンスクラスを個別に設定できる
読み取り可能なスタンバイを備えたマルチAZ
- 2つの読み取り可能なスタンバイを備えたマルチAZがMySQL、PostgreSQLでリリース (2022年3月)
- 追加
- 35秒以内のフェイルオーバー
- これまでのマルチAZの書き込み同期レイテンシーの2倍の高速化
- スタンバイへの読み取り許可
- インスタンスクラスが限定
Amazon Aurora
- ボリューム:3つのAZに6つのレプリケーションを持つ
- ライターインスタンス
- リクエストを受けるインスタンス
- 書き込み可能
- プライマリデータベースとして利用
- リードレプリカインスタンス
- 最大15
- 読み取り可能
- ライターの障害発生時:リードレプリカが自動でライターに昇格し復旧
サーバーレス (Serverless V2)
- インスタンスクラスを指定する必要はなく、ACU(Aurora Capacity Unit) の最小値、最大値を決める
- 0.5ACUで1GiBのメモリ性能を提供
- リクエストと負荷の状況により自動で増減
Amazon API Gateway
API Gateway キャッシュ
APIステージで、GETリクエストに対してキャッシュを有効
- 容量に応じて時間単位での追加料金が発生
- キャッシュ容量変更:インスタンスの再作成になるので、その時点までのキャッシュは削除される
APIエンドポイント
エッジ最適化APIエンドポイント
エッジロケーションPOPを経由してルーティングされるので、全世界のユーザーが使用するようなAPIに最適
リージョンAPIエンドポイント
使用するユーザーが特定地域に集中している場合
プライベートAPIエンドポイント
VPCのみから使用するAPI
使用量プラン
- 顧客へ配布するAPIキーごとに1秒、1日、1週間、1ヶ月のAPI利用量を設定
- 特定の顧客のキーによって発生した異常な数のAPIリクエストが全体へ影響しないように調整できる
APIの認証
IAM認証
IAMポリシーで許可されたIAMユーザーのみにAPIの実行が許可される
- 実行を許可するIAMユーザーのアクセスキーID、シークレットアクセスキーを発行
- 署名バージョン4で署名を作成して、リクエストに含む
例)実行を許可するユーザーのIAMポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:region:account-id:api-id/",
}
]
}
他アカウントのIAMユーザーに許可する場合:API Gatewayのリソースベースポリシーに他アカウントからの実行を許可するポリシーを定義
Cognitoオーソライザー
- CognitoユーザープールでサインインしてJWT(JSON Web Token)を取得
- 取得したJWTをAuthorizationヘッダーに含めて、API Gatewayにリクエストを実行 (Cognitoユーザープールで認証済みのJWTがなければ、APIを実行できない)
Lambdaオーソライザー
カスタム認証やサードパーティ製品の認証を検証できる
Discussion