AWS 認定ソリューションアーキテクト – プロフェッショナル 合格への道#10

#初めに

#学習

9 ds 〇

EC2条でアプリを実行ている。ネットワークトラフィックのモニタリングと監視を行いたい。要件は以下
スケール、運用コスト最小、クエリと可視化

• VPCフローログを作成してDynamoDBにパブリッシュする。LambdaでDBストリームからデータを読み出しログデータをAuroraのテーブルに書き込む。amazon Quicksightをテーブルに接続してデータを可視化
  • 送信先のDynamoDBが意味不明
• VPCフローログを作成してS3にパブリッシュする。athnaに外部テーブルを作成しログファイルをクエリ。Athnaをテーブルに接続してデータを可視化
• Amazon kinesis datastream でCloudwatchからログファイルをキャプチャーする。amazon kinesis firehoseを使ってログファイルをS3にプッシュする。athnaに外部テーブルを作成しログファイルをクエリ。Athnaをテーブルに接続してデータを可視化
  • elbのメトリクスはシステムが正常に動作していることを表す。脅威検出には向いていない。
• VPCフローログを作成してEMRのインメモリのsparkにパブリッシュする。amazon Quicksightをクラスターに接続し可視化
  • 送信先のsparkが意味不明。

Athenaを使ってVPC Flow Logsを解析する

https://techblog.nhn-techorus.com/archives/6202

VPC フローログとELBアクセスログの比較

VPC

• Ver
• アカウントID
• ENI-ID
• 送信元IP
• 送信先IP
• 送信元ポート
• 送信先ポート
• プロトコル
• パケット数
• バイト数
• 開始unixtime
• 終了unixtime
• 許可or拒否
• ステータス

ELB

• timestamp
• elb
• client:port
• backend:port
• request_processing_time
  • ELBがクライアントからリクエストを受けてからインスタンスにリクエストを送信するまでの時間。
• backend_processing_time
  • ELBがインスタンスにリクエストを送信し、インスタンスからレスポンスが戻ってくるまでの時間。
• elb_status_code
• backend_status_code
• received_bytes
• sent_bytes
• "request"

10 ds ×

us-west2のNLB背後のAutoScaling設定の入った複数AZEC2でアプリを実行。静的コンテンツはS3から配信され、トランザクションデータはRDS Mysqlに保管。DNSはRoute53。構成情報はSSMに保管アプリはCFNでデプロイされる。この構成でDR対策を検討する。RTOは30分、RPOは15分。安定した状態では4つのEC2が稼働する。
既に行ったこと

• S3クロスリージョンレプリケーション実行
• 全ての既存静的コンテンツをレプリケーション先S3バケットに移動
• レプリケーション先にリードレプリカとSSMの構成情報をレプリケーション
• CFNマッピングセクションを適切なAMIとRZに変更
• レプリケーション先でCFN実行
• レプリケーション先のスケーリンググループ設定をの最小および希望する数を１に設定
• 53でルーティングポリシーをフェイルオーバールーティングに変更
• レプリケーション先のNLBをポイントする53のホストゾーンにセカンダリレコードを追加
• 1番目のリージョンでアプリケーションに障害が発生した時にSNS通知をするよう設定

＋必要なことはなにか

---

• テンプレートのパラメータを追加してデプロイ先を指定
  • する必要がない
• AMIをレプリケーション先にコピーする
  • する必要がない
• レプリケーション先にAutoscalingの稼働数を4に設定するLambdaを配置。関数をヘルスチェックアラームSNSにサブスクライブする。
  • 正解
• レプリケーション先からレプリケーション元のAMIを使用できるように権限を設定
  • すでに環境が最小構成で動いている
• レプリケーション先にリードレプリカをスタンドアロンDBインスタンスにプロモートするLmabdaを配置。関数をヘルスチェックアラームSNSにサブスクライブする。
  • 正解

AWS CloudFormation

• 変更セット

  • スタックで実行中のリソースに変更を加える必要がある場合は、スタックを更新します。リソースに変更を加える前に、変更案の概要である変更セットを生成できます。変更セットで、変更が実行中のリソース、特に重要なリソースに与える可能性のある影響を、実装前に確認できます。

• AWS CloudFormation の VPC エンドポイントの設定

  • インターフェイス VPC エンドポイントを使用するように AWS CloudFormation を設定することで、VPC のセキュリティ体制を強化できます。インターフェイスエンドポイントは、プライベート IP アドレスを使用して AWS CloudFormation API にプライベートにアクセスできるテクノロジーである PrivateLink を使用しています。PrivateLink は、VPC および AWS CloudFormation 間のすべてのネットワークトラフィックを Amazon ネットワークに限定します。また、インターネットゲートウェイ、NAT デバイスあるいは仮想プライベートゲートウェイの必要はありません。

