SLP KBIT Advent Calendar 2014 -23日目-

この記事は

の23日目の記事だよ！

内容が無いよう(´・ω・｀)…

最近流行りのクラウド上の負荷分散について書くよ
(当社比)

有名ドコロ

• AmazonEC2
• Cloud n
• GMOクラウド

とか最近耳にすると思う。
特にEC2とかは「○○をEC2上に構築する」とか「EC2のインスタンス使って～」という
内容の記事も目にする機会が非常に多くなった。

詳しくはAmazon EC2（スケーラブルなクラウド上の仮想サーバー） | アマゾン ウェブ サービス（AWS 日本語）とか読もう。

で、本題

ソシャゲとか周りでやってる人も多いし、イベントの時によく鯖が重いとか耳にする。
これはみんな同時にアクセスしに行ってて鯖の処理が追いついていない状態。
こういう大量のアクセスを捌くことを負荷分散と称してあれやこれやしている。

最近の主流

• DNSラウンドロビン+ロードバランサ構成

AmazonEC2(特にELB)とかを見てる限りでは、DNSとロードバランサを組み合わせて負荷分散をしている。どういうことかというと、ロードバランサ単体では、ロードバランサ自体にアクセスが集中してしまい、そこで重くなってしまう。DNSラウンドロビン単体だといろいろとまずい面がある。(詳しくはここを読もうDNSラウンドロビン - Wikipedia)

イメージ

                            ┌―→|AP|
ユーザ  →   |   |   ┌→|LB|→ ┤
ユーザ  →   |DNS| →＋        ├─→|AP|
ユーザ  →   |   |   └→|LB|→ ┤
                            └―→|AP|

LB:ロードバランサ
AP:アプリケーションサーバ

＿人人人人人人＿
＞　見づらい　＜
￣Y^Y^Y^Y^Y￣

ユーザがURLを踏む
→ DNSに「このURLのIP何？」って聞きに行く
→ DNSが「xxx.xxx.xxx.xxx」とサーバのIPを返す
→ ユーザのPCがxxx.xxx.xxx.xxxにアクセスしに行く
→ LB「ばかめ！かかったな！振り分けてやる！」

という事になっている

実際の運用

実際はこれに加えて、サーバ側でマシンの台数を変化させたりする。(オートスケール)
実運用時には、アプリケーションサーバの後ろにいるDBについても冗長構成にしてロードバランスするケースもある。その辺はサービスの形態や状況に応じていろいろなケースが見られる。

もっともこういった冗長構成を作るときには、きちんと障害検知なりをして、生きているサーバに振分けられることが保証されていないとマズイ。

おわり

バイト前にそういや今日だったことに気づいてめちゃ雑に書いてる＼(^o^)／