書籍概要

WEB+DB PRESS plus

[24時間365日]サーバ/インフラを支える技術 ……スケーラビリティ、ハイパフォーマンス、省力運用

著者
発売日
更新日

概要

一度スタートしたサービスは止めたくない,というのはWebに携わる開発者や担当者に共通する意識ではないでしょうか。しかし,サービスの成長にともない,サーバの増強,ハードウェア/ネットワークの障害対応,複数サーバの同期と管理などが不可欠となり,24時間365日止まらないサービス,稼動し続けるサーバ/ネットワークインフラを設計・構築・運用するには,数々のテクニックが必要です。

本書では,Webシステムのスケールアウトを念頭に,負荷分散システムの構築&高可用の実現,パフォーマンスチューニング,そして手間を極力抑えた運用術という三つのテーマをまとめて解説します。

こんな方におすすめ

  • 24時間365日稼動し続けるサーバ/インフラの設計/構築/運用の基本を知りたい方
  • 複数のサーバを用いたWebシステム構築をお考えの方
  • システムの性能についてお悩みの方
  • サーバ/インフラの日々の運用管理テクニックを知りたい方

著者から一言

本書には,(株)はてなとKLab(株)のサーバ/インフラエンジニア陣総勢6名が書いた,絵空事ではない,実稼働中のシステムにまつわる実践的な情報が詰まっています。

実践的とはいっても,ハウツー本ではありません。手取り足取りのインストール手順の説明はありませんし,本に書いてあるとおりにコマンドを実行すれば何かができるというわけでもありません。……では何が書かれているのか?

システムというのは系です。系というのは個々の要素が関係しあって構成されるものです。本書で重視した点はここにあり,個々の要素技術の詳説をしつつ,これらをどのように関連付け,組み合わせ,つなげたかを明らかにするところに力を注ぎました。

つまり,本書に記されていることは,実際の現場において,我々がどのように考え,悩み,工夫してきたか,その軌跡と成果です。

読者の方々が次にサーバ/インフラの設計・構築・運用をするときに本書が役立つといいな,そんな思いをこめて本書を執筆しました。(「本書について」より)

WEB+DB PRESS plusシリーズページについて

特設サイトを設置しております。

本書関連の勉強会について

「サーバ/インフラ Tech Meeting開催概要」
http://gihyo.jp/event/2008/24svr-tech-meeting

※勉強会は終了しました。ご参加ありがとうございました。

目次

1章 サーバ/インフラ構築入門 ……冗長化/負荷分散の基本

1.1 冗長化の基本

  • 冗長化とは
  • 冗長化の本質
    • (1)障害を想定する
    • (2)予備の機材を準備する
    • (3)運用体制の整備 ……障害発生の際,予備機材に切り替える
  • ルータが故障した場合の対応
    • コールドスタンバイ
  • Webサーバが故障した場合の対応
    • ホットスタンバイ
  • フェイルオーバ
    • VIP
    • IPアドレスの引き継ぎ
  • 障害を検出する ……ヘルスチェック
    • Webサーバのヘルスチェック
    • ルータのヘルスチェック
  • Active/Backup構成を作ってみる
    • IPアドレスを引き継ぐしくみ
  • サーバを有効活用したい ……負荷分散へ

1.2 Webサーバを冗長化する ……DNSラウンドロビン

  • DNSラウンドロビン
  • DNSラウンドロビンの冗長構成例
  • もっと楽にシステムを拡張したい ……ロードバランサへ

1.3 Webサーバを冗長化する ……IPVSでロードバランサ

  • DNSラウンドロビンとロードバランサの違い
  • IPVS ……Linuxでロードバランサ
    • ロードバランサの種類とIPVSの機能
  • スケジューリングアルゴリズム
  • IPVSを使う
    • ipvsadm
    • keepalived
  • ロードバランサを構築する
    • Webサーバの設定
    • keepalivedを起動する
    • 負荷分散を確認する
    • 冗長構成を確認する
  • L4スイッチとL7スイッチ
  • ◎Column L7スイッチと柔軟な設定
  • L4スイッチのNAT構成とDSR構成
  • 同じサブネットのサーバを負荷分散する場合の注意
  • ◎Column LinuxベースのL7スイッチ