スタンドアロン DB インスタンスとなるようにリードレプリカを昇格

11 〇

データベースクラスタの以下の要件を満たすソリューションは何か？

• ノード間最小遅延
• 最大ネットワークスループット

---

• ENAを有効にしたEC2を起動。すべてのインスタンスをスプレッドプレイスメントグループに含める
• ジャンボフレームを有効化した最適化EC2インスタンスを単一AZで起動する。
• ENAを有効にしたEC2を起動。すべてのインスタンスをクラスタプレイスメントグループに含めジャンボフレームを有効にする
  • 正解
• 複数のEC2をもったENAを有効にしたEC2を起動。すべてのインスタンスをクラスタプレイスメントグループに含めジャンボフレームを有効にする

EC2 Linux の拡張ネットワーキング

拡張ネットワーキングでは、シングルルート I/O 仮想化 (SR-IOV) を使用して、サポートされるインスタンスタイプにおける高性能ネットワーキング機能が提供されます。SR-IOV は、従来の仮想化ネットワークインターフェイスと比較し、I/O パフォーマンスが高く、CPU 利用率が低いデバイス仮想化の手法です。拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。拡張ネットワーキングは追加料金なしで使用できます。

Elastic Fabric Adapter

Elastic Fabric Adapter (EFA) は、ハイパフォーマンスコンピューティング (HPC) と機械学習アプリケーションを高速化するために Amazon EC2 インスタンスにアタッチできるネットワークデバイスです。EFA では、AWS クラウドが提供するスケーラビリティ、柔軟性、伸縮性により、オンプレミスの HPC クラスターのアプリケーションパフォーマンスを実現できます。
EFA では、クラウドベースの HPC システムで従来使用されていた TCP トランスポートよりも低く、一貫性の高いレイテンシーを提供し、高いスループットが得られます。HPC と機械学習アプリケーションのスケーリングに不可欠なインスタンス間通信のパフォーマンスが向上します。既存の AWS ネットワークインフラストラクチャで動作するように最適化されており、アプリケーション要件に応じてスケーリングすることができます。

プレイスメントグループ

新しい EC2 インスタンスを起動する場合、EC2 サービスは、相関性のエラーを最小限に抑えるために、すべてのインスタンスが基盤となるハードウェアに分散されるようにインスタンスを配置します。プレイスメントグループを使用することで、ワークロードのニーズに対応するために独立したインスタンスのグループのプレイスメントに影響を与えることができます。ワークロードのタイプに応じて、以下のいずれかのプレイスメント戦略によりプレイスメントグループを作成できます。

• クラスタープレイスメントグループ
  • クラスタープレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。クラスタープレイスメントグループは、同じリージョン内の複数のピア VPC にまたがることができます。同じクラスタープレイスメントグループ内のインスタンスは、TCP/IP トラフィックの 10 Gbps を上限とするフローごとのスループット制限が高くなり、ネットワークの同じ高バイセクションバンド幅セグメントに配置されます。
  • 低いネットワークレイテンシー、高いネットワークスループット、またはその両方からメリットを受けるアプリケーションの場合は、クラスタープレイスメントグループの使用をお勧めします。また、ネットワークトラフィックの大部分がグループ内のインスタンス間で発生している場合にもお勧めします。プレイスメントグループで、最も低いレイテンシーと最も高いネットワークパフォーマンス (1 秒あたりパケット数) を実現するためには、拡張ネットワーキングをサポートするインスタンスタイプを選択
• パーティションプレイスメントグループ
  • パーティションプレイスメントグループは、アプリケーションに関連するハードウェア障害の頻度を軽減するために役立ちます。パーティションプレイスメントグループを使用する場合、Amazon EC2 は各グループをパーティションと呼ばれる論理的なセグメントに分割します。Amazon EC2 には、プレイスメントグループ内の各パーティションにそれぞれ一連のラックがあります。各ラックには独自のネットワークおよび電源があります。プレイスメントグループ内のパーティションどうしが同じラックを共有することはありません。これにより、アプリケーション内でのハードウェア障害による影響を隔離できます。
  • パーティションプレイスメントグループは、同じリージョン内の複数のアベイラビリティーゾーンにパーティションを持つことができます。パーティションプレイスメントグループは、アベイラビリティーゾーンごとに最大 7 つのパーティションを持つことができます。パーティションプレイスメントグループで起動できるインスタンス数の制限は、アカウントの制限のみです。
