馬とテニスのIT革命
馬とテニスとリラックマが好きな IT 系のエンジニアです。
エンジニア

さくらインターネットからAWSへ全サイト移行する

初めて「さくらインターネット」のレンタルサーバを借りたのが 2006 年。

その時はスタンダードプランを契約しましたが、そこから仕事の兼ね合いもあって最終的に 6 アカウント分の契約をしました。

さすがに落ちてもいいサービスのホスティングには使えませんが、そこまでシビアじゃないサイトには最適でした。

スタンダードプランのコスパ最高

スタンダードプランのいいところは、とにかく安くて美味いところ。

値段ならもっと安いレンタルサーバはありますが自由度が高いのです。

また、ハードウェアは時代に合わせて調整してくれるので、最初は数ギガバイトしか割り当てられていなかったハードディスクも最終的に 100GB にまで増えました。

さくらインターネットの良かったところ

他にもこんないいところがありました。

ssh でシェルにログインできる
PHP も MySQL も早い段階でバージョンアップが用意される
アクセスログが残せる
ドメインが 20 個まで紐付けできる

シェルが使えると、サイト内のランキング集計とかバッチで処理させられるので楽です。

またブラウザの管理画面からだと cron が 5 個までしか設定できませんが、コンソールから crontab -e で編集すれば何個でもタスクが登録できます。

アクセスログから 404 や 500 のログを抜き出したり、mysqldump で定期的に MySQL の DB の内容をダンプしたりと運用に必要な作業はすべてバッチ化しました。

ちなみに、DB のバックアップは同じサーバ上に置いておいても意味がないので、圧縮してメールに添付して gmail に送信しています。

特にセキュアなデータは扱っていないので、gmail をバックアップストレージ代わりにしていました。

さくらの不便だったところ

もちろん、良いところもあれば不満だったところもあります。

OS が FreeBSD
共有サーバなので他のアカウントに引きずられる
ハードウェア故障でメンテナンスが入る

まず、OS が FreeBSD なので Linux 感覚でコンソール使っていると、若干の違和感を感じると思います。

また共有サーバなので、他のアカウントが重い処理をすると必然的に負荷のあおりを食らいます。

これはお互い様ですし、ある程度 1 アカウントのリソースの上限値は決められて制御されているので、そこまで気にするものではなさそうですが・・・。

ハードウェア故障や故障検知も、メンテナンス情報をチェックしておかないと、いつの間にかメンテになっていてサイトが繋がらないとかあるので要注意です。

例えば、データベースにメンテナンスが入る時は Web サーバ側で 503 を返すようにするとか、一時的に他のサイトにリダイレクトするなど準備しておきたいですね。

AWSへの移行を考えた理由

純粋にアクセスの多いサイトが増えてきたので、共有サーバのリソースだと辛くなってきたということです。

それほどアクセスの多くないサイトをホスティングしていたサーバでしたが、504 レスポンスが増えてきたので、問い合わせをしたらそのような回答が返ってきました。

「そういったサーバなのでご了承ください」という、アッサリしたメールだったので、他のサイトも不安だなっと思って移行を検討したわけです。

もちろん「さくらのVPS」も候補ではあったのですが、AWS の VPC が魅力的に感じたので・・・。

AWSの無料枠から構成を考える

さて、AWS は従量課金の要素が多いためか、個人で使う分には消極的になる人が結構いるようです。

私もどうせなら最初の 1 年は無料の範囲でと思っていましたが、構成を考えた段階で無理だと気付きました(笑)

パっと思い付いたのが、こんな構成イメージでした。

ゲートウェイサーバ(CIサーバ用途でも使う)
Web サーバ(2台)
ロードバランサ(ELB)
MySQLデータベース(RDS)
Redis(ElastiCache)
DNS(Route53)
画像のキャッシュ(CloudFront)
バックアップ置き場(S3)

徐々にサイトを移行していくこともあり、Web サーバは最初は 1 台でいいということにして 2 台構成は止めました。

