サーバインフラを支える技術を読んでみて

サーバインフラを支える技術を自腹購入して通勤時に一読しました。

まだ一回しか読めていなく、コードなども書かれている箇所の試しもまだ出来ていない箇所がほとんどですが、覚えた事など随時記録していこうと思います。

購入に至った経緯

サーバ構築や運用を日々ある程度やる必要が出てきており、（とは言っても小さな環境ですが）勉強会やQiitaでの情報収集時にみんなサーバインフラの知識があるなと日々感じ取っており、自分ももっと知っておかなきゃ。と思った為です。

あとこの技術評論社のWEB+DB PRES plusシリーズだと、とりあえず読んでみておきたくなりamazonでポチりました。

覚えた事・新しく知った事・感想など

読んでみて覚えた事や新しく知った事やその感想など章ごとに書いておこうと思います。

逆にこういう事が覚えられる本（サーバインフラを支える技術）だという事にもなりそうです。

あと自分が良くわからなかった点や深い理解を必要とする箇所についてはまだ書けない為、また理解した際に追記します。また、そんなレベルですので解釈の誤りもありそう・・・。ですので、ここに書いた内容は本（サーバインフラを支える技術）の内容イコールでもないですし、不足点が多くなりますのでご注意ください。

本は基本的な考えや知識の説明からの記載があり、具体的に設定する例などもあります。自分は具体的な設定例の方は実際にやってみないとわからないところが多いので、知識を深める目的で今読んでいます。

冗長化の基本

冗長とは「《名・ダナ》述べ方が長たらしく、むだのあること。」のようです。悪い言葉のようですが、サーバ運用においてのこの言葉のざっくりとした捉え方としては、予備構成を準備しておき（冗長）障害時に切り替えようという感じだと思いました。

フェイルオーバ

フェイルオーバ。完全に意味を忘れていたので再認識出来ました。

障害時などに自動的に予備に切り替える事でした。

ちなみに手動切り替えはスイッチオーバです。

VIP（Virtual IP Adress）

仮想IPアドレスです。

フェイルオーバ時に自動的に予備機に切り替える際に、インターネットから見たIPは変えたくないので、このVIPを本番機に振っておき、障害時には予備機にこのVIPをあてるという感じになります。

ヘルスチェック

VIPでのフェイルオーバをするには自動的に障害を検出するしくみが必要で、そのしくみがヘルスチェックです。

DNSラウンドロビン

サーバ構築の話しでロードバランサという言葉を良く耳にします。割り振ってくれる役割という事しかわかっていませんでしたが、もう少し知識が深まりました。

webサーバへのアクセスを順番に割り振ってくれるのですが、それがDNSを使用して割り振られます。ただし、割り振るだけなので、割り振り先のwebサーバ障害は検出出来ません。

その場合の冗長構成例として、前述のVIPでのフェイルオーバになります。

本（サーバインフラを支える技術）にはフェイルオーバのコードもあります。

IPVSでロードバランサ

ロードバランサ（負荷分散器）は専用機器ですが、OSSでも構築出来ます。

IPVS（IP Virtual Server）

LinuxにIPVSという負荷分散機能のモジュールがあります。それを使えばロードバランサを構築出来ます。

ロードバランサにはL4スイッチとL7スイッチの2種類あります。

余談ですが、Lはレイヤで、OSI7階層の番号です。OSI7階層はネットワークの階層です。以下ですが、自分の7階層の覚え方は、7階層目から、ア、プレ、ゼン、ト、ネ、デ、ブです。

1. 物理層
2. データリンク層
3. ネットワーク層
4. トランスポート層
5. セッション層
6. プレゼンテーション層
7. アプリケーション層

話しを元に戻して、ロードバランサのスイッチ2種類は、L4（トランスポート層）とL7（アプリケーション層）があるという事になります。

この層でロードバランサの機能を使うという事は、L4スイッチ（トランスポート層）はIPアドレスやポート番号で分散し、L7スイッチ（アプリケーション層）はリクエストのURLで、分散出来るという事です。

一般的にロードバランサはL4を指すようです。L4の方がパフォーマンスが良いです。

IPVSはipvsadmとkeepalivedのツールで利用出来ます。

本（サーバインフラを支える技術）には設定時のコードもあります。

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