• スプレッドプレイスメントグループ
  • スプレッドプレイスメントグループは、それぞれに独自のネットワークおよび電源がある異なるラックに別々に配置できるインスタンスのグループ
  • スプレッドプレイスメントグループは、同じリージョン内の複数のアベイラビリティーゾーンに分散できます。グループごとのアベイラビリティーゾーンごとに、最大 7 つの実行中のインスタンスを持つことができます。

EC2 インスタンスの最大ネットワーク送信単位 (MTU)

ネットワーク接続の最大送信単位 (MTU) とは、接続を介して渡すことができる最大許容パケットサイズ (バイト単位) です。接続の MTU が大きいほど、より多くのデータを単一のパケットで渡すことができます。イーサネットパケットは、フレーム (送信している実際のデータ) とそれを囲むネットワークオーバーヘッド情報で構成
イーサネットフレームの形式はさまざまで、最も一般的な形式は、標準イーサネット v2 フレーム形式です。これはインターネットのほとんどでサポートされている最大のイーサネットパケットサイズである 1500 MTU をサポートします。インスタンスでサポートされている最大 MTU は、インスタンスタイプによって異なります。すべての Amazon EC2 インスタンスタイプで 1500 MTU がサポートされており、現在の多くのインスタンスサイズで 9001 MTU またはジャンボフレームがサポートされています。

• ジャンボフレーム (9001 MTU)
  • クラスタープレイスメントグループ内にコロケーションされたインスタンスでは、考えられる最大のネットワークスループットの実現するうえでジャンボフレームが役立ちます。

12

DBのDiskQueuePAth指標が急上昇した時に取る対策は？

• RDSのボリュームを増やす
  • IOが追い付いていないので関係ないと思われる。
• ストレージタイプをIOPSに変更し最大のIOPSでプロビジョニングする
  • 正解
• DBインスタンスをマルチAZ化する
  • 主な目的は高可用性
• DBインスタンスでEBS最適化オプションを実行
  • 不正解。m5.4xlargeはデフォルトで有効となっている

Amazon RDS​ のモニタリングの概要

• CPU または RAM の高消費量
  • CPU または RAM の消費量が大きい値になっていても、それは妥当である場合があります。ただし、アプリケーションの目標 (スループット、同時実行数など) に沿った想定値であることが前提
• Disk space consumptionディスクスペースの消費量
  • クスペースが一貫して合計ディスクスペースの 85% 以上である場合は、ディスクスペースの消費量を調べます。インスタンスからデータを削除するか、別のシステムにデータをアーカイブして、スペースを解放できるかどうかを確認
• Network traffic
  • ネットワークトラフィックについてシステム管理者に問い合わせて、ドメインネットワークとインターネット接続に対する想定スループットを把握します。スループットが一貫して想定よりも低い場合は、ネットワークトラフィックを調べます。
• Database connections データベース接続数
  • ユーザー接続数が多いことが、インスタンスのパフォーマンスが下がっていること、応答時間が長くなっていることに関連しているとわかった場合、データベース接続数を制限することを検討します。DB インスタンスの最適なユーザー接続数は、インスタンスのクラスと実行中のオペレーションの複雑さによって異なります。User Connections パラメータを 0 (無制限) 以外の値に設定したパラメータグループと DB インスタンスを関連付けることで、データベース接続数を決めることができます。既存のパラメータグループを使用するか、新しいパラメータグループを作成できます。
• IOPS メトリクス
  • IOPS メトリクスの想定値はディスクの仕様とサーバーの設定によって異なるため、ベースラインを使用して一般的な値を把握します。値とベースラインとの差が一貫しているかどうかを調べます。最適な IOPS パフォーマンスを得るには、読み取りおよび書き込みオペレーションが最小限になるように、一般的な作業セットがメモリに収まることを確認

####Amazon RDS メトリクス

• BinLogDiskUsage
  • マスターでバイナリログが占有するディスク領域の量。MySQL リードレプリカに適用されます。
• BurstBalance
  • 汎用 SSD (gp2) のバーストバケット I/O クレジットの利用可能パーセント。
• CPUUtilization
  • CPU 使用率。
• CPUCreditUsage
  • (T2 インスタンス) CPU 使用率に関してインスタンスで消費される CPU クレジットの数。1 CPUクレジットは、1 分間 100％ の使用率で実行される 1 つの vCPU、または vCPU、使用率、時間の同等の組み合わせに相当します。
• CPUCreditBalance
  • (T2 インスタンス) インスタンスが起動または開始後に蓄積した獲得 CPU クレジットの数。T2 スタンダードの場合、CPUCreditBalance には蓄積された起動クレジットの数も含まれます。
• DatabaseConnections
  • 使用中のデータベース接続の数。
