駆け出しインフラエンジニアが「インフラエンジニアの教科書２」を読んだ

本

インフラエンジニアになって半年が経った（駆け出しインフラエンジニアというのは怪しい？）．インフラエンジニアたるもの1度は読んでおきたい本だったので「インフラエンジニアの教科書２」を読んでみた．本の中でインフラエンジニアが実務で注目しておくべき点がまとめられていたのでそれらを紹介していこうと思う．

読んだ感想としては，書名に教科書という単語が入っているのが納得なほどインフラエンジニアに欠かせない知識が体系的にまとめられている本だった．自分のようにインフラエンジニアになって日が浅い人は，インフラエンジニアとして学ぶべき技術を把握することがそもそも大変なので，この本を読むことで学ぶべき技術の対象がある程度はっきりする．また，オンプレでインフラを構築している方なら，この本を読んだ後に「これインフラエンジニアの教科書２で見たやつだ」ということが実務で起こりうる内容になっていると思う．駆け出しインフラエンジニアには何はともあれ読んでほしい！！

インフラエンジニアの教科書2 スキルアップに効く技術と知識

インフラエンジニアの教科書2 スキルアップに効く技術と知識

  • 作者:佐野 裕
  • 出版社/メーカー: シーアンドアール研究所
  • 発売日: 2016/08/26
  • メディア: 単行本（ソフトカバー）

目次

  • 第1章：プロトコル
  • 第2章：OS
  • 第3章：ネットワーク
  • 第4章：データベース
  • 第5章：WEBのサーバサイド開発言語
  • 第6章：共通鍵暗号方式と公開鍵暗号方式
  • 第7章：障害対策と障害対応
  • 第8章：よく知られたセキュリティ攻撃
  • 第9章：インターネットの運用と発展をつかさどる組織や団体
  • 第10章：RFCの読み方と作られ方
  • 第11章：世界規模のインターネットサービス運営
  • 第12章：インフラエンジニアとして目指す方向

インフラエンジニアのプロセス管理

サーバ上で何か問題が発生したときに各プロセスの状態に着目すると，サーバ上で何が起こっているか把握でき，その対策を考えることができる．
ここではインフラエンジニアがプロセス管理で意識しておくべきことを紹介する．

  • シングルプロセスかつシングルスレッドの処理速度向上

シェルスクリプトなどのシングルプロセスかつシングルスレッド型のプログラムでは，プロセスが１つしかないので実行時にCPUコアが１つしか使われない．このような場合はクロック数が高いCPUに入れ替えると処理速度が向上する．

  • CPUコアを無駄なく使う

マルチコアCPUを搭載したサーバにおいて，実行状態のプロセス数が少なくて，CPU使用率が0％のCPUコアが目立つ場合はCPUリソースが余っている状態である．このような場合は，他のアプリケーションを起動するか，もしくはすでに起動しているマルチプロセス型のプログラムの設定変更を行ってさらにCPUコアを割り当てることでCPUリソースを無駄なく使うことができる．

頻繁にプロセスのコンテキストスイッチが発生する環境では応答速度が落ちる．実行可能状態のプロセスを減らすことでコンテキストスイッチの発生を可能な限り抑えることが好ましい．

  • 割り込み処理

OSに割り込みが発生した場合もCPUコアが使われる．割り込みはIRQ（Interupt ReQuest）とも呼ばれる．Linuxカーネルの場合は割り込みが発生すると常に0番目のCPUコアを使おうとするが，irqbalanceサービスを起動しておくと，他のCPUコアにも割り当てが分散されるようになる．

インフラエンジニアのメモリ管理

不適切なメモリ利用が原因でメモリ使用量が限界近くまで上がると突然パフォーマンスが低下したり，カーネルパニックが発生してOSが落ちたりすることがある．
ここではインフラエンジニアがメモリ管理をするうえで気をつけるべき点を紹介する．

スワップが発生する場合，「物理メモリが足りない」か「物理メモリの断片化が進んでまとまったメモリを確保できない」の2つの原因が考えられる．
「物理メモリが足りない場合」は，物理メモリの増設を行うことで対応する．
「物理メモリの断片化が進んでまとまったメモリを確保できない場合」は，大量のメモリを確保しているプロセスを終了させることで割り当てられていた仮想メモリ空間を解放することが一番確実な方法である．下記の例のように，OSによってはスワップ領域自体を解放する方法もあるが，ディスクI/O負荷が非常に高く，かつとても時間のかかる処理なので実サービスで実施するのは危険．

