静的コンテンツの配信-ミリ秒単位の請求

8年前、私は静的コンテンツの配布を加速することについての記事を書きました。それはいくつかのhabrachitelamiに訴え、長い間関連性を保ちました。



そのため、すでに機能しているものを迅速に加速すると同時に、最終的に何が起こったのか経験を共有することにしました。 もちろん、 HTTP / 2が不要なレーキについて説明します。8x1TbSATA SSDの代わりに7.6Tb NVMe SSDを購入する理由と、他の多くの高度な専門情報。



コンテンツの保存と配信は2つの異なるタスクであり、配信（高度なキャッシュ）についてのみ説明することにすぐに同意しましょう。



鉄から始めましょう...

NVMe SSD

既に理解したように、キャッシュの保存には最新の7.68 TB SSD HGST Ultrastar SN260 {HUSMR7676BHP3Y1} NVMe、HH-HL AICを使用します。 ねじテストは、マーケティング資料ほど美しいものではありませんが、非常に楽観的です

[root@4 www]# hdparm -Tt --direct /dev/nvme1n1 /dev/nvme1n1: Timing O_DIRECT cached reads: 2688 MB in 2.00 seconds = 1345.24 MB/sec Timing O_DIRECT disk reads: 4672 MB in 3.00 seconds = 1557.00 MB/sec [root@4 www]# hdparm -Tt /dev/nvme1n1 /dev/nvme1n1: Timing cached reads: 18850 MB in 1.99 seconds = 9452.39 MB/sec Timing buffered disk reads: 4156 MB in 3.00 seconds = 1385.08 MB/sec
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、「自分用」にサイズとメーカーを選択し、SATAインターフェイスを検討することもできますが、私たちは何のために努力すべきかについて書いています:)



それでもNVMeを選択した場合、ネジ情報を取得するには、nvme-cliパッケージをインストールし、「主力製品」の特性を確認してください

 [root@4 www]# nvme smart-log /dev/nvme1n1 Smart Log for NVME device:nvme1n1 namespace-id:ffffffff critical_warning : 0 temperature : 35 C available_spare : 100% available_spare_threshold : 10% percentage_used : 0% data_units_read : 158 231 244 data_units_written : 297 968 host_read_commands : 45 809 892 host_write_commands : 990 836 controller_busy_time : 337 power_cycles : 18 power_on_hours : 127 unsafe_shutdowns : 14 media_errors : 0 num_err_log_entries : 10 Warning Temperature Time : 0 Critical Composite Temperature Time : 0 Temperature Sensor 1 : 35 C Temperature Sensor 2 : 27 C Temperature Sensor 3 : 33 C Temperature Sensor 4 : 35 C
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のように、ねじの感触は素晴らしく、負荷がかかった状態でも温度範囲は同じ範囲に維持されると言われています。



ピーク時には、 1秒あたり約4000 /写真 （写真サイズは約10〜100K）を提供します。この負荷の半分でiostatが0.1％を超えて上昇することはありません。RAMも重要です。



安価なSATA SSDの代わりに、今では高価なNVMeに賭けている理由についていくつかの言葉。 たとえば、同様のサーバーアーキテクチャ、RAM、および同じ負荷で、Ultrastar SN260 7.68TB NVMeは、Areca ARC-1882 RAIDを備えたストリップRAIDの8xSamsung SSD 850 PRO 1TBの10倍少ないiowaitで動作することを示すテストを実施しました。コントローラPCI。 サーバーでは、NVMe 26のコア数と、ARC-1882 24コアのコア数、RAM 128Gの数に多少の違いがあります。 残念ながら、これらのサーバーの消費電力を比較する方法はありません。 8xINTEL SSDSC2BB480G4 480GのStripped RAIDソフトウェアと24個のAMD Opteron（tm）プロセッサー6174コア上のARC-1680 RAIDコントローラーPCIを搭載したAMDプロセッサー用の同様のシステムでNVMeプラットフォームの消費電力を測定する機会がありました。 AMDの274ワットに対して、113ワットの2.5倍のエネルギー。 まあ、CPUとiowaitの負荷も1桁低くなっています（AMDにはハードウェア暗号化はありません）

ファイルシステム

