負荷分散勉強会

負荷分散勉強会
〜Webシステムの運用で試行錯誤したこと〜

株式会社シーエー・アドバンス
大谷祐司

Copyright © 2012 CAADvance, Inc. All Rights Reserved.

自己紹介

大谷祐司
(株式会社シーエー・アドバンス技術責任者)
出身：山口県下関市
年齢：３２歳
趣味：プログラミング、技術系の勉強、車
はまっているもの：自転車

2009年：サイバーエージェント入社。
2011年：シーエー・アドバンスに出向。
その前：人材会社で仕事の紹介をしていました。

シーエー・アドバンスの紹介


シーエー・アドバンスってどんな会社？

2008年に、サイバーエージェントの子会社として設
立。

インターネットメディアや広告の運用に関連する事業
を中心に行っている会社です。


シーエー・アドバンスってどんな会社？

従業員数は約300人で、東京と沖縄に事業所がありま
す。
(東京約50名、沖縄約250名)

私も毎月沖縄出張しています。
(オフィスとホテルの往復ですが・・・)


勉強会で対象にするシステム


■ 勉強会で対象にするシステム

リスティング広告運用プラットフォーム

Search Suite(サーチスイート)


■ Search Suiteについて

概要：
・リスティング広告の運用をサポート。
・いわゆる社内システム。
・約500名のユーザが存在。
・30以上のサブシステムが乗っています。


■ Search Suiteについて

特徴：
・扱うデータが大きい。
・データ集計などで負荷の高い処理が多い。
・土日、祝日はほとんどアクセスが無い。

私はサイバーエージェントに入社してからずっと、
Search Suiteの開発・運用に関わってきました。


■ リスティング広告とは

・検索エンジンの結果画面に表示される広告。
・Yahoo!, Googleが大きなシェアを持っています。



・キーワード毎に入札を行い、表示順番が決まる。
・大型のクライアントは数百万キーワードに入札します。



赤枠の部分が広告です。


■ Search Suite 開発の経緯

私が入社当初の2009年、社内ではリスティング広告の運用に
とても多くの時間がかかっていました。

Excel上のコピー&ペーストを繰り返したり、Yahoo!やGoogle
の用意する管理画面から１つづつレポートデータをダウンロー
ドして並び替えたり。


■ Search Suite 開発の経緯

リスティング広告の運用をシステムで効率化して、オペレー
ションのスピードと正確性でサイバーエージェントの競争力
を高めていく。

これを実現すべく開発されたのが「Search Suite」です。


本日は「レポート機能」で行った
負荷対策をメインでご紹介します。


■ レポート機能の概要

・クライアントに提出するレポートを作成する。
・システム負荷が高くて運用が大変。


■ レポート機能の概要

Yahoo!やGoogleからAPIで広告の実績データを取得。

⬇
Search SuiteのDBに蓄積。

⬇
集計してExcelファイルで出力。


■ レポートデータ取り込み/出力の概要図

Intranet

Internet

Batch Web

DB


■ リスティング広告のレポートデータ

リスティング広告の階層構造

クライアント人材会社XXXX 保険代理店XXXX

アカウント

アルバイト採用システムアルバイト採用システム火災保険生命保険保険見火災保険生命保険保険見
キーワードエンジニア転職採用試験
内定人材派遣人材紹介派
エンジニア転職採用試験
内定人材派遣人材紹介派
直し地震保険自動車保険
保険見積もり保険代理店
直し地震保険自動車保険
保険見積もり保険代理店
遣登録ヘッドハンティン遣登録ヘッドハンティン新築アパート水害保険安新築アパート水害保険安
グ派遣会社人材紹介会社グ派遣会社人材紹介会社い保険保険更新保険見積い保険保険更新保険見積
年収退職交渉内定承諾採年収退職交渉内定承諾採もり安い自動車保険もり安い自動車保険
用試験 etc・・・用試験 etc・・・ etc・・・ etc・・・


■ レポートデータの量

アカウント単位のレポート

約2,500レコード/日(約100万/年)


■ レポートデータの量

キーワード単位のレポート

約160万レコード/日(約6億/年)


どのようにして、ユーザーが見たいレポートを早く
正確に出力できるようにするか。

