Skip to main content

 

 

 

 
Language:

 

 
 
 
OutSystems

OutSystemsプラットフォームのサーバーのディスク領域の使用と管理に関するガイド

固定リンク: www.outsystems.com/goto/disk-space-usage-guide

はじめに

この記事では、OutSystems Platform Serverがオブジェクトを保存するときにディスクをどのように使用するかについて説明して、ユーザーがディスク領域の使用について理解し、制御および管理できるようにします。

一般的な最大ディレクトリの把握

最初に、.NETスタックバージョンのプラットフォームでPlatform Serverがインストールされている場合に、Platform Serverのインストールディレクトリで一般的に最もサイズが大きくなるフォルダの場所について説明します。開発インフラのサイズ、環境の目的、フォルダにもよりますが、こうした場所はそれぞれ10分の数GBに達する可能性があります。

以下の表には、多くのディスク領域を使用しがちな各フォルダに保存される内容についての詳細な情報を掲載しました。各フォルダの目的と、存在するサーバープロファイルおよび環境タイプも示しています。この表では、以下のサーバープロファイルを考慮します。

  • コントローラ: コントローラは、1-Click Publishプロセスを処理するサーバーです。ここでは、フロントエンドサーバーロールを持たない純粋なコントローラを想定しています。

  • フロントエンド: OutSystemsアプリケーションのランタイム実行を処理するサーバーです。ここに、アプリケーションがデプロイされます(Public AreaまたはPersonal Area)。

コンテンツのタイプ 説明 場所
完全コンパイルのキャッシュ
  • 生成済みソースコード(.oml、.cs、.csprojなど)のファイル
  • アプリケーションリリースのバイナリファイル(.dll、.aspx、.asmxなど)
  • 完全コンパイルのアプリケーションリソースファイル(.js、.css、.png、.gifなど)
パス: <Platform Server>\share\<eSpace名>\full
コントローラ内: あり
フロントエンド内: なし
環境タイプ: すべて
リリースアプリケーションファイルのパッケージ(zip) パス: <Platform Server>\share\<eSpace名>
コントローラ内: あり
フロントエンド内: なし
環境タイプ: すべて
部分コンパイルのキャッシュ
  • 生成済みソースコード(.oml、.cs、.csprojなど)のファイル
  • アプリケーションリリースのバイナリファイル(.dll、.aspx、.asmxなど)
  • eSpaceを実行/デバッグする各開発者用に部分コンパイルされたアプリケーションリソースファイル(.js、.css、.png、.gifなど)
パス: <Platform Server>\share\<eSpace名>\partial\<開発者>コントローラ内: あり
フロントエンド内: なし
環境タイプ: デバッグが有効になっているすべての環境タイプ
リリースアプリケーションファイル
  • フロントエンドのアプリケーションサーバー(IIS)での読み込み用にデプロイされたすべてのリリースアプリケーションファイル。
    これらのファイルには、このeSpaceのすべてのアプリケーションファイル(.dll、.aspx、.asmx、.js、.css、画像、その他の含まれるリソース)が含まれます。
  • アプリケーション間で共有されるすべてのアプリケーションコンパイルファイル(DLLおよびJAR)は、\repositoryフォルダに保存されている実際のファイルへのハードリンクです。
パス: <Platform Server>\running\<eSpace名>.<バージョンID>
コントローラ内: なし
フロントエンド内: あり
環境タイプ: すべて
アプリケーション間で共有されるすべてのアプリケーションコンパイルファイル(DLLおよびJAR)は、プラットフォームの他のライブラリとともに共有サーバーライブラリに保存されます。
これが\runningフォルダのすべてのプロデューサアプリケーションのDLL/JARのローカルコピーの代わりになることで、必要なディスク領域とフロントエンドサーバーに配布すべきファイルの数を減らすことができます。
パス: <Platform Server>\repository\
コントローラ内: あり
フロントエンド内: あり
環境タイプ: すべて
Personal Test Areaファイル 特定のユーザーが実行/デバッグしている特定のバージョンのすべてのリリースアプリケーションファイル。
これらのファイルには、このeSpaceのすべてのアプリケーションファイル(.dll、.aspx、.asmx、.js、.css、画像、その他の含まれるリソース)が含まれます。
パス: <Platform Server>\test\<eSpace名>\<開発者>コントローラ内: なし
フロントエンド内: あり
環境タイプ: デバッグが有効になっているすべての環境タイプ
一時ASP.Netファイル これらのファイルはPlatform Serverではなく.Net Frameworkによって自動的に生成されますが、あらゆるASP.NETアプリケーションの一部となります。 パス: C:\windows\microsoft.net\framework\v4.0.30319\Temporary Asp.Net Files\<eSpace名>またはC:\windows\microsoft.net\framework64\v4.0.30319\Temporary Asp.Net Files\<eSpace名>
コントローラ内: なし
フロントエンド内: あり
環境タイプ: すべて

1つのサーバーが両方のロールを持つことができます。その場合は、両方のサーバーロールのコンテンツを保持します。通常、非本番環境は本番環境より多くのディスク領域を使用します。この主な原因は開発者の数であり、デバッグ用のPersonal Test Areaです。

削除できるフォルダコンテンツ

極論すると、アプリケーションが単一のOMLファイルとエクステンションによって定義されるPlatform Serverのアーキテクチャに基づいて、どのようなフォルダのコンテンツでも削除することができます。また削除後に1-Click Publishなどの内部プロセスで復旧することができます。しかし、お気付きのとおり、このプロセスは時間がかかるため、ほとんどの環境では推奨されません。各コンテンツを削除した場合の副作用の詳細を以下に示します。

