メディアマーカー Archive

たびたびのサービス停止で、
たいへんご迷惑をおかけしております。

サーバーが重くなる主要因は、
登録や編集などのデータ更新が集中すると、
データベースのテーブルがロックしてしまうためでした。

最近では、CNETなどで紹介いただいた結果、
新規ユーザーのメディア登録が集中してロックする、
という流れでした。

あまりに頻発するようになってきたので、
今回のメンテナンスとなりました。

　
　
現在、データベースには MySQL を利用しており、
ストレージエンジン MyISAM でテーブルを作成しています。

MySQLには別のストレージエンジン innoDB もあり、
比較すると以下のような特徴があります。

内容	MyISAM	innoDB
ロック形式	テーブル単位	行単位
平行性	低い	高い
CPU負荷	低い	高い
データサイズ	小さい	大きい
Read速度	速い	遅い
全文検索	可	不可

　
一般的には、参照が多いなら MyISAM、
ひんぱんに更新するなら innoDB と言われています。

これまで速度を重視して MyISAM を利用していましたが、
平行性の高い innoDB を試すのが今回のメンテナンス目的でした。

　
　
その結果は、
現在のサーバー環境では厳しいようです(^^ゞ

　
テストではCPU負荷が急増してしまい、
表示されるのに2倍以上の時間がかかってしまいました。

CPU性能が良かったりデータ量が少なければ、
また違った結果になったのかもしれませんが…。

多少の速度ダウンは仕方ないと思っていましたが、
あまりにも遅すぎてムリでした。

　
やっぱり、メディアマーカーは、サクサク動かないと！

　
　
次の対策として、
データベース用メモリ領域を約2倍することで対応しました。

メモリ上で高速処理すれば、
ある程度の集中なら耐えられるようになると思います。

そのぶん、メール処理などに影響があるかもしれませんが、
そのあたりなら許容範囲内でしょう。

　
次は、アクセス集中時に制限をかけたり、
ダウンしてもスグ復旧できるようにするなど、
バックアップ的な仕組みを検討したいと思います。

　
MyISAM から innoDBへ変換してテスト、
また元に戻して別の対策を行うなどした結果、
長時間のサービス停止となりました。

ご協力いただきありがとうございました。

今後もより良いサービスを目指して、
がんばっていきたいと思います。

4/25にCNETで紹介されてから、
たびたびアクセス障害が発生しておりご迷惑をおかけしております。

（CNET掲載、ありがとうございました～）

主な原因は、アクセス集中と日次データの更新負荷で、
対策としてサーバー設定を見直すことにしました。

　
まずは、ブルートフォースアタック対策の強化。

連続してパスワードを間違えたら、
数時間アクセスできないようにしました。

これで、サーバー攻撃は減るハズですが、
自分が締め出されないように気をつけないと(^^ゞ

　
次に、一部の検索エンジンクローラーをアクセス禁止に。

以前にも対策していますが、
さらに対象ロボットを増やしておきました。

　
最後に、日次データ更新の見直し。

これまで、深夜に集中して更新していたんですが、
ある程度分散して作業するように変更しました。

　
さて、これで安定するといいんですが。（←頼む～）

それなりに改善したハズなので、
しばらく様子を見たいと思います。