スケーラビリティに関する考慮事項

Session Recordingは、数千から数万のセッションを処理できる、非常にスケーラブルなシステムです。Session Recordingのインストールと実行には、Citrix Virtual Apps and Desktopsの実行に必要なもの以外に、ほとんど追加のリソースは必要ありません。ただし、Session Recordingを使用して多数のセッションを記録する予定がある場合、または記録する予定のセッションが大きなセッションファイル（たとえば、グラフィックを多用するアプリケーション）になる可能性がある場合は、Session Recordingの展開を計画する際にシステムのパフォーマンスを考慮してください。

この記事では、Session Recordingが高いスケーラビリティをどのように実現しているか、また最小限のコストで記録システムを最大限に活用する方法について説明します。

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

Session Recordingが競合製品と比較してスケーラビリティが高い主な2つの理由は次のとおりです。

• 小さいファイルサイズ

  Session Recordingで作成された記録済みセッションファイルは、非常にコンパクトです。スクリーンキャプチャを行うソリューションで作成された同等のビデオ記録よりも、桁違いに小さくなります。各Session Recordingファイルを転送および保存するために必要なネットワーク帯域幅、ディスク容量、およびディスクIOPSは、同等のビデオファイルよりも通常、少なくとも10分の1です。

  記録済みセッションファイルのサイズが小さいため、ビデオフレームのレンダリングがより高速かつスムーズになります。記録はロスレスであり、ほとんどのコンパクトなビデオ形式でよく見られるピクセル化もありません。記録内のテキストは、元のセッションと同様に、再生中に読みやすいです。ファイルサイズを小さく保つため、Session Recordingはファイル内にキーフレームを記録しません。Session Recordingは、ビデオが実行されているセッションを記録中にH.264パッケージをドロップできるため、記録ファイルサイズを削減できます。この機能を使用するには、Session Recording AgentでHKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Agent\DropH264Enabledを1に設定し、Use video codec for compressionの値をFor actively changing regionsに設定します。

  アクティブに変更される領域の選択中(/ja-jp/session-recording/2103/media/selecting-for-actively-changing-regions.png)

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

  記録済みセッションファイルには、ほぼネイティブ形式で抽出されたセッションのICA®プロトコルデータが含まれています。このファイルは、Citrix Workspace™アプリとの通信に使用されるICAプロトコルデータストリームをキャプチャします。リアルタイムでデータの形式を変更するために、高価なトランスコーディングまたはエンコーディングソフトウェアコンポーネントを実行する必要はありません。処理量が少ないことは、VDAのスケーラビリティにとっても重要であり、同じVDAから多数のセッションが記録される場合でも、エンドユーザーエクスペリエンスが維持されることを保証します。

  さらに、再生可能なICA仮想チャネルのみが記録されるため、さらなる最適化が実現されます。たとえば、プリンターおよびクライアントドライブマッピングチャネルは、ビデオ再生に何のメリットもなく大量のデータを生成する可能性があるため、記録されません。

データ入力および処理レートの推定

Session Recording Serverは、記録済みセッションファイルの中央収集ポイントです。Session Recordingが有効になっているマルチセッションOS VDAを実行している各マシンは、記録済みセッションデータをSession Recording Serverに送信します。Session Recordingは大量のデータを処理でき、バーストや障害にも耐えることができますが、1つのサーバーが処理できるデータ量には物理的な制限があります。

各Session Recording Serverに送信するデータ量と、サーバーがこのデータをどれだけ迅速に処理および保存できるかを考慮してください。システムが受信データを保存できるレートは、データ入力レートよりも高くなければなりません。

データ入力レートを見積もるには、記録されたセッション数に各記録セッションの平均サイズを乗じ、セッションを記録している時間で割ります。たとえば、8時間の勤務日に20 MBのMicrosoft Outlookセッションを5,000回記録するとします。この場合、データ入力レートは約3.5 Mbpsです。（5,000セッション × 20 MB ÷ 8時間 ÷ 3,600秒/時間）。記録されたデータを保存するのに十分なディスク容量を持つ100 Mbps LANに接続された一般的なSession Recording Serverは、ディスクおよびネットワークIOPSによって課される物理的制限に基づいて、約5.0 Mbpsでデータを処理できます。このレートが処理レートです。この例では、処理レート（5.0 Mbps）が入力レート（3.5 Mbps）よりも高いため、5,000のOutlookセッションを記録することは実現可能です。