1.4 ルータやロードバランサの冗長化

  • ロードバランサの冗長化
  • 冗長化プロトコルVRRP
  • VRRPのしくみ
    • VRRPパケット
    • 仮想ルータID
    • プライオリティ
    • プリエンプティブモード
    • 仮想MACアドレス
  • keepalivedの実装上の問題
    • gratuitous ARP(GARP)の遅延送出
  • keepalivedを冗長化する
    • VIPの確認
    • VRRPの動作確認
    • VRRPインスタンスを分離する
    • VRRPインスタンスを同期する
  • keepalivedの応用

2章 ワンランク上のサーバ/インフラの構築 ……冗長化,負荷分散,高性能の追求

2.1 リバースプロキシの導入 ……Apacheモジュール

  • リバースプロキシ入門
  • HTTPリクエストの内容に応じたシステムの動作の制御
    • IPアドレスを用いた制御
    • User-Agentによる制御
    • URLの書き換え
  • システム全体のメモリ使用効率の向上
    • 例:動的ページにおけるリクエストの詳細
  • Webサーバが応答するデータのバッファリングの役割
    • HTTPのKeep-Alive
    • 例:メモリ消費とKeep-Aliveのオン/オフ
  • Apacheモジュールを利用した処理の制御
    • リバースプロキシの導入の判断
  • リバースプロキシの導入
    • Apache 2.2を使う
    • workerでhttpdを起動
    • httpd.confの設定
    • 最大プロセス/スレッド数の設定
    • Keep-Aliveの設定
    • 必要なモジュールのロード
    • RewriteRuleを設定
  • 一歩進んだRewriteRuleの設定例
    • 特定ホストからのリクエストを禁止
    • ロボットからのリクエストに対してはキャッシュサーバを経由させる
  • mod_proxy_balancerで複数ホストへの分散
    • mod_proxy_balancerの利用例

2.2 キャッシュサーバの導入 ……Squid,memcached

  • キャッシュサーバの導入
    • HTTPとキャッシュ
    • Live HTTP Headersで知るキャッシュの効果
  • Squidキャッシュサーバ
    • Squidでリバースプロキシ
    • Squidは何をキャッシュするのか
    • Squidの設定例
  • memcachedによるキャッシュ

2.3 MySQLのレプリケーション ……障害から短時間で復旧する

  • DBサーバが止まったら?
    • DBサーバが停止するケース
    • 短時間で復旧する方法
  • MySQLのレプリケーション機能の特徴と注意点
    • シングルマスタ,マルチスレーブ
    • 非同期のデータコピー
    • レプリケーションされるデータの内容
  • レプリケーションのしくみ
    • スレーブのI/OスレッドとSQLスレッド
    • バイナリログとリレーログ
    • ポジション情報
  • レプリケーション構成を作るまで
    • レプリケーションの条件
    • my.cnf
    • レプリケーション用ユーザの作成
    • レプリケーション開始時に必要なデータ
  • レプリケーションの開始
    • マスタ,スレーブのmy.cnfの比較
    • スレーブの動作開始&確認
  • レプリケーションの状況確認
    • マスタの状況確認
    • スレーブの状況確認

2.4 MySQLのスレーブ+内部ロードバランサの活用例

  • MySQLのスレーブの活用方法
    • スレーブ参照
    • 複数のスレーブに分散する方法
  • スレーブ参照をロードバランサ経由で行う方法
    • 概略図
    • 内部ロードバランサの設定
    • MySQLスレーブの設定
    • スレーブ参照のロードバランスを体験
  • 内部ロードバランサの注意点 ……分散方法はDSRにする

2.5 高速で軽量なストレージサーバの選択

  • ストレージサーバの必要性
    • ストレージサーバは単一故障点になりやすい
    • ストレージサーバはボトルネックになりやすい
  • 理想的なストレージサーバ
    • 負荷を軽くする工夫
  • HTTPをストレージプロトコルとして利用する
    • 軽量なWebサーバの選択
    • HTTPを利用するメリット
  • 残る課題
  • ◎Column 小さくて軽いWebサーバの選択

3章 止まらないインフラを目指すさらなる工夫 ……DNSサーバ,ストレージサーバ,ネットワーク

3.1 DNSサーバの冗長化

  • DNSサーバの冗長化の重要性
  • レゾルバライブラリを利用した冗長化と,問題
    • レゾルバライブラリの問題点
    • 性能低下の危険性 ……メールサーバの例
    • DNS障害の影響は大きい
  • サーバファームにおけるDNSの冗長化
  • VRRPを利用した構成
  • DNSサーバの負荷分散
  • まとめ

