Cognos クラウドのベスト・プラクティス: パフォーマンスとスケーラビリティーに応じたアーキテクチャーのサイズ変更

IBM Cloud に対して Cognos の大規模なデプロイメントをするためのベスト・プラクティスと推奨案

Cognos 8® は高度な製品と機能を 1 つのセットにしたものです。そんな Cognos 8 のアーキテクチャーの規模を変更するのは、システム全体で予測される作業負荷について理解していることが要求される難しいタスクとなります。したがって、要件に合うように Cognos 8 のアーキテクチャーを適切にカスタマイズするには、アーキテクチャーに対する処理を何度か繰り返す覚悟でいてください。この記事では、IBM Cloud (IBM Smart Business Development and Test on the IBM Cloud) に対して Cognos 8 の大規模なデプロイメントをするための一般的な指針とアーキテクチャーに関する推奨案を説明します。

Stephan Jou, Technical Architect, IBM Australia

Stephan Jou は、IBM Business Analytics 部門 Office of the CTO の Technology and Innovation チームの技術アーキテクト、研究スタッフ・メンバー、およびシニア技術スタッフ・メンバーとして働いています。Cognos ソフトウェアにおける経歴では、初期リリース製品の設計を担当し、データ・マイニング、ニューラル・ネットワーク、可視化、ダッシュボード、可動性、およびセマンティック検索を実現したという意味で、開発および製品化を主導しました。IBM での現在の任務は、学術研究および IBM の研究を Cognos および SPSS ソフトウェアの製品戦略につなげることです。彼は、University of Toronto で計算論的神経科学と生体工学の理学修士号、およびコンピューター・サイエンスと人間生理学の二重学位を取得しました。



William Lee, Senior Software Consulting Engineer, IBM Australia

William Lee は、IBM の Cognos 買収後、IBM でシニア・ソフトウェア顧問エンジニアとして働いています。彼は IBM Business Analytics 部門 Office of the CTO の Technology and Innovation チームの一員として、Cognos および SPSS ソフトウェア製品の技術ビジョンと方向性の定義を支援しています。1992年に IBM に入社して以来、Cognos に取り組んでいます。彼はカナダ・オタワ州の Carleton University でコンピューター・サイエンスの理学士号と修士号を取得しました。



Thanh Pham (thanhp@us.ibm.com), Solution Architect, IBM

Thanh Pham は、IBM Information Management Advanced Technology に所属するソリューション・アーキテクトです。現在は、IBM Mashup Center 製品および IBM クラウド・コンピューティングを使用したアプリケーション構築のための顧客支援を重点に取り組んでいます。この任務の前は、ECM/Filenet Business Process Framework のアーキテクトを担当していました。



Biraj Saha, Advisory Software Developer, IBM Australia

Biraj Saha は IBM Cognos の顧問ソフトウェア開発者で、Cognos Framework Manager、Cognos Metrics Designer、Cognos Architectなどのモデリング・ツールのメタデータとアルゴリズムの設計および開発、そして Cognos 8 BI Server の SOA および SDK 開発を専門としています。2000年までは、EDS Systemhouse のシニア・ソフトウェア・エンジニアとして、ERP および RDBMS ベンダー・アプリケーションの変換、カスタム Java™、C++、ストアード・プロシージャー、4GL アプリケーションを初めとする多種多様な RDBMS 関連の開発において、広範な顧客の開発プロジェクトを主導してきました。彼はカナダの University of New Brunswick でコンピューター・サイエンスの学士号を取得し、カナダのUniversity of Waterloo ではオブジェクト指向データベースの制約理論を専攻してコンピューター・サイエンスの修士号を取得しました。



2010年 8月 31日

Cognos 8 は高度な製品と機能を 1 つのセットにしたものです。そんな Cognos 8 のアーキテクチャーの規模を変更するのは、システム全体で予測される作業負荷について理解していることが要求される難しいタスクとなります。したがって、要件に合うように Cognos 8 のアーキテクチャーを適切にカスタマイズするには、アーキテクチャーに対する処理を何度か繰り返す覚悟でいてください。

クラウド・インスタンスの仮想ハードウェア仕様を決めるときには、考慮しなければならない要素が数多くあります。これらの要素の組み合わせがシステムで処理可能な負荷の量を左右するわけですが、その組み合わせは場合によってさまざまです。

