LinuC レベル 2 Version10.0 学習教材
（新規追加出題範囲）

v1.0.2 版

【改訂履歴】

版

v1.0.0(2020 年 5 ⽉ 1 ⽇)
v1.0.1(2020 年 9 ⽉ 3 ⽇)
v1.0.2(2021 年 4 ⽉ 1 ⽇)

主な改訂内容（概要）新規作成
2.06.2 Docker コンテナとコンテナイメージの管理
・⼀部⽂⾔の修正・タイトルの変更
・本教材の位置付け説明のテキスト修正・問い合わせ先の変更

1
https://linuc.org/

本学習補助教材の位置づけ
本学習教材は、ボランティアの⽅のご協⼒により LinuC レベル２Version 10.0 の出題範囲の中で過去の LinuC のバージョン（レベル２：Version4.5)と⽐べて新たに追加となった
項⽬に絞って解説をするものです。
市販の LPI-Japan 認定教材（Version10.0 対応）と合わせてご利⽤いただくことを想定しており、学習の指針を⽰すものではありませんので、その点ご理解いただいた上でご活⽤いただければ幸いです。
よりよい内容にしていくため、皆様のコメント・フィードバックなど頂ければ幸いです。

今後必要とされる技術
IoT に代表されるような膨⼤なデータから価値を⽣むような現代において、クラウドを活⽤したシステム連携や主要技術のオープンソース化が進展しています。このような環境の中で活躍できるエンジニアになるためには、以下のような知識・技術を持つことが求められます。
１）クラウド活⽤技術
従来のオンプレミス環境のシステムにおいてもクラウド活⽤が進み、サーバー技術だ
けでなくクラウドの基本技術を⾝に付けている必要があります。
２）オープンソースへの理解
ソフトウェアを⾃社で新規に開発するというよりは、外部とコラボレーションしながらオープンソースで提供されている世の中の最新技術をいかに使いこなすかが重要になってきているため、オープンソースを利⽤する上での⼀般知識（リテラシー）を保有しておく必要があります。
３）システムアーキテクチャへの知⾒
システム環境の多様化により、コンピューター・アーキテクチャだけでなく、クラウドも含んだシステム全体のアーキテクチャへの知⾒が求められています。
⼀⽅で、クラウド技術が進展し使いやすくなってきたことに伴い、技術の本質を理解せず「操作しかできないエンジニア」が⽣まれて技術が空洞化するリスクもあり、問題が起きた際にも対処できるような優れたエンジニアになるためには、技術の本質を理解しておくことが重要になってきます。

2https://linuc.org/

LinuC レベル 1／レベル２ Version 10.0 の価値
Version10.0 の出題範囲は、SIer、エンドユーザー企業、組込みシステムを扱う企業などに所属するトップエンジニア、Linux 技術の教育関係者と書籍の執筆者など約 50 名の SME（Subject Matter Expert）に参加いただいた議論を通じて決められ、現在の開発の現場で本当に必要とされる技術スキルや知識を問う内容になりました。
また、クラウド／仮想化を⽀える技術的な基盤であり、オープンソースであるが故にコンピューターの仕組みを学ぶ上での最適な教材でもある「Linux」を学ぶことでコンピュー
ター・アーキテクチャを効率的に学べ、クラウド時代に必要な本質的な技術⼒を保有した
エンジニアであることの証明となります。

LinuC レベル 1／レベル２ Version 10.0 の出題範囲
従来の LinuC のバージョン（レベル１：Version4.0、レベル２：Version4.5）に対して、主に以下の項⽬が追加されています。
１） クラウドを⽀える技術領域へ拡⼤

レベル１

1.01.2：仮想マシン・コンテナの概念と利⽤
1.10.4：クラウドセキュリティの基礎

レベル２

2.04.6：システム構成ツール
2.05： 仮想化サーバー
2.06： コンテナ

２） オープンソースのリテラシーの理解を追加

レベル１

1.11：オープンソースの⽂化

３） システムアーキテクチャの要素を導⼊

レベル２

2.13：システムアーキテクチャ

3
https://linuc.org/

LinuC レベル 2 Version 10.0 の受験対象者
今までの LinuC は物理的なサーバーサイドの IT 技術を対象としていましたが、今回のVersion10.0 では、それに加えてクラウド時代に現場で必要な技術要素を取り⼊れ、シス
テム全体のアーキテクチャに対しても素養のあるエンジニアを育成・認定するものとなっています。Linux システムの構築・運⽤・保守に関わる IT エンジニアにとどまらず、クラウドシステムや各種アプリケーション開発に携わる IT エンジニアにとっても有効な認定になっています。

本教材の範囲
本教材は、LinuC レベル 2 Version 10.0 で新規に追加した以下の出題範囲に関する知識を習得するための補助教材の位置づけです。
2.04.6：システム構成ツール
2.05： 仮想化サーバー
2.06： コンテナ
2.13：システムアーキテクチャ

執筆者・校正者紹介
太⽥ 俊哉 (執筆、校正担当)

本資料の作成、校正を担当しました。クラウドや仮想化など、新しい技術要素が含まれるようになりましたが、これらの技術を使いこなす技術者をめざす⽅にお役に⽴てれば幸いです。
井上 博樹 (執筆担当)

ソースコードからのビルドとインストール, 監視ツール, システム構成ツール、仮想化サーバー、コンテナ、システムアーキテクチャについて執筆を担当しました。Git, Ansibleによる構成⾃動化、Zabbix による監視、KVM や Docker による仮想化など、システム管理者の負担を軽減する仕組みを紹介しています。みなさんのシステム構築・運⽤に役⽴てていただければ幸いです。

4https://linuc.org/

著作権
本教材の著作権は特定⾮営利活動法⼈エルピーアイジャパンに帰属します。
Copyright© LPI-Japan. All Rights Reserved.

使⽤に関する権利
本教材は、クリエイティブ・コモンズ・パブリック・ライセンスの「表⽰ - ⾮営利 - 改
変禁⽌ 4.0 国際 (CC BY-NC-ND 4.0)」でライセンスされています。

●表⽰

本教材は、特定⾮営利活動法⼈エルピーアイジャパンに著作権が帰属するものであることを表⽰してください。
●⾮営利

本教材は、⾮営利⽬的で教材として⾃由に利⽤することができます。商業上の利得や⾦銭的報酬を主な⽬的とした営利⽬的での利⽤は、特定⾮営利活動法⼈エルピーアイジャパン
による許諾が必要です。ただし、本教材を利⽤した教育において、本教材⾃体の対価を請求しない場合は、営利⽬的の教育であっても基本的に利⽤できます。その場合も含め、
LPI-Japan 事務局までお気軽にお問い合わせください。
※営利⽬的の利⽤とは以下のとおり規定しております。営利企業または⾮営利団体において、商業上の利得や⾦銭的報酬を⽬的に当教材の印刷実費以上の対価を受講者に請求して当教材の複製を⽤いた研修や講義を⾏うこと。
●改変禁⽌

本教材は、改変せず使⽤してください。ただし、引⽤等、著作権法上で認められている利⽤を妨げるものではありません。本教材に対する改変は、特定⾮営利活動法⼈エルピーア
イジャパンまたは特定⾮営利活動法⼈エルピーアイジャパンが認める団体により⾏われています。
本教材の使⽤に関するお問い合わせ先：
特定⾮営利活動法⼈エルピーアイジャパン（LPI-Japan）事務局〒100-0011 東京都千代⽥区内幸町 2-1-1 飯野ビルディング 9 階E-Mail：info@lpi.or.jp
5
https://linuc.org/

⽬次
出題範囲 新旧対照表（バージョン 10.0 vs バージョン 4.5） ...................................... 7201 試験出題範囲 新旧対照表 .................................................................................. 7
202 試験出題範囲 新旧対照表 .................................................................................. 8
新出題範囲 学習補助教材........................................................................................... 10
2.04.1 make によるソースコードからのビルドとインストール（Git 部分のみ） ... 10
2.04.5 死活監視、リソース監視、運⽤監視ツール ................................................. 15
2.04.6 システム構成ツール..................................................................................... 26
2.05.1 仮想マシンの仕組みと KVM......................................................................... 34
2.05.2 仮想マシンの作成と管理 .............................................................................. 41
2.06.1 コンテナの仕組み ......................................................................................... 48
2.06.2 Docker コンテナとコンテナイメージの管理 ................................................ 53
2.13.1 ⾼可⽤システムの実現⽅式 ........................................................................... 70
2.13.2 キャパシティプランニングとスケーラビリティの確保................................. 77
2.13.3 クラウドサービス上のシステム構成............................................................. 84
2.13.4 典型的なシステムアーキテクチャ ................................................................ 90
Appendix .................................................................................................................... 98
A.1 Zabbix の概要 ................................................................................................... 98
A.2 Pacemaker, Corosync のインストールと主な設定 ........................................... 115

6https://linuc.org/

出題範囲 新旧対照表（バージョン 10.0 vs バージョン 4.5）201 試験出題範囲 新旧対照表
バージョン 4.5

バージョン 10.0
出題範囲

v.4.5 の範囲

2.01：システムの起動と Linux カーネル

v.10.0 の範囲

出題範囲
202：システムの起動

2.01.1

ブートプロセスと GRUB

202.2
102.2

202.2

システムのリカバリ

2.01.2システム起動のカスタマイズ

202.1

202.1

システムの起動をカスタ
2.01.2
マイズする

202.3

その他のブートローダ

2.01.1【削除】

201：Linux カーネル
2.01.3

Linux カーネルの構成要素

201.1

201.1

カーネルの構成要素

2.01.4

Linux カーネルのコンパイル

201.2

201.2

Linux カーネルのコンパ
2.01.4イル

2.01.5

Linux カーネル実⾏時における
201.3
管理とトラブルシューティング

201.3

カーネル実⾏時における管理とトラブルシューテ 2.01.5
ィング

2.02：ファイルシステムとストレージ管理
2.02.1

2.02.2203：ファイルシステムとデバイス

ファイルシステムの設定とマウ
203.1
ント

ファイルシステムの管理

2.01.3

104.2
203.2
203.3

203.1

Linux ファイルシステム
2.02.1
を操作する

203.2

Linux ファイルシステム
2.02.2の保守

203.3

ファイルシステムを作成
してオプションを構成す 【削除】る204：⾼度なストレージ管理

2.02.3

論理ボリュームマネージャの設
204.3
定と管理

2.03：ネットワーク構成

204.1

RAID を構成する

【削除】

204.2

記憶装置へのアクセス⽅【削除】
法を調整する204.3

論理ボリュームマネージ
2.02.3
ャ

205：ネットワーク構成

2.03.1

基本的なネットワーク構成

205.1

205.1

基本的なネットワーク構
2.03.1成

2.03.2

⾼度なネットワーク構成

205.2

205.2

⾼度なネットワーク構成 2.03.2

2.03.3

ネットワークの問題解決

205.3

205.3

ネットワークの問題を解
2.03.3決する

7
https://linuc.org/

2.04：システムの保守と運⽤管理

206：システムの保守

2.04.1

make によるソースコードから 206.1のビルドとインストール【git 追加】

206.1

ソースからプログラムを
make してインストール 2.04.1
する

2.04.2

バックアップとリストア

206.2

206.2

バックアップ操作

2.04.3

ユーザーへの通知

206.3

206.3

システム関連の問題をユ
2.04.3ーザに通知する

2.04.2

200：キャパシティプランニング
2.04.4

リソース使⽤状況の把握

200.1

200.1

リソースの使⽤率の測定とトラブルシューティン 2.04.4
グ

2.04.5

運⽤管理ツールによる死活監
視とリソース監視

200.2
200.2
【⼤幅改定】

将来のリソース需要を予 2.04.5
測する
2.13.12.04.6

システム構成ツール【新設】

2.05：仮想化サーバー
2.05.1

仮想マシンの仕組みと KVM【新設】

2.05.2

仮想マシンの作成と管理【新設】

2.06：コンテナ
2.06.1コンテナの仕組み【新設】

2.06.2Docker コンテナとコンテナイ【新設】
メージの管理202 試験出題範囲 新旧対照表
バージョン 4.5

バージョン 10.0
出題範囲

v.4.5 の範囲

2.07：ネットワーククライアント管理

v.10.0 の範囲

出題範囲

210：ネットワーククライアントの管理

2.07.1

DHCP サーバーの設定と管理

210.1

210.1

DHCP の設定

2.07.12.07.2

PAM 認証

210.2

210.2

PAM 認証2.07.22.07.3

LDAP クライアントの利⽤⽅法

210.3

210.3

LDAP クライアントの利⽤
2.07.3
⽅法

2.07.4OpenLDAP サーバーの設定

210.4

210.4

OpenLDAP サーバの設定 2.07.4

2.08：ドメインネームサーバー

207：ドメインネームサーバ

2.08.1

BIND の設定と管理

207.1

207.1

DNS サーバの基本的な設定

2.08.12.08.2

ゾーン情報の管理

207.2

207.2

DNS ゾーンの作成と保守

2.08.22.08.3

セキュアな DNS サーバーの実現 207.3

207.3

DNS サーバを保護する

2.08.38https://linuc.org/

2.09：HTTP サーバーとプロキシサーバー

208：HTTP サービス

2.09.1Apache HTTP サーバーの設定と
208.1
管理

208.1

Apache の基本的な設定

2.09.1

2.09.2OpenSSL と HTTPS の設定

208.2

208.2

HTTPS 向けの Apache の設定

2.09.2

2.09.3nginx の設定と管理

208.4

208.4

Web サーバーおよびリバー
スプロキシとしての Nginx 2.09.3の実装

2.09.4

Squid の設定と管理

208.3

208.3

キャッシュプロキシとして
2.09.4の Squid の実装

2.10：電⼦メールサービス
2.10.1

2.10.2

Postfix の設定と管理

Dovecot の設定と管理

211：電⼦メールサービス
211.1

211.3

2.11：ファイル共有サービス

211.1

電⼦メールサーバの使⽤

211.2

電⼦メール配信を管理する 【削除】2.10.1

211.3

メールボックスアクセスを
2.10.2
管理する

209：ファイル共有

2.11.1

Samba の設定と管理

209.1

209.1

Samba サーバの設定

2.11.1

2.11.2

NFS サーバーの設定と管理

209.2

209.2

NFS サーバの設定

2.11.2

2.12：システムのセキュリティ

212：システムのセキュリティ

2.12.1

iptables などによるパケットフィ
ルタリング

212.1

212.1

ルータを構成する

2.12.12.12.2OpenSSH サーバーの設定と管理

212.3

212.3

セキュアシェル (SSH)

2.12.22.12.3

OpenVPN サーバーの設定と管理 212.5

212.5

OpenVPN

2.12.32.12.4セキュリティ業務

212.4

セキュリティ業務

2.12.4212.2

FTP サーバの保護

【削除】

212.4

2.13：システムアーキテクチャ
2.13.1

⾼可⽤システムの実現⽅式【新設】

2.13.2

キャパシティプランニングとスケ【新設】 200.2
ーラビリティの確保

2.13.3

クラウドサービス上のシステム構【新設】
成2.13.4

典型的なシステムアーキテクチャ 【新設】

将来のリソース需要を予測 2.09.5
する
2.13.29https://linuc.org/

新出題範囲 学習補助教材
2.04.1 make によるソースコードからのビルドとインストール
1. Git の概要
Git は Linux カーネルを開発しているリーナス・トーバルズ⽒が開発した分散型のバージョ
ン管理システムです。現在、多くのプロジェクトで採⽤され、バージョン管理やチームによる共同開発などで使⽤されています。
Git では、単⼀のリポジトリ（サーバー上の特定のフォルダ）を全員で共有するのではなく、
ユーザーごとにリポジトリのローカルコピー（ローカルリポジトリ）を作成し、すべての編
集・更新履歴を管理します。このため、ユーザーごとに、オフラインでもバージョン管理が可能です。
Git 以外のバージョン管理システムとしては CVS（Concurrent Versions System）や SVN（Subversion）などがあります。これらは単⼀のリポジトリを使⽤するところが Git と異なります。

10
https://linuc.org/

2. Git でできること
Git を使うと、以下のようなことができます。
lファイルの変更履歴の管理ができるl

変更履歴を参照してバージョンを過去のバージョンに戻すことができる

l

ソースコード以外のデータファイルも管理できる

lチームで変更履歴を共有し、衝突を防ぐことができる

そのためソフトウェア開発だけではなく、ドキュメントや Web デザインなどの分野でも使⽤されています。
全体的な操作の流れは以下のようなイメージになります。

リポジトリ複製

ファイル追加git clone

git add

ローカルに反リモートに反映

映

git commit

git push

3. 主要な Git コマンド
3.1 ローカルリポジトリの作成（git init）

Git を使⽤するにはリポジトリの作成が必要です。以下の git init コマンドを実⾏すると、ローカルホスト上に「.git」ディレクトリが追加されて、履歴などを管理するためのファイル群が作成されます。
＄ cd <リポジトリを新規に追加するディレクトリ＞＄ git init

