【朗報】Amazon CloudFrontのキャッシュ削除(Invalidation)が速くなりました【5秒で90%】 | DevelopersIO
ども、大瀧です。 本日、AWSのCDNサービスCloudFrontのキャッシュ無効化(Invalidation)高速化のアナウンスがありました。 AWS Developer Forums: Announcing Fast Invalidations 試してみた様子をレポートします。 CloudFrontのキャッシュ削除にかかる時間 CloudFrontのキャッシュ削除は、コンテンツのパス単位(ワイルドカード指定も可)で従来10〜15分程度かかっていたものです。今回のアップデートで、CloudFrontエッジロケーション(キャッシュサーバー)の90%には5秒で、全体には1分で削除が行われるようになりました。同時リクエスト数や料金などのルールは従来通りです。 では、手元のCloudFront Distributionで試してみます。キャッシュ設定は以下の通り、60秒キャッシュする状態(Defa
React RouterをAmazon S3で利用する
React-Routerをルーティングに利用した、SPAを Amazon S3でホスティングした際にハマったので。 多くのReactアプリケーションのルーティングでReact-Routerが使われているかと思うのですが、 Amazon S3にホスティングして、アクセスしてみると、残念ながら404エラーになってしまいます。 Amazon S3がバケット上にファイルの存在を確認できないため、404になっているのでした。 対応としては、3つのオプションがあるのかなと思っていて、 (他アイデアあれば教えていただきたい) NginxなどのProxyサーバを立てて、index.htmlへ遷移させる React-Rotuer hashHistoryを利用する Amazon CloudFrontを利用する 今回は簡潔にAWS上だけでセットアップしたい思いがあったので、 Cloud Frontを利用すること
Deploying create-react-app to S3 or CloudFront
The React CLI tool, create-react-app, helps front end developers finally focus on building applications, rather than configuring them. Gone are the days of searching through the dozens of boilerplate and starter apps to get off the ground. For the modest price of accepting some opinionated (but sensible) configuration settings, you’re off to the races. Once you’ve kicked off a new application, npm
AWSにおける静的コンテンツ配信パターンカタログ（アンチパターン含む） | DevelopersIO
独自ドメインSSLだとCloudFront使えないから横綱無理だよねー、という話がありました。うん、確かにそうでした、執筆時点では…！ 本日2013/06/12、CloudFrontの独自ドメインSSL対応が発表（英語・日本語）されましたので、みなさん揃って横綱になればいいと思います。 よく訓練されたアップル信者、都元です。AWSを利用して構築した環境から、クライアント（モバイルやブラウザ等）に対してHTTPを使って静的なコンテンツを配信したいケースって、多いですよね。多いというか、むしろどんなシステムにも多かれ少なかれ、静的なコンテンツ配信があると思います。 スケーラビリティ・柔軟性・可用性・パフォーマンス・コスト 静的なコンテンツというのは、コンテンツをリクエストに応じて生成したりせず、完成品としてのファイルが手元にある状態です。例えば、多くのWebシステムにおいて、ほとんどの画像やJ
Railsのassetsをs3に格納し、cloudfrontから配信する
今まで使おう使おうと思いつつ、さほどPVがあるサイトの運営をする機会がなかったため、 やってなかったcloudfrontを満を持して設定してみました。 （とりあえず入れとけ的な話もよく聞きますし…） 今回は、railsのassetsをS3に置いて、cloudfrontから配信するようにしました。 結果、噂通りすごく簡単に導入できたのですが、調査に割りと時間がかかったのでメモしておきます。 Herokuのドキュメントを取っ掛かりにしました。 概要は以下です。 assets格納用のS3バケットを作る cloudfrontのdistributionを作成し、S3をorigin serverに設定 railsプロジェクトに設定追加 Gemfileに、gem "asset_sync" を追加 config/initializersに、asset_sync.rb を作成 (カスタム設定の場合） con
RailsにCloudFront噛ませたら10倍速くなった。RailsのエッジサーバとしてのCloudFrontの有用性について - Qiita
RailsにCloudFront噛ませたら10倍速くなった。RailsのエッジサーバとしてのCloudFrontの有用性についてRailsCloudFront RailsのエッジサーバとしてCloudFront噛ませたら10倍以上速くなりました。 構成 example.com(Route53) -> CloudFront -> Rails App server 単にappのdomainからcloudfrontを見るように設定し、Rails App Serverをオリジンとして設定。 今回は適当運用なのでLBすら置いてません。 しかし、後述するように冗長性は（比較的）保たれています。 CloudFrontのいいところ route別でオリジン分けたり出来る route別でキャッシュポリシー変えたり出来る POSTのパススルーが出来る（！） めっちゃエッジサーバ多い（Brazilとかでも速い）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
