キャパシティ要件の見積

Yellowfin実装計画時の重要なステップとして、キャパシティ要件の見積りがあります。これは、提供目標とサービス品質保証を満たすために必要な、初期のコンピューティングリソースを概算します。キャパシティの見積りは非公式、または構造化されたアプローチに基づき実行することができ、ユーザーが行う主要な活動を含めて考慮しなくてはいけません。

見積もるべき主要なシステム要件は、以下の通りです。

• • 処理能力：処理能力は最も高額になるため、一般的には最も重要なリソースです。これには、物理的なサーバ台数、速度、bit数、CPU数の決定が含まれます。
  • システムメモリ：計画されている実装のメモリ要件は、オペレーティングシステムの選択や、処理能力の決定に影響を与えます。例えば、32-bitのWindows プラットフォーム上で実行される任意のアプリケーションプロセスは、最大3GBまでのシステムメモリしか使用することができません。一方で、64-bitのWindows、UNIX、Linux オペレーティングシステムは、アプリケーションの使用に、理論的には18 exabyteのアドレス空間をサポートします。
  • ハードディスク容量：コンピューティングリソースにおいて、ハードディスクリソースは、3種類のシステムリソースの中で最も安価であり、重要度も一番低いです。

キャパシティの見積りは、成長するユーザーのニーズに、システムインフラが対応し続けるために、継続して実行していく必要があります。ユーザー要件の管理、データソースからのデータ取得、アナリティクス機能の追加、レポート結果の書式設定や配信、レポートインタラクションの実行など、これらすべてにコンピューティングリソースが使用されます。ユーザー数、レポート数、データ量や、Yellowfin サーバに制御される分析レポート量の増加は、同等レベルのパフォーマンスとレポートスループットを維持するために必要とされるコンピューティングリソースの量を増加させます。キャパシティの見積りをすることで、Yellowfinの実装に必要なコンピューティングリソースの量を合理的に把握できます。

キャパシティ要因とその影響

キャパシティ計画の最も重要な要因は、以下の通りです。

• • ユーザー数
  • レポートのデザイン
  • レポートのインタラクティビティ
  • 監視と管理
  • データ準備
  • ストーリーの使用
  • シグナルの使用

3つの主要なシステム要件に対する影響をまとめると、以下のようになります。

ユーザー数の見積

アプリケーションのユーザー総数は、最も簡単に見積ることのできる要因です。ユーザー情報や、監査証跡、レポートインスタンスのユニーク情報は、Yellowfinのリポジトリに保存されるため、ユーザー数の増加はハードディスク要件も増加させます。ユーザーのアプリケーション使用方法に応じて、CPUやメモリ要件にも影響を与える場合があります。

任意の時点で、典型的なレポート作成アプリケーションを使用している同時接続ユーザーは、全体の10-20%程度です。Yellowfin アプリケーションサーバは、システムリソースの共有プールから、アクティブユーザーごとにメモリとアドレス空間を割り当てます。同時接続ユーザーのセッション数が増加するに従い、アプリケーションサーバに消費されるメモリリソースも増加します。

通常、Yellowfinにログインしているユーザーの30-50%程度が、同時にジョブを実行します。そのため、Yellowfinのユーザー活動率は、指名ユーザー全体の3-10%程度です。アクティブユーザーは、コンピューターサーバのプロセッサやメモリリソースに直接的に影響を与えます。

経験則として、アプリケーションサーバの同時接続ユーザ数25につき、メモリ8GBと3 GHz（8スレッド）プロセッサを使用できます。

例えば、Yellowfinインスタンスに指名ユーザーが500登録されている場合、任意の時点でログインしているアクティブユーザーは50程度です（ピーク時の使用量は大幅に増加）。これには最低でも、16GBメモリを搭載した、16スレッドサーバが必要です。もちろんこれはガイドラインに過ぎず、データベースのサイズや複雑さ、実行されているレポート、オンライン対バックグランド負荷の特性などが含まれ、様々な要因に応じてリソースの消費は異なります。