3.2 リモートリポジトリのクローニング（git clone）
既存のリポジトリにあるプロジェクトをコピーして開発に参加したり、成果物を使⽤した
りするには、まずプロジェクトのリポジトリをコピー（クローニング）します。
＄

cd <リポジトリを新規に追加するディレクトリ＞＄ git clone リポジトリの URL

11https://linuc.org/

とすると指定した URL に存在するリポジトリ内のファイル群が、フォルダごとローカルマ
シン上のカレントディレクトリにコピーされます。
コピーしたローカルリポジトリ（フォルダ）内のファイルを更新したり、追加したりします。

3.3 変更履歴の保存・コメントの追加（git add, git commit, git tag）
編集を終えたら、＄ git add ファイル名＄ git commit -m “コメント"
としてローカルリポジトリに変更履歴を反映します。
また、$ git tag ＜タグ名＞とすると直前のコミットに対してわかりやすい別名をつけることができます。例えば、ソフ
トウェアの場合だと、アルファ版、ベータ版、リリース候補（Release Candidate）、公開版（General Availability）、Stable（安定版）、あるいはバージョン番号などのタグをつけておくと、他のチームメンバーがバージョン情報やステータスをチェックしやすくなるでしょう。

3.4 公開リポジトリに変更を送信する（git push）
commit した変更をリモートリポジトリに反映するには push コマンドを使⽤します。

$ git push 反映先（リモートリポジトリ） ブランチ

リポジトリには、バージョン管理のためにブランチとリビジョンという仕組みがあります。
ブランチはメインのリポジトリから分岐（フォーク）したもので重複しない名前をつけます。
ブランチ内ではさらにリビジョンをつけて、ブランチ内でのバージョン管理を⾏います。
ブランチ名を指定することで、リモートリポジトリ上のブランチを切り替えてクローニン
グ（複製）することが可能です。

12
https://linuc.org/

リビジョンリビジョン

3.5 ブランチを切り替える（git checkout）$ git checkout <ブランチ名＞

3.6 タグで絞り込んで表⽰する（例えばタグに v1.9.5 を含むものだけを表⽰）$ git tag -l “v1.9.5*”
オプションをつけないと、すべてのタグが表⽰されます。

13
https://linuc.org/

4. リモートリポジトリからのクローニングとソースコードのビルド
それでは、実際にリポジトリをクローニング（複製）して、ソフトウェアをビルドしてみま
しょう。ここでは、コンピュータービジョンのソフトウェアで有名な darknet のビルドにトライします。
$ git clone https://github.com/pjreddie/darknet.git$ cd darknet

リポジトリのブランチを指定しないと、デフォルトでは master ブランチ（最新安定版）が選択されます。もしも、リリースブランチを指定してダウンロードしたい場合には、checkout
コマンドを使います。

$ git checkout ＜ブランチ名＞# r1.10 など

リポジトリをクローニングしたら、ローカルリポジトリのディレクトリに移動して make コ
マンドを実⾏します。
$ cd darknet$ make

無事にコンパイルが完了したら$ ./darknet

としてコマンドを実⾏してみましょう。
usage: ./darknet <function>とコマンドの使⽤⽅法（usage）が表⽰されたら、ビルドに成功しています。

14https://linuc.org/

2.04.5 死活監視、リソース監視、運⽤監視ツール
現在、Web サイトや SNS、サーバーと連携するスマホアプリなどインターネット上で提供されるサービスや、企業内のファイルサーバー、メールサーバー、グループウェアなどのシ
ステムは、24 時間 365 ⽇いつでも問題なく使⽤できることが当然だと考えられています。
しかし、問題なくシステムを連続稼働させることは当然ではありません。それなりの対策が必要です。例えば、ハードウェア、ネットワーク、OS など、システムを構成するさまざまな要素で障害が発⽣する可能性があるため、何らかの障害が発⽣してもシステム全体を停⽌せずに運⽤を継続させる仕組みが必要となります。
そのため、障害発⽣時のシステムやデータ復旧、サービス再稼働までの時間を短縮し、サービスのダウンタイムをできるだけ短くしてユーザーの利便性を損なわないためには、シス
テムやサーバーを的確に監視してサービスが停⽌しないよう、障害をできるだけ早期に検知して対応することが重要です。

1. システム障害と予兆システムの障害を引き起こす原因には以下のようなものが考えられます。

1.1 リソースの枯渇
メモリ消費量が実メモリ容量を超えてスワップ領域へのアクセスが多発すると、OS のパフォーマンスが⼤幅に落ちます。
また、ディスク容量を使い果たしてしまうと、それ以上データを書き込んだりできなくなるためにシステムが停⽌してしまうトラブルが発⽣します。

1.2 過負荷
アプリケーションの処理などで CPU 使⽤率が 100%に達するとシステムが応答しなくなったり、アプリケーションの処理が遅延/停⽌して、ブラウザーやアプリへの応答がなくなり、処理結果が表⽰されない、などのトラブルを引き起こします。

1.3 異常停⽌
システム上のどこかで障害が発⽣した結果、システムやサービスが停⽌する場合があります。

1.4 結果異常
サービスが返す処理結果が異常な値を⽰していたり、データの破損により、システム障害が発⽣する可能性があります。

15
https://linuc.org/

1.5 OOMKiller
Linux はメモリが不⾜（Out-Of-Memory：OOM と略す）してシステム停⽌が発⽣してしまう状況になると、メモリリソースを⼤量に消費しているプロセスを強制終了（kill）
します。
停⽌処理をしていないプロセスが存在していない場合は、OS によって強制終了された可能性があります。Centos では、/var/log/messages、Ubuntu なら/var/log/syslog の各 OS のシ
ステムログに、強制終了した情報が記録されます。
強制終了される可能性があるプロセスは、dstat コマンドの top-oom オプションで確認できます。dstat コマンドは、/proc/PID/oom_score を参照して結果を表⽰します。
$ dstat --top-oom--out-of-memory--kill score
sshd

594

sshd

594

強制終了させるプロセスの優先度を設定しておくこともできます。
/proc/PID/oom_adj に、-16 から+15 までの優先度を設定することができます。
-17 を設定すると強制終了の対象リストから外されます。

2. 死活監視の対象と⼿法
死活監視の対象としては、
l

サーバー

l

ネットワーク機器

lサーバー上の特定のサービスなどがあります。
システムに対しての死活監視は、例えばサーバーのネットワークインターフェースに対して疎通確認を⾏い、応答（レスポンス）が返ってくるかどうかを確認します。
疎通確認が取れない場合には、サーバーが何らかの原因で停⽌しているか、ネットワークイ
ンターフェースに障害が発⽣しているなどのケースが考えられます。

16
https://linuc.org/

また、各種サービスの死活監視については、Web サーバー、アプリケーションサーバー、
メールサーバー、ファイルサーバーなどのプロセスが起動しているかを確認します。プロセスが起動していないとサービスが提供されません。また、CPU やメモリ、ディスクなどが不⾜するとサービスの提供に影響が出るので、次のリソース監視もあわせて実⾏します。

3. リソース監視の対象と⼿法
リソース監視の対象には、
lログ（サーバー、サービス、プロセス、ネットワーク）l

使⽤率（CPU、メモリ、ストレージ、通信量）などがあります。

3.1 ログの監視サーバーやネットワーク機器などのログファイルを tail コマンドなどを⽤いてコンソール
上でリアルタイムに表⽰して確認することもできますが、ログ監視ツールや統合監視ツー
ルなどを⽤いる⽅が管理者の負担が軽減できます。
ログ監視ツールを⽤いると、指定したディレクトリに保存されているログファイルをリア
ルタイムに監視して、特定のパターンにマッチしたら、メールでの通知を送信したり、スク
リプトを実⾏することができます。
監視する対象としては、以下のようなログがあります。
lサーバーのシステムログlサービスごとのログファイル
例えば、httpd や nginx のログファイルにはサービスの起動、停⽌、エラーのログが記録されます。

l

プロセスやネットワークの監視ログ
監視ツールから、定期的にプロセスの起動をチェックしたり、ネットワークの疎通確認を⾏った記録がログファイルに記録されます。

3.2 SNMP によるリソース監視
サーバーやネットワーク機器を監視するには、SNMP（Simple Network Management
Protocol）を⽤いたリソース監視も使われます。これは、IP アドレスが設定されているさま
ざまなデバイスから情報を取得し、動作の状況や、障害の状況など、デバイスの状態を監視するための仕組みです。

17
https://linuc.org/

監視対象としては、lCPU、メモリ、ネットワークインターフェース、サーバー筐体の温度などの状態

l

HDD、電源、ファンなどのハードウェアの稼働状況

lネットワークの稼働状況（L2 ループ、マルチキャストやブロードキャストパケットの多重ループ、が発⽣していないか）などがあります。
また、監視には、l SNMP マネージャから SNMP エージェントへのポーリング（定期的なリクエスト送信）l SNMP エージェントから SNMP マネージャへの通知の２タイプの仕組みがあります。
例えば、オープンソースの監視ツールである Nagios には SNMP マネージャの機能が内蔵されています。そして、監視対象のサーバーやデバイスでは SNMP エージェントのプロセスが動作しています。SNMP マネージャは、SNMP エージェントに対して⼀定間隔（例えば 3 分おき）にリクエストの送信と、エージェントからのレスポンス受信を⾏います。
SNMP エージェントは、多くのルーターやスイッチなどのネットワークデバイスには組み込まれていることが多く、設定をすることで利⽤が可能になります。
Linux では、net-snmp パッケージにエージェントが含まれています。パッケージをインストールし、設定を⾏うことで利⽤が可能になります。
Windows マシン1 では「SNMP Service」を追加・設定して起動すれば SNMP エージェントが使えるようになります。
アプリと機能の追加の設定メニューから「簡易ネットワーク管理プロトコル（SNMP）」を選択して、インストールを実⾏すると、サービスの⼀覧に表⽰されます。

1

Windows 10 Pro version 1903 で確認
18
https://linuc.org/

SNMP エージェントの追加

SNMP サービスの起動・停⽌画⾯

19
https://linuc.org/

4. 運⽤監視ツールによる監視作業の標準化と⾃動化
サービスやデバイスごとに監視スクリプトを開発・実⾏し、ログ監視やリソース監視を⼿動で⾏うことはシステム規模が⼤きくなると負担が⼤きく、現実的ではありません。
そこで、監視ツールによる監視作業の標準化や⾃動化が重要になります。
例えば、オープンソースの監視ツールである Zabbix には以下のような監視、障害検知機能が搭載されています。
l ネットワーク上のノード監視
ICMP（ping）による死活監視
l リソース監視CPU、メモリ、ディスク使⽤率
l ネットワークデバイス監視
監視ツールのエージェントプロセスや SNMP エージェントによる監視
l プロセス監視
ホスト上で動作しているプロセスの監視
l ポート監視指定したポートを通じた通信が可能かどうかの監視
l サービス監視HTTP, FTP, SMTP, POP, IMAP, LDAP, SSH, NNTP, NTP などのサービスの動作監視
l ログ監視ログファイル中に指定した⽂字列パターンが含まれないかを監視
l Windows 監視
Windows ⽤エージェントを使⽤すると Windows のサービス起動状況やイベントログを監視できます。複数のエージェント対応、ソフトウェアのインストール・アンインストール、アプリケーションの起動・停⽌など Windows 版固有の機能が搭載されています。
また、それぞれの項⽬についてしきい値を設定し、E メールなどによるアラート通知⽅式を設定することが可能です。

4.1 監視⽅式の⾃動化や RBA によるパッケージ化
さらに、単⼀のノードの監視だけでなく、複数台のノードをまとめて監視したり、複数の処理を⾃動的に実⾏したりする⾃動化機能が備わっている監視ツールもあります。
こうした⾃動化機能は、RBA（Run Book Automation）と呼ばれ、問題や障害を検出した際にあらかじめ定義しておいた作業を⾃動的に実⾏することができるようになります。
20
https://linuc.org/

4.2 監視業務の標準化の重要性
システム監視業務プロセスの改善にあたっては、既存の監視業務プロセスが効率的に⾏われているかどうかをチェックするところからスタートするとよいでしょう。
監視作業の⾃動化以前に、まず監視業務プロセス全体の⾒直しと標準化を⾏う必要があります。無駄な作業はないか、より効率を向上できないかなどをチェックしてから、監視プロ
セスの標準化を進めることが重要です。プロセスが標準化されれば、監視対象が増えても担当者の負担を軽減したり、作業ミスや運⽤の負担やコストを軽減したりすることにつながるでしょう。
標準化を進めることで監視ツールを統⼀したり、RBA による⾃動化を適⽤したりしやすくなります。その結果、全体最適化を進めることが可能となるでしょう。

5. 主要な監視ツール
5.1

Icinga2

Icinga2 は、Nagios(後述)から派⽣（フォーク）して開発されたオープンソースの監視ツールです。Icinga2 を⽤いると Web インターフェース、もしくはコマンドラインインターフェースから監視設定を⾏うことができます。
標準的な監視機能（システムやリソースの監視、通知）に加えて、監視結果の可視化(動的なグラフ⽣成)や、分散構成への対応などの特徴があります。

5.2

Nagios

Nagios もオープンソースの監視ツールの⼀つです。ネットワークサービスの監視、リソース監視、アラート機能など標準的な機能を備えています。基本的な設定は Web インタ
ーフェースから⾏います。
Nagios はプラグインをユーザーが開発・追加できる点が特徴的です。Bash, C++, Perl,
Ruby, Python, PHP, C#などで、監視したい対象についてプラグインを開発して使⽤することができます。
現在は、機能を強化した商⽤版と、オープンソース版が存在しています。新機能は商⽤版に主に追加されるため、Icinga のように分岐して新機能の開発を独⾃に進めるプロジ
ェクトも出てきています。

5.3

collectd（https://collectd.org/）collectd は、システムやアプリケーションのパフォーマンス情報を収集するオープンソースの監視ツールです。collectd は、100 個以上の豊富なプラグインを使⽤して、システ
21
https://linuc.org/

ムやリソースの監視を⾏えます。収集したデータは、RRD というフォーマットで保存されます。
collectd は C ⾔語で書かれているため、パフォーマンスが⾼く、実⾏ファイルのサイズが⼩さいのが⼤きな特徴です。そのため、⼀般的なサーバー以外にも組込み系システム
やルーターなどにも搭載可能です。
⼀⽅で、グラフ⽣成機能は含まないため可視化ツールを併⽤する必要がある、モニタリ
ング機能が限定的である、という短所もあります。

collectd が収集したデータを可視化した例2

5.4

MRTG

MRTG は、「Multi Router Traffic Grapher」の略で、ルータなどネットワークデバイス
が送受信したデータトラフィック量を可視化するために使⽤されるオープンソースの監視ツールです。
MRTG は Perl ⾔語で書かれていて、取得した情報を HTML 形式で出⼒可能なため、Web サーバーと連携して結果を表⽰させることができます。
もともとはルーターを監視対象として開発されましたが、現在は SNMP マネージャとして動作させることが可能で、SNMP エージェントと連携してサーバーやネットワークデ
バイスの監視が可能となっています。SNMP に対応しているため、ネットワークトラフ

2

https://collectd.org/
22
https://linuc.org/

ィックだけでなく、サーバーのリソース状況（CPU、メモリ、ディスクなどの使⽤率）なども監視することが可能です。
⽋点としては、⼆つの系列データの可視化までしかできないなど、可視化機能が弱い点が挙げられます。

MRTG で送受信のデータトラフィックを可視化した例3

5.5

Cacti

Cacti は、オープンソースの監視ツールの⼀つで SNMP マネージャとして機能することが可能です。
Cacti は collectd や MRTG が採⽤している RRD フォーマットのデータを扱うことができるだけでなく、SNMP 対応や Web インターフェースによる設定の容易さなどが特徴です。
CentOS では、EPEL リポジトリを追加すると yum コマンドでインストールすることが可能です。net-snmp, net-snmp-utils の⼆つのパッケージをインストールすると、/etc/snmp/snmpd.conf で設定を⾏うことができるようになります。

Cacti で⽣成したグラフ（ルーターのトラフィック）43

https://oss.oetiker.ch/mrtg/

4

https://docs.cacti.net/manual:100:2_basics.1_first_graph#creating_the_graphs

23
https://linuc.org/

5.6

ZabbixZabbix は現在⾮常に⼈気のあるオープンソースの監視ツールの⼀つです。バックエンド
は C ⾔語で書かれています。Web インターフェースは PHP ⾔語で書かれています。
２０２０年４⽉現在、最新安定版は 4.4.1、LTS（⻑期サポート版）は 4.0LTS です。
Zabbix はデータベースに収集した情報を格納するため、MySQL や PostgreSQL などのリレーショナルデータベースと連携して動作します。
Zabbix では、l

ICMP(ping)、SMTP、HTTP などによるサービスの稼働状況の確認lZabbix エージェントを監視対象にインストールして、ホストのリソース監視（CPU、メモリ、ディスクなどの使⽤率）の監視などの、複数の監視⽅法に対応しています。エージェントをインストールしなくても多数のホストやデバイスの監視に対応しているところが特徴的です。
Zabbix の詳細については、Appendix で取り上げますが、以下のようなダッシュボード
機能を提供し、監視対象を⼀覧表⽰することができます。

