AWS Innovate Online Conference 「試験対策セッション2：パフォーマンスに優れたアーキテクチャを定義する」をまとめてみた

参考文献

AWS Innovate Online Conference
AWS 認定 - 試験対策 「ソリューションアーキテクト - アソシエイト」
セッション2：パフォーマンスに優れたアーキテクチャを定義する

を視聴して、まとめた内容を記載しています。

2.1 高パフォーマンスなストレージおよびデータベースを選択する

Amazon EBSのボリュームタイプ

• SSDタイプ
  • 汎用SSD
    • 低コストで高いIOPS
  • プロビジョンドIOPS SSD
    • IOPSとスループットが高い、高コスト
• HDDタイプ
  • スループット最適化HDD
  • コールドHDD
• マグネティック（旧世代のボリュームで非推奨）

一般的にワークロードに合うものを選択する
パフォーマンスとコストを読み解くことが重要

Amazon S3 バケット

インターネットからアクセス可能なストレージ。
静的なコンテンツ配信が可能。

静的なコンテンツを配信する場合は、通常はWebサーバを起動してエンドユーザーからリクエストを受け付ける必要があった。
利用者が増えるとサーバー台数が増えて、パフォーマンスの低下やコスト増加のリスク。
S3は完全マネージド型サービス。Webシステムのパフォーマンス向上につながる。

S3を利用するには、バケットを作成する。
バケットを作成する際には、バケット名を付与してリージョンを指定して作成。
バケット名は、基本的にファイルセットのプレフィックスであり、グローバル全体で一意の名前をつける必要がある。

1つのアカウントに複数のバケットを配置できる。
バケットごとにアクセス制御も可能。→バケットのオブジェクトを作成できるユーザーのアクセスコントロールもできる。
S3では、ファイルをオブジェクトと予備、バケットを作成するとバケット内でオブジェクトをいくつも保存できる。

オブジェクトを保存するには、保存するファイルをバケットにアップロードする。
アップロード時に、データへのアクセス許可やメタデータを設定できる。

料金は、

• 保存しているデータサイズ
• リクエスト回数
• リージョン外へのデータ転送量

で発生。
リージョンによっても料金は異なる。
データ転送でも、リージョン内やAmazon Cloud Frontへの送信では料金が発生しない。

いくつかのストレージクラスが提供されている。
ストレージクラスは手動で管理するより、ライフサイクルポリシーの機能を使ったほうがいい。
経過時間に伴い、ストレージタイプを変更できる。
例）
30日経過して、あまりアクセスしなくなったS3標準低頻度アクセスに移動。
60日経過して、さらにアクセスしなくなったらGlacierに移動。
1年経過したら、データを自動的に削除。

データベース

試験によくデータベース

• RDS
• Dynamo DB

- RedShift

AWSには、様々なデータベースの選択肢が提供されている。
設計上ベスト・プラクティスは存在しない。
要件に応じて最適なデータベースを選択することが重要。

RDS

最適な使用例

• 複雑なトランザクションや複雑なクエリ。
• 中～高速のクエリ／書き込みレートが必要な場合。
• 単一ノードで管理する必要がある場合。
• 高耐久性

使用すべきではない例

• 毎秒150,000の書き込み／秒くらいの超高速高速な読み取り、書き込み。
• RDSの単一ノードでは処理しきれないシャーディングする必要がある。
• 簡単なGET/PUTのみのリクエストで足りる場合。

- EC2でRDBMSを細かくカスタマイズしたい場合。

使用すべきではない環境では、Dynamo DBやNo SQLを使用するか、EC2でリレーショナル・データベースエンジンを実行することを検討する。

RDSの性能向上のために、インスタンスタイプをより大きいサイズに変更する。
最大サイズまでスケールアップしても性能が足りない場合は、リードレプリカを使用する。
リードレプリカによって、DBインスタンスのキャパシティに制約されることなく、伸縮自在にスケールアウトすることできる。
よって、読込量が多いデータベースワークロードに対応できる。

DBインスタンスに対して1つ以上のリードレプリカを作成。
アプリケーションの大量の読込トラフィックを処理できるため、全体の読込スループットが向上する。
必要に応じて、スタンドアロンのDBインスタンスに昇格させることが可能。