本日は、これまでに行ってきた処理の効率化や負荷
分散の対策をお話ししたいと思います。


Search Suite システム構成


■ Search Suite システム構成

LAMP環境で構築しています。

○ OS ：Linux(CentOS 5)
○ 言語：PHP5.3
○ Webサーバ：Apache2.2
○ DB ：MySQL5.5
○ キャッシュ：Memcached
○ フレームワーク：未使用


■ 保持しているデータのサイズ

総レコード数：約63億
増加頻度：300万レコード/日
容量：約4.3T

ほとんどが、レポートデータです。


現在の状態にするまでに、たくさんの試行
錯誤がありました。

今日はリリースから現在までの4年間に
行ってきた対策を、凝縮してお伝えしま
す。


ステージ１

とりあえずWebサービスを作る。


■ システムリリースまで

入社してすぐ、リスティング広告の運用における
問題解決のためにWebサービスを構築することに
なりました。

・社内マスタ管理
・売り上げ管理

この２つ機能を持ったシステムの開発です。
社内にサーバを置き、イントラネットで公開する
ことにしました。


■ システムリリースまで

この時のレポートは「アカウント単位」のみを持っ
ています。

アカウント単位のレポート

約2500レコード/日(約100万/年)


■ 与えられたサーバー

システム構築用に、終了したWebサービスで使っ
ていた中古のサーバが1台割り当てられました。

とりあえずそのサーバでシステム構築を進めるこ
とになりました。



ハードウェア：Dell Power Edge 650 (2003年製)
CPU ：Pentium4 3.06GHz
メモリ：4G
HDD ：120G



・当時でも非常に低いスペックでした。

・入社したばかりで「サーバ買ってくれ」と主張
できませんでした。

・ひとまず社内のサーバルームに置くことにしました。


■ リリース当初のDB

下記のようにDBを構築しました。

・MySQL5.1
・my.cnfはデフォルトのまま。
・ストレージエンジンは全てMyISAM。
・インデックスは張らない。
・定期的なバックアップはとらない。


リリースしましたが、すぐに問題が
発生しました。


■ リリース当初に発生した問題

① テーブルのロック待ちが頻発し、画面が固まる。
② トップページの「売上推移」表示に時間がかかる。
③ 深夜のレポート取り込みバッチが朝までに終わらない。


■ リリース当初の問題点 ①

問題点：テーブルのロックにより、画面が固まる。

対策：テーブルをMyISAMからInnoDBに変更。



MyISAMはデータ参照時にテーブル単位でロックしま
す。

重いクエリでjoinを行うと長時間テーブルがロック
されたままになってしまいます。

Select

Select MyISAM Select



InnoDBはレコード単位でロックします。

InnoDBにしたことで、テーブルロックで処理待ちが
発生する事象が解消されました。

Select

Select InnoDB Select



ロック等、DBのクエリ実行状況は、
SQL「show processlist」で確認できます。


■ リリース当初の問題点 ②

問題点：トップの「売上推移」表示に時間がかかる。

対策：予めサマリしたデータを別テーブルに保持する。


■ リリース当初の問題点 ②

対策前：
約20,000レコードを集計してグラフを表示。

対策後：
バッチで集計済のデータを予め別のテーブルに保持。

これで、トップ画面の表示が約10秒から1秒以下に短縮
されました。


■ 画面表示用にバッチで予め集計

集計バッチ導入前

そのまま蓄積集計/サマリ
30,000レコー
ド
75,000レコード/日
DB Web


■ 画面表示用にバッチで予め集計

集計バッチ導入後

そのまま蓄積集計/サマリ

360レコード
75,000レコード/日
DB Web

集計/サマリ

Batch


■ リリース当初の問題点 ③

問題点：深夜のレポート取り込みバッチが朝までに
終わらない。

対策：バッチの並列実行と、SQLのbulk-insertへ
の切り替え。



・バッチでAPIから取得したレポートをDBに登録す
る。
・バッチの完了期限⇒9時
・12時までかかってしまう事もありました。



対策①
処理対象のレコードを分割して、4本のバッチを
並行して起動するようにしました。



対策②
SQLを変更しました。

insert部分を1レコード毎から、1,000件毎の
bulk-insertに変更しました。