# Linuxにおけるswap領域の操作コマンド
$ swapoff -a ← スワップ領域の解放と無効化
$ swapon -a ← スワップ領域の有効化
  • 空き物理メモリが足りなく見える

物理メモリ使用量が多くて空き物理メモリ量が足りなく見える場合でも，空き物理メモリのほとんどがキャッシュとして使われているだけで実質的には空き物理メモリとみなすことができる場合が多い．キャッシュには「ページキャッシュ」（ファイルのページ単位でのキャッシュ）と「バッファキャッシュ」（ディスクのブロック単位でのキャッシュ）がある．バッファキャッシュはOSで少しだけ使われるが，ページキャッシュはファイルにアクセスすればするほど肥大化していく．
下記の例をみると，32GBの物理メモリに対して，①空き物理メモリ量が1016MB（≒1GB程度）しか残っていないように見えるが，②実質的なメモリ使用量は21868MG（≒21.8GB程度）が使われていて，③キャッシュを除いた実質的な空きメモリ量は10226MB（≒10GB程度）となる．

$ free -m
              total          used           free        shared        buffers        cached
Mem:          32095         31078         ①1016             0            357          8852
-/+ buffers/cache:         ②21868        ③10226
Swap:          4095            10           4085

③キャッシュを除いた実質的な空きメモリ量は以下のように算出される．

10.226（MB）≒ Mem free 1016(MB) + buffers 357(MB) + cached  8852(MB)
  • バックアップとページキャッシュ

バックアップを取るために一時的に巨大なファイルを操作すると，ページキャッシュに乗っていたデータが追い出されて，一時的にしか使われないバックアップデータに取って代わられてしまうことがある．日常から負荷が高いサーバの場合，ページキャッシュに乗っていたデータが追い出された瞬間からサーバ負荷が急増してパフォーマンスに影響を与えることがある．
この回避策として，以下のようにddコマンドのダイレクトI/Oオプションを用いてブロック単位でバックアップを取る方法がある．ただし，この方法はとても遅いので注意する．

↓NFSマウントした外部ストレージにバックアップを取る場合
$ dd if=/home/user/1GB.txt of=/mnt/extdisk iflag=direct

↓同じサーバにバックアップを取る場合
$ dd if=/home/user/1GB.txt of=/home/backup/1GB.txt iflag=direct oflag=direct

インフラエンジニアのファイル管理

ファイルの操作はOSを利用する上でもっとも基本的な機能だが，OSのファイル管理の仕組みを理解していないと一見よく分からない事象がまれに起こる．
ここではファイル管理において時折見かける現象を紹介する．

  • ファイルを消しても空き容量が増えない

プロセスがファイルをオープンしている場合は元のファイルを消しても実際は削除されない．この場合，ファイルをオープンしているプロセスを終了すればファイルが完全に削除される．LinuxなどにおいてファイルをオープンしているプロセスIDを特定したい場合にはlsofコマンドを使う．以下の例では，削除したアクセスログをWebサーバのプロセスがオープンしているので，空き容量を増やすにはWebサーバの再起動が必要である．

$ rm /var/log/httpd/access_log
$ lsof | grep deleted
COMMAND        PID          USER          FD          TYPE          DEVICE          SIZE/OFF          MODE          NAME
httpd       103317        apache          3r           REG           8.1               7              273722        /var/log/httpd/access_log（deleted）
  • ディスク容量に空きがあるのにファイルを生成できない

Linuxなどで容量に空きがあるのにファイルを生成しようとすると「No space left on device」というエラーが出てファイルが書き込めないことがある．これはinodeテーブルが枯渇している状態である．以下のようにしてinodeの枯渇を調べることができる．

$ df
Filesystem       1K-blocks            Used           Available      Use% Mounted on
/dev/sba1       262930508           71539660         191390848           28% /    ←空き容量に余裕があるように見える