Zabbix のダッシュボード5

5

https://www.zabbix.com/documentation/4.0/manual/web_interface/frontend_sections/monitoring/dashboard

24
https://linuc.org/

また、各ターゲットの詳細情報はウィジェットという四⾓形の領域に表⽰されます。例えば、以下は CPU 使⽤率の監視結果を可視化したグラフです。

Zabbix で CPU 使⽤率の推移を可視化したグラフの例66

https://www.zabbix.com/documentation/4.0/manual/web_interface/frontend_sections/monitoring/graphs

25
https://linuc.org/

2.04.6 システム構成ツール
1. システム構成ツールの必要性と導⼊メリット
IT システムを構築するにあたり、サーバーへの OS インストール、ルーターなどネットワ
ーク機器の設定が、インフラ構築作業では必要です。
しかし近年ではさらにシステムの⼤規模化やクラウド化が進んだり、マイクロサービスア
ーキテクチャによる処理の分散化が進⾏したりしてきました。その中で、アプリケーションのコンテナ化や、DevOps の進化により、アプリケーションの開発からデプロイ（本番環境への配置）が⾼速になり、短期間にアプリケーションがリリースされるようになってきました。
管理すべきサーバーやアプリケーション、コンテナなどの数が増⼤し、さらに開発から運⽤までの期間も短縮されたことで、以前のように⼿作業で 1 台ずつ設定作業をしていては、サービスの提供や運⽤管理が間に合わなくなったり、⼈的エラーが発⽣したりしてしまう
リスクが出てきました。
こうしたニーズやリスク低減に対応するために各種設定作業もコード化しておいて、作業を⾃動化しようという取り組みが⾏われるようになります。こうした作業のコード化を、Infrastructure as Code（IaC）と呼んでいます。
作業を⾃動化することで、
lサーバー設定などのプロビジョニング作業を標準化できるlより効率よく、ミスなく作業ができるl

台数が多くなっても短時間で作業が可能になるl

同じ設定を間違えずに⾏えるなどのメリットが⽣まれます。
◎

冪等性（べきとうせい）

設定作業を何度も実⾏しても同じ結果が得られる特徴のことを「冪等性（べきとうせい）、
idempotency」と呼びます。
構成管理ツールには、正規表現によるパターンマッチングを⾏い無駄な設定を追加しないようにする機能や、設定は⾏わずテストを⾏う dry run 機能などがあり、誤った設定や余分な設定を⾏わないような⼯夫がされています。

26
https://linuc.org/

冪等性が確保されることで、システムが⼤きくスケールした際にも、設定ミスを回避したり、作業負荷を軽減することが可能になります。

2. Ansible の概要
作業の⾃動化を実⾏するには、構成管理ツールを使⽤します。
構成管理ツールには、いろいろなソフトウェアが存在します。Puppet, Chef, Salt, Ansible な
どが広く使⽤されています。
このうち、Puppet や Chef などは管理対象となるマシンにエージェントと呼ばれるクライ
アントソフトウェアをインストールし常時稼働させておく必要があります。それに対し、
Ansible では（Linux を含む Unix 系 OS の場合） SSH 接続が可能であれば、管理対象のマ
シンにエージェントを常駐させておく必要がないため、エージェントレスな構成管理ツー
ルと呼ばれています。
Ansible はオープンソースで開発・公開が進められている構成管理ツールで、Python ⾔語で記述されています。
YAML という所定のフォーマットで記述された⼆つの設定ファイル（構成を定義したテキストファイル）に従って、サーバーやネットワークデバイスなどの設定を⾃動的に実⾏できます。
Ansible の動作環境は以下のようになっています。
l

設定ターゲットを定義するインベントリファイル（Inventory file）

l

設定作業を記述するプレイブック（Playbook）

l

処理の最⼩単位（Module）

Ansible のコマンドを実⾏すると、インベントリファイルに定義したホストに Playbook がPython スクリプトに変換されます。そして、変換されたスクリプトと、処理を実⾏するための Module がターゲットのホストに転送され、転送先のホストで Playbook の記述にしたがって、各種処理や設定が実⾏されます。

27
https://linuc.org/

Ansible の動作イメージ
さらに構成管理だけでなく、アプリケーションの配置（デプロイ）や、コンテナの構成などにも対応するようになってきています。

3. ローカル環境への Ansible のインストールと対象ホストの設定
Ansible を CentOS7 にインストールするには、まず EPEL リポジトリを追加します。これは Ansible が CentOS の公式リポジトリに含まれていないためです。
# yum install epel-release

リポジトリを追加したら、yum コマンドで ansible をインストールします。
# yum install ansible

28
https://linuc.org/

すると、/etc/ansible/ansible.cfg に設定ファイルが⽣成されます。そして、Ansible を実⾏するホストを定義するには、この設定ファイルで inventory の定義⾏の先頭の＃を削除して有効化します。

inventory = /etc/ansible/hosts # 先頭のシャープを取ります。

続いて、/etc/ansible/hosts に、Ansible で設定を⾏うホストの情報を記述します。

[www1]
192.168.1.10

複数台を指定するには 1 ⾏に⼀つのホストの情報を⼊⼒します。

4. Ansible Playbook の設定と実⾏
YAML は各⾏に、「キー： 値」というフォーマットで設定を記述していきます。
例えば、Ansible で構成を⾏うホストに httpd をインストールするには、playbook.yml に以下の記述を⾏います。

- hosts: www1
remote_user: roottasks:- name: yum installyum: name=httpd

設定する先（hosts）と Playbook ファイルを記述したら、以下のように ansible-playbook コ
マンドを実⾏して設定作業を実⾏します。
$ ansible-playbook -i inventory playbook.yml

設定するターゲットの root ユーザーの ssh ログインのパスワードを求められるので⼊⼒すると Playbook から⾃動⽣成された Python スクリプトが転送され、実⾏されます。
29
https://linuc.org/

このようにして、設定対象となるホストと、設定処理の⼿順をあらかじめ記述しておくこと
で、各種設定を⾃動的に実⾏することができます。

5. システムの構成変更の⾃動化
Ansible などの構成管理ツールを⽤いると、既存のサーバーの設定変更だけでなく、コンテナの管理や設定変更などにも対応できます。

5.1 仮想サーバー・コンテナの払い出し
Ansible は、Docker コンテナのイメージの作成、Kubernetes への展開などが可能になります。例えば、ansible-bender や Ansible Operator などがあります。
コンテナの作成、起動だけであれば Docker Composer でも実現できますが、上記のようなツールを⽤いると、あらかじめ記述しておいた Playbook にしたがって設定作業も実⾏することができるのが利点です。
他にも、以下のような操作を実⾏できます。
l

既存イメージ、またはスクラッチからコンテナを⽣成する

l

既存コンテナまたは Dockerfile からイメージを⽣成する

l

コンテナの root ディレクトリをマウント・アンマウントして操作できるようにする

lコンテナやイメージを削除する

lローカルコンテナをリネームする（別名をつける）

5.2 アプリケーションのリリース
構成管理ツールを⽤いると、仮想マシンの⽣成だけでなく、アプリケーションを配布した
り、もしくはアプリケーションを含むコンテナイメージからコンテナを⽣成し、アプリケ
ーションを提供したりすることができます。
Ansible を⽤いる場合は、Playbook に記述した⼿順で、l

既存のサーバーにアプリケーションを配布して実⾏する

l

新たに仮想マシンを⽣成や起動し、アプリケーションの配置や設定ファイルの読み込みなどを⾏うl

アプリケーションを内包しているコンテナからイメージを⽣成して実⾏するなどの⼿順でアプリケーションを配布、リリースできます。

30
https://linuc.org/

5.3 ネットワーク機器のステータス取得・設定変更
Ansible などの構成管理ツールはネットワーク機器の設定や、ステータス取得などにも対応しています。
各デバイスに対応した管理機能は、Ansible Network Module と呼ばれ、Ansible 最新版（執筆時点では 2.9）には数百ものネットワークモジュールが⽤意されています。
⽇本でもよく知られているデバイスには、以下のようなネットワークモジュールが提供されています。
l

A10（ロードバランサ）lAruba（アクセスポイント）l

F5（ロードバランサ） BigIP などの製品

lFortios（ファイアウォール） FortiGatel

Ios（Cisco 製品、各種スイッチやルーター）lJunos（Juniper 製ネットワークデバイス）

ネットワークモジュール⼀覧（Ansible の公式ドキュメントより）https://docs.ansible.com/ansible/latest/modules/list_of_network_modules.html
そして、Playbook に記述する設定には、
l config （設定）l command（実⾏する設定コマンド）l facts （収集された設定情報）
31
https://linuc.org/

などがあります。

5.4 ネットワーク機器の情報を参照する例
Ansible の hosts ファイルでは⼀つのネットワークデバイスを定義します。
[router]
10.0.10.110

次は Playbook を作成します。以下の例では、ルーターのバージョン情報を取得し、テキス
トファイルに出⼒しています。ファイル名を「show_ver.yml」としています。

- hosts: routergather_facts: notasks:- name: sh ver
raw : "show ver"register: show_ver- name: sh ver output
local_action:

shell/bin/echo"{{

show_ver.stdout}}">/home/cisco/ansible/shver_{{ inventory_hostname }}.txt

ホスト情報と Playbook の作成を終えたら、ansible-playbook コマンドを実⾏します。
$ ansible-playbook -i hosts show-ver.yml --ask-pass
PLAY [router] *********************************TASK: [sh ver] ***********************************************
ok: [10.0.10.110]
TASK: [sh ver output] ****************************************
changed: [10.0.10.110 -> 127.0.0.1]
PLAY RECAP ********************************************
10.0.10.110: ok=2changed=1

unreachable=0

failed=032
https://linuc.org/

shver_10.0.10.110.txt のファイルの内容を確認すると、以下のようにルーターの OS のバー
ジョンを確認できます。以上のようにしてサーバーだけでなく、ネットワーク機器の情報を取得したり、設定を実⾏することができます。
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Experimental
Version 15.4(20140730:011659) [lucylee-pi25-2 107]33
https://linuc.org/

2.05.1 仮想マシンの仕組みと KVM
1. 仮想化の概要と⼆つの⽅式（ホスト型とハイパーバイザー型）
仮想化とは、コンピューターやその他種々の物理的なリソースを抽象化し、ソフトウェア化する技術のことです。コンピューターの場合、単⼀のハードウェア上で、複数の、ソフトウ
ェア化されたコンピューターを動作させます。この、ソフトウェア化されたコンピューターのことを「仮想マシン（Virtual Machine）」と呼びます。
コンピューターに対して仮想化技術を使⽤すると、⼀つのハードウェア上で複数の異なる
オペレーティングシステム（以下、OS）を動作させ、物理サーバー台数の節約をしたり、⽤途ごとのサーバーを⾼速に構築して提供したり、柔軟に構成を変更してスケールアップ
やスケールアウトに対応できるなどの利点があります。また、近年普及が拡⼤しているパブリッククラウドを実現する基盤技術としても使⽤されています。
コンピューターに対する仮想化⽅式は、ホスト型とハイパーバイザー型があります。
◎

ホスト型

ハードウェアにインストールした OS（「ホストＯＳ」と呼びます）上に仮想化ソフトウェ
アをインストールし、その上で（複数の）仮想マシンをインストールして動作させる⽅式です。ホスト型の仮想化ツールでは、VirtualBox や VMware Player などがよく知られています。

ホスト型の構成イメージ

34
https://linuc.org/

◎ハイパーバイザー型

コンピューター上にハイパーバイザーと呼ばれる仮想化管理ツールを介して、直接 OS をインストールして動作させる⽅式です。直接ハードディスク上にインストールするため、ホスト型に⽐べて⾼速に動作する、ホストＯＳの制約のためにゲストＯＳを調整する負担がな
い、などが利点です。ハイパーバイザー型の仮想化ツールとしては VMware ESXi や HyperV, KVM などがよく知られています。

ハイパーバイザー型の構成イメージ

2. KVMKVM は、Kernel-based Virtual Machine の略で、Linux カーネルの拡張モジュールとして動作します。
CPU ごとにモジュールが開発されていてl

kvm-intel（Intel 社製 CPU ⽤）l

kvm-amd（AMD 社製 CPU ⽤）の⼆種類のカーネルモジュールが提供されています。

35
https://linuc.org/

CPU が仮想化⽀援機能に対応しているかどうかは、/proc/cpuinfo や lscpu コマンドで確認します。
$ ls /proc/cpuinfo

そして、Intel 製 CPU の場合には「vmx」
AMD 製 CPU の場合には「svm」があることを確認します。
もし含まれていない場合は仮想化ツールを実⾏することができません。Intel 製なら Core i3
以降の CPU なら仮想化機能（VT-x）に対応しています。ただし、出荷時の設定で無効化されている場合があります。その場合は、電源投⼊直後に BIOS や UEFI の設定メニューを起動して、仮想化機能を有効化（Enable）にする必要があります。
KVM モジュールは Linux カーネル上で動作するため、上記の分類のハイパーバイザー型のように動作します。そのため、ゲストＯＳ側でホスト OS の制限を受けにくく、Linux の拡張機能などを使えます。

KVM の構成イメージ

36
https://linuc.org/

◎ 完全仮想化と準仮想化
仮想化を実⾏する上では、以下の⼆つの仮想化⽅式があります。
l BIOS レベルからハードウェア全体を仮想化し、ディスク I/O などをすべてエミュレートして、OS に⼿を⼊れないで仮想マシンを構成する「完全仮想化」
l ゲスト OS にハイパーバイザーとの連携の仕組みを取り⼊れる「準仮想化」
準仮想化は完全仮想化よりも⾼パフォーマンスを期待できますが、ハイパーバイザーへの依存性が⾼まるため、ハイパーバイザー間の移植性は低くなります。
KVM では virtio という準仮想化ドライバパッケージを⽤いることで、より⾼速なディスク
I/O や⾼スループット、CPU 処理のオーバヘッドの減少を実現します。

3. KVM を⾼速動作させるための QEMUQEMU は、ゲスト OS からの⼊出⼒ I/O(ディスク、ネットワーク)を仮想化する機能を提供するエミュレータです。KVM がメモリや仮想ＣＰＵを、ＱＥＭＵがディスクやネットワ
ークインターフェースなどの仮想ハードウェアを提供します。処理をそれぞれ分担することでパフォーマンスの向上を図っています。

KVM と QEMU の動作イメージ

37
https://linuc.org/

4. KVM の導⼊と設定
KVM の導⼊・仮想マシンの追加は以下のようなステップで⾏います。
（１） ホストＯＳに KVM（カーネルモジュール）や QEMU をインストールする（２） ブリッジインターフェースを設定する（３） 仮想マシンを追加する
それでは順に実⾏していきましょう。ここでは CentOS 7 を使います。

4.1 必要なパッケージのインストール
以下のパッケージを yum コマンドでインストールします。
l yum のモジュール機能を使⽤して仮想環境パッケージ（virt）
l 仮想マシンのＯＳインストールツール（virt-install）
l ブラウザーインターフェースから仮想マシン(VM)を管理するツール（cockpit,
cockpit-machines）# yum -y module install virt
# yum -y install virt-install cockpit cockpit-machines

4.2 仮想化サポート機能の確認# virt-host-validateを実⾏して仮想化サポート機能の確認を⾏いましょう。

4.3 仮想化をサポートする libvirtd サービスの⾃動起動を有効化・起動# systemctl enable --now libvirtd

続いてはブラウザーインターフェースを提供する cockpit ソケットの⾃動起動を有効化し、起動しましょう。
# systemctl enable --now cockpit.socket

4.4 インストール⽤ ISO イメージの⽤意
インストールしたい OS のイメージをダウンロードしておきます。今回の例では、
38
https://linuc.org/

Ubuntu18.04LTS を使⽤します。

4.5 仮想マシンを追加する準備（ネットワークの設定）
KVM をインストールすると、デフォルトでは virbr0（仮想のブリッジインターフェース）と仮想ネットワーク（default） が設定されています。default は、ルーターとして機能し、DHCP サーバー機能を提供します。それぞれ設定を確認しておきましょう。
まずはインターフェースの確認をしてみましょう。
$ nmcli con | grep bridge
virbr0dfeb02ec-554a-473e-b416-71334d164cbd bridge

virbr0

次に仮想ネットワークの確認を⾏いましょう。
$ virsh net-list
名前状態

⾃動起動 永続---------------------------------------------------------default

動作中 はい (yes) はい (yes)

4.6 ブリッジインターフェースを追加
上記の NAT 接続ですと外部への接続はできますが、外部からの（インバウンド）接続ができません。そこでブリッジインターフェースを追加して、外部から接続できるようにしましょう。KVM には下記の Network Manager を使⽤する以外に、ブリッジ設定を⾏うブリッ
ジユーティリティー（bridge-utils）も⽤意されています。
$ nmcli con add type bridge con-name br0 ifname br0$ nmcli con mod br0 bridge.stp no$ nmcli con mod br0 ipv4.method manual ipv4.addresses “192.168.1.5/24”
ipv4.gateway “192.168.1.1” ipv4.dns 192.168.1.1 （アドレスは各⾃の LAN に合わせる）# nmcli con mod br0 autoconnect yes

