OSSVERTとは

OSSセンタでは，NTTグループの

OpS（Operation Support System）

や情報系システムで，もっとも利用頻

度の高いWeb３層システム構成＊１に

着目し，OSS（Open Source Soft-

ware）からなるリファレンスモデル

（モデル）＊２を設計・構築し，組合せ

検証を行い，構築手順や検証データな

どのノウハウをドキュメントにまとめ提

供してきました．OSSVERT（OSs

Suites VERified Technically） と

は，モデルやドキュメントも含め，OSS

の利用を支援するためのノウハウを指

します．OSS利用のメリットは，シス

テム構築・運用コストの削減だけでな

く，ベンダロックイン＊３の回避，ソー

スコードが公開されており，OSSセン

タからのサポートが継続して受けられ

ることなどが挙げられます．さらに

OSSVERTのように，あらかじめ検証

済みの推奨構成や設定を利用すること

で，OSSの選択や最適な組合せを検討

する手間を省くことができ，OSSを用

いたシステム設計・構築の効率化が期

待できます．

これまでの取り組み

OSSVERTで想定するシステムの要

件は，図１に示すようにクライアント

の同時接続数が5 000以上，データ規

模が数100 GBで，稼動率99.99％

程度の可用性を想定しており，サー

バやネットワーク機器の冗長化され

た，単一障害点のない構成を基本とし

ています．Web３層システムの主な

ソフトウェア構成として，各サーバの

OSには共通してRHEL（Red Hat

Enterprise Linux）＊４を採用し，LB

（ロードバランサ）/Webサーバには，

LB UltraMonkey＊５， Webサーバ

オープンソフトウェアにかかわる最新の取り組み

NTT技術ジャーナル 2011.88

オープンソースソフトの導入を支援するOSSVERTの拡張

クライアント

LB/Webサーバ

APサーバ

DBサーバ

主な構成ソフトウェア

主なシステム要件 ・性能　　：クライアント同時接続数 5 000以上 ・可用性　：稼動率 99.99％

図１　リファレンスモデルの構成と要件

ACT SBY

UltraMonkey

RHEL

アプリケーション

Tomcat/JBoss

OpenJDK

RHEL

PostgreSQL/MySQL/Oracle

Heartbeat/Pacemaker

RHEL

Apache mod_ jk

OSSセンタでは，OSSからなるシステムの設計・構築，組合せ検証を事前に行うことで，OSSを適用する際の課題を取り除く活動をしてきました．現在は，これまでの成果を最新化しつつ，サーバ統合を実現する仮想化モデルや運用監視モデルの追加を行っています．

と よ だ ひろはる おくむら まさかず

豊田 裕晴　/奥村 昌和すみ りゅういち

角　 隆一

NTT研究企画部門

リファレンスモデル サーバ統合 運用監視

＊1 Web３層システム構成：クライアントサーバシステムを「プレゼンテーション層」「アプリケーション層」「データ層」の３層に分割して構築したシステム．

＊2 リファレンスモデル：あらかじめ定義した要件に基づくリファレンス実装．

＊3 ベンダロックイン：ある特定のメーカや販売会社がユーザを自社製品で囲い込むこと．

＊4 RHEL：Red Hat社が開発・提供している企業向けの商用Linuxディストリビューション．

特集

NTT技術ジャーナル 2011.8 9

Apache＊６，Webサーバコネクタ

mod_jk＊７を採用，AP（アプリケー

ション）サーバは，Tomcat＊８，もし

くはJBoss＊９，Java実行環境には

Open JDK＊10を採用，さらにDB（デー

タベース）サーバには，クラスタソフ

トとして，Heartbeat＊11，あるいは

Pacemaker，DBMS（DataBase

Ma n a g eme n t S y s t em） に は

Pos tgreSQL＊12，あるいはMySQL

などを採用しています．

OSSVERTでは，インターネット上

の書店を模擬したベンチマークアプリ

ケーションを利用し，テストベッドを

用いた実機による性能測定を行ってい

