スケーラビリティに関する注意事項

Session Recordingは、数千の、または数万のセッションを処理する高スケーラブルなシステムです。Session Recordingのインストールと実行のために、XenAppおよびXenDesktopの実行に必要なハードウェア要件を超えて、さらにリソースを追加する必要はほとんどありません。ただし、Session Recordingを使用して数多くのセッションを録画する可能性がある場合、または画像処理に多くのリソースを消費するアプリケーションを録画するなど、セッションの録画ファイルのサイズが大きくなることが予測される場合は、Session Recordingの展開計画を立てるときに、使用するシステムのパフォーマンスについて検討します。

ここでは、Session Recordingによって高いスケーラビリティを実現し、最低限のコストで録画システムを最大限に活用できる方法について説明します。

Session Recordingのスケーラビリティが高い理由

Session Recordingが同様の他社製品と比べて高いスケーラビリティを提供できるのには、主に2つの理由があります：

• 小さなファイルサイズ

  Session Recordingで作成されたセッションの録画ファイルは比較的小さなサイズです。スクリーンスクレイピングによるソリューションで作成された同様のビデオ録画に比べると、けた外れに小さなサイズです。各Session Recordingファイルの転送および格納に必要なネットワーク帯域幅、ディスクスペース、ディスクIOPSは通常、同様のビデオファイルの10分の1以下です。

  セッションの録画ファイルのサイズが小さいと、ビデオフレームのレンダリングもより高速かつスムースになります。また、録画は完全に無損失で、大半の小さなサイズのビデオ形式で発生しがちな表示の滑らかさの問題もありません。録画の中のテキストは、再生中でも元のセッションと同じくらい読み取りやすい状態です。ファイルサイズの小ささを維持するために、Session Recordingはファイル内でキーフレームを記録しません。

• ファイルの生成に必要な処理が少ない

  セッションの録画ファイルには、実質的には本来の形式で抽出されたセッションのICAプロトコルデータが含まれます。つまり、ファイルはCitrix Workspaceアプリと通信していたICAプロトコルデータストリームをキャプチャします。リアルタイムでデータを変換するために高価なトランスコードやエンコード用のソフトウェアコンポーネントを実行する必要はありません。VDAのスケーラビリティでは、処理の量を抑えることも重要です。これによって、同じVDAから多くのセッションが録画された場合でも、エンドユーザーエクスペリエンスが維持されます。

  また、再生が可能なICA仮想チャネルのみが録画されるため、さらに最適化が促進されます。たとえば、プリンターやクライアントドライブマッピングチャネルはビデオの再生時に必要がなく生成するデータ量も多いため、録画の対象外です。

データの入力速度および処理速度の推定

Session Recordingサーバーは、セッションの録画ファイルを一元的に収集する場所です。マルチセッションOS VDAを実行している各マシンでSession Recordingを有効にすると、セッションの録画データをSession Recordingサーバーに送信します。Session Recordingは大量のデータを処理することができ、バーストや障害にも耐性がありますが、どのようなサーバーでも物理的なデータ量の限界はあります。

各Session Recordingサーバーに送信するデータの量と、サーバーでこのデータを処理し格納するのにかかる時間について考慮します。受信データを格納する速度がデータ入力速度より高速である必要があります。

データ入力速度を推定するには、録画対象のセッションの数をその平均サイズで乗算してから、セッションの録画時間で除算します。たとえば、5,000件のMicrosoft Outlookのセッションの平均サイズが20MBとして、毎営業日に8時間録画するとします。この場合、データの入力速度は約3.5Mbpsです（5,000セッション×20MB÷8時間÷3,600秒）。通常、100Mbps LANに接続され、記録されたデータを格納する十分なディスクスペースがあるSession Recordingサーバーは、ディスクおよびネットワークIOPSによる物理的な制限を考慮すると、データを約5.0Mbpsで処理できます。これが、処理速度です。この例では、処理速度（5.0Mbps）は入力速度（3.5Mbps）より高い値であるため、5,000件のOutlookセッションを録画することが可能です。

セッションごとのデータ量は録画される内容によって大きく異なり、画面の解像度、色数、グラフィックモードなどのその他の要素も影響します。グラフィック操作が一定して多いCADパッケージを実行しているセッションでは、エンドユーザーがMicrosoft Outlookでメールを送受信するセッションよりも、大幅に大きなサイズの録画データが生成されることが予想できます。したがって、同じ数でもCADセッションはきわめて高い入力速度を必要とし、Session Recordingサーバーの使用率も高くなります。