各インストールで状況は異なります。そのため、本番環境の負荷を想定したパフォーマンステストの実施を強く推奨します。これにより、ソフトウェアがパフォーマンス要件を満たし、Yellowfinコンテンツが合理的な時間で読み込まれることを確認できます。

レポート特性の理解

実装されるレポート数は、キャパシティ要件の決定に重要な要因ですが、レポート数のみでは正確な見積りはできません。レポートのサイズ、分析的複雑さ、レポートのレイアウトも合わせて考慮する必要があります。

レポートのサイズ

最近実行されたレポートは、メモリリソースを使用してキャッシュに保存されます。使用されるメモリ量は、使用されるデータ量とデータ型に応じて異なり、これは比較的正確に見積ることができます。また、レポート履歴も、ハードディスク容量を使用して保存されます（例：結果セットのXMLのコピーは、レポートが更新される度に、Yellowfinのリポジトリに保存されます）。

分析的複雑さ

Yellowfinは、セクションやクロス集計データの生成、計算や小計、ドリル、並べかえ、ピボットの追加、フィルタープロンプトの管理によりレポートに分析機能を追加します。大規模な分析処理を必要とするレポートには、より多くの処理能力とメモリが要求されますが、正確な量の定量は困難です。

レポートのレイアウト

Yellowfinは、クロス集計グリッドやグラフ、HTML、PDF、CSVなど、様々な形式でレポートに書式を設定します。レポート結果への書式の適用は、処理能力とメモリの両方を使用します。レポートにより多くの書式や制御、レポートオブジェクトを含めることで、より多くの処理能力やメモリリソースが消費されます。

レポートインタラクション効果の組み込み

電子メールによるレポートの受信から、複雑なレポート作成機能まで、Yellowfinとのインタラクションレベルはユーザーに応じて異なります。これらインタラクションによる効果は、以下のようにカテゴリー分けすることができます。

レポート閲覧と作成

Yellowfinは、中央集約管理された、非常にリッチなレポート作成、分析、および監視環境を提供します。プラットフォームには、システムへのアクセスや、レポートの検索、実行、印刷などの基礎的な機能から、ドリルや並べかえ、ピボット、計算の追加や、エクスポートなどの強力な分析機能まで、幅広い機能があります。洗練されたレポート開発機能もまた、このプラットフォームで利用できます。

レポートインタラクションの量と多様性は、Web サーバ、アプリケーションサーバ、Yellowfin リポジトリ・データベースサーバ、データソース、Web ブラウザなど、Web インフラのすべての階層で、処理能力とメモリの両方を消費します。すべての階層に対して、キャパシティを見積る必要があります。

レポートのバッチ処理と配信

数多くの組織で、頻繁に使用されるレポートや、スケジュール設定されたレポートをバッチ処理しています。これらの処理はオフピーク時や、システム使用率の低い時に実行されることが望ましいです。レポートバッチ処理のシステムリソースを管理する主な制約は、実行され、配信されるレポートの量と、処理が実行されるバッチウィンドウのサイズです。バッチウィンドウが短くなり、レポート量が増加すると、割り当てられた時間内でレポートの処理と配信を完了するために、アプリケーションサーバにより多くの処理能力とメモリリソースが必要になります。

レポートの履歴

レポートの結果セットは、複数ユーザーで再利用するために、Yellowfin リポジトリに保存することができます。これにより、複数バージョンのレポートを比較できます。これはデータソースの負荷を軽減しますが、Yellowfin インストールのハードディスク要件も増加させます。

管理者によるクリーンアッププロセスと、削除ポリシーを定義することで、必要とされるリソースの総量を削減できます。

BI実装の管理と監視

Yellowfinは、実装を確実に成功させるために、様々な監視、およびパフォーマンス強化機能を備えた、豊富なアプリケーションメタデータを提供します。機能的な充実と、継続的なパフォーマンス監視は、キャパシティの見積りで考慮すべきシステムリソースを占有します。