これでバッチが完了するまでの時間が約20倍ほ
ど早くなりました。


レポート取り込みSQLの解説


■ レポート取り込みSQLの歴史

レポート取り込みバッチのSQLは、何度か変更を
行いました。

対策についてより深く知ってもらうため、レポー
ト取り込みがどんなシステムかを説明します。



①毎日深夜、Yahoo!, Googleから過去30日分の
レポートデータをAPI経由で取得します。

Internet Batch



②直近1日分のレポートは新規で登録します。

新規登録
直近1日分



③それ以前の29日分のレポートは、既に登録さ
れている値を書き換えます。

レコード更新
過去29日分



30日分を更新している理由は、過去の数値が変動する
からです。

・不正な広告クリック分の調整
・集計遅延分の反映

このような原因で、過去の数値が変動します。



30日分のレポートは、
2,500(アカウント) × 30(日) = 75,000
レコードになります。



初期段階：
・APIから取得したレポートを条件に1件ずつselect。
・同一レコードがDBに存在するかを確認。
・insertまたはupdateを実行。

SQL発行回数：150,000回 (75,000回 × 2)



改修後：
・過去データを一括でdelete。
・レポートを1,000件づつbulk-insert。

SQL発行回数：76回

速度は劇的に早くなったのですが・・・



改修後の問題点：
delete⇒insertを繰り返した結果、InnoDBテーブルの
性能劣化が顕著にみられるようになりました。

DBのデータサイズの増加が激しくなりました。

※InnoDBのデータサイズは、レコードを削除しても減りませ
ん。



再改修後：
・INSERT ... ON DUPLICATE KEY UPDATE 構文に変
更。
・既存レコードはUPDATE、新規レコードはINSERT。
・1,000レコードづつ一括で実行。

SQL発行回数：76回



現在は、
・1,000レコードに対して一括でクエリを実行できる
・レコードが存在すればUPDATE、存在しなければ
INSERT
・削除分の無駄な容量増加がほとんど起こらない
・過去データの著しい劣化が無い

という、良い状態での運用を実現できています。


■ リリース当初に発生した問題

以上の対策を行ったことで、システムを何とか運用でき
るようになりました。


ステージ２

きちんとシステムが動くようにする


Search Suiteがリリースされて半年。

リスティング広告の売り上げも順調に伸び、シ
ステムのユーザも増えてきました。

最初はシステム化されたことに喜んでいたユー
ザも、徐々にパフォーマンスを求めるように
なってきました。


より大きな業務改善を実現するために、キーワード
単位のレポートを蓄積する必要が出てきました。

キーワード単位のレポート

約160万レコード/日(約6億/年)


■ 次に行った対策

システムのパフォーマンスアップのため、以下の
対策を行いました。

① ハードウェア増強
② DBにインデックスを張る
③ DBのレプリケーション


■ ハードウェア増強

さすがに今のままのサーバ構成だと限界だと感じ、
サーバを増やす事にしました。

本番サーバと同じものがヤフオクで5,000円で落札
されていたのに軽くショックを受けた頃でした。



増設前：
Web/Batch/DBを全て1台のサーバで運用

増設後：
サーバを4台構成にして、それぞれに別の役割を
持たせるようにしました。



新しく購入したサーバで、かなりスペックも上
がりました。見た目も強そうです。

ハードウェア：Dell Power Edge
CPU ：Xeon E5506
メモリ：32G
HDD ：600G SAS



同じタイミングで社内サーバールームを撤去す
ることになったので、インフラをデータセン
ターに移設しました。


■ その時点のハードウェア構成

Intranet

VPN

Web Batch
Data Center

MySQL(MASTER) MySQL(SLAVE)


■ サーバの役割分担で解消されたこと

・メモリやHDDを目一杯割り当てる事ができる。
・Web, Batchがの負荷お互いに影響を与えなくなった。
・サーバ負荷が高いとき、原因の特定がしやすくなった。


■ DBにインデックスを張りました

対策の方針：
・検索される条件になるカラムにインデックスを張る。
・設定ファイルのslow-query-logを有効にする。
・クエリにインデックスが効いているかを調べる(explain
文)


■ インデックスによる速度の違いを調べました

対象テーブル：アカウント
レコード数：約1万6千
カラム数：18