• DiskQueueDepth
  • 未処理のディスク I/O アクセス (読み取り/書き込みリクエスト) の数。
• FailedSQLServerAgentJobsCount
  • 過去 1 分間に失敗した SQL Server Agent ジョブの数。
• FreeableMemory
  • 使用可能な RAM の容量。
• FreeStorageSpace
  • 使用可能なストレージ領域の容量。
• MaximumUsedTransactionIDs
  • 使用された最大のトランザクション ID。PostgreSQL に適用されます。
• NetworkReceiveThroughput
  • モニタリングとレプリケーションに使用する顧客データベーストラフィックと Amazon RDS トラフィックの両方を含む、DB インスタンスの受信ネットワークトラフィック。
• NetworkTransmitThroughput
  • モニタリングとレプリケーションに使用する顧客データベーストラフィックと Amazon RDS トラフィックの両方を含む、DB インスタンスの送信ネットワークトラフィック。
• OldestReplicationSlotLag
  • 受信した WAL データに関して最も遅延の大きいレプリカの遅延サイズ。PostgreSQL に適用されます。
• ReadIOPS
  • 1 秒あたりのディスク読み取り I/O 操作の平均回数。
• ReadLatency
  • 1 回のディスク I/O 操作にかかる平均時間。
• ReadThroughput
  • 1 秒あたりのディスクからの平均読み取りバイト数。
• ReplicaLag
  • ソース DB インスタンスからリードレプリカ DB インスタンスまでのラグ。MySQL、MariaDB、Oracle、PostgreSQL、および SQL Server のリードレプリカに適用されます。
• ReplicationSlotDiskUsage
  • レプリケーションスロットファイルで使用されているディスク容量。PostgreSQL に適用されます。
• SwapUsage
  • DB インスタンスで使用するスワップ領域の量。このメトリクスは SQL Server では利用できません。
• TransactionLogsDiskUsage
  • トランザクションログで使用されているディスク容量。PostgreSQL に適用されます。
• TransactionLogsGeneration
  • 1 秒あたりに生成されるトランザクションログのサイズ。PostgreSQL に適用されます。
• WriteIOPS
  • 1 秒あたりのディスク書き込み I/O 操作の平均回数。
• WriteLatency
  • 1 回のディスク I/O 操作にかかる平均時間。
• WriteThroughput
  • 1 秒あたりのディスクへの平均書き込みバイト数。

AWSSysOps備忘録1

EBS 最適化はデフォルトでは有効になっていません

低世代はダメというイメージ

large

• C
  • 1
    • x
  • 3
    • x
    • 2x
    • 4x
• g
  • 2
    • x
• i
  • 2
    • x
    • 2x
    • 4x
• m
  • 1
    • large
  • 2
    • 2x
    • 4x
  • 3
    • x
    • 2x
• r
  • 3
    • x
    • 2x
    • 4x

13

ストリームは400KB。動画アプリケーション。ログストリームをSQLで分析したい。

• ログデータをfirehose配信ストリームに出力。Lmabdaでデータ変換してRedshiftでクエリ
• ログをSQSに配信。Lambdaでデータ変換。Redshiftでクエリ
  • リアルタイムに処理するのに向いていない。順番性がない。
• ログをcloudwatchでS3に出力。Lambdaでデータ変換。Redshiftでクエリ
  • メトリクスとして配信であればリアルタイムについていけるのだろうか
• kinesisデータ配信ストリームに出力。Lambdaで二番目のストリームにデータを配信。kinesis data analyticsでクエリ

【初心者】Amazon Kinesis Video Streams を使ってみる（ラズパイカメラからの送信

Amazon Kinesis Data Firehose とは?

Amazon Kinesis Data Firehose は、リアルタイムのストリーミングデータを Amazon Simple Storage Service (Amazon S3)、Amazon Redshift、Amazon Elasticsearch Service (Amazon ES)、Splunk などの送信先に配信するための完全マネージド型サービスです。Kinesis Data Firehose は、Kinesis ストリーミングデータプラットフォームの一部です。他にも、Kinesis Data Streams、Kinesis ビデオストリーム、Amazon Kinesis Data Analytics があります。Kinesis Data Firehose を使用すると、アプリケーションを記述したり、リソースを管理したりする必要はありません。Kinesis Data Firehose にデータを送信するようデータプロデューサーを設定すると、指定した送信先にデータが自動的に配信されます。データを配信前に変換するように、Kinesis Data Firehose を設定することもできます。

主要なコンセプト

• Kinesis Data Firehose 配信ストリーム
  • Kinesis Data Firehose の基盤となるエンティティ。Kinesis Data Firehose を使用するには、Kinesis Data Firehose 配信ストリームを作成し、それに対してデータを送信