典型的なデータ・センター環境ではピーク負荷に合わせて計画を立てなければならないため、IT リソースが十分に活用されないことがよくあります。けれどもクラウドの動的な性質のおかげで、必要に応じて簡単にピーク負荷に対応することができます。リソースが必要になったら動的に追加し、負荷が減ったらいつでも取り除くことができるので、新しい計画標準は平均的なリソース容量の要求を示すものになります。

この記事では、IBM Cloud に対して Cognos 8 の大規模なデプロイメントをするための一般的な指針とアーキテクチャーに関する推奨案を説明します。

パフォーマンスとスケーラビリティーのプラクティスについて説明するため、以下の話題を取り上げます。

  • ユーザー・グループとユーザーの地理的分布
  • アプリケーションの複雑さ (各種の層)
  • デプロイ後の考慮事項

Cognos を IBM Cloud にインストールして構成する方法についての詳細は、この連載の他の記事と Cognos のサイト (「参考文献」) を参照してください。

ユーザー・グループとユーザーの地理的分布

この記事のコンテキストでは、Cognos ソリューションのユーザーは以下の 3 つのユーザー・グループに分けられます。

  • 登録ユーザー: システムに登録されているすべてのユーザー。
  • アクティブ・ユーザー: システムに現在ログインしているユーザー。ただし、必ずしもリクエストを送信しようとしているとは限らず、またリクエストの送信が完了するのを待っているとも限らない登録ユーザー (例えば、レポートを読んでいるユーザーなど)。
  • 実行中ユーザー: リクエストを送信しようとしているか、リクエストの送信が完了するのを待っているアクティブ・ユーザー

IBM での大規模なデプロイメントの経験から言うと、これらのユーザーの比率は一般的に 100:10:1 です (実行中ユーザーの比率は常に、わずか 1 パーセントにすぎません)。つまり 100 人の登録ユーザーがいるとすれば、10 人がアクティブ・ユーザーであり、そのうち 1 人がリクエストを送信しようとしているか、または実行中ということになります。

同じシステムでも、実行中ユーザーの比率がこれより大幅に高くなったり、大幅に低くなったりしますが、この数値が 5 パーセントから 7 パーセントを超えることはめったにありません。これは、ピーク時にも当てはまります。したがって、システムの負荷を計算するときには、実行中ユーザー数だけを考慮すればよいということになります。

考慮しなければならないもう 1 つの重要な要素は、ユーザー・グループの地理的分布です。これも、システムの平均負荷とピーク負荷に影響を与えます。ユーザーがいる地域のタイムゾーンがさまざまに異なると、Cognos のデプロイメントでの 1 日の負荷パターンに驚くほどの影響が出てきます。同等の実動サーバーを配置しているとしたら、その実際の負荷パターンを一定の期間測定すると、実行中ユーザーの正確な比率を知る上で大いに役立つので、この方法を是非ともお勧めします。


アプリケーションの複雑さ

平均実行中ユーザー数の要件だけでなく、アプリケーションの複雑さもリソースの要件に影響します。例えば、複雑なデータベース・クエリーや高度なフォーマット設定を必要とするレポートには、レポート処理能力が余計に必要になります。つまり、対応可能なレポート数が減る時点が発生する可能性があるということです。このようなタイプのアプリケーションで同じ数の実行中ユーザーをサポートするためには、システム容量を大きくしなければなりません。

以降のセクションでは、Web サーバー層、アプリケーション層、そしてコンテンツの管理を行う層のスケーラビリティーとパフォーマンスをバランス良く維持するために適用できるいくつかのプラクティスを説明します。

Web サーバー層

ハードウェア仕様を計画するにあたっては、最近の CPU の場合、CPU 1 基あたり 50 人の実行中ユーザー (ユーザーのロールに関わらず) に対処するという前提で環境の規模を決めることを提案します。

ただし、Web 層で平均負荷をサポートするためのハードウェア要件については、その推定に影響する要素が 2 つあります。

  • 1 つは、SSL (Secure Sockets Layer) 接続を使用すると、サポートされる実行中ユーザーの推定数が減ることです。
  • さらに重要な点として、ソリューションのフェイルオーバー要件を考慮し、追加の CPU を割り当てることで高可用性の要件を満たすようにしなければなりません。