実行したSQL

SELECT SQL_NO_CACHE
id, account_name
FROM
account
WHERE
client_id=3894



インデックスによる実行速度の違い

30倍ほど高速になっています。

■ 300万件以上のレコードで実行してみました。

対象テーブル：アカウント別レポート
レコード数：約340万
カラム数：16



実行したSQL

SELECT SQL_NO_CACHE
account_id, report_date
FROM
transaction_daily_report
WHERE
account_id='961-565-4063'
AND
report_date >= ‘20121101’
AND
report_date <= ‘20121130’



インデックスによる実行速度の違い

6,000倍ほど高速になっています。

■ DBにインデックスを張りました

インデックスを張ることで、特に大容量テーブルの
速度が速くなることが分かりました。


■ レプリケーション

MySQLには、親子関係を作って複数台で同じデー
タを保持できる「レプリケーション」という機能が
あります。

ハードウェアのコストはかかりますが、負荷対策に
とても有効です。また、ハードウェア障害の対策に
もなります。


■ レプリケーションの仕組み

①APからマスタDBにクエリ送信
②マスタDBがバイナリログにクエリを書き込み
③マスタサーバからAPに実行完了を伝達
④バイナリログに書き込まれたクエリをスレーブに転送


■ レプリケーションの仕組み

注意
マスタとスレーブにおけるデータの一意性は保証されて
いません。マスタとスレーブで同期の遅延が発生するこ
とがあります。


■ レプリケーションの活用方法

よく使用されるのが、データを更新する時はマスターに、
参照する時はSLAVEにクエリを振り分ける方法です。
サーバの負荷が分散されてパフォーマンスがUpします。

Web 参照
SLAVE

更新
参照

MASTER SLAVE


■ レプリケーションの活用方法

定期的なバックアップはSLAVEで行うと、マスタの
更新処理に影響を与えることなく実行できます。

SLAVE
dump

MASTER

SLAVE


■ その他：リソース監視ソフト(Munin)導入

サーバリソースの使用状況を確認できるように
しました。
定期的に確認して、システムリソースに問題が
無いかをチェックしています。


■ きちんとシステムが動くようにする

以上の対策を行ったことで、
「とても重くて時間がかかるシステム」
から、
「業務システムとして割と普通に使えるシステム」
になったと思います。


ステージ３

原因調査からのパフォーマンス対策


■ 負荷の原因特定

レポートシステムにはよく、想定していなかった負
荷の高いリクエストを投げてくるユーザがいます。

・２年分くらいのレポートを一括で出す。
・100アカウントのレポートを一気に出す。

などなど。


■ 負荷の原因特定

正直、どのように対応してよいか非常に迷いました。
アプリケーションで制限するのは簡単だけど、業務影
響はどうなんだろうかと。


■ ログ出力の詳細化(Web/Batch)

アプリケーションの実行のログから、負荷が高いク
エリは誰のどういう操作か追えるようにしました。



アプリケーションの実行ログに、下記を出力しました。
・リクエスト固有のID
・リクエストURL
・実行ユーザID
・メモリ使用量
・実行時間
ログを定期的に確認し、システムのどこに負荷がか
かっているかを特定しました。



[実行ログのサンプル]

2012-11-28 03:42:08 t
PID[14754] t
UID[CAAM0182] t
MEMORY[26,990,224] t
TIME[2.391] t
URL[/sem/quickview/quickview.php] t
info ACTION_END n


■ ログ出力の詳細化(DB)

Web/Batchと合わせてDBのログから、負荷が高いク
エリは誰のどういう操作か追えるようにしました。


■ ログ出力の詳細化(DB)

全てのSQLに「発行したサーバID」と「リクエスト
ID」を付与しました。

DBの「プロセス一覧」「slow-log」とWebの実行ロ
グを付け合せ、どのリクエストに負荷がかかってい
るか調査できるようになりました。


■ ログ出力の詳細化

[SQLの例]

/** SID[web01] PID[4083428] */ select account_id from
report_batch_history where exe_date = '2012-11-08' and
report_type = 'ACCOUNT' and status = 0

ただし、これを行うとクエリキャッシュが効か
なくなってしまうのでご注意ください。


■ そのリクエストは何のために？