ます．システムを構成する個々のOSS

の機能検証の後，OSSを組み合わせた

モデル構成で，表１に示す①基本動

作，②障害発生時のサービス継続性，

③最大性能，および④長時間運転時

の安定性などを主な観点として検証を

行い，商用環境で安心して使えるかど

うかを判断するとともに，表２に示す

ドキュメントに検証結果やノウハウを

まとめています．

図２は，サービス継続動作検証の一

例です．APサーバにネットワークイン

タフェースのハードウェア擬似障害を

発生させるサービス継続動作検証を実

施したところ，しばらく性能が改善し

ない不具合を摘出しました．原因であ

るWebサーバコネクタmod_jk1.2.27

の採用を見送り，コミュニティに対し

てフィードバックを行うとともに，不

具合の改修が行われるまで前版の

mod_jk1.2.22を継続して推奨とする

措置をとりました．これは，OSSVERT

表２　提供内容一覧

項番

１

２

３

４

５

ドキュメント 内容

モデル概要書

インストール手順書

環境定義書

検証報告書

ノウハウ

システム要件

OSSをサーバにインストールするための手順

OSSの各種設定パラメータの設定指針，および推奨値

各種検証の結果と測定データ

設計・構築・検証を通じて得られたノウハウ

表１　OSSVERTにおける主な検証項目一覧

項番

1-1

1-2

1-3

2-1

2-2

2-3

2-4

2-5

2-6

2-7

2-8

3

4

大項目 中項目

基本動作検証

サービス継続動作検証

長時間運転検証

性能検証

アプリケーション基本動作確認

Webサーバ負荷分散動作確認

APサーバ負荷分散動作確認

LB/Webサーバ（1 台）障害時のサービス継続動作確認

LB/Webサーバ（1 台）障害時のサービス継続動作確認

APサーバ（1 台）障害時のサービス継続動作確認

DBサーバ（1 台）障害時のサービス継続動作確認

最大性能値の測定

LBソフトウェア障害

48時間連続運転検証

LBハードウェア障害

Webサーバソフトウェア障害

Webサーバハードウェア障害

APサーバソフトウェア障害

APサーバハードウェア障害

DBサーバソフトウェア障害

DBサーバハードウェア障害

＊5 Ultra Monkey：Linuxオペレーティングシステム上でオープンソースのコンポーネントを使用して，ローカルエリアネットワークの負荷分散と高可用性サービスを実現するためのプロジェクト．

＊6 Apache：Apache Software Foundationが開発しているHTTPサーバソフトウェアの名称．

＊7 mod_jk：ApacheとTomcatを連携するためのモジュール．

＊8 Tomcat：Jakartaのプロジェクトとして開発されているOSS.

＊9 JBoss：J2EEアプリケーションサーバもしくはJavaによるOSSの総称．

＊10 OpenJDK：Sun MicrosystemsのJDKから派生したオープンソースのJDK．

＊11 Heartbeat：プライマリシステムの万一の障害に備えた冗長構成環境において，システムの状態を監視し，障害を検出した後に予備のシステムへ切替えを行うOSSミドルウェア．

＊12 PostgreSQL：オープンソースのオブジェクトリレーショナルデータベース管理システムの１つ．

の取り組みにより，不具合を見つけ，

トラブルを未然に防いだ１つの例です．

モデル開発後は，OSSのバージョン

アップに伴う追検証を定期的に行い，

最新化を図っています．ここ５年間の

主な変更として，図３に示すようにOS

は，RHEL４から５へ，Java実行環

境は，商用製品のOracle JDK（Sun

JDK）からOSSのOpenJDKへ，DB

サーバは，PostgreSQL８から９へ，

クラスタソフトは，商用製品の

Matr ixHA＊13から，OSSのHear t -

beat，さらに後継のPacemakerへの

移行を進めるなど，機能拡張や安定化

とともに，利用導入のしやすさからフ

ルオープンソース化の促進を進めてき

ました．

2011年３月の時点で，Web３層シ