アプリケーション層

ハイパフォーマンスの Cognos ソリューションを実現したいと思ったら、レポートおよびクエリー処理を考慮することが最も優先される事項となります。レポートおよびクエリー処理は、実行中ユーザー数だけでなく、アプリケーションの複雑さによっても影響を受けます。

インタラクティブなレポートを作成する場合の一般的な指針は、CPU 1 基あたりのインタラクティブなレポート・プロセス数は 2 つとし、各 CPU のレポート実行スレッドは 4 つとする、という前提から始めることです。換算すると、物理 CPU 1 基あたり、8 つのインタラクティブ・レポート作成リクエストを同時に処理することになります。

  2 report processes/CPU
x 4 report execution threads
--------------------------------------
  8 concurrent reporting requests/CPU

バッチ・レポート作成処理には大量のデータが関わってくるため、一般的な指針としては、CPU 1 基あたりのバッチ・レポート・プロセスは 2 つとし、各 CPU のレポート実行スレッドは 2 つとする、という前提にします。つまり、各物理 CPU で、4 つのバッチ・レポート・プロセスを同時に実行するということです。

  2 batch report processes/CPU
x 2 report execution threads
-------------------------------------------
  4 concurrent batch reporting requests/CPU

以上は IBM の経験に基づく一般的な前提であり、それぞれのソリューションによって異なってくることに注意してください。クラウドでの Cognos ソリューションに必要なリソースを計算するときには、以上の一般的前提と併せ、予想される実行中ユーザーの 1 日の平均数を考えてクラウド・ハードウェア要件を決定する必要があります。

Cognos 8 はスケーラビリティーを念頭に置いて設計されています。ピーク時にシステム負荷の増加に対処するために Cognos アプリケーション・サーバーを追加するには、サーバーを新しくインスタンス化してシステムに組み込むだけの簡単な話です。この新しく追加されたサーバー・インスタンスは、システム負荷を自動的に、しかもほとんど即時に共有します。処理能力が必要なくなったときには、サーバーをただ単にシャットダウンすれば追加インスタンスを取り除くことができます。

Content Manager 層

Content Manager のパフォーマンスは、パッケージまたはフォルダーに含まれるオブジェクトの数、そしてオブジェクトに関連付けられたセキュリティーによって大きく左右されます。例えば、フォルダーまたはパッケージに多数のオブジェクトが含まれている場合、限られた特権を持つユーザーがオブジェクトにアクセスする際には、オブジェクトごとのユーザーの権限を検証してセキュリティー・ルールが確実に施行されるようにする必要があります。フォルダーに含まれるオブジェクトの数が少ない場合、あるいはフォルダー全体が保護されていない場合には、必要となるリソースは大幅に減ります。

IBM での平均的な使用パターンの経験から提案するのは、レポート処理用の CPU 4 基に対して 1 基の Content Manager 用の CPU を割り当てることです。ただし、アプリケーションにそれ以上のContent Manager の処理能力が必要な場合には、Content Manager への CPU 割り当てを 2 倍にするのが妥当でしょう。

最後に付け加える点として、32 ビットの JVM のメモリー・アドレス空間は 2GB に制限されることから、IBM では Cognos Content Manager を 64 ビットのオペレーティング・システムにデプロイすることを推奨しています。大規模なデプロイメントには、64 ビットの構成を強くお勧めします。


デプロイ後の考慮事項

以上で説明した推奨案は、IBM の平均的な使用パターンの経験に基づいた一般的な指針でしかありません。リソースをデプロイするときにはシステムを監視することが不可欠です。それによって、構成を調整する結果となることは珍しくありません。フェイルオーバーや負荷分散の要件によっては、追加のリソースが必要になる可能性もあります。

Cognos をクラウドで実行する方法については、Cognos サイトおよび developerWorks で詳細を調べてください (「参考文献」を参照)。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=548927
ArticleTitle=Cognos クラウドのベスト・プラクティス: パフォーマンスとスケーラビリティーに応じたアーキテクチャーのサイズ変更
publish-date=08312010