令和になったことだしクラウドへ移行する – 12 – AWSの初障害を味わう

ども。こんばんは。

当ブログですが、2019/06/25 11:00(JST)頃からアクセス不可になっていたようです。

というのも、このブログはAWS上で稼働していますが、運悪くインスタンスが乗っかっているハードウェアで障害が起きてしまったようです。

気づくのにだいぶ遅れましたが、以下のようなメールが届いていました。

Amazon EC2 Instance Retirement [AWS Account ID: xxxx]

Hello,

EC2 has detected degradation of the underlying hardware hosting your Amazon EC2 instance (instance-ID: i-xxxx) associated with your AWS account (AWS Account ID: xxx) in the us-east-1 region. Due to this degradation your instance could already be unreachable. We will stop your instance after 2019-07-09 02:00 UTC.

You can find more information about maintenance events scheduled for your EC2 instances in the AWS Management Console (https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Events)

(以下略)

まとめると、あんたのインスタンスが乗ってるハードウェアがぶっ壊れてもうすでに接続できないよ、7/9に吹き飛ばすよ、ということらしいです。

参考:AWSのインスタンスリタイアお知らせが来た時の対処

メールは家に帰ってから見たのですが、コンソール上でも以下のようなメッセージが確認できました。

というか、EC2のところで、ステータスチェックでずっとエラーになってました。(←キャプチャは取り忘れ)

でまぁ、再起動(stop->start)したら直りました。

なかなか止まらなくて、stopを何度かしてようやく止まった感じです。

ちなみに焦ってTerminate(終了)しそうになりましたが、どうやらAWSのTerminateはインスタンスをふっとばす機能みたいですね。。。恐ろしい。

どれほど効果があるか調べてないですが、削除の保護を設定しておきました。

うーん、こういう障害は初めてですね。こうならないようにアヴェイラヴィリティゾーンとかを設定しなきゃですが、まぁ個人だしそこは仕方ない。。。

一瞬、今後ののためにIncapsulaでServe Stale Contentを効かせて、インスタンス障害時もコンテツキャッシュから返すようにしようかと悩みましたが、うーん、まぁやめとこう。それよりもステータスチェックに失敗したら携帯にメールを飛ばそう。。。

ということでこんな感じに設定してみました。

自動で再起動もできるようですが、ちょっとそれも不安なので一旦通知のみです。

間隔としきい値は適当です。CloudWatchのことまだ良くわかってない・・・。
できれば、こんな感じにCPUクレジットが0になっても通知するの作りたいと思いつつまだできてません。

ちなみにトピック名とやらは日本語不可です。エラーになりました。

で、ここに入力したメールアドレスが初めて登録したものの場合、認証メールが来るみたいです。

認証したところ。

実際に動かしてみないとわからないことが多いですね。

【バックナンバー】

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

Leave a Comment

サックス練習 – 33 –

ども。こんばんは。

久々に動画です。

松田聖子さんの名曲「SWEET MEMORIES」です。

いい曲ですね。

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

Leave a Comment

令和になったことだしクラウドへ移行する – 11 – AWSからはじめての請求がきた

ども。こんばんは。

2019/6/3に請求が来ていました。

$1.29でした。

t2.microは無料なので、データ転送量だけ課金された感じです。

以下にプラスして消費税$0.1で、$1.29でした。

 

Data Transfer

$1.19

US East (N. Virginia)

AWS Data Transfer USE1-APN1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from Asia Pacific (Tokyo)
0.005 GB
$0.00
AWS Data Transfer USE1-APN1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to Asia Pacific (Tokyo)
0.116 GB
$0.00
AWS Data Transfer USE1-APS1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from Asia Pacific (Singapore)
0.000000070 GB
$0.00
AWS Data Transfer USE1-APS1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to Asia Pacific (Singapore)
0.000000040 GB
$0.00
AWS Data Transfer USE1-CAN1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from Canada (Central)
0.000000070 GB
$0.00
AWS Data Transfer USE1-CAN1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to Canada (Central)
0.000000040 GB
$0.00
AWS Data Transfer USE1-CloudFront-In-Bytes
$0.00

$0.00 per GB data transfer in to US East (Northern Virginia) from CloudFront
0.000011 GB
$0.00
AWS Data Transfer USE1-CloudFront-Out-Bytes
$0.00

