ども、こんにちは。

前回の記事で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が激重になる

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

ども。こんばんは。

mariaDB問題は解決して、ようやく落ち着いたかと思ったら、今日はなぜかブログが激重になりました。。。

で、調べてみると、st(steal)が上昇していました。

今まで意識したことがなかったのですが、st値は、

【EC2】CPU使用率のsteal項目とは

馴染みがない項目だったのでで詳細を調べてみると、仮想サーバにおいて
「ゲストOSに処理を要求をしても、CPUリソースを割り当てられなかった時間の割合」
を意味するとのことです。

らしいです。で実際こんな感じでstが80%消費されており、実質20%しかCPUが使えない？状態のようです。

そりゃ重いわな。

AWSコンソールで、CPUクレジットを見ていると、クレジット使い切っちゃったみたいですね。

t2.microのCPUクレジットは144です。
※t3.microはほぼ値段一緒なのにCPUクレジットが多いんですよねー。やっぱt3にしたいなぁ。

バースト可能パフォーマンスインスタンスの CPU クレジットおよびベースラインパフォーマンス

とりあえず、インスタンスを再起動するとリセットされるようなのでその場しのぎですが再起動しました。

うーん。なかなかクラウドならではですねぇ。

これKUSANAGIのbcacheとか効かせたら処理減って軽くなるのかなぁ。とりあえず明日一日様子見ですね。

確かにちょっとアクセスおおかったのかなぁ。。。

【バックナンバー】

• 令和になったことだしクラウドへ移行する – 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が落ちる

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

ども。こんばんは。

件名のとおりです。

いろいろありつつ、半日でなんとか終わりました。

多分見れてるはず。です。

もちろんCloudFlare越しですが。

awsは12ヶ月無料枠のt2.microでKUSANAGIを入れました。
※KUSANAGIの推奨はメモリ4GB以上ですが、まぁこのくらいの規模なら全然余裕ですね。きっと。

ただ、KUSANAGIの全力は出てないと思いますが、前よりはキャッシュはCloudFlareのキャッシュも効いているはず。

疲れた。

途中経過は概ねログと画面キャプチャがあるのですが、もうありふれた話ばかりなので今回はポイントだけを自分用にメモです。

• AWS
  • 普通にセットアップ、管理者のMFAを有効にしたくらい
  • あと一応請求が$10超えたらメール来るようにしてみた。
  • VPC
    • リージョンは最安で米国東部(バージニア)
      • どうせCloudFlare通すしきっといい感じになる。。。とおもう。
    • アベイラビリティゾーンはus-east-1f
  • EC2
    • インスタンスはt2.micro
      • 本当はt3にしたかったが、AMIのKUSANAGIが対応していなかった
    • Elastic IP一つ取得
  • KUSGANAGI
    • とりあえずyumで諸々アップデートしてから設定
    • php7だとうちの古めかしいvistaテーマが動かない&諸々エラーが出たのでphp5.6に戻した(kusanagi initやりなおし)。
      • あとlike-box.phpもphp7だと動かない。ログイン画面すら出ず焦った。
        まぁそれ以上に今のテーマを変えたくなかったのでしばらくphpは5.6だなぁ
        • 参考：フェイスブックのLike Boxを設置している方はPage Pluginへ変更しよう！
    • サブディレクトリにWordPressを展開しているので多分効いてないKUSANAGIの機能がある気がする。
    • bcacheを効かせるには、多分以下の設定いれればいけるかも？
      • KUSANAGIでサブディレクトリにWordPressを複数インストールする
    • てか、KUSANAGIってそれ用のWordPressプラグインあるっぽいけどそのへんよくわかんない
    • あと、サブディレクトリに入れた関係か多分Let’s Encryptちゃんと動いてないと思う。
  • 引っ越しの仕方
    • BackWPupプラグインでファイルもDBの抜こうとしたが、旧環境だとPHPが2GB以上のファイルをP扱えなくてエラー(PHPバージョンで扱えない大きさのアーカイブになります。)でアーカイブがコケまくったので諦めた。
      • 一応古いPHPで2GB以上のファイルが扱えないことはないが再コンパイルなんて今さらやってられないのでスルー。
        • 参考：https://bugs.php.net/bug.php?id=36478
    • wp-contents配下をtgzで固めてscpでゴリゴリコピーした。
    • KUSANAGIのデフォルトのドキュメントルートをまるまる「/blog」にコピーしてwp-contentsだけ上書き。
    • DBはBackWPupで抜いたものをmysqlコマンドでどーん。
  • 心残りというか明日以降確認
    • KUSANAGIのサブディレクトリ化もう少し見直す
    • SSL化する？(Cloudflareの機能でもいいかも)
    • キャッシュのテスト
    • メールでDBのバックアップ飛ばしてるけど、多分動かないだろうなぁ。
    • ちと、ポートスキャンとか外部からのアクセス確認をば。セキュリティグループはしっかり作ったはず。
    • Google Analyticsとか大丈夫だと思うけど、明日確認
  • いずれやりたい
    • せっかくAWSのアカウント作ったし、BackWPupはS3にバックアップ取れるので、バックアップの方式を検討する

そんなところかな。

【追記】

やっぱりへんだなぁーと思ってたらやりがちなことをやってしまっていた。
参考：KUSANAGIに移設する際の5つの手順をまとめてみた

ここでの注意点は移設先のwp-content内にあるmu-pluginsを削除してしまわない事。
よくあるのがwp-contentをリネームしてまるっと置き換える方法。これやっちゃうとKUSANAGI用のオリジナルプラグインがなくなっちゃいますので、リネームしたディレクトリから移しておきましょう。

KUSANAGI用のオリジナルプラグインはWordPressの高速化の一端を担っています。
多言語に対応したWordPressが日本語で表示できるのは当たり前ですが、この翻訳が管理画面なども遅くする原因にもなっています。ですので、翻訳ファイルをキャッシュしてしまうことでWordPressの高速化を図っています。

なせ、オリジナルプラグインなのか。それはWordPressのコアを修正したりしないためです。
良く勘違いされるのがKUSANAGIで導入されたWordPressはチューニング（改造）されていると言う間違いですね。これやっちゃうとバージョンアップできなくなるので絶対やりません。

これで、Azure、Office365、AWSとGCPもちょっとだけ(AIY Voice Kitで)やったので、主要なクラウドには手が広げられたかなぁ。

以下画像アップロードテスト。

連休中に、メールとWebのクラウド化が無事完了したε-(´∀｀*)ﾎｯ

これで、なんと我が家のFWでは外部→内部を処理するルールがなくなってしまう&監視するものがなくなってしまう。。

それはそれで少しさみしいですね。
とはいえ、まだオンプレでもいろいろやりたいことはあるかなー。

【バックナンバー】

• 令和になったことだしクラウドへ移行する – 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)

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