想定外の重い処理を行っているユーザを特定し
て、時には電話ヒアリング。

システムからレポートを出していると、いきな
り電話がかかってくるのです。よくびっくりさ
れました(笑)


■ DBの負荷対策を重点的に行いました

① シャーディング
② 敢えて正規化しない
③ インデックス見直し
④ 設定ファイルのチューニング
⑤ キャッシュサーバ導入


■ DBのシャーディング

レコード数が大きなテーブルを、複数に分割しました。
キーワードレポートは「年月」「クライアント」で分割
しています。


■ DBのシャーディング

テーブル数が増えるために「テーブルの構造変更」
「テーブル横断での検索」は行いにくくなりますが、
更新/参照の速度は非常に早くなりました。


■ 敢えて正規化しない

レコード数の大きなテーブルでは、あえて正規化を
せずにデータを持っています。
Joinや複数回のクエリでレコードを作るよりも、高
速に値の取得ができるからです。

report
report
account

＋



データ容量は少し大きくなりますが、パフォーマンスは
大きく向上します。
結合先の値が変わらない前提のデータのみに有効です。

report
report
account

＋



正規化した場合

・SQLでjoinして取得。

・別々に取得して、プログラムで紐づける。

report
account

＋



正規化しない場合

単一テーブルから完全なデータが取得できます。
これによって、データ生成のコストを抑えることがで
きます。
report


■ パフォーマンスを比較してみました

対象テーブル：キーワード別レポート
レコード数：約3400万
カラム数：16



「正規化」で実行したSQLはこちらです。

SELECT SQL_NO_CACHE
count(*)
FROM
transaction_daily_report
inner join
account on account.id=transaction_daily_report.account_id
WHERE
transaction_daily_report.account_id='961-565-4063'
AND
report_date >= ‘20121101’
AND
report_date <= ‘20121130’



結果はこんな数値になりました

Joinすると、約3倍の時間がかかっています。


■ インデックスの見直し

データベースにインデックスを張っていましたが、改
めて見直しを行いました。



ポイント
・無駄なインデックスは削除
・複合インデックスで賄えるものは、そちらに一本化。
・カーディナリティ(値の分散)が高いものから順に復号
インデックスを張る。



explain文でインデックスが有効かを確認します。

例)EXPLAIN SELECT * FROM media_master WHERE id =1

詳しい説明は割愛しますが、クエリの実行にインデック
スがきちんと効いているかを調べる事ができます。

Extraフィールドでクエリの実行計画を確認できます。


■ MySQL設定ファイルの最適化

MySQL設定ファイルを書き換えて、チューニングを行
いました。



・メモリ関連のチューニングを行いました。
(InnoDBに多くのメモリを割り当てています。)

・接続した際に、文字コードをutf8に設定しています。
init-connect=SET NAMES utf8



・InnoDBのデータファイル「ibdata」をテーブル毎に
作成する。
⇒Innodb_file_per_table
└テーブルを最適化しやすい。
※デフォルトだと、データベース単位でibdataが作成されます。



ib_logfile(更新用の領域)を最大値の4GBを取り、更新系
クエリの高速化を図っています。

innodb_log_file_size = 1364MB
innodb_log_files_in_group = 3
※MySQL5.6系ではib_logfileを512GBまで拡張可能になるようです。



これらの対策を行った結果、DBの動作が目に見えて高
速になりました。


■ キャッシュサーバ導入

キャッシュサーバとしてMemcachedを導入しまし
た。


■ Memcached について

概要：
Key-Value型のデータストア。
オンメモリで動作をし、非常に高速なのが特徴です。
データは「キー」と「値」をペアで保持します。


■ Memcached の特徴

特徴

・１つのキーに対して、値の上限が1M。
・指定したメモリの上限に達した場合、最近最も
使われなかったものから消されていく。

・オンメモリのため、サーバが落ちるとデータは消失する。


■ キャッシュサーバ導入

導入にあたり、検討したポイント

① 値を保持する方法。
② 検索の仕組み。
③ DB→Memcachedへデータロードのタイミング。
④ Memcachedに値が無い場合。


■ 値を保持する方法

テーブルの内容や検索結果の全レコードをtsvにし、
１つのキーに設定しています。


■ 検索の仕組み

