ablog

不器用で落着きのない技術者のメモ

AWS を使って Web サイトを公開したりしてみる

AWS

ゆるく、AWS を使って Web サイトを公開したり、いろんなサービスを使ってみたりしていくメモ。

07. AWS WAF で CloudFront ディストリビューションに web ACL 作成

  • マネジメントコンソールで WAF & Shield にアクセスして、[Create web ACL] をクリック。
    • Resource type: CloudFront distributions
    • add AWS resources で CloudFront distribution を追加
  • [Add managed rule groups] をクリック。

f:id:yohei-a:20210124115622p:plain

  • [AWS managed rule groups] で有効にする ACL（Add to web ACL、Set rules action to count）をチェックする。

f:id:yohei-a:20210124114636p:plain

  • 次に進む

f:id:yohei-a:20210124114711p:plain

  • 次に進む

f:id:yohei-a:20210124114727p:plain

  • 次に進む

f:id:yohei-a:20210124114740p:plain

  • web ACL を作成する

f:id:yohei-a:20210124114754p:plain
f:id:yohei-a:20210124114815p:plain

参考

Amazon DynamoDB の監視設計

AWS

アラート通知

ThrottledRequests
メトリクス 説明
ThrottledRequests リソース (テーブルやインデックスなど) でプロビジョニングされたスループットの上限を超える、DynamoDB へのリクエスト。リクエスト内で任意のイベントがプロビジョンドスループットの制限を超過した場合、ThrottledRequests は 1 ずつ増加します。たとえば、グローバルセカンダリインデックスを持つテーブルの項目を更新する場合、テーブルへの書き込みと、各インデックスへの書き込みという複数のイベントが発生します。1 つ以上のイベントが抑制されると、ThrottledRequests が 1 ずつ増加します。
（中略）
どのイベントがリクエストを抑制しているかを確認するには、ThrottledRequests と、そのテーブルとインデックスの ReadThrottleEvents と WriteThrottleEvents を比較してください。
注記
調整されたリクエストでは、HTTP 400 ステータスコードになります。これらのすべてのイベントは、ThrottledRequests メトリクスに反映されますが、UserErrors メトリクスには反映されません。
単位: Count
ディメンション: TableName, Operation
有効な統計:
-Sum
-SampleCount
  • プロビジョニングされたスループットの上限を超える、DynamoDB へのリクエスト
  • ThrottledRequests が発生した場合は、ReadThrottleEvents、WriteThrottleEvents を確認することで、Read/Write のいずれもしくは両方でスロットリングが発生しているかを確認することができる。1リクエストのスロットリングで ThrottledRequests は 1 増える。1 リクエストで複数回のイベントが発生すると ReadThrottleEvents、WriteThrottleEvents は 2 以上増えることがある。
  • オンデマンドキャパシティモードでは自動的にスケールアウトするため基本的にスロットリングは発生しないが、急激なリクエスト増加などにより発生する可能性があるため、監視対象とすることを推奨。
    • テーブルにおける前のピークトラフィックの最大 2 倍まで瞬時に対応する。ただし、30 分以内に前のピークの 2 倍を超えた場合、スロットリングが発生する可能性がある。
SystemErrors
メトリクス 説明
SystemErrors 指定された期間中に HTTP 500 ステータスコードを生成する、DynamoDB または DynamoDB ストリームへのリクエスト。通常、HTTP 500 は内部サービスエラーを示します。
単位: Count
ディメンション: TableName, Operation
有効な統計:
-Sum
-SampleCount
DynamoDB メトリクスとディメンション - Amazon DynamoDB
UserErrors
DynamoDB メトリクスとディメンション - Amazon DynamoDB

モニタリング

ConsumedReadCapacityUnits
ConsumedWriteCapacityUnits
SuccessfulRequestLatency

参考

作成済の Aurora クラスターの Performance Insights を有効化する

AWS
  • クラスター作成後に Performance Insights を有効化する場合は、[クラスターの変更] ではなく [インスタンスの変更] で有効化する。
  • Aurora MySQL では t2、t3 インスタンスクラスは Performance Insights はサポートされていない。
  • RDS MySQL から Aurora リードレプリカを作成して昇格した場合に、Performance Insights を有効化できないという相談を受けたことがあるが、t2、t3 インスタンスクラス意外であれば、[インスタンスの変更]から有効化することができる。

参考

AWS Backup で Amazon DynamoDB のバックアップを定期的に取得する

AWS

AWS Backup で Amazon DynamoDB のバックアップを日次で取得してみた。
マネジメントコンソールで AWS Backup に移動してから以下の手順で作成した。

手順

バックアッププランを作成する
  • バックアップウインドウ: バックアップウインドウをカスタマイズ
    • バックアップウインドウの 開始時間 04:00 PM UTC（JST 01:00）
    • 次の時間内に開始: 1時間
      • 開始時間からできるだけ早く開始されるよう設定
    • 次の時間内に完了: 18時間
      • バックアップに要する時間より長めにウィンドウを設定
  • 有効期限切れ: 作成後の日数=7
      • バックアップを保持する期間を設定

f:id:yohei-a:20210120072956p:plain

リソースを割り当てる
  • [リソースを割り当てる] をクリック

f:id:yohei-a:20210120073015p:plain

  • リソースを割り当てる
    • 割り当て単位: リソースID
    • リソースタイプ: DynamoDB
    • テーブル名: 対象のテーブル名を選択

f:id:yohei-a:20210120073033p:plain

参考

Spark UI で参照している S3 のパスを変更する

AWS

CloudFormation で Spark UI 用に EC2 インスタンスを作成後に、参照する S3 のパスを変更する手順。

  • /opt/spark/conf/spark-defaults.conf の spark.history.fs.logDirectory を編集する
spark.eventLog.enabled                      true
spark.history.fs.logDirectory               s3a://spark-ui/ap-northeast-1/eventlog ★
spark.history.ui.port                       0
spark.ssl.historyServer.enabled             true
spark.ssl.historyServer.port                8192
spark.ssl.historyServer.keyStorePassword    ********
spark.ssl.historyServer.keyStore            /home/ec2-user/ec2-13-***-***-250.ap-northeast-1.compute.amazonaws.com.jks
  • Spark History Server を再起動する
$ sudo systemctl restart spark-history-server.service