ELM製品をオンプレミスで使うとき、ELM製品の導入先サーバーを準備する必要があります。サーバースペックはユーザー数やユースケースにより異なりますが、考慮事項がガイドにまとめられています。
本記事では下記サイトの日本語訳を掲載します。
Sizing ELM deployments for 7.x releases
https://jazz.net/wiki/bin/view/Deployment/ELMSizingOverview71
はじめに
IBM Engineering Lifecycle Management（ELM）製品を利用するお客様は、新規ユーザーであれ熟練したエキスパートであれ、皆同じことを望んでいます。それは、導入した ELM 環境が性能面で足かせにならず、さらに利用規模の拡大にも追随できることです。そのような要望から、次のような基本的な疑問が生まれます。
- ELM を稼働させるために、どのようなハードウェアが必要か
- そのハードウェアに対して最適なデプロイメント・トポロジーは何か
- ある特定のハードウェア構成において、どの程度のユーザー数とデータ量をサポートできるのか
本記事では、IBM パフォーマンス・エンジニアリング・チームが実施した各種テスト結果や、多数の実際の顧客導入事例の分析をもとに、これらの疑問に答えます。
特定のハードウェア構成でどの規模のデプロイメントをサポートできるかを正確に見積もることは容易ではありません。というのも、ユーザーが具体的にどのような操作を行うかや、データ量に大きく依存するためです。そこで本記事では、標準的なマシンサイズ（メモリ、CPU）をいくつか定義し、それぞれについてサポート可能なおおよその同時接続ユーザー数およびリポジトリサイズを提示するというアプローチを取っています。
ここで示すガイダンスは、あくまで目安あるいは出発点として捉えてください。デプロイメントの成長に応じて、システムサイズやトポロジーの調整が必要になることを前提としてください。IBM は、システム利用状況の推移を把握するために、アプリケーション監視のベストプラクティスを活用することを強く推奨しています。これにより、デプロイメントの変更がいつ必要になるのかを事前に予測できるようになります。
パフォーマンスに影響を与える要因
システム仕様の詳細に入る前に、まずパフォーマンスに影響を与える一般的な要因について説明します。これらの要因を理解することで、後述するガイダンスの位置づけが明確になり、また、ご自身の環境に応じて調整が必要かどうかを判断する助けとなります。
主な要因は次のとおりです。
デプロイメント・トポロジー
何台のサーバーを配置するのか。また、それぞれのサーバーの仕様（メモリ容量、CPU 数、ディスク I/O の速度）はどうなっているか。
データ
デプロイメントの規模はどれくらいか（成果物の数や種類）。人の利用、カスタムスクリプト、あるいは外部連携によって成果物が作成されることで、どの程度の速度でデータが増加しているか。
アプリケーションの利用状況
- 同時にアクティブに利用しているユーザーは何人か。
- ユーザーはどのような操作を行っているか。
- 利用モデルに考慮すべき連携機能やカスタムスクリプトは存在するか。
- 新規ユーザーはどのくらいのペースでオンボーディングされているか。
ELM を初めて導入する場合は、まずデータ量とアプリケーションの利用状況を見積もることから始めてください。その見積もりをもとに、適切なデプロイメント・トポロジーを選択し、サーバーのサイジングを行います。将来的な成長を見越して、数年先までを想定した見積もりを行うことで、初期導入時から拡張に耐えられる構成にできます。
既存のデプロイメントを管理している場合は、稼働中のサーバーを監視し、過負荷になっているシステムがないかを確認するとともに、リポジトリのサイズを監視してください。これらの監視データは、サーバーサイズの調整や、デプロイメント・トポロジー変更の判断に役立ちます。
デプロイメント・トポロジーの影響
デプロイメント・トポロジーに関する詳細な情報は、標準デプロイメント・トポロジー概要ページを参照してください。主なデプロイメントタイプは次の 3 つです。
- 部門（デパートメント）トポロジー
IBM が本番環境でのデプロイメントに対して推奨する最小構成です。必要なハードウェアを最小限に抑えることができ、小規模なプロジェクトや小規模チームに最適です。 - エンタープライズ・トポロジー
中規模から大規模のチームに適した構成です。追加のサーバーに処理負荷を分散させることで、より多くのユーザーをサポートできるようになります。 - フェデレーテッド・トポロジー
製品ラインや組織部門ごとに ELM ソリューションを導入する非常に大規模な企業向けの構成です。一方で、プログラム全体として作業ポートフォリオを俯瞰できる共通ビューを維持することが可能です。
部門トポロジーでは、使用するハードウェアを削減する代わりに、データ量とユーザー規模の両方を抑える必要があります。そのため、利用可能な処理能力やメモリが限られており、サポートできるユーザー数も少なくなります。
エンタープライズ・トポロジーでは、各アプリケーションが専用のサーバー上で稼働します。これにより、追加のサーバーを配置することで処理能力とメモリの双方が拡張され、サポート可能なユーザー数やデータ量が増加します。
フェデレーテッド・トポロジーでは、共通要素を維持しながら、複数のエンタープライズ・トポロジーを組み合わせて導入します。追加サーバーの配備によって、さらに多くの処理能力とメモリを確保することができます。
プロセッサ数の影響
デプロイメントがサポートできるアクティブユーザー数に最も大きな影響を与える要因は、利用可能な CPU の数 です。
たとえば、ユーザーがブラウザー経由で ELM アプリケーションを操作し、UI 上で何らかの選択を行ってサーバー側の処理を実行する場面を想像してください。この操作には 1 つの CPU が使用されます。もし 200 人のユーザーが同時にサーバー上で処理を実行していた場合、理論上は 200 個の CPU が必要になります。サーバーに十分な CPU がない場合、CPU 使用率は 100% に達し、ユーザーの操作は遅くなります。
ただし、実際のユーザーは常に処理を実行し続けているわけではありません。画面上の内容を考えたり、コーヒーを取りに行ったり、会議に出席したりします。そのため、200 人のアクティブユーザーがいるからといって、必ず 200 個のプロセッサが必要になるわけではありません。これはあくまで最悪ケースの話です。それでもなお、アクティブユーザーが増えれば、それに応じてより多くの CPU が必要になるという基本原則は成り立ちます。
特別なケースとして、アプリケーション・プログラミング・インターフェース（API） を通じてシステムにアクセスするユーザーが挙げられます。API を利用してデプロイメントと連携するコードを開発すると、そのコードは実際のユーザー操作よりも大きな負荷をデプロイメントに与えます。サイジングの観点では、API ユーザー 1 人は、実ユーザー 20 人分に相当するものとして考えてください。詳細については、「統合および API」に関するセクションを参照してください。
CPU を増やす方法には、主に次の 3 つがあります。
- 個々のサーバーに搭載するプロセッサ数を増やす
- アプリケーションをそれぞれ専用サーバーに分離し、結果としてマシン数を増やすことで、利用可能なプロセッサ総数を増加させる
- アプリケーションをクラスタリングし、複数のクラスタノードを構成することで、利用可能なプロセッサ数を増やす
メモリの影響
ELM デプロイメントの信頼性に最も大きな影響を与える要因は、利用可能な RAM です。メモリが不足すると、アプリケーションがハングしたり、クラッシュしたり、動作が著しく遅くなる可能性があります。
ELM サーバーでは、主に次のようなメモリ消費要因を満たすだけの十分な RAM を割り当てる必要があります。
- アプリケーションを実行する Java 実行環境（JRE）のヒープメモリ
- Java 実行環境が使用するネイティブメモリ （特にファイル転送を伴うネットワーク処理では重要）
- オペレーティングシステムが使用するメモリ
- JVM のヒープサイズが不十分であったり、適切にチューニングされていない場合、ガベージ・コレクションによってシステム性能が低下することがある
- メモリ需要が過剰になると、オペレーティングシステムのファイルキャッシュが縮小し、アプリケーションサーバー上にローカル保存されているデータのキャッシュ効率に影響を与える
- メモリ使用率が高くなるとディスクへのスワップが発生し、これがパフォーマンス低下の原因となる
データ（リポジトリサイズ）の影響
リポジトリのサイズはパフォーマンスに影響を与え、良好な性能を実現するために必要となるハードウェア要件にも影響します。ここでいうリポジトリサイズには、次の 2 つの側面があります。
- 各成果物タイプの数 （例：作業項目の数、テストケースの数、要件の数など）。これがリポジトリの「サイズ」です。
- 成果物の構造と、それらの間の関係性 （例：作業項目が開発計画に関連付けられる、テストケースがテスト計画に関連付けられる、要件がモジュールに追加される、成果物同士がリンクによって参照し合うなど）。これがリポジトリの「形状（シェイプ）」です。
- 全文検索インデックス（成果物検索に使用）は、成果物が増えるにつれて大きくなります。全文検索インデックスに関連するファイルをキャッシュするために、より多くのメモリが必要になります。
- データを格納する データベース表 は、成果物数の増加に伴って拡大します。データベースが大きくなるほど、データベースサーバーにはより多くのメモリが必要になります。
- Java のネイティブメモリ（特にダイレクト・メモリ・バッファ）は、Web アプリケーションサーバーがネットワーク経由でブラウザー（または EWM Eclipse クライアント）に情報を送信する際に使用されます。EWM のソースコード管理機能は、ソースファイルのサイズ、ワークスペース内のファイル数、ワークスペースの更新頻度（ビルドなどによる更新）の影響を特に受けやすい傾向があります。
- Java ヒープメモリ は、ELM の各種操作を実行するために使用されます。リポジトリが大きくなると、サーバーからクライアントへ転送されるデータ量が増え、それに伴い ELM アプリケーションサーバー側で必要となるメモリも増加します。Java ヒープへのメモリ要求が増えると、ガベージ・コレクションの発生頻度が高まり、パフォーマンスが低下する可能性があります。また、大量の結果セットを返すレポート実行時などには、一時的に非常に高いメモリ使用量が発生することもあります。
ELM デプロイメントのサイジング
本記事で採用しているサイジング手法では、次の 2 つの観点からなる簡略化したモデルを使用しています。
- デプロイメント規模
- マシンサイズ
これらの各観点は大まかな区分（バケット）に分けられており、各製品ごとに、デプロイメント規模に応じたマシンサイズが割り当てられています。デプロイメント規模は次のように定義されます。
| Size | Active Users | Total Database size |
|---|---|---|
| Small | 10 | Up to 50G |
| Medium | 10-250 | Up to 250G |
| Large | 250-500 | Up to 1TB |
| Extra-large | >500 | >1TB |
アクティブユーザーとは、システムと実際にやり取りを行い、アプリケーションに対してリクエストを送信しているユーザーのことを指します。一方、登録ユーザーとは、システムへのアクセス権を持つユーザーのことです。
サイジングにおいて重要なのはアクティブユーザー数であり、登録ユーザー数はそれよりもはるかに多くなる可能性があります。登録ユーザーは、実際にアクティブになるまでシステムリソースを消費しません。
アクティブユーザーの定義には、スクリプトや自動化処理で使用されるユーザー ID は含まれません。スクリプトは、通常、実際の人の操作よりもはるかに大きな負荷をシステムに与えるためです。計画策定の観点では、API ユーザー 1 人を実ユーザー 20 人分として扱ってください。
これらのサイジング区分はアプリケーションごとに適用されます。例えば、
EWM の中規模デプロイメントでは、最大 250 ユーザーと、最大 250GB の EWM データベースをサポートできます。
ETM の大規模デプロイメントでは、最大 500 ユーザーと、最大 1TB の ETM データベースをサポートできます。
1 つのデプロイメント内で、中規模の EWM サーバーと大規模の ETM サーバーを併存させることも可能です。
標準的に使用されるサーバーサイズは次のとおりです。
- 2 vCPU / 4GB RAM
- 4 vCPU / 8GB RAM
- 8 vCPU / 16GB RAM
- 16 vCPU / 32GB RAM
- 48 vCPU / 96GB RAM
- 64 vCPU / 128GB RAM
- JTS: Jazz Team Server
- JAS: Jazz Authorization Server
- GCM: Global Configuration Management
- EWM: Engineering Workflow Management
- ERM: Engineering Requirements Management DOORS Next
- ETM: Engineering Test Management
- DCC: Data Collection Component（Jazz Reporting Service の一部）
- RB: Report Builder（Jazz Reporting Service の一部）
- LQE rs: Lifecycle Query Engine（リレーショナル・ストア）
- LDX rs: Link Index Provider（リレーショナル・ストア）
- PUB: PUB Document Builder
- ENI: Engineering Lifecycle Optimization – Engineering Insights
エンタープライズ・トポロジーのサイジング
IBM では、エンタープライズ・トポロジーにおいては、各アプリケーションを専用サーバーに配置することを推奨しています。各アプリケーションサーバーに対する推奨サイジングは、以下の表に示されています。
これらのサイジングの背後にある考え方は次のとおりです。
- アクティブユーザー数が増えるほど、より多くの vCPU が必要になる
- データ量が増えるほど、より多くの RAM が必要になる
- データベースはすべてのサーバーから使用されるため、より大きな構成が必要になる
- デプロイメントが成長するにつれて、データベースにはより多くのメモリが必要になります。
- 大規模なデプロイメントでは、複数のデータベースサーバーを用意することを計画してください。
- 7.1 では、LDX および LQE サーバーはデータの保存先としてデータベースサーバーを使用します。ただし、インデックス作成のためには引き続きメモリが必要です。IBM では、レポーティングとリンクインデックスの両方をサポートするために 単一の LQE rs システムを使用することを推奨しており、そのため LQE rs サーバーは他のサーバーよりも大きな構成となります。
- 超大規模（Extra-large）デプロイメントでは、EWM および ETM サーバーをクラスタ構成にする必要があると想定してください。また、リポジトリの成長に伴い、ERM サーバーを複数配置する必要が生じる場合もあります。
- Jazz Authorization Server は、さほど多くのリソースを必要としません。
- 冗長性確保のために複数のプロキシサーバーが必要になる場合や、高いユーザー負荷に対応するためにより多くの vCPU が必要になる場合があります。 8 vCPU を搭載した単一のプロキシサーバーでは、1 秒あたり 500～1000 トランザクション程度の処理レートで過負荷になる可能性があります。
複数のアプリケーションを 1 台のサーバー上でホストする必要がある場合は、各アプリケーションごとの vCPU 要件とメモリ要件を合算した値を、そのサーバーに適用してください。
例えば、小規模デプロイメントにおいて ETM と EWM を同一サーバーでホストする場合、8 vCPU および 16GB の RAM が必要になります。
部門（デパートメント）トポロジーのサイジング
部門トポロジーでは、使用するサーバー台数を抑え、1 台のサーバー上で複数のアプリケーションをホストします。IBM では、このトポロジーは小規模および中規模デプロイメントにのみ使用することを推奨しています。
サイジングにあたっては、エンタープライズ・トポロジーで示されているサイジング見積もりを基準とし、同一サーバー上でホストする各アプリケーションの vCPU および RAM 要件を合算してください。
標準的な部門トポロジーにおけるシステム要件は、次のとおりです。
ここで「Apps」とは、単一サーバー上でホストされる ELM アプリケーション群を指しており、具体的には次のコンポーネントが含まれます。
- EWM
- ETM
- ERM
- JTS
- ENI
- PUB
- GC（GCM）
検証（PoC）環境のサイジング
概念実証（Proof of Concept：PoC）または評価目的のトポロジーは、超小規模（Extra‑small）デプロイメント向けに使用できます。
- 同時接続ユーザー数が 合計 10 人未満
- 成果物数が 合計 100,000 個未満
IBM では、PoC の取り組みにおいては 部門（デパートメント）トポロジーを使用することを強く推奨しています。これは、ユーザー負荷が低くても、リポジトリサイズが比較的短期間で急激に増加する可能性があるためです。部門トポロジーを採用することで、PoC の実施中にスケーラビリティの問題を回避するために十分なリソースを確保できます。
PoC の規模を小さく維持する場合は、次のシステムサイズを使用できます。
| Application | vCPU | RAM |
|---|---|---|
| JTS | 2 | 4 |
| JAS | 2 | 4 |
| Apps | 8 | 24 |
| DCC | 4 | 8 |
| LQE/LDX rs | 8 | 16 |
| Proxy | 2 | 4 |
| Database | 4 | 12 |
さらに、推奨はされませんが、アプリケーションを追加で統合し、3 台構成のシステムにまとめることも可能です。
| Application | vCPU | RAM |
|---|---|---|
| JTS/JAS/Apps/Proxy | 8 | 32 |
| DCC/LQE/LDX rs | 8 | 32 |
| Database | 4 | 12 |
ストレージ
ストレージ要件を検討する際には、次の 2 つの要素を考慮する必要があります。
- 各アプリケーションにどれだけのディスク容量が必要か
- そのストレージはどの程度の速度が必要か
成果物数とリポジトリサイズ
本サイジングモデルは、アプリケーションデータベースのサイズを基準としています。新規デプロイメントを計画している場合は、成果物数を見積もる方が容易かもしれません。
目安として、成果物 100 万件あたり 50GB のデータベース容量が必要です。構成管理を有効にしている場合は、100 万バージョンあたり 50GB と見積もってください。これは ETM、EWM/RMM、ERM に適用されます。
LQE rs（および LDX rs）は、すべてのアプリケーションからデータを読み取るため、より多くのディスク容量を必要とします。また、構成（ストリームやベースライン）ごとのバージョン情報も保持するため、必要容量は「構成あたりのバージョン数 × 構成数」に依存します。
LQE rs のデータベースサイズは、次の目安で見積もってください。
- インデックス対象リソース 100 万件あたり 12GB
- 構成用に追加されるバージョン 100 万件あたり 0.5GB
Jena を使用する旧コンポーネント
一部の旧バージョンのコンポーネントでは、Jena 技術に基づくトリプルストア・データベースが使用されており、成果物の増加に伴ってサイズが拡大します。特に影響を受けやすいコンポーネントは次のとおりです。
- Lifecycle Query Engine（7.0.3 より前）
- Link Index Provider（LDX、7.1 より前）
これらのコンポーネントは現在ではリレーショナルストアに移行されているため、以下の内容は旧バージョンにのみ適用されます。
トリプルストアは、クエリー最適化のために OS のファイルシステムキャッシュを利用します。十分な空き RAM があればインデックスをメモリに保持できますが、他のアプリケーションが RAM を必要とすると、キャッシュは縮小されます。
目安として、次の合計をもとに必要 RAM を見積もります。
JVM 最大ヒープサイズ
インデックスのディスクサイズ
上記に加えて OS オーバーヘッドとして 4GB
大規模／超大規模デプロイメントでは、LQE または LDX の Jena インデックスを完全にキャッシュするために 1TB を超える RAM が必要になる場合もあります。
データベースサーバーに関する考慮事項
リポジトリが成長するにつれて、データベースサーバーはより多くの RAM の恩恵を受けます。Oracle および Db2 は、メモリを使ってデータをキャッシュするため、RAM が多いほど SQL クエリーの性能が向上します。
1 台のデータベースサーバーを複数の ELM アプリケーションで共有している場合、データベースのメモリ需要は、すべてのアプリケーションサーバーの 合算負荷 によって決まります。
EWM、ETM、ERM など複数アプリケーションで数百万件の成果物を扱う場合、64GB 以上のメモリを搭載したデータベースサーバーを推奨します。
大規模／超大規模デプロイメントでは、756GB 以上のメモリや複数のデータベースサーバーが必要になることもあります。
連携（Integrations）と API
ELM スイートは、カスタムアプリケーションから連携可能な API を提供しています。API の使い方によっては、ELM デプロイメントに非常に大きな負荷を与える可能性があります。
スロットリングなしでマルチスレッドで API を呼び出すカスタムアプリケーションは、実ユーザー 1000 人分に相当する負荷を簡単に発生させることがあります。
IBM は、API 利用に関するガバナンスプロセスの導入を推奨しています。
具体的な推奨事項：
- API ベースのツールの棚卸しを行い、それぞれの負荷を把握する 不明な場合、API スレッド 1 本＝実ユーザー 20 人分 と見積もる
- 各ツールを「高負荷シナリオ」として登録・監視する
- 本番同等データを使用した負荷試験をテスト環境で実施する
- 連携導入を管理する 変更管理委員会（CCB） を設置する
- システム状況に応じて負荷を制御できる スロットリング を実装する
Data Collection Component（DCC）
Data Collection Component は、デプロイメント規模の影響をあまり受けません。固定スレッド数で動作し、同時ユーザー負荷を処理しないためです。通常は 4 vCPU / 8GB RAM で十分です。
スレッド数を増やした場合や、追加のデータソースをインデックス化する場合は、最大 8 vCPU / 16GB RAM が必要になることがあります。
クラスタリング
500 ユーザーを超える超大規模デプロイメントでは、クラスタリングを検討してください。
ELM 7.1 でクラスタリングがサポートされているのは次のコンポーネントです。
- Engineering Test Management
- Engineering Workflow Management（Rhapsody Model Manager 含む）
- Jazz Authorization Server
- Oracle（RAC）および Db2（PureScale）
ELM のクラスタリングには、次の 2 つの追加コンポーネントが必要です。
- DCM（Distributed Cache Manager）
- Eclipse Amlen
| Size | DCM | Amlen |
|---|---|---|
| Large | 8 vCPU, 8G RAM | 1 instance: 8 vCPU, 16G RAM, 64G disk |
| Extra Large | 16 vCPU, 16G RAM | 2 instances: 8 vCPU, 16G RAM, 64G disk |
Eclipse Amlen の詳細なサイジング情報は別資料を参照してください。
なお、ELM の他のコンポーネントはクラスタリングをサポートしていませんが、以下のように インスタンスを追加して負荷分散することは可能です。
- ERM サーバーの追加
- Report Builder インスタンスの追加
- 一部アプリケーション向けに LQE / LDX サーバーを追加
ネットワーク
本サイジングモデルでは、ネットワーク要件は扱っていません。以下が前提条件となります。
- すべてのサーバーが単一データセンター内にあり、低遅延（例：1ms 未満）
- 十分なネットワーク帯域が確保されている
- 高い QoS（パケット再送なし）
- 通信を妨げるネットワーク機器が存在しない
オペレーティングシステム
Windows か Linux かの選択は、サイジング推奨値に影響しません。