セッションあたりのデータ量は、記録される内容によって大きく異なり、画面解像度、色深度、グラフィックモードなどの他の要因も影響します。グラフィックアクティビティが常に高いCADパッケージを実行しているセッションは、エンドユーザーがMicrosoft Outlookで電子メールを送受信するセッションよりもはるかに大きな記録を生成する可能性があります。したがって、同数のCADセッションを記録すると、高い入力レートが生成され、より多くのSession Recording Serverを使用する必要が生じる可能性があります。

バーストと障害

前の例では、データの単純で均一なスループットを想定していますが、バーストとして知られる、より高いアクティビティの短期間にシステムがどのように対処するかについては説明していません。バーストは、すべてのユーザーが朝同時にログオンする（9時のラッシュとして知られる）場合や、Outlookの受信トレイで同じ電子メールを一度に受信する場合に発生する可能性があります。Session Recording Serverの5.0 Mbpsの処理レートは、この突然の需要に対処するには非常に不十分です。

各VDAで実行されているSession Recording Agentは、Microsoft Message Queuing（MSMQ）を使用して、記録されたデータを中央のSession Recording Serverで実行されているStorage Managerに送信します。データは、送信者、メールサーバー、受信者の間で電子メールが配信されるのと同様に、ストアアンドフォワード方式で送信されます。Session Recording Serverまたはネットワークがバースト時の高いデータレートを処理できない場合、記録されたセッションデータは、データメッセージのバックログがクリアされるまで一時的に保存されます。ネットワークが混雑している場合はVDAの送信キューに、データがネットワークを通過したがStorage Managerがまだ他のメッセージの処理でビジーである場合はSession Recording Serverの受信キューに、データメッセージが一時的に保存されることがあります。

MSMQは、フォールトトレランスメカニズムとしても機能します。Session Recording Serverがダウンしたり、リンクが切断されたりした場合、記録されたデータは各VDAの送信キューに保持されます。障害が修正されると、キューに入れられたすべてのデータがまとめて送信されます。MSMQを使用すると、既存のセッションの記録を中断したりデータを失ったりすることなく、アップグレードやメンテナンスのためにSession Recording Serverをオフラインにすることもできます。

MSMQの主な制限は、データメッセージの一時保存用のディスク容量が有限であることです。この制限により、データが最終的に失われるまでにバースト、障害、またはメンテナンスイベントが継続できる期間が制限されます。データ損失後もシステム全体は継続できますが、この状況では、個々の記録にデータの欠落部分が生じます。データが欠落しているファイルは再生可能ですが、データが最初に失われた時点までしか再生できません。以下に注意してください。

• 各サーバー、特にSession Recording Serverにディスク容量を追加し、それをMSMQで利用できるようにすることで、バーストや障害に対する耐性を高めることができます。

• 各Session Recording Agentのメッセージライフ設定を適切なレベルに構成することが重要です（Session Recording Agent PropertiesのConnectionsタブ）。デフォルト値の7,200秒（2時間）は、各記録データメッセージがStorage Managerに到達するまでに2時間あり、それを過ぎると破棄され、記録ファイルが破損することを意味します。利用可能なディスク容量が多い場合（または記録するセッションが少ない場合）は、この値を増やすことができます。最大値は365日です。

MSMQのもう1つの制限は、データがバックログされると、データメッセージの読み書きのためにキューで追加のディスクIOPSが発生することです。通常の状態では、Storage Managerはデータメッセージがディスクに書き込まれることなく、ネットワークから直接データを受信して処理します。データの保存には、記録されたセッションファイルを追加するディスクへの単一の書き込み操作が含まれます。データがバックログされると、ディスクIOPSは3倍になります。各メッセージはディスクに書き込まれ、ディスクから読み取られ、ファイルに書き込まれる必要があります。Storage ManagerはIOPSに大きく依存しているため、メッセージのバックログがクリアされるまでSession Recording Serverの処理レートは低下します。この追加のIOPSの影響を軽減するには、次の推奨事項を採用してください。

• MSMQがメッセージを保存するディスクが、記録ファイルストレージフォルダーとは異なることを確認してください。IOPSバスのトラフィックが3倍になったとしても、実際の処理レートの低下はそれほど深刻ではありません。