追加したら、もう⼀度インターフェースを確認してみましょう。
$ nmcli con | grep bridgebr0

bde3f90a-58ba-4d69-8992-5ba493f5d604 bridge

br0

virbr0dfeb02ec-554a-473e-b416-71334d164cbd bridge

virbr039
https://linuc.org/

次に br0 の接続先として、イーサネットインターフェース（enp0s3 など、マシン上で確認しましょう）を追加します。

$ nmcli con add type bridge-slave ifname enp0s3 master br0

ブリッジインターフェースを有効化します。
$ nmcli con up br0
接続が正常にアクティベートされました (master waiting for slaves) (D-Bus ア
クティブパス: /org/freedesktop/NetworkManager/ActiveConnection/7)

ブリッジ接続を確認したら、enp0s3 の接続設定を削除しましょう。
$ nmcli con del enp0s3

40
https://linuc.org/

2.05.2 仮想マシンの作成と管理
続いては、仮想マシンの追加や OS のインストールを実⾏していきます。以下のように virtinstall コマンドで仮想マシンの追加が⾏えます。例えば、以下では、64bit CPU、2 コア、メモリ（RAM）1GB、ディスク 20GB の Ubuntu 18 の仮想マシンを作成しています。
$ VM_NAME="ubuntu18"$ virt-install ¥--name ${VM_NAME} ¥--hvm ¥--arch x86_64 ¥--os-type linux ¥--os-variant OS 種類 ¥--vcpus 2 ¥--ram 1024 ¥--diskpath=/var/lib/libvirt/images/${VM_NAME}.img,format=qcow2,size=20 ¥--network bridge=br0 ¥--graphics vnc,keymap=ja ¥--noautoconsole ¥--location ISO イメージファイルのパス

OS の種類に指定できるオプションは、osinfo-query コマンドで確認できます。まずはこのコマンドを実⾏して使⽤可能なバージョンを確認してから、ISO イメージをダウンロード
してもいいでしょう。
$ osinfo-query os

virt-install コマンドを実⾏したら、virsh コマンドで仮想マシンが表⽰されることを確認しましょう。
$ virsh list

続いては、仮想マシンとブリッジインターフェースの接続を確認しましょう。

41
https://linuc.org/

$ virsh domifest ubuntu18

1. 仮想マシンへの OS インストール
仮想マシンが追加できたら、OS のインストールを進めていきましょう。virt-install コマン
ドを実⾏すると、新しく追加された仮想マシン上で OS のインストーラが起動しています。
CentOS のブラウザーインターフェースを起動して、仮想ディスプレイに接続し、インスト
ーラを実⾏してみましょう。
https://ホストマシンの IP アドレス:9090にアクセスして、root 権限を持つユーザーでログインします。
左側ペインのメニューで「仮想マシン」をクリックし、先頭の「＞」をクリックしましょう。
コンソールタイプを選択して仮想ディスプレイに接続します。GUI インターフェースを使⽤するためは「Graphics Console(VNC)」を選択しましょう。
あとはインストーラの指⽰にしたがって、OS のインストールを進めていきましょう。
以上の⼿順で CentOS 上に KVM（カーネルモジュール）を追加して、仮想マシンを追加し、異なる OS をホスト OS 上で実⾏できるようになります。

2. 代表的な virsh コマンドのオプション
KVM で⽣成した仮想マシンを操作するには、virsh コマンドを⽤います。主なコマンドには
以下のようなものがあります。
仮想マシン（VM）の⼀覧を表⽰します。
$ virsh list all

VM を起動します。
$ virsh start <vm 名>42
https://linuc.org/

VM を停⽌します。
$ virsh shutdown <vm 名>

VM を強制終了します。
$ virsh destroy <vm 名>

VM を再起動します。
$ virsh reboot <vm 名>

VM を削除します。
$ virsh start <vm 名>

VM の設定を変更します。
（VM の停⽌が必須）$ virsh edit <vm 名>

VM の CPU 情報を取得します。
$ virsh vcpuinfo <vm 名>43
https://linuc.org/

3. GUI で仮想マシンを管理するツール（virt-manager）
前節では virt-install コマンドを⽤いて仮想マシンの追加を⾏いましたが、デスクトップ環
境を使⽤している場合には、GUI ベースの virt-manager を使⽤することも可能です。

# yum -y install virt-manager（中略）
インストール済み:
virt-manager-2.2.1-2.el8.noarch
完了しました!

インストールが完了したら、
lvirt-manager コマンドを実⾏する

l

ナビゲーションメニューから、「アプリケーション > システムツール > 仮想マシ
ンマネージャー」をクリックするのいずれかの⽅法で起動します。

仮想マシンマネージャを起動したところ

44
https://linuc.org/

この時、libvirtd が起動していないと接続エラーが出ますので、⾃動起動にしていない場合は以下のように libvirtd を起動します。
# systemctl start libvirtd

左上のディスプレイのアイコンをクリックすると仮想マシンを追加することができます。
デフォルトでは、「ローカルのインストールメディア（ISO イメージまたは CD-ROM ドラ
イブ）」が選択されています。あらかじめ仮想マシンにインストールしたい OS の ISO イメ
ージを⽤意しておきましょう。

新しい仮想マシンの追加ウィザード

45
https://linuc.org/

ISO イメージを選択して仮想マシンを作成するメニュー
このようにして、仮想マシンマネージャー（virt-manager）を使⽤すると、GUI ベースで仮想マシンの追加を実⾏できます。

仮想マシンマネージャーを使って CentOS7.7 のインストーラを実⾏しているところ

46
https://linuc.org/

インストーラの実⾏が完了したら、OS を再起動します。今回は最⼩インストールパッケー
ジを選択したので、下記のようにコマンドラインのログイン画⾯が表⽰されます。

インストールを完了して KVM 上で CentOS 7 が動作している様⼦

47
https://linuc.org/

2.06.1 コンテナの仕組み
1. 仮想マシンとコンテナ型仮想化の違い
前節では物理マシンに直接 OS をインストールするのではなく、ホスト型・ハイパーバイザ
ー型などの仮想化技術を利⽤した仮想マシンにインストールする⽅法について学びました。
この結果、複数の OS を⼀つのハードウェア上で稼働させることができました。

仮想マシン型の仮想化イメージ
しかし、ハードウェアを丸ごと仮想化し、仮想マシンごとに OS をインストールするため、ホストマシンのメモリーやディスクの消費量が増え、仮想マシンの制御を⾏う分だけ CPUの負荷が⾼くなります。さらに、仮想マシンのバックアップに必要なディスク容量が増⼤したり、起動や複製に時間がかかったりするなどの問題があります。
そこで近年普及してきているのが、Docker などホスト OS 上のプロセスとして動作するコ
ンテナ型仮想化技術です。コンテナ型仮想化技術を⽤いると、ウェブアプリケーションや各
種サーバーなどの動作に必要なコンポーネントだけを切り出してコンテナというパッケージを構成し、より⾼速に起動や複製を実⾏できます。

48
https://linuc.org/

コンテナ型仮想化イメージ

2. コンテナを実現する技術
コンテナ型仮想化は、
l

コンテナエンジンを動作させる「ホスト OS」

l

コンテナの動作を管理する「コンテナエンジン」

l

サーバーのプロセスやリソースを区画化した「コンテナ」から構成されます。
ホスト上に区画化された空間を実現することを「コンテナ型仮想化」、実現⽅法を「コンテナ技術」と呼んでいます。コンテナは、アプリケーションだけでなく、動作に必要となるラ
イブラリや設定ファイルなど、実⾏環境をまとめたものです。
コンテナ型仮想化の特徴としては、以下のような点が挙げられます。
l

コンテナを起動するために、仮想マシンやゲスト OS を起動する必要がない。

l

コンテナエンジンがホスト OS に常駐し、コンテナの操作・管理を⾏う。

l

各コンテナはコンテナエンジンが動作しているホスト OS のカーネルを共有している

l

各コンテナの機能を構成するプロセスをプロセス群として扱うことができ、コンテナ間で互いのプロセスは参照できない。

49
https://linuc.org/

上記のようにコンテナ型仮想化は、仮想マシンやゲスト OS のリソースや負荷がないので、
l仮想マシン型に⽐べるとコンテナのサイズは⼩さく、リソース消費量を抑えられる。

l

ゲスト OS の起動停⽌が不要なので、起動が⾼速である

l

仮想マシンは数 GB のサイズになることが多いが、コンテナは数百 MB 以内の容量であることが多く、すべてのユーザーに同じ環境を提供することが容易になる。

などのメリットが得られます。

3. 名前空間（namespace）
コンテナ型仮想化では、名前空間（ネームスペース）という技術を使⽤して、コンテナとよばれるワークスペース間の分離（isolation）を実現しています。コンテナエンジンはコンテ
ナごとに名前空間の集合を⽣成します。
名前空間を扱う API（関数）には以下のようなものがあります。
lclone： 新たなプロセスを⽣成する

lsetns:

lunshare: 呼び出したプロセスを新しい名前空間に移動させる

呼び出したプロセスを既存の名前空間に参加させる

コンテナ型仮想化で使⽤される名前空間には以下のようなものがあります。
l

IPC 名前空間 （プロセス間通信のリソースを分離）

l

マウント名前空間 （ファイルシステムツリーを分離）

lネットワーク名前空間 （ネットワークインターフェースを分離）

l

PID 名前空間 （プロセス ID 空間を分離）

lユーザー名前空間（UID/GID を分離）

l

UTS 名前空間（nodename, domainame のシステム識別⼦を分離）

50
https://linuc.org/

各名前空間は、/proc/{pid}/ns/以下で確認できます。
$ ls -l /proc/$$/ns/
合計 0
lrwxrwxrwx. 1 root root 0 4 ⽉ 28 11:46 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx. 1 root root 0 4 ⽉ 28 11:46 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx. 1 root root 0 4 ⽉ 28 11:46 mnt -> 'mnt:[4026531840]'
lrwxrwxrwx. 1 root root 0 4 ⽉ 28 11:46 net -> 'net:[4026531992]'
lrwxrwxrwx. 1 root root 0 4 ⽉ 28 11:46 pid -> 'pid:[4026531836]'
lrwxrwxrwx.

1

root

root

4 ⽉

0

28

11:46

pid_for_children->'pid:[4026531836]'
lrwxrwxrwx. 1 root root 0 4 ⽉ 28 11:46 user -> 'user:[4026531837]'
lrwxrwxrwx. 1 root root 0 4 ⽉ 28 11:46 uts -> 'uts:[4026531838]'
ホスト OS で namespace ⼀覧を表⽰した結果
⼀⽅、コンテナ上でも namespace を確認してみます。
root@fe4ef9552b2e:/# ls -l /proc/$$/ns/
total 0lrwxrwxrwx. 1 root root 0 Apr 28 02:59 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx. 1 root root 0 Apr 28 02:59 ipc -> 'ipc:[4026532311]'
lrwxrwxrwx. 1 root root 0 Apr 28 02:59 mnt -> 'mnt:[4026532309]'
lrwxrwxrwx. 1 root root 0 Apr 28 02:59 net -> 'net:[4026532314]'
lrwxrwxrwx. 1 root root 0 Apr 28 02:59 pid -> 'pid:[4026532312]'
lrwxrwxrwx.

1

root

root

0

Apr

28

02:59

pid_for_children->'pid:[4026532312]'
lrwxrwxrwx. 1 root root 0 Apr 28 02:59 user -> 'user:[4026531837]'
lrwxrwxrwx. 1 root root 0 Apr 28 02:59 uts -> 'uts:[4026532310]'
コンテナ上で namespace を表⽰した結果
例えば、pid の結果を⽐較すると異なるノード番号が割りあてられています。
l

ホスト：

l

コンテナ： pid:[4026532312]

pid:[4026531836]

これにより、コンテナはホスト OS のカーネルを使⽤していますが、コンテナ毎に異なる
namespace 番号をつけることでプロセス群を分離して認識しています。
51
https://linuc.org/

コンテナ上で ps コマンドを実⾏すると、ホスト OS で動作しているプロセスの情報は表⽰されません。これは、コンテナとホスト OS が異なる名前空間を使⽤しているためです。
# docker run -it ubuntu bash
root@fe4ef9552b2e:/# ps
PID TTY

TIME CMD

1 pts/0

00:00:00 bash

10 pts/0

00:00:00 ps
ubuntu コンテナに接続してから ps コマンドを実⾏した結果[root@centos7 ~]# ps
PID TTY

TIME CMD

3716 pts/1

00:00:00 su

3724 pts/1

00:00:00 bash

3746 pts/1

00:00:00 ps
ホスト OS 上で ps コマンドを実⾏した結果

4. cgroups（コントロールグループ）
コンテナ型仮想化では、cgroups を⽤いてリソース（CPU やメモリ）などの割り当てを⾏います。これに対して namespace（名前空間）では、名前空間ごとに識別⽤のノード番号を割り当てて、リソースの分離を実⾏していました。
cgroup は Linux カーネルの機能で、システムリソースの割り当て、優先度の変更、拒否、管理や監視レベルの制御などを⾏えます。

5. コンテナとイメージ各コンテナはコンテナエンジン上で動作します。各コンテナのテンプレートはイメージと呼ばれ、コンテナからイメージを作ることもできますし、既に構成済みのイメージファイル
を公開リポジトリからダウンロードして使⽤することもできます。
イメージから⽣成されたコンテナのインスタンスにはそれぞれユニークな ID が振られ、起動や停⽌、接続や削除などができます。

52
https://linuc.org/

2.06.2 Docker コンテナとコンテナイメージの管理
1. Docker の概要
コンテナ型仮想化で広く使⽤されているのが Docker です。Docker の各コンテナは、コン
テナの動作プラットフォーム（Docker Engine など）上で動作します。
Docker は Go ⾔語で書かれていて、Apache 2.0 ライセンスの元でオープンソースソフトウ
ェアとして公開されています。
さらに Kubernetes などコンテナオーケストレーション技術を⽤いると、複数コンテナを連動させて可⽤性の⾼いシステムを短時間に構築し稼働させることができるようになってきています。
ただし、Docker を使いこなすためにはシステム構成を考え、それに適した構成定義ファイル（Dockerfile）などを作成するスキルが必要で、ある程度の知識が必要です。

Docker の動作イメージ7

1.1 コンテナのファイルシステムとイメージの関係
各コンテナはイメージと呼ばれるコンテナのテンプレートファイルから⽣成されます。ユ7

http://docs.docker.jp/_images/architecture.png
53
https://linuc.org/

ーザーは独⾃にコンテナに含めるコンポーネントを定義してイメージを作成することもできますし、Docker Hub（https://hub.docker.com/）などの公開リポジトリなどから、公開されている既成のイメージを取り込んでコンテナを⽣成することもできます。

Docker Hub のサイト
Docker Hub では ubuntu などの OS、mysql, mariadb, httpd, nginx など各種アプリケーシ
ョンやミドルウェアを含んでいるイメージが公開されています。
そして、docker pull コマンドを⽤いてイメージをダウンロードし、docker create コマンドでコンテナを⽣成、そして docker run コマンドでコンテナを実⾏できます。

1.2 Docker の動作イメージ
Docker の各コンテナは Docker Engine 上で動作し、ホストマシンのカーネルを使⽤します。
そのため、ハイパーバイザーや仮想マシンの負荷がないため、より軽量で⾼速な動作が期待
されます。

54
https://linuc.org/

コンテナ型仮想化（Docker）の動作イメージ
Docker は各種ミドルウェアライブラリのインストールや環境設定をコード化（テキストフ
ァイルに定義を記述）して管理します。
構成ファイルを共有することで、l

誰でも同じ仮想環境を構築できるl

作成したシステム環境を配布しやすい（構成ファイルを提供すればよい）

l

コンテナの追加・削除が容易にできるなどの利点が得られます。

1.3 構成⾃動化ツール利⽤の利点
構成⾃動化ツールのセクションでも扱いましたが、各種設定をコード化して管理する
Infrastructure as Code を実現しています。コード化することにより、環境構築を⾃動化し、短時間に同じ環境を確実に再現できるため、システムの運⽤管理の負担軽減や、チーム開発
時の環境構築の負荷軽減などに役⽴ちます。
開発段階からコンテナ上で開発を進め、本番環境に同じ環境を構築してデプロイ（本番環境に配置）することができるため、DevOps、開発（Development）と運⽤（Operation）の連
携がスムーズになります。
開発メンバー間で設定ファイルを共有することで短時間に開発環境を⽣成し、バージョン55
https://linuc.org/

調整やインストールなどの負担を減らせます。

2. Docker の導⼊Docker コンテナを動作させる Docker Engine には、有償の Enterprise Edition（EE）と無償の Community Edition（CE）の 2 系統があります。初めて Docker を導⼊する場合にはCommunity 版を使⽤するといいでしょう。
ここでは公式のインストール⼿順にしたがって、
Docker CE をインストールしていきます。
まずはホスト名の確認を⾏います。
hostname コマンドでホスト名が表⽰されることを確認しましょう。
$ hostname
centos7