コンテンツのタイプ 削除した場合の副作用 復旧方法
完全コンパイルのキャッシュ このコンパイルのキャッシュは、参照を含むモジュールを1-Click Publishする際やデバッグする際に使用されます。Platform Serverは、この場所からプロデューサ参照を取得します。これらがこの場所にないと、参照の破損によるコンパイルエラーまたは実行時エラーがコンシューマeSpaceで発生する可能性があります。 プロデューサモジュールの1-Click Publishを実行し、プロデューサのコンパイルキャッシュを再作成する必要があります。最善の方法は、Service Centerでオールコンテンツソリューションを作成してパブリッシュすることです。
部分コンパイルのキャッシュ このコンパイルのキャッシュは、デバッグ用のPersonal Test Areaを作成するときに使用されます。これがないと、デバッグプロセスが影響を受けます。 モジュールのデバッグを再試行すると、部分コンテンツが再度作成されます。
リリースアプリケーションファイル これらは結果のOutSystemsアプリケーションファイルで、IISアプリケーションサーバーでマッピングされます。これらがないと、アプリケーションがオフラインになります。このフォルダのコンテンツを維持する自動的な内部スレッドがあるため、これが削除されることはありません。 すべてのモジュールを再度デプロイし、アプリケーションファイルを復元する必要があります。これを行うには、サーバーでOutSystems Deployment Serviceを再起動するか、Service CenterでAll Contentソリューションの1-Click Publishを実行するか、Service Centerで各モジュールの[Re-deploy]ボタンを使用します。
Personal Test Areaファイル これらは各モジュールおよび開発者のPersonal Test Areaの実際のアプリケーションファイルです。これらを削除すると、開発者がWebブラウザでアプリケーションにアクセスして実行/デバッグを行うことができなくなります。 開発者が自分のモジュールのPersonal Test Areaを復元するには、Service Studioで実行/デバッグを再度行う必要があります。
一時Asp.Netファイル これらはIISによってメモリに読み込まれる実際のASP.NETアプリケーションファイルで、使用中はIISが停止するまで削除できません。これらのファイルを削除すると、アプリケーションの最初のロードが遅くなります。 アプリケーションへの初回アクセス時にIISによって自動的に生成されます。

そのため、上記の表に基づき、一部のコンテンツの削除を試みなければならないほどサーバーのディスク領域の使用量に関して懸念がある場合は、以下の手順を実行します。

  • 一時ASP.NETファイルを定期的に(毎日または毎週)クリーンアップします。

  • 開発者と連携して、開発環境で定期的に(毎週または毎月)Personal Test Areaファイルをクリーンアップし、最終的には部分コンパイルキャッシュをクリーンアップします。

  • 完全コンパイルのキャッシュリリースアプリケーションファイルを定期的に削除することは絶対に避けます。特定の状況でこれが必要になり、All Contentソリューションをパブリッシュする予定がある場合は、関係するチームとの調整が必要になることがありますが、リリースアプリケーションファイルを削除するとアプリケーションのダウンタイムが発生するため、適切にスケジュールを設定する必要があることに留意してください。

推奨されるディスクサイズ

最後に、推奨されるディスクサイズをいくつか示します。

開発インフラのディスク領域の使用量は、アプリケーションオブジェクトやソフトウェアユニット、eSpace、1つの環境で作業する開発者の数によって大きく変動するため、簡単には予測できません。また、アプリケーションのタイプ(およびそのアプリケーションに含まれるリソース)によってどのようなメトリックにもオフセットが発生する可能性があります。これまでの経験と、ディスクのフラグメント化が与えるサーバーパフォーマンスへの影響を鑑み、アプリケーションオブジェクト/ソフトウェアユニットのメトリックのみに注目した場合、以下の使用量を推奨します。

  • 小規模開発インフラ(アプリケーションオブジェクト数が250未満/ソフトウェアユニット数が150,000未満)の場合は36GB

  • 中規模開発インフラ(アプリケーションオブジェクト数が500未満/ソフトウェアユニット数が300,000未満)の場合は73GB

  • 大規模開発インフラ(アプリケーションオブジェクト数が500以上/ソフトウェアユニット数が300,000以上)の場合は146GB

これまでのところ、非本番環境と本番環境のいずれの場合もこれで十分です。最終的には、優れたベストプラクティスとして、システムドライブのフラグメント化を避けるため、システムパーティションとは別のパーティションにPlatform Serverをインストールします。

リリースアプリケーションファイルの自動クリーンアッププロセス

OutSystems Deployment Serviceは、runningディレクトリの自動クリーンアッププロセスを定期的に実行します。このサービスでは、IISの仮想ディレクトリによって現在使用されていない<Platform Server>\running\内のフォルダがすべて削除されます。現在のデフォルトは以下のとおりです。

  • 開発環境(サーバーモード = Development)では、15分以上前の古いフォルダを消去します。

  • 本番環境(サーバーモード = Production)では、24時間以上前の古いフォルダを消去します。

さらにこのサービスでは、<Platform Server>\repository\内にある、フロントエンドのアプリケーションによって使用されていない、作成から30分以上が経過した古いコンパイル済みアプリケーションファイルも削除します。

これらの値を微調整する必要がある場合は、OutSystems Supportに、デフォルトを変更する方法に関するソリューションについてお問い合わせください。

クリーンアップスレッドの期間は、Service Centerの[Monitoring]ページで設定することができます。Deployment Serviceの詳細にアクセスすると、Unused Folders Removalスレッドと最後の実行からの時間が表示されます。

ログに関しては、削除されたものがあれば、(システムの)eSpaceでこのクリーンアップスレッドに関するGeneralログを確認できます。OSTrace(オンプレミス環境の場合のみ)でもこのアクティビティを監視できます。