タグ別アーカイブ: Lightsail

Amazon Lightsailの利用料金が半額になったのでインスタンスをスケールアップする

AWSのVPSサービスであるAmazon Lightsailの料金が半額になったという発表が有りました。値下げされた分、これまで最も低コスト・低スペックなプランを選択していたインスタンスをワンランク上のインスタンスにスケールアップしてみようと思います。

Lightsailについて

LightsailはEC2よりもかなり手頃なコストで仮想サーバーを利用する事ができる仮想サーバーです。VPC上にEC2を立てるよりは柔軟性が落ちる物の、固定IP設定、固定IP付け替え、スナップショット取得、ディスク追加、ロードバランサ―機能、ファイアウォール、DNS機能などが利用できます。また、安い利用料金にある程度のデータ転送料金も含んだ形になっているのでEC2よりも費用感が想定しやすいのもメリットです。

Lightsail
https://aws.amazon.com/jp/lightsail/

Amazon Lightsail が 50% の値下げと 2 つの新インスタンスサイズを発表
https://aws.amazon.com/jp/about-aws/whats-new/2018/08/amazon-lightsail-announces-50-percent-price-drop-and-two-new-instance-sizes/

これまで512MB RAMのインスタンスに月額5ドルを払っていた分で、新料金プランでは1GB RAMのプランを契約できるようになります。安くなった恩恵をそのまま受けてもいいのですが、512MBでは常時スワップを消費するような運用になっていたのでこの機会にスペックアップさせます。

要点

Lightsailインスタンスのスペックアップは「スナップショット取得」→「新マシン作成」→「静的IPの付け替え」で行います。これまで使っていた静的IPがそのまま使えるのでDNSの設定変更は不要です。ダウンタイムの発生はIPを付け替える際の1~2分程度です。

この手順を行うには以前はAWS CLIでの操作が必要だったようですが、現在はコンパネの操作で完結します。

手順

AWS マネジメントコンソールから Lightsail の画面に移動します。

最新のスナップショットを取得します。

作成したスナップショットから新規インスタンスを作成していきます。

インスタンスプランは3.5ドルのプランが初期選択になっているので5ドルのプランに変更します。

しばらく待つとインスタンスが起動します。

SSHで接続確認。

メモリが増えている事を確認。ディスクサイズがアップした分も自動で認識されています。

ファイアウォール設定はインスタンスごとになるので既存のファイアウォールと同じように適宜調整します。HTTPSが初期状態では開いていないのでHTTPSを追加しておきます。

Webブラウザから接続確認。IPアクセスの為証明書がエラーになる以外は問題なく接続可である事を確認。ミドルウェアのバージョンアップなどはこのタイミングで必要に応じて行っておきます。

インスタンスの画面からネットワーキングの画面に移動。静的パブリックIPの管理画面に移動。既存のインスタンスから「デタッチ」を行い、新しく起動したインスタンスに「アタッチ」し直します。間違って静的IPを削除したりしないように気を付けます。

新しいインスタンスを選択してアタッチ。

旧インスタンスで使っていた静的パブリックIPでSSH接続。メモリやディスク容量からも新しい方のインスタンスになっている事が確認できます。Webブラウザからも問題なくアクセスできることを確認。

もろもろ問題が無ければ旧インスタンスを削除。

これで切り替えは完了です。

旧インスタンスのスナップショットは残ったままなので適宜削除してください。また、新しいインスタンスのスナップショットが無い状態ですのでスナップショットも取得しておくといいと思います。

IPの付け替えにかかる時間は短くインスタンスの利用料金も1時間単位での課金(月額5ドルという数字は一か月起動したときの料金)ですので、Lightsailのスペックアップは気軽に検討して行けそうですね。


ブログをAzure WebAppsからAmazon Lightsailに移設してみた。良い所と引っかかった所など

無料版の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が使えることなどにメリットを感じるならなかなか良いんじゃないでしょうか。