勉強日記

チラ裏

AWS Solution Architect Associate 試験対策 ch3

AWS 勉強メモ

book.impress.co.jp

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間通信専用帯域を確保
      • 他の通信トラフィックの影響を受けず、安定したパフォーマンスを実現

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でのセンサーデータのデータベース
  • クライアントからの利用
  • DAX: DynamoDB Accelerator
    • DynamoDB: 数ミリ秒のレイテンシ
    • DAX併用すると、1,000,000回/s単位のリクエストを数ミリ秒でさばける
    • EC2 --> DAX --> DynamoDB

Redshift

  • PB単位のデータを標準SQLで分析可能
  • 特徴
    • 列指向
      • 行指向の問題
        • レコードが増えるとレスポンス遅くなる
        • ビッグデータの集計・分析で使えない
      • これを解決
      • ある列に格納された値をすべて集計する、といった処理に強い
  • ユースケース
    • 大量データの保持(PB単位)
    • DWH
    • BIツール

ElastiCache

  • 特徴
    • NoSQL
    • インメモリデータベース
  • ユースケース
    • RDBの前段に置いてパフォーマンス向上
      • クエリ結果をキャッシュ
    • セッション情報の保持

Memcached vs Redis

AWS資料

Memcached Redis
データ構造の複雑性 シンプル(文字列、オブジェクト等) 複雑(hash, list等)
レプリケーション なし あり
フェイルオーバー なし あり
永続性 なし。
DB別途必要 		あり。
データストアとしても利用可能

その他もろもろ