Zenn
Closed18

AWS認定試験の勉強する。SAA-03

AWS
AWS 認定試験
YuuuuYuuuu

Amazon DynamoDB Accelerator (DAX)

https://aws.amazon.com/jp/dynamodbaccelerator/
DynamoDB用のキャッシュサービス

利点

  • 非常に高いパフォーマンス
    • 読み取り負荷の高いワークロードで1秒当たり数約万件のリクエストに対する応答時間をマイクロ秒単位で実現可能。
  • 高いスケーラビリティ
    • オンデマンドでスケール可能
    • 3ノードのDAXクラスターから始めて、最大10ノードの食らうスターまでノードの追加して容量を増やすことができる
  • フルマネージド
  • 使いやすさ
    • DynamoDBとAPI互換なので、アプリケーションコードを変更する必要なし
  • セキュア
    • 保管時、転送時の暗号化、VPCエンドポイントもあり

仕組み

DAXはVPCで動作するように設計されている

詳細

DynamoDB Blackbelt

DAXには2種類のキャッシュを持てる

  • Item Cache
    • GetItemやPutItem等KeyValue形式
  • Query Cache
    • QueryテキストやResultセット

DAXのユースケース

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/DAX.html#DAX.use-cases

DAX は、次のタイプのアプリケーションに最適です。

  • 可能な限り迅速な読み込み応答時間を必要とするアプリケーション。
  • 少数の項目を他のものよりも頻繁に読み込むアプリケーション。
  • 読み込み負荷が高いが、コストも重要なアプリケーション。DynamoDB を使用する場合、アプリケーションが要求する読み込み数を 1 秒ごとにプロビジョニングします。読み込みアクティビティが上昇すれば、テーブルにプロビジョニングされた読み込みスループットも増加し (追加コストがかかり) ます。または、アプリケーションからのアクティビティを DAX クラスターにオフロードして、そうしない場合に購入する必要がある読み込みキャパシティユニットの数を削減できます。
  • 大規模データセットに対して繰り返し読み込みが必要なアプリケーション。このようなアプリケーションは、データベースリソースを他のアプリケーションから引き離してしまう可能性があります。たとえば、リージョンの天気データの長期分析では、DynamoDB テーブルのすべての読み込みキャパシティが一時的に消費される可能性があります。この状況は、同じデータにアクセスする必要がある他のアプリケーションに悪影響を及ぼします。DAX を使用することで、代わりにキャッシュデータに対して気象分析を実行できます。

DAX は、次のタイプのアプリケーションには最適ではありません。

  • 強整合性のある読み込みを必要とする (または結果整合性のある読み込みを許容できない) アプリケーション。
  • 読み込みでマイクロ秒の応答時間を要求しない、または基礎となるテーブルから繰り返される読み込みアクティビティをオフロードする必要がないアプリケーション。
  • 書き込み負荷の高いアプリケーション。書き込み量が多い場合、クラスター内の DAX ノード間のレプリケーションが増加します。これにより、リソースの消費量が増加し、可用性の問題が発生するリスクがあります。
  • 読み込みの繰り返しが少ないアプリケーション。DAX は、キャッシュヒットレートが 90% を超える場合に最適に動作します。キャッシュヒットレートが低いとキャッシュミスが増加し、DAX クラスター全体でより多くのリソースが消費されます。
YuuuuYuuuu

脆弱性診断→Inspector

Inspectorのスキャン対象

  • EC2インスタンス
  • ECRリポジトリに保存されたコンテナイメージ
  • Lambda関数
YuuuuYuuuu

コンピューティングの選択

リレーショナルデータベースを利用したアプリケーションで、常に利用可能である必要がある。
また、予測できないトラフィックパターンが発生し、アイドル期間中のコンピューティングコストを最低限にしたい→Fargate ＆ Aurora Serverlessの利用

アイドル状態でのコストを抑えるためにはサーバーレス構成を取ることが必要
❓ Fargatってサーバーレスでいいの？→サーバーレスでよい！

サーバーレスで従量制料金のコンピューティングエンジンであり、サーバーを管理することなくアプリケーションの構築に集中することができます。

https://aws.amazon.com/jp/fargate/

YuuuuYuuuu

Redshift

RedShiftのコスト削減

