画像ソース：Pikisuperstarによって作成されたインフォグラwww.freepik.com

コンテンツ配信ネットワーク(CDN)は、一般的に静的要素の読み込みを高速化するためにサイトやアプリケーションで使用されます。 これは、世界のさまざまな地域にあるCDNサーバー上のファイルをキャッシュすることによって達成されます。 CDNを介してデータを要求すると、ユーザーは最寄りのサーバーからデータを受信します。

Cdnとその機能の背後にある基本的な原則は、それらのすべてでほぼ同じです。 ファイルの要求を受け取ったCDNサーバーは、元のサーバーから一度ファイルを受け取り、それをユーザーに転送し、そのコピーを一定期間キャッシュします。 データのさらなる要求は、キャッシュを使用して処理されます。 すべてのCdnには、ファイルのプリロード、キャッシュクリア、キャッシュ保持時間などのオプションがあります。

様々な理由から、自分自身のCDNを構築する必要があるかもしれないので、それを実現する方法について以下のガイドを提示します。

あなた自身のCDNが必要なのはいつですか？

あなた自身のCDNを作成する必要があるかもしれない状況を見てみましょう:

• そのチャレンジしているうちはお金も手頃な価格のようにソリューションBunnyCDN末は海外では数百ドル/月
• たいときに常設キャッシュが必要な保証帯域の資源
• 既存CdnいPoPs目標とする領域
• 必要な特別コンテンツの調達や配信技術に関する設定項目
• したい速度までの配送の動的コンテンツィへのユーザーの
• ご当該第三者CDNsが不正に収集、利用ユーザーデータ(こんにちはあり、サーバーな

他のほとんどのケースでは、既存の既製のソリューションを使用する方が実行可能です。

独自のCDNを作成しましょう

単純なコンテンツ配信ネットワークを構築するには、次のものが必要です:

• ドメイン名またはサブドメイン
• 異なる地域にある最低二つのサーバー。 サーバは、専用または仮想
• geoDNSツールにすることができます。 これにより、ドメインにリクエストを送信するユーザーは、最寄りのサーバー

ドメインの登録と注文サーバー

ドメイン名の登録は簡単です。 CDNの場合は、次のようなサブドメインも使用できますcdn.domainname.comこれは次の例の場合です。

サーバーに関しては、ターゲットオーディエンスがいる地域や国でそれらをレンタルする必要があります。 あなたのプロジェクトがintercontinentalの場合は、OVH、Leaseweb、100tb（専用サーバーの場合）、Vultr、DigitalOcean（仮想サーバーとクラウドサーバーの場合）など、世界中のサーバーを提供するホスティングプロバイダーの中から選択すると便利です。

私たちのプライベートCDNのために、異なる大陸に三つの仮想サーバーを注文しましょう。 Vultrは、25GB SSDスペースと1TBのトラフィックをmonth5/月で提供しています。 インストール中に、最新のDebianを選択します。 ここに私たちのサーバーがあります:

• フランクフルト、ip: 199.247.18.199

• シカゴ,ip:149.28.121.123

• シンガポール、ip: 157.230.240.216

geoDNSの設定

ドメインまたはサブドメインに要求を送信する際にクライアントが適切な(最も近い)サーバーに送信されるようにするには、geoDNS機能を備えたDNSサー

:

1. クライアントのIP（DNS要求を送信した場合）または要求の処理に使用される再帰DNSサーバーのIPを取得します。 一般的に言えば、そのような再帰的なサーバーは、通常、インターネットプロバイダのDNSsです。
2. クライアントのIPによって、国または地域を識別します。 この操作では、供給不足で利用可能なGeoIPデータベースを使用する必要があります。 まともな無料のオプションもあります。
3. クライアントの場所に応じて、geoDNSは最も近いCDNサーバーのIPアドレスを返します。

geoDNS機能を備えたDNSサーバーは、自分で構築できるものですが、世界中のサーバーとすぐに使えるAnycastオプションを備えた既製のソリューションを使用する方が:

• ClouDNS、from9から。95/月、GeoDNSパッケージ、一つのDNSフェイルオーバーは、デフォルトで提供されています
• Zilore、2 25/月から、DNSフェイルオーバーが含まれています
• Amazon Route53、3 35/月から50万ジオリク DNSフェイルオーバーは別途料金
• DNS Made Easy,$125/月から,10個のDNSフェイルオーバー
• Cloudflare,Geoステアリング機能はエンタープライズパッケージで提供されています

geoDNSを注文するときは、パッケージに含まれるリクエスト数に注意を払い、実際のリクエスト数が期待を大幅に上回る可能性があることに注意する必要があります。 何百万の仕事に網のクローラー、走査器、spammersおよび他のdevilryがある特定の時点である。

ほとんどすべてのDNSサービスには、CDN構築-DNSフェイルオーバーのための便利な機能が含まれています。 これを使用すると、サーバーがダウンした場合にシステムが自動的に代わりに作業サーバーにクライアントをリダイレクトするように、アクティCDNでは、ClouDNSとそのGeoDNSパッケージを使用しましょう。

プロファイルで、新しいDNSゾーンを追加し、ドメイン名を指定します。 サブドメインを使用していて、メインドメインが使用中の場合は、ゾーンを追加した直後に既存のDNSレコードを追加することを忘れないでください。 次のステップでは、CDNドメイン/サブドメイン用に複数のaレコードを作成し、それぞれが指定された地域に使用されます。 大陸または国を地域として指定することができ、米国およびカナダでは小地域オプションを使用できます。

この例では、CDNは次のコマンドで動作します。cdn.sayt.in サブドメイン。 を追加しました。sayt.in ゾーンでは、サブドメインの最初のAレコードを作成し、すべてのNAクライアントをChicagoサーバーに指示します:

他のリージョンに対してこの手順を繰り返し、デフォルトのリージョンに対して1つのレコードを作成することを忘れな 最終結果は次のようになります:

最後のデフォルトレコードは、すべての不特定の地域（ヨーロッパ、アフリカ、衛星インターネットユーザーなど）か）は、フランクフルトのサーバーに送られます。

これで、基本的なDNS設定は終了です。 残っているのは、registrar webサイトに移動し、現在のネームサーバーをClouDNSが提供するものに置き換えることだけです。 彼らが更新されている間、我々はサーバーを設定します。

SSL証明書のインストール

私たちのCDNはHTTPSを使用して動作しますので、ドメインまたはサブドメインのSSL証明書を既に持っている場合は、/etc/ssl/yourdomain/ディレ

証明書がない場合は、Let’S Encryptから無料で入手できます。 ACMEシェルスクリプトは素晴らしいオプションです。 それはユーザーフレンドリーなクライアントを持っており、より重要なのは、ClouDNSによるAPIを使用してDNS経由でドメイン/サブドメインの検証を実行するこ

acme.sh 1つのサーバーのみ—ヨーロッパのサーバー（199.247.18.199）から、証明書は他のすべてのサーバーにコピーされます。 インストールするには、次のコマンドを実行します:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

インストール中に、証明書の自動更新のためのCRONタスクが作成されます。

証明書の発行時のドメイン検証はAPIを使用してDNS経由で実行されるため、ClouDNSプロファイルのReseller APIで、新しいAPIユーザーを作成し、パスワードを指定します。 結果のauth-idとパスワードを次のファイルに入力します。~/。acme.sh/dnsapi/dns_cloudns.sh （と混同しないようにdns_clouddns.shコメントを解除して編集する必要がある行は次のとおりです:

CLOUDNS_AUTH_ID=<auth-id>CLOUDNS_AUTH_PASSWORD="<password>"

それでは、cdnのSSL証明書の発行を要求しましょう。セイトで

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

将来の使用のために、パラメータでは、証明書を更新するたびに自動構成を再起動するコマンドを残しました。

証明書の取得には最大2分かかる場合がありますので、中断しないでください。 ドメイン検証エラーが発生した場合は、コマンドを再度実行してみてください。 最後に、証明書がダウンロードされた場所を確認します。

これらのパスを覚えておいて、証明書を他のサーバーにコピーするときに指定する必要があり、サーバー設定で指定する必要があります。 -証明書の更新中に完全に構成されたサーバーでは発生しません。SSL証明書については、証明書パスを保存している他の2つのサーバーにコピーするだけです。 各サーバーに同一のディレクトリを作成し、証明書ファイルをコピーします:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

証明書の更新を自動化するには、両方のサーバーで毎日のCRONタスクを作成する必要があります。 以下は、CRONジョブに追加する必要があるコマンドです:

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload</pre>

リモートオリジンサーバーへの接続には、パスワードを入力せずにキーでアクセスする必要があることに注意してくださ それを作成することを忘れないでください。

nginxのインストールと設定

静的コンテンツ配信のために、キャッシュプロキシサーバーとして構成されたNginxを使用します。 パッケージのリストを更新し、3つのすべてのサーバーにインストールします:

root@cdn:~# apt updateroot@cdn:~# apt install nginx

デフォルトの設定の代わりに、以下のものを使用してください：

nginx。conf

user www-data;worker_processes auto;pid /run/nginx.pid;events { worker_connections 4096; multi_accept on;}http { sendfile on; tcp_nopush on; tcp_nodelay on; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; access_log off; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; gzip_comp_level 6; gzip_proxied any; gzip_vary on; gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml; gunzip on; proxy_temp_path /var/cache/tmp; proxy_cache_path /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d; proxy_cache_bypass $http_x_update;server { listen 443 ssl; server_name cdn.sayt.in; ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer; ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key; location / { proxy_cache cdn; proxy_cache_key $uri$is_args$args; proxy_cache_valid 90d; proxy_pass https://sayt.in; } }}

configで、編集してみましょう:

• max_size—キャッシュサイズが利用可能なディスク領域を超えない
• inactive—要求されていないキャッシュデータの保持時間
• ssl_certificateおよびssl_certificate_key—SSL証明書とキーへのパス
• proxy_cache_valid—キャッ9288>proxy_pass—cdnがキャッシュのためにデータを要求するオリジンサーバーのアドレス。 私たちの例では、それは次のとおりですsayt.in

ご覧のように、それはロケット科学ではありません。 唯一の難点は、inactiveパラメータとproxy_cache_validパラメータの類似点を考慮すると、保持時間を設定することです。 詳しく見てみましょう。 Inactive=7dおよびproxy_cache_valid=90dで何が起こるかは次のとおりです:

• 要求が7日以内に繰り返されない場合、データはキャッシュから削除されます
• 要求が7日の間に一度でも繰り返される場合、キャッシュは90日後に期限切れとみなされ、次の要求はnginxにオリジンサーバー

からnginxで更新されます。confが処理され、設定をリロードします:

root@cdn:~# service nginx reload

だから、私たちのCDNは使用する準備ができています！ $15/月のために、私たちは三つの大陸とトラフィックの3TBのPoPsを得ました：各地域のための1TB。

CDNの確認

別の場所からCDNへのpingを見てみましょう。 この場合、pingサービスはすべて行います。

結果は良いです。 次に、testという名前のテスト画像を配置しましょう。メインサーバー上のjpgとCDNを介してロードする速さを確認します。 言って完了しました。 ローディングは速いです。

CDNポイントのキャッシュをクリアする必要がある場合に備えて、小さなスクリプトを作成しましょう。

purge.sh

#!/bin/bashif then echo "Purging all cache" rm -rf /var/cache/cdn/*else echo "Purging " FILE=`echo -n "" | md5sum | awk '{print }'` FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE} rm -f "${FULLPATH}"fi

サーバー上のすべてのキャッシュをクリアするには、スクリプトを実行するだけです。 いくつかのファイルをパージする必要がある場合は、そのパスを指定するだけです:

root@cdn:~# ./purge.sh /test.jpg 

すべての場所でキャッシュを消去するには、すべてのCDNサーバーでスクリプトを実行する必要があります。結論の代わりに

最後に、私がすでにクリアした落とし穴に陥るのを避けるために、いくつかの有用なヒントを与えたいと思います:

• 将来のCDNの実行可能性と保守コストを考慮します。 ほとんどの場合、安価なCDNを購入する方がはるかに効率的で簡単ですが、これはより安定しており、品質が向上する可能性が最も高いでしょう。
• CDNのフォールトトレランスを向上させるには、DNSフェイルオーバーを設定することをお勧めします。 DNSのレコードコントロールパネルでこれを行うことができます。
• カバー範囲の広いウェブサイトは多数のポップを必要としますが、過度に熱心になることはありません。 ほとんどの場合、6-7の場所（ヨーロッパ、北米（東）、北米（西）、シンガポール、オーストラリア、香港、または日本）にサーバーがある場合、ユーザーはCDNと有料のCDNの違いに気付か
• ホスティングプロバイダーは、Cdn用のレンタルサーバーを使用できないことがあります。 そのため、CDNサービスを作成する場合は、ホスティングプロバイダーの利用規約を必ずお読みください。
• 海底ケーブルマップを研究して、大陸がどのように接続されているかを理解し、CDNを構築する際にこの知識を使用します。
• 別の場所からサーバーにpingを実行してみてください。 このようにして、Popに最も近い地域を見つけることができ、GeoDNSを設定するのに役立ちます。