refirio.org

CDN（Content Delivery Network）で、日本語にするならコンテンツ配信サービス 世界中にエッジサーバ（データをキャッシュする、ユーザの近くにあるサーバ）があり、 最寄りのエッジサーバに誘導することで高速な配信ができる コンテンツのキャッシュにより、オリジンサーバの負荷も減らすことができる AWS再入門 Amazon CloudFront編 ｜ Developers.IO http://dev.classmethod.jp/cloud/cm-advent-calendar-2015-aws-re-entering-cloudfront/ 制限 - Amazon CloudFront https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html AWS WAFを使うためシステムにCloudFrontを導入した時の注意点まとめ ｜ Developers.IO http://dev.classmethod.jp/cloud/aws/setup-amazon-waf-and-cloudfront/ いますぐ使う CloudFront - Qiita https://qiita.com/sasasin/items/0f0ec1a90af6295589f9 ※60秒のタイムアウト制限があるので注意 巨大ファイルのアップロード受け付けるなど、長時間の処理が必要な場合はCloudFrontがネックになる 詳しくは「タイムアウト時間を調整する」を参照 ※以前は、WAFを使うにはCloudFrontを導入する必要があった ただし現在は、ALBに対してWAFを設定できるようになっている ※2019年4月8日以降、HTTPのみで使用する場合でもSSL証明書が必要になっている Amazon CloudFront の代替ドメイン名(CNAMEs)設定に SSL 証明書が必須になりました ｜ DevelopersIO https://dev.classmethod.jp/cloud/aws/201904_enhancing-domain-security-on-cloudfront/ ■費用について S3にCloudFrontを通すことで月20万ぐらい節約した話 - Qiita https://qiita.com/katsunory/items/2663baef6a14550078d9 S3から直接配信せずに、CloudFrontを挟むことで大幅に費用を削減できたという話 ただ、本当にCloudFrontを挟むだけで安くなるのかは疑問 単純にCloudFrontを挟むと、むしろS3からの直接配信より若干高額になるのでは ただし以下のサイトによると月の配信容量が150TBを超えるくらいからCloudFrontの方が安くなるらしいので、 上の話は相当な容量の動画を配信しているサイトのことなのかもしれない S3ウェブホスティングとS3 + CloudFront構成の料金比較 - Qiita https://qiita.com/yamamoto_y/items/c58ae2083a792d8b7b0f gzipを使うことで削減する方法はあるみたい [超簡単]cloud frontの料金を最大1/5に減らす節約方法 | YongJin Kim's Blog https://yongjinkim.com/%E8%B6%85%E7%B0%A1%E5%8D%98cloud-front%E3%81%AE%E6%96%99%E9%87%91%E3%82%92%E6... AWSのCloudFrontでアセットをHTTP2 & gzipで高速に配信する - Clueit Developersブログ http://cluex-developers.hateblo.jp/entry/cloudfront-with-http2-and-gzip 以下は公式ツールによる試算 見積もり： https://calculator.s3.amazonaws.com/index.html?lng=ja_JP#r=NRT&key=files/calc-2dbf71fce105f5593d... 上記の見積もりで、「Amazon S3 → データ転送」の「データ転送送信」を「10 GB/月」から変更してみる 10 GB/月 ... 月額 $ 162.29（デフォルト） 100 GB/月 ... 月額 $ 172.55 1000 GB/月 ... 月額 $ 275.15 10000 GB/月 ... 月額 $ 1301.15 上記の見積もりで、S3を変更せずに「Amazon CloudFront → データ転送の「データ転送送信」を「10 GB/月」から変更してみる 10 GB/月 ... 月額 $ 162.29（デフォルト） 100 GB/月 ... 月額 $ 172.64 1000 GB/月 ... 月額 $ 276.09 10000 GB/月 ... 月額 $ 1310.58 CloudFrontからの配信の方が、若干高額であることが判る また、月に1TBくらいの動画配信なら、大体10,000〜12,000円くらいであることも判る 以下のページで「1TBで月額$116」となっているので、公式の試算とも一致する オンデマンド動画配信のためのクラウド構成と料金試算例 | AWS https://aws.amazon.com/jp/cdp/cdn/ ■EC2の構築（準備） 203.0.113.1 ... ごく普通の設定でApache+PHPが動いているとする 203.0.113.9 ... アクセス元のIPアドレスとする http://203.0.113.1/ http://203.0.113.1/sample/ ※ブラウザでアクセスすると、当然ながら REMOTE_ADDR にはIPアドレス 203.0.113.9 が入る ■ロードバランサーを導入（準備） 「ロードバランサー → EC2」 という構成を作成。 http://develop-123456789.ap-northeast-1.elb.amazonaws.com/ http://develop-123456789.ap-northeast-1.elb.amazonaws.com/sample/ ※REMOTE_ADDR には 10.0.0.71 が入る（ロードバランサーのIPアドレス） HTTP_X_FORWARDED_FOR に 203.0.113.9 が入る（アクセス元のIPアドレス） ■CloudFrontを導入（キャッシュさせない設定でEC2に導入する場合） EC2（ロードバランサー）にCloudFrontを導入し、キャッシュさせずに配信する CloudFront → Create Distribution → Web → Get Started Origin Domain Name: 作成したロードバランサーを選択 Origin ID: 自動的に入力されるので変更せず 以下、キャッシュさせないための設定 Allowed HTTP Methods: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE Forward Headers: All （Allにすると、Minimum TTL・Maximum TTL・Default TTL は 0 として扱われるみたい） Forward Cookies: All Query String Forwarding and Caching: Forward all, cache based on all 2017年11月に確認すると、「Forward Headers」の設定が無くなっている 以下の設定のみでいいかも [AWS] Amazon CloudFrontのキャッシュ無効化(TTL設定) ｜ Developers.IO https://dev.classmethod.jp/server-side/aws-amazon-cloudfront-no-cache-by-ttl-setting/ Object Caching: Use Origin Cache Headers Minimum TTL: 0 Maximum TTL: 31536000 Default TTL: 86400 ↓ Object Caching: Customize Minimum TTL: 0 Maximum TTL: 0 Default TTL: 0 「Create Distribution」ボタンを押す Distributionの一覧が表示されるので、「Status」が「Deployed」に変わるのを待つ （完了までに15分程度かかる） 一覧からIDを選択し、その後表示される「Domain Name」にあるURLにアクセスすると、 オリジナルサーバと同じ内容が表示される。キャッシュされていないことも確認する （「Status」が「Deployed」に変わってからも、数分間はアクセスできなかった） http://123456789.cloudfront.net/ http://123456789.cloudfront.net/sample/ 可能なら、TTLは「0」よりも「1」の方がいいかも （0だとそのままオリジンにアクセスされるため、大量アクセスからの保護のためにも1秒にしておくといいみたい） AWS CloudFrontで極力キャッシュさせたくない時の話 - Qiita https://qiita.com/shogomuranushi/items/a2367350ea54a8f41257 ※REMOTE_ADDR には 10.0.1.120が入る（ロードバランサーのIPアドレスと思われる） HTTP_X_FORWARDED_FOR に 203.0.113.9, 204.246.186.45 が入る （1つ目はアクセス元のIPアドレス、2つ目はCloudFrontのIPアドレスと思われる） ■CloudFrontを導入（キャッシュする設定でS3に導入する場合） S3にCloudFrontを導入し、キャッシュしつつ配信する 今回参照するバケットは以下のとおり https://refirio-test.s3-ap-northeast-1.amazonaws.com/ CloudFront → Create Distribution → Web → Get Started Origin Domain Name: refirio-test.s3.amazonaws.com Origin ID: 自動的に入力されるので変更せず 「Create Distribution」ボタンを押す Distributionの一覧が表示されるので、「Status」が「Deployed」に変わるのを待つ （完了までに10分程度かかる） 一覧からIDを選択し、その後表示される「Domain Name」にあるURLにアクセスする Distribution ID: EVEVZHDVZEK34 ARN: arn:aws:cloudfront::123456789012:distribution/EVEVZHDVZEK34 Domain Name: 123456789.cloudfront.net オリジナルサーバと同じ内容が表示される https://refirio-test.s3-ap-northeast-1.amazonaws.com/images/brownie.jpg https://refirio-test.s3-ap-northeast-1.amazonaws.com/movie/flower.mp4 https://123456789.cloudfront.net/images/brownie.jpg https://123456789.cloudfront.net/movie/flower.mp4 キャッシュされていることも確認する（test1.txt を更新しても、CloudFront経由だと反映されない） https://refirio-test.s3-ap-northeast-1.amazonaws.com/test1.txt https://123456789.cloudfront.net/test1.txt ■CloudFrontのキャッシュを削除する場合 ※キャッシュの削除は「1ヶ月に1000回まで無料」となっている 頻繁に削除が必要な設計にしないように注意する CloudFront → 対象のIDを選択 → Invalidations → Create Invalidation 「Object Paths」に以下のように入力し、「Invalidate」をクリック Invalidateの一覧が表示されるので、「Status」が「Completed」に変わるのを待つ （完了までに1分程度かかるが、9割ほどは5秒程度で削除される） https://refirio-test.s3-ap-northeast-1.amazonaws.com/text/test1.txt https://123456789.cloudfront.net/text/test1.txt 「Object Paths」に以下のように入力し、「Invalidate」をクリック 「Object Paths」に以下のように入力し、「Invalidate」をクリック AWS CloudFrontのキャッシュを削除する - サーバーワークスエンジニアブログ http://blog.serverworks.co.jp/tech/2019/05/15/cloudfront-cache-clear/ 【朗報】Amazon CloudFrontのキャッシュ削除(Invalidation)が速くなりました【5秒で90%】 | Developers.IO https://dev.classmethod.jp/articles/cloudfront-fast-invalidation/ ■エラーのキャッシュ時間を変更する CloudFrontはデフォルト設定では、エラーを5分間キャッシュする つまりPHPの編集時などに500エラーを発生させてしまうと、修正しても5分間はアクセスできないままになる 開発初期は念のため、10秒程度にしておくといいかも キャッシュの設定は以下の方法で設定できる CloudFront → 対象のIDを選択 → Error Pages → Create Custom Error Response HTTP Error Code: 500 Internal Server Error Error Caching Minimum TTL (seconds): 任意の秒数 Customize Error Response: 専用のエラーページを表示したい場合に設定 500エラー以外も、同じ手順で設定できる Amazon CloudFront で HTTP 4xx 5xx ステータスコードのキャッシュ時間を変更する ｜ Developers.IO https://dev.classmethod.jp/cloud/aws/amazon-cloudfront-error-caching-minimum-ttl/ ■独自ドメインに対応させる CloudFront → 対象のIDを選択 → General → Edit Alternate Domain Names(CNAMEs) にドメインを設定する（例：www.refirio.net） 設定しないと以下のエラーになる キャッシュのタイミングによっては、しばらくアクセスできているように見えるかも ■ドメイン割り当て前のアクセステスト CloudFrontは固定IPアドレスを持たない よって、Windowsのhostsファイルを編集するなどしてCloudFrontにアクセスしたい場合、その時点のIPアドレスを調べる必要がある 例えばCloudFrontのURLが 123456789.cloudfront.net でブラウザから http://123456789.cloudfront.net/ でアクセスできる場合、nslookupコマンドを使って以下のようにすればCloudFrontのIPアドレスを調べることができる（digコマンドでも可） この場合、ロードバランサーは 203.0.113.1 と 203.0.113.2 と 203.0.113.3 と 203.0.113.4 のIPアドレスを持つ よって、Windowsのhostsファイルなどで C:/windows/System32/drivers/etc/hosts このように設定すると、http://refirio.net/ でアクセスしたときにCloudFront経由でアクセスできる （203.0.113.1 と 203.0.113.2 と 203.0.113.3 と 203.0.113.4 のどれを指定してもいい） エラーになる場合、「独自ドメインに対応させる」の設定を行なっているか確認する ■SSLに対応させる ※無料SSL証明書を実際に試したときのメモは「Certificate Manager」を参照 ACMで証明書を発行し、CloudFrontに設定する…という流れで設定できる CloudFrontとELB間をSSLで通信させる ｜ Developers.IO http://dev.classmethod.jp/cloud/aws/cloudfront_elb_ssl_traffic/ [ACM] AWS Certificate Manager 無料のサーバ証明書でCloudFrontをHTTPS化してみた ｜ Developers.IO https://dev.classmethod.jp/cloud/aws/acm-cloudfront-ssl/ ただし、現状色々と注意点があるみたい ・古い環境でアクセスできなくなる ・S3との連携には制限がある ・CloudFront の証明書は、バージニア北部リージョンに入れる必要がある ・CloudFrontとELBで同じFQDNを使う場合、ELB側のACMは自動更新できない恐れがある ・外部で購入したSSL証明書は、CDNでの使用が許されてるか要確認。オリジンのサーバ数だけライセンス購入が必要なことがある 管理画面から証明書を登録できない…と解説されていることがあるが、ごく最近の解説では触れられていない 今は大丈夫なのかも？ CloudFrontで独自ドメインのSSL設定する方法 | レコチョクのエンジニアブログ https://techblog.recochoku.jp/3181 以下、その他参考になりそうなページ 代替ドメイン名 (CNAME) を使用する - Amazon CloudFront https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html CloudFront に SSL 証明書を導入する際のポイントまとめ - Qiita https://qiita.com/koseki/items/4462b09f1527ad07bdce CloudFrontの下でWordpressを実行する時に色々ハマった話 前編 - Qiita https://qiita.com/kunitaya/items/1a78cd2d4d2971394e0d CloudFront × WordPressで格安高速エンジニアブログを作ってみた | TABI LABO TECH BLOG https://tech.tabilabo.co.jp/40/ [GitHub Pages] 独自ドメインをCloudFrontでSSL化 - onox blog https://onoxeve.com/posts/github-pages-ssl-certificate/ Route53でドメイン買ってACMでSSL証明書発行してCloudFrontでGithub Pageと買ったドメインと紐付けた - Qiita https://qiita.com/yamanoku/items/c4f9c28d79f981afc40f ■SSLにリダイレクトさせる httpでアクセスされたとき、httpsにリダイレクトする EC2側で「SSLか否か」を判定しようとしても、CloudFront以降はhttpでアクセスされることが多いので判定が難しい CloudFrontの設定で対応できる CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit 「Viewer Protocol Policy」を「Redirect HTTP to HTTPS」に変更 CloudFrontでhttpリクエストをhttpsにリダイレクトできるようになった - yoshidashingo http://yoshidashingo.hatenablog.com/entry/2014/03/06/144345 CloudFront とカスタムオリジンとの間の通信に HTTPS を必須にする - Amazon CloudFront https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-c... ■ヘッダ情報を転送 CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit 「Cache Based on Selected Request Headers」を「Whitelist」に変更 「Accept」「CloudFront-Forwarded-Proto」「Referer」を追加 （必要なら、さらに追加する） さらに、一覧上部のテキストボックスに「User-agent」を入力して「Add Custom >>」で追加 （設定していない場合、UserAgentは常に「Amazon CloudFront」になる） CloudFrontを導入してもUser-agentの値は書き換えられないようにする方法。 - Qiita https://qiita.com/kooohei/items/4dcdb506745a6a1eef66 ■Basic認証に対応 CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit 「Cache Based on Selected Request Headers」を「Whitelist」に変更 「Authorization」を追加 CloudFrontでベーシック認証 | TF Lab - クラウド開発記録 - https://lab.taf-jp.com/cloudfront%E3%81%A7%E3%83%99%E3%83%BC%E3%82%B7%E3%83%83%E3%82%AF%E8%AA%8D%E8%... ■バーチャルホストに対応 CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit 「Cache Based on Selected Request Headers」を「Whitelist」に変更 「Host」を追加 [新機能] Amazon CloudFrontでHostヘッダを転送する ｜ Developers.IO https://dev.classmethod.jp/cloud/cloudfront-host-header-forward/ ■POSTでエラーになる CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit Allowed HTTP Methods を GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE に設定する ■Cookieを有効にする CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit Forward Cookies を All に設定する ■画面が正しく表示されない ブラウザによっては一部画面のCSSが反映されない そもそも、今はキャッシュさせない設定のはずでは 外部ファイルを読み込めていない？以下が真っ白 http://www.refirio.net/wp-admin/load-styles.php?c=0&dir=ltr&load%5B%5D=dashicons,buttons,forms,l10n,login&ver=4.9 以下がより細かくキャッシュさせる設定みたい これで正しく表示された CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit Query String Forwarding and Caching を Forward all, cache based on all に設定する ■ログを記録する CloudFront → 対象のIDを選択 → General → Edit 一例だが、以下のように設定する しばらく待つと、S3にログが保存され始める Logging: On Bucket for Logs: ログ出力先のS3バケット Log Prefix: cf-logs/ Amazon CloudFront編〜アクセスログを取得してみよう！〜｜S3　バケット　ログ収集　CDN　使用方法 | ナレコムAWSレシピ https://recipe.kc-cloud.jp/archives/2624 ■タイムアウト時間を調整する Webアプリケーションからの巨大ファイルのアップロードなどで、処理がタイムアウトしてしまう問題について ・PHPの設定を変更しても、その上位で60秒の制限があるので解除が必要。 ・nginxに制限があるが、設定を変更することで600秒などに伸ばすことが可能。 ・ロードバランサーにも制限があるが、設定を変更することで600秒などに伸ばすことが可能。 ・CloudFrontにも制限があるが、デフォルトで30秒。これは60秒以上に伸ばすことができない。 いますぐ使う CloudFront - Qiita https://qiita.com/sasasin/items/0f0ec1a90af6295589f9 Amazon CloudFrontのオリジンタイムアウトが変更できるようになりました ｜ Developers.IO https://dev.classmethod.jp/cloud/aws/change-cloudfront-origin-timeouts/ ディストリビューションを作成または更新する場合に指定する値 - Amazon CloudFront https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-spe... 対処1: AWSに例えば600秒に伸ばすように申請する（可否は要検証だが、無限に伸ばせるわけでは無いかもしれないので注意） 対処2: CloudFrontを外す 対処3: 一部の処理のみ、CloudFrontを経由しない（あまり良い方法では無いかもしれない） ■CloudFrontの経由を強制 ※未検証 【アップデート】Amazon CloudFront を経由しないアクセスのブロックが簡単になりました | DevelopersIO https://dev.classmethod.jp/articles/amazon-cloudfront-managed-prefix-list/ ■署名付きURLで限定配信 CloudFrontの署名付きURLでS3にアクセスする方法 - Qiita https://qiita.com/jeayoon/items/c148a8637a177c0f8c9f CloudFront+S3で署名付きURLでプライベートコンテンツを配信する http://dev.classmethod.jp/cloud/aws/cf-s3-deliveries-use-signurl/ Amazon CloudFront で HLS動画のプライベートオンデマンド配信を行う方法 http://akiyoko.hatenablog.jp/entry/2015/08/24/192618 URLに特定の文字列が含まれていないとアクセスできないようにする また、そのURLにはアクセスできる期間も指定できる コンテンツの限定配信に使える 以下の手順はCloudFrontを無視してS3に直接アクセスできるので、できればそちらも制限したい（CloudFront側にそのような設定がある） 以下のバケットを参照するものとする https://develop-123456789.ap-northeast-1.elb.amazonaws.com/ CloudFront → Create Distribution → Web → Get Started Origin Domain Name: develop-123456789.s3.amazonaws.com Origin ID: 自動的に入力されるので変更せず 「Create Distribution」ボタンを押す Distributionの一覧が表示されるので、「Status」が「Deployed」に変わるのを待つ （完了までに10分程度かかる） https://123456789.cloudfront.net/brownie.jpg CloudFront → 対象のIDを選択 → Behaviors → 対象のオリジンを選択 → Edit 以下のように変更して「Yes, Edit」をクリックする Restrict Viewer Access (Use Signed URLs or Signed Cookies): Yes … アクセスの際に署名付きURLか署名付きCookieを求める https://123456789.cloudfront.net/brownie.jpg これだとアクセスできないだけなので、署名付きURLを使えるようにする rootアカウントでAWSコンソールにサインインする マイセキュリティ資格情報 → CloudFrontのキーペア → 新しいキーペアの作成 キーペアが作成されるので、 「プライベートキーファイルのダウンロード」と「パブリックキーファイルのダウンロード」 からそれぞれのキーをダウンロードしておく 今回は以下のファイルがダウンロードできた プライベートキーファイル ... pk-APKAIRZZSSNKVA5FUH6X.pem パブリックキーファイル ... rsa-APKAIRZZSSNKVA5FUH6X.pem ダイアログを閉じるとキーペアの一覧が表示され、作成日やアクセスキーIDなどを確認できる アクセスキーIDは「APKAIRZZSSNKVA5FUH6X」となっていた（後で使用する） 検証のために、以下のPHPプログラムを作成 署名付きURLを発行し、10秒間だけ test1.txt にアクセスできるようにする アクセスキーとシークレットアクセスキーは無くても実行できた。別途プライベートキーを使っているからだと思われる プライベートキーは上でダウンロードしたもの 署名付きURLでアクセスできるようになった バケットポリシーのアクセス制限については要確認 https://develop-123456789.s3-ap-northeast-1.amazonaws.com/test1.txt https://123456789.cloudfront.net/test1.txt https://123456789.cloudfront.net/test1.txt?Expires=1587352798&Signature=dt3PhFcUqsRyDgIaYCMOseAa... 動画の配信もテスト 特に問題は無さそう https://develop-123456789.s3-ap-northeast-1.amazonaws.com/test/1.mp4 https://123456789.cloudfront.net/test/1.mp4 https://123456789.cloudfront.net/test/1.mp4?Expires=1587353157&Signature=izvCUYMq4NwgA2HfxyaMIAI... 機能しているが、S3へのリダイレクト扱いになっている …が、これは24時間待てば自動で解決した S3+CloudFrontでS3のURLにリダイレクトされてしまう場合の対処法 | Developers.IO https://dev.classmethod.jp/articles/s3-cloudfront-redirect/ ■レスポンスヘッダの設定 ※未検証 L@EとCF2が不要に？！CloudFront単体でレスポンスヘッダーが設定できるようになりました | DevelopersIO https://dev.classmethod.jp/articles/cloudfront-support-response-headers-policies/ ■データ転送量の確認 CloudFront → Reports & analytics → Usage で、リクエスト数や転送量などを確認できる また詳細を確認したい CloudFront 使用状況レポート - Amazon CloudFront https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/usage-charts.html ■WordPressでCloudFrontを使う場合の参考ページ WordPressサイトをCloudFrontで配信する - Qiita https://qiita.com/Ichiro_Tsuji/items/38592e737257cb45ca13 WCT2016:WordPressのCDN設定/Cloudfront レベル2 | J-Stream CDN情報サイト https://tech.jstream.jp/blog/meeting/wct2016cloudfront-l2/ WCT2016:WordPressのCDN設定/Cloudfront レベル3 | J-Stream CDN情報サイト https://tech.jstream.jp/blog/meeting/wct2016cloudfront-l3/ ■大量アクセスを捌くときの参考ページ Amazon CloudFront の デフォルト上限値が更に大幅にアップしました！(2016秋) ｜ Developers.IO https://dev.classmethod.jp/cloud/aws/cloudfront-limit-update-201610/ CloudFrontを使ったサイト公開のハマりどころ | HAWSクラウドサービス http://haws.haw.co.jp/tech/cloudfront-site-publish/ Cloud front limit increase https://www.slideshare.net/AmazonWebServicesJapan/cloud-front-limit-increase