awsにおけるパフォーマンス
AWSにおけるパフォーマンスの考え方
費用対効果の優れたシステムの構築
AWSにおけるパフォーマンス効率の設計原則
-
最新技術の導入
- クラウドベンダーにおまかせ
- スキル不足で諦めない
-
グローバルな環境
- 世界中のリージョンにシステム構築可能
-
サーバーレスアーキテクチャの使用
- 静的コンテンツの配信はストレージサービスだけで可能
-
比較テストの実施
- 異なるタイプのインスタンスやストレージ等への変更容易
- パフォーマンスの比較容易
-
適切な技術の利用
- 要件に合った最適な技術を使用する
ネットワークサービスにおけるパフォーマンス
ネットワークにおけるパフォーマンスの考え方
-
ユーザーとサービス動作場所とが地理的に離れていると大きなレイテンシーが発生
- グローバルな環境ゆえの問題
CloudFront
-
接続ポイントは2つ
- キャッシュが2段になってる感じ
- システム構成図を書くときは省略されること多し
接続ポイント | 説明 |
---|---|
エッジロケーション | |
リージョン別エッジキャッシュ | エッジロケーションよりも大容量のデータをキャッシュ可能 |
-
CloudFrontのユースケース
-
静的コンテンツ
CloudFront -> S3
-
動的コンテンツ
CloudFront -> ELB -> EC2
-
Route 53
-
レイテンシーベースルーティング
- 地理的に一番近くなくても、レイテンシーが最小となるリージョンからリクエスト処理
プレイスメントグループ
- クラスターコンピューティング等で使うやつ
-
AZ内のEC2インスタンスを論理的にグルーピングする
- 異なるAZでは不可
- 異なるリージョンでも当然不可
-
可用性重視構成
- 異なるAZにEC2配置、高速通信
-
パフォーマンス重視構成
- 同一のAZにEC2配置、プレイスメントグループ化してさらなる高速通信
コンピューティングサーピスにおけるパフォーマンス
適切なインスタンスタイプを選ぶ
EBS最適化インスタンス
-
EBS使用時のパフォーマンスに影響を及ぼす因子
- EBSストレージタイプ
- EC2インスタンスタイプ
- EC2インスタンス — EBSストレージ間通信
-
EBS最適化
- EC2インスタンス作成時の設定項目
-
有効化すると、EC2-EBS間通信専用帯域を確保
- 他の通信トラフィックの影響を受けず、安定したパフォーマンスを実現
Auto Scalingによる最適化の実現
-
従来: サーバーは固定台数で運用したいもの
- 毎日は使わないのに起動しっぱなし
- 月末にしか負荷が集中しないのにピーク時でも余裕のあるリソースで常時稼働
-
クラウド: オンデマンド
- 従量課金
-
オンデマンドでリソース利用するためには
-
CloudWatch
- しきい値を超えたらアラート
-
Auto Scaling
- アラートをトリガーにスケールアウト・スケールイン
-
Lambdaのレイテンシー対策
-
レイテンシ
-
コンテナ初回起動
- Lambdaはコンテナ上で動作
- 一定時間停止後の初回起動時は、コンテナ起動時間ぶんレイテンシーがある
-
VPCエンドポイントでENI: Elastic Network Interfaceの確立
- VPC内にLambda置くと発生
- VPC外に置けばおこらない
-
-
ホットスタンバイで回避可能
- SQS等利用して
ストレージサービスにおけるパフォーマンス
S3
- S3の原理に基づいてパフォーマンスチューニング
-
S3はオブジェクトストレージ
- オブジェクトを格納すると、オブジェクトキー名のインデックスが管理される
- オブジェクトキーはインデックス内の複数のパーティションに格納される
- 格納先はキー名依存
-
ファイル名の先頭文字列が同じファイルが大量に存在すると、同じパーティションへのI/Oが集中してしまう
- キーにランダムなプレフィックスを付与して回避可能
EBS
-
紛らわしいやつ
-
スループット: 時間あたり容量
- 巨大ファイル扱うならこれが高いと有利
-
IOPS: 時間あたりI/O回数
- 4KB以下の小さなファイルを大量に扱うならこれが高いと有利
-
- 総じてHDDのほうがSSDよりも低コスト
- おのおの、IOPSが低いほうが低コスト
-
ボリュームタイプ5種類
- PIOPS: Provisioned IPOS
汎用SSD | PIOPS SSD | スループット最適化HDD | コールドHDD | マグネティック | |
---|---|---|---|---|---|
記号 | gp2 | io1 | st1 | sc1 | |
分類 | SSD | SSD | HDD | HDD | HDD |
サイズ | 1~16TB | 4~16TB | 500GB~16TB | 500GB~16TB | 1~1TB |
IOPS | 100~10,000 | ~64,000 | ~500 | ~250 | avg 100 |
最大スループット (MiB/s) |
160 | 500 | 500 | 250 | 40-90 |
ユースケース | DBとか | ビッグデータ、 DWH、ログ処理 |
低頻度アクセス | 低頻度アクセス (旧世代) |
-
RAID
-
標準的なものすべて利用可能
- 0,1,5,6等
- OSがRAID設定をサポートしていること
-
RAID 0
- ストライピング
- ディスク分散、I/O向上
- AWSではEBSがAZ内で冗長化されているため、耐障害性も両立できる
-
RAID 1
- EBSがもともと一般的な市販ディスクドライブの20倍の信頼性
- さらにミラーリングするとオンプレよりも信頼性高くなる
-
RAID 5, 6
- パリティデータ書き込みでIOPS浪費するためAWSでは非推奨
-
データベースサービスにおけるパフォーマンス
- ユースケースに応じて適切なサービス選べ
RDS
-
パフォーマンスチューニング
-
スペック
- インスタンス
- ストレージ
- 間の通信経路
- リードレプリカ機能
- いずれも既出
-
-
ユースケース
- 企業の基幹システム
DynamoDB
-
特徴
- NoSQL
- 高い信頼性
- パフォーマンス維持
-
ユースケース
- モバイルゲーム
- アドテクノロジー
- IoTでのセンサーデータのデータベース
-
クライアントからの利用
-
API
- AWS SDK
- AWS CLI
-
-
DAX: DynamoDB Accelerator
- DynamoDB: 数ミリ秒のレイテンシ
- DAX併用すると、1,000,000回/s単位のリクエストを数ミリ秒でさばける
EC2 --> DAX --> DynamoDB
Redshift
- PB単位のデータを標準SQLで分析可能
-
特徴
-
列指向
-
行指向の問題
- レコードが増えるとレスポンス遅くなる
- ビッグデータの集計・分析で使えない
- これを解決
- ある列に格納された値をすべて集計する、といった処理に強い
-
-
-
ユースケース
- 大量データの保持(PB単位)
- DWH
- BIツール
ElastiCache
-
特徴
- NoSQL
-
インメモリデータベース
- Memcached
- Redis
-
ユースケース
-
RDBの前段に置いてパフォーマンス向上
- クエリ結果をキャッシュ
- セッション情報の保持
-
Memcached vs Redis
Memcached | Redis | |
---|---|---|
データ構造の複雑性 | シンプル(文字列、オブジェクト等) | 複雑(hash, list等) |
レプリケーション | なし | あり |
フェイルオーバー | なし | あり |
永続性 | なし。 DB別途必要 |
あり。 データストアとしても利用可能 |
その他もろもろ