3.2 ストレージサーバの冗長化 ……DRBDでミラーリング

  • ストレージサーバの故障対策
  • ストレージサーバの同期は困難
  • DRBD
    • DRBDの構成
  • DRBDの設定と起動
    • DRBDのマスタサーバを起動する
    • DRBDのバックアップサーバを起動する
  • DRBDのフェイルオーバ
    • 手動で切り替える
    • keepalivedの設定
    • keepalivedをdaemontoolsで制御する
  • NFSサーバをフェイルオーバする際の注意点
  • バックアップの必要性

3.3 ネットワークの冗長化 ……Bondingドライバ,RSTP

  • L1/L2構成要素の冗長化
  • 故障するポイント
  • リンクの冗長化とBondingドライバ
    • Bondingドライバ
  • スイッチの冗長化
    • リンク故障時の動作
    • スイッチ故障時の動作
    • スイッチ間接続の故障時の動作
  • スイッチの増設
    • さらなる冗長化を目指して
  • RSTP
    • ブリッジの優先順位とルートブリッジ
    • RSTPにおけるポートの役割
    • RSTPの動作
  • おわりに

3.4 VLANの導入 ……ネットワークを柔軟にする

  • サーバファームにおける柔軟性の高いネットワーク
  • VLANの導入がもたらすメリットを考える
    • スイッチの有効利用
    • 故障したサーバの復旧体制 ……1台の代替機を活用したい
    • 1台の代替機による復旧と,VLANの使いどころ
  • VLANの基本
  • VLANの種類
    • ポートVLAN
    • タグVLAN
  • サーバファームでの利用
    • VLANを使わない場合の構成
    • ポートVLANを利用した構成
    • タグVLANを利用した構成
  • 複雑なVLAN構成でも物理構成はシンプルさが鍵

4章 性能向上,チューニング ……Linux単一ホスト,Apache,MySQL

4.1 Linux単一ホストの負荷を見極める

  • 単一ホストの性能を引き出すために
    • 性能とは何か,負荷とは何かを知る
  • 推測するな,計測せよ
  • ボトルネック見極め作業の基本的な流れ
    • ロードアベレージを見る
    • CPU,I/Oのいずれがボトルネックかを探る
    • CPU負荷が高い場合
    • I/O負荷が高い場合
  • 負荷とは何か
    • 二種類の負荷
    • マルチタスクOSと負荷
    • 負荷の正体を知る=カーネルの動作を知る
    • プロセススケジューリングとプロセスの状態
    • プロセスの状態遷移の具体例
    • プロセスの状態遷移のまとめ
    • ロードアベレージに換算される待ち状態
    • ロードアベレージが報告する負荷の正体
  • ◎Column プロセスの状態をツールで見る ……ps
  • ロードアベレージ計算のカーネルのコードを見る
  • ロードアベレージの次はCPU使用率とI/O待ち率
    • sarでCPU使用率,I/O待ち率を見る
    • CPUのユーザモードとシステムモード
    • I/Oバウンドな場合のsar
  • マルチCPUとCPU使用率
  • CPU使用率の計算はどのように行われているか
  • プロセスアカウンティングのカーネルコードを見る
  • スレッドとプロセス
    • カーネル内部におけるプロセスとスレッド
    • psとスレッド
    • LinuxThreadsとNPTL
  • ps,sar,vmstatの使い方
    • ps ……プロセスが持つ情報を出力する
    • VSZとRSS ……仮想メモリと物理メモリの指標
    • TIMEはCPU使用時間
    • ブロッキングとビジーループの違いをpsで見る
    • sar ……OSが報告する各種指標を参照する
    • sar -u ……CPU使用率を見る
    • sar -q ……ロードアベレージを見る
    • sar -r ……メモリの利用状況を見る
    • I/O負荷軽減とページキャッシュ
    • ページキャッシュによるI/O負荷の軽減効果
    • ページキャッシュは一度readしてから
    • sar -W ……スワップ発生状況を見る
    • vmstat ……仮想メモリ関連情報を参照する
  • OSのチューニングとは負荷の原因を知り,それを取り除くこと