• 計画的な停止はオフピーク時のみにしてください。予算の制約に応じて、高可用性サーバーを構築するための認識されたアプローチに従ってください。このアプローチには、UPS、デュアルNIC、冗長スイッチ、ホットスワップ可能なメモリとディスクの使用が含まれます。

予備容量の設計

記録されたセッションデータのデータレートは均一である可能性が低く、バーストや障害が発生する可能性があり、メッセージバックログのクリアはIOPSの点でコストがかかります。このため、各Session Recording Serverは十分な予備容量を持って設計してください。後のセクションで説明するように、サーバーを追加したり、既存のサーバーの仕様を改善したりすることで、常に余分な容量が得られます。一般的な経験則として、各Session Recording Serverは総容量の最大50%で実行するようにします。前の例では、サーバーが5.0 Mbpsを処理できる場合、システムは2.5 Mbpsでのみ実行するように目標を設定します。1つのSession Recording Serverで3.5 Mbpsを生成する5,000のOutlookセッションを記録する代わりに、約2.5 Mbpsを生成する3,500のセッションに減らします。

バックログとライブ再生

ライブ再生とは、レビュー担当者がセッションがアクティブな間に再生のためにセッション録画を開くことです。ライブ再生中、セッションを担当するSession Recording Agentはそのセッションのストリーミングモードに切り替わり、録画データは内部バッファリングなしでStorage Managerに即座に送信されます。録画ファイルは常に更新されるため、Playerはライブセッションからの最新データを継続的に取得できます。ただし、AgentからStorage Managerに送信されるデータはMSMQを介しているため、前述のキューイングルールが適用されます。このシナリオでは問題が発生する可能性があります。MSMQがバックログ状態になると、ライブ再生で利用可能な新しい録画データは、他のすべてのデータメッセージと同様にキューに入れられます。レビュー担当者は引き続きファイルを再生できますが、最新のライブ録画データの表示は遅延します。ライブ再生がレビュー担当者にとって重要な機能である場合は、展開に予備容量とフォールトトレランスを設計することで、バックログの発生確率を低く抑えてください。

シトリックス バーチャル アプリ™ アンド デスクトップ のスケーラビリティ

Session Recordingは、セッションのパフォーマンスを低下させたり、録画データのバックログに応じてセッションを停止させたりすることはありません。エンドユーザーエクスペリエンスとシングルサーバーのスケーラビリティの維持は、Session Recordingシステムの設計において最も重要です。録画システムが回復不能なほど過負荷になった場合、録画されたセッションデータは破棄されます。Citrixによる広範なスケーラビリティテストの結果、ICAセッションの録画がCitrix Virtual Apps and Desktopsサーバーのパフォーマンスとスケーラビリティに与える影響は低いことが明らかになっています。影響の大きさは、プラットフォーム、利用可能なメモリ、および録画されるセッションのグラフィックの性質によって異なります。以下の構成では、シングルサーバーのスケーラビリティへの影響は1%から5%の間になると予想されます。言い換えれば、Session Recordingがインストールされていないサーバーが100人のユーザーをホストできる場合、インストール後は95～99人のユーザーをホストできます。

• マルチセッションOS VDAを実行する8 GB RAM搭載の64ビットサーバー
• OutlookやExcelなどのOffice生産性向上アプリケーションを実行するすべてのセッション
• アプリケーションの使用がアクティブかつ継続的であること
• Session Recordingポリシーで構成されているとおりにすべてのセッションが録画されること

録画されるセッションが少ない場合や、セッションアクティビティが継続的ではなく散発的である場合、影響は少なくなります。多くの場合、スケーラビリティへの影響はごくわずかで、サーバーあたりのユーザー密度は変わりません。前述のとおり、影響が少ないのは、各VDAにインストールされているSession Recordingコンポーネントの処理要件が単純であるためです。録画データはICAセッションスタックから抽出され、MSMQを介してSession Recording Serverにそのまま送信されます。データの高価なエンコードは行われません。