ステム構成を中心に，16のモデルを開

発し，延べ200を超えるNTT社内シス

テムへのOSSの適用にあたり，ノウハ

ウを活用していただいています．

現状の課題

ICT環境を取り巻く変化として，コ

ストの最適化や経営環境の変化に柔軟

に対応するため，クラウドコンピュー

ティングの導入が進みつつあります．現

在は，市販製品によるクラウド環境の

構築が主ですが，OSSのメリットを活

かした低コストで柔軟性のあるクラウ

ド環境の構築についてもニーズが増え

ています．このような背景のもとに，要

素技術として，サーバ統合を実現する

方式や手順の確立が求められています．

一方，複数のOSSにより構成された

システムの運用にあたっては，個々の

OSSの運用方法だけでなく，システム

全体を統合的に監視する仕組みが求め

られています．

オープンソフトウェアにかかわる最新の取り組み

NTT技術ジャーナル 2011.810

APサーバ ハードウェア障害発生

検証条件 　APサーバハードウェア障害 　（ネットワークインタフェースの停止）

mod_jk 1.2.22を適用

負荷

図２　サービス継続動作検証の一例

正常動作 （仕掛かり中のコネクションのみ影響）

mod_jk 1.2.27を適用

障害発生後，タイムアウトまで の一定時間，スループット， レスポンス時間が低下

スループット

Ｗｅｂインタラクション（ＷＩ）

レスポンス時間

14個のWebインタラクション レスポンス時間

2 000

1 500

1 000

500

0

10 000

5 000

0

スループット

Ｗｅｂインタラクション（ＷＩ）

レスポンス時間

14個のWebインタラクション レスポンス時間

2 000

1 500

（ms） （WIPS）

0 5 10 15 20 25 30 35 （ms） （WIPS）

1 000

500

0

10 000

5 000

0

UltraMonkey （ACT）

LB/Webサーバ１号機

APサーバ１号機

DBサーバへ

LB/Webサーバ２号機

Apache

mod_jk

Tomcat

UltraMonkey （SBY）

APサーバ２号機

Apache

mod_jk

Tomcat

スループット

スループット

時間（min）

＊13 MatrixHA：NTTコムウェアと米Poly Serveが開発したクラスタソフトウェア．複数のコンピュータを組み合わせてシステムを構成することで，どれか１つのノードに障害が発生しても，システム全体のダウンを防ぎ高可用性を実現．

特集

NTT技術ジャーナル 2011.8 11

次に，これらの課題も踏まえた最新

の活動におけるトピックを紹介します．

仮想化モデルの追加

KVM（ Kernel-based Virtual

Machine）などの成熟しつつあるOSS

の仮想化ソフトウェアを用いて，複数

のAPサーバを１台の物理サーバ上に統

合した構成を実現しました．これは新

たに，もしくはサーバ更改等のタイミ

ングで，異なる業務APサーバを１台の

物理サーバ上に統合し，サーバ台数を

削減するケースを想定しています．

仮想環境における検証では，これま

での観点に加えて，物理サーバ上の仮

想マシン（VM: Virtual Machine）

の集約数を増やしていった場合の仮想

化処理のオーバヘッドの測定やCPU資

源の割り当ての方針の違いによる性能

傾向の測定，突発的な高負荷を避け

るための各仮想マシン上の起動サービ

スのスケジューリング方針の調査など

を行い，仮想環境でOSSシステムを設

計・構築・運用する際のノウハウや留

意点をまとめています．

図４は，KVMを適用し，３台の仮

想マシンを作成し，異なるAPサーバを

１つの物理サーバ上に統合した構成例

です．APサーバには，Tomcatを採用し

ており，冗長構成＊14（ACT－ACT構

成）をとっています．

今回は，APサーバのハードウェアと

して，IBM社のx3650M3〔CPU

Intel社Xeon E5630×２枚（８コア

PostgrePostgreSQL9

構成品 UltraMonkey-L4

Apache

mod_jk

Tomcat5 Tomcat6