Memcachedから値を取り出す際に、指定条件でフィルタ
できるようにアクセス用のクラスを開発しました。

複数の値を、1回のMemcachedアクセスで取得
することができます。

アプリケー
フィルタ
ション


■ DB→Memcachedへデータロードのタイミング

・ほぼ更新のないマスタ系のデータ：１日３回
・頻繁に更新されるデータ：１時間に３回
・DBの値を更新した際：再ロードを実行


■ Memcachedに値が無い場合

キーに対して値が全く存在しない場合には、DBから
値を持ってくるような仕組みを構築しました。

①

アプリケー
ション

②


Memcached導入の具体例


■ レポート作成画面への導入事例

クライアントを選択する画面です。
プルダウンのリストをMemcached化しました。


Memcached登録用のSQL
select
company_name, account.client_id,
if( LENGTH( client_name ) > 0,
concat( company_name, '//', client_name ) , company_name ) AS client_name
from
account
inner join
account_info on account.id=account_info.account_id
inner join
client on client.id=account.client_id
inner join
company on company.id=client.company_id
inner join
client_con_user on client.id= client_con_user.client_id
where
account_info.account_status_id=1
and
client.delete_flg = 0 and client_con_user.user_id=‘XXXX’
group by
client_id order by company_name, client_name



「ログインユーザの担当クライアントを選択」

という条件をSQLで実行しています。



DBから取得していた値をMemcachedに載せました。



Mencache導入の結果、画面表示が2倍以上早くなりまし
た。


■ Memcached導入

Memcachedはとても効果の大きい対策になりました。
少し手間はかかりましたが、導入して良かったです。


ステージ４

更なるパフォーマンスを求めて


■ 新メンバーのジョイン

新しいエンジニア2名がチームに加わりました。
別グループにいた佐久本、仲里です。

力を合わせて、システムの更なる高速化・安定運用
に向けて取り組みます。


■ 更なる対策

更なる速度を追求すべく対策を行いました。

① サーバの増強(また追加しました)
② PHPのアクセラレータ導入
③ DB-SLAVEへのLB導入
④ ネットワークの２重化


■ サーバの増強

この頃になると、予算もキーワード数も多いク
ライアントが多くなってきました。

システム負荷は上がるばかりです。

これに対応すべく、サーバの増強を行うことに
しました。


■ サーバの増強

サーバを10台ほど購入し、以下の対策を行いました。
・Webサーバの多重化
・容量の多いデータベースを別サーバに移動する。
・DBサーバ(SLAVE)の多重化

サーバ多重化に伴い、ロードバランサを導入しました。


■ ロードバランサ導入

ロードバランサの種類：IPVS(LVS：Linux Virtual
Server)
振り分け方法：全てのサーバに均等(ラウンドロビン)

サーバ①②③に均等に振り分け
Load Balancer

る。

Web① Web② Web③


■ ロードバランサ導入

KeepalivedのMISC_CHECKと組み合わせて、ダウンし
たサーバは自動的に切り離すようにしています。

Load Balancer

サーバダウン⇒自動的に切り離
× す。

Web① Web② Web③


■ ハードウェア構成
Intranet
監視(nagious) Intranet

VPN

Load Balancer NFS
Data Center

Web/ Cache Batch

監視(nagious)
Load Balancer

MySQL(MASTER) MySQL(SLAVE)


■ PHPアクセラレータ導入

Webサーバに「eAccelerator」を導入しました。
PHPの実行が驚くほど早くなりました。



PHP(スクリプト型言語)の特徴として

・コンパイル無しですぐに実行できる。
・ソースを入れ替えるだけでリリース可能。

等があります。



でも、実は裏では、
実行する前にソースがコンパイルされているの
です。

プログラムが参照するファイルが多ければ多い
ほど、コンパイルに時間がかかってしまいます。



アクセラレータは初回実行時に、コンパイル済の
バイトコードをメモリ上にキャッシュします。

これによって高速な実行を実現しています。

PHP実行イメージ

初回実行時に
メモリにキャッシュ

コンパイ
解析
ル

PHPソースコードバイトコード実行


■ PHPアクセラレータの効果

画面を表示する時間を計測しました。

表示にDBアクセスはせず、キャッシュサーバーから
プルダウンのリストを取得して表示しています。