ロードバランサそのものの障害時を考慮してロードバランサも冗長化（フェイルオーバ）する方法が紹介されています。

VRRP（Virtual Router Redundancy Protocol）

仮想　ルータ　冗長性　規約　と訳してみましたが、どうなんでしょう。

機器のベンダによって規約がなかった為、冗長化させる為の標準化規約のようです。

これにより仮想ルータID、仮想MACアドレスが利用出来るので、ここで冗長化させてフェイルオーバ出来るようになります。

本（サーバインフラを支える技術）にはこれらの設定例のコードもあります。

リバースプロキシの導入

普通のプロキシは、インターネットへのアクセス時に、代理でアクセスする事ですが、

リバースプロキシでは、インターネットからのアクセス時に、代理で返答します。

webサーバの代わりに代理でプロキシサーバが返答してくれるので、ここに振り分け（IPやuser agentなどで）など処理（URLの書き換えなど）を入れたりする事が出来ます。

apacheのmod_proxy_balancerで分散化も出来ます。

本（サーバインフラを支える技術）には導入の設定例など記載があります。

キャッシュサーバの導入

Squid

OSSのHTTPレベルでのキャッシュサーバです。大学や企業のクライアント側に設置して、クライアントLAN内側でキャッシュします。

これをリバースプロキシとしても使えます。サーバ側のLAN内でキャッシュする形です。

本（サーバインフラを支える技術）にはこれの設定例など記載があります。

memcached

SquidがHTTPレベルでのキャッシュサーバで、memcachedはアプリ内部が利用するデータの粒度でキャッシュするサーバです。

MySQLのレプリケーション

MySQLのレプリケーションについて仕組みから設定例まで色々と書いてます。

スレーブには2つのスレッドがあります。

1. I/Oスレッド
2. SQLスレッド

I/Oスレッドは、マスタの更新ログをリレーログに記録します。

SQLスレッドは、リレーログを読んでSQLを実行します。

このブログのMySQLの記事はこちら。

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

スレーブをバックアップ以外にも有効活用しようという事で、スレーブを参照用に使用します。スレーブを複数準備して内部ロードバランサで分散させようという事でした。

具体的な設定例の記載があります。

DNSサーバの冗長化

DNSサーバの冗長化やVRRPを利用した構成例などについて書かれています。

ストレージサーバの冗長化DRBD（Distributed Replicated Block Device）でミラーリング

ストレージサーバの冗長化について書かれています。同期が困難なのでDRBDというツールを使った方法・そのフェイルオーバなどが記載されています。

ネットワークの冗長化　Boundingドライバ、RSTP

L1物理層、L2データリンク層での冗長化について書かれています。Linuxのネットワークドライバを使って冗長化させる例が書かれています。

Boundingドライバ

Linuxのネットワークドライバです。複数のNICを１つのNICとして扱えるようにします。NICの冗長化。

NICの故障チェックをして使わないようにも出来る。

故障検出方法以下の２種類が存在する。

1. MII監視（Media Independent Interface）
2. ARP監視（Address Resolution Protocol）

MII監視はNICがリンクダウンしているかで故障判断する。

ARP監視はリクエストのリプライ有無で故障判断する。

RSTP（Rapid Spanning Tree Protocol）

スイッチ間接続を冗長化させて増やしていくとループしてしまうので、正常時はループするところを自動的に遮断するプロトコル。スイッチ間でのBPDU（Bridge Protocol Data Unit）パケットのやり取りで故障判断する。

VLAN（Virtual LAN）の導入　ネットワークを柔軟にする

VLANを使用すればスイッチが１つでもLANを複数組める。

VLANは以下の2種類の方法が存在

1. スタティックVLAN
2. ダイナミックVLAN

スタティックVLANは、ポート単位に手動でLANを決める。

ダイナミックVLANは、接続機器によって動的にLANを決める。

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

見極めるもの、

1. ロードアベレージ
2. CPU
3. I/O

top,uptimeでロードアベレージを見る。

top,sarでCPU負荷を見る。

sar,vmstatでI/O負荷を見る。

※本にはもっと細かく書いてます。

Apacheのチューニング

以下の平行処理の種類がある。

1. マルチプロセスモデルは、複数のプロセスで処理をする。
2. マルチスレッドモデルは、実行単位のスレッドで処理をする。
3. イベントドリブンモデルは、イベント毎に処理をする。シングルスレッド。

