ども、こんにちは。

前回の記事でt2.microのCPUクレジットを使い切って激重になった話を書かせていただきました。

んで、まぁ適当にKUSANAGIのnginxのログを解析していると・・・・

[root@kusanagi80 nginx]# zcat access.log-20190508 | awk ‘{ print $NF,$2,$3,$12,$10,$15,$16 }’ | sort | uniq -c | sort -rn | head -n 10
18840 “138.68.229.65” – – 200 /blog//xmlrpc.php “Mozilla/5.0 (Windows
(1位以下はすでに桁が全く違うので割愛)

どうもbot臭いのです。

「xmlrpc.php」へのアクセスを時間帯別に解析してみると、まぁ激重時間と大体一緒ですかね。

また、CdloufFlareがキャッシュしていなかったのも納得です。

[root@kusanagi80 nginx]# zcat access.log-20190508.gz |grep /blog//xmlrpc.php | awk ‘{ print $7 }’ | cut -b 2-15 | sort | uniq -c | sort -rn | head -n 10
4345 07/May/2019:17
4317 07/May/2019:16
4021 07/May/2019:18
3707 07/May/2019:15
541 07/May/2019:20
538 07/May/2019:19
519 07/May/2019:21
508 07/May/2019:22
345 07/May/2019:23
7 07/May/2019:12

ということで、CloudFlareで bot対策をしようと思ったのですが、無償だとGoogleなどのbotも止めてしまいそうです。

Before getting started

Cloudflare Firewall Rules can affect how traffic from known bots is handled. For details, see this FAQ.

ふむ。よろしい。ならばここに関しては無償のIncapsulaのほうが向いてるな。ということで、いつか失敗した多段に再挑戦します。

が、その前に、ちょっとKUSANAGIのbcacheとfcacheを設定してみます。

参考：詳解！KUSANAGIキャッシュ講座

で、うちの場合は、サブディレクトリにWordPressをおいていますので、まずはKUSANAGIのシェルを修正します。

まぁこの辺みながら雰囲気で。fcacheは早い話、nginxのリバースプロキシ機能でのキャッシュ、bcacheは動的に生成されるページを一定期間HTMLとして静的に保存する。両方組み合わせれば、bcacheで静的に生成されたHTMLをリバプロがキャッシュして返してくれると。

参考：KUSANAGIでサブディレクトリにWordPressを複数インストールする

で、onにします。

さて、実際効果はあるのかというところをちょっとテストしてみます。

WebPageTestで測ってみました。
※Tokyo, Japan – EC2 – Chromeで。

• 旧オンプレサイト(CentOS Cpu 4コア/Mem:3GB)
  • https://www.webpagetest.org/result/190508_47_351c4d9104d0ca884007a289d9065993/
    
  • First Bytes 1.958s Fully Load 20.796s
• 新サイト(AWS t2.micro) CloudFlareなし
  • https://www.webpagetest.org/result/190508_T5_c5f0471c39b6ab87f8c1434dd7518f10/
    
  • First Bytes 2.817s Fully Load 20.163s
  • 流石にCPU性能、メモリ性能では旧オンプレ環境に負けてるので遅いですね。
• 新サイト(AWS t2.micro) + CloudFlare
  • https://www.webpagetest.org/result/190508_AR_24e95db4462d767499f2b0859ef05bed/
    
  • First Bytes 2.065s Fully Load 17.114s
  • お、早くなりました。これを基準にbcacheとfcacheを試していきます。
• 新サイト(AWS t2.micro) + CloudFlare + KUSANAGI fcache
  • https://www.webpagetest.org/result/190508_4J_7b0928d6f924e8d4698b6753caeed8d1/
    
  • First Bytes 0.845s Fully Load 15.867s
  • おおー。確実に早くなりました。以下のようにF-CACHEにHITしたことがわかります。
    
• 新サイト(AWS t2.micro) + CloudFlareなし + KUSANAGI fcache
  • https://www.webpagetest.org/result/190508_5W_8e0f63161b11d9fd14497d9f13b5a3b9/
    
  • First Bytes 0.588s Fully Load 18.046s
  • おー、CloudFlareなしfcacheオンリーだと、初速はめちゃめちゃ早いですね。
• 新サイト(AWS t2.micro) + CloudFlare + KUSANAGI fcache + KUSANAGI bcache
  • https://www.webpagetest.org/result/190508_97_66422e4c559c1d51847abac508e88ba8/
    
  • First Bytes 0.892s Fully Load 15.231s
  • 初速は落ちましたね。けど、やっぱり他の静的コンテンツがCloudFlareのキャッシュから帰ってくるので、全体的なスピードはアップした、という感じでしょうか。
• 新サイト(AWS t2.micro) + CloudFlareなし + KUSANAGI fcache + KUSANAGI bcache
  • https://www.webpagetest.org/result/190508_BD_ea283a342e16f40954704f80b313cff8/
    
  • First Bytes 0.614s Fully Load 18.451s
  • やはり初速は早いけど、全体的にはCloudFlareのCDNのほうが強いですね。
• 新サイト(AWS t2.micro) + Incapsula(Static+Dynamicモード) + KUSANAGI fcache + KUSANAGI bcache
  • https://www.webpagetest.org/result/190511_A0_cda343e19da80c01960fe5d7d3c34170/
    
  • First Bytes 1.165s Fully Load 17.531s
  •  初速遅いけど判定は、Cですね。。