バックアップ

Amazon Redshift のスナップショットスケジューリング機能で作成されるデフォルトの Redshift 自動スナップショットに料金は発生せず、最大 35 日間保持することができます。

https://aws.amazon.com/jp/redshift/pricing/#Backup_storage

逆に言えば、手動スナップショットには費用が発生する。
そのため、スナップショットには保持期間を設け、不要なスナップショットは削除する。
スナップショットは増分バックアップであることも頭に入れておく。

データ転送

バックアップ、復元、読み込み、アンロードといったオペレーションのために、同じ AWS リージョン内の Amazon Redshift と Amazon S3 の間でデータを転送しても、料金はかかりません。これ以外の Amazon Redshift との間のデータ転送すべてには、通常の AWS データ転送料金が請求されます。 特に、Amazon Virtual Private Cloud (VPC) で Amazon Redshift クラスターを実行する場合、Amazon Redshift クラスターエンドポイントへの JDBC/ODBC によるデータ転送に対し、標準の AWS データ転送料金がかかります。さらに、拡張された VPC のルーティングを使用する場合や、別のリージョンにある Amazon S3 にデータをアンロードする場合は、通常の AWS データ転送料金が発生します。

https://aws.amazon.com/jp/redshift/pricing/#Data_transfer

Redshift ↔ S3の通信には料金は発生しない。
がしかし、それ以外は発生する。

拡張 VPC ルーティングの使用には追加料金はかかりません。

https://docs.aws.amazon.com/redshift/latest/mgmt/enhanced-vpc-routing.html

コンピューティングリソース

ノードタイプとクラスターの選択ができ、オンデマンド料金かリザーブドインスタンスでの料金がある。

ノードタイプはRA3 or DC2。

RA3 ノードでは、コンピューティング性能とマネージドストレージのスケーリングと支払いを独立させることで、データウェアハウスを最適化できます。RA3 では、パフォーマンス要件に基づいてノードの数を選択し、使用したマネージドストレージに対してのみ料金が発生します。

DC2 ノードでは、ローカル SSD ストレージを搭載し、コンピューティング負荷の高いデータウェアハウスを実現します。~~未圧縮で 1 TB 未満のデータセットでは、最も低い価格で最良のパフォーマンスを得るため、DC2 ノードタイプの利用を推奨します。データ量の増大が予想される場合は、RA3 ノードのご利用をお勧めします。

データ量に応じたノードタイプの選択をすることにより、コスト最適化を図る。

Redshift Serverless

Amazon Redshift Serverless は、1 時間あたり 3 USD という低料金で使い始めることができます。お支払いいただくのは、データウェアハウスがアクティブなときに消費したコンピューティングキャパシティに対してのみです。

https://aws.amazon.com/jp/redshift/pricing/#Amazon_Redshift_Serverless

低コストで始められる◎。
公式でも比較しているので、見る。

https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-console-comparison.html

Redshift Spectrum

S3バケット上に保存されたファイルに対して直接、高度なクエリ処理を実行することが可能に。

Amazon Redshift Spectrum を使用すると、効率的にクエリを実行し、Amazon Redshift テーブルにデータをロードすることなく、Amazon S3 のファイルから構造化および半構造化されたデータを取得できます。
Redshift Spectrum クエリでは超並列処理を採用しており、大きなデータセットに対する処理が非常に高速で実行されます。処理の多くは Redshift Spectrum レイヤーで生じ、データの大部分が Amazon S3 に保持されます。複数のクラスターが Amazon S3 で同じデータセットを同時にクエリできます。クラスターごとにデータをコピーする必要はありません。

https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c-using-spectrum.html

YuuuuYuuuu

AWS ParallelCluster

AWS ParallelCluster は、オープンソースのクラスター管理ツールで、AWS でハイパフォーマンスコンピューティング (HPC) クラスターをデプロイして管理することを容易にします。

https://aws.amazon.com/jp/hpc/parallelcluster/

AWS ParallelCluster is an AWS supported open source cluster management tool that helps you to deploy and manage high performance computing (HPC) clusters in the AWS Cloud.

https://docs.aws.amazon.com/parallelcluster/latest/ug/what-is-aws-parallelcluster.html

パラレルとクラスターの間にスペースないらしい