$0.00 per GB data transfer out of US East (Northern Virginia) to CloudFront
0.000003 GB
$0.00
AWS Data Transfer USE1-EUC1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from EU (Germany)
0.000002 GB
$0.00
AWS Data Transfer USE1-EUC1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to EU (Germany)
0.000093 GB
$0.00
AWS Data Transfer USE1-EUN1-AWS-In-Bytes
$0.00

USD 0.0 per GB for EUN1-AWS-In-Bytes in EU (Stockholm)
0.000000430 GB
$0.00
AWS Data Transfer USE1-EUN1-AWS-Out-Bytes
$0.00

USD 0.02 per GB for EUN1-AWS-Out-Bytes in EU (Stockholm)
0.000001 GB
$0.00
AWS Data Transfer USE1-EUW2-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from EU (London)
0.000000070 GB
$0.00
AWS Data Transfer USE1-EUW2-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to EU (London)
0.000000040 GB
$0.00
AWS Data Transfer USE1-USW1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from US West (Northern California)
0.000004 GB
$0.00
AWS Data Transfer USE1-USW1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to US West (Northern California)
0.000010 GB
$0.00
AWS Data Transfer USE1-USW2-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from US West (Oregon)
0.000157 GB
$0.00
AWS Data Transfer USE1-USW2-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to US West (Oregon)
0.012 GB
$0.00
Bandwidth
$1.19

$0.000 per GB – data transfer in per month
6.862 GB
$0.00
$0.000 per GB – data transfer out under the monthly global free tier
15 GB
$0.00
$0.000 per GB – regional data transfer under the monthly global free tier
0.035 GB
$0.00
$0.090 per GB – first 10 TB / month data transfer out beyond the global free tier
13.214 GB
$1.19

結局アウトバウンドトラフィックだけ課金ってことなかな。

IncapsulaでCDN効かせてるのでそこそこ節約してる・・・と信じたい。

 

Bandwidth
$1.19

$0.000 per GB – data transfer in per month
6.862 GB
$0.00
$0.000 per GB – data transfer out under the monthly global free tier
15 GB
$0.00
$0.000 per GB – regional data transfer under the monthly global free tier
0.035 GB
$0.00
$0.090 per GB – first 10 TB / month data transfer out beyond the global free tier
13.214 GB
$1.19

【バックナンバー】

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

Leave a Comment

パニック障害の経過 – 3 –

ども。こんばんは。

そろそろ発症から半年ほどになりますが、なかなか治りませんね。

今週は天気も悪かったせいか、いまいち調子も上がらず。。

2019/6/14から薬を調整して今こんな感じになりました。
ベースのイミドールが夜と就寝前に10mgを一錠ずつ追加です。

一日17錠ってなかなか薬多い気もしますね。

  • 朝  :ソラナックス 0.4mg x1   /ガナトン50mg x1/イミドール 25mg x1/イミドール10mg x2
  • 昼  :ソラナックス 0.4m x0.5  /ガナトン50mg x1/イミドール 25mg x1/イミドール10mg x1
  • 夜  :ソラナックス 0.4m x0.5  /ガナトン50mg x1/イミドール 25mg x1/イミドール10mg x2
  • 就寝前:ソラナックス 0.4m x0.5  /イミドール10mg x2

ここのところ、頓服薬を使わなくてもなんとか耐えれるようになってるので、だいぶ快方に向かっている気はしますが、なかなか後ちょっとのところで治りませんね。。。

【バックナンバー】

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

Leave a Comment

HTC U19e/HTC Desire 19+記事まとめ

でましたね。

■HTC台湾の公式ページ

https://www.htc.com/tw/smartphones/htc-u19e/

■各種ブログ、ニュース

うーん・・・。

うーん・・・・・。

過去のスマフォ遍歴。

Windows Mobile:

  • X02HT
  • X04HT
  • (X02T←唯一東芝)

Android:

  • HTC evo WiMAX(ISW11HT)
  • HTC J(ISW13HT)
  • HTC J One(HTL22)
  • HTC J Butterfly(HTV31)
  • HTC U11(HTV33)