■ PHPアクセラレータの効果

ベンチマークしてみました。

約2倍も高速になっているのが分かります。


■ PHPアクセラレータの導入

とても手軽で、かつ効果的な対策でした。
コストも0円です。

もっと早く知っていれば・・・。


■ DB-SLAVEのロードバランサ導入

アプリケーション側で行っていたSLAVEへクエリ発
行する際の接続先制御を、ロードバランサで行うよ
うにしました。



ロードバランサでのSLAVE接続先制御を行うことで、
・故障したハードの切り離し
・SLAVEの追加
・負荷が低いサーバへの接続

これらが簡単にできるようになりました。



これまでのDBバランシング
⇒アプリケーション側でSLAVE接続先を選択。



対策後のDBバランシング
⇒ロードバランサーがSLAVE接続先を選択。



ロードバランサを利用したMySQLの運用にあたり

・MySQLのレプリケーションの遅延を監視
・遅延しているSLAVEにリクエストしない

これを実現する仕組みを構築して運用しています。



SLAVEサーバにプログラムを設置し、自身の状態を監視。
MISC_CHECK経由でロードバランサがSLAVEの状態を確
認。

レプリケーション遅延や停止が起こるとSLAVEを切り離
します。



この対策を行った結果、DB負荷の高い処理が１つの
SLAVEに集中しなくなりました。

結果として、「レポート出力に時間がかかる」とい
う問題発生を減らすことができました。


■ ネットワークの2重化

ネットワークをデータセンターの内部向け/外部
向けで2重化を行い、トラフィックを分散させま
した。


■ 対策前のネットワークのイメージ

外部向け、内部向けのネットワークが全てが同じセグメ
ントにあるので、回線にトラフィックが集中しています。

外部API

Data Center

DB(MASTER
Web Batch DB(SLAVE)
)


■ 対策後のネットワークのイメージ

外部向け、内部向けのネットワークが分かれているので、
トラフィックを分散することができるようになりました。

外部API

Data Center 外部向けネット
ワーク
× ×
DB(MASTER
Web Batch DB(SLAVE)
)

内部向けネット
ワーク


■ ネットワークの2重化

ネットワークの2重化によって

・外部APIからのデータ取得の高速化
・ DBとWeb-Batchサーバ間の通信高速化
・レプリケーション遅延の減少

これらを実現することができました。


■ 今はここまで

これらの対策を行った結果、システムの速度や安定
性が格段に上がりました。

これからもメンバーと力を合わせて、更に高いレベ
ルを目指していきたいと思います。


失敗した対策


■ DBへのSSD導入

書き込みの回数が多すぎて、1ヶ月でSSD
が故障(ミラーリングしていた2台とも・・)

書き込みが回数多いDBへのSSDは導入は難しいのか
もしれません。

速度はとても早くなったのですが・・・


■ DBへのSSD導入

講演「 GREEを支える大規模インフラテクノロジー」
や書籍「Mobageを支える技術」によると、GREEさ
んDeNAさんではSSD導入で成功しているみたいです。

弊社でも機会があれば、また検証したいと思います。


これから行いたいこと


■ Fusion-io使ってみたい！

・新しいフラッシュメモリのストレージ。
・非常に高速で、信頼性が高い。
・Amebaでは、96台のサーバを8台にした実績あり。
・百万円以上で、HDDと比べると非常に高価。


■ MySQL5.6を導入したい！

・現在はRC(リリース候補版)が最新。
・データベース単位でレプリケーションの並列実行。
・MemcachedプロトコルでInnoDBに直接アクセス可能。
・InnoDBがパワーアップして、全文検索に対応。
その他、新機能が盛りだくさん。


■ さいごに

いかがでしたでしょうか。本日の内容が、少しでも
皆様のお役に立てば幸いです。

ブログも書いていますので、興味があればぜひご覧
ください。

エグジニアブログ
http://ameblo.jp/exgineer/


本日の勉強会は以上になります。
ご清聴ありがとうございました。


負荷分散勉強会

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 負荷分散勉強会

Similar to 負荷分散勉強会 (20)

More from Yuji Otani

More from Yuji Otani (20)

Recently uploaded

Recently uploaded (7)

負荷分散勉強会