バーストや障害

前述の例では、非常にシンプルで均一なデータのスループットを想定しましたが、短い時間に高いアクティビティが発生するバーストといわれる状態をシステムが処理する方法については、また異なります。バーストは、すべてのユーザーが朝の同じ時間に一斉にログオンするとき（9時台のラッシュ）や、全員が一斉にOutlookの受信ボックスで同じメールを受信した場合などに発生することがあります。このような急激な需要には、Session Recordingサーバーの5.0Mbpsという処理速度では対応が不十分になります。

各VDAで実行されているSession Recording Agentは、Microsoftメッセージキュー（MSMQ）を使用して記録されたデータをSession Recordingサーバーに送信します。データは、ストアアンドフォワード方式で送信されます。これは、メールが送信者、メールサーバー、受信者との間で送受信される方法と似たような方式です。Session Recordingサーバーやネットワークがバースト時の大量のデータを処理できない場合、セッションの録画データはデータメッセージのバックログが消去されるまで一時的に格納されます。ネットワークが混雑した場合、データメッセージは一時的に発信キューに格納されることがあります。または、データがネットワークを経由してもストレージマネージャーが他のメッセージの処理でビジー状態の場合、Session Recordingサーバーの受信キューに格納されることがあります。

MSMQはフォールトトレランスメカニズムとしても機能します。Session Recordingサーバーがダウンするかリンクが破損している場合、記録されたデータは各VDAの発信キューにとどまります。障害が解消されると、キューのすべてのデータが一度に送信されます。MSMQを使用することで、現在のセッションの録画を中断したりデータを失ったりすることなくSession Recordingサーバーをオフラインでアップグレードやメンテナンスすることもできます。

MSMQの主な制限は、データメッセージの一時ストレージとしてのディスクスペースが限られていることです。このため、バースト、障害、またはメンテナンスイベントが長引く場合、最終的にデータが失われることがあります。データ損失後も総合的なシステムは機能し続けますが、この状況では個別の記録内でデータの一部が失われます。データが失われたファイルは再生可能ですが、最初に失われたデータの箇所まで進むと再生が停止します。以下の点に注意してください：

• 各サーバー、特にSession Recordingサーバーにディスクスペースを追加してMSMQで使用できるようにすると、バーストや障害時の許容値が上昇します。

• 各Session Recording Agentでメッセージの有効期間を適切なレベルに設定することが重要です（Session Recording Agentプロパティの ［接続］ タブ）。デフォルト値の7,200秒（2時間）は、記録された各データメッセージが破棄され、録画ファイルが破損する前にストレージマネージャーに到達するのに2時間の猶予があることを意味します。利用可能なディスクスペースが増えると（または録画するセッションを削減すると）、この値を増やすことを選択できます。最大値は365日です。

MSMQのその他の制限は、データのバックログが作成されると、データメッセージの読み取りと書き込みのために追加のディスクIOPSが発生するということです。通常の状態であれば、ストレージマネージャーはネットワークから直接データを受信して処理し、データメッセージがディスクに書き込まれることはありません。データを格納するためには、セッションの録画ファイルを追加するためにディスクへの一度の書き込み操作が必要になります。データのバックログが作成された場合、ディスクIOPSが3倍になります。これは、各メッセージがディスクに書き込まれ、ディスクから読み取られ、ファイルに書き込まれる必要があるためです。ストレージマネージャーはIOPSに大幅に影響を受けるため、Session Recordingサーバーの処理率はメッセージのバックログが消去されるまで低下します。この追加のIOPSの影響を緩和するため、以下の推奨事項を採用します：

• MSMQがメッセージを格納するディスクは、録画ファイルのストレージフォルダーとは異なるディスクを使用してください。IOPSバストラフィックが3倍になっても、実際の処理率の低下は深刻なものにはなりません。

• 計画的な停止をピーク時以外のみにとどめます。予算の制限によっては、高可用性サーバーの構築で実証済みのアプローチを使用します。このアプローチには、UPS、デュアルNIC、スイッチの冗長化、ホットスワップ対応メモリとディスクの使用が含まれます。

処理能力を重視した設計

