D.Horiyama's output

AWS Solution Architect Associate 試験対策 ch3

AWS勉強メモ

出典: 

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

AWS資料

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

その他もろもろ