JBoss4 JBoss5

OracleJDK（SunJDK）（商用製品）

PostgreSQL8

Oracle10g（商用製品）

MartixHA（商用製品）

MySQL5

PostgreSQL9

2006 2007 2008 2009 2010

図３　主な構成ソフトウェアの変更

OpenJDK

Heartbeat

RHEL4

RHEL5

年度

LB

Web サーバ

Java 実行環境

DBMS

クラスタ

OS

APサーバ

Webサーバ コネクタ

UltraMonkey-L7

Pacemaker

＊14 冗長構成：障害対策などのために，通常の運用で必要なシステム以外に予備のシステムを加え，バックアップできるようにした構成．

LB/WebRHEL

LB/WebRHEL

図４　仮想化モデルの構成例（AP層の統合）

ACT─ACT構成

仮想化の範囲

VM＃１ VM＃２

…

…

VM＃３ VM＃１ VM＃２ VM＃３ APLTomcat

DB＃１ PostgreSQLRHEL

DB＃３ PostgreSQLRHEL

RHEL

APLTomcatRHEL

KVM KVM

SBY

APLTomcatRHEL

APサーバ １号機

APサーバ ２号機

…

共有ストレージ

DB１ DB３

オープンソフトウェアにかかわる最新の取り組み

NTT技術ジャーナル 2011.812

構成）〕を利用しましたが，このような

ハードウェア条件では，APサーバ３台

を集約した構成で，３つのシステムご

とに性能要件（クライアントの同時接

続数が5 000以上）を十分に満たすこ

とを確認しています．

また，サービス継続動作検証の１つ

として，仮想マシンVM＃１に擬似障

害を発生させた際（仮想マシンゲスト

障害）のVM＃２，およびVM＃３

のサービスへの影響を調べました．図

５に示すように，障害発生時には瞬間

的に，Webインタラクションのレスポ

ンス時間の増大とともに性能値が劣化

しますが，VM＃１の２号機への縮退

により，サービスが継続されているこ

とが分かります．仮想マシン間の影響

を極小化するため，仮想CPUを固定

的に物理コアに割り当てる設定では，

ある仮想マシンに障害が発生した場合

も同じ物理サーバ上で動作するほかの

仮想マシンには影響がないことが確認

できました．

運用監視モデルの追加

これまでの検討対象は，Web３層

システムが中心でしたが，図６に示す

ように監視サーバと組み合わせ，既存

のOSSVERT構成について稼動状況を

監視できるようにしました．

運用業務の設計においては，まず監

視項目を調査し，運用要件に合った

監視方法を決める必要があります．

OSSVERTでは，検証で利用している

ハードウェアやシステムを構成す

るRHE L，A p a c h e，T om c a t，

PostgreSQLなどのOSSについて，あ

らかじめハードウェア障害監視，死活

監視，リソース監視，プロセス監視，

ポート監視，およびログ監視などの観

点で約600の監視項目を調査し，その

設定値を整理したものを，「推奨監視

項目一覧」にまとめています．実シス

テムの運用設計では，特定の監視ソフ

トウェアに依存することなく，推奨監

視項目一覧を雛形として利用可能で

あり，OSSに関する監視項目の調査や

検討の手間を省くとともに，OSSで構

成されたシステムの統合監視が可能と

なります．

APサーバVM＃１障害発生 APサーバVM＃１の障害復旧

検証条件 　仮想マシンVM＃１ 障害

図５　仮想環境におけるサービス継続動作検証の例

スループット

スループット

Ｗｅｂインタラクション（ＷＩ）

レスポンス時間

14個のWebインタラクション レスポンス時間

5005 10 15 20 25 30 35 40 450

400

300

200

100

0

スループット

500

400

300

200

100

0

スループット

500

400

300

200

100

0

5 000

4 000

3 000

2 000

1 000

（ms） （WIPS）

（ms） （WIPS）

（ms） （WIPS）

0

5 000

4 000

3 000

2 000

1 000

0

Ｗｅｂインタラクション（ＷＩ）