セッションの録画データが均一であることは少なく、バーストや障害が発生する可能性があり、メッセージのバックログの消去はIOPSを増加させます。このため、各Session Recordingサーバーは処理能力に余裕をもって設計します。後のセクションで説明するように、サーバーを追加するか既存のサーバーの仕様を改善することで、より多くの処理能力を獲得できます。一般的な目安は、各Session Recordingサーバーを合計処理能力の最大50%で実行することです。前述の例のように、サーバーが5.0Mbpsで処理することができる場合、システムは2.5 Mbpsで実行することを目標にします。1つのSession Recordingサーバーで5,000件のOutlookセッションの録画では3.5Mbpsですが、これを3,500件のセッションに抑えると約2.5Mbpsになります。

バックログとライブ再生

ライブ再生とは、セッションがアクティブなときに閲覧者がセッションの録画を開いて再生することです。ライブ再生中に、そのセッションを担当するSession Recording Agentがストリーミングモードに切り替え、録画データを内部バッファリングなしにストレージマネージャーに即座に送信します。録画ファイルは常に更新され、Playerは引き続きライブセッションからの最新データを取得します。Agentからストレージマネージャーに送信されたデータはMSMQを経由し、前述のキューの規則が適用されます。このシナリオでは、問題が発生する可能性があります。MSMQのバックログが作成されると、ライブ再生で利用可能な新しい録画データは、他のすべてのデータメッセージのようにキューに登録されます。閲覧者がファイルを再生することはできますが、ライブで記録された最新のデータの閲覧には遅延が発生します。ライブ再生が閲覧者にとって重要である場合は、展開でバックログの必要性が低くなるように処理能力やフォールトトレランスを設計してください。

XenAppおよびXenDesktopのスケーラビリティ

Session Recordingがセッションのパフォーマンスを低下させたり、記録されたデータバックログへの応答でセッションを停止させたりすることは決してありません。エンドユーザーエクスペリエンスや単一サーバーのスケーラビリティを維持することが、Session Recordingシステムの設計において何よりも優先されます。記録システムが不可逆的に過負荷になった場合、記録されたセッションのデータは破棄されます。シトリックスが実施した広範囲にわたるスケーラビリティテストによると、ICAセッションの録画がXenAppおよびXenDesktopサーバーのパフォーマンスとスケーラビリティに与える影響は大きくありません。影響の大きさは、プラットフォーム、利用可能なメモリ、録画されたセッションの画像の性質によって異なります。以下の構成では、単一サーバーのスケーラビリティへの影響は1〰5%程度と予想されます。つまり、Session Recordingをインストールしない場合に100ユーザーをホストできるサーバーの場合、インストール後は95〜99人のユーザーをホストすることができます：

• マルチセッションOS VDAを実行している8GB RAMの64ビットサーバー
• Office業務アプリケーション（OutlookやExcel）を実行しているすべてのセッション
• アプリケーションの使用が可能で維持される
• すべてのセッションがSession Recordingポリシーの構成に従って録画される

録画されているセッションが少数か、維持されるセッションアクティビティが少なく散発的であれば、影響は大きくありません。多くの場合、スケーラビリティへの影響は無視できる範囲で、サーバーあたりのユーザー密度に変化はありません。前述したように、影響が少ないのは各VDAにインストールされたSession Recordingコンポーネントの処理要件がシンプルであるためです。記録済みのデータは、ICAセッションスタックから抽出され、そのままMSMQ経由でSession Recordingサーバーに送信されるだけです。コストがかかるデータのエンコードは発生しません。

セッションが録画されていない場合でも、Session Recordingの使用には多少のオーバーヘッドが発生します。この影響は大きくありませんが、特定のサーバーから録画されるセッションがないことが分かっている場合は、そのサーバーの録画を無効にできます。Session Recordingを削除する方法もあります。より影響の少ないアプローチは、Session Recording Agentの ［Session Recording］ タブで ［このVDAマシンでセッションを録画する］ チェックボックスをオフにすることです。あとからセッションの録画が必要になった場合、このチェックボックスを再度オンにします。

スループットの測定

セッションの録画データをVDAから送信してSession Recordingサーバーで受信する場合のスループットを測定するには、さまざまな方法があります。最も簡単かつ効果的なアプローチの1つは、録画されたファイルのサイズ、およびSession Recordingサーバーでディスクスペースが消費される速度を測定することです。ディスクに書き込まれるデータの量は、生成されるネットワークトラフィックの量をほぼ反映しています。Session Recordingで提供されるカウンターに加えて、Windowsパフォーマンスモニターツール（perfmon.exe）には、監視可能なさまざまな標準のシステムカウンターがあります。カウンターは、スループットの測定だけでなく、ボトルネックやシステムの問題を特定するために使用できます。次の表では、最も有用なパフォーマンスカウンターの一部をまとめました。