メタデータ

Yellowfin リポジトリのサイズは、アプリケーションサーバのメモリ消費に影響を与えます。アプリケーションサーバは、起動時に、メタデータ構成情報をメモリに読み込みます。

キャッシュ

Yellowfinは、スループットの向上、クエリーパフォーマンスの最適化、エンドユーザー応答時間の削減のために、包括的なキャッシュ機能を提供します。サーバのキャッシュは、メモリ内に保存されます。

監視

Yellowfinは、Yellowfin リポジトリ・データベースサーバに、統計、およびユーザーアクティビティを記録します。使用率やパフォーマンス統計の保存は、無視できる程度の処理能力やメモリリソースしか消費しませんが、レコードの保存には追加のディスク容量が必要です。

また、Yellowfinによりログファイルが作成されます。キャパシティの見積りでは、パフォーマンス監視と、使用率統計ログも考慮しなくてはいけません。これらの監視リソースを使用して、将来的なキャパシティ見積りや、アクティビティのチューニングを改善することが重要です。

Yellowfin シグナル

Yellowfin シグナルが実行する自動解析は、様々な要因に応じて、複雑にもシンプルにもなり得ます。システムに影響を与えるシグナル解析の要因は、以下の通りです。

シグナルの実行

解析される各データセットのサイズに応じて、シグナル解析は、タイムスライス全体を一度に解析するために必要なメモリを要求します。これは、各スライスにより返されるロウ（行）数が、使用されるメモリ量に影響することを意味します。選択されたディメンション（次元）フィールド内の一意のディメンション（次元）値の数と、解析日付範囲のサイズの組み合わせが、各解析サブタスクの最大メモリ使用量に最も大きく影響します。

シグナルは、高度に並列化されるように最適化されており、これは、複数のクラスタノードとCPUを利用して、問題を小さな塊に分割し、個別に解析できることを意味します。そのため、通常CPUスピード・パワーがシグナルのボトルネックになる前に、データベースやネットワーク、メモリ制約が発生しますが、これは非常に出力の低い環境、もしくは、非常に大量のシグナルタスクやサブタスクを同時に解析している環境で制約になります。

シグナル実行における最後の懸念点は、ディスクの空き容量です。シグナルやその設定に関する非常に大量のメタデータが保存されるほか、複数のシグナルユーザーやジョブにより、システム上に大量の通知が生成される可能性があるため、シグナルはリポジトリデータベースのサイズに大きく影響を与えます。データセットのキャッシュもこれに影響を与えますが、これは構成可能なオプション設定です。

シグナルのインタラクション

データセットサイズや、関連および相関グラフの数など、いくつかの要因に応じて、シグナルとのインタラクションが、システム全体に比較的負担をかけることがあります。シグナルを開くたびに、いくつかのグラフとともに複数のレポートを実行するという意味で、本質的にシグナルは、自動生成されるダッシュボードと言えます。これはつまり、複数のユーザーが同時にシグナルを閲覧する場合、メモリやCPU使用率が急増することを意味します。

シグナルデータセットのキャッシュは、多少これをサポートしますが、グラフ生成や、メモリへのデータセットの読み込みは依然として必要です。そして、多くの場合キャッシュは速度の遅いソースがある時に、読み込み時間の短縮をサポートするだけです。これは、より多くのデータセットを同時に読み込む必要があるため、この段階はシグナル解析の実行よりも、高い負荷が発生します。

各シグナルとともに表示される自動インサイトの解析は、最初のユーザーがシグナルを開いた時に一度だけ実行されるものです。その後は、キャッシュされ、表示されたバージョンが読み込まれ、レポートは実行はされません。これは、開かれることがないかもしれないシグナルのために、複数の余分な自動インサイトレポートが実行され、保存されるのを防ぐためです。しかしこれは、通常の自動インサイトの解析と同様の懸念により、システムにも影響を与えます。