kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

Amazon CloudFrontおぼえがき

DDoS対策は?

デフォルトでAWS Shieldが入っているので、それで対策される

脆弱性攻撃対策は?

WAFを入れれば対策できる

Basic認証入れたい

CloudFront Functions を使う

特定のPATHの場合リダイレクトしたい

CloudFront Functions を使う

Lambda@Edgeと、CloudFront Functionsってどっち使えばいいの?

  • レスポンスヘッダ編集、リダイレクト、キャッシュキーの正規化みたいな軽い処理は CloudFront Functions
  • もっと重い処理は Lambda@Edge

docs.aws.amazon.com

TTLよくわからない

これ読んで

blog.kasei-san.com

Amazon CloudFrontのTTL挙動おぼえがき

TTLの挙動は、これ見るのが一番早い

christina04.hatenablog.com

Cache-Control ヘッダについては、こちらを参照

techblog.lclco.com

なんでこんなにややこしいの

オリジン側の Cache-Control を尊重した上で、CDNではどう振る舞うのか? を考慮しているため……だと思う……

ものすごくざっくりした理解

  • s-max-agemax-ageExpires の順で優先される
  • max-age などが、 MinTTLMaxTTLの範囲であれば、max-age が尊重される
    • max-age が、MinTTL 以下ならば、MinTTL が優先
    • max-age が、MaxTTL 以上ならば、MaxTTL が優先
  • Cache-Controlno-cache, no-store, private のいずれかの場合
    • MinTTL = 0 ならば、キャッシュしない
    • MinTTL > 0 ならば、MinTTL
  • Cache-Control が無い場合、
    • MinTTL = 0 ならば、DefaultTTLDefaultTTL 唯一の登場機会
    • MinTTL > 0 ならば、MinTTL

TTLのデフォルト値

  • MinTTL : 未記載
    • おそらく 0
    • TTLを何も設定しないと、24時間キャッシュされると書かれているので
  • MAXTTL : 1年
  • DefaultTTL : 24時間

docs.aws.amazon.com

オリジンをS3で使う場合

  • デフォルトでは Cache-Control は未指定なので以下のように設定すれば良い。
    • MinTTL=0
    • DefaultTTL=${キャッシュしたい秒数}
    • MaxTTL= 31536000 ← ぶっちゃけどんな値でも問題ないはず

参考

dev.classmethod.jp

docs.aws.amazon.com

RDS Auroraの自動バックアップ、スナップショットのおぼえがき

自動バックアップとスナップショットの違い

  • スナップショット: フルバックアップ。手動のみ。保存期間無限
  • 自動バックアップ: 差分バックアップ。1日1回自動。保存期間は1〜35日。任意の日時で復元が可能(PITR)

どちらもクラスタ単位。復元では新しいクラスタが生成される

自動バックアップ