$ df -i
Filesystem       Inodes                 IUsed       IFree       IUse% Mounted on
/dev/sda1       16703488             16703488           0               100% /    ←inodeが枯渇していることがわかる

ファイルかディレクトリを1個生成する度にinodeが1個消費される．通常の用途では十分な量のinodeが用意されているが，小さいファイルやディレクトリを大量に作るとinodeが枯渇してしまうことがある．この場合はファイルかディレクトリを削除するか，もしくはinodeに余裕がある他のファイルシステム上のディレクトリに移動することでinodeの使用率を下げる方法がある．もしくは動的にinodeテーブルサイズを変更できるファイルシステムを使っている場合はinodeテーブルを拡張するという方法もある．

  • ログ出力でディスク容量を使い果たした

ApacheやTomcat，アプリケーションなどのログが肥大化してディスク容量を使い果たしてしまうことがある．このような場合はログを出力しているプロセスを停止してからログファイルを削除するか，もしくは他の大きいパーティションにログファイルを移動してからシンボリックリンクを貼ることで対処可能である．
しかし，どうしてもプロセスを停止できない場合は，以下のように既存のログファイルを他のパーテションにコピーして上書きすることでログファイルの中身を空にするという方法がある．

$ ls -lh /var/log/httpd/access_log
-rw-r--r-- 1 root root 480G Apr 1 19:27 access_log

$ cp /var/log/httpd/access_log /home/user/    ←他のディスクにデータを退避する
$ cp /dev/null /var/log/httpd/access_log      ←ログファイルの中身を空にする

$ ls -lh /var/log/httpd/access_log
-rw-r--r-- 1 root root 211 Apr 1 19:29 access_log  ←ログファイルが空になった後，新しいログが書き込まれている

このときによくある失敗としては，ログファイルをmvコマンドで他のパーテションに退避した後，同じファイル名でログファイルを作成してしまうというものである．この場合，プロセスがオープンしているログファイルのinode番号と新しく生成したログファイルのinode番号が異なるので，同じファイル名であったとしても，プロセスを再起動しない限りは新しいファイルにログが書き込まれることはない．そもそも古いファイルはまだ解放されていない状況なので空きディスク容量は増えない．

$ mv /var/log/httpd/access_log /home/user/           ←他のディスクにデータを移動する
$ echo "" > /var/log/httpd/access_log                ←同じファイル名でログファイルを新規作成する

...しばらくして...

$ ls -lh /var/log/httpd/access_log
-rw-r--r-- 1 root root 0 Mar 27 01:02 access_log     ←新しく作成したファイルにログが書き込まれない
  • 想定よりもハードディスクの空き容量が少ない

ext3/ext4などのファイルシステムでは，リザーブ領域もしくは予約領域と呼ばれるrootしか使えない専用領域がデフォルトで5%確保されている．そこでtune2fsコマンドでリザーブ領域を0%に変更すると，すべての領域が使えるようになる．

$ df -kh | grep -e /dev/sda3 -e Filesystem
Filesystem        Size        Used        Avail        Use% Mounted on
/dev/sda3         536G          0G         508G          0%    /home        ←使用率が0%なのに使える容量が実容量より少ない

$ tune2fs -l /dev/sda3 | grep -e "Block count" -e "Reserved block count"
Block count:             142540544
Reserved block count:    7127027     ←予約領域が5%分割り当てられている

$ tune2fs -m 0 /dev/sda3             ←予約領域を0%にする
tune2fs 1.41.12（17-May-2010）
Setting reserved blocks percentage to 0%（0 blocks）

$ tune2fs -l /dev/sda3 | grep -e "Block count" -e "Reserved block count"
Block count:             142540544
Reserved block count:    0           ←予約領域が0%になった

$ df -kh | grep -e /dev/sda3 -e Filesystem
Filesystem        Size        Used        Avail        Use% Mounted on
/dev/sda3         536G          0G         536G           0%    /home         ←使える容量が実容量と一致した

インフラエンジニアのネットワーク管理

ここではネットワークまわりでインフラエンジニアが関与すべきことを紹介する．

  • ネットワーク経由でのファイルコピーが遅い