8年前、 btrfsを使用してXFSを試しましたが、ext4は大きな並列負荷でより活発に動作するため、ext4を選択します。 適切なext4チューニングは、このfsのすでに優れたパフォーマンスをさらに強化できます。

最適化はフォーマットの瞬間から始まります。たとえば、主に1〜5Kのファイルを配布する場合、フォーマットするときにブロックサイズをわずかに減らすことができます。

 mkfs.ext4 -b 2048 /dev/sda1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または

 mkfs.ext4 -b 1024 /dev/sda1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルシステムの現在のブロックサイズを調べるには、次を使用します。

 tune2fs -l /dev/sda1 | grep Block
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または

 [root@4 www]# fdisk -l /dev/nvme1n1  /dev/nvme1n1: 7681,5 , 7681501126656 і, 1875366486 і і = і  1 * 4096 = 4096 і і  (і/і): 4096 і / 4096 і і - (іі/): 4096 і / 4096 і  і : dos Іі : 0x00000000
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

NVMe SSDのセクターのサイズは4kであるため、ブロックサイズをこの値より小さくすることは最適ではないため、フォーマットします。

 mkfs.ext4 /dev/nvme1n1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ディスクをパーティション分割したのではなく、ブロックデバイス全体でフォーマットしたことに注意してください。 OSについては、別のSSDを使用していますが、故障があります。 / dev / nvme1n1としてファイルシステムにマウントできます



最大速度を引き出すような方法でディスクキャッシュをマウントすることが望ましいです。これにより、不要なすべてをオフにし、オプション「noatime、barrier = 0」でマウントします。atime属性が重要な場合は、カーネル4 以降にlazytimeオプションがあります。 RAMにatime値を保持し、読み取り時のアクセス時間の頻繁な更新の問題を部分的に解決します。

RAM

静的データがRAMに配置されている場合は、上記のすべてを忘れて、RAMからファイルを配布してください。



RAMから配布する場合、OS自体が頻繁に要求されたファイルをキャッシュに描画するため、このために何も設定する必要はありませんが、ファイルが保存されているデバイスが遅く、多くのファイル（数十万）がある場合、OSが同時に多くを要求する可能性がありますファイルシステムとストレージデバイスのファイルが同時に「スローダウン」し始めます。 この問題を次のように解決して、静的データをRAMディスクにロードし、そこから配布することができます。



RAMディスクの作成例：

 mount -t tmpfs -o size=1G,mode=0700,noatime tmpfs /cache
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マウントしたパラメーターを忘れた場合は、findmntで確認できます。

 findmnt --target /cache
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

再起動せずに再マウントできます：

 mount -o remount,size=4G,noatime /cache
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RAMの一部（頻繁に要求されるプレビュー）とSSDの残りを結合することもできます。