Session Recordingサーバーのハードウェア

Session Recordingサーバーで使用されるハードウェアを慎重に選択することで、展開の処理能力を拡大できます。選択肢は、スケールアップ（各サーバーの処理能力を増やす）かスケールアウト（さらにサーバーを追加する）の2つです。最低限のコストでスケーラビリティを増やすことを念頭に、どちらかを選択します。

スケールアップ

単一のSession Recordingサーバーの場合、予算内で最適なパフォーマンスを確保する次のベストプラクティスを検討してください。システムは、IOPSに依存しています。これによって、ネットワークからディスク間で録画されたデータの高いスループットを確保できます。そのため、適切なネットワークやディスクのハードウェアに投資することが重要です。高いパフォーマンスのSession Recordingサーバーの場合、デュアルCPUまたはデュアルコアCPUをお勧めしますが、これを超える仕様にしてもさほどパフォーマンスは上昇しません。64ビットプロセッサをお勧めしますが、x86プロセッサでも問題ありません。4GBのRAMをお勧めしますが、これを超える仕様にしてもパフォーマンスに大幅な変化はありません。

スケールアウト

スケールアップのベストプラクティスを使用しても、大量のセッションを録画する場合、1つのSession Recordingサーバーではパフォーマンスとスケーラビリティに限度があります。負荷に対応するために、追加のサーバーが必要な場合があります。複数のSession Recordingサーバーを異なるマシンにインストールすることで、負荷分散プールとして機能させることができます。このタイプの展開では、Session Recordingサーバーはストレージとデータベースを共有します。負荷を分散するには、Session Recording Agentを負荷分散を担当するロードバランサーに割り当てます。

ネットワークの性能

Session Recordingサーバーに接続するには100Mbpsのネットワークリンクが適しています。ギガビットイーサネット接続ではパフォーマンスが向上するかもしれませんが、100Mbpsのリンクの10倍のパフォーマンスが得られるわけではありません。実際には、スループットの増加量は大幅にダウンします。

Session Recordingで使用するネットワークスイッチを、使用できるネットワーク帯域幅を求めて競合する可能性のあるサードパーティ製のアプリケーションと共有しないようにします。Session Recordingサーバー専用のネットワークスイッチを用意することが理想的です。ネットワークの混雑がボトルネックであると判明した場合、ネットワークのアップグレードはシステムのスケーラビリティを向上させるうえで比較的安価な方法です。

ストレージ

ディスクとストレージハードウェアへの投資は、サーバーのスケーラビリティにおいて単独で最も重要な要因です。ディスクへのデータの書き込み速度が速いほど、システム全体のパフォーマンスが向上します。ストレージソリューションを選択する場合、読み取りパフォーマンスよりも書き込みパフォーマンスに重点を置いてください。

ローカルディスクコントローラーを使用したRAID、またはSANのいずれかとして制御されるローカルディスクのセットにデータを格納します。

注：

SMB、CIFS、またはNFSのようなファイルベースのプロトコルでNASにデータを格納すると、深刻なパフォーマンスおよびセキュリティ上の問題が発生する可能性があります。この構成は、Session Recordingの実稼働環境では決して使用しないでください。

ローカルドライブを使用する場合、キャッシュメモリが組み込まれたディスクコントローラーを検討してください。キャッシュによって、コントローラーはライトバック中に昇順に並べ替えることができるため、ディスクヘッドの動きを最小限にとどめ、物理ディスクの操作が完了するのを待機せずに書き込み操作を完了できます。このため、最小限の追加コストで大幅に書き込みパフォーマンスを向上させることができます。ただしキャッシュを使用する場合、停電時にデータ損失が発生する問題を検討する必要もあります。データとファイルシステムの整合性を確保するには、キャッシュ機能付きディスクコントローラーに予備電源装置を付け、停電時にもデータキャッシュが保持され、復旧したときにデータがディスクにライトバックされるようにします。

適切なRAIDストレージソリューションを使用するようにしてください。パフォーマンスと冗長性の要件に対応した、多くのRAIDレベルがあります。次の表は、各RAIDレベルと各標準がSession Recordingにどのように適用されるかを示します。

RAID 0とRAID 3が、最も推奨されるRAIDレベルです。RAID 1とRAID 5は一般的な標準ですが、Session Recordingには推奨されません。RAID 10は、パフォーマンス上のいくつかのメリットを提供していますが、コストパフォーマンスは低くなります。