MPM（Multi Processing Module）

以下のMPMがある。

1. preforkは、複数プロセスを生成してクライアント接続に備えるマルチプロセスモデル。
2. workerは、マルチスレッドとマルチプロセス両方。

Apacheのコンパイル時にどちらか決める。

MySQLのチューニングのツボ

パーティショニング

テーブルを物理的に分ける。感じ？（やった事ありません

ただ、個人的にはパーティショニングするのではなく、テーブルを分割すれば良いような気がします。ユーザテーブルをユーザ基本テーブルとユーザ詳細テーブルにする感じです。そういう事は書いてませんがどうなのでしょうか。パーティショニングをやった事がないのでやった時に追記します。

設計

以下については良くやっています。インデックスに気を付けながら結合していくと速くなる感覚でいます。

• SQL改善テーブル結合箇所
• SQL改善インデックス）
• 非正規化
• スロークエリ対応

ただ、個人的には非正規化についてはあまりやりたくありません。早くなるのは良いのですが、一時しのぎ的な対応に感じます。非正規化してしまうと、あとあと発生する仕様変更にデータベース構造が追いつかなくなってくる気がします。なんでこんなテーブル設計してるんだみたいな。テーブルは柔軟な形でおいておきたいのですが、それでも遅くてどうにかしないといけない時がくるのでしょうか。未経験ゾーンです。

他

キャッシュを使うというチューニングもあるようです。

他、本にはメモリ関連のパラメータチューニングについて詳しく書いてました。

サービスの稼働監視

OSSサービス稼働監視ツールのNagiosについて概要や使い方が書かれています。

この本も勢いで買いました。まだ実践してません。実践したら記事にします。

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

ツールの紹介。Gangliaの概要や設定例が書かれています。

これもまだ実践してません。実践したら記事にします。

サーバ管理の効率化

サーバ群を管理出来るPuppetというツールがあり、設定や使用例の記載があります。

これもまだ使った事がありません。

デーモンの稼働管理

daemontools

ネットワークブートの活用

ネットワークブートとはブートに必要なファイルをネットワーク上から取得してブートする事です。ディスクレスシステムも可能になる。

ネットワークブートの動作・活用例などの記載があります。

リモートメンテナンス（メンテナンス回線、シリアルコンソール、IPMI（Intelligent Platform Management Interface）)

リモートメンテナンスする為の手段として、メンテナンス回線、シリアルコンソール、IPMIがある。

メンテナンス回線・・・そのままで、裏口的な考え。

シリアルコンソール・・・別のマシンからRS-232Cで接続して操作する。

IPMI（Intelligent Platform Management Interface）・・・隣りのマシンからネット経由で電源制御。

Webサーバのログの扱い（syslog,syslog-ng,cron,rotatelogs）

syslogについて、apacheのログのローテートrotatelogsについて記載があります。

はてなのなかみ

はてなの環境紹介です。

MySQLのマルチマスタ設定。（そういうのが出来るのですね・・・）

サーバのリソースを全て使用する。仮想か技術を駆使して余らせないようにする。

トラフィック・負荷に応じて生き物のように増えたり減ったり勝手にするような仕組みを構築しようとしている。

など、もっともっと詳しく書いてます。（かいつまんでここに書ける知識がありません）

DSASのなかみ

DSAS環境紹介です。

どこが切れても止まらないネットワーク。（サーバ・スイッチなど冗長化）

サーバ増設が簡単。（ネットワークブート）

故障時の復旧が簡単。（ネットワークブート・スイッチの冗長化によりロードバランサ故障時でも代替サーバがネットワークブートでロードバランサとして起動。更にリモートメンテナンス可能）

他にも書けない事（私が理解出来ていない事）が書いてます。

まとめ

この本は自分が今後サーバ／インフラ構築する際の１つの指針となりました。迷った時など見返せるよう情報にインデックスを貼れてよかったです。

とは言っても、2008年の本なので現状ではもっと違うツールが使われていたりするはずです。その辺のところは最新の情報を見る必要がありそうです。

ツールを使った事がないのは仕方ありませんが、どんなツールでも良いからやった。という経験がない箇所が多かったので、そういう事が出来るのかという知識が広がった気がします。

また１年後などに見直して追記修正したいです。