7台続いたhTc信者ですが、ここに来てもうやっぱり駄目かな・・・。
Pixelにするかなぁ。

新機種も面白そうだし、基盤透けてるのexodusぽくて格好いいんだけど、U11でスペック的にもまだ全然戦えるし、U11がこのまま3年目突入かなー。

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

 

Leave a Comment

有給休暇、久々の秋葉原、煙管の掃除ほか

ども。こんばんは。

今日は有給休暇ももらいましました。

今年度に入ってまだ1日も取得してなかったし、計画的に取らないとですね。

午前中はバタバタと洗濯したり掃除したりして、午後からは久しぶりに秋葉原に出向いてみました。

平日だとちょっと空いてます。けど、海外から来てる観光客が多いですねー。

行ってみたかったお店を何件か回りましたが特に買うものもなく・・・。
iPad miniほしいなーとか、BlackBerry KEY2が意外とイケてるなーとか。
程度のいいPC-98ないかなーとかウロウロしていました。
98Noteレストアしたい熱にかられてます。

そういえばHTC U11もそろそろ2年ですね。買い替えどうしようかな。。。

さて、話変わって煙管(キセル、きせる)ネタです。

結局前回購入したヒュミストーンは加湿力が強過ぎて以下のものを買いました。

柘製作所(tsuge) ヒュミドール・アルミ・ブラック #77609

¥540なり。

どっちが表だろう?

前回購入したヒュミドールは全体がヒュミドールだったけど、今回は中になにか入ってる感じ?
大きさはちょっと小ぶりになりました。

小粋の箱にピッタリです。

まあ、なんとかこれでいい感じ?でしょうか。

まだまだこのあたりの管理方法がちゃんとわかっていませんね。

それはさておき、煙管を初めて1週間ほど経ちましたので、今日は掃除をしてみました。

火皿が結構汚れています。

1週間、毎日1〜2回喫煙しています。

これを、無水エタノール、綿棒、モール(煙管と同時に購入)で掃除します。

モールに無水エタノールを染み込ませて、吸い口側から、火皿方向に向かって通します。

おー、だいぶ汚れてた。

火皿も無水エタノールを染み込ませた綿棒で掃除してみました。

分かりづらいですがだいぶきれいになりましたね。

残骸たち。結構汚い。

私の煙管は、羅宇も金属なので、水洗いでもいい気がしてきた。。。
でも大体この流れが一応正規?の清掃の仕方みたいです。

いろいろ探していると、以下の動画のようなやり方もあるみたいですね。
エタノール飲んじゃいそうな気もしますが、次はこれでやってみようかな?

 

久々に有給を有意義に過ごした・・・気がする。

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

Leave a Comment

Facebookのプライバシー設定でスマートリストでの除外ができなくなった?

ども。こんばんは。

2019年5月25日頃?から、

投稿時に以下のようなメッセージが出るようになってしまいました。

「オーディエンスを更新してください」

このスマートリストをオーディエンスから除外することはできません。除外する人をそれぞれ選択するか、別のオーディエンスを選択してください。

私は、公開範囲を「友達」にしつつ、一部の会社や学校を除外する設定をデフォルトにしています。

どうやらそれが効かなくなったっぽいです。

こまったなー。

プライバシー設定を変えようとすると以下のようなエラーとなり更新できません。

「このスマートリストを除外することはできません」

You can’t exclude this smart list from your audience. Please select each person you want to exclude or choice a different audience.

しょうがないので、除外ではなく、公開したい人だけを公開範囲に設定しました。

どうやら影響があるのはスマートリストだけみたいですねー。

なおらないかなーこれ。

アプリでも同じようなエラーになりますね。

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

Leave a Comment

Lenovo Yoga Tablet 2にWindows 10 May 2019 Update(Version 1903)は今の所入らない?

ども。こんばんは。

まだギリギリ使ってるYoga Table 2を1903にアップデートしようかと。

過去記事:

えっと、結論失敗しました。

多分原因はこれ。とはいえ、容量足りないからSDは必須なんだよね。

USB デバイスや SD カードが接続されているコンピューター上の「Windows 10 にこの PC をアップグレードすることはできません」エラー

注意!Windowsアップデート1903はUSBやSDカードを外さないとエラーが起きる

 