4.2 Apacheのチューニング

  • Webサーバのチューニング
  • Webサーバがボトルネック?
  • Apacheの並行処理とMPM
    • preforkとworker,プロセスとスレッド
    • プログラミングモデルから見たマルチプロセス/マルチスレッドの違い
    • パフォーマンスの観点で見たマルチプロセス/マルチスレッドの違い
    • 1クライアントに対して1プロセス/スレッド
  • httpd.confの設定
    • Apacheの安全弁MaxClients
    • preforkの場合
    • 親子でメモリを共有するコピーオンライト
    • コピーオンライトで共有しているメモリサイズを調べる
    • MaxRequestsPerChild
    • workerの場合
    • 過負荷でMaxClientsを変更する,その前に
  • Keep-Alive
  • Apache以外の選択肢の検討
    • lighttpd

4.3 MySQLのチューニングのツボ

  • MySQLチューニングのツボ
    • チューニングの切り口での分類
    • (1)サーバサイド
    • (2)サーバサイド以外
    • (3)周辺システム
    • 本節でこれから扱う内容
  • メモリ関係のパラメータチューニング
    • バッファの種類 ……チューニングの際の注意点(1)
    • 割り当て過ぎない ……チューニングの際の注意点(2)
    • メモリ関連のパラメータ
  • メモリ関連のチェックツール ……mymemcheck

5章 省力運用 ……安定したサービスへ向けて

5.1 サービスの稼働監視 ……Nagios

  • 安定したサービス運営と,サービスの稼働監視
  • 稼働監視の種類
    • (1)死活状態の監視
    • (2)負荷状態の監視
    • (3)稼働率の計測
  • Nagiosの概要
    • Nagiosのインストール
  • Nagiosの設定
    • 設定ファイル
    • host ……ホストの設定
    • service ……サービスの定義
    • command ……コマンド定義
    • contactとcontactgroup ……通知先と通知先グループ
    • 設定のテスト
  • Web管理画面
  • Nagiosの基本的な使い方
    • ホストとサービスの定義
    • 通知
  • 応用的な使い方
    • 稼働率の測定
    • 独自プラグイン
  • おわりに

5.2 サーバリソースのモニタリング ……Ganglia

  • サーバリソースのモニタリング
    • モニタリングの目的
  • モニタリングのツールの検討
  • Ganglia - 大量ノード向けのグラフ化ツール
  • Apacheプロセスの状態をグラフ化
    • Gangliaにグラフを追加する方法
    • 実際に複合グラフを追加してみる
    • そのほかのカスタムグラフ

5.3 サーバ管理の効率化 ……Puppet

  • 効率的なサーバ管理を実現するツールPuppet
  • Puppetの概要
  • Puppetの設定
    • ノードの定義
    • クラスの定義
    • 設定の反映
  • 設定ファイルの書き方
    • リソースの定義
    • リソース
    • サーバごとの設定の微調整
    • リソース間の依存関係
    • テンプレートによるマニフェストの定義
  • 動作ログの通知
  • 運用
  • 自動設定管理ツールの功罪

5.4 デーモンの稼働管理 ……daemontools

  • デーモンが異常終了してしまったら
  • daemontools
    • daemontoolsを使う理由
    • デーモンになるための条件 ……フォアグラウンドで動作する
  • デーモンの管理方法
    • デーモンの新規作成
    • デーモンの開始
    • デーモンの停止,再開,再起動
    • デーモンの削除
    • シグナル送信
    • keepalived ……runファイルの例(1)
    • 自作の監視スクリプト ……runファイルの例(2)
  • daemontoolsのTips
    • 依存するサービスの起動順序の制御
    • 便利シェル関数

5.5 ネットワークブートの活用 ……PXE,initramfs

  • ネットワークブート
    • ネットワークブートの特徴と利点
  • ネットワークブートの動作 ……PXE
  • ネットワークブートの活用例
    • ロードバランサ
    • DBサーバ/ファイルサーバ
    • メンテナンス用ブートイメージ
  • ネットワークブートを構成するために
    • initramfsの共通化と役割の識別
    • ディスクレス構成にする際に考慮すべき点

5.6 リモートメンテナンス ……メンテナンス回線,シリアルコンソール,IPMI

  • 楽々リモートログイン
  • ネットワークトラブルに備えて
    • メンテナンス回線
    • スイッチのトラブルに対する備え
  • シリアルコンソール
    • シリアルコンソールの実現
  • IPMI
    • IPMIでできること
    • IPMIを使うには
  • おわりに