メリット

  • 自動リソーススケーリング
    • アプリケーションに必要なリソースを自動でモデル化、プロビジョニング、動的スケーリングしてくれる
  • 簡単なクラスター管理
    • 自動で構築や再構築をしてくれる
  • クラウドへのシームレスな移行
    • 複数のOS対応、パッチスケジューラへの対応をしている

ユースケース

  • プロダクションワークロードの最適化
    • HPCクラスターを簡単に作れる
  • ラピッドプロトタイプ

機械学習での利用

HPCで機械学習を利用するときに、ENAとしてEFA（Elastic Fabric Adapter）をParallelClusterと併用する。
EFA を使用すると、Message Passing Interface (MPI) を使用する高性能計算 (HPC) アプリケーションをスケールさせることができ、その結果、AWS クラウドのオンデマンドの伸縮自在性と柔軟性を備えたオンプレミスの HPC クラスターのアプリケーションパフォーマンスを実現できます。

YuuuuYuuuu

Auto Scaling

起動が繰り返し失敗する

Amazon EC2 Auto Scaling は、インスタンスの起動に繰り返し失敗する Auto Scaling グループのプロセスを停止することもできます。これは、管理上の中断と呼ばれます。管理上の中断は一般に、24 時間以上インスタンスの起動を試みているが、インスタンスの起動に成功しない Auto Scaling グループに適用されます。

https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-suspend-resume-processes.html

24時間以上失敗を繰り返すと一時停止する。

中断/再開機能は、以下のプロセスをサポートします。
・Launch – グループがスケールアウトしたとき、または Amazon EC2 Auto Scaling がウォームプールにインスタンスを追加するときなど、他の理由でインスタンスを起動することを選択した場合に、Auto Scaling グループにインスタンスを追加します。 Auto Scaling
・Terminate – グループがスケールインするとき、または Amazon EC2 Auto Scaling が最大存続期間を超えたためにインスタンスが終了したときやヘルスチェックに失敗したときなど、他の理由でインスタンスを終了することを選択した場合に、Auto Scaling グループからインスタンスを削除します。 Auto Scaling
・AddToLoadBalancer – インスタンスが起動されたときに、アタッチされたロードバランサーターゲットグループまたは Classic Load Balancer にインスタンスを追加します。詳細については、「Elastic Load Balancing を使用して、受信アプリケーショントラフィックを Auto Scaling グループに分散する 」を参照してください。
・AlarmNotification – 動的スケーリングポリシーに関連付けられているアラームからの CloudWatch通知を受け入れます。詳細については、「Amazon EC2 Auto Scaling の動的スケーリング」を参照してください。
・AZRebalance – 以前に使用できなかったアベイラビリティーゾーンが正常な状態に戻った場合など、グループが不均衡になったときに、指定されたすべてのアベイラビリティーゾーンにわたってグループ内のEC2インスタンスの数を均等に分散します。詳細については、「アクティビティの再分散」を参照してください。
・HealthCheck — Amazon EC2または Elastic Load Balancing がインスタンスに異常があることを Amazon EC2 Auto Scaling に指示した場合、インスタンスの状態をチェックし、インスタンスを異常としてマークします。このプロセスは、手動で設定したインスタンスのヘルス ステータスをオーバーライドできます。詳細については、「Auto Scaling グループ内のインスタンスのヘルスチェック」を参照してください。
・InstanceRefresh – インスタンスの更新機能を使用してインスタンスを終了して置き換えます。詳細については、「インスタンスの更新を使用して Auto Scaling グループのインスタンスを更新する」を参照してください。
・ReplaceUnhealthy – 異常とマークされたインスタンスを終了し、新しいインスタンスを作成して置き換えます。詳細については、「Auto Scaling グループ内のインスタンスのヘルスチェック」を参照してください。
・ScheduledActions – スケーリングプランを作成し、予測スケーリングを有効にするときに、作成した、または自動的に作成されたスケジュールされた AWS Auto Scaling スケーリングアクションを実行します。詳細については、「Amazon EC2 Auto Scaling のスケジュールされたスケーリング」を参照してください。

https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-suspend-resume-processes.html#process-types

YuuuuYuuuu

S3

S3ストレージクラス

