24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) [プログラミング]
2008年出版の、オープンソースとコモディティな機材を使って、冗長化とスケーラビリティを兼ね備えたシステムを構築する方法。
インストール方法などはネットで簡単に調べられるが、その先の運用におけるこれらのノウハウには苦労したのでまとめたのだそうだ。
株式会社はてなとKLab株式会社による実際にサービスを提供するうえでの事例を扱っているため、より実践的になっている。
冗長化・・・障害が発生しても予備の機材でシステムの機能を継続できるようにすることを指す。可用性を確保するともいえる。
スケーラビリティ・・・利用者や規模の拡大にあわせて、どれだけシステムを拡張して対応できるかという能力。
1章サーバインフラ構築入門
冗長化の基本
１障害を想定化する
２障害にs萎えて予備の機材を準備する
３障害が発生した際に予備の機材に切り替えられる運用体制を整備する。
シンプルなwebサーバー、ルーター、インターネットの構成を考える。
・ルータの故障
ルータの予備機を用意してきりかえればよい。（コールドスタンバイ）
・Webサーバーの故障
予備機に切り替えても内容が同じでないといけない。そのためコールドスタンバイは現実的ではない。
常にネットワークに接続し、内容も同じに保たないといけない（ホットスタンバイ）
フェイルオーバー・・・現用機に障害が発生したとき自動的に処理を予備機に引き継ぐ仕組み。
VIPで予備機が仮想アドレスを引き継ぐ、ヘルスチェックプログラムでルーターとサーバのVIPを自動的に引き継ぐプログラムの例。
負荷分散（ロードバランス）・・・複数台のサーバに処理を分散させてサイト全体のスケーラビリティを向上させる手法
予備機になにもさせないのはもったいので、負荷分散で仕事をさせる。サーバ増設のときも古い資源も無駄にならない。
Webサーバの冗長化の具体的方法
DNSラウンドロビン・・・DNSを利用して一つのサービスに複数台のサーバを分散させる方法。
比較的簡単に負荷分散できるが、欠点としては以下がある。
・サーバの数だけグローバルアドレスが必要（VIPにすれば解決）
・均等に分散されると限らない
・サーバがダウンしても気が付かない
実際にフェイルオーバーするときのスクリプト例がのっていた。個々のサーバーにこのスクリプトを乗せる
ロードバランサ（負荷分散機）・・・１つのIPアドレスに対するリクエストを複数のサーバへ分散する。
この危機がサービス用のグローバルアドレスを持った仮想的サーバとして動作して、クライアントからのリクエストをリアルサーバに中継する。ヘルスチェックはロードバランサで行うので、個々のサーバにフェイルオーバーのプログラムを乗せる必要はないし、どのサーバに処理を割り当てるか制御できる。
欠点としては、アプライアンス製品は高価であるため収益が確保できない段階では導入に踏み切れないこと。
安価な構築方法としてLinuxのIPVSを利用したロードバランサの構築方法を紹介。
IPVS・・・Linuxが実装している負荷分散機能を提供するモジュール。L4スイッチ相当の機能を提供する。スケジューリングアルゴリズムを選択できる。
具体的ソフトウェア
ipvsadm・・・IPVSの開発元が提供しているコマンドラインツール。
keepalived・・・C言語で書かれているデーモン（Windosでサービスプログラムのイメージ）
keepalivedを使用した具体的なロードバランサ構築例。
L4スイッチ・・・OSI参照モデルのレイヤ４（トランスポート層）のさす。IPアドレスやポート番号の解析ができる。パフォーマンスがよい。
L7スイッチ・・・OSI参照モデルのレイヤ７（アプリケーション層）を指す。クライアントからリクエストされたURLまで解析できる。柔軟な設定ができる。
L4スイッチの構成例
NAT構成・・・クライアントからのパケットの送信先を書き換えてリアルサーバに送る。Webサーバからの応答パケットを受け取ってIPアドレスを描き戻す。
DSR構成・・・クライアントから受け取ったパケットをそのままリアルサーバに送る。リアルサーバはL４スイッチを経由しないで応答を返すことができる。(リアルサーバがグローバルアドレスを処理できる必要がある、リアルサーバのループバックインタフェースに仮想サーバのIPアドレスをわりあてるか、netfilterで仮想サーバあてのパケットを自分あてにDNATする方法が考えられる）
ロードバランサで同じサブネットのサーバを負荷分散する場合はDSR構成にしないと正常に通信できなくなるので注意。
ロードバランサの冗長化
VRRP・・・ロードバランサの冗長化プロトコル、ベンダ非依存。
仕組み解説。
VRRPパケット・・・マスターノードが定期的にマルチキャストアドレスに送出するパケット。仮想IPアドレス、仮想ルータID,プライオリティからなる。バックアップノードはこのパケットが一定期間こないとフェイルオーバーを開始する。
仮想IPアドレス（VIP）・・・VRRPパケットはすべて同じIPアドレスに送出されるので、どのノードが見分けるのに使う。
プライオリティ・・・どのノード(バックアップ）がマスタになるか、プライオリティで判別。自分よりプライオリティが高いノードがいたらマスタになるのをあきらめる。(ふぃえるオーバーしない）
プリエンプティブモード・・・これを無効にすると、すでにマスターになったノードがある限り、自分の方がプライオリティが高くてもフェイルオーバーしない。
仮想MACアドレス・・・MACアドレスも引き継がないと、通信相手の機器のARPテーブル(ここに通信相手のMACアドレスが入っており、キャッシュが更新されるまで変わらない）の内容と矛盾してしまう。
keepalivedでも利用できるので、ロードバランサをもう一台構築してkeepalivedを走らせれば簡単に冗長化できる。ただしkeepalivedは仮想MACアドレスを使っていないので、gratuitousARPを送出して、通信相手にARPテーブルを更新してもらう。ただし一度ではうまくいかないことがあるのでgrap_master_delay時間待ってから再送出を行う。
keepalivedを冗長化する例紹介。
2章ワンランク上のサーバ/インフラの構築
●リバースプロキシ・・・クライアントからの要求をうけとり(必要なら手元で処理を行った後）適切なWebサーバへ要求を転送する。Webサーバはリバースプロキシに応答を返す。普通プロキシサーバはLAN→WANの要求を代理で処理するが、リバースプロキシはWAN→LANの要求を代理するのでリバースとついている。この機能でクライアントからの要求がWebサーバに届く前後にいろんな処理ができる。動的コンテンツを配信するAPサーバの場合特に有効。
いろんな処理の例
・HTTPリクエストのURLをみて、/images/logo.jpgなら画像用Webサーバに、/newsであれば動的コンテンツ生成サーバ（APサーバ）に処理をわりあてる。通常1リクエストに1プロセスまたは１スレッドを割り当てるが、画像のような静的コンテンツまでメモリに常駐させる必要はないのでWebサーバをわけてAPサーバのメモリを節約する。
・クライアントのIPアドレスをみて、特定のIPアドレスのみサーバのアクセスを許可する。
・クライアントのUser-Agentをみて、任意のUser-Aentからのリクエストを特別なWebサーバへアクセス誘導する・
・/hoge/foo/barというURLを/hoge?foo=barというURLに変更してWebサーバへリクエストする。(見た目のURLをきれいにできる）
・HTTPのKeep-Alive機能を使ってAPサーバのバッファとして機能する。クライアントとリバースプロキシはKeep-Aliveだが、リバースプロキシとAPサーバの間はオフにする。APサーバよりたくさんのプロセスを立ち上げられる（1000-10000程度）リバースプロキシだからできる。
APサーバ・・・動的コンテンツを返却するWebサーバ。アプリケーションの起動に時間がかかるため、メモリに常駐させる手法をとることが多い。そのため大量のメモリが要求される。普通最大プロセス数は50-100。
HTTPのKeep-Alive・・最初の1リクエストで確率したサーバとの接続をそのリスエストが終了した後も切断せずに維持して、続くリクエストを処理する。複数のファイルをダウンロードするときなど早くなって便利。
Apachでリバースプロキシを構築するには、mod_proxy,mod_proxy_balancerを組み込む。
また、lightepd, Squidでも構築できる。
両方とも具体的紹介あり。
●キャッシュサーバ・・・HTTPはステートレスなプロトコルでドキュメントの状態をもたないためキャッシュしやすい
そのため、プロトコルレベルでキャッシュ機能がある。IEなどで一度取得したドキュメントはローカルにキャッシュしている。
FireFoxのLive HTTP Headerのやりとりをみてキャッシュの効果を説明。
サーバとサーバの間でもHTTPキャッシュは使える。
Squid・・・HTTP,HTTPS、FTPなどで利用されるオープンソースのキャッシュサーバ。複数のクライアントをSquid経由にすることでドキュメントの参照を高速化したりするのに使われる。
HTMLファイルCSS、JavaScript、画像などの静的ドキュメントを効率よくキャッシュできる。
動的コンテンツについては、一意なURLが与えられているドキュメントは基本的にキャッシュできる。またあるページを30分間だけキャッシュするなどの制御が可能。
ただし、動的なドキュメントでも状態を持つドキュメントはキャッシュするとまずい。この場合はより粒度の細かいキャッシュサーバ(memcachedなど）を選ぶ。
Squidでリバースプロキシを構築する方法を紹介。
mencachd・・・C言語で書かれた高速なネットワーク対応の分散キャッシュサーバ。ストレージにOSのメモリを使用。使用はプログラム内部から行う。
●MySQLのレプリケーション
DBサーバが停止した場合、問題となるの「DBのデータ」。
レプリケーション・・・一般的にはデータをリアルタイムに他の場所へ複製すること。
MySQLのレプリケーションとは2台のDBサーバでMySQLを実行して、まったく同じDBデータのサーバを作ること。
MySQLのバージョンは5.0.45を使用。
MySQLのレプリケーションの特徴は
・シングルマスタ、マルチスレーブ
・非同期のデータコピー
・レプリケーションされるデータの内容・・・レプリケーションがSQL文単位で行われる。この方法だとマスターとスレーブで異なる行が更新される可能性がある。MySQL5.1.5では行単位のレプリケーションができるので解決されている。5.1.8では混合モード（文単位と行単位の場合分け）もある。
レプリケーションの仕組み
スレーブでI/Oスレッド（マスタからの更新ログをファイルにいれる）とSQLスレッド（更新ログのファイルを実行）がデータの更新をしている。
マスタには「バイナリログ」(参照処理ではなく、更新処理のみが記録される、mysqlbinlogで解読できる）スレーブには「リレーログ」（マスタの更新ログをうけとったもの、更新が終わると自動で消去される）が作成される。
ポジション情報はスレーブがどこまでレプリケーションしたかを記録する。maser.infoに保管され、SHOW SLAVE STATUSというSQL文で確認できる。
レプリケーション構成の作り方紹介
my.cnf設定方法、レプリケーション用ユーザ作成、レプリケーション開始に必要なデータなど
レプリケーションを開始するにはスレーブでmysqldを起動。レプリケーションの状況を確認するには、「SHOW MASER STATUS」 「SHOW MASTER LOGS」 「SHOW SLAVES STATUS」など。
参照系のクエリをMySQLのスレーブにやらせて負荷を分散する方法紹介。
方法としてはアプリケーションによる分散と、内部ロードバランサによる分散がある
内部ロードバランサによるスレーブ参照の方法を紹介。
●ストレージサーバ・・・大容量コンテンツ（動画や音声）を配信するサービスでコンテンツファイルを格納するサーバ。各WebサーバはNFSマウントでコンテンツファイルを読みだす構成になる。ただし、ストレージサーバはボトルネックになりやすく、単一故障点になりやすい。
理想的なストレージサーバは読み込みが速く、ディスク容量が大きいのが条件。
読み込みを早くするために、HTTPをストレージプロトコルとして利用したストレージサーバの例
アップロードするサーバのみNFSマウントしており、サーバ内のNFSサーバーがHDDに書き込みを行う。
他のWebサーバは同じくサーバー内のWebサーバーを介してHDDから読み込みを行う。こうするとすべてのWebサーバがNFSマウントする必要がない。
HTTPはNFSに比べるとサーバとクライアントの結合が祖であるので、万一ストレージサーバの異常を検出してもエラーを返したりできる。
筆者の環境では、ストレージサーバに読み出しのリクエストが集中するときには、だいたい同じデータが読みだされているのでthttpdを使うことで負荷分散できたという。
単一故障点になるのを回避するには、複数台のサーバにファイルを分散させる必要があるが、大容量であるだけに同期が難しい。詳細は3章で。
３章 止まらないインフラを目指すさらなる工夫
●DNSサーバの冗長化
DNSサーバの障害は一旦発生すると原因が発生するまで時間がかかる。
レゾルバライブラリを使用した冗長化・・・/etc/resolv.confにDNSサーバを複数指定する。手軽な方法だが、異常を検出するのにタイムアウトを待たないといけないので性能低下の危険があるので避けたほうがいい。
サーバファームにおけるDNSの冗長化・・・VRRP（keepalived）を利用して、片方がVIPでActiveサーバになる構成にする。ただし、DNSサービスが停止してもフェイルオーバーしないので、digコマンドで自分自身にDNS問い合わせをするスクリプトを使う。さらにロードバランサを使って負荷分散をする。
●ストレージサーバの冗長化
RAIDを使うのが一般的だが、整合性のチェックは時間がかかるしサーバに負荷がかかる。
DRBDというソフトを使用するのを推奨していた。このソフトはファイル単位ではなくブロックデバイスに対する更新をリアルタイムに転送する。ネットワーク越しのRAID１と考えられる。このソフトの設定、フェイルオーバー（自動、手動）、方法紹介。
keepalivedとVRRPでNFSサーバを冗長化する方法紹介。
DRBDでディスクのミラーリングをしていても、オペミスで消してしまったファイルはやはり両方消されてしまう。バックアップはやはり行うべき。
●ネットワークの冗長化
L1(OSI参照モデルレイヤ１）、L2（OSI参照モデルレイヤ2）で故障が発生してもシステム停止しないように冗長化する方法。
故障の種類
１LANケーブル
２NIC（ネットワークカード）
３ネットワークスイッチのポート
４ネットワークスイッチ
１－３はサーバとスイッチ間の接続故障なので、リンク故障
１と３はスイッチ間接続の故障
４はスイッチ故障。
リンク故障対応・・・LinuxのBondingドライバは複数の物理的なネットワークカードをまとめて1つの論理的なネットワークカードとして扱う。この機能の設定方法解説。
スイッチ故障対応・・・スイッチを複数台用意して、Bondingドライバは以下の物理NICをそれぞれ別のスイッチに接続する。
スイッチ増設方法解説
ポートの多いスイッチに交換しただけなら状況は変わらないが、増設の場合は冗長性を保つうえでの条件が増える。カスケード接続した場合の例で解説。
すべてのスイッチが相互接続するとブロードキャストストームが発生するので注意。これを発生させないためのRSTPプロトコルの解説。
RSTPを使用するとBondingドライバｎ頼らずにスイッチの冗長化ができる。
●VLAN導入でネットワークを柔軟にする。
サーバファームにおける柔軟性の高いネットワークとは
１新規サーバ追加が容易
２サーバが故障したときにすぐに代替え機に移行できる
３あるサーバを別の役割のサーバに切り替えられる
これらにこたえられて、作業場のネックがない。
VLAN・・・物理的な構成ではなく、ネットワーク機器やサーバの設定で「論理的」にネットワークを分割して構成する技術。ブロードkyストドメインの分割が論理的に可能になる。同じスイッチに複数のセグメントの端末を接続しても、設定によって論理的にブロードキャストドメインを分割できるので、適切なポートにのみ、フレームがフォワードされる。
VLANを導入すると、
1台のスイッチで複数のセグメントを管理できる。
設定だけでポートに流れるデータを制御できる。
というメリットがある。
VLANの種類
スタティックVLAN・・・ポート単位に手動でグループの割り当てを行う
ダイナミックVLAN・・・つながる機器などによって動的にグループの割り当てを変える。
近年の傾向として、ユーザごとやMACアドレスごとなどのルールで制御を行うVLANを利用してセキュリティを高めるなどの使い方をされている。
ベンダ依存のVLAN
ポートVLAN
タグVLAN
データセンター内のサーバが故障したという想定で復旧までの流れを解説。
VLANを使わない場合と使った場合。
4章性能向上、チューニング
●Linux単一ホストの負荷の見極め
ＯＳのチューイングとは負荷の原因を知り、それを取り除くこと。
負荷は推測しないで計測する。
Linuxのツールps, top, sarで負荷を調べる。
ボトルネック見極めには、
ロードアベレージ（システム全体の負荷）を見る・・・特に処理を実行したくても実行できなくて待たされているプロセスがどのくらいあるか？
CPUかI/Oどちらがボトルネックか探る。・・・CPU使用率とI/O待ち時間
CPU負荷が高い場合
・ボトルネックはユーザプログラムの処理化システムプログラムか。
・原因となるプロセス特定
・プロセスを詳細にみるのにstraceでトレースしたり、oprofileでプロファイリング
I/O負荷が高い場合
・特定のプロセスが極端にメモリを消費していないか
・プログラムの不具合でメモリを使いすぎていないか
・多雨歳メモリが不足しているならメモリ増設か分散を検討。
負荷の総体を知るために、マルチタスクOSの仕組み、カーネルの動作、スケジューリングとプロセスの状態解説。
CPU使用率計算方法、マルチＣＰＵの場合など。
プロセスアカウンティングのカーネルコードの見方解説。スレッドとプロセス解説。
ps, sar, nmstatコマンド使い方
●Apacheのチューニング
Ａｐａｃｈｅ＝Apache HTTP SERVERはオープンソースのWebサーバのディファクトスタンダード。
ApacheのMPMを利用した並列処理の解説。これを利用した負荷分散の方法を解説。
●MySQLのチューニングのツボ
DBサーバのチューニングは、サーバサイド、サーバサイド以外、周辺システムで考えられる。
サーバサイドではディスクI/Oのチューニングがキモなので、ディスクI/O関連のKernelパラメータ調整、適切なファイルシステムの選択とマウントオプション調整が考えられる。
サーバサイド以外では、テーブル設計（適切なインデックスの作成、意図的な非正規化）、SQLの最適化（インデックスをうまく使うように、テーブルの結合順序と方法を調整）
周辺システムでは、memcachedなどのキャッシュサーバ。
サーバサイドのチューニングの中で重要なもの
メモリのパラメータ解説と、あるDBサーバ（実メモリ４GB）の設定値
チェックルール
5章省力運用
●サービス稼働監視
監視の種類
１死活状態の監視(pingなど）
２負荷状態の監視（CPU使用率、サービスの同時処理数）
３一定期間サービス提供ができていたか(稼働率)計測。
監視ツールNagiosを使った監視方法の解説。
●サーバリソースのモニタリング
モニタリング対象として考えられるもの。
CPU使用率、メモリ使用率、ロードアベレージ、ネットワークトラフィックなど
監視用ツールはいろいろあるが、MuninとCactiについて使用感がのべられていた。
●サーバ管理の効率化
サーバ管理ソフトPuppeｔ紹介と設定方法解説。
●デーモンの稼働管理
デーモンは落ちたことにきがつきにくく、i/etc/init.dは再起動の機能がない。
デーモン稼働管理ソフトdaemontoolsの解説と設定方法。
●ネットワークブートの活用
ネットワークブートはマシンがブートするために必要なデータやファイルをネットワークから取得してブートすること。
ＰＸＥを利用したネットワークブート動作解説。
著者の環境でネットワークブートを利用しているのは、ロードバランサ、DBサーバ/ファイルサーバ、メンテナンス用ブートイメージ
●リモートメンテナンス
メンテナンス回線の構成例。インターネットからの入り口を二つに。
通常のログインができないときに使用するシリアルコンソールの紹介。
IPMIは隣のマシンからネットワークを通じて電源を制御する仕組み。
●Webサーバログの扱い
アクセスの集計やトラブル解析にログが必要。
ログの収集・・・各サーバに出力されたログを定期的にあつめ保存する
ログの集約・・・webサーバが出力するログを常に転送して１つにまとめること、そのときどきの状況を把握するために使う。
syslogを使用したログの集約解説
複数サイトの場合syslog-ngを使用。
Apacheのによるログのローテート方法。cronとrotatelogs
ログサーバ・・・ログの集約と収集、ログの保存、解析に使う。
６章 あのサービスの舞台裏
自律的なインフラへ、ダイナミックなシステムへ
●はてなのなかみ
はてなのインフラ解説と写真。
スケーラビリティと安定性のため、LVS（IPVS）＋keepalivedを利用したサーバ2台。VRRPで冗長化したのを1セット、リバースプロキシサーバ、APサーバ、DBサーバの3層のそれぞれの手和えに1セット配置。
LVSサーバのストレージはコンパクトフラッシュを使用。
各サーバの構成解説。
サーバはパーツを調達して社内でくみ上げBIOS設定、OSインストール。LDAPやautofsによるユーザログイン設定、Puppet初期設定、IRCチャネルにIP通知。目的はリモートで作業できるようにすること。
アプリケーションの動作に必要なライブラリなどのインストール設定、監視などのインフラの一部として動作するための設定は自動化されている。
サーバ管理は独自の監視ツールを作っている。オープンソースとして公開予定。
電源効率、リソース利用効率の向上を目指したサーバの導入のガイドライン
・サーバを設計・調達するときに１Aあたりのパフォーマンスを重視
・1台当たりのサーバ能力をできるだけ高めて、仮想化技術により、分割して利用
・不要なパーツはのせない。
最終的には生物のような自律的強固なインフラを目指す。
●DSASの中身
DSASとはKLab(株)が運用しているサーバ・ネットワークインフラの総称。
東京都福岡のデータセンターで300台以上のサーバが稼働している。
DSASの特徴
・一つのシステムに複数のサイトを収容。・・・どのサイトがどのサーバを利用するかは動的に変更できる
・オープンソースで構築
・どこが切れても止まらないネットワーク
・サーバ増設が簡単・・・ネットワークブート
・故障時の復旧が簡単・・・RSTPでL２スイッチを冗長化。DSASではインターネット回線がL2スイッチに直接接続されている。ロードバランサが直接インターネットと接続しているとロードバランサ故障時に代替え機にNIC増設ケーブル差替えがあるが、これがない。
![[24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)](https://images-fe.ssl-images-amazon.com/images/I/51uK4ACymiL._SL160_.jpg "[24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)")
インストール方法などはネットで簡単に調べられるが、その先の運用におけるこれらのノウハウには苦労したのでまとめたのだそうだ。
株式会社はてなとKLab株式会社による実際にサービスを提供するうえでの事例を扱っているため、より実践的になっている。
冗長化・・・障害が発生しても予備の機材でシステムの機能を継続できるようにすることを指す。可用性を確保するともいえる。
スケーラビリティ・・・利用者や規模の拡大にあわせて、どれだけシステムを拡張して対応できるかという能力。
1章サーバインフラ構築入門
冗長化の基本
１障害を想定化する
２障害にs萎えて予備の機材を準備する
３障害が発生した際に予備の機材に切り替えられる運用体制を整備する。
シンプルなwebサーバー、ルーター、インターネットの構成を考える。
・ルータの故障
ルータの予備機を用意してきりかえればよい。（コールドスタンバイ）
・Webサーバーの故障
予備機に切り替えても内容が同じでないといけない。そのためコールドスタンバイは現実的ではない。
常にネットワークに接続し、内容も同じに保たないといけない（ホットスタンバイ）
フェイルオーバー・・・現用機に障害が発生したとき自動的に処理を予備機に引き継ぐ仕組み。
VIPで予備機が仮想アドレスを引き継ぐ、ヘルスチェックプログラムでルーターとサーバのVIPを自動的に引き継ぐプログラムの例。
負荷分散（ロードバランス）・・・複数台のサーバに処理を分散させてサイト全体のスケーラビリティを向上させる手法
予備機になにもさせないのはもったいので、負荷分散で仕事をさせる。サーバ増設のときも古い資源も無駄にならない。
Webサーバの冗長化の具体的方法
DNSラウンドロビン・・・DNSを利用して一つのサービスに複数台のサーバを分散させる方法。
比較的簡単に負荷分散できるが、欠点としては以下がある。
・サーバの数だけグローバルアドレスが必要（VIPにすれば解決）
・均等に分散されると限らない
・サーバがダウンしても気が付かない
実際にフェイルオーバーするときのスクリプト例がのっていた。個々のサーバーにこのスクリプトを乗せる
ロードバランサ（負荷分散機）・・・１つのIPアドレスに対するリクエストを複数のサーバへ分散する。
この危機がサービス用のグローバルアドレスを持った仮想的サーバとして動作して、クライアントからのリクエストをリアルサーバに中継する。ヘルスチェックはロードバランサで行うので、個々のサーバにフェイルオーバーのプログラムを乗せる必要はないし、どのサーバに処理を割り当てるか制御できる。
欠点としては、アプライアンス製品は高価であるため収益が確保できない段階では導入に踏み切れないこと。
安価な構築方法としてLinuxのIPVSを利用したロードバランサの構築方法を紹介。
IPVS・・・Linuxが実装している負荷分散機能を提供するモジュール。L4スイッチ相当の機能を提供する。スケジューリングアルゴリズムを選択できる。
具体的ソフトウェア
ipvsadm・・・IPVSの開発元が提供しているコマンドラインツール。
keepalived・・・C言語で書かれているデーモン（Windosでサービスプログラムのイメージ）
keepalivedを使用した具体的なロードバランサ構築例。
L4スイッチ・・・OSI参照モデルのレイヤ４（トランスポート層）のさす。IPアドレスやポート番号の解析ができる。パフォーマンスがよい。
L7スイッチ・・・OSI参照モデルのレイヤ７（アプリケーション層）を指す。クライアントからリクエストされたURLまで解析できる。柔軟な設定ができる。
L4スイッチの構成例
NAT構成・・・クライアントからのパケットの送信先を書き換えてリアルサーバに送る。Webサーバからの応答パケットを受け取ってIPアドレスを描き戻す。
DSR構成・・・クライアントから受け取ったパケットをそのままリアルサーバに送る。リアルサーバはL４スイッチを経由しないで応答を返すことができる。(リアルサーバがグローバルアドレスを処理できる必要がある、リアルサーバのループバックインタフェースに仮想サーバのIPアドレスをわりあてるか、netfilterで仮想サーバあてのパケットを自分あてにDNATする方法が考えられる）
ロードバランサで同じサブネットのサーバを負荷分散する場合はDSR構成にしないと正常に通信できなくなるので注意。
ロードバランサの冗長化
VRRP・・・ロードバランサの冗長化プロトコル、ベンダ非依存。
仕組み解説。
VRRPパケット・・・マスターノードが定期的にマルチキャストアドレスに送出するパケット。仮想IPアドレス、仮想ルータID,プライオリティからなる。バックアップノードはこのパケットが一定期間こないとフェイルオーバーを開始する。
仮想IPアドレス（VIP）・・・VRRPパケットはすべて同じIPアドレスに送出されるので、どのノードが見分けるのに使う。
プライオリティ・・・どのノード(バックアップ）がマスタになるか、プライオリティで判別。自分よりプライオリティが高いノードがいたらマスタになるのをあきらめる。(ふぃえるオーバーしない）
プリエンプティブモード・・・これを無効にすると、すでにマスターになったノードがある限り、自分の方がプライオリティが高くてもフェイルオーバーしない。
仮想MACアドレス・・・MACアドレスも引き継がないと、通信相手の機器のARPテーブル(ここに通信相手のMACアドレスが入っており、キャッシュが更新されるまで変わらない）の内容と矛盾してしまう。
keepalivedでも利用できるので、ロードバランサをもう一台構築してkeepalivedを走らせれば簡単に冗長化できる。ただしkeepalivedは仮想MACアドレスを使っていないので、gratuitousARPを送出して、通信相手にARPテーブルを更新してもらう。ただし一度ではうまくいかないことがあるのでgrap_master_delay時間待ってから再送出を行う。
keepalivedを冗長化する例紹介。
2章ワンランク上のサーバ/インフラの構築
●リバースプロキシ・・・クライアントからの要求をうけとり(必要なら手元で処理を行った後）適切なWebサーバへ要求を転送する。Webサーバはリバースプロキシに応答を返す。普通プロキシサーバはLAN→WANの要求を代理で処理するが、リバースプロキシはWAN→LANの要求を代理するのでリバースとついている。この機能でクライアントからの要求がWebサーバに届く前後にいろんな処理ができる。動的コンテンツを配信するAPサーバの場合特に有効。
いろんな処理の例
・HTTPリクエストのURLをみて、/images/logo.jpgなら画像用Webサーバに、/newsであれば動的コンテンツ生成サーバ（APサーバ）に処理をわりあてる。通常1リクエストに1プロセスまたは１スレッドを割り当てるが、画像のような静的コンテンツまでメモリに常駐させる必要はないのでWebサーバをわけてAPサーバのメモリを節約する。
・クライアントのIPアドレスをみて、特定のIPアドレスのみサーバのアクセスを許可する。
・クライアントのUser-Agentをみて、任意のUser-Aentからのリクエストを特別なWebサーバへアクセス誘導する・
・/hoge/foo/barというURLを/hoge?foo=barというURLに変更してWebサーバへリクエストする。(見た目のURLをきれいにできる）
・HTTPのKeep-Alive機能を使ってAPサーバのバッファとして機能する。クライアントとリバースプロキシはKeep-Aliveだが、リバースプロキシとAPサーバの間はオフにする。APサーバよりたくさんのプロセスを立ち上げられる（1000-10000程度）リバースプロキシだからできる。
APサーバ・・・動的コンテンツを返却するWebサーバ。アプリケーションの起動に時間がかかるため、メモリに常駐させる手法をとることが多い。そのため大量のメモリが要求される。普通最大プロセス数は50-100。
HTTPのKeep-Alive・・最初の1リクエストで確率したサーバとの接続をそのリスエストが終了した後も切断せずに維持して、続くリクエストを処理する。複数のファイルをダウンロードするときなど早くなって便利。
Apachでリバースプロキシを構築するには、mod_proxy,mod_proxy_balancerを組み込む。
また、lightepd, Squidでも構築できる。
両方とも具体的紹介あり。
●キャッシュサーバ・・・HTTPはステートレスなプロトコルでドキュメントの状態をもたないためキャッシュしやすい
そのため、プロトコルレベルでキャッシュ機能がある。IEなどで一度取得したドキュメントはローカルにキャッシュしている。
FireFoxのLive HTTP Headerのやりとりをみてキャッシュの効果を説明。
サーバとサーバの間でもHTTPキャッシュは使える。
Squid・・・HTTP,HTTPS、FTPなどで利用されるオープンソースのキャッシュサーバ。複数のクライアントをSquid経由にすることでドキュメントの参照を高速化したりするのに使われる。
HTMLファイルCSS、JavaScript、画像などの静的ドキュメントを効率よくキャッシュできる。
動的コンテンツについては、一意なURLが与えられているドキュメントは基本的にキャッシュできる。またあるページを30分間だけキャッシュするなどの制御が可能。
ただし、動的なドキュメントでも状態を持つドキュメントはキャッシュするとまずい。この場合はより粒度の細かいキャッシュサーバ(memcachedなど）を選ぶ。
Squidでリバースプロキシを構築する方法を紹介。
mencachd・・・C言語で書かれた高速なネットワーク対応の分散キャッシュサーバ。ストレージにOSのメモリを使用。使用はプログラム内部から行う。
●MySQLのレプリケーション
DBサーバが停止した場合、問題となるの「DBのデータ」。
レプリケーション・・・一般的にはデータをリアルタイムに他の場所へ複製すること。
MySQLのレプリケーションとは2台のDBサーバでMySQLを実行して、まったく同じDBデータのサーバを作ること。
MySQLのバージョンは5.0.45を使用。
MySQLのレプリケーションの特徴は
・シングルマスタ、マルチスレーブ
・非同期のデータコピー
・レプリケーションされるデータの内容・・・レプリケーションがSQL文単位で行われる。この方法だとマスターとスレーブで異なる行が更新される可能性がある。MySQL5.1.5では行単位のレプリケーションができるので解決されている。5.1.8では混合モード（文単位と行単位の場合分け）もある。
レプリケーションの仕組み
スレーブでI/Oスレッド（マスタからの更新ログをファイルにいれる）とSQLスレッド（更新ログのファイルを実行）がデータの更新をしている。
マスタには「バイナリログ」(参照処理ではなく、更新処理のみが記録される、mysqlbinlogで解読できる）スレーブには「リレーログ」（マスタの更新ログをうけとったもの、更新が終わると自動で消去される）が作成される。
ポジション情報はスレーブがどこまでレプリケーションしたかを記録する。maser.infoに保管され、SHOW SLAVE STATUSというSQL文で確認できる。
レプリケーション構成の作り方紹介
my.cnf設定方法、レプリケーション用ユーザ作成、レプリケーション開始に必要なデータなど
レプリケーションを開始するにはスレーブでmysqldを起動。レプリケーションの状況を確認するには、「SHOW MASER STATUS」 「SHOW MASTER LOGS」 「SHOW SLAVES STATUS」など。
参照系のクエリをMySQLのスレーブにやらせて負荷を分散する方法紹介。
方法としてはアプリケーションによる分散と、内部ロードバランサによる分散がある
内部ロードバランサによるスレーブ参照の方法を紹介。
●ストレージサーバ・・・大容量コンテンツ（動画や音声）を配信するサービスでコンテンツファイルを格納するサーバ。各WebサーバはNFSマウントでコンテンツファイルを読みだす構成になる。ただし、ストレージサーバはボトルネックになりやすく、単一故障点になりやすい。
理想的なストレージサーバは読み込みが速く、ディスク容量が大きいのが条件。
読み込みを早くするために、HTTPをストレージプロトコルとして利用したストレージサーバの例
アップロードするサーバのみNFSマウントしており、サーバ内のNFSサーバーがHDDに書き込みを行う。
他のWebサーバは同じくサーバー内のWebサーバーを介してHDDから読み込みを行う。こうするとすべてのWebサーバがNFSマウントする必要がない。
HTTPはNFSに比べるとサーバとクライアントの結合が祖であるので、万一ストレージサーバの異常を検出してもエラーを返したりできる。
筆者の環境では、ストレージサーバに読み出しのリクエストが集中するときには、だいたい同じデータが読みだされているのでthttpdを使うことで負荷分散できたという。
単一故障点になるのを回避するには、複数台のサーバにファイルを分散させる必要があるが、大容量であるだけに同期が難しい。詳細は3章で。
３章 止まらないインフラを目指すさらなる工夫
●DNSサーバの冗長化
DNSサーバの障害は一旦発生すると原因が発生するまで時間がかかる。
レゾルバライブラリを使用した冗長化・・・/etc/resolv.confにDNSサーバを複数指定する。手軽な方法だが、異常を検出するのにタイムアウトを待たないといけないので性能低下の危険があるので避けたほうがいい。
サーバファームにおけるDNSの冗長化・・・VRRP（keepalived）を利用して、片方がVIPでActiveサーバになる構成にする。ただし、DNSサービスが停止してもフェイルオーバーしないので、digコマンドで自分自身にDNS問い合わせをするスクリプトを使う。さらにロードバランサを使って負荷分散をする。
●ストレージサーバの冗長化
RAIDを使うのが一般的だが、整合性のチェックは時間がかかるしサーバに負荷がかかる。
DRBDというソフトを使用するのを推奨していた。このソフトはファイル単位ではなくブロックデバイスに対する更新をリアルタイムに転送する。ネットワーク越しのRAID１と考えられる。このソフトの設定、フェイルオーバー（自動、手動）、方法紹介。
keepalivedとVRRPでNFSサーバを冗長化する方法紹介。
DRBDでディスクのミラーリングをしていても、オペミスで消してしまったファイルはやはり両方消されてしまう。バックアップはやはり行うべき。
●ネットワークの冗長化
L1(OSI参照モデルレイヤ１）、L2（OSI参照モデルレイヤ2）で故障が発生してもシステム停止しないように冗長化する方法。
故障の種類
１LANケーブル
２NIC（ネットワークカード）
３ネットワークスイッチのポート
４ネットワークスイッチ
１－３はサーバとスイッチ間の接続故障なので、リンク故障
１と３はスイッチ間接続の故障
４はスイッチ故障。
リンク故障対応・・・LinuxのBondingドライバは複数の物理的なネットワークカードをまとめて1つの論理的なネットワークカードとして扱う。この機能の設定方法解説。
スイッチ故障対応・・・スイッチを複数台用意して、Bondingドライバは以下の物理NICをそれぞれ別のスイッチに接続する。
スイッチ増設方法解説
ポートの多いスイッチに交換しただけなら状況は変わらないが、増設の場合は冗長性を保つうえでの条件が増える。カスケード接続した場合の例で解説。
すべてのスイッチが相互接続するとブロードキャストストームが発生するので注意。これを発生させないためのRSTPプロトコルの解説。
RSTPを使用するとBondingドライバｎ頼らずにスイッチの冗長化ができる。
●VLAN導入でネットワークを柔軟にする。
サーバファームにおける柔軟性の高いネットワークとは
１新規サーバ追加が容易
２サーバが故障したときにすぐに代替え機に移行できる
３あるサーバを別の役割のサーバに切り替えられる
これらにこたえられて、作業場のネックがない。
VLAN・・・物理的な構成ではなく、ネットワーク機器やサーバの設定で「論理的」にネットワークを分割して構成する技術。ブロードkyストドメインの分割が論理的に可能になる。同じスイッチに複数のセグメントの端末を接続しても、設定によって論理的にブロードキャストドメインを分割できるので、適切なポートにのみ、フレームがフォワードされる。
VLANを導入すると、
1台のスイッチで複数のセグメントを管理できる。
設定だけでポートに流れるデータを制御できる。
というメリットがある。
VLANの種類
スタティックVLAN・・・ポート単位に手動でグループの割り当てを行う
ダイナミックVLAN・・・つながる機器などによって動的にグループの割り当てを変える。
近年の傾向として、ユーザごとやMACアドレスごとなどのルールで制御を行うVLANを利用してセキュリティを高めるなどの使い方をされている。
ベンダ依存のVLAN
ポートVLAN
タグVLAN
データセンター内のサーバが故障したという想定で復旧までの流れを解説。
VLANを使わない場合と使った場合。
4章性能向上、チューニング
●Linux単一ホストの負荷の見極め
ＯＳのチューイングとは負荷の原因を知り、それを取り除くこと。
負荷は推測しないで計測する。
Linuxのツールps, top, sarで負荷を調べる。
ボトルネック見極めには、
ロードアベレージ（システム全体の負荷）を見る・・・特に処理を実行したくても実行できなくて待たされているプロセスがどのくらいあるか？
CPUかI/Oどちらがボトルネックか探る。・・・CPU使用率とI/O待ち時間
CPU負荷が高い場合
・ボトルネックはユーザプログラムの処理化システムプログラムか。
・原因となるプロセス特定
・プロセスを詳細にみるのにstraceでトレースしたり、oprofileでプロファイリング
I/O負荷が高い場合
・特定のプロセスが極端にメモリを消費していないか
・プログラムの不具合でメモリを使いすぎていないか
・多雨歳メモリが不足しているならメモリ増設か分散を検討。
負荷の総体を知るために、マルチタスクOSの仕組み、カーネルの動作、スケジューリングとプロセスの状態解説。
CPU使用率計算方法、マルチＣＰＵの場合など。
プロセスアカウンティングのカーネルコードの見方解説。スレッドとプロセス解説。
ps, sar, nmstatコマンド使い方
●Apacheのチューニング
Ａｐａｃｈｅ＝Apache HTTP SERVERはオープンソースのWebサーバのディファクトスタンダード。
ApacheのMPMを利用した並列処理の解説。これを利用した負荷分散の方法を解説。
●MySQLのチューニングのツボ
DBサーバのチューニングは、サーバサイド、サーバサイド以外、周辺システムで考えられる。
サーバサイドではディスクI/Oのチューニングがキモなので、ディスクI/O関連のKernelパラメータ調整、適切なファイルシステムの選択とマウントオプション調整が考えられる。
サーバサイド以外では、テーブル設計（適切なインデックスの作成、意図的な非正規化）、SQLの最適化（インデックスをうまく使うように、テーブルの結合順序と方法を調整）
周辺システムでは、memcachedなどのキャッシュサーバ。
サーバサイドのチューニングの中で重要なもの
メモリのパラメータ解説と、あるDBサーバ（実メモリ４GB）の設定値
チェックルール
5章省力運用
●サービス稼働監視
監視の種類
１死活状態の監視(pingなど）
２負荷状態の監視（CPU使用率、サービスの同時処理数）
３一定期間サービス提供ができていたか(稼働率)計測。
監視ツールNagiosを使った監視方法の解説。
●サーバリソースのモニタリング
モニタリング対象として考えられるもの。
CPU使用率、メモリ使用率、ロードアベレージ、ネットワークトラフィックなど
監視用ツールはいろいろあるが、MuninとCactiについて使用感がのべられていた。
●サーバ管理の効率化
サーバ管理ソフトPuppeｔ紹介と設定方法解説。
●デーモンの稼働管理
デーモンは落ちたことにきがつきにくく、i/etc/init.dは再起動の機能がない。
デーモン稼働管理ソフトdaemontoolsの解説と設定方法。
●ネットワークブートの活用
ネットワークブートはマシンがブートするために必要なデータやファイルをネットワークから取得してブートすること。
ＰＸＥを利用したネットワークブート動作解説。
著者の環境でネットワークブートを利用しているのは、ロードバランサ、DBサーバ/ファイルサーバ、メンテナンス用ブートイメージ
●リモートメンテナンス
メンテナンス回線の構成例。インターネットからの入り口を二つに。
通常のログインができないときに使用するシリアルコンソールの紹介。
IPMIは隣のマシンからネットワークを通じて電源を制御する仕組み。
●Webサーバログの扱い
アクセスの集計やトラブル解析にログが必要。
ログの収集・・・各サーバに出力されたログを定期的にあつめ保存する
ログの集約・・・webサーバが出力するログを常に転送して１つにまとめること、そのときどきの状況を把握するために使う。
syslogを使用したログの集約解説
複数サイトの場合syslog-ngを使用。
Apacheのによるログのローテート方法。cronとrotatelogs
ログサーバ・・・ログの集約と収集、ログの保存、解析に使う。
６章 あのサービスの舞台裏
自律的なインフラへ、ダイナミックなシステムへ
●はてなのなかみ
はてなのインフラ解説と写真。
スケーラビリティと安定性のため、LVS（IPVS）＋keepalivedを利用したサーバ2台。VRRPで冗長化したのを1セット、リバースプロキシサーバ、APサーバ、DBサーバの3層のそれぞれの手和えに1セット配置。
LVSサーバのストレージはコンパクトフラッシュを使用。
各サーバの構成解説。
サーバはパーツを調達して社内でくみ上げBIOS設定、OSインストール。LDAPやautofsによるユーザログイン設定、Puppet初期設定、IRCチャネルにIP通知。目的はリモートで作業できるようにすること。
アプリケーションの動作に必要なライブラリなどのインストール設定、監視などのインフラの一部として動作するための設定は自動化されている。
サーバ管理は独自の監視ツールを作っている。オープンソースとして公開予定。
電源効率、リソース利用効率の向上を目指したサーバの導入のガイドライン
・サーバを設計・調達するときに１Aあたりのパフォーマンスを重視
・1台当たりのサーバ能力をできるだけ高めて、仮想化技術により、分割して利用
・不要なパーツはのせない。
最終的には生物のような自律的強固なインフラを目指す。
●DSASの中身
DSASとはKLab(株)が運用しているサーバ・ネットワークインフラの総称。
東京都福岡のデータセンターで300台以上のサーバが稼働している。
DSASの特徴
・一つのシステムに複数のサイトを収容。・・・どのサイトがどのサーバを利用するかは動的に変更できる
・オープンソースで構築
・どこが切れても止まらないネットワーク
・サーバ増設が簡単・・・ネットワークブート
・故障時の復旧が簡単・・・RSTPでL２スイッチを冗長化。DSASではインターネット回線がL2スイッチに直接接続されている。ロードバランサが直接インターネットと接続しているとロードバランサ故障時に代替え機にNIC増設ケーブル差替えがあるが、これがない。
[24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)
- 作者: 安井 真伸
- 出版社/メーカー: 技術評論社
- 発売日: 2008/08/07
- メディア: 単行本（ソフトカバー）
2012-05-26 14:11
nice!(0)
コメント(0)
トラックバック(0)
コメント 0