去年の終わりから徐々に行っていた、
自前のサーバからAmazon EC2への移転がほぼ終了しました。
移転作業を始める前にはよくわかっていなかったけれど、
事前にわかっていれば移転判断の助けになっていたかもしれないポイントをまとめてみます。
-
OSについて
Amazon EC2はLinuxをベースにした独自OSを採用しています。
yumなどでインストールするアプリケーションも専用のリポジトリを利用できるので高速です。
言語設定はUTF8がデフォルトなので場合によっては最適化が必要です。 -
Apacheについて
Apacheはデフォルトでインストールされています。
設定方法もCentOSなどと変わりません。
多くの場合特別なチューニングは必要としないでしょう。
今回はバーチャルホストで運用したのでその部分は追加設定しています。 -
PHPについて
デフォルトで用意されているバージョンは5.3でした。
PHPのフレームワークを利用していると移転に支障がでるので注意した方がいいと思います。
今回はフレームワークのバージョンアップを無理矢理行いました。
もっとも失敗だった部分です。 -
MySQLについて
今回はAmazon RDSを利用しました。
VPCを使ってもIPアドレスが変更される可能性がある(フェイルオーバーなどでも)そうなので
DBサーバのアドレス指定にはエンドポイント(ホスト名)を指定する必要があります。
定義が一つだけだと変更も楽ですが、複数箇所の書き換えが必要な場合は注意するべきです。 -
EBSブートを基本形態に
EC2はダウンさせると設定などが消えてしまうので、
そうならないようにEBSブートを選択しておくべきです。 -
バックアップについて
多くの場合、AMIのスナップショットを一か月に数回取得するだけで大丈夫だと思います。
1日単位で頻繁にコンテンツが書き換えられ、本番サーバしかない場合は
別のバックアップ方法を検討した方がいいかもしれません。
取得したAMIはそのままインスタンス化することができますが、
サーバ証明書が書き換わるっぽいのでSSHやSSLを利用している場合は実際に起動させてみて確認した方がいいと思います。 -
転送速度
それほどアップロード、ダウンロード速度が速くない印象なので
大容量のデータを少ないクライアントで操作するような用途にはそもそも向いていません。
別途専用サーバなどを契約した方が幸せになれそうです。 -
セキュリティー
簡単なF/W機能がAmazonのコントロールパネルで提供されます。
IPやポートの制限だけならこれだけで十分です。
sudoなどOSレベルの制限には個別の対応が必要です。 -
Amazon EC2に移転して幸せになれるか
自社でサーバを維持していて、月額数十万円以上払っているなら検討する価値があります。
場合によっては保守費を大幅に圧縮できる可能性があります。
ただ、公開サーバではなく社内インフラの一部だったり大容量のデータを扱う場合は
べつのクラウドサービスを同時に検討した方がいいと思います。
今回移転したサービスは単純なWEBサイトとCMS(MT)だったので大きなトラブルは発生しませんでした。
メモリやディスクなどのリソースが大幅に増えたにもかかわらず運用費は半減です。
メモリ容量の逼迫にWEBアプリケーション軽量化であくせく対応するくらいなら
AmazonEC2などを検討した方がいいかもしれません。