負荷分散の失敗談



はじめての負荷分散

私がサーバーエンジニアとして駆け出しの頃、約6,000人の社員が出社と同時にアクセスするグループウェア(Perl)のパフォーマンスを上げるよう命ぜられたことがありました。

イントラで限られた人数のみのアクセスとは言え、SunのUltra51台で担っていたものですからデータ量が多くなるとパフォーマンスは悪くなる訳です。

今でこそ負荷分散の情報はたくさん得られますが、15年くらい前はそれほど多くの情報は無かったように思います。

その時知った負荷分散方法が、1つのホスト名に複数のIPアドレスを割り当てて、それらのIPアドレスを順番に循環させクライアントに返すDNSラウンドロビンという方法。

www    IN    A    127.0.1.1
www    IN    A    127.0.1.2
www    IN    A    127.0.1.3

簡単に言うと、DNSのゾーンファイルに、このようなレコードを書き記す訳です。このゾーンファイルが○○.jpのものだとすると、www.○○.jpにアクセスすると127.0.1.1 〜 127.0.1.2 の3台のどれかにアクセスすることになります。

アクセスが多いサーバーでは、同じ内容のサーバーを複数台用意して、DNSのゾーンファイルに複数のIPアドレスをを割り当てれば負荷分散ができ、高額な負荷分散装置を買わなくても済んでいました。但し、サーバー自体の負荷状態を見て振り分ける技術ではないですが、サーバーを1台から3台に増やしある程度の分散ができていたので当時の環境においては有効な手法でした。

 

 

負荷分散成功と思いきや…

駆け出しということで、データ同期の仕組みまで気が回らなかったのですねwww

最初は「速くなった!」とお褒めの言葉をいただきほっとしたのもつかの間、「予定入れたのに予定が入ってない」というような問い合わせが、荒れ狂う波となって私を襲って来たのは言うまでもありません。

グループウェアのデータの多くは、CSVファイルに追記するものだったので運良くば3回に1回は入力したデータを拝めるといった状態でした。

即、DNSレコードを元に戻して1台運用に切り替えました。1台の運用でも、旧サーバーと違い新しくなった分パフォーマンスが良くなりストレス無く処理されていたのが唯一の救いでした。

 

 

データの同期

参考にした文献が静的ページを前提にしたもの。もっと考えるべきだったとデータ修復しながら反省し、データやプログラムの同期はどうすればいいのかさらに文献を読みあさり辿り着いた方法が、ネットワークファイル共有システムでディレクトリを共有できるNFSでした。

静的ページと動的ページでは負荷分散の概念も異なる、そしてグループウェアのデータがCSVに蓄積されるということの意味を考えると、同期ではなく3台のサーバーで一つのディレクトリーを共有すればいいと。

初めて自分で答えを見いだすことができたような気がして嬉しくなったのを思い出します。

私の失敗を皆がカバーしようとしてくれていて、グループウェアをCSVファイルからデータベース化(PostgreSQL)するという動きもあり本当に恵まれた環境で経験を積ませてもらっていました。

最終的には、このような構成となりました。

DNSランドロビン&NFSシェアリング

DNSランドロビン&NFSシェアリングの負荷分散例

 

 

CMSでの負荷分散に応用できるNFS

最近は高額な投資をせずともロードバランサー等を使った負荷分散ができるようになってきています。セッション維持機能もついているので、DBでセッション管理と頭を悩ませていた頃は何だったのと思います。

コンテンツにおいては、CMSを利用して運用しているケースも非常に多くなってきています。CMSは簡単にサイトやネットショップを構築できる反面、サーバーに負荷がかかり始めてからの対処が難しかったりします。

ロードバランサーを使いCMSのキャッシュ機能を持たせDBアクセスを抑えれば、インフラエンジニアの手だけでも上の図のような負荷分散が可能になります。それぞれのサーバーが故障した場合の対処を考えておけばOK。



67 More posts in コンピューター category
Recommended for you
MacBook Pro (Late 2016)をDVIで外部ディスプレイに接続

MacBook Pro (La...