事の起こり
ある時、ホームページが落ちていることに気がついた。正確には、TOPページは表示されるけど個別ページを見に行くとエラーで表示されないというもの。
再起動すると復活するけど、しばらくすると同じようにエラーになる。そして、管理画面に行こうとするとnginxのエラー画面が。。。
あれ？ これって、t1.microでトラブったあれか？
AMIMOTOでT1からT1へのお引越し
問い合わせてみると、「HHVMでt2.microだとメモリ足りません」的な回答が。なるほど、引越しだな！
よし、移行ついでにSSLだ
あれですな、HTTP/2とかでSSLってやつですよ（←よくわかってない
うむ。
手順途中で迷子になる（笑
なんか、基本的なところで勘違いしてるに違いないと、４回目の失敗でサジ投げるw
smallで逃げる
これではいかんと、元のインスタンスサイズを上げて対応してみたが、やはり定期的に死んじゃう（涙
料金倍増でも死ぬって何の苦行だw
死活監視でしょ！
Lambdaでページチェックを定期実行して200じゃなければslackへ通知だよね！ 通知来たら再起動って流れでどうだ！
インスタンスのステータスも2/2で正常だし、こういう場合にcloudwatchで使えるメトリクス無いんだよなぁ。。。カスタムなの作るのはハードル高いしねぇ。
結果はブラウザから見れないにもかかわらず、、、
”kintone スモールオフィスシリーズ 「kintone 050オフィス」: http://okiyasu.biz/?p=541 にアクセスして HTTP 200 が返ってきました. 通知はスキップします”
あ、だめだ、チェックできてないw
あ、cloudwatchで自動rebootだな
定期チェックで低い負荷がかかってるので、CPU負荷が閾値下回ったら再起動で良いんじゃない？ という、個人ブログなので、適当な感じで自動rebootするようにしてみたら、何とかなりました。
以前と同じくエラーにはなるけど、チェック→再起動が自動で走るので、長時間落ちてることは無くなった感じ。
WooCommerce？
とはいえ、このままではいかんと思い再度挑戦するべくみてみると・・・・、あれ、前のAMIが使用終了になってる。
聞いてみると、新しいAMIMOTOは全てHTTP/2対応なので、どれ選んでも大丈夫との事。
うむ、一度普通にインスタンス立ててみよう！
WooCommerce Powered by AMIMOTO (Apache HTTPD PHP7)
ついでにWooCommerceをだね、、、、すみません、設定項目多くてうまく動きませんでしたw
まぁ、何かの時にー。
移行作業
元WordPressの管理画面から、ツールでエクスポートして内容をバックアップ。新しいWordPressへインポートしてみると、画像を自動読み込みとかのチェックを発見！
ほほぅ、これで画像の移動でsftpで接続とかの手順がなくても大丈夫なのねー。と、やってみると、新しいインスタンスのIPで書き換わってしまいましたw
なるほど、サイトAからサイトBに移行する場合とかには良いけど、サイトAを別インスタンスのサイトAにする場合は細工が必要なのか！
次回、ちゃんとしようね＞自分
安定のt2.micro
という事で、おなじみのt2.microで再出発です。タイトルも3rdになっておりますw
まぁ、画像とかをS3保存にして、DBをRDSに持っていけば、ELBでオートスケール出来るといえばそうなんですけどねー。なんかのタイミングで色々と対応してみたいと思います。
実は業務でホームページ作成とかやってない（どころか、AWS自体を仕事で使わせてくれない）ので、こうやって定期的に移行作業とかやるのが丁度いい練習になります。
作業レベルが甘いんですけどねー（爆