ネットワーク経由でファイルコピーを行うとき，期待通りの速度が出ないことがある．この場合，以下のようにさまざまな要因が考えられる．

  1. 「ネットワークインタフェースの制限」
    1GbpsのNICを使っている場合，理論上は1Gbps / 8bit = 125MB/sが転送速度の上限となる．
  2. 「ネットワークスイッチのスイッチング性能不足」
    サーバとサーバの間にネットワークスイッチを挟んでいる場合，そのネットワークスイッチのスイッチング性能不足の場合がある．特に家庭用スイッチングハブを挟んでいる場合はそこがボトルネックになっている場合がある．この場合は業務用スイッチに置き換えるか，もしくはサーバ間をクロスケーブルを用いて直結することで転送速度が向上する．
  3. 「WindowsでNICのオフロード機能を使っている」
    Windowsの場合，ネットワークアダプタのオフロード機能が有効になっていると，転送速度が落ちる場合がある．この場合，ネットワークアダプタのプロパティでオフロードという名前がついている設定項目をすべて無効にすると転送速度が向上する可能性がある．
  4. 「プロトコル」
    扱うプロトコルによって桁違いの速度差が出ることがある．例えば，Windows Server 2003まで使われていたSMB1.0の場合，WAN間でのファイルコピーが特に遅いと言われている．

インフラエンジニアのデータベース管理

ここではデータベースまわりでインフラエンジニアが気をつけるべき点を紹介する．

万が一のデータベース障害に備えて正しい方法で定期的にバックアップを取っておくことが重要である．障害が発生したデータベースを障害発生直前の状態に復旧するためには，バックアップデータだけではなく，バックアップ取得時点から障害発生直前までに出力されたすべてのWAL（Write Ahead Logging）ログが必要であることに注意する．WALとは，書き込みや更新といった更新処理が走るとき，変更内容をログとして記録し，その後，実データに反映する仕組みである．バックアップデータを復元しただけだと，データベースはバックアップ取得時点の状態に戻るだけなので，障害発生直前の状態まで復旧するには，バックアップを復元した後WALログを流し込む必要がある．

  • RDBMS起因でない原因不明のパフォーマンス低下対応

原因不明のパフォーマンス低下が起こった場合，ハードウェアやOS側に問題がある場合がある．ハードウェア故障はOSのシステムログ（/var/log/syslogやイベントログなど）やRAIDコントローラーのログで確認できる．比較的よくみかけるのがハードディスクにエラーが発生していてパフォーマンスが低下するパターンである．ハードディスクは不良セクターが発生してもある程度は自己修復機能で修復され，エラーカウントが閾値を超えるとサーバはやっとハードディスク故障と認定する．しかし，実際はサーバが故障と認定する前の状態でも事実上，故障状態でパフォーマンス低下によるサービス影響が起きていることがある．このとき，ハードディスク内のエラーカウント値が急速に増えているものの，まだ閾値を下回っているため，OSのシステムログに現れてこず，普通に見ただけではハードウェア故障に気づくことができない．このような場合はRAIDコントローラーのログやステータス情報を見てハードディスクの劣化状態を知る以外に方法がない．MegaRAIDコントローラを使用している場合の例を以下に示す．

$ MegaCli -PDList -aall | grep -e Slot -e Count
Slot Number: 1
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0

Slot Number: 2
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0

↓ハードディスク故障の兆候が見える
Slot Number: 3
Media Error Count: 35
Other Error Count: 6
Predictive Failure Count: 2

Slot Number: 4
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0

誤植

以下のサイトに公開されている正誤表以外の誤植があったのでメモ程度にまとめておく．

www.c-r.com

  • Chapter3 P.105：特にdiscard値とunbindの発生は特に注意 -> 「特に」が2回出てきている
  • Chapter12 P.248：現在のバージョンの課題なそ -> 現在のバージョンの課題など
  • あとがき P.250：本があったいいのに -> 本があったらいいのに

まとめ

  • 「インフラエンジニアの教科書２」を読んだ
  • インフラエンジニアに欠かすことのできない知識が体系的にまとめられており，特に駆け出しインフラエンジニアにおすすめ
  • 記事ではインフラエンジニアが意識しておくべき点をまとめてみたが，これは一部分でありこれ以外にもまだ紹介されていた