No.
2023-08-26
  • Jan
  • Feb
  • Mar
  • Apr
  • May
  • Jun
  • Jul
  • Aug
  • Sep
  • Oct
  • Nov
  • Dec
  • Sun
  • Mon
  • Tue
  • Wed
  • Thu
  • Fri
  • Sat
  • 27
  • 28
  • 29
  • 30
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

パフォーマンス効率

早引き

  • S3はSNSを介せず、直接Lambda関数を呼び出すことができる
  • JSONのデータをそのままテーブルのアイテムとして保存 -> DynamoDB(KVS型のDBなので親和性が高い)
  • SQSキューを使用しなくてもLambdaには自動スケーリング機能があるので、相当の負荷にも耐えられるようになっている（1秒間に同時に実行できる関数の数はデフォルトで1000）
    • 処理にタイムアウトが発生するなどでなければ、SQSを使用せずにS3イベント通知からLambda関数を実行する方がシンプルで効果的な構成
  • 実はEC2インスタンスストアが最もI/O性能が高い
  • DBのパフォーマンス向上：
    • ディスクパフォーマンス低下(容量がいっぱいの時) -> Auto Scalingなどで容量を増やす
    • メモリパフォーマンス低下(クエリ発行数が多い時) -> クエリの結果をキャッシュする
  • BI(Business Intelligence)：ビッグデータを分析し経営に役立てること
    • BIツール：Amazon EMR、Amazon Redshift
  • IoT、リアルタイム -> Amazon Kinesis
  • リアルタイムな分析に使うDB -> DynamoDB(応答性が高いため)
  • ビッグデータなど大容量のデータ分析に使うDB -> Redshift
  • プロビジョニング：予測して
  • オンデマンド:要求に応じて
  • DynamoDBにキャッシュレイヤーを追加したい場合は、　DynamoDB Accelrator(DAX)を追加することで実現できる
  • リードレプリカからスナップショットを作成することはできない
  • セカンダリーDBインスタンスはフェイルオーバー時の待機用として使うので、リードレプリカのように読み込み専用として使うことはできない
  • ゴールデンイメージ：最新状態のAMI
  • ALBはレイヤー7、TLSリスナーに基づいたヘルスチェックを実施することはできない
  • マウントターゲット：EFS
  • Route53において、Blue/Greenデプロイメントに利用できるのは加重ルーティング

AWS Auto Scaling

  • AWSリソースを負荷状況や設定したスケジュールに従って、自動的にスケーリングする機能
  • Auto ScalingはELBと組み合わせて利用することが多い
  • ELBのターゲットグループ配下のリソースに障害が発生した時や負荷が増大した時に、Auto Scalingが自動的に新規のリソースを立ち上げてELBのターゲットグループに追加
  • 逆に負荷が低くなっている時は、ターゲットグループ内のリソースを減らす

AutoScalingグループ

  • Auto Scalingグループは自動スケーリング対象の管理単位
  • グループ内でのリソースの最小数および最大数や、スケールアウト/インの実行条件などを指定
項目 説明
希望する容量 Auto Scalingグループで稼働するリソースの数
最小キャパシティ Auto Scalingグループで稼働するリソースの最小数
最大キャパシティ Auto Scalingグループで稼働するリソースの最大数
ターゲットグループ Auto Scalingグループに細づけるELBのターゲットグループ
ヘルスチェックのタイプ ELBのヘルスチェックと、EC2のステータスチェックが利用できる
ヘルスチェックの猶予期間 インスタンスが起動してから初回のヘルスチェックまでの待機時間
インスタンスの保護 スケールインが発生した時に削除対象から除外する
終了ポリシー スケールインが発生した時に、リソースを削除する優先順位

スケーリングポリシー

  • ターゲット追跡ポリシー：
    • CloudWatchメトリクスを判断材料にしてスケーリングする
    • 単一の段階を設定する場合に使う
    • 例)CPU使用率が50%を超えたらインスタンスを増やす
  • ステップスケーリングポリシー：
    • CloudWatchAlermを判断材料にしてスケーリングする
    • 複数の段階を設定する場合に使う
    • 例)CPU使用率が50%を超えた時にインスタンスを2つ、70%超えた時に3つに増やす
  • スケジュールドスケーリングポリシー：
    • 前もって日付などを指定してインスタンスの数などをスケーリングする
    • 例)イベントに合わせてインスタンス数を増やす

ヘルスチェック

  • リソースがEC2インスタンスの場合、Auto Scalingのヘルスチェックのタイプには「EC2」と「ELB」がある
    • 「EC2」はインスタンスのステータスチェックの結果を確認し、「ELB」は指定した接続先への応答確認をする
    • Auto Scalingのヘルスチェックで異常となったリソースは、自動的に終了される
    • デフォルトでは「EC2」が有効、「ELB」は無効になっている
    • 「EC2」「ELB」ともに有効にすることが推奨されている
  • リソースが起動してから初回のヘルスチェックまでの待機時間として「ヘルスチェックの猶予期間」を設定できる
  • ヘルスチェックの猶予期間を設定することにより、リソースが起動してアプリケーションなどが立ち上がる前にヘルスチェックが実行されてしまい、ヘルスチェックが異常になってしまうのを防ぐ

プレイスメントグループ

  • 単一AZ内におけるインスタンスの配置戦略のこと
  • クラスター
  • 分散
  • パーティション