AMI(アマゾンマシンイメージ)を作っておけば、最悪インスタンスは復活できるのでそれで良しとしました。

外部からの ssh はゲートウェイだけにしておいて、Web サーバは VPC 内のプライベートな IP からのみ(ELB経由になるので)アクセスを受け付けるようにしました。

無料枠をあっさり超えました

さて、この時点で既に無料枠をオーバーしています(笑)

EC2 のインスタンスが 2 台なので、1 台分は費用が掛かります。

また、Route53 でドメインを 1 つ追加する度に 50 セントの費用が掛かります。

よって、EC2 の t2.micro インスタンス用のリザーブドインスタンスを 1 台分購入することにしました。

24 時間 365 日稼働させるのであれば、リザーブドインスタンスを購入することで 3 割くらいコストカットが可能です。

あと 1 つ大きなミスを犯しました。

データベースはマスタ・スレーブ構成がいいだろうと思ってマスタからレプリカを作成してスレーブ用途にしたのですが、レプリカの分は費用が掛かってしまうのですよね。

請求情報をチェックしていて、RDS の料金が加算されていたので発覚しました。

運用実績

AWS のアカウントを取得して 10 ヶ月。

RDS の構成をミスったことも大きかったですが、他にも Web サーバのキャッシュやログでデフォルトの 8GB じゃ収まらなくなったことから容量を 40GB に増やしたのですが、無料枠が 30GB までという罠(自分の調査不足)。

また、ドメインを 20 個前後 Route53 で管理しているので毎月 10 ドルは嫌でも発生します。

あと、AMI を作る際のスナップショットの容量が課金されることに気付いていなかったので、いつの間にか課金が発生していて焦ることもしばしば。

最近 RDS をマスタのみの構成にして無料枠期間の終わりに備えましたが、それでも最近は毎月 30 ドルくらい支払っています。

トラフィックの無料枠超過もありますが、やはり無料枠の詳細な条件や従量課金が発生するサービスなど、このくらいいけるでしょって感覚で使っていたのがアダになったようです。

あと、S3 は今のところ使っていません。

データベースやアクセスログのバックアップを置こうと考えていたのですが、データベースのバックアップはさくらの頃と同じく gmail に送って、アクセスログは cron で定期的に撲滅しています(爆)

無料枠期間の終了に向けて

さて、あと数ヶ月もすると無料枠の期間が終了しますが、そこでどのくらいコストが増大するのか不安な部分もあります。

ただ、今の構成から気軽に外せるものは CloudFront くらいなので、すぐにリザーブドインスタンスの購入ですね。

なお、RDS はレプリカ用に購入したリザーブドインスタンスがあるので、それで当面は代用です。

もちろん、AZ(Availability Zone)は今のマスタに合わせてあるので、なぜかリザーブドインスタンスが適用されてないっていうトラブルも心配なさそうです。

商用サービスをする場合はケチってばかりもいられませんが、ある程度のトラフィック計算やサイトの成長を見越してインスタンスタイプを決めておくといいと思います。

Web サーバなどは AutoScaling で困った時に増やせばいいやと思いがちですが、リザーブドインスタンスを何個購入しておくのか、どのインスタンスタイプのものを購入しておくのか、どの AZ のものを購入するのか、悩みどころは多いです。

このリザーブドインスタンスが AZ 別になっているのはどうにかして欲しいですよね。

Web API The Good Parts

オライリーの「Web API」に特化した本です。最近の多くの Web サービスは API が活用されていますが、その技術はこれまでの Web サイトとそれほど大きく変わりません。

今後、マイクロサービス化が進む中で知っておいて損はない内容が詰め込まれており、現場のエンジニアやこれから Web 系のエンジニアを目指す人にもオススメの一冊です。

created by Rinker
¥2,376
(2018/10/15 13:40:38時点 Amazon調べ-詳細)

あなたにオススメ