リードレプリカが使用できるサービス

• Amazon RDS for MySQL
• Amazon RDS for MariaDB
• Amazon RDS for PostgreSQL
• Amazon RDS for Aurora

DynamoDB

完全マネージド型NoSQLデータベース。
一定の低レイテンシーのパフォーマンスを維持しながら水平方向にスケールすることができる。
設計上はいくらでもスケール可能。（小さくても大きくても）
スケーラビリティは、キャパシティユニットの数値を指定することで増加／減少することが可能。
キャパシティユニットは読込書き込みそれぞれ指定することが可能。

2.2 パフォーマンス向上のためキャッシュを使用する

Amazon CloudFront

低レイテンシーかつ高速な転送速度でデータ、動画、アプリケーション、APIなどを閲覧者に安全に配信するグローバルなコンテンツ配信ネットワーク（CDN）
エッジロケーション上で動作。

シームレスに連携できるサービス

• DDoS攻撃を緩和するAWS Shield
• S3
• ELB
• EC2
• Lambda

Amazon ElastiCashe

MemcachedやRedisといったオープンソースのキャッシュエンジンをマネージド型サービスとして利用できる。
そのため、インメモリキャッシュ環境の管理、モニタリング、オペレーションが簡単。
そのぶん、アプリケーションの実装に専念できる。

システム内部でキャッシュを利用したい場合に使用する。
（CloudFrontは、Webシステムにおけるフロント部分でのキャッシュ。）

Memcached

• マルチスレッド
  • 多くのCPUコアを使用できる
• メンテンスが簡単
  • シンプルに設計されているため
• 水平スケーリングが簡単
• フラットなHTMLページ、シリアライズされたJSONなどの文字列をキャッシュするように設計されている
• 永続性はない
  • 空のノードを作成し、そのノードを終了、またはスケールダウンするとノードのキャッシュメモリに保存されていたデータは失われる
  • スケールダウンすると、ノードのキャッシュメモリに保存されていたデータは失われる

Redis

• 単一スレッド
• 高度なデータタイプを使用する必要がある場合
• 複数のデータ構造をサポート
• 永続性
  • プライマリデータストアとして使用できる

Memcachedは、Redisの高度な機能を必要としない場合に使用する。
Redisは、データの永続性、高度なデータタイプなどが必要な場合に使用する。

2.3 伸縮性とスケーラビリティに優れたソリューションを設計する

垂直スケーリングと水平スケーリングの比較

垂直スケーリング

• スケールアップ／スケールダウン
• インスタンスのスペックの変更
  • CPUやメモリの追加 水平スケーリング
• スケールイン／スケールアウト
• インスタンス数の変更
  • 必要に応じて追加及び削除

垂直スケーリングには最終的な限度がある。
Javaアプリの場合、大容量のJavaヒープメモリを使用すると、ガベージコレクションの稼働時間が長くなり、中断時間が長くなってしまう。

垂直スケーリングで再起動が求められる可能性。
水平スケーリングには限度がなく、ワークロードの増加に対応できる。

Auto Scaling

CloudWatchのメトリクスと連携したスケーリングポリシーを指定すると、アプリケーションの需要の条件に応じて変化するCPU使用率などのメトリクスに応じてAuto Scallingによりインスタンスが作成／終了される。
1つのAZが利用不可になった場合、影響を受けていないAZにAuto Scalingで新しいインスタンスを作成する。
異常だったAZが正常に戻ったら、Auto Scallingによりアプリケーションインスタンスは、Auto ScalingグループのすべてのAZ全体に均等に自動で再分散される。

AutoScalingでは、CloudWatchのアラームと連携するAuto Scalingポリシーを指定できる
CPU使用率が増えたときはインスタンスを増やしたり、低い場合にインスタンスを削除するといったAuto Scalingグループ内に起動する。
Auto Scalingグループでは、複数のAZに関連付けることができる各AZで均等になるようにEC2インスタンスが起動される。
Auto ScalingグループはELBと関連付けることができる。EC2を自動的にELBに登録されて自動的に負荷分散の対象になる。