無料版のAzure WebAppsはそれなりに良い物だったのですが、いかんせんスペック不足過ぎており、上位のプランにアップしようと思うといきなり数千円からという価格になってくるため、AWSのAmazon EC2よりもお安く使えるAmazon Lightsailに移設してみました。
EC2(AWSにおけるIaaSなクラウドサーバ)とLightsail(AWSにおけるVPS)の違いは以下のようになっております。
Amazon EC2
- 完全従量課金で1時間単位の課金。
- ネットワーク使用量についても従量課金。
- スケールアップ、スケールダウンがいつでも自由にできる。
- ディスクの拡張も比較的容易。
- オートスケーリングを用いたスケールアウト、スケールインも（動かすプログラムが対応していれば）簡単。
- VPCでの様々なネットワーク制御。
- IAMによる細かな権限制御。
Amazon Lightsail
- マシン自体は月額定額制の固定料金（5ドル～）。スナップショットについては容量に応じた従量課金。
- ネットワーク使用量に比較的大きめ（1TB～）の無料枠有り。
- ディスク容量はプランごとに固定。
- スケールアップする場合はスナップショット作成からの新マシン作成となる。
- EC2のコンパネとは色々と勝手が異なる。EC2のVPCとも異なるのでVPC関連で出来る事でLightsailでは出来ない事が多々ある。
- 中身はEC2のt2インスタンス（のような物）だと思われる。ハイエンドな性能は求められない。
- 他のVPSサービスとは異なり、EC2と同じ「Amazon Linux」が使える。
今回はt2.nanoベースと思われる月額5ドルのプランにしてみました。nanoインスタンスはCPUクレジットに不安が残るものの、今のところ明らかにAzure WebApps 無料プランよりは快適に動いています。
以下、移設の中で引っかかった所をまとめておきます。
LightsailのDNS機能はRoute53側でネームサーバーの変更が必要
LightsailにはAmazon Route53とは別のDNS管理機能が有り、一般的なVPSサーバを建てるための設定が全てLighsail側で完結するようになっているのですが、ここでRoute53でドメインを取得しているとひと手間必要になります。
Route53で新規取得したドメインは自動でNSレコードやSOAレコードがRoute53側に設定されますが、LightsailのDNS管理機能を使うにはここでネームサーバの指定をLighsailのDNS機能のネームサーバーへ変更してやる必要が有ります。
考えてみれば当たり前なのですが気づくのに結構時間がかかりました。ネームサーバの指定は例えばGoogle Plubic DNSのキャッシュ フラッシュ機能でもフラッシュ出来ないので、結構な時間変更の反映を待つ形になります。仕方が無いのでRoute53側でも一次的なAレコードを追加しました。
今思うとドメイン関連は、Route53だけで完結させても良かった気がします。
WordPressのサイトURL変更
昔SQLでパパっと変更すればOKだったような気がしますが、実際にはテキストではない形でデータを持っている部分も有りダメという情報を見かけました。
サイト URL の変更 – WordPress Codex 日本語版
https://wpdocs.osdn.jp/%E3%82%B5%E3%82%A4%E3%83%88_URL_%E3%81%AE%E5%A4%89%E6%9B%B4
上記を参考にwp-login.phpに一次的に
update_option('siteurl','http://example.com/');
update_option('home','http://example.com');
を記載する形で対応しました。
動かない301リダイレクト系プラグイン
WordPressはサイト移設時に行う301リダイレクトについてもプラグインがいくつか有り、移行元サイトの方で「Simple 301 Redirects」「Redirection」等を試してみたのですが、なぜか動かない。もしかしてHTTPヘッダの送出ではなく.htaccessファイルを作るなど、Apacheであること前提のプラグインだったりするんでしょうか？（未確認）
仕方が無いので（Azure WebAppsはIISなので）web.configを編集して対応しました。
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<!--
もともとWordPressを動かすために書いてあったURLリライトルール
-->
<rule name="Redirect All" stopProcessing="true">
<match url="(.*)"/>
<action type="Redirect" url="http://www.sodo-shed.com/{R:1}" redirectType="Permanent"></action>
</rule>
<!-- 以下略
これで問題なく新サイトへのパス指定を維持したリダイレクトが動いています。最初からこれでよかったですね。
OOM Killerで死ぬMySQL
最初からメモリが少ない（一番下の月額5ドルのプランは512MB）事が分かっているので、
innodb_buffer_pool_size=64M
にするなど相当にしょっぱい設定にしていましたが、それでもMySQLが起動しません。スワップ領域を追加する事で起動するようになりました。
Amazon EC2, mysql aborting start because InnoDB: mmap (x bytes) failed; errno 12
https://stackoverflow.com/questions/10284532/amazon-ec2-mysql-aborting-start-because-innodb-mmap-x-bytes-failed-errno-12
に記載の方法で追加（以下引用）。
Run dd if=/dev/zero of=/swapfile bs=1M count=1024
Run mkswap /swapfile
Run swapon /swapfile
Add this line /swapfile swap swap defaults 0 0 to /etc/fstab
私は1024MBではなく2048MBでスワップを作成しました。一度の接続数が10に満たないサイトですが、以下のようなメモリ使用状況になります。vm.swappinessは20に設定しています。
$ free -m
total used free shared buffers cached
Mem: 89 473 16 33 41 85
-/+ buffers/cache: 345 143
Swap: 2047 336 1711
月額10ドルのプランではメモリが1GB有るので、お試しでも512MBはちょっと……という方はそちらを選ぶといいと思います。
CPUクレジット残高の確認方法が無い
前述のようにt2系インスタンス（と同じような制御の物）を使っている可能性が高いのですが
Amazon Lightsailのベンチマーク – 稲葉サーバーデザイン
https://inaba-serverdesign.jp/blog/20161208/aws_lightsail_benchmark.html
t2系では重要なCPUクレジットバランス（CPUクレジット残高）を確認する方法が、すくなくともマネジメントコンソール上では見当たりません。CloudWatch側のメトリクスにも有りません。
t2系インスタンスはクレジットが枯渇しそうでないか、だけを見ればCPUについて今のスペックが適切かどうかが分かりますが、それが無いのでサーバー監視の設定は何かしら別で用意した方がよさそうです。
まとめ
他にも何かあったような気がしますが、CPUクレジット以外については当たり前と言えば当たり前に必要になる対応なので、逆にそれ以外は特殊なことは無く、EC2でAmazon Linuxを立ち上げるような気持ちではるかに格安なサーバーを建てる事が可能でした。価格重視だと国内VPSにも種類は多いですが、AWSである事、VPC間接続でEC2 VPCとの接続が可能である事、その他AWSで提供されるサービスとの親和性、Amazon Linuxが使えることなどにメリットを感じるならなかなか良いんじゃないでしょうか。