ディスクドライブの種類や仕様を決定します。IDE/ATAドライブや外付けUSBまたはFireWireドライブは、Session Recordingでの使用に適していません。主な選択肢は、SATAかSCSIです。SATAドライブはSCSIドライブと比較して、MB単位のコストが抑えられた十分高い転送速度を提供します。ただし、SCSIドライブはより優れたパフォーマンスを提供し、サーバー展開でより一般的です。サーバーRAIDソリューションは、主にSCSIドライブをサポートしますが、一部のSATA RAID製品も利用可能になりました。ディスクドライブ製品の仕様を評価する場合、ディスクの回転速度および他のパフォーマンス特性を考慮してください。

一日あたり数千のセッションの録画は、相当量のディスクスペースを消費する可能性があるため、総合的な処理能力とパフォーマンスのどちらかを選択する必要があります。前述の例では、毎営業日に8時間、5,000件のOutlookセッションを録画すると、約100GBの記憶域を消費します。10日間の録画（50,000件のセッションの録画ファイル）を格納するには、1,000GB（1TB）が必要です。ディスクスペースに対するこうしたプレッシャーは、古い録画をアーカイブまたは削除する前の保有期間を短縮することで緩和できます。1TBのディスクスペースが利用でき、7日間の保有期間が適切な場合、ディスクスペースの使用は約700GB程度にして、300GBは多忙な日のバッファとして確保します。Session Recordingでは、ファイルのアーカイブや削除がICLDBユーティリティでサポートされ、最短保有期間は2日間です。バックグラウンドタスクをスケジュール設定して、ピーク時以外に1日に1回実行できます。ICLDBコマンドおよびアーカイブについて詳しくは、「データベースレコードの管理」を参照してください。

ローカルドライブやコントローラーを使用する代わりに、ブロックレベルのディスクアクセスベースのSANストレージソリューションを使用できます。Session Recordingサーバーには、ディスクアレイはローカルドライブとして表示されます。SANはセットアップにコストがかかりますが、ディスクアレイが共有されると、管理が簡易化され一元化されというメリットがあります。SANには、ファイバチャネルとiSCSIという2つの主な種類があります。iSCSIは基本的にTCP/IPを介したSCSIで、ギガビットイーサネットの導入以来ファイバチャネルよりも一般的になっています。

データベースのスケーラビリティ

Session Recordingデータベースでは、Microsoft SQL Server 2016、Microsoft SQL Server 2014、Microsoft SQL Server 2012、またはMicrosoft SQL Server 2008 R2が必要です。データベースにはセッション録画のメタデータのみが格納されるため、データベースに送信されるデータ量は少なくなります。セッションの録画ファイル自体は別のディスクに書き込まれます。Session RecordingイベントAPIを使用してセッションに検索可能なイベントを挿入するのでなければ、セッション録画1件につきデータベースに必要な容量は通常1KBのみです。

Microsoft SQL Server 2016、Microsoft SQL Server 2014、Microsoft SQL Server 2012、およびMicrosoft SQL Server 2008 R2のExpress Editionでは、データベースサイズの上限は10GBです。1件のセッション録画あたり1KBのデータが書き込まれるとすれば、この制限があっても、4百万件のセッションをデータベースでカタログ化できます。Microsoft SQL Serverのほかのエディションではデータベースサイズの制限はなく、使用できるディスク容量によってのみ上限が決定されます。データベース内のセッション数が増加するにつれて、データベースのパフォーマンスと検索速度はごくわずかに低下します。

Session RecordingイベントAPIによるカスタマイズを行わない場合は、録画セッションそれぞれについて、録画開始時に2件、ユーザーがセッションにログオンするときに1件、および録画終了時に1件の、合わせて4件のデータベーストランザクションが生成されます。Session RecordingイベントAPIを使用してセッションをカスタマイズする場合は、検索可能な録画イベントそれぞれについて1件のトランザクションが生成されます。最も基本的な方式で展開したデータベースで、1秒あたり何百件というトランザクションを制御できるため、データベースの処理負荷が高くなる可能性はほとんどありません。影響が十分に小さいため、XenAppまたはXenDesktopのデータストアデータベースを含めたほかのデータベースと同じSQL Serverで、Session Recordingデータベースを実行できます。

Session Recordingのデータベースで何百万というセッション録画をカタログ化する必要がある場合は、SQL Serverのスケーラビリティに関するMicrosoft社のガイドラインに従います。