S3 Standard (S3標準)

  • アクセス頻度の高いデータ向け汎用ストレージ
  • 低レイテンシーかつ高スループット
  • SLA: 99.9%

S3 Inteligent-Tiering

  • アクセス頻度に基づいてデータを最も費用対効果の高いアクセス階層に自動的に移動させる
  • 高頻度アクセス階層、低頻度アクセス階層、アーカイブインスタントアクセス階層はS3 Standardと同じ低レイテンシーと高スループットのパフォーマンス
  • 低頻度アクセス階層はストレージコストを最大40％節約
  • アーカイブインスタントアクセス階層は最大65%節約
  • ディープアーカイブアクセス階層はGlacier Deep Archiveと同じパフォーマンスを発揮し、最大95%節約
  • 128KBより小さなオブジェクトは高頻度アクセス階層料金で課金され、モニタリング料金やオートメーション料金は発生しない

S3 Standard-IA

  • ミリ秒単位のアクセスを必要とするアクセス頻度の低いデータ
  • S3 Standardと同じ低レイテンシーかつ高スループットなパフォーマンス
  • SLA: 99%

S3 One Zone-IA

  • アクセス頻度の低いデータを再作成可能
  • S3 Standardと同じ低レイテンシーかつ高スループットなパフォーマンス
  • SLA: 99%

S3 Glacier Instant Retrieval

  • 年に数回アクセスがあり、瞬時に取り出される長期間のデータ
  • S3 Standardと同じパフォーマンスのミリ秒単位のデータの取り出し
  • 99%の可用性SLA
  • 128KBの最小オブジェクトサイズ
  • S3 Glacier Instant Retrieval に直接アップロードする S3 PUT API と、オブジェクトを自動移行するための S3 ライフサイクル管理

S3 Glacier Flexible Retrieval (旧S3 Glacier)

  • ほとんどアクセスされない低コストのバックアップデータとアーカイブデータ
  • 99.9% の可用性 SLA で 99.99% の可用性を実現するように設計されています
  • 転送中のデータの SSL と保管中のデータの暗号化をサポート
  • コストを気にせずに、時に大量のデータを数分で取り出す必要があるバックアップと災害対策のユースケースに最適
  • 設定可能な取り出し時間 (数分から数時間)、無償の一括取り出し
  • S3 Glacier Flexible Retrieval に直接アップロードする S3 PUT API と、オブジェクトを自動移行するための S3 ライフサイクル管理

取得タイプ

  • 迅速
    • 1～5分で取り出し
  • プロビジョニングキャパシティ
    • 迅速取り出しの取得容量を必要な時に利用できるように保証
  • 標準
    • デフォルト
    • 3～5時間で取り出し
  • 大容量
    • 1日以内
    • 5～12時間で取り出し
    • 最も安価

S3 Glacier Deep Archive

  • アクセス頻度が非常に低くk、コストも尾非常に低いアーカイブデータ
  • SLA: 99.9%
  • 磁気テープライブラリの理想的な代替策
  • 取り出し時間は12時間以内
  • S3 Glacier Deep Archiveに直接アップロードするS3 PUT APIと、オブジェクトを自動移行するためのS3ライフサイクル管理

S3ストレージクラスパフォーマンス表

S3オブジェクトロック

コンプライアンスモード VS ガバナンスモード

  • コンプライアンスモード
    • rootユーザ含め、保護されたオブジェクトのバージョンの上書きや削除できない
      *リテンションモードの変更もできず、保持期間を短縮することもできない
  • ガバナンスモード
    • 特別なアクセス許可がない限り、上書きや削除、ロック設定を変更できない
    • 一部のユーザに対して必要に応じてアクセス許可を付与できる
YuuuuYuuuu

AWS Storage Gateway

オンプレのアプリケーションにS3をつなぐ。

S3ファイルゲートウェイ

https://aws.amazon.com/jp/storagegateway/file/s3/

ローカルキャッシュを使用してNFSまたはSMBファイいるデータからS3オブジェクトを保存してアクセス。

テープゲートウェイ

https://aws.amazon.com/jp/storagegateway/vtl/

AWSの仮想テープにオンプレミスデータをバックアップしアーカイブする。

ボリュームゲートウェイ

https://aws.amazon.com/jp/storagegateway/volume/