続いては root に切り替えてから、Docker CE のインストールに必要なパッケージ、yumutils、device-mapper-persistent-data、lvm2 をインストールします。
lyum-utils は yum のユーティリティーで yum-config-manager を含みます。

ldevice-mapper-persistent-data と lvm2（論理ボリュームマネージャ）は、デバイスマッ
パーストレージドライバの動作に必要です。

# yum install -y yum-utils device-mapper-persistent-data lvm2

次に Docker Engine のインストールは、公式リポジトリを使⽤して⾏います。
まずは Docker 社の提供するリポジトリを追加します。
# yum-config-manager ¥--add-repo ¥https://download.docker.com/linux/centos/docker-ce.repo

リポジトリを追加したら、Docker Engine CE のインストールを実⾏します。

# yum install docker-ce docker-ce-cli containerd.io56
https://linuc.org/

Docker Engine CE がインストールされたら、起動してみましょう。
# systemctl start docker

動作確認のために hello-world イメージを動作させてみましょう。Docker Hub から helloworld（テスト⽤）イメージをダウンロードしてインスタンスを⽣成し、確認⽤のメッセー
ジを出⼒します。run コマンドは、イメージの取得（pull）、コンテナの⽣成（create）、コン
テナの起動（start）を連続して実⾏します。
# docker run hello-world

ホスト OS の起動時に Docker を起動するには、systemd（CentOS や Ubuntu 最新安定版など）を使⽤しているのであれば以下のコマンドを実⾏します。
# systemctl enable docker

3. Docker によるネットワークの構築
Docker の Linux イメージを使⽤してコンテナを作成すると、通常は NAT（⾃動ポート変換）機能でホスト OS のポートを⾃動的に変換してコンテナに IP アドレスを割り当てます。
しかしこの⽅式だと、名前解決ができずコンテナ名で相互にアクセスできないので、ブリッジ接続に変更して同⼀ネットワークに異なる IP アドレスで接続するように設定を変更し、コンテナ間の通信を可能にする場合があります。
まずは ubuntu1,ubuntu2 というコンテナを起動してネットワーク設定を調べてみます。最初に ubuntu1 という名前のコンテナを起動します。d は起動時に接続しない（detouch）というオプションです。
$ docker run -itd –-name ubuntu1 ubuntu /bin/bash

コンテナの起動に成功したら設定を inspect コマンドで確認します。
$ docker inspect ubuntu1

57
https://linuc.org/