5.7 Webサーバのログの扱い ……syslog,syslog-ng,cron,rotatelogs

  • Webサーバのログの集約・収集
  • 集約と収集
  • ログの集約 ……syslogとsyslog-ng
    • syslogを使ったログの集約
    • syslog-ng
  • ログの収集
    • Apacheログのローテート ……cronとrotatelogs
  • ログサーバの役割と構成
  • おわりに

6章 あのサービスの舞台裏 ……自律的なインフラへ,ダイナミックなシステムへ

6.1 はてなのなかみ

  • はてなのインフラ
  • スケーラビリティと安定性
    • リバースプロキシ
    • DB
    • ファイルサーバ
  • 運用効率の向上
    • キックスタートによるインストール
    • パッケージ管理とPuppet
    • サーバの管理と監視
    • Capistranoによるデプロイ
  • 電源効率・リソース利用率の向上
    • 1Aあたりのパフォーマンスを重視する
    • 1台あたりのサーバ能力をできるだけ使い切る
    • 不要なパーツは載せない
  • 自律的なインフラに向けて

6.2 DSASのなかみ

  • DSASとは
  • DSASの特徴
    • 一つのシステムに複数のサイトを収容
    • OSSで構築
    • どこが切れても止まらないネットワーク
    • サーバ増設が簡単
    • 故障時の復旧が簡単
  • システム構成の詳細
    • Bondingドライバを利用する理由
    • DRBDをフェイルオーバする際の注意点
    • SSLアクセラレータ
    • ヘルスチェック機能の拡張
    • 簡単で安全に運用できるロードバランサ
    • セッションデータの取り扱い
    • memcached
    • repcached
  • DSASの今後

Appendix

  • mymemcheck(4.3節)
  • apache-status(5.2節)
  • ganglia.patch(5.2節)

サポート

ダウンロード

本書のサンプルコードをダウンロードできます。

データは,圧縮ファイル形式でダウンロードできます。圧縮ファイルをダウンロードしていただき,適宜解凍してご利用ください。

正誤表

本書掲載の記述に誤りがありました。ここに訂正し,深くお詫び申し上げます。

(2012年5月8日更新)

p.61 13行目(第4刷以降,修正済み)

BalacnerMemberディレクティブ
BalancerMemberディレクティブ

p.106 リスト3.1.2 1行目~2行目(第9刷以降,修正済み)

#/bin/sh
while true do
#!/bin/sh
while true; do

p.113 3行目(第6刷以降,修正済み)

drdbadm
drbdadm

p.183 4行目(第4刷以降,修正済み)

kmbmemfree
kbmemfree

p.189 3行目(第4刷以降,修正済み)

それがによって
それがによって

p.201 リスト4.2.1 6行目(の一部)(第7刷以降,修正済み)

usage: %0
usage: $0

p.245 (本文)下から10行目(第6刷以降,修正済み)

gmetrix
gmetric

p.259 下から1行目(第6刷以降,修正済み)

59:106:108
59.106.108

p.324 図6.2.3 バックエンドサーバ「PS/WS」の役割について(第7刷以降,修正済み)

補足

「PS/WS」は「Permanent Share/Web Share」の略で,PSはNFS経由,WSはHTTP経由で共有ファイルにアクセスできることに由来した名称です。「PS/WS」とは「NFSサーバにWebサーバを載せたサーバ」を意味しています。サーバ構成上は,PSとWSは同じサーバを指していますが,たとえば,アプリケーション開発者と仕様について話をするときなどは,

  • PSからファイルを読み込みます -> NFS経由
  • WSからファイルを読み込みます -> HTTP経由

という具合に使い分けることがあります。

補足情報

P.102 3.1節「DNSサーバの冗長化」の参考情報

事象:メインマシンのDNSを停止した際に,バックアップ機に仮想IPでDNSに接続できない(タイムアウト)場合の対応について

DNSサーバのBINDは,起動時にNICに割り当てられている

IPアドレスごとにリクエストを待ち受ける実装になっています。

そのため,BINDの稼働中に動的にIPアドレス割り当てられても,新しいIPアドレス宛のDNSリクエストに応答できないため,フェイルオーバ時にはBINDを再起動する必要があります。

Keepalivedは,フェイルオーバしたときに任意のコマンドを実行できるようになっているため,keepalived.confのvrrp_instanceの中に,以下のような設定を追加することで対応可能です。

notify_master "/etc/init.d/named restart"

商品一覧