とりあえずアップデートします。

今は1809ですね。

まだ普通のWindows Update経由ではうちには来ないみたいなので、手動アップデートします。

相変わらずの容量不足。

あと数百MBかあー。

お、Windows Updateのクリーンアップで7GBくら確保できそう。

クリーンアップしても減らなかったぞ・・・。
Kindleのダウンロード済みデータとかを消してなんとか8GBを確保。

はじまったー。

おー、進んでる。

ということで、冒頭に戻りますorz

次の作業が必要です。

このPCをWindows 10にアップグレードすることはできません。
お使いのPCはこのバージョンのWindows 10で使用する準備ができていないハードウェアがが使われています。対処は必要ありません。問題が解決された後、このバージョンのWindows 10がWindows Updateで自動的に提供されます。

 

 

そのうちうまくできるようになるのかなー。

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

 

Leave a Comment

「劇場版 夏目友人帳 ~うつせみに結ぶ~」を見た。

ども。こんばんは。

発売日に届いていたのですが、ようやく今日見ました。

劇場版 夏目友人帳 ~うつせみに結ぶ~(完全生産限定版) [Blu-ray] ¥6,479

めちゃくちゃ良かったそしてめちゃくちゃ泣いた(´;ω;`)

EDでもう一回泣いた。本編とEDが合いすぎ。

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

Leave a Comment

サックス練習 – 32 – リードを変えました。

ども。こんばんは。

昨日の会社帰りに、クロサワ楽器さんに行って、新しいリードとコルクグリスを買いました。

前回の記事で触れましたが、今までの3 1/2から3に変更しました。

Vandorenの青箱の2 1/2とWoodStoneの3はおじくらいの硬さみたいです。

サックスリード硬さの比較表

WoodStone AltoSax 3 ¥2,295(税抜き)←ネットで買うよりだいぶ安い
YAMAHA コルクグリス ¥412(税抜き)←ネットで買うよりちょっと安い

歴代リード

マメなので後ろに購入日が書いてあります。

で、今日は74回目の練習に。

目論見通り、やっぱり3のほうがあってますね。
今日は今までより下唇を噛みしめる強さも減って、疲れにくくなりました。

しばらくこのままですね。3 1/2も数枚余っててちょっともったいないですが。。。

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

Leave a Comment

CISMに挑戦してみる – 7 –

ども。こんばんは。

今日ようやくバッジと正式な認定証が届きました!

中身はこんな感じ。

バッジは磁石式・・・。

すでに、PDFではダウンロードできるようになっている認定証の原本?です。

もう一枚紙が入っていました。
おめとうがんばれ、的な。

 

最終的な受験〜合格〜認定まで時系列はこうなりました。

今月も月例会に参加します!

【バックナンバー】
参考にならないと思いますが、勉強方法などは3に記載しています。

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

Leave a Comment

令和になったことだしクラウドへ移行する – 10 – CloudFlare+Incapsulaの多段化はやっぱり無理

ども。こんばんは。

今日は連投ですね。

令和になったことだしクラウドへ移行する – 9 – t2.micro激重の原因とKUSANAGIのキャッシュの本気、CloudFlare+Incapsulaの多段化

にごちゃごちゃ追記したのですが、結論やっぱり無理です。

しばらくすると、IncapsulaでError Code 23になってしまいました。

その後、CloudFlareのCDNをoff(=DNS上、www.hits-net.comの解決結果がIncapsulaのCNAME)状態であれば通ります。

これを何度か再現テストして今の所再現率100%なので、やはり、IncapsulaのProxyは名前解決をちゃんと見ているのかもしれませんし、Free Planゆえのなにかかもしれません。

一応Error code 23の主要な原因はこれです。

https://support.incapsula.com/hc/en-us/articles/231496108-Grace-period-for-removed-sites
※24時間以内に同じFQDNを追加削除すると駄目だよっていう感じの話。

以下、完全に推測です。もしかしたら本当にIncapsulaがゴミ持ってるかもしれないし・・・。

上述の動作なら通常テストするときにhostsファイルに書いてアクセスしても同じことが起きるんじゃ?と思いますが・・・。

おそらくですが、hostsを編集した状態でアクセスしても、

元々のDNS(=Incapsulaが知っているDNS解決結果)と同じなら、通してくれる
※都度かどうかはわからないがIncapsula自身が名前解決をしている。これはoriginに対してではなく保護対象として登録したFQDNに対してと思われる。(OriginがCNAMEの場合はもちろん名前解決しますが、今回はOriginはIPアドレス直接指定なので)

のではないかと思います。

CloudFlareを前段に持ってきてCDNをOnにすると、IPアドレスの解決結果はあくまでCloudFlareです。

ということは、Incapsullaからすると、www.hits-net.comは、元々Incapsulaが最初にスキャンしたOriginのIPでもなく、Incapsulaが払い出したCNAMEでもない第3の「なにか(=ここではCloudFlare)」を解決してしまうことになります。
確かにこのパターンはそうそうないかも。

多分それが今回のError Code 23の原因かと。しばらくうまく行ったように感じるのは、CloudFlareのキャッシュが帰ってくるからかと思います。

CloudFlareのCDNをoffにすると割とすぐにError code 23はなくなります。(CloudFlareのTTLが300秒なので多分最大5分待てばいい。)

これCNAME Reuse使えれば話は違うんだろうけどなぁ。
OriginをCNAMEで登録したいなぁ。

もういいや、ということで、多段は諦めて、Incapsulaでキャッシュすることにしました。

【バックナンバー】

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

Leave a Comment

煙管はじめました

本記事は喫煙を推奨するものではありません。

以下タバコのパッケージ警告文(Wikipediaより)。


  • 喫煙は、あなたにとって肺がんの原因の一つとなります。疫学的な推計によると、喫煙者は肺がんにより死亡する危険性が非喫煙者に比べて約2倍から4倍高くなります。(詳細については、厚生労働省のホーム・ページ www.mhlw.go.jp/topics/tobacco/main.html をご参照ください。)
  • 喫煙は、あなたにとって心筋梗塞の危険性を高めます。疫学的な推計によると、喫煙者は心筋梗塞により死亡する危険性が非喫煙者に比べて約1.7倍高くなります。
  • 喫煙は、あなたにとって脳卒中の危険性を高めます。疫学的な推計によると、喫煙者は脳卒中により死亡する危険性が非喫煙者に比べて約1.7倍高くなります。
  • 喫煙は、あなたにとって肺気腫を悪化させる危険性を高めます。
  • 妊娠中の喫煙は、胎児の発育障害や早産の原因の一つとなります。疫学的な推計によると、たばこを吸う妊婦は、吸わない妊婦に比べ、低出生体重の危険性が約2倍、早産の危険性が約3倍高くなります。(詳細については、厚生労働省のホーム・ページ www.mhlw.go.jp/topics/tobacco/main.html をご参照ください。)
  • たばこの煙は、あなたの周りの人、特に乳幼児、子供、お年寄りなどの健康に悪影響を及ぼします。喫煙の際には、周りの人の迷惑にならないように注意しましょう。
  • 人により程度は異なりますが、ニコチンにより喫煙への依存が生じます。
  • 未成年者の喫煙は、健康に対する悪影響やたばこへの依存をより強めます。周りの人から勧められても決して吸ってはいけません。

 

ども。こんばんは。

何を思ったか煙管(キセル、きせる)を始めてみました。

過去に電子タバコのiQOSgloを始めたりしましたが、実は最近めっきり吸っていません。

結局紙巻きが一番かなと。

で、ちょっと先日新宿の紀伊国屋に立ち寄ったところ、面白そうなお店が。

喫煙具専門店 kagaya

おー、見たことない煙草、葉巻、Zippoライター、パイプ、煙管、お酒、雑貨・・・など、ちょっと大人心をくすぐるお店があるじゃないですか。

ということで、以前からちょっぴり興味のあったパイプか煙管を買おうかなと入ってみました。

パイプもたくさん並んでいたのですが、ちょっと吸うのが難しそうだったので、今回は煙管を買ってみました。

購入したのは、以下のもの。

店員さんと相談してとりあえず以下3つと、無水エタノールがあればいいんじゃないかということでした。
エタノールは過去に無線APの加水分解したラバーを剥がすのに買っていますので今回は買っていません。

・煙管本体(メーカ?とかはよくわからない。メタルの羅宇煙管) ¥2,600
・掃除用のモール ¥500
・小粋 ¥470

通常の羅宇煙管は、真ん中が竹みたいですが、これは全部金属です。
真鍮に銀メッキ?なのかな?

全部金属のものを延べ煙管と言ったりするようですが、これは一応羅宇があるので?羅宇煙管ですかね。
まだ勉強中です。

で、とりあえず一服しようかと思ったら・・・

葉が乾燥しまくっててパッキパキというか粉々になって、YouTubeとかで紹介されているように、丸めて詰めることができない・・・・。

ちょっと分かりづらいですが、つまむとバラバラと折れてしまいます。

吸えないこともないけど、リアルに一服したら燃え尽きちゃうよ。

全く知らなかったのですが、どうやら加湿してあげないと駄目らしいです。
湿気がダメそうなイメージですが・・・。

で、いいものがないかといろいろ調べて見たら、ヒュミドールというものがあるそうな。

よくよく考えるとサックス用のリードヴァイタライザーでも良さそうなんですよね。
#というか実際全く同じものを使っている人がいました。。。。

とはいえ、別の容器(タッパーとか?)に移し替えたりするのもの面倒なので、もっといいものないかなーと。

Amazonで売ってる↓が小粋の箱に入ってちょうどいいらしいという記事を見かけたのですが、

柘製作所(tsuge) ヒュミドール・アルミ・ブラック #77609 柘製作所(tsuge)

まぁ他に買うものもなく、これ一個買うのも・・・と思い、家から一番近い煙草の専門店に行ってみました。
※今後小粋を確保しなくてはならないので、そのへんの確認も兼ねて。

店員さんがとっても気軽に話を聞いてくれて、それなら、シャグ用(手巻きタバコ?なのかな)だけどこのヒュミストーンを使ってみたらどうだろう?というアドバイスをもらったので買ってきました。

左にあるのはついでに買ってきたパイプ用のコンパニオンです。
※火皿を掃除するのにいいかなーと思って買ってみました。

これを水につけて、2〜3分後に小粋の箱の入れて2〜3時間加湿すればいいかも?ということでした。

ただ、加湿しすぎるかもしれないので、様子見て、加湿しすぎなら出して、また加湿してと調整してみてください、ということでした。

ちゃんと入れた状態でも箱に収まる。

・・・。せっかく忠告をもらったのに、入れた状態でぐっすり寝てしまい・・・。

数時間後にあけてみると、ヒュミストーンのうらに若干こびりついてましたが、全体的にはもともとのカラカラ具合よりはしっとりしており、ちゃんと丸めることができるくらいの状態になっていました。

まぁ一応成功ということで・・・。

とりあえず形はそれっぽく吸えるようになりました。
いろんな方がブログやYouTubeに吸い方の動画をアップしているので参考にさせていただきました。

一つだけここでも紹介します。 

この方のように上手には吸えませんが、吸ってみての感想として・・・
普段がホープなので割とキツめなバタコに慣れているのか、煙管でもそんなにガツンとくる感じはない気がします。
※詰め方とかが下手なのかも。

ただ、一回の喫煙でのニコチンの摂取量が多い気がします。
※吸った後の次の喫煙までの時間が長い。

葉の湿度調整とか、道具とかいろいろこだわると楽しそうなので、ぼちぼちやってみたいと思います。

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

Leave a Comment

FortiOS v6.0.5 build0268 (GA)が出ていた

ども。こんばんは。

出てますねー。

上げました。最近比較的アップデートに失敗しないし、起動後のディスクチェックやれ!っていうのも出なくなりましたね。

 

リリースノート:

https://docs.fortinet.com/document/fortigate/6.0.5/FortiOS%20Release%20Notes/760203/introduction

これまだknown issueなの?さっさとなおしてくだいませー。
もはやバグのレベルなのか?という気がする。

Bug ID Description
435951 Traffic keeps going through the DENY NGFW policy configured with URL category.

 

6.2がもう出てるけど、うちの90Dには入らないし、本気でそろそろ50Eあたりに買い換えないと。

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

Leave a Comment

サックス練習 – 31 –

ども。こんばんは。

昨日は73回目の練習に行ってきました。

で、先日からGottsuのMetal HL(2018)を使っているのですが、ちょっと以前よりも下唇を押し付けている感じが強くなっていることに気が付きました。。

リードは以前から同じくWoodStoneの3 1/2です。

あと、練習不足なのもありますが、以前よりも口が疲れやすい気がしています。

で、昨日は試しに、サックス購入時に併せて購入したVandorenの2 1/2をGottsu Metal HLにつけてみたのですが、すごく吹きやすく感じ、口の疲れも少し減った気がします。

っということは、今のマウスピースとリードの組み合わせがあってないか、アンブシュアが悪いかですね。。。

音色?はWoodStoneのほうが好きな気がするので、WoodStoneの3を買ってみようかなぁ。

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

Leave a Comment

令和になったことだしクラウドへ移行する – 9 – t2.micro激重の原因とKUSANAGIのキャッシュの本気、CloudFlare+Incapsulaの多段化

ども、こんにちは。

前回の記事で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制御目的ですし、2箇所でキャッシュ持つとややこしいので、キャッシュは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の多段化はやっぱり無理

 

【バックナンバー】

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

Leave a Comment

令和になったことだしクラウドへ移行する – 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とか効かせたら処理減って軽くなるのかなぁ。とりあえず明日一日様子見ですね。

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

 

【バックナンバー】

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

 

Leave a Comment

2019年 GWの振り返り

ども。こんばんは。

毎年恒例ですかね。

いろいろしましたが意外とグダグダでした。

  • 1日目(04/27):練習へ、ちょっと仕事した。
  • 2日目(04/28):寝てた。夕方仕事した。
  • 3日目(04/29):ゲームしてた。夜飲みに行った。(薬はちょっと控えてね)
  • 4日目(04/30):寝てた
  • 5日目(05/01):Office365移行
  • 6日目(05/02):練習へ
  • 7日目(05/03):寝てた
  • 8日目(05/04):Office365移行の続き
  • 9日目(05/05):ブログのAWS移行、図書館戦争見た
  • 10日目(05/06):AWS環境のトラブルシューティングした。図書館戦争の劇場版みた

今年は、連休前にちょっと仕事でトラブルががあって、そっちも気になってあんまり外出できませんでした。
※という言い訳。

ふと思い立って過去のGWを集めてみました。

今年は2012年以来の大規模インフラ更改だったかも

 

皆さんの10連休はいかがでしたか。

今日はお風呂にでもゆっくり浸かって。また明日から頑張って仕事しよ。

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

 

設定変えたの写真のアップロードテスト。

 

Leave a Comment

令和になったことだしクラウドへ移行する – 7 – t2.microでmariaDBが落ちる

ども。こんばんは。

昨日以降したAWS環境ですが早速トラブルです。

というかまぁ起きそうだなぁとは思ってましたが、メモリが足りずmariaDBが落ちてました。

[root@kusanagi80 blog]# more /var/log/mysql/mysqld.log

2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: The InnoDB memory heap is disabled
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Compressed tables use zlib 1.2.7
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Using Linux native AIO
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Using SSE crc32 instructions
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Initializing buffer pool, size = 384.0M
InnoDB: mmap(421724160 bytes) failed; errno 12
2019-05-06 10:23:26 140552243030272 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2019-05-06 10:23:26 140552243030272 [ERROR] Plugin ‘InnoDB’ init function returned error.
2019-05-06 10:23:26 140552243030272 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
2019-05-06 10:23:26 140552243030272 [Note] Plugin ‘FEEDBACK’ is disabled.
2019-05-06 10:23:26 140552243030272 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-05-06 10:23:26 140552243030272 [ERROR] Aborting

確かにちょいとメモリが足りないしswapがないんですよねー。

[root@kusanagi80 blog]# free -m

              total        used        free      shared  buff/cache   available
Mem:            989         678          73          76         237          81
Swap:             0           0           0

にいろんな方も同じ状況みたいで、swapを作る方法がありました。
t2.microでもssdだし、swap作っても大丈夫?かな。

参考:AWSのMySQLがよく落ちるのを解決 「Failed to start MariaDB」「InnoDB: Cannot allocate memory for the buffer pool」

手順は上記の参考サイトの通りですが、最後にfstabにも書きます(そうしないと起動時にswapがマウントされないので)

 

[root@kusanagi80 blog]# sudo dd if=/dev/zero of=/swapfile bs=1M count=1024

1024+0 レコード入力
1024+0 レコード出力
1073741824 バイト (1.1 GB) コピーされました、 35.3172 秒、 30.4 MB/秒

[root@kusanagi80 blog]# sudo mkswap /swapfile
スワップ空間バージョン1を設定します、サイズ = 1048572 KiB
ラベルはありません, UUID=81d4b5f0-bf32-4ea1-a3f5-3c4eaf7926a4
[root@kusanagi80 blog]# sudo swapon /swapfile
swapon: /swapfile: 安全でない権限 0644 を持ちます。 0600 がお勧めです。
[root@kusanagi80 blog]# sudo chmod 600 /swapfile
[root@kusanagi80 blog]# free -m

              total        used        free      shared  buff/cache   available

Mem:            989         670          83          76         235          92
Swap:          1023           0        1023

SWAPでけたー。仕上げにfstabに書いて、rebootしてswapできてたからokかな。

/swapfile swap swap defaults 0 0

さぁ、これで様子見ですね。

【追記】

また落ちました・・・。
2019年 GWの振り返り」の公開後、多分クローラーからのアクセスとかで落ちたっぽいです。
ロードアベレージが偉いことになってたのと、swapも結構浸かってしまってました。
参ったな。

以下ぱっと見た時のリソース。

こっからガッとswapへりました。多分mariaDB落ちたと思う。
※この手前でもしかしたらswap食い尽くしてたかも。

[root@kusanagi80 blog]# free -m

              total        used        free      shared  buff/cache   available
Mem:            989         857          66          10          65          12
Swap:          1023         620         403

top

top – 18:33:51 up  2:23,  1 user,  load average: 24.80, 14.64, 5.86
Tasks: 103 total,   1 running, 101 sleeping,   0 stopped,   1 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  1013192 total,   842544 free,    56472 used,   114176 buff/cache
KiB Swap:  1048572 total,   996736 free,    51836 used.   814284 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND  
9125 root      20   0  559436  23724  18016 S  0.0  2.3   0:00.04 php-fpm  
9130 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9131 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9132 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9133 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9134 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9135 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9126 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9127 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9128 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9129 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9106 httpd     20   0  126160   5240    908 S  0.0  0.5   0:00.00 nginx    
9107 httpd     20   0  124956   3680    856 S  0.0  0.4   0:00.00 nginx    
9108 httpd     20   0  124956   3680    856 S  0.0  0.4   0:00.00 nginx    
9105 root      20   0  124952   3004    392 S  0.0  0.3   0:00.00 nginx       
    1 root      20   0  191120   2496   1516 S  0.0  0.2   0:03.30 systemd  
9145 root      20   0  161880   2204   1564 R  0.0  0.2   0:00.00 top

ちょっと参ったな。swap2GBに増やしてみたので、これで様子見ですかねー。

 

 

【バックナンバー】

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

Leave a Comment

令和になったことだしクラウドへ移行する – 6 – ブログがAWSになりました。

ども。こんばんは。

件名のとおりです。

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

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

もちろん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やりなおし)。
      • サブディレクトリにWordPressを展開しているので多分効いてないKUSANAGIの機能がある気がする。
      • bcacheを効かせるには、多分以下の設定いれればいけるかも?
      • てか、KUSANAGIってそれ用のWordPressプラグインあるっぽいけどそのへんよくわかんない
      • あと、サブディレクトリに入れた関係か多分Let’s Encryptちゃんと動いてないと思う。
    • 引っ越しの仕方
      • BackWPupプラグインでファイルもDBの抜こうとしたが、旧環境だとPHPが2GB以上のファイルをP扱えなくてエラー(PHPバージョンで扱えない大きさのアーカイブになります。)でアーカイブがコケまくったので諦めた。
        • 一応古いPHPで2GB以上のファイルが扱えないことはないが再コンパイルなんて今さらやってられないのでスルー。
      • 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では外部→内部を処理するルールがなくなってしまう&監視するものがなくなってしまう。。

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

【バックナンバー】

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

Leave a Comment