オンプレミスアプリケーションにクラウドバックアップのiSCSIブロックストレージボリュームを提供する。

  • キャッシュボリューム
    • データをS3に保存し、頻繁にアクセスされるデータのコピーをローカルに保持する。
    • キャッシュボリュームを使用すると、プライマリストレージのコストが大幅に削減され、オンプレミスでストレージを拡張する必要性が最小限に抑えられる。
    • オンプレ環境のストレージをS3に拡張
    • 頻繁にアクセスされるデータはローカルのストレージゲートウェイに保持してS3をプライマリデータストレージとして使用
    • 頻繁にアクセスするデータはオンプレにキャッシュ保持することで、低レイテンシーなアクセスが可能
  • 保存ボリューム
    • データセット全体に低レイテンシーでアクセスする必要がある場合は、まずオンプレミスゲートウェイを設定して、すべてのデータをローカルに保存する。
    • 次にこのデータのポイントインタイムスナップショットをS3に非同期にバックアップする。
    • ローカルデータセンタまたはEC2に復元できる。
    • プライマリデータをローカルに保存する一方でそのデータを非同期にS3にバックアップする。
    • オンプレのアプリがそのデータセット全体に低レイテンシーでアクセスが可能となる

参考：https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html

How Volume Gateway works

YuuuuYuuuu

Route53

ルーティング

  • シンプルルーティング
  • フェイルオーバールーティング
  • 位置情報ルーティング
    • ユーザーの位置に基づいてルーティング
  • 地理的近接性ルーティング
    • リソースの場所に基づいてルーティング
  • レイテンシールーティング
  • IPベースルーティング
  • 複数値回答ルーティング
    • ランダムに選ばれたレコードにIPを設定して複数の値を返答する
  • 加重ルーティング
YuuuuYuuuu

DynamoDB

キャパシティ

オンデマンドモード

  • 利用負荷が予測できない場合に利用
  • オンデマンドでRead/Write処理に自動スケールを実施

プロビジョニングモード

  • 利用負荷があらかじめ予測できる場合はプロビジョンドスループットモードを選択
  • 事前にWCU/RCUを設定

WCU (Write Capacity Unit)/RCU(Read Capacity Unit)

  • WCU
    • 項目のサイズが1KBまでなら1WCUで標準の書き込み要求1秒あたり1回の実行
    • トランザクション書き込み要求なら2WCUが必要
  • RCU
    • 強力な整合性、結果整合性、トランザクション読み取りがある
    • 強力な整合性
      • 項目のサイズが4KBまでなら1RCUで強力な整合性のあるリクエストを1秒あたりに1回の実行
    • 結果整合性
      • 項目のサイズが4KBまでなら1RCUで結果整合性のあるリクエストを1秒当たりに2回の実行
    • トランザクション
      • 4KBまでの項目を1秒当たり1回読み取るのに2RCUが必要

https://aws.amazon.com/jp/dynamodb/pricing/provisioned/

DynamoDBストリーム

DynamoDB テーブル内の項目レベルの変更に関するシーケンスを時間順にキャプチャし、その情報を最大 24 時間ログに保存します。アプリケーションは、このログにアクセスし、データ項目の変更前および変更後の内容をほぼリアルタイムで参照できます。

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Streams.html

YuuuuYuuuu

RDS

RDSプロキシ

  • 接続のプーリングができる
  • RDS プロキシの認証
  • TLS/SSLが使える
  • フェイルオーバーによる高可用性

接続が多すぎる場合等に使う

YuuuuYuuuu

Kinesis Data Stream

シャードって何？

スループットの単位
1シャードは1MB/秒のデータ入力と2MB/秒のデータ出力

コールドシャード vs ホットシャード

コールドシャード＝予想以上のシャード
ホットシャード＝予想以内のシャード

シャードの操作

シャードの分割って？？
→1つのシャードを2つに分ける。分割するとストリームの容量は増えるが、その分コストは増加

マージって？？
→2つのシャードを1つに結合する。容量とコストは減少

YuuuuYuuuu

FSx

種類 (FSx for ,,,)

  • FSx for NetApp ONTAP
  • FSx for OpenZFS
  • FSx for Windows File Server
  • FSx for Lustre
このスクラップは1ヶ月前にクローズされました