![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2020-10-15T10:31:29+00:00","default:wikiadmin","wikiadmin") #author("2021-03-29T21:57:53+00:00","default:wikiadmin","wikiadmin") -CDN #contents *概要 [#jb53e6e9] CDNとしてコンテンツをキャッシュできる。全世界にキャッシュを持つので、キャッシュクリアや設定の変更反映には時間がかかるので注意。またCloudFrontにキャッシュさせるとブラウザキャッシュにも入ってしまうので、なんかおかしいなと思ったらブラウザのキャッシュクリアも試してみること。設定の変更には時間がかかるので検証する場合はまとめて＆気長に！ *CloudFront 用語集 [#a1df3a3c] |Distribution|CloudFrontの一番大きな管理単位| |Origin|Distributionに複数配置可能。次のBehaviorsにて/path以下を別ドメインに割り当てるなんてことも可能。| |Behaviors|パスに対してどのoriginを割り当てるかの設定。path/*をどのOriginにするかを指定する。クエリーストリングを渡さないのがデフォルトなので注意。パスはそのままoriginにわたるので/hogeだとorigin/hogeになる。あと末尾が完全一致しないと飛ばないのでwiki/*にたいしてwikiではマッチしない。| |C Name|ランダムなxxx.cloudfront.netだとアクセスしづらいのでCNameを設定できるが正規のSSL証明書が必須となった| *cli [#bde5260c] |一覧|aws cloudfront list-distributions | |invalidation|aws cloudfront create-invalidation --distribution-id XXXXXXX --paths '/*' | *SSLでCNAMEを使う [#e54fb604] +ヴァージニアのACMに独自証明書をインポートする。 https://recipe.kc-cloud.jp/archives/11408 +terraform https://qiita.com/tos-miyake/items/f0e5f28f2a69e4d39422 https://tech.torico-corp.com/blog/aws-cloudfront-acm-ssl-sertificate/ *キャッシュについて [#k96dff5e] **デフォルト設定 [#xe066138] 何もしないとデフォルトは２４時間キャッシュ。クエリストリング部分は参照しないのでwikiなんかでは延々とTOPページが表示される。originサーバーでのCacheヘッダーを参照するようにするとその通りに動いてくれる。no-cacheやprivateを入れていればキャッシュしない。Behaviroの設定でカスタマイズすることもできるのでurlパス単位で設定できる。 PHPだと以下のキャッシュコントロールを入れるとキャッシュされなかった。 <?php header("Cache-Control: no-cache"); header("Cache-Control: private"); date_default_timezone_set('JST'); echo date(DATE_RFC2822); echo date("Y/m/d G:i:s"); **QueryString Forwarding and Caching [#y7893e5b] |None|クエリーストリング無視。完全静的ページ向け| |Forward all, chache based on whitelist|クエリーストリングで指定パラメータ以外はキャッシュする。a=xxx&b=123でaが指定されている場合bが変わってもa=xxxのページキャッシュがかえる| |Forward all, cache based on all|クエリーストリング列も含めてキャッシュ対象| **キャッシュかどうかの見分け方 [#efcf783f] -ヘッダーにX-Cacheが付与されている。 |キャッシュがないとき|X-Cache: Miss from cloudfront| |キャッシュ有通常ページ|X-Cache: Hit from cloudfront| |キャッシュ有かつエラーページ|X-Cache: Error from cloudfront| *IP制限 [#s5f5f63a] Terraform使ってやるといい https://www.terraform.io/docs/providers/aws/d/ip_ranges.html *キャッシュ無効化 [#o1377c31] キャッシュ無効化は１０００件までは無料。ワイルドカードでも良いので消したいフォルダの上位で指定するのが無駄なくて良い。無効化は各エッジサーバーに伝播するのに、結構時間がかかるのとObjectの数が3000個らしいので頻繁に変わるところは適宜キャッシュコントロールを付けるのがおすすめ。 *Originの制限 [#be7adbae] -CloudFront→OriginでSSLはダメ？(toolsがダメだったがWWWはOKなので別の原因だろう) -Diguest認証外したらOK！ *Lambda@Edge [#w97af7b6] 仕掛けるタイミングはViewer Request/Origin Request/Origin Response/Viewer Responseで４つ。それぞれ一つだけであるが、behaviorごとに設定できる！ https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-edge.html **注意点 [#ib2c1a40] -一度紐づけると各リージョンにreplicaが作成されて、コンソールから削除はできない。CloudFrontからの紐付けが外れると数時間で消える。 **ARN [#i2ecd302] -バージョン付きARNじゃないとダメで、どこで取得できるのか？ARN取得して:バージョン番号を付与する。qualified_arnがそれ default_cache_behavior { # 中略 # lambda@Edge lambda_function_association { event_type = "viewer-request" lambda_arn = aws_lambda_function.redirect.qualified_arn } } **必要な権限 [#kae0c78a] -assume role { "Version": "2012-10-17", "Statement": [ { "Action": "sts:AssumeRole", "Principal": { "Service": ["lambda.amazonaws.com", "edgelambda.amazonaws.com"] }, "Effect": "Allow" } ] } -以下の管理ポリシーはDocumentには記載があるが実際には付与しないでもOKだった。（付与したらエラー） AWSServiceRoleForLambdaReplicator AWSServiceRoleForCloudFrontLogger *Behaivor [#c663e372] 上から順番に一致なので、より細かいものを上に持ってくるべし -これだとhoge/mogeは一つ目にマッチしてしまうので hoge/* hoge/moge/* -逆にする hoge/moge/* hoge/* *エラーページ [#j1d32a93] *CloudFrondの障害など [#b081c793] 年1－2回レベルで発生しているらしいので、落ちた時の対策を考えておく必要がある。 *CloudFront用のrewrite設定 [#t30d767c] **Wordpress [#g0dfc0ad] RewriteEngine On RewriteCond %{HTTP_USER_AGENT} !CloudFront RewriteCond %{REQUEST_METHOD} =GET RewriteRule ^(.*)$ http://%1クラウドフロントのURL$1 [R=301,L,NE] 最後のNEはURLエンコーディングをしないということで、これを入れないと検索できない。 **pukiwiki [#v73f4e18] もともとno-cacheなので大して負荷軽減にはなってないぞ。 RewriteEngine on RewriteCond %{HTTP_USER_AGENT} !CloudFront RewriteCond %{QUERY_STRING} !(cmd=edit|plugin=newpage|その他除外したいクエリー) RewriteCond %{REQUEST_METHOD} =GET RewriteRule ^(.*)$ http://%1クラウドフロントのURL$1 [R=301,L,NE] 同じくNE必須。 *ログの出力 [#u268976c] ログを出力を有効にすると約10分毎にログがS3に生成される。PUTが多くなるのでS3の無料枠をはみ出すことになるので本格運用する場合はコストに含めておくべき。 *CloudFront移行 [#p660159d] 同じcnameは同時に存在できないので、移行元で別名に変更後、わりとすぐに別名で作成できる。 *S3連携 [#ud453472] -CloudFrontからのみアクセス可能にするためにはOAIを作成後、そのUSER IDをS3のポリシーに設定。Update Bucket policyをすると該当S3のバケットポリシーを許可してくれる。 "だがうまくいかない" -OriginAccessIdentityを作成後に該当バケットのバケットポリシーを見ると、アクセス許可が入っているはず。 { "Version": "2008-10-17", "Id": "PolicyForCloudFrontPrivateContent", "Statement": [ { "Sid": "1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity XXXXXX" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::アクセスさせたいバケット名称/*" } ] } **S3連携でDirectory Index実現 [#r1b67248] -CloudFrontはDefault Root Objectが指定できるがドメイン直下のみ -S3もIndex.htmlなどの設定ができるが、S3直接アクセスのみ(CloudFront経由だと機能しない) Lambda@Edgeのoriginトリガー(cache missの時に動く、/をindex.htmlにするだけであればこれで十分) #counter