概要

  • Auroraの場合は必ず適用される
  • バックアップウィンドウの時間に1日1回バックアップが取られる
  • クラスタ単位でバックアップが取られる
  • 保持期間は 1〜35 日の間で設定可能。それ以上はバックアップできない
    • その場合はスナップショットを使え、ということらしい
  • AWS Backupでの「継続的なバックアップ」をAuroraでは「自動バックアップ」と読んでいる(らしい

仕組み

  • トランザクションログとシステムスナップショットをS3に保存する
    • このS3にはユーザはアクセスできない
    • システムスナップショットとは、おそらく、RDSの各種設定と、ベースとなるボリュームのスナップショットと思われる
  • 差分バックアップ
    • ボリュームそのものではなく、トランザクションログをバックアップしていく仕組み
    • そのため、バックアップに掛かる時間が短い
  • ポイントインタイムリカバリ(PITR)
    • トランザクションログがあるため、バックアップがあれば、任意の時間の状態に復元することが可能

料金

  • 1日分のバックアップは無料
  • 保存料金は、東京リージョンでは 2024/04/21 時点で、毎月 USD 0.023/GB
  • どれだけ使用しているかは、BackupRetentionPeriodStorageUsed の値で確認できる
    • ここには1日分のバックアップのデータ量は入っていない様子
  • 上記のように、差分でバックアップがとられるため、ボリューム量と、バックアップ量は相関が無い
    • 変更が多ければそれだけ料金が掛かる
    • ただし、 自動バックアップの合計請求使用量が、保持期間中の累積クラスターボリュームサイズを超えることはない とのこと

自動バックアップの合計請求使用量が、保持期間中の累積クラスターボリュームサイズを超えることはありません。例えば、保持期間が 7 日間で、クラスターボリュームが毎日 100 GB の場合、請求される自動バックアップの使用量は 700 GB (100 GB * 7) を超えることはありません。

docs.aws.amazon.com

復元

  • RDSの管理画面から「バックアップ -> 自動バックアップ -> アクション -> 特定の時点への復元」で復元
  • 新しいクラスタとして復元されるので、参照しているアプリのエンドポイントを変更する必要あり

マルチリージョンでのバックアップ、復元

  • AWS Backupで設定すれば、複数リージョンにPITAできるバックアップを取ることが可能
  • ただし、各リージョンへの転送料と、バックアップ保持のコストが掛かる
    • 転送量が結構高い ( USD 0.09/GB )
  • 他リージョンで復元する場合、元リージョンで使用していた、パラメータグループやオプショングループが必要
    • Terraformなどで残しておく必要あり

スナップショット

概要

  • クラスタ単位でスナップショットが取られる
  • 保持期間は特に定められていない
    • ただし、サポートされていないDBバージョンのスナップショットは復元できない。長期間保持するときは注意
  • ポイントインタイムリカバリは使えない
    • 自動バックアップの「仕組み」で書いた システムスナップショット を手動で取得するサービス。という理解
    • なので、1スナップショットで掛かるデータ量は、DBのボリュームのサイズと同一

料金

  • 保存料金は、東京リージョンでは 2024/04/21 時点で、毎月 USD 0.023/GB
  • バックアップ保持期間の間は無料。それを過ぎると課金される
    • バックアップ期間が7日あるならば、スナップショットを取ってから7日間は無料。8日目から課金される
  • どれだけ使用しているかは、SnapshotStorageUsed の値で確認できる
    • バックアップ保持期間内のスナップショットのデータ量はここに含まれないとのこと。親切!!

復元

  • RDSの管理画面から「スナップショット -> 手動スナップショット -> アクション -> スナップショットを復元」
  • バックアップと同じく、新しいクラスタとして復元されるので、参照しているアプリのエンドポイントを変更する必要あり
  • サポートされていないDBバージョンのスナップショットは復元できない

マルチリージョンでのスナップショット、復元

  • 他リージョンへのコピー機能があるので、それを使う

docs.aws.amazon.com

  • こちらも、各リージョンへの転送料と、バックアップ保持のコストが掛かる
    • 転送量が結構高い ( USD 0.09/GB )
  • こちらも、他リージョンで復元する場合、元リージョンで使用していた、パラメータグループやオプショングループが必要
    • Terraformなどで残しておく必要あり

その他

  • 長期間保存する場合、S3エクスポートを推奨している
  • ただし、 S3にエクスポートしたデータからクラスタの復元は困難
    • Apache Parquet という形式で保存される。Athenaなどで分析する時に使うフォーマットらしい
    • AWS Glueとかを使えばAuroraに復元できなくなはないらしい

tech-blog.cloud-config.jp

感想

  • 自動バックアップは、スナップショットにトランザクションログを乗せているという認識
    • 二重課金になるので、自動バックアップの期間内はスナップショットは無料なのでは?

参考

docs.aws.amazon.com

docs.aws.amazon.com

aws.amazon.com

dev.classmethod.jp

dev.classmethod.jp

docs.aws.amazon.com

RDS Auroraのreaderからのpg_dumpの途中で接続が切れる場合、max_standby_streaming_delay を上げると良いよ

タイトルで言いたいことだいたい言っちゃったんですが、

readerエンドポイントでpg_dump を実行していたら、大きめのテーブルをdumpしている時に接続がちょこちょこ途切れる現象が発生していました。 それで、DBのログを見てみたら以下のエラーがありました

FATAL:  terminating connection due to conflict with recovery
DETAIL:  User was holding a relation lock for too long.

これは、以下のサイトに詳しいのですが

www.fujitsu.com

「writer側の更新によるWAL(トランザクションログ)が、reader側に更新される」のと、「reader側の参照処理」がコンフリクトした場合に、一定時間が経過すると、参照側の接続が切られる という、psqlの機能のために発生しています

で、その待機時間を設定するためのオプションが、max_standby_streaming_delay です

max_standby_streaming_delay のポイント

  • postgreSQLのデフォルト値は30秒
  • Amazon Aurora PostgreSQL では、14秒
  • Amazon Aurora PostgreSQL で、設定できる最大値は 30秒

30秒で処理しきれない参照処理がある場合はどうしたら良いの?

  • 諦めてwriterエンドポイントで処理する
  • もしくは、SQLを分割するなど対策をする

参考

www.postgresql.jp

Amazon Athenaでアクセスログから、特定PATHの分ごとのアクセス数をカウントする方法

以下は、2023/11/18の15:00〜15:10の間の https://example.com:443/hoge への分単位のアクセス数を取るSQL

SELECT
    minute,
    COUNT(minute) AS count
    FROM (
        SELECT 
            date_trunc('minute', from_iso8601_timestamp(time)) AS minute
        FROM "alb_access_logs"
        WHERE 
            (time BETWEEN '2023-11-18T15:00:00' AND '2023-11-18T17:10:00') AND
            request_url like 'https://example.com:443/hoge'
    )
GROUP BY minute

date_trunc は、タイムスタンプを特定の範囲に丸めるもの ( minute とか day とか )

また、date_trunc にわたす前に、time を from_iso8601_timestamp で、ISO 8601 に変える必要がある

AUTOVACUUMが動かない時に調べること

AUTOVACUUMの設定

SELECT name, setting
FROM pg_settings
WHERE name LIKE '%autovacuum%';
  • autovacuumon であること
  • 他の数値も異常な値でないこと(どう考えても実行されない閾値とか)

AUTOVACUUMの最終実行日時

SELECT relname, last_autovacuum,last_autoanalyze FROM pg_stat_user_tables
WHERE 
    last_autovacuum is not NULL OR
    last_autoanalyze is not NULL;

テーブル毎のオプション

SELECT relname, reloptions
FROM pg_class
WHERE array_length(reloptions, 1) IS NOT NULL;
  • {autovacuum_enabled=false} が設定されていると、AUTOVACUUMされない

AUTOVACUUM実行対象のテーブル一覧

WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM 
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM 
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'), 
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace 
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid 
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) + 
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * 
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;

👇こちらから拝借

docs.aws.amazon.com

参考

qiita.com