Networks という項⽬の内容をチェックしてみましょう。
[{（中略）"Networks": {"bridge": {,,,"Gateway": "172.17.0.1","IPAddress": "172.17.0.2",
,,,
}
,,,
]

すると 172.17.0.2 という IP アドレスが設定されています。
同様に ubuntu2 というコンテナも起動します。

$ docker run -itd –name ubuntu2 ubuntu /bin/bash

ubuntu2 も設定を inspect コマンドで確認します。
$ docker inspect ubuntu2

58
https://linuc.org/

[（中略）"Networks": {"bridge": {,,,"Gateway": "172.17.0.1","IPAddress": "172.17.0.3",
,,,
}
｝
]

すると、ubutnu2 には、172.17.0.3 という異なる IP アドレスが割り当てられています。
次に ubuntu1 から ubuntu2 に ping で疎通確認をしてみたいと思います。まずはコンテナを起動して、bash シェルを起動します。exec は指定したコマンドを実⾏するオプションです。
$ docker exec -it ubuntu1 /bin/bash

次に ping コマンドを使うために、iputils-ping をインストールします。

root@d3ce49845646:/# apt-get update && apt install iputils-ping

インストールが成功したら、ubuntu1 から ubuntu2 へ ping を実⾏してみましょう。
root@d3ce49845646:/# ping -c 3 172.17.0.3
PING 172.17.0.3 (172.17.0.3) 56(84) bytes of data.
64 bytes from 172.17.0.3: icmp_seq=1 ttl=64 time=1.46 ms
64 bytes from 172.17.0.3: icmp_seq=2 ttl=64 time=1.70 ms
64 bytes from 172.17.0.3: icmp_seq=3 ttl=64 time=1.63 ms

59https://linuc.org/

続いて、コンテナ名で ping を送信してみましょう。
root@d3ce49845646:/# ping -c 5 ubuntu2
ping unknown host ubuntu2

デフォルトのネットワーク構成ではコンテナ名でアクセスできないので、ユーザー⾃⾝でブリッジネットワークを定義して、コンテナ名でアクセスできるようにしましょう。
まずは、独⾃のネットワークを定義します。ここでは nw1 とします。
$ docker network create nw1

続いて、ubuntu1,2 のコンテナを nw1 に接続します。
$ docker network connect nw1 ubuntu1$ docker network connect nw1 ubuntu2

もう⼀度 inspect コマンドを実⾏して nw1 の情報を確認します。
$ docker inspect ubuntu1

するとネットワークのセクションに、”nw1”が表⽰されます。
続いては、ubuntu1 に接続して ping を実⾏していきます。まずは、docker exec コマンドで ubuntu1 コンテナに接続します。
$ docker exec -it ubuntu1 /bin/bash

コンテナに接続してコマンドプロンプトが切り替わったら、コンテナ名で ping を実⾏してみましょう。

60
https://linuc.org/

root@d3ce49845646:/# ping -c 3 ubuntu2
PING ubuntu2(172.19.0.3) 56(84) bytes of data.
64 bytes from 172.19.0.3: icmp_seq=1 ttl=64 time=1.46 ms
64 bytes from 172.19.0.3: icmp_seq=2 ttl=64 time=1.70 ms
64 bytes from 172.19.0.3: icmp_seq=3 ttl=64 time=1.63 ms
これで、コンテナ名で通信ができるようになりました。
このようにして、独⾃に定義したブリッジネットワークを使⽤すると、同じホストにつながるコンテナ間で、シンプルなネットワークを構築することができます。
さらに異なるホスト上で動作するコンテナ間で通信を⾏うためには、各ホスト OS にブリッジインターフェースを追加し、異なるホスト上で動作するコンテナを同⼀の L2 ブリッジネットワークに接続して、通信を可能にするフラットなネットワークを構成することもあります。

4. Docker コンテナの管理コマンド
Docker のインストール直後に、docker run コマンドを実⾏して、hello-world イメージをダ
ウンロードしてコンテナを⽣成、動作させました。
Docker にはこれ以外にもコンテナの操作をするコマンドが⽤意されています。
ldocker ps/stats コマンドを使うと、稼働中のコンテナ⼀覧や詳細を表⽰できます。

ldocker run/create/restart コマンドを使うと、コンテナの実⾏、イメージからの作成、再起動ができます。

ldocker pause/unpause コマンドを使うと、実⾏中の Docker コンテナのプロセスの
⼀時中断、および再開を実⾏できます。

ldocker stop/kill コマンドを使うと、実⾏中のコンテナを停⽌したり、強制終了したりできます。

ldocker rm を使うと、既存のコンテナを削除できます。

4.1 コンテナに接続してプロセスを実⾏する
docker attach や exec コマンドを使うと、実⾏中のコンテナに接続して、コマンドを実⾏することができます。
という書式で使⽤します。

$ docker exec <コンテナ名> <コマンド名>61
https://linuc.org/

例えば、CentOS が動作しているコンテナに接続して bash（シェル）を起動してみましょう。

$ docker exec -it ubuntu /bin/bashl-i オプションは標準出⼒を開き続けるl-t オプションは疑似ターミナルを割り当てるというオプションで、この⼆つを指定すると、ホスト OS からコンテナ内のシェルにコマンドを投⼊できるようになります。例えば、以下のようにホスト OS のコマンドプロンプトがコンテナのシェルのコマンドプロンプトに切り替わります。コンテナ上で exit コマンドを実⾏するとホスト OS のコマンドプロンプトに戻ります。

# [root@centos ~]# docker run -it ubuntu bash
root@d3ce49845646:/#

5. コンテナイメージの管理
Docker レジストリは、Docker イメージの管理（保管や提供）をする仕組みです。複数のリポジトリを持つことができ、それぞれ複数のイメージを格納しておけます。
リポジトリは、イメージを保存しておく領域のことで、ユーザーが名前をつけてイメージを識別したり、リポジトリ内のイメージを参照してコンテナを⽣成することもできます。
Docker Hub のように公開のレジストリも存在しますが、会社や組織内だけで公開せずにイメージを使いたい場合には、プライベートリポジトリを運⽤するのが適しています。

62https://linuc.org/

Docker レジストリのイメージ

lDocker レジストリの開始⽅法

Docker レジストリ（コンテナ）を開始するには、以下のように docker run コマンドを使⽤します。

$ docker run -d -p 5000:5000 –-name registry registry:2
Ø -d は、デタッチオプション、コマンド実⾏時にコンテナに接続しないオプションです。
Ø -p は、ホストのポートをコンテナのポートを関連付けるオプションです。
Ø name オプションでレジストリ名を指定します。
Ø registry:2 は取得するレジストリのイメージの名前を指定しています。

ldocker images コマンドを使⽤すると、ローカルリポジトリ内のイメージ⼀覧を表⽰できます。

$ docker images

63
https://linuc.org/

ldocker pull

コマンドを使⽤すると、Docker Hub（公開リポジトリ）からイメージを取得します。例えば、下記は ubuntu のイメージを取得します。

$ docker pull ubuntuldocker tag コマンドを使うと、⾃分のレジストリ上にタグをつけて保存できます。例えば、先ほど取得した、ローカルにあるイメージにタグをつけるには、以下のようにします。

$ docker tag ubuntu localhost:5000/ubuntul

作成したイメージをローカルレジストリに登録するには、以下のように push コマン
ドで送信します。

$ docker push localhost:5000/ubuntu

登録したイメージをローカルのレジストリから取得するには pull コマンドを⽤います。

$ docker pull localhost:5000/ubuntulDocker レジストリを停⽌・削除するには以下のコマンドを⽤います。

$ docker stop registry && docker rm -v registryØ -v オプションで削除するレジストリ名を指定します。

ldocker import コマンドを使⽤するとアーカイブ（圧縮された）ファイルからイメージを⽣成します。例えば、以下のようなフォーマットでコマンドを実⾏すると、tgz ファイルからイメージを⽣成します。ただし、タグ付けされていないイメージが⽣成されます。

$ docker import http://example.com/exampleimage.tgz

URL ではなく、ローカルファイルシステムから読み込むことも可能です。その場合は64
https://linuc.org/

URL の部分をファイルへの PATH にします。
より詳細なオプションは、Docker の公式ドキュメントを参照してください。
http://docs.docker.jp/engine/reference/commandline/import.html

ldocker commit コマンドを使うと、既存のコンテナに名前をつけてイメージとして保存することができます。

$ docker commit default httpd

イメージの⼀覧を表⽰するには、docker images コマンドを使⽤します。

$ docker images
REPOSITORY
httpd

TAG

IMAGE ID

CREATED

SIZE

4f0aa49f1e67

48 seconds ago

197MB

上記の例では default が httpd という名前のイメージとして保存されます。また、既存のイメージにタグをつけて保存することも可能です。
例えば、centos のイメージに httpd をインストールし、centos:httpd という名前（前者がイメージ名で後者がタグ）でイメージを保存できます。

$ docker commit centos centos:httpdl

イメージの削除

イメージを削除するには、docker rmi (remove image)コマンドを使います。ただし、削除を実⾏するにはイメージを使⽤しているコンテナを停⽌しておく必要があります。

$ docker rmi httpd（イメージ名）

6. Dockerfile
ここまでは、docker pull/run コマンドで Docker Hub からイメージを取得したり、commit
コマンドでコンテナからイメージを作成したりする⼿順を紹介しました。
しかし、この⽅法だとイメージを転⽤する際に不便な場合があります。例えば、イメージの65
https://linuc.org/

構成内容をドキュメント化したり、イメージから⽣成したコンテナに対して⼿作業で設定を変更したりしなくてはならないケースが出てきます。
そこでプログラムのビルドに使⽤される Makefile のように、コンテナの構成内容をドキュ
メントではなく、テキストファイルに定義しておいて、できるだけ⼿作業を減らして構成を⾃動化するための仕組みが Dockerfile です。
Dockerfile を作成しておくと、テキストファイル内でイメージに含むアプリケーションやミ
ドルウェアを定義して、docker build コマンドで Docker コンテナのイメージをコマンドライン（docker build コマンド）から⾃動⽣成できます。そのため、作業負担や操作ミス、作業時間などを減らせます。
lDockerfile の書式

Dockerfile は、以下のフォーマットで記述します。
# コメント<命令> <引数>

主な命令には以下のようなものがあります。FROM だけでも実⾏できますが、主に RUN と
ADD を⽤いてカスタマイズされたイメージを作成します。

66
https://linuc.org/

命令

操作内容

FROM

元となる Docker イメージの指定

MAINTAINER

作成者の情報RUN

コマンドの実⾏

ADD

ファイル／ディレクトリの追加

CMD

コンテナの実⾏コマンド 1

ENTRYPOINT

コンテナの実⾏コマンド 2

WORKDIR

作業ディレクトリの指定

ENV

環境変数の指定

USER

実⾏ユーザーの指定

EXPOSE

ポートのエクスポート

VOLUME

ボリュームのマウント

l

カスタマイズイメージ作成の例

例えば、Ubuntu のイメージをベースにして、nginx をインストールしたイメージを⽣成してみましょう。

67
https://linuc.org/

$ mkdir mynginx$ cd mynginx$ vi Dockerfile

として vi エディターを起動し、以下のような内容を記述します。

FROM ubuntu
MAINTAINER Foo Bar foo@example.jp
RUN apt-get install -y nginx
ADD index.html /usr/share/nginx/html/

また、別途 index.html ファイルを作成しておきましょう。例えば、メッセージを 1 ⾏だけ含むファイルを⽣成します。

$ echo “Hello Nginx on Docker!” > index.html
Dockerfile と index.html が⽤意できたら、docker build コマンドを実⾏してイメージを⽣成してみます。

$ docker build -t <イメージ名>:<タグ名> <Dockerfile のディレクトリ>という書式で Dockerfile からイメージを⽣成します。

$ docker build -t foo/mynginx:1.0 .

イメージを⽣成したら、images コマンドでイメージが追加されたことを確認しましょう。
リポジトリ名とタグが Dockerfile と⼀致していることを確認しましょう。

$ docker images
REPOSITORYTAG

IMAGE ID

foo/mynginx

1.0

4f0aa49f1e67

centos7

CREATED48 seconds ago

2d194b392dd1

2 weeks ago

SIZE
198MB
195MB

68
https://linuc.org/

イメージからコンテナを⽣成・起動し、動作確認をしてみます。

$ docker run -d -p 80:80 –name foo/mynginx:1.0 /usr/sbin/nginx -g‘daemon off;’ -c /etc/nginx/nginx.conf
起動したら、コマンドラインから、コンテナの http ポートにアクセスして動作を確認してみましょう。

$ curl localhost
Hello Nginx on Docker!
というように index.html ファイルに記述した内容が表⽰されたら成功です。
もしもこのコンテナが不要な場合は、コンテナの停⽌、削除を実⾏しましょう。

$ docker stop mynginx
mynginx$ docker rm mynginx
mynginx

69
https://linuc.org/

2.13.1 ⾼可⽤システムの実現⽅式
このセクションでは、⾼可⽤システムを実現する⽅式について学びます。
システムに障害が発⽣すると、提供しているサービスが停⽌してしまい、社会的信⽤を失ったり、損害賠償を請求されたりするリスクがあります。
例えば、2016 年 3 ⽉には ANA（全⽇本空輸）の航空券予約・販売・搭乗⼿続きのシステムに障害が発⽣し、⽇本各地の空港で搭乗⼿続きや発券処理ができなくなってしまった事例などがあります。このケースでは、国内線のデータを格納しているデータベースサーバーを接続するイーサネットスイッチの故障が原因でした。
システム障害発⽣によるリスクを最⼩限にするために、バックアップや冗⻑化（構成要素の多重化や負荷分散）などの対策をあらかじめ講じておくことが重要です。

1. 可⽤性に影響のある事象
システム障害が発⽣する原因には、以下のようなさまざまな要素があります。
lハードウェアの⽼朽化・経年劣化、落下などの衝撃による物理障害（ハードウェア障害）

lシステムの構成ミス、アプリケーションの設計ミスや不具合などの論理障害（ソフトウ
ェア障害）

l

ネットワークの障害l

オペレーションミスなどの⼈的要因

l

不正アクセス、コンピューターウィルス、DOS(悪意のある集中アクセス)などのセキュ
リティ攻撃

l

地震や⽔害、台⾵などの⾃然災害

また、メンテナンスのための停⽌も可⽤性に影響します。メンテナンスによる停⽌にもl

定期的なバックアップなどのための計画的なサービス停⽌l

過負荷によるサーバーダウンやディスク破損などに対応するための緊急的なサービス停⽌。

があります。

70
https://linuc.org/

できるだけシステム停⽌時間を短くし、可⽤性を向上させるためには、サーバーや構成機器、
アプリケーションの冗⻑構成などの⼯夫をします。ただし、無限にコストをかけるわけにもいかないので、さまざまな評価指標を⽤いて、コストとリスク低減のバランスを考えてシス
テム構成を⼯夫する必要があります。
◎

SPoF, 回復性

システム停⽌を回避するには、その部分で障害が起きてしまうと、全システムが停⽌してしまう部分をなくす⼯夫が重要です。そして、システムの中で障害が発⽣してしまうとシステ
ム全体が機能しなくなる要素は、「SPoF（Single Point of Failure：単⼀障害点）
」と呼びま
す。

1 台故障したらサービス停⽌

1 台故障しても、サービス継続
SPoF（単⼀障害点）のイメージ

また、システム障害が発⽣してしまった場合でもシステムを復旧させる時間を短縮するためにレプリケーション、つまり複数サーバー間でデータをリアルタイムにコピーしたり、同期したりする仕組みや複数のサーバーを同時に動かし、故障した機械から別の機械に切り替える、クラスタリングという⼿法が⽤いられることもあります。
許容される障害時間やコストを考慮し、クラスタリングやレプリケーションなどの⼯夫をして、システムの停⽌時間や復旧にかかる時間を限られた予算の中で以下に短縮できるか、ということが重要になります。
次の節ではシステムの稼働率や安定性を評価する指標について⾒ていきましょう。

71
https://linuc.org/

2. 可⽤性の評価⽅法
可⽤性を評価するためには以下のような指標がよく⽤いられます。

◎

l

稼働率と SLAl

RTO と RPOl

MTBF（Mean Time Between Failure）

l

MTTR（Mean Time to Repair）

稼働率と SLA

システムの稼働率を表すには、Availability（可⽤性）がよく⽤いられます。
Availability は、（合意したサービス時間 ‒ システム停⽌時間）／合意したサービス時間
をパーセント表⽰したものです。
クラウドサービスなどの契約には、サービス提供品質の指標として、Availability を⽤いて
SLA（Service Level Agreement）を記述します。稼働率⽬標レベルを定義し、それを下回った場合に賠償請求ができるなどの項⽬を含むことがあります。
ISMS（情報セキュリティマネジメントシステム）では、情報の機密性・完全性・可⽤性を主要な 3 要素としています8 。その中で可⽤性について定義をする際には、Availability(可⽤性)レベルを下表のようなクラスに分類し、⽬標レベルを定義します。
例えば、Availability レベルが 99.9%だと、ダウンタイムは 1 年間に 8 時間 45 分(24 時間 x
365 ⽇ x 0.1%)となります。
レベル

Availability（％）

年間ダウンタイム(時間)

レベル１

99.999

5分

レベル２

99.99

53 分

レベル 3

99.9

8.8 時間レベル 4

99-99.5

44〜87 時間

Availability レベルとダウンタイム
⼀般的な⾼可⽤化クラスタリングソフトウェアは、上記のうちレベル２の稼働率を実現するように設計されています。
◎

8

MTBF と MTTR

JIS Q 27000:201472
https://linuc.org/

また、システムの平均的な連続稼働時間を MTBF（Mean Time Between Failure、平均故障間隔）と呼びます。Failure はシステム障害のことなので、システム障害が発⽣するまでの平均的な時間、つまり連続稼働時間の平均値になります。MTBF は⻑いほど、システムが安定して稼働していると考えられます。
さらにシステムが停⽌してから再稼働するまでの時間は MTTR（Mean Time To Repair、
平均修復時間）と呼ばれます。MTTR が少ないほど、システム障害が発⽣してから復旧するまでの時間を短く抑えられる、ということを意味します。

MTBF と MTTR のイメージ◎

RTO と RPO

そして、⾼可⽤化システムを設計する際に⽤いられる指標には、RTO（⽬標復旧時間：
Recovery Time Objective）と RPO（⽬標復旧時点： Recovery Point Objective）があります。
RPO はデータを復旧するバックアップデータの古さの⽬標です。どこまでデータを復元できるかの⽬標値です。これによりバックアップ⼿法や保存期間、バックアップ処理のタイミ
ングなどを策定します。
RTO はシステムを再稼働するまでの時間です。障害が発⽣してから、データ復旧、機器の修理・換装などをして、サービスを再稼働するまでの⽬標値です。
それぞれを短くするとダウンタイムを短縮することができますが、コストは数値を⼩さくするほど増⼤します。

73
https://linuc.org/

RPO と RTO のイメージ

3. ⾼可⽤性（HA: High Availability）を実現するシステム構成
可⽤性の⾼いシステムは、⼀般的に「⾼可⽤性のあるシステム」と呼ばれます。または略して HA（High Availability）構成と表記することもあります。
◎

冗⻑化（HA クラスタ）

⾼可⽤性を実現するためには、サービスを提供しているマシンが停⽌してしまった際に、何らかの⽅法で、直ちにサービスを継続することが必要です。このためには、あるサービスを提供するシステムを多重化して、待機している予備マシンでサービスを引き継ぎます。引き継ぐ処理のことを「フェイルオーバー」と呼んでいます。こうすることで、ダウンタイムを極⼒少なくしてサービス提供が継続できるようになります。
こうした現⽤系(アクティブ)と待機系(スタンバイ)のノードから構成されるシステムは、
HA クラスタ(⾼可⽤性クラスタ)と呼ばれています。

HA クラスタの動作イメージ74
https://linuc.org/

⾼可⽤性クラスタを構成するには、クラスタリングソフトウェアが使⽤されます。例えば、オープンソースで開発が進められているクラスタリングソフトウェアでは Pacemakerが有名です。Pacemaker はそれ以前から開発されてきた HeartBeat というソフトウェアのリソース管理機能だけを独⽴させたものです。
Pacemaker は単独では HA クラスタを稼働させることはできません。Corosync などのクラスタを制御するソフトウェアと組み合わせて動作させます。
Pacemaker のエージェントプロセスは、各マシン上で常時起動し、アクティブ系なノードとスタンバイ系のノードで指定した間隔で死活監視をしています。
ネットワーク

サーバー2

サーバー1
（アクティブ）
Pacemaker

相互監視⽤接続（スタンバイ）
Pacemaker

また、サービスの監視や制御をするためのプロセスは RA（リソースエージェント）と呼ばれます。RA は、サービスの起動、停⽌、監視などを⾏います。
RA には、Web サーバー（Apache や Nginx）、データベースサーバー（PostgreSQL やMySQL）、ネットワークインターフェース、ファイルシステムなどの監視に対応したものがあります。
そして、もしも障害を検出したら、待機系のマシンに処理を引き継ぎます。フェイルオー
バーに失敗すると、両⽅のノードがアクティブになってしまいます。これをスプリットブ
レインと呼びますが、両⽅のシステムから共有ディスクにアクセスしてしまい、データの不整合や破損のリスクが発⽣します。
スプリットブレインを防⽌するために STONITH（Shoot The Other Node In The Head の頭⽂字）という仕組みが⽤いられます。STONITH は両⽅がアクティブにならないように
フェイルオーバー時に障害が起きた⽅のサーバーの OS を強制的に再起動したり停⽌した75
https://linuc.org/

りする機能です。
◎

ロードバランシング（負荷分散）

例えば、⼤学や企業のポータルサイトなどで Web アクセスが集中することで Web サーバ
ーのメモリを使い果たしてしまい、応答時間が⻑くなったり Web ページがホワイトアウト
したりしてしまう場合があります。
そこで、複数台の Web サーバー間で負荷を分散するために、l

DNS ラウンドロビンを⽤いてランダムにアクセスを振り分けるl

ロードバランサを⽤いてサーバー負荷の監視を⾏い、できるだけ負荷の少ないサーバーノードにアクセスを振り分けるなどの⼯夫がされます。

4. 物理的、地理的分散による可⽤性レベルの違い
同⼀拠点でハードウェアを冗⻑化するだけでは、⾃然災害などでデータセンターが機能しなくなった場合にシステム停⽌が発⽣してしまいます。
そこで、地理的に離れた複数拠点でロードバランシングしたり、データをレプリケーション（複製）したりしておく、などの⼯夫がサービス停⽌の回避に有効です。
前節の HA クラスタリングソフトウェアなどを⽤いると、複数拠点に配置したサーバー間でフェイルオーバーすることも可能となるでしょう。

76
https://linuc.org/

2.13.2 キャパシティプランニングとスケーラビリティの確保
このセクションでは、キャパシティプランニングとスケーラビリティの確保に関する対応
策と、リソース使⽤状況の把握について学びます。

1. キャパシティプランを作成するために把握すべきシステムリソース
システムのキャパシティを⾒積もるためには、主に以下のようなリソースの消費状況を確認する必要があります。
◎

処理能⼒

CPU の使⽤率などを監視ソフトウェアなどで継続的に監視します。
⼤規模アクセスが発⽣するサービスを⽀えるサーバーでは、データベースへの同時ア
クセスが急上昇すると、CPU 使⽤率が１００％に達してしまうことがあります。こう
なると処理が追いつかず、例えばウェブページが表⽰されない、スマホアプリにリクエ
ストへのレスポンスが返らないというようなトラブルが発⽣します。そこで、定期的にCPU 使⽤率をモニターし、CPU の搭載数を増やす、サーバーの台数を増やして CPU
数を増やす、などの対策が必要となります。
◎

メモリ

オペレーティングシステムが消費するメモリ量と、アプリケーションが消費するメモ
リ量の合計が、メモリの消費量になります。
そして、この合計がハードウェアメモリの容量を超えると、メモリ容量を物理的なメモ
リ容量よりも⼤きく使えるようにする仮想メモリの仕組みによって、ディスクのスワップ領域へのアクセスが発⽣し、急激にシステムのパフォーマンスが低下します。
システムが快適な動作をするためにはできるだけスワップ領域へのアクセスを少なくすることが必要です。各メモリの消費量は top コマンドなどで確認が可能です。
Web サーバーへの集中アクセスが発⽣すると Web サーバーの⼦プロセスが多数起動され、メモリを使い果たしてしまうことがあります。この場合は、前述したように、メモリを増設したり CPU を⾼速化したりするスケールアップや、Web サーバーを複数台設置してロードバランシングするスケールアウトなどの対策が採られます。

77
https://linuc.org/

◎

ディスク容量メモリや CPU がいくら⾼速でもハードディスク領域を使い果たしてしまうと、システムが停⽌してしまいます。ハードディスクが満杯にならないように、消費状況をモニタ
ーし、溢れそうな気配があれば増設する準備を進めておく必要があります。ディスクの空き容量は、df コマンドで確認できます。
◎

ユーザー数

システムを利⽤するユーザー数と同時接続数を、データベース上のユーザーテーブル
や Web サーバーのログから確認しておきましょう。使⽤している OS やアプリケーシ
ョンで許諾されているユーザーライセンス数を超えると、利⽤ができなくなる場合があります。

2. リソースを増減させる⽅法と必要な対応
サービスが停⽌しないようにリソースを増減させる⽅法には、
l

メモリを増設する、転送速度の⾼速なタイプに換装する（スケールアップ）

lサーバーの台数を増やす（スケールアウト）l

CPU を増設する。コア数の多いものに換装する（スケールアップ）

lディスクを増設する（スケールアップ）などの対応が考えられます。

3. スケールアップの⽅式
スケールアップは先に述べたように単⼀のサーバーのリソースを増強するものです。増強
可能なものとしては、l

CPU の個数を増やす、コア数が多いものに換装する

l

メモリの容量を増やす、転送速度が⾼速なものに換装する

l

ディスクの増設、⼤容量のディスクへの換装、転送速度が速いディスクを選択する

lネットワークインターフェースを⾼速なタイプに換装するなどが考えられます。

78
https://linuc.org/

設

リ増

メモ

増設
CPU
I/F

化

⾼速

サーバー
サーバー

スケールアップのイメージ（各サーバーを増強）

4. スケールアウトの⽅式
スケールアウトは単⼀のサーバーではなく、サーバーを複数台構成に（⽔平⽅向に）拡張して CPU 負荷や、メモリやディスクなどの消費量を抑えて、サービス停⽌を防⽌するための⼯夫です。
例えば、⼤学の履修登録や企業のキャンペーンなどが発⽣すると、Web アクセスが集中することで Web サーバーのメモリを使い果たしてしまい、応答時間が⻑くなったり Web ページがホワイトアウトしたりしてしまう場合があります。このような時には、Web サーバ
ーを多重化して、各 Web サーバーのメモリ消費量や CPU 消費量を低減させて、安定的にWeb ページの配信を⾏えるようにします。

スケールアウトのイメージ（台数を増やして各ノードの負荷分散）

79
https://linuc.org/

さらに外部から 1 台のサーバーにアクセスしているように⾒せるためにl

DNS ラウンドロビンを⽤いてランダムにアクセスを振り分けるl

ロードバランサを⽤いてサーバー負荷の監視を⾏い、できるだけ負荷の少ないサー
バーノードにアクセスを振り分けるなど、ロードバランシングと呼ばれる⼯夫をします。
DNS ラウンドロビンを⽤いると特定のホスト名に送信されてきたリクエストを、複数の異なる IP アドレスが付与された Web サーバーにランダムに割り振って、負荷の分散を図ります。
例えば、DNS サーバーのゾーンファイル上で同じホスト名に対して複数の IP アドレスを割り当てます。すると同じ URL にアクセスしようとした場合に、クライアントのウェブ
ブラウザーには登録されている IP アドレスが順番に（ラウンドロビンに）返されます。
それによって、アクセスを登録した IP アドレスの個数分のサーバーにアクセスを分散させることができます。

DNS ラウンドロビンによる負荷分散のイメージ（DNS サーバーが異なる IP アドレスを返す）
ロードバランサソフトウェアや、専⽤装置（アプライアンス）を⽤いると、各ノードの負荷を監視して、より負荷の低いマシンにリクエストを振り分けたり、同じセッションのリクエ
ストを同⼀のノードで処理したりするように、クライアント（Web ブラウザーなど）からのリクエストや通信を振り分けます。
80
https://linuc.org/

ロードバランサの動作イメージ
ロードバランサはネットワーク機器ベンダーが提供する専⽤アプライアンス、ソフトウェ
アベースのロードバランサ、クラウドサービスにおける仮想ネットワークデバイスなどの選択肢があります。
例えば、オープンソースのロードバランサには、haproxy などがあります。また、SPoF（単⼀障害点）を減らすために、ロードバランサを複数台並べて、死活監視を⾏い、ロードバラ
ンサ間でフェイルオーバーしたり、障害が発⽣したノードを停⽌したりすることもあります。haproxy を使⽤する場合には、サーバーを冗⻑化する keepalived でロードバランサを切
り替え、システム停⽌を回避することができます。

haproxy を冗⻑化したイメージ

81
https://linuc.org/

◎スケールアウトに対応できるアプリケーション構成

アプリケーションの構成でスケールアウトに対応できるようにするためには、l

Web サーバー、ミドルウェアを動作させるサーバー、データベースサーバーを分離する
まずは、HTTP アクセスの処理、アプリケーションの実⾏、データベースアクセスの負荷を分散するために、Web サーバー（Nginx や Apache）、ミドルウェア（PHP や JavaEE サーバーなどのアプリケーションサーバー）、データベースサーバーのそれぞれを１台で構成します。

l

続いて、それぞれのノードの負荷が増⼤した場合
ØWeb サーバーを複数台構成にしてロードバランシングする（先頭にロードバラン
サを配置する）Ø

データベースサーバーを複数台構成にしてデータを複数台で保持するデータベー
スクラスタリングを⾏うなどの対策を考えます。
lアプリケーションをステートレスな構成にする。
Øセッションが複数サーバーで利⽤できるよう、共有領域に保持するようにアプリ
ケーションを開発したり、設定ファイルで指定したりできるようにする。

Ø

ロードバランサによっては同⼀セッションを同じマシンに処理させるセッション
親和性（セッションアフィニティ）機能を搭載しているデバイスもあります。

Ø

アプリケーションが⽤いるデータを共有ディスクに保持する。これにより、データの整合性が保持されます。

Ø

データベース設計を疎結合に対応できるように⼯夫する。リレーションを厳しくし過ぎないでデータベースを複数に分割できるように構成しておく。参照系と更新・挿⼊系のデータベースを分けるなど複数台で運⽤することを想定したアプリケーション構成にしておくことも有効な場合があります。

82
https://linuc.org/

◎

構成管理ツールや仮想マシンイメージを使ったスケールアウト

⼿動で仮想マシンを追加すると、Apache や Nginx などの Web サーバーソフトウェアをインストールして設定したり、MySQL などのデータベースサーバーソフトウェアをインストールして初期化する、などの初期設定作業が必要になります。こうした初期設定作業はプロビジョニングと呼ばれています。しかし、台数が増えてくると作業者の負担が⼤きくなり、設定ミスが発⽣したりするリスクが発⽣します。
そこで、構成管理ツールを使⽤してあらかじめサーバーに組み込むソフトウェアや設定などの情報をプロビジョニング設定ファイルに記述しておき、コマンドから読み込むことで⼀連のプロビジョニング作業を⾃動的に⾏うと、前述のリスクを低減させることができます。
構成管理ツールには、2.04.6 で解説したような Ansible などが使⽤されています。

83https://linuc.org/

2.13.3 クラウドサービス上のシステム構成
クラウドはインターネットに接続して利⽤することを前提とした各種サービスのことを指します。特徴としては、負荷の増減に応じて柔軟にリソースを追加したり、構成を変更しなおしたりできます。
ただし、クラウドサービスには、SaaS、PaaS、IaaS など、さまざまな利⽤形態があります。
SaaS（Software as a Service9 ）◎Saas は、従来パッケージ製品として提供されていたソフトウェアをインターネット経由でサービスとして提供し、利⽤する形態のことです。Salesforce や G Suite などが広く使⽤されています。
PaaS（Platform as a Service10 ）◎PaaS は、ソフトウェアが動作するためのハードウェアや OS などの⼀式をインターネ
ット上で提供する形態のことです。各サービスの仕様に沿ってソフトウェアを開発することで、OS やミドルウェアなどのインストールや設定をしなくても、アプリケーシ
ョンの開発、提供ができるのが特徴です。Google App Engine や Heroku などが広く使⽤されています。
IaaS（Infrastructure as a Service11 ）◎IaaS は、仮想サーバーやストレージ、ネットワークデバイスなどのインフラを、インターネット上のサービスとして提供する利⽤形態のことです。ユーザは必要に応じて、⾃由にシステムを構成するためのサーバーやデバイスのスペックや容量を選択できるのが特徴です。Google Compute Engine や Amazon Elastic Cloud(EC2)など、パブリック
クラウドと呼ばれるサービスが IaaS に分類されます。
このセクションでは、IaaS を中⼼としたシステムを構成する要素について説明していきます。

1. クラウドストレージの種別

9

サース

10

パース

11

アイアース・イァース

84https://linuc.org/

クラウドサーバーで使⽤できるストレージには、以下のようなものがあります。
◎

エフェメラルストレージ

インスタンスの起動時だけ使⽤可能なストレージです。AWS などではインスタンスス
トレージと呼ばれます。
仮想マシンのインスタンスを停⽌するとデータが消えて（蒸発する、揮発する、とも⾔います）しまうという特徴があります。
しかし、⾼速・広帯域（ディスク I/O が⾼速）で、追加料⾦がかからない（AWS EC2の場合）ので、
Ø

バッチ処理やバックアップ作業などの⼀時的な作業領域

Ø

キャッシュ

Ø

テンポラリな（⼀時的な）ログの保持Ø

データダンプを⼀時的に保持するなどの⽤途に使います。
◎

永続化ストレージ

⾼速・広帯域な揮発性のインスタンスストレージに対して、インスタンスを停⽌、起動してもデータが消えない（蒸発しない、揮発しない）タイプのストレージは、永続化（パーシステントな）ストレージと呼ばれます。
物理的なハードディスクなどブロックデバイスのように、初期化してファイルシステ
ムを構築し、仮想マシンにマウントすることができます。
同じネットワーク上の複数の仮想マシンにマウントしたり、逆に⼀つの仮想マシンに
複数ボリュームをマウントしたりすることができます。

2. クラウドのネットワークの種別
クラウド上で仮想マシンや（仮想）ネットワークデバイスに IP アドレスを割り当てる場合には、固定 IP アドレスを割り当てる⽅法と、複数の仮想マシンのインスタンスで IP アド
レスを共有する⽅法があります。

85
https://linuc.org/

◎

固定 IP アドレス

固定で IP アドレスを割り当てます。パブリック IP アドレスを設定すれば外部からア
クセスできます。また、ファイアウォールの内側でプライベートな IP アドレスを割り当てることも可能です。
◎

フローティング IP アドレス

⾼可⽤化クラスタで冗⻑化したシステムを構成する場合などに使います。まず、アクティブなノードにある IP アドレスを割り当てます。もしもアクティブなノードで障害が発⽣したら、クラスタ制御ソフトなどを使い、その IP アドレスをスタンバイしているノードに割り当て直してからアクティブにします。その際、元のアクティブノードの IP
アドレスは解放します。
このようにクラスタを構成するノードで IP アドレスをシェアし、動的に割り当てを変更するタイプの IP アドレスを「フローティング IP アドレス」と呼びます。フローティ
ング IP アドレスはクラウド環境だけでなく、ベアメタル環境でも使⽤することがあります。

3. クラウドのネットワークセキュリティ◎

テナントネットワーク

多くのクラウドサービスではユーザーは他のネットワークから独⽴した仮想ネットワーク
を構築します。この独⽴したネットワークは「テナントネットワーク」と呼ばれます。また、仮想のエッジデバイス（外部と通信するノード）でルーティングを設定することで異なるテ
ナントネットワーク間で通信をすることも可能です。
◎

ファイアウォール（セキュリティグループ）

セキュリティグループとは、クラウドサービスで設定できるファイアウォール機能のことです。セキュリティグループを構成すると、仮想マシンへのアクセスや外部からサーバープ
ロセスへの通信などを制御することができます。
例えば、l

特定の IP アドレスからの SSH 接続のリクエストを許可して、管理者権限ユーザ
ーが sshd にアクセスし、ログイン処理を⾏えるようにする

l

任意のクライアントから Web サーバー（httpｄ）への 80 番、443 番、指定したポート番号を⽤いたアクセスを許可するなどの設定が可能です。
86
https://linuc.org/

パブリッククラウドサービスは、オンプレミスのサーバーや社内システムとは違い、常に第三者からのポートスキャンなどの脅威にさらされます。
不⽤意にインバウンド（外から内）のアクセスを許可していると、不⽤意にログインされてしまったり、連携している社内システムに侵⼊されたりするリスクが発⽣します。そこで、必要以上にアクセスを許可しないなど、セキュリティグループの設定には細⼼の注意が必
要です。
◎

認証の強化

先に説明したようにパブリッククラウド環境では第三者がポートスキャンをして、接続を試みるリスクがあります。そこで、オンプレミスでは ID・パスワード認証をしていても、クラウドサーバーについては公開鍵認証⽅式を⽤いる⽅がセキュリティ強度を⾼めることができます。ユーザーがキーを作成し、登録する⼿間はかかりますが、サイバー攻撃からシステムを防御するためには⾮常に有効な⼿段となりますので、できる限り公開鍵認証⽅式が使えるように設定をしましょう。
◎

マシンイメージのセキュリティ

クラウドサービスでは、既存のサーバーイメージを元に仮想マシンのインスタンスを⽣成して、⼿動や構成管理ツールを⽤いて、短時間に新しいサーバーの増設ができる利便性があります。
しかし、マスターとなるサーバーイメージにセキュリティホールが存在した場合には、そのイメージから新規に追加したインスタンスにも脆弱性が引き継がれてしまいます。
そこで、既存イメージをそのまま使いまわすのではなく、セキュリティパッチなどを適⽤して安全なイメージを⽤いて仮想マシンインスタンスの追加ができるように継続的にメンテナンスする必要があります。

4. クラウドを⽀える主要な技術やサービス
以下では、クラウドを⽀える主要な技術やサービスについて説明します。
◎

オブジェクトストレージ

データの保存に特化したサービスはオブジェクトストレージと呼ばれています。
87https://linuc.org/

例えば、Amazon S3 では「バケット」という単位でデータオブジェクトを格納する領域を設定し、各種データの保存や取り出しを⾏えます。例えば、OS のイメージ、バックアップデータから、個別のテキストファイル、画像データなど、さまざまなサイズ、フォーマットのデータを格納することができます。
各データには URL でアクセスすることが可能で、
l

バケット名が aws-s3-bucket1l

データのキーが/photos/image1.jpg

である場合には、
https://aws-s3-bucket1.s3.amazonaws.com/photos/image1.jpgのように URL を⽤いて参照し、アプリケーションから呼び出して使⽤することが可能となります。
◎

メッセージングシステム（キュー）メッセージングシステムは、異なるシステムやアプリケーション間で⾮同期に処理を連携する際に使われる仕組みです。
各アプリケーションはメッセージングプロバイダと呼ばれるサービスにメッセージを送信します。メッセージングプロバイダは、コンシューマーと呼ばれるメッセージを受信するシステムやアプリケーションに対して、受け取ったメッセージを送信します。
メッセージにはアプリケーション固有のデータは含めません。例えば、在庫商品の情報、⼈事情報などアプリケーションに依存しないデータがやりとりされます。
メッセージングシステムを使⽤することで、異なるアプリケーション間での処理を⾮同期に連携することが可能になります。

88
https://linuc.org/

◎オートスケーラー

パブリッククラウドサービスでは、システムの負荷の増減状況に基づいて、⾃動的に仮想マシンインスタンスの増設や削除を⾏う「⾃動（オート）スケーリング」機能が提供されています。
オートスケールを⾏うインスタンス群は、事前に設定したスケーリングポリシー（⽅針）に基づいて、⾃動的にインスタンスの追加・削除を実⾏します。
負荷が⼤きくなった場合にインスタンスを追加してスケールアウト（台数を増やす）処理
は「アップスケーリング」、負荷が少なくなった場合にインスタンスを削除する処理は「ダウンスケーリング」と呼ばれています。
オートスケーリングのポリシーには、以下のようなものがあります。
l

平均 CPU 使⽤率
例えば、インスタンスあたりの CPU 平均使⽤率が７０％以下になるようにインス
タンス数を増減させて⾃動調整します。

l

１秒あたりの HTTP/HTTPS リクエスト数
例えば、１秒あたり１０００アクセスを処理できるようにインスタンス数の調整を
⾏います。

l

グループ全体での指標
各インスタンスではなく、インスタンスグループ全体でのリソース消費や CPU 負荷、処理能⼒などの指標を設定します。

89https://linuc.org/

2.13.4 典型的なシステムアーキテクチャ
このセクションでは⾼可⽤性やスケーラビリティを確保するためのシステム構成パターン
について学びます。

1. LAPP, LAMP 構成
オープンソースの Apache/Nginx Web サーバーと PHP モジュール、PostgreSQL またはMySQL などのリレーショナルデータベースから、構成される Web アプリケーションは世界中で広く使⽤されています。
PHP ⾔語は、l HTML ファイルに PHP ⾔語で記述したプログラムを埋め込むことができる
l シンプルな⽂法で⽐較的短時間に習得することができる
l 安価なホスティングサービスが PHP プログラムの動作に対応しているなどの特徴から、Web アプリケーション開発に広く採⽤されています。
また、WordPress、Moodle などのコンテントマネジメントシステム（CMS、Web サイトやブログをプログラミング知識なしに構築・運⽤できるソフトウェア）やオンライン学習⽀援システムが動作することもあり、Ruby, Python, Java などで書かれたソフトウェアよりもより多くのサイト運⽤に使⽤されています。
LAPP は、Linux + Apache + PHP + PostgreSQL、LAMP は Linux + Apache + PHP +MySQL から構成された Web アプリケーションの動作環境です。PostgreSQL はトランザクション制御などに優れ、安定性が注⽬されています。MySQL は PostgreSQL や他のデータベースソフトウェアに⽐較すると、より⾼速に動作することを優先していて、開発者の間で⼈気があります。ただし、Oracle 社が MySQL の知的財産を取得してから、元の開発者たちはコードをフォーク（分岐）し、MariaDB というプロジェクトで開発を進めています。

90
https://linuc.org/

LAPP・LAMP 構成
LAMP, LAPP によるシステムは 1 台でも動作しますが、先に解説したように複数台で構成することも可能です。
l Web サーバー（PHP モジュール）とデータベースサーバーを分離して 2 台構成にする
l ロードバランサ―を⼊れて Web サーバーを複数台構成に冗⻑化する
l データベースサーバーをクラスタリングして複数台構成にするなどシステムの負荷に応じて、冗⻑構成を取り、より⼤きな負荷に耐えられるようシステ
ム構成を柔軟に変更することができます。
また近年ではリソース消費を節約できるため、Apache の代わりに Nginx（エンジンエックス）という Web サーバーソフトが使⽤されるケースも増加しています。
Apache や Nginx は PHP を別のプロセスで動作させる PHP-FPM モジュール12 を⽤いて、FastCGI という仕組みで PHP プログラムを処理できます。Web サーバーとは別のプロセスでサーバーサイドの PHP プログラムを動作させる仕組みです。
これによりl

Web サーバーの負荷を軽減できるl

CGI だとプログラムの実⾏のたびにプロセスを起動・停⽌するが、FastCGI は常駐するためプロセスの起動・停⽌のリソース消費を節約できるなどの利点があります。

12

PHP-FPM、FastCGI Process Manager は Apache にも Nginx にも対応しています。
91
https://linuc.org/

2. Web3 層モデル
１の PHP は Web サーバーのプロセス上で動作しましたが、
アプリケーションの処理を Web
サーバーと切り離すことでそれぞれの負荷を軽減したり、冗⻑構成にしたりして負荷分散を図ることが可能です。その場合は、
Web サーバー + アプリケーションサーバー ＋ データベースサーバーという 3 階層の構成を取ります。
またそれぞれのレイヤーで冗⻑化構成を取ることも可能です。
アプリケーションサーバーとしては、Java に対応した Tomcat, JBoss などが有名です。
Tomcat は Java で書かれた Web アプリケーション（Java サーブレットや JSP[Java Server
pages]）を動作させることができ、Java を使⽤した Web アプリケーション開発で⼈気があります。また、簡易な Web サーバーとして機能することが可能です。
ただし、Tomcat など Java ベースのアプリケーションサーバーは Java VM（Java の実⾏環
境、JVM とも呼ばれる。OpenJDK や Oracle JDK などに含まれる）や JRE（Java Runtime
Engine）の上で動作するため、メモリ消費量が増⼤したり、Java 実⾏環境へのメモリ割当て
量を増加させたりして実⾏環境がクラッシュしないようにするなどの⼯夫が必要で、⼀定のチューニング知識を要します。

Web3 層モデルのイメージ

92
https://linuc.org/

3. 冗⻑構成の Web3 層モデル
Web3 層モデルのそれぞれの層は多重化したり、冗⻑構成を取ることが可能です。
l

多重化はロードバランサ―を⼊れて処理を複数台に分散する仕組みl冗⻑化は、HA クラスタリングソフトウェアでサービスの死活監視を⾏い、アクティブなサーバーをスタンバイ系のサーバーと切り替えて、システム停⽌を回避する仕組みです。

Web サーバー多重化 + アプリケーションサーバーの HA クラスタ + DB サーバー構成

4. LB/DNS ラウンドロビン + 複数 Web サーバー(スケールアウト)によるス
ケーラブルなシステム
93
https://linuc.org/

３で取り上げたフロントエンドの Web サーバーの多重化、スケールアウトによるロードバ
ランシング（負荷分散）は、バックエンドのデータベースやアプリケーションサーバーがな
い環境でも機能します。
例えば、WordPress サイトを以下の様に構成して⼤規模アクセスに耐えるように構成できます。

ロードバランサを使って Web サーバーを多重化したイメージ

5. プロキシサーバー(キャッシュサーバー)や CDN（Content Delivery Network）
を活⽤した Web システム◎

プロキシサーバー

Apache や Nginx などのプロキシサーバー（リバースプロキシ機能）を⽤いると、クライアントからのリクエストのうち、l

静的なコンテンツはキャッシュから配信するl

動的なコンテンツ（例えばデータベースを参照して結果を動的に返す）については、
94
https://linuc.org/

アプリケーションサーバーで処理してレスポンスを返すというように、アプリケーションサーバーの負荷やテナントネットワーク内のトラフィッ
クを軽減することが可能になります。

プロキシサーバーを⽤いて、負荷分散をした構成例◎

CDN（Content Delivery Network）を活⽤したシステム

⼤規模の動画コンテンツ配信などを⾏う際に、⼀拠点にあるサーバーからコンテンツ配信
を⾏うと、サーバーだけでなく、インターネット回線がいっぱいになってしまったり、動画の再⽣が途切れたり、再⽣までの時間が⻑くなってしまう、などの問題が発⽣します。
そこで、コンテンツを複数拠点のサーバーに分散させておき、地理的に最も近いサーバーからコンテンツ配信を⾏うための仕組みが⽤いられます。Content Delivery Network、コンテ
ントデリバリーネットワーク、または略して CDN と呼ばれます。
95
https://linuc.org/

例えば、Akamai 社のサービスなどが有名です。また動画配信に限れば、YouTube, Vimeo,
Brightcove などの動画配信および配信⽤の変換サービスを提供する事業者もいます。
CDN を使う場合には、オリジナルのコンテンツを CDN サービスの管理画⾯などからオリジンサーバーと呼ばれるサーバーにアップロードします。
オリジンサーバーは配信⽤のデータ変換（動画の場合にはトランスコード、複数の回線速度で切り替えて配信できるように、複数のビットレートに変換する）を⾏った後、各拠点にあるキャッシュサーバー（エッジノード）にデータを複製していきます。
こうした仕組みを⽤いることで、できるだけ配信サーバーの負荷や回線消費量を抑え、配信
サービスの遅延や再⽣できないトラブルを減らすことが可能になります。

CDN の動作イメージ

6. メッセージングキューを活⽤した⾮同期データ処理システム
メッセージングシステムは、異なるサーバー間で処理を連携するための仕組みです。サーバ
96
https://linuc.org/

ー間のメッセージは所定のフォーマットの XML ファイルなどで記述され、アプリケーションにできるだけ依存しない形でデータの受け渡しを⾏い、柔軟に連携を図ることができます。こうしたアプリケーションやシステムに依存しない連携は「疎結合」と呼ばれています。
メッセージングシステムを構成する要素としては、以下のようなものがあります。
lメッセージプロデュ―サー： メッセージを送信するアプリケーションlメッセージキュー： メッセージを格納するところ。キューは列という意味。

lメッセージブローカー： メッセージを中継するノードlメッセージコンシューマー： メッセージを受け取るシステム

メッセージングブローカーには、オープンソース（Apache ライセンス）で開発されている
ActiveMQ などがあります。

メッセージングシステムの動作イメージ

97
https://linuc.org/

Appendix
A.1 Zabbix の概要
Zabbix とは、システム運⽤時に、サーバーやネットワークの状態を監視するための運⽤監視ツールです。システムの状態を監視し、必要に応じてアラートをあげるために、
l ネットワーク経由でサーバーやデバイスなどの死活監視やリソース消費状況を監視する
l 指定したしきい値を超えたりエラーが検出されたりしたらメールなどで通知をする
l 指定の条件を満たしたら、コマンドを実⾏するなどを⾏う機能を有しています。

1. Zabbix でできること
Zabbix は以下のような機能を有しています。

1.1 さまざまなデバイスやアプリケーションの監視
監視対象には以下のようなものが挙げられます。
lZabbix エージェントをインストールしたサーバーや仮想マシン

l

SNMP で監視可能なネットワークデバイスlエンドユーザーの Web ブラウザーl

Web アプリケーションl

データベース

1.2 障害検知
1 で挙げたような監視対象から収集した稼働状況やパフォーマンスについての情報から、障害ステータスを⾃動的に検知します。Zabbix は障害検知に関連して以下のような機能を提供します。
l

柔軟な定義設定l

障害の切り分けと障害復旧状況

l

障害の緊急度・深刻度（Severity）レベルl

原因の解析・推定l

異常検知（障害発⽣はしていないが、リソースがひっ迫しているなど）

l

傾向予測
98
https://linuc.org/

1.3 可視化
Zabbix に内蔵された Web インターフェースを⽤いると、以下のような情報にアクセスできます。
lウィジェット（機能ごと）ベースのダッシュボード（⼀覧表⽰画⾯）

l

グラフ

l

ネットワーク構成図l

スライドショー

l

ドリルダウンレポート（詳細分析機能）

1.4 アラート通知と復旧
Zabbix を⽤いると、システム管理者にさまざまな経路で障害の発⽣を通知したり、復旧⽤
スクリプトの実⾏などが可能になります。
l

メールによる通知l

あらかじめ設定した復旧⽤のスクリプトの実⾏

l

問題の深刻度によるレポート機能（エスカレーション）のカスタマイズlメッセージのカスタマイズ

1.5 セキュリティと認証
Zabbix では、エージェントやノード間の通信においてデータ保護を実現するためのセキュリティ機能を提供します。
lZabbix コンポーネント（サーバー・エージェント・WebUI）間での強⼒な暗号化l

複数の認証⽅法への対応
ØlOpen LDAP, Active Directory(Microsoft の認証プロダクト)

ユーザー権限の設定

1.6 簡単な導⼊
Zabbix は導⼊・運⽤のハードルを下げるために以下のような機能が提供されます。
l

主要ディストリビューション向けの公式インストールパッケージl

すぐに使えるテンプレート機能l

テンプレートのカスタマイズ機能l

ユーザコミュニティで公開されている多数のテンプレ―ト
99
https://linuc.org/

l

有償のテンプレート作成サービス

1.7 オートディスカバリー
Zabbix を⽤いるとコンポーネントの追加・削除・変更を⾃動で⾏えます。
lネットワークディスカバリー
定期的にネットワークをチェックし、デバイスタイプ、IP アドレス、ステータス、アップタイム・ダウンタイムなどを発⾒し、問題を発⾒した際には事前に定義したアクシ
ョンを実⾏します。

l

ローレベルディスカバリー
あらかじめ定義したターゲットデバイスに対して、監視対象となるファイルシステム
項⽬、トリガー（アクションを実⾏するきっかけやしきい値）、グラフを⾃動で⽣成します。

lアクティブエージェントの⾃動登録
Zabbix エージェントがインストールされている機器が接続されると⾃動的に監視をス
タートします。

1.8 分散監視
Zabbix は分散したデバイスやアプリケーションの集中管理を実現します。例えば、以下のような分散監視が可能になります。
l

数千の監視ターゲットからのデータ収集・可視化lファイアウォールや DMZ（ネットワーク上の⾮武装領域、ファイアウォールと同じゾーンまたは外にある領域）越しの監視l

ネットワーク障害時にも（可能な限り）データを収集l

監視ターゲット上で、リモート環境からカスタムスクリプトを実⾏

1.9 Zabbix API
Zabbix は API（アプリケーション・プログラミング・インターフェース）を提供し、他のアプリケーションから、Zabbix の機能にアクセスしたり連携したりすることができます。
例えば、以下のような連携が可能になります。
l

API 経由での Zabbix 管理の⾃動化

l200 以上のメソッド（関数）を⽤いた Zabbix の機能へのアクセスlZabbix と連携するアプリケーション開発⽤の API の提供

l外部アプリケーションとの連携
100
https://linuc.org/Øl

設定管理、チケットシステム（障害トラッカーへの⾃動登録・チケット発⾏）

設定やログの取り出し、管理

2. Zabbix を構成するコンポーネント
Zabbix は三つのコンポーネントから構成されています。
lZabbix サーバー
監視ターゲットからデータを取得してデータベースに保存したり、特定の条件を満たした場合に通知を送信したりするlZabbix Web UI
収集したデータやリソース消費状況などを表⽰したり、監視内容の設定を Web ベース
で実⾏したりするlZabbix エージェント
監視ターゲットとなるマシンにインストールして常時起動し、サーバーから監視を実⾏できるようにするクライアント

101
https://linuc.org/

3. Zabbix のインストール（2020 年 4 ⽉現在）
Zabbix の最新安定版のバージョンは 4.4, ⻑期サポート対応版は 4.0 となっています。
Zabbix の公式サイトでは、バージョンやディストリビューション、データベースソフトウ
ェアの種類などを選択すると、その組み合わせに対応したインストール⼿順が表⽰されるようになっています。

それでは、CentOS 8.0 と MySQL、Apache の組み合わせでインストールを実⾏してみましょう。
（１）Zabbix のリポジトリの追加とテンポラリファイルのクリーンアップ（削除）# rpm -Uvh https://repo.zabbix.com/zabbix/4.4/rhel/8/x86_64/zabbixrelease-4.4-1.el8.noarch.rpm# yum clean all（２）Zabbix サーバー、Web インターフェース、Apache 設定ファイル、Zabbix エージェ
# yum install zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf
zabbix-agent
102
https://linuc.org/

ントのインストール（３）MySQL データベース上に Zabbix の収集したデータを保存するデータベースインス
タンスを追加して zabbix ユーザーにアクセス権を追加する。
# mysql -uroot -p<password>
mysql> create database zabbix character set utf8 collate utf8_bin;
mysql> grant all privileges on zabbix.* to zabbix@localhost identified
by '<zabbix ユーザのパスワード>';
mysql> quit;

Zabbix サーバー上で、データベースのスキーマ（テーブル構成）や初期データのインポー
トを⾏います。
# zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql uzabbix -p zabbix（４）Zabbix の設定ファイル（/etc/php-fpm.d/zabbix.conf）にデータベース設定（zabbix
ユーザの DB パスワード）を追記する。
DBPassword=<zabbix ユーザーのパスワード>（５）タイムゾーンの設定を PHP の設定ファイル（/etc/php-fpm.d/zabbix.conf）に追加する。
; php_value[date.timezone] = Europe/Riga⇒
php_value[date.timezone] = Asia/Tokyo（６）Zabbix サーバーと Apache, PHP(FastCGI モードの PHP プロセス)を起動する。またOS 再起動時に⾃動起動するための enable 設定を⾏う。
# systemctl restart zabbix-server zabbix-agent httpd php-fpm# systemctl enable zabbix-server zabbix-agent httpd php-fpm
103
https://linuc.org/

（７）Web インターフェースにアクセスしてフロントエンドの設定を⾏う。
http://Zabbix サーバーをインストールしたサーバーのホスト名・IP/zabbixにアクセスします。
◎フロントエンドの設定 URL を開いたところ

インストール条件の確認（問題があれば PHP 設定などを変更）

104
https://linuc.org/

データベースの接続設定を⼊⼒して「Next step」をクリックします。

Zabbix サーバーの設定を⾏います。Name はオプションですが、⼊れておくと管理画⾯に表⽰され、他のサーバーと識別しやすくなります。

105
https://linuc.org/

すると設定のサマリー（要約）ページが表⽰されます。

設定ファイルをダウンロードして、zabbix のドキュメントルートの conf ディレクトリに保
存します。

106
https://linuc.org/

インストールを完了します。

インストールが完了したら、ログイン画⾯が出るので、初期 ID・パスワード（Admin・zabbix）
でログインしましょう。

107
https://linuc.org/

4. Zabbix の初期設定（ユーザの追加・設定）
無事にログインできたら、Administration ⇒ Users というメニューを開いて、ユーザー⼀覧を表⽰しましょう。

右上の「Create User」をクリックして、ユーザーの追加を⾏います。

108https://linuc.org/

「Add」をクリックしてユーザーが追加されたら、続いては上部の「Media」タブをクリックして通知設定を⾏います。

109https://linuc.org/

l Send to は送信先のメールアドレス
l When active は、通知を送信する時間帯の指定
l Use if severity は、情報や障害の深刻度により送受信の可否を設定できます。例えば、Disaster は障害発⽣情報、Warning は警告や注意、それ以外はパフォーマン
スなどの情報です。

l Enabled では通知の有効化・無効化を切り替えられます。
続いては「Permissions」タブをクリックして、監視対象のデバイスやサーバーの選択をします。

110
https://linuc.org/

Select をクリックすると選択肢の⼀覧が表⽰されます。
例えば、下の図では「Linux Servers」へのアクセスを選択しています。それ以外には、⾃動検知されたホスト、ハイパーバイザー、テンプレート、仮想マシン、Zabbix サーバーなどが選択可能となっています。

チェックを⼊れたら「Select」をクリックして、設定を保存しユーザー情報のページに戻ります。
以上の設定で、Web インターフェースから Linux サーバーの情報にアクセスできるようになります。
◎インターフェースの⽇本語化
ページ右上のユーザプロフィールを表⽰するアイコンをクリックすると、⾔語設定を切り替えることができます。
デフォルトでは英語メニューになっています。もし、⽇本語メニューで使⽤したい場合には、「Japanese(ja_JP)」を選択すると⽇本語メニューに切り替えることができます。

111
https://linuc.org/

5. 監視対象の追加と表⽰例
あとは、監視ターゲットの情報を追加して、監視する対象（例えば、CPU 使⽤率やメモリ
使⽤量）などを指定します。
まずは監視対象のホストを追加します。

Zabbix エージェントのホストを追加する画⾯13
監視対象のホストを追加したら、次は監視するリソースを設定します。
例えば、下の図では CPU 使⽤率のデータを設定しています。

13

https://www.zabbix.com/documentation/4.0/manual/quickstart/host112
https://linuc.org/

localhost の CPU 使⽤率を監視アイテムに追加する画⾯14
ダッシュボードに戻ると、以下のような CPU 使⽤率の推移を可視化したグラフを得ることができます。

14

https://www.zabbix.com/documentation/4.0/manual/quickstart/item113
https://linuc.org/

Zabbix で CPU 使⽤率の推移を可視化したグラフの例15◎SELinux を有効化した状態で Zabbix を動作させるための設定
SELinux が有効になっている状態では、Zabbix が外部と通信することができません。そこ
で、Zabbix ⽤の SELinux のポリシーパッケージをインストールして、OS を再起動しまし# semodule -i my-zabbixserver.pp
ょう。

15

https://www.zabbix.com/documentation/4.0
114
https://linuc.org/

A.2 Pacemaker, Corosync のインストールと主な設定
以下では ２台の CentOS 7 マシンに Pacemaker と Corosync を導⼊し、簡単なクラスタ構成を構築してみます。
Pacemaker と Corosync は yum コマンドでインストールできます。
$ yum install pacemaker-all

yum コマンドを使⽤することで、リソースエージェントのライブラリなども同時にインストールされます。
インストールが完了したら、クラスタ制御部（Corosync）とリソース制御部（Pacemaker）それぞれの設定を⾏います。
まずはクラスタの基本的な動作設定を⾏います。
/etc/corosync/corosync.conf という設定ファイルにクラスタの定義やハートビート（死活監視）の設定などを記述します。設定ファイルを作成したら、もう 1 台のマシンに SCPなどで転送して同じディレクトリに配置します。

115
https://linuc.org/

compatibility: whitetankaisexec { # 実⾏ユーザーとグループの設定
user: rootgroup: root}
service {name: pacemaker # 使⽤するクラスタ
ver: 0 # バージョン番号}
totem { # ハートビート（死活監視）の通信⽅法の指定
version: 2 # 設定ファイルのバージョン
secauth: off# メッセージの認証に HMAC/SHA1 認証使⽤の有無

threads: 0 # 認証に使⽤するスレッド数
rrp_mode: none # 冗⻑リングのモード
clear_node_high_bit: yes # nodeid の最⾼位を 0 にするか
token: 4000 # タイムアウト値
consensus: 10000 # 新しい構成のラウンドを開始するまでの待機時間
rrp_problem_count_timeout: 3000 # 障害カウンタに減算処理をするまでの時
間interface {ringnumber: 0 # 冗⻑リングの番号
bindnetaddr: 192.168.10.0 # ネットワークアドレス
mcastaddr: 226.94.1.1 # マルチキャストアドレス
mcastport: 5405 # マルチキャストで使⽤するポート}}
logging{ # ログの設定オプション
fileline: on # 表⽰されるファイルと⾏
to_syslog: yes # ログの出⼒先
syslog_facility: local1 # シスログのファシリティタイプ
syslog_priority: info # シスログのロギングレベル
debug: off # デバッグ出⼒を記録するか
timestamp: on # 全ログにタイムスタンプをつけるか}

116
https://linuc.org/

/etc/syslog.conf に先ほどの設定ファイルで指定したロギングの設定を追加します。local1について、/var/log/messages ではなく、/var/log/ha-log にログを記録するように設定しています。local.none は/var/log/messages にログを記録しない設定です。こちらも最初のマシンで設定を終えたら、もう 1 台のマシンに SCP などでファイルを転送しておきます。
*.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages
local1.* /var/log/ha-log

上記の設定を終えたら、クラスタを起動します。クラスタに属する各サーバー上で起動します。これでリソースエージェントによるサービスの死活監視、ハートビートによるアク
ティブ・スタンバイのフェイルオーバーが開始されます。
$ systemctl start corosync.service

corosync の動作を確認するには、1 台⽬のマシンの corosync を停⽌させ、オンラインのマシンが切り替わるか確認します。
まずは、2 台⽬のマシンで crm_mon を実⾏します。

[root@SRV2] crm_mon -AfroOnline: [ SRV1 SRV2 ]Full list of resources:
Resource Group: VM-1g
SRV1-VIP(ocf::heartbeat:IPaddr2):

SRV1-apache(lsb:httpd_vm1):

Started SRV1
Started SRV1

すると最初は 2 台ともオンラインと認識されています。
そして、1 台⽬の corosync を停⽌します。

117
https://linuc.org/

[root@SRV1]# service corosync stop
Signaling Corosync Cluster Engine (corosync) to terminate: [ OK ]Waiting for corosync services to unload:....

[ OK ]

そして、2 台⽬の crm_mon の表⽰を確認します。

Online: [ SRV2 ]OFFLINE: [ SRV1 ]Full list of resources:
Resource Group: VM-1g
SRV1-VIP(ocf::heartbeat:IPaddr2):

SRV1-apache(lsb:httpd_vm1):

Started SRV2
Started SRV2

すると corosync を停⽌した 1 台⽬のホストはオフラインになり、2 台⽬のマシンでApache が動作していることがわかります。

118
https://linuc.org/

LinuC レベル 2 Version 10.0 学習教材（新規追加出題範囲）
2021 年 4 ⽉ 1 ⽇ v1.0.2 版
LPI-Japan 発⾏
Copyright© 2021 LPI-Japan. All Rights Reserved.
119
https://linuc.org/