Amazon cloud frontcdnの加速原理と構成チュートリアル: あなたのサイトをユーザーの家の前に「移動」します
想像してみてください。あなたは人気のあるネットショップを開いて、サーバーが海外に設置されています。ある日、東京のユーザーがあなたのサイトを開設して、太平洋を越えて、いくつかの国際海底光ケーブルノードを通ってあなたのサーバーに到着することを要求して、サーバーが処理してから元の道に戻る。今回の「長距離奔走」は、webページのロードに5秒かかった。
「Webページのロードが3秒を超えると、ユーザーが半分になる」という今日、この遅延は致命的である。
どうやって解決しますか?答えは
CDN (コンテンツ配信ネットワーク)
。クラウドコンピューティングの分野では、Amazonクラウドフロントは最高レベルの「加速特急」です。今日は大きな口語で、クラウドフロントの加速原理を徹底的に掘り起こして、手を持って実戦的な配置を完成させます。
一、核心原理: クラウドフロントはどのように遅延を撲滅しますか?
クラウドフロントのコアロジックを一言で要約すると、次のようになります
空間で時間を変えて、静的な資源を「分身」にして、ユーザーに一番近いところに行きます。
これを実現するために、アマゾンは世界で巨大なネットワークを作った。このネットワークは三つの核心概念に支えられている
[ソースステーション (S3/EC2)] <---> [地域レベルのエッジキャッシュ (area Edge)] <---> [エッジサイト (Edge Location)] <---> [エンドユーザー]
ソースステーション (Origin): Amazon S3バケットやEC2サーバなど、元のwebサイトのデータを保存する場所。
エッジサイト: 世界中の大都市に導入されたデータセンター (世界中の数百点)。複雑なビジネスコードを実行せず、買いだめ (キャッシュデータ) ということだけをしています。
地域レベルのエッジキャッシュ: ソースサイトとエッジサイトの間にある「大きな倉庫」。エッジサイトが品切れになったときは、ソースステーションを直接驚かせるのではなく、まずここに行って、ソースステーションのストレスをさらに軽減します。
ユーザーがクラウドフロントを構成したwebサイトにアクセスすると、何が起こるのでしょうか?
最寄りのアクセス: 東京のユーザーがリクエストを開始し、クラウドフロントはスマートDNS解析を通じて、直接にリクエストを東京のローカルのエッジサイトに導いています。
キャッシュヒット (Cache Hit): このエッジサイトに、ユーザーが見たい画像 (例: logo.Exe) がキャッシュされている場合は、画像秒をユーザーに直接渡します。時間は数ミリ秒しかないかもしれません。ウェブサイトは秒で開けます。
キャッシュバック (Cache Miss): このサイトが初めて訪問された場合、この画像がなければ、アマゾン内部のバックボーンに向かってソースサイトに「商品を要求」し、画像を入手した後ユーザーに送りながら、自分で1部 (キャッシュ) 保存して、次のものに便利です
京のユーザーが取りに来ます。
静的ファイル (画像、CSS、JS) を高速化するだけでなく、クラウドフロントは高速化します
動的リクエスト
(ログイン、APIインタフェースなど)。動的データはキャッシュできませんが、ユーザーは最も近いエッジサイトからアクセスできます
AWSが独自に構築したグローバル光ケーブルのバックボーン網
。これは車を「高規格専用高速道路」に運転し、公衆網の渋滞や回り道を徹底的に避けたようなものです。
二、実戦チュートリアル: あなたの最初のクラウドフロント配布を手で配置します
うそばかり言っています。次に、最も一般的なシナリオである「クラウドフロントを使用してAmazon S3バケットの静的なwebサイト/画像を高速化する」を例に、完全な構成プロセスを実行します。
ステップ1: 配布を作成する
AWSマネジメントコンソールにログインし、検索バーにCloudFrontと入力して、クリックして入ります。
右上にある「Createわし」ボタンをクリックします。
ステップ2: ソースステーション設定の構成
Origin domain (ソースドメイン名): 入力ボックスをクリックすると、AWSは現在のアカウントのリソースを自動的にリストします。準備したS3バケット (my-website-bucket.s3.amazonaws.comなど) を選択します。
Origin access (ソースアクセス権): Origin access control settings (OAC) を選択することを強く推奨します。💡ピット回避ガイド: 多くの初心者は図の便宜のために、S3バケットを「完全公開」としている。これはとても危険だ! OACを選択すると、あなたのS3バケットはプライベートのままにすることができます、それを読むことができるのはクラウドフロントだけです。ユーザーはCDNを迂回して直接あなたのS3トラフィックを磨くことができず、安全でコストも節約できる。
Create new OCIをクリックして、デフォルトの推奨構成を使用して制御ポリシーを作成します。
ステップ3: デフォルトの動作を設定する
この部分はCDNがユーザーの要求をどのように処理するかを決定します
Viewerプロトコルポリシー: Redirect HTTP to HTTPSを選択します。現在のwebサイトのセキュリティ第一は、安全でないHTTPトラフィックを自動的に安全なHTTPSに変換する。
Allowet HTTPメソッド (許可されたHTTPメソッド): 静的な加速だけであれば、GET、HEADを選択すればよい動的APIが混在している場合は、GET、HEAD、OPTIONS、put、POST、パッチを選択しますDELETE。
Cache key and
Origin requests (キャッシュキーとソース要求): デフォルトを保持することを推奨します。キャッシュポリシー (キャッシュポリシー) で、cachingoスタイピング (キャッシュの最適化) を選択します。これはAWSが公式に構成したベストプラクティスで、GzipとBrotli圧縮を自動的にオンにして、コードファイルの体積を70% 以上削減し、転送を高速化します。
ステップ4: 設定と代替ドメイン名を設定します
プライスクラス (価格階層): あなたのビジネスがグローバル指向の場合は、すべてのエッジサイトを使用します。予算が限られていて、ユーザーが主に欧米にいる場合は、より安い階層を選ぶことができる。
Alternate domain name (CNAME): cdn.yourdomain.comなど、自分の美しいドメイン名を入力します。
Custom SSL certificate: 自分のドメイン名を使っている以上、証明書を配布する必要があります。次のRequestスケルトンをクリックすると、AWSスケルトンマネージャ (ACM) からSSL証明書を無料で申請できます。申請が成功したらページを更新して選択します。
Default root object (デフォルトのルートオブジェクト): 静的なwebサイトの場合は、index.htmlを入力します。
間違いがないことを確認したら、一番下のをクリックしてください
Createわし
。完成しましたAWSはあなたの配布をグローバルに導入し始め、ステータスはになります
配置
。約3分から5分かかります。
Enabled
時、あなたは形を得ました。
D111111abcdef8.cloudfront.net
の公式加速ドメイン名。
ステップ5: 重要な終わり: S3バケットポリシーの更新
次のステップでOACを選んだことを覚えていますか?この時点では、クラウドフロントは権限を作成していますが、S3バケットに「ドアを開けて接客」しなければなりません。
クラウドフロントで成功したヒントページを作成すると、目立つ黄色のヒントが表示され、Copy policy (ポリシーのコピー) をクリックします。
S3バケットに移動し、Permissions (権限) タブをクリックします。
Bucket policy (バケットポリシー) を見つけ、「編集」をクリックして、先ほどコピーしたJSONコードを貼り付け、保存します。
今、あなたのドメイン名プロバイダ (例えばGoDaddy、阿里雲、DNSPod) に行って、あなたのサブドメイン名 (例えば
Cdn.yourdomain.com
) を作る
CNAMEレコード
、クラウドフロントがあなたに与えたものを指します
.クラウドフロント
ドメイン名です。
三、高度な調整とお金を節約するハッカー技術
配置ができたのは合格しただけで、実際の業務で早くてお金を節約するには、次の3点を知っていなければならない
1.キャッシュ更新の芸術
Webサイト上の画像やJSファイルを更新したとき、クラウドフロントのキャッシュはまだ期限が切れていない (TTLは期限が切れていない) 場合、古いユーザーがアクセスしたのはまだ古いバージョンです。
暴力的な解法: cloudfrontsideコンソールの「Invalidations」タブに行って、更新タスクを作成し、/* (ステーション全体を更新) または/images/* と入力します。これにより、グローバル・エッジ・サイトはキャッシュを削除し、ソースに戻ります。
優雅な解法 (推奨): フロントエンドのエンジニアリングにバージョン番号やファイルHashを入れる。たとえば、画像を更新するときは、logo.Exeを上書きせずに、logo _ 2.pngという名前を付けます。これにより、キャッシュを手動で更新する必要はなく、古いキャッシュは無効にならず、新しい要求は自動的に新しいファイルを実行し、ソースステーションに非常に友好的である。
2.キャッシュ破壊と回復率を警戒する
CDNがお金を節約する前提は
キャッシュヒット率が高い
。要求ごとにソースステーションに戻ってデータを取得しなければならない場合、CDNは一つの飾り物になって、流量料金を追加で2つ負担する (ソースステーションからCDNへのCDNからユーザーへ)。
キャッシュキーに頻繁に変更されるQuery String (タイムスタンプなど) を含まないようにしますか?t = 123456)。CDNは、要求ごとに新しいファイルであると考え、狂気の回復を引き起こした。
3.クラウドフロントスケールでエッジロジックを処理する
異なる国のユーザーに異なる言語のページを見せたり、URLを書き換えたりしたい場合があります。これまでは、Nginxなどのサーバにルールを書かなければなりませんでした。今、あなたは利用できます。
エッジ計算
。エッジサイトでは、非常にシンプルなJavaScriptコードを何行か直接実行して、要求がまだソース駅前に届いていないうちに需要を処理して、スピードが速くて飛び、多額のサーバーの計算費用を節約することができる。
結語
今のこの一秒の遅延が長いインターネット時代に、Amazon cloud frontは技術コンポーネントだけではなく、ユーザー体験の「堀」です。
資源を合理的に世界各地のエッジサイトに配布することで、あなたのサイトに翼をつけて、秒を実現するだけでなく、強固な盾のようにあなたの発信元サーバのために大量の同時ストレスを遮断します。本論文の手順に従ってOACを踏むだけです。
権限とキャッシュ戦略のすべての穴は、高レベルのグローバルレベルが加速しているように見えるが、実際には十数分の配置工夫にすぎない。
