サーバ増強の記録

Share on Facebook14Tweet about this on TwitterShare on Google+0Share on LinkedIn0

こんにちは、mi2yo4です。
今日は書こう書こうと考えていたこの2月に行ったサーバ増強の話を書いてみます。

0a3dae3989031cc2168cfcfafb123b96_s

(2月の話ですが)サーバ設備を増強しました!

弊社のサービス、「あぐりログ」のサーバ増強をこの2月の終わりに行いました。
年初にあぐりログのサーバダウンという大きなトラブルを起こしたのは記憶に新しいと思います。本来の計画では負荷の増加を見越し、この7-8月ぐらいにサーバ増強の計画を立てていましたが、このトラブルで急遽前倒しで計画を実行するようになりました。

これまでのサーバ構成の歩み

これまでのサーバ構成と現在のサーバ構成について時系列で書いてみます。

サービス黎明期(2014/10以前~2015/1)

基本的に1台のサーバで賄う時代
311348all

走り始めのサービスで、ユーザーが付いていません。なので、投資は最小限にしたいし!

という事で、あぐりログを構成する主要なサービス(Webサーバ,DBサーバ等)は1台で賄っていました。
全て1台で済むので確認も簡単ですが、サービス走り始めの頃は今のようにデプロイスクリプトを組んでいなかったので、色々と置き換えミスをやったような気がします…orz

バックアップは社内PCにサーバのデータベース他を毎日フルバックアップしていました。

試験サービス開始後(2015/1~2016/11)

Web,DBサーバ+APIサーバ+バックアップ

web_database_api

2014年10月に試験サービスを開始。
2015年の2月にはあぐりログで使用している「ミドルウェアパッケージ」の置き換えを計画しました。
導入当初からこのミドルウェアパッケージは、いわゆる「枯れた」状態のものを採用していたのですが、いかんせん古くなりすぎて来た事による弊害の方が大きいのでは?という懸念があったためです。

そして、あぐりログサービスを更新する際に一気に全てを書き換えるビッグバン的に行うか、既存の資産を活かしつつゆっくり少しずつ移行するかで社内で議論がされました。

結果から言えば後者の「既存の資産を活かしつつ少しずつ移行する」やり方を採用しています。
ビッグバン的な書き換えを行うには、全てのソースコードを書き換えるぐらいの作業量になるので、とても時間がかかる事が予想されます。
となると書き換え作業している間、既存のサービスの改善はどうなるのでしょうか?
おそらく社内リソース的にも書き換え作業により既存サービスの改善は停滞すると判断し、それを避けたいという思いがあったからです。

これにより以降の新しい機能は別サーバに展開しました。
具体的には、外部にAPIサーバを建ててPCやスマートフォンからの計測データ等の取得はAPIサーバを参照するようにしました。
これまでのサーバは基本的なWeb,Databaseサーバとして運用という形にしました。

ただ、これでも負荷としてはWeb,Databaseサーバの方がやる事が多いので高かったですね。

この頃から顧客から預かったデータを無くしてはいけない、という事でバックアップ体制については、色々と改善の歴史があります。

当初は1日1回のフルバックアップ体制でしたが、オペミスによるトラブルが起こったため見直しを行いました。
結果的に社内PCから1日1回のタイミングで計測値以外のテーブルはフルバックアップ、計測値に関しては前日分の更新データをファイルバックアップ、併せてトランザクションログを20分毎にバックアップするようになりました。

ただ、巷でよく行われているバックアップ方法とはちょっと違いますよね。
計測値に関してもフルバックアップを行いたかったのですが、バックアップの際に元々負荷の高かったWeb,Databaseサーバにかなりの負荷をかける事がわかったため、データ量の多い計測値は差分バックアップを積み重ねていました。

稼働数400を超えたあたり(2016/12-)

Webサーバ+APIサーバ+DBサーバ+バックアップ

311348later

稼働数400を超えて、500に近づこうかという時に、いよいよデータベースの負荷が大きくなってきました。
この頃から一番負荷の大きかったWeb,Databaseサーバがその負荷のため色々と小さなトラブルを起こし始めてきました。
これを何とかしなきゃ…と思っている間に、年初の大きなトラブルに繋がりましたorz

何とかトラブルに対処し、計画を前倒しして以前から負荷の大きかったWeb,Database周りの改善を実行。
弊社で使っていたDatabaseはMySQLですが、以下の問題がありました。

  • バージョンが古い(5.1.xx)
  • データベースエンジンにMyISAMを使用しているテーブルが多い

MySQL 5.1の公式プロダクトライフサイクルは2013/12/31いっぱいで終了となっています。CentOSの方でパッチを提供し続ける可能性もありますが、それもあと数年の話でしょう。
以前からアップグレードしなくては…という話が上がっていましたが、他の業務を優先したため後回し状態だったのが良くなかったと判断。
これを機に新しくDatabaseサーバを立ち上げ、更にMySQLのバージョンを5.5にアップグレードを考えました。
また、MyISAMを使っている限りバックアップに支障が起こる可能性が否定できない、普段の使い勝手が悪いのと、MySQL5.5からはInnoDBがデフォルトのストレージエンジンという事を考えストレージエンジン変更もやっておきたい。

これらの事から下記のように計画を立案しました。

  • Web,Databaseサーバを機能分割、別サーバに展開
  • Databaseエンジンのバージョンアップ(5.1→5.5)
  • ストレージエンジンをMyISAMからInnoDBに変更
  • データベースサーバを冗長化、Databaseサーバ、レプリカサーバ、バックアップサーバの3つ

レプリカサーバとバックアップサーバの違いが図からはよく判りませんが、説明すると以下のようになります。

  • レプリカサーバはDatabaseサーバを常時複製(レプリケーション)しています。Databaseサーバにトラブルが起きた場合、レプリカサーバを新Databaseサーバとして運用します
  • バックアップサーバはDatabaseサーバをほぼ常時複製しています。バックアップの際にレプリケーションを一時停止し、フルバックアップを行います

バックアップサーバを専用に用意したことで、本番サーバではバックアップ時の負荷について考慮しなくてもOKな仕組みに変更。

移行時に少しトラブルがありましたが、それ以外は順調です。
これはもっと早めにやっておいても良かったですね。それぐらい日々のサービス提供に安心が持てるようになりました。

これからのサーバ構成計画

あぐりログは成長し続けるサービスなので、サーバ構成についても時期を見て手直しをするようにしなければいけません。

現状で考えているのはMySQLのバージョンアップです。最新はMySQL5.7.xとなっています。
MySQLは1バージョンずつのみのアップグレード保証となっていますので、次はMySQL5.6ですね~。

という事で、MySQL5.5から5.6へのアップグレード情報について色々と調べている昨今です。

いかがだったでしょうか?

あぐりログのサービスの裏側ではこのようなサーバが色々と動いていて、日々進化し続けています。
私も一緒にあぐりログのサービスを改善したい!と思った方、只今メンバー募集していますので是非とも応募してみて下さいね。

それではまた!