レスポンス時間

Ｗｅｂインタラクション（ＷＩ）

レスポンス時間

5 000

4 000

3 000

2 000

1 0000

システム＃１ 負荷

APサーバ１号機

（APサーバ１号機（物理サーバ）上で３つのVMが 稼動中に VM#１を強制終了）

システム＃２ 負荷

システム＃３ 負荷

VM＃１

APL

Tomcat

RHEL

VM＃２

APL

Tomcat

RHEL

VM＃３

APL

Tomcat

RHEL

KVM

スループット 　システム＃１

スループット 　システム＃２

縮退の仕掛かり中 のみ影響

影響なし

スループット 　システム＃３

影響なし

時間（min）

特集

NTT技術ジャーナル 2011.8 13

今後の取り組み

OSSVERTは，Web３層システム

の基本構成から，ICT環境を取り巻く

状況に合わせ，仮想化モデルや運用監

視モデルの追加など，拡張を図ってき

ました．今後は，図７に示すようにシ

ステムのライフサイクル全般をカバーで

きるように，構築だけでなく，初期検

討，設計，運用時においても活用でき

るノウハウへと拡張し，提供していき

たいと考えています．

さらに，クラウドなどの大規模運用

システムも新たなターゲットとして視野

に入れ，成熟しつつあるOSSの評価を

基に，モデル開発を行っていきたいと

考えています．

引き続き本特集では，OSSVERT

を支える基盤OSS関連技術や運用管

理ソリューションに対する取り組みと，

OSS分野における先進的な基盤技術

開発について紹介します．

■参考文献（1） 内川：“オープンソースを手際よく使うために

―― OSSVERTの取り組み，”NTT技術ジャーナル，Vol.19，No.3，pp.60-62，2007．

（左から）豊田 裕晴/ 奥村 昌和/

角 隆一

OSSVERTの拡張にあたっては，利用者の皆様のご意見が重要となります．OSS利用にあたり，ご要望などをフィードバックしていただけると幸いです．

◆問い合わせ先NTT研究企画部門OSSセンタTEL 03-5860-5055FAX 03-5463-5491E-mail contact oss.ntt.co.jp

No. 監視項目 監視単位 監視対象 マシン

監視項目 詳細

監視項目 （設定値）

監視 間隔

情報蓄積 間隔

障害レベル 警告レベル 回復レベル しきい 値 重要度

しきい 値 重要度

しきい 値 重要度

1 2 3 4 5 6 7 8 9 10

cpu. total cpu. system cpu. user cpu. steal cpu. iowait physical swap in out total

300 300 300 300 300 300 300 300 300 300

600 600 600 600 600 600 600 600 600 600

90 90 90 90 90 90 90 500 500 500

3 3 3 3 3 3 3 3 3 3

4 4 4 4 4 4 4 4 4 4

80 80 80 80 80 80 80 450 450 450

5 5 5 5 5 5 5 5 5 5

50 50 50 50 50 50 50 400 400 400

各サーバ共通 Linux監視

CPU使用率 CPU識別

メモリ使用率 メモリ識別

ページIO回数 IO種別

図６　運用監視構成の一例

「推奨監視項目一覧」の例

Crane Agent

Crane Agent

Crane Agent

約600項目 ・各リソースごとの監視項目の規定 ・しきい値やメッセージトラップの設定指針を整理 ・仮想環境における資源も監視対象

監視対象（既存のOSSVERT）

監視サーバ 監視コンソール

LB/Web サーバ

APサーバ

DBサーバ Crane Agent

Crane Manager

Crane Console

※　NTT情報流通プラットフォーム研究所開発の運用統合 　ソフトウェアCraneとの組み合わせの例

マイグレーション ツール等

バックアップ・ 故障対応 運用支援等

初期検討・システム設計 運用・保守 構築

Web３層モデル

図７　OSSVERT の拡張

クラウド等の 大規模システム運用モデル

拡張

拡張

OSSソリューション

従来のOSSVERT拡張