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

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

AWSさくらインターネットから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 別になっているのはどうにかして欲しいですよね。

参考

AWS(アマゾンウェブサービス)

さくらインターネット

最終更新日:

関連記事

人気記事

新着情報