• 新サイト(AWS t2.micro) + Incapsula(Static+Dynamicモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
  • https://www.webpagetest.org/result/190511_R9_f82b1950e6e8f1b3d46e4dc9f0443109/
    
  • First Bytes 1.036s Fully Load 17.636s
  • ※Dynamic Content Acceleration機能です。今回はAWSのVPCがus-eastなので、アシュバーン？が最寄りでした。てか応答速っ。
    
• 新サイト(AWS t2.micro) + CloudFlare + Incapsula(Static+Dynamicモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
  • https://www.webpagetest.org/result/190512_KK_01657d85a38a8e24a91fbc0cc160285c/
    
  • First Bytes 1.033s Fully Load 13.971s
  • 初速ともにまぁまぁですね。一応両方ちゃんと通ってます。
    ※X-Iinfo: がNNNなので、Incapsulaのキャッシュはまだ効いてませんでした・・・けど、CloudFlareがHITしているので、結局AWSまでは取りには行ってないはず。
    
• 新サイト(AWS t2.micro) + CloudFlare + Incapsula(Staticモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
  • https://www.webpagetest.org/result/190512_M8_c66631c02506ebbda0a56be2d30fbda1/
    
  • First Bytes 1.312s Fully Load 14.404s
  • 一つ上とまぁ誤差ですね。
• 新サイト(AWS t2.micro) + CloudFlare + Incapsula(キャッシュ無効+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
  • https://www.webpagetest.org/result/190512_7E_1393ad66c4ae2ed3eb8490e5876edda1/
    
  • First Bytes 1.382s Fully Load 14.749s
  • 今これです。

ということで、初速は、CloudFlareなしで、KUSANAGIのfcacheが一番速い。
トータルは CloudFlare + Incapsula(Static+Dynamicモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcacheが一番速いようです。

が、まぁ今回IncapsulaはBot制御目的ですし、２箇所でキャッシュ持つとややこしいので、キャッシュはCloudFlareだけにしました。

■CloudFlareとIncapsulaの多段構成について

多段構成のポイント？ですが、

Incapsulaを手前にすることは(おそらく無償版では)不可。
無償版IncapsulaはOriginにCNAMEが使えずIPアドレスしか使えない。

CloudFlareを前にする場合のポイント。(多分合ってると思う)

・CloudFlareに別のドメインを作ってそっちをIncapsulaに登録する
→同じ名前をCloudFlareとIncapsulaに存在すると以下のようなエラーになる。
※IncapsulaのProxyが名前解決したときに自分じゃない名前解決結果が来るから？と思われる。
→そんなことないです。それできなかったら導入前のhostsを使ったテストもできないので。(2019/05/26)

【2019/05/26 追記】

いろいろ間違ってます。普通にincapsulaにはwww.hits-net.comで登録してそのCNAMEをCloudFlareで向けつつCloudFlareのCDNを有効にすれば動きます。
↑のError code 23の原因にはサポートとも確認しましたが、結局わからずじまいで、なぜか今日改めて試したらうまくいきました。

・CNAME reuseの機能を活用して、CloudFlareの本丸ドメインをCNAMEでIncapsulaに向ける。
→Incapsulaにはxxx.hits-net.comで登録してるけど、そこで払い出されたCNAMEをwww.hits-net.comに向けてさらにCloudFlareのCDNとDNSをオンにして、多段にしました。

 

■リダイレクトの初速を上げる

いま「/blog」へのリダイレクトは、cloudflareがやってる・・・と思う。

 

【2019/5/12追記】

何故かIncapsulaが時折古いオリジン(旧オンプレ)に転送してしまう謎現象が発生したので切り戻しました。
今はCloudFlareオンリーです。

このX.X.X.100っていまいま設定上どこにもないんですよねー。

同じドメインを何度か消したり入れたりしてるから一部のPoPにゴミ情報のこったかなぁ。

まいったなぁ。てかよく見たらCNAME Reuseって

Note: Available for Enterprise plan customers only.

あちゃー。

【2019/05/26 追記】
結局のところ、原因不明です。多分やっぱり古い情報持ってたとしか思えないですね。
上述の通りサポートともいろいろやりとりして、Incapsulaのサイト登録もやり直しましたが、結局原因不明で時間が解決したか、何らかのIncapsula側のメンテナンスで直ったとかそんな感じですね。

【2019/05/27 追記】
CloudFlareとIncapsulaの多段化はやはり無理でした。
令和になったことだしクラウドへ移行する – 10 – CloudFlare+Incapsulaの多段化はやっぱり無理

 

【バックナンバー】

• 令和になったことだしクラウドへ移行する – 1 – 全体方針
• 令和になったことだしクラウドへ移行する – 2 – Exchange Server 2010 to Office 365(1)
• 令和になったことだしクラウドへ移行する – 3 – Exchange Server 2010 to Office 365(2)
• 令和になったことだしクラウドへ移行する – 4 – Exchange Server 2010 to Office 365(3)
• 令和になったことだしクラウドへ移行する – 5 – Exchange Server 2010 to Office 365(4)
• 令和になったことだしクラウドへ移行する – 6 – ブログがAWSになりました。
• 令和になったことだしクラウドへ移行する – 7 – t2.microでmariaDBが落ちる
• 令和になったことだしクラウドへ移行する – 8 – t2.microが激重になる

ではでは。またの機会に。