セッションが録画されていない場合でも、Session Recordingを使用するとわずかなオーバーヘッドが発生します。影響は低いものの、特定のサーバーからセッションが録画されないことが確実な場合は、そのサーバーでの録画を無効にできます。Session Recordingを削除する方法が1つです。より侵襲性の低いアプローチは、Session Recording Agent PropertiesのSession Recordingタブで、このVDAマシンでセッション録画を有効にするチェックボックスをオフにすることです。将来セッション録画が必要になった場合は、このチェックボックスを再度選択してください。

スループットの測定

送信側VDAから受信側Session Recording Serverへの録画セッションデータのスループットを測定する方法はいくつかあります。最も単純で効果的なアプローチの1つは、録画されるファイルのサイズと、Session Recording Serverのディスクスペースが消費される速度を観察することです。ディスクに書き込まれるデータの量は、生成されるネットワークトラフィックの量を密接に反映しています。Windowsパフォーマンスモニターツール（perfmon.exe）には、Session Recordingが提供するいくつかのカウンターに加えて、観察できる標準システムカウンターが多数あります。カウンターは、スループットの測定、ボトルネックとシステムの問題の特定に使用できます。次の表は、最も有用なパフォーマンスカウンターの一部を示しています。

セッションレコーディングサーバーのハードウェア

Session Recording Serverに使用するハードウェアを慎重に選択することで、展開の容量を増やすことができます。選択肢は2つあります。スケールアップ（各サーバーの容量を増やす）またはスケールアウト（サーバーを追加する）です。どちらの選択肢でも、目標は最小限のコストでスケーラビリティを向上させることです。

スケールアップ

単一のSession Recording Serverを検討する際は、利用可能な予算で最適なパフォーマンスを確保するために、以下のベストプラクティスを考慮してください。システムはIOPSに依存します。これにより、ネットワークからディスクへの記録データの高いスループットが保証されます。そのため、適切なネットワークおよびディスクハードウェアへの投資が重要です。高性能なSession Recording Serverには、デュアルCPUまたはデュアルコアCPUが推奨されますが、それ以上のスペックにしてもほとんどメリットはありません。64ビットプロセッサアーキテクチャが推奨されますが、x86プロセッサタイプも適しています。4 GBのRAMが推奨されますが、これもまた、それ以上追加してもほとんどメリットはありません。

スケールアウト

最高のスケールアッププラクティスを用いても、多数のセッションを記録する際に単一のSession Recording Serverで達成できるパフォーマンスとスケーラビリティには限界があります。負荷に対応するために、追加のサーバーが必要になる場合があります。複数のSession Recording Serverを異なるマシンにインストールして、Session Recording Serverをロードバランシングプールとして機能させることができます。この種の展開では、Session Recording Serverはストレージとデータベースを共有します。負荷を分散するには、Session Recording Agentをワークロード分散を担当するロードバランサーにポイントします。

ネットワーク容量

100 Mbpsのネットワークリンクは、Session Recording Serverの接続に適しています。ギガビットイーサネット接続はパフォーマンスを向上させる可能性がありますが、100 Mbpsリンクの10倍のパフォーマンスが得られるわけではありません。実際には、スループットの向上は大幅に少なくなります。

Session Recordingで使用されるネットワークスイッチが、利用可能なネットワーク帯域幅を競合する可能性のあるサードパーティアプリケーションと共有されていないことを確認してください。理想的には、ネットワークスイッチはSession Recording Server専用に使用されます。ネットワークの輻輳がボトルネックであることが判明した場合、ネットワークのアップグレードはシステムの拡張性を高める比較的安価な方法です。

ストレージ

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

データは、ローカルディスクコントローラーによってRAIDとして制御されるか、SANとして制御される一連のローカルディスクに保存します。

注：

SMBやNFSなどのファイルベースプロトコルに基づくNASにデータを保存すると、パフォーマンスとセキュリティに影響を与える可能性があります。セキュリティ上の問題を回避し、適切なパフォーマンスを確保するために、プロトコルの最新バージョンを使用し、スケールテストを実行してください。

ローカルドライブのセットアップでは、内蔵キャッシュメモリを備えたディスクコントローラーを目指してください。キャッシュにより、コントローラーはライトバック中にエレベーターソートを使用でき、ディスクヘッドの移動を最小限に抑え、物理ディスク操作の完了を待たずに書き込み操作が完了することを保証します。これにより、最小限の追加コストで書き込みパフォーマンスを大幅に向上させることができます。ただし、キャッシュは停電後のデータ損失の問題を引き起こします。データとファイルシステムの整合性を確保するために、キャッシュディスクコントローラー用のバッテリーバックアップ機能を検討してください。これにより、停電が発生した場合でもキャッシュが維持され、最終的に電源が復旧したときにデータがディスクに書き込まれることが保証されます。