S3

  • オブジェクト名に日付ベースの順次命名を適用することでアクセス時のパフォーマンスを改善することができる

S3イベント通知

  • S3バケットに発生したイベント（オブジェクトの作成や削除など）をトリガーに通知を行う機能
  • 通知先：Lambda関数、SQSキュー、SNSトピック

ストレージクラス

ストレージクラス 説明
S3 Standard(S3 標準） デフォルトで選択されるストレージクラスです。
保存したデータに無料・低遅延でアクセスができるので、アクセス頻度が高いデータに適しています。
S3 Standard-Infrequent Access(S3 標準 - 低頻度アクセス） 保存料金がS3 Standardより低価格ですが、データ取り出し料金がかかります。
アクセス頻度は低くても、アクセス時には低遅延が求められるデータに適しています。
S3 One Zone-Infrequent Access(S3 1ゾーン - 低頻度アクセス） 保存料金がS3 Standard-IAより低価格ですが、保存したデータは1ヵ所のAZに保存されます。
AZ障害が発生した場合、保存したデータへのアクセス不能やデータ消失の可能性があるため、リスクよりも低コストであることが優先されるデータに推奨されます。
S3 Intelligent-Tiering 実際の利用状況に応じて「高頻度アクセス用ストレージ」か「低頻度アクセス用ストレージ」ヘデータを自動的に移します。
取り出し料金はかかりませんが、黙視とデータ移動の自動化に対する月額利用料がかかります。
アクセス頻度が変動するなど予測が難しいデータに適しています。
S3 Glacier 大量のデータを低価格で保存できるアーカイブデータ向けストレージです。
データ取り出し時に数分～数時間の遅延と取り出し料金がかかります。
アクセス頻度が低く、取り出し時に遅延が発生しても問題ないデータに適しています。
S3 Glacier Deep Archive S3ストレージクラスの中で最もデータ保存料金が低価格のアーカイプデータ向けストレージです。
データの取り出しにS3 Glacierより長い運延と高い取り出し料金がかかります。
アクセスがほとんどないデータを長期にわたって保存する場合に適しています。

ストレージサービス

Amazon EFS

  • NFS（Network File System）プロトコルをサポートするファイルストレージサービス
  • EFSはNFSに対応したAWSサービスおよびオンプレミス（自社運用）のシステムから利用可能
  • 複数のEC2インスタンスでストレージを共用したい時にも使える

Amazon EBS

  • EBS（Elastic Block Store）はEC2インスタンスに割り当てられるブロックストレージで、物理ハードディスクドライブと同じように利用できる
  • EBSは必要に応じて複数作成し、EC2インスタンスにアタッチ（取り付け）して利用する
  • EC2とEBSは1対１の関係。共用はできない。

EC2インスタンスストア

  • インスタンスストアは、EC2インスタンスから利用できる揮発性の（インスタンス稼働中にだけ利用可能な）ブロックストレージ
  • インスタンスストアは、EBSよりも高いパフォーマンスを発揮できるという特徴がある
    • EBS：最も高性能なボリュームタイプでも64,000IOPS
    • インスタンスストア：数百万IOPS
    • IOPS（Input Output per Second）… 1秒間にどれだけI/O（Input/Output:読み取り/書き込み）が行えるかを意味する性能指標のこと。

Amazon S3

  • Amazon S3（Simple Storage Service）は安価で耐久性が高く、保存容量が無制限のオブジェクトストレージサービス
  • S3に保存されたオブジェクトにはURLが付与され、インターネットからアクセスできる

DynamoDB

  • Key-Value型のデータ形式をサポートするNoSQLのデータベース
  • Amazon DynamoDBでは、テーブルに対する書き込み・読み込みの量と利用料金が関係している
    • オンデマンドモード … 書き込み・読み込みのリクエスト単位で利用料金がかかる
    • プロビジョニングモード … 1秒間に行う書き込み・読み込みの量で利用料金が異なる
    • リクエスト量が予測できる場合は、プロビジョニングモードに設定するとコストを抑えることができる

プロビジョニングモード

  • プロビジョニングモードにおける書き込み・読み込みは、「キャパシティユニット」という単位で管理されている
  • 1秒間にどれだけ読み込み・書き込みを行うかを予約する設定で、容量が大きいほど料金がかかる
    • WCU(書き込み時):最大1KBのデータを1秒間に1回書き込み
    • RCU(読み込み時)：最大4KBのデータを1秒間に1回読み込み(強い整合性を持たない読み込みは2回)
    • デフォルトではWCU・RCUが5に設定されている
    • 変更はいつでも可能、負荷に応じて自動でスケールもできる

Amazon OpenSearch Service（旧Amazon Elasticsearch Service）

  • フルマネージド型の検索・分析エンジンサービスであり、テキストの全文検索やログ分析などの用途に利用
  • OpenSearch Serviceは内部の分散ストレージを活用することで、大量のデータに対して高速な検索や分析を実現
  • 高度な検索機能を提供しており、テキストデータのような非構造化データに対しても高速なキーワードおよびフレーズ検索ができる

Amazon Athena

  • S3上のデータに対して標準SQLを実行できるデータ分析サービス

Amazon EMR

  • HadoopやSparkを用いてビッグデータの分析や処理を行う

AWS Glue

  • データソース（S3やDynamoDBなど）からデータを抽出し、変換・統合したデータをターゲットのデータベース（S3やRDSなど）へ格納するといった、データ分析における橋渡しの役割をするサービス