nginxでは、次のようになります。

  location / { root /var/cache/ram; try_files $uri @cache1; } location @cache1 { root /var/cache/ssd; try_files $uri @storage; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテンツがRAMに収まらない場合は、カーネルを信頼する必要があります。アクティブキャッシュ3〜5Gのサイズの128G RAMを搭載し、256Gに増やすことを考えています。

CPU

プロセッサの周波数に特別な要件はありませんが、機能の要件があります：トラフィックを暗号化する必要がある場合（たとえば、httpsを介して）、ハードウェアベースのAES-NI（Intel Advanced Encryption Standard）暗号化をサポートするプロセッサを選択することが重要です。



Linuxでは、コマンドのAES-NI命令プロセッサのサポートを確認できます

 grep -m1 -o aes /proc/cpuinfo aes
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「aes」出力がない場合、プロセッサはそのような命令をサポートしておらず、暗号化はプロセッサのパフォーマンスを浪費します。

nginxを構成する

一般的なアイデアは前の記事で説明されていますが 、最適化にはいくつかのポイントがありますが、今からそれらについて説明します。

• サーバーディレクティブのトップレベルでの書き換えは避け、ロケーションセクションでの正規表現は歓迎しません。 何らかの方法でこれがない場合、少なくとも次のように、通常の場所で通常のシーズンをラップするようにしてください：
  
  
  
  

    location /example/dir { rewrite ^/example/dir(.*) /newexample/$1; }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  これが行われない場合、正規表現は配布システムへの各リクエストに適用され、この例では、写真へのパスが/ example / dirで始まる場合にのみリダイレクト正規表現が試行されます
  
  
• コンテンツをキャッシュに保存する場合、1つのフォルダー（ブロックサイズが4Kのデフォルト設定でディスクをフォーマットした場合）、2Kの場合は128などに255個を超えるファイルまたはフォルダーを保存しないというルールに従ってください。
  
  
• できれば4.1以上の新しいコアを配置します。 nginxでは、 SO_REUSEPORTサポートを有効にすることを忘れないでくださいこのディレクティブは、配信サーバーからのファイルの並列ダウンロードにプラスの効果をもたらします。
• サーバーをユーザーの近くに配置するので、ユーザーをより幸せにし、ユーザーはそれを認識し、検索エンジンに感謝します

CDNはどうですか

CDNは、さまざまな国で働いていて、コンテンツが多くトラフィックが少ない場合に適していますが、トラフィックが多く、コンテンツがほとんどなく、特定の国で働いている場合、すべてを計算して、あなたにとってより有益なものを理解することは理にかなっています。 たとえば、私たちはウクライナ市場に取り組んでいます。CDNサービスを提供する世界のリーダーの多くはウクライナにサーバーを持っておらず、流通はドイツまたはポーランドからです。 そのため、+ 3-5ms-+ 30-50msの代わりに、青色の回答が得られます。 適切なウクライナDCに2Uサーバーを配置すると、チャネルあたり18ドル +支払いで開始されます。たとえば、100Mbps-10ドル合計28ドルです。 ウクライナでCDNトラフィックを配信するための商用価格は約0.05ドル/ Gです。 毎月560Gを超える量を配布する場合は、すでに自己配布のオプションを検討できます。 RIA.comサービスは1日に数テラバイトの静的データを配信します。そのため、私たちは長い間、自己配信に関する決定を下してきました。

検索エンジンで友達を作る方法

多くの検索エンジンにとって重要な特徴は、TTFB（最初のバイトまでの時間）と、コンテンツを探している人にどれだけ近いか、さらに、コンテンツへのリンクのテキスト、Exifタグの説明、一意性、コンテンツのサイズなどです。 .d。

これらのすべては、主にTTFBを拡張し、ユーザーにより近づけるために、ここに書いています。 トリックに行き、User-Agentを使用して検索ボットを検出し、別のサーバーからコンテンツを提供して「混雑」または「ピーク時のスローダウン」をなくすことができます（通常、ボットは均一な負荷を与えます）。 。 Google ChromeとYandex Browserは、ブラウザがクライアントの位置からページを読み込む速度について提供する情報を信頼している疑いがあるほか、これを行いません。



また、異なるボットからの負荷が非常に大きくなる可能性があるため、これらのボットのサービスにリソースのほぼ半分を費やさなければならないことにも注意してください。 RIA.comプロジェクトは、ボットからの約1千万から1千5百万のリクエストを処理します（これには、静的な呼び出しだけでなく、通常のページへの呼び出しも含まれます）。

静的コンテンツ配信の最適化

さて、配信プロセスが既に設定されている場合-コンテンツ自体で何ができるかを考える時が来たので、よりアクセスしやすく、読み込みが速く、スペースが少なくて済み、検索エンジンにとって魅力的でした。

• 最初に注意する必要があるのは写真形式です。多くのプロジェクトで非常に人気のあるjpegは、Web上の新しい形式、たとえばGoogleが2010年から推進しているWebP形式に匹敵する品質で既にサイズが劣っています。 さまざまな情報源によると、同等の品質で20〜30％サイズが小さくなっています。 クライアントで特別なタグを使用することもできます。これにより、ブラウザが表示できるいくつかの形式を記述できます。ブラウザがWebP形式をサポートしていない場合は、たとえばjpegが読み込まれます
  
  また、SEO要件についても少し説明します。
  
  
  
  
  • 配布サーバーをクライアントの近くに配置し、そのリターンを加速することで、SEO最適化の一部を既に作成しました。
  • exifタグに関するいくつかの言葉、それらの多くは写真を拡大縮小するときに切り取られます-無駄です！ また、Googleはこの情報を分析します。ImageDescriptionexifタグまたは著作権exifタグの写真に表示されているものを写真に示すのはなぜですか。もちろん、あなたのものでない限り：
  • コンテンツファイルに関するさまざまなメタ情報を示すHTTPヘッダーを忘れないでください。 たとえば、Expiresヘッダーを使用して、ブラウザーキャッシュにコンテンツを保存する期間を指定できます。
  
  
  サイトがHTTP / 2で実行されている場合、次の最適化を試す必要があります。
  
  
  
  
  • 1つの接続で小さなファイルの転送を多重化すると、この最適化を使用してhttp / 1.1を介して通常達成されるゲインを補償できるため、css-spritesの使用を拒否できます
  • web-pushテクノロジーを試してください。ダウンロードを最適化するこの方法では、 プッシュされるブラウザーキャッシュ内のコンテンツの存在は考慮されませんが、例に示すように、Cookieと単純なnginx構成を使用して解決します
    
    
    
    

     server { listen 443 ssl http2 default_server; ssl_certificate ssl/certificate.pem; ssl_certificate_key ssl/key.pem; root /var/www/html; http2_push_preload on; location = /demo.html { add_header Set-Cookie "session=1"; add_header Link $resources; } } map $http_cookie $resources { "~*session=1" ""; default "</style.css>; as=style; rel=preload, </image1.jpg>; as=image; rel=preload, </image2.jpg>; as=style; rel=preload"; }
          
          
    
            
            
            
          
    
        
            
            
            
          
          
    
            
            
            
          
    
        
         

    
    
    
  • 私たちの経験から、プロジェクトのメインドメインとは異なるドメイン名でコンテンツを配布する方が適切です。
  
  
  

  神秘的なHTTP / 2

  
  
  ご存じのように、HTTP / 2は、複数のファイルが送信される単一の接続を多重化します。一方、ファイルの送信、ヘッダーの圧縮、および新しいプロトコルのその他の利点を優先しますが、ほとんど書いていない欠点もあります。 私は遠くから行きます。おそらく、uTorrentの時代以前にインターネットを覚えていた行商人の年上の人がいるかもしれません。多くの人は、特別なロッキングホースフラッシュゲット、ダウンロードマスターなどを使用しなければなりませんでした。 6つまたは8つのスレッドで1つのファイルをダウンロードし、送信サーバーへの6〜8の接続を開きました。 なぜそうしたのですか？ 結局、配信サーバーと受信サーバーのあるチャネルは、それらの間の接続数に依存するべきではありませんが、実際には、チャネルが悪く、パケット損失とパケット伝送エラーがある場合、この依存関係が存在します。 そのような状況では、いくつかのスレッドでより速くスイングすることがわかります。 さらに、チャネルが複数のクライアントで使用されている場合、1つのクライアントからの接続数を増やすと、チャネルの帯域幅を増やして「リソースのブランケット」をそれ自体にドラッグできます。 もちろん、これは常に発生するわけではありませんが、http / 1.1プロトコルを使用して動作するブラウザの形で「つかむ」競合他社を取得するという脅威があります。 私の練習では、http / 2を拒否する「デスクトップ壁紙の写真ホスティング」などのサイトでケースがありました。http/ 2プロトコルのサイトが著しく遅くなり、サーバー自体に目に見える負荷がなく、男はhttpsのままでしたが、切り替えましたhttp / 1.1で状況は解決されました。
  
  
  
  また、異なるドメイン（ただし実際には1つのサーバー）からコンテンツを受信する実験も行います。この手法はドメインシャーディングと呼ばれます。http/ 2をあきらめず、ブラウザーにサイト管理者が必要な数の接続を設定することなく、状況から抜け出す方法が可能です
  
  
  
  

  結論の代わりに

  
  
  サイトの速度が低下し始める瞬間を不快と呼ぶことはできません。トラフィックが増えていると感じているため、顧客が増えているからです。 私たちは「ブレーキ」を回避するタスクを設定することはありません;この成長に迅速に対応することを学びました。 パフォーマンスの最適化は無限のプロセスです。高速であるという点で競合他社と競争する喜びを否定しないでください。