適切な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製品も現在利用可能です。ディスクドライブ製品の仕様を評価する際には、ディスクの回転速度やその他のパフォーマンス特性を考慮してください。

1日に数千ものセッションを記録すると、大量のディスク容量を消費する可能性があるため、全体的な容量とパフォーマンスのどちらかを選択する必要があります。前述の例では、8時間の勤務時間中に5,000のOutlookセッションを記録すると、約100 GBのストレージ容量を消費します。10日分の記録（つまり、50,000個の記録済みセッションファイル）を保存するには、1,000 GB（1 TB）が必要です。ディスク容量へのこの負担は、古い記録をアーカイブまたは削除する前に保持期間を短縮することで軽減できます。1 TBのディスク容量が利用可能な場合、7日間の保持期間は妥当であり、ディスク容量の使用量が約700 GBに保たれ、忙しい日のためのバッファとして300 GBが残ります。Session Recordingでは、ICLDBユーティリティを使用してファイルのアーカイブと削除がサポートされており、最低2日間の保持期間があります。ピーク時以外の時間に1日1回実行されるバックグラウンドタスクをスケジュールできます。ICLDBコマンドとアーカイブの詳細については、「データベースレコードの管理」を参照してください。

ローカルドライブとコントローラーを使用する代わりに、ブロックレベルのディスクアクセスに基づくSANストレージソリューションを使用する方法があります。Session Recordingサーバーにとって、ディスクアレイはローカルドライブとして表示されます。SANはセットアップに費用がかかりますが、ディスクアレイが共有されるため、管理が簡素化され一元化されるという利点があります。SANには主に2つのタイプがあります。Fibre ChannelとiSCSIです。iSCSIは本質的にTCP/IP上のSCSIであり、Gbイーサネットの導入以来、Fibre Channelよりも人気を集めています。

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

Session Recordingデータベースには、Microsoft SQL Server 2019、Microsoft SQL Server 2017、Microsoft SQL Server 2016、Microsoft SQL Server 2014、Microsoft SQL Server 2012、またはMicrosoft SQL Server 2008 R2が必要です。データベースに送信されるデータ量は少量です。これは、データベースが記録されたセッションに関するメタデータのみを保存するためです。記録されたセッションのファイル自体は、別のディスクに書き込まれます。通常、各記録済みセッションはデータベース内で約1 KBのスペースしか必要としません。ただし、Session RecordingイベントAPIを使用して検索可能なイベントをセッションに挿入する場合は除きます。

Microsoft SQL Server 2019、Microsoft SQL Server 2017、Microsoft SQL Server 2016、Microsoft SQL Server 2014、Microsoft SQL Server 2012、およびMicrosoft SQL Server 2008 R2のExpress Editionでは、データベースサイズが10 GBに制限されています。記録セッションあたり1 KBの場合、データベースは約4,000,000セッションをカタログ化できます。Microsoft SQL Serverの他のエディションにはデータベースサイズの制限がなく、利用可能なディスク容量によってのみ制限されます。データベース内のセッション数が増加しても、データベースのパフォーマンスと検索速度の低下はごくわずかです。

Session RecordingイベントAPIを介してカスタマイズを行わない場合、各記録済みセッションは4つのデータベーストランザクションを生成します。記録開始時に2つ、記録中のセッションにユーザーがログオンしたときに1つ、記録終了時に1つです。Session RecordingイベントAPIを使用してセッションをカスタマイズする場合、記録された検索可能なイベントごとに1つのトランザクションが生成されます。最も基本的なデータベース展開でも毎秒数百のトランザクションを処理できるため、データベースへの処理負荷が問題になる可能性は低いでしょう。その影響は十分に軽微であるため、Session Recordingデータベースは、Citrix Virtual Apps and Desktopsデータストアデータベースを含む他のデータベースと同じSQL Server上で実行できます。

Session Recording展開で数百万もの記録済みセッションをデータベースにカタログ化する必要がある場合は、SQL Serverのスケーラビリティに関するMicrosoftのガイドラインに従ってください。