--- schema_version: "1" id: 501229055f0c1beb1b26b285c60e2aa42daacda9ba858cff2be3a1d3b299e039 title: CloudHub 2.0 オペレーティングシステムのパッチ更新 collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/cloudhub-2/ch2-patch-updates.md canonical_url: https://docs.mulesoft.com/jp/cloudhub-2/ch2-patch-updates source_site: docs.mulesoft.com content_type: documentation content_hash: b854621a9eb11157fb1141e254400f26728e8986b4ae997017b2e61666f41912 description: MuleSoft Documentation Site latest: true --- # CloudHub 2.0 オペレーティングシステムのパッチ更新 CloudHub 2.0 はサービスとしてのインテグレーションプラットフォーム (iPaaS) であり、オペレーティングシステムのパッチ設定を自動で管理するため、ユーザーはアプリケーションの開発と更新に集中できます。 CloudHub 2.0 によって必要に応じてセキュリティパッチが適用されるため、アプリケーションが保護されます。 パッチ更新では、ローリング更新デプロイメントモデルを使用するアプリケーションに青/緑デプロイメントを使用し、それをサポートするアプリケーションのダウンタイムをゼロにしています。 CloudHub 2.0 では、MuleSoft が管理する 2 つのデプロイメントプラットフォームに継続的な更新を適用します。 - US クラウド - EU クラウド ## [](#cloudhub-2-0-インフラストラクチャの更新)CloudHub 2.0 インフラストラクチャの更新 コンテナベースのプラットフォームである CloudHub 2.0 は、必要に応じてインフラストラクチャ修正とセキュリティパッチが適用されるため、インフラストラクチャが保護され、最新の状態に保たれます。パッチ更新では、ローリングアップグレードデプロイメントが使用され (デプロイメントモデルとして選択されている場合)、オペレーティングシステムの変更または内部ソフトウェアへの変更が含まれる場合があります。ローリング更新デプロイメントモデルを使用している場合、更新により基盤となるホストの段階的な循環、ドレイン、置換が行われるため、ダウンタイムがゼロになります。アップグレード中に、Mule アプリケーションが新しいセキュアホスト上で再起動される場合があります。Mule ワーカーが複数のレプリカで実行されていない場合、または再作成デプロイメントモデルを使用している場合、わずかなダウンタイムが発生します。 更新が利用可能になると、CloudHub 2.0 はそれを新しい非公開スペースのデフォルトとして本番環境に含めます。既存のインフラストラクチャパッチスケジュールは、​[CloudHub 2.0 Runtime パッチ](https://docs.mulesoft.com/jp/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes)​と同じメンテナンス期間で実行されます。インフラストラクチャと Runtime の更新により、アプリケーションの再起動が行われる場合があります。 CloudHub 2.0 で使用される ​[Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-maintenance)​ は、継続的にアップグレードされます。新しい更新が利用可能になるたびに、サービスレベル契約内で VPN にパッチが適用されます。Anypoint VPN が高可用性としてセットアップされていない場合、または非高可用性 VPN が 2 つのトンネルを使用してセットアップされていない場合、ダウンタイムが予想されます。 ### [](#クラスタリングされたレプリカとローリング更新)クラスタリングされたレプリカとローリング更新 [クラスター](https://docs.mulesoft.com/jp/cloudhub-2/ch2-clustering)​で Mule を実行している場合、Hazelcast バージョンの変更を含む Mule Runtime バージョンのローリング更新を行うと、クラスターに異なる Hazelcast バージョンを持つ複数のメンバーが存在することになる可能性があります。 その結果、各種 Hazelcast バージョンに互換性がない場合、Hazelcast のシリアル化エラーによってアプリケーションが失敗することがあります。 このようなエラーを防ぐには、再作成更新戦略を使用します。 ## [](#self-upgrade-schedule)インフラストラクチャアップグレードのスケジュール (省略可能) リリースが使用可能になってから​[月 1 回の更新テーブル](https://docs.mulesoft.com/jp/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes)​に記載されている自動更新日までの間に、スケジュールされたパッチプロセスよりも早くインフラストラクチャアップグレードをスケジュールします。こうすることで、組織にとって都合の良い将来日付を選択できます。 平均で、このアップグレードが完了するには 30 ～ 60 分かかります。アップグレードがキューに登録されている場合は、30 分以上かかる場合があります。実行中のアプリケーションに対するアップグレードプロセスの影響は、前のセクションに記されている自動パッチ適用の動作と同じです。 スケジュールされたアップグレードは、まだ進行中でなければ変更または削除できます。これは、​`[Queued (キューに登録済み)]`​ 状況で確認できます。スケジュールをキャンセルした場合、別のスケジュールを作成するか、以前のアップグレードにオプトインしないと、必須のパッチ適用期間中にアップグレードが発生します。 ### [](#runtime-manager-でアップグレードをスケジュールする)Runtime Manager でアップグレードをスケジュールする 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 非公開スペースでアップグレードが可能になったら、​**\[Infra Status (インフラ状況)\]**​ 列に ​**\[Upgrade Available (アップグレードが使用可能)\]**​ 状況が表示されます。 2. **\[Schedule an Upgrade (アップグレードをスケジュール)\]**​ をクリックします。 3. 非公開スペースをアップグレードする日付を選択します。 アップグレードは選択した日付の 00:00 UTC に実行されます。 4. チェックボックスをオンにして、早期のアップグレードに同意することを確定します。 5. **\[Upgrade (アップグレード)\]**​ をクリックします。 アップグレードを適用したら、​**\[Infra Status (インフラ状況)\]**​ 列ので状況を確認できます。 ## [](#早期インフラストラクチャアップグレードへのオプトイン-省略可能)早期インフラストラクチャアップグレードへのオプトイン (省略可能) リリースが使用可能になってから​[月 1 回の更新テーブル](https://docs.mulesoft.com/jp/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes)​に記載されている自動更新日までの間に、スケジュールされたパッチプロセスよりも早くインフラストラクチャアップグレードを適用します。こうすることで、組織にとって都合の良いタイミングを選択できます。 平均で、このアップグレードが完了するには 30 ～ 60 分かかります。アップグレードがキューに登録されている場合は、30 分以上かかる場合があります。実行中のアプリケーションに対するアップグレードプロセスの影響は、前のセクションに記されている自動パッチ適用の動作と同じです。
このアップグレードは元に戻すことができます。必ずアップグレードの影響を理解してから、本番環境で適用する前に組織のニーズに基づいてアップグレードをトリガーするタイミングを選択してください。
### [](#runtime-manager-を使用してオプトインアップグレードを適用する)Runtime Manager を使用してオプトインアップグレードを適用する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 非公開スペースでアップグレードが可能になったら、​**\[Infra Status (インフラ状況)\]**​ 列に ​**\[Upgrade Available (アップグレードが使用可能)\]**​ 状況が表示されます。 2. **\[Upgrade available (使用可能なアップグレード)\]**​ をクリックします。 3. **\[Upgrade now (今すぐアップグレード)\]**​ をクリックして、早期アップグレードにオプトインします。 4. **\[Upgrade (アップグレード)\]**​ をクリックします。 アップグレードを適用したら、​**\[Infra Status (インフラ状況)\]**​ 列ので状況を確認できます。 ### [](#api-を使用してアップグレードをスケジュールまたは適用する)API を使用してアップグレードをスケジュールまたは適用する 非公開スペースのアップグレード API を使用して非公開スペースをアップグレードできます。詳細は、Exchange の [「Upgrade Private Space API (非公開スペース API のアップグレード)」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/minor/1.0/console/endpoint/%232428/)​ドキュメントを参照してください。 ## [](#runtime-updates)月 1 回の日付パッチ更新 各月の最初の 1 週間に、MuleSoft では​_日付パッチ更新_​をリリースします。これには、Mule Runtime Engine で発見された問題を解決するための後方互換性があるバグ修正が含まれています。 スケジュールされた日付がセキュリティ SLA 内であれば、月 1 回の日付パッチ更新にセキュリティパッチが含まれる場合もあります。 月 1 回のパッチでは、アプリケーションがパッチバージョンの最新の日付パッチのみに更新されます。 パッチバージョン番号は変更されません。 これらの 4.3.x または 4.4.x バージョンへの更新のバージョン番号の形式は次のようになります。 _メジャー_​._マイナー_._パッチ_​ : _日付_ パッチ日付が含まれるバージョン番号の例を示します。 `4.4.0:20211015` Mule 4.5 以降、MuleSoft は Edge と長期サポート (LTS) という 2 つの新しいリリースチャネルを導入します。新しいリリースチャネルの Mule Runtime バージョン設定スキーマは次のとおりです。 _メジャー\[数値\] .マイナー\[数値\] . パッチ\[数値\] : ビルド\[数値\] チャネル\[Edge の場合は e、LTS の場合はなし\]_ これらの値の例としては、Edge の場合は ​`4.5.0:1e`​、LTS の場合は ​`4.6.0:1`​ となります。 詳細は、[Edge and LTS Releases for Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence)を参照してください。 ### [](#更新スケジュール)更新スケジュール - 月の第 1 週に MuleSoft によって日付パッチがリリースされます。 - 月の第 3 週に MuleSoft によってその月の第 1 週にリリースされた日付パッチが自動的に適用されます。 - 本番以外の環境のアプリケーションは週内に更新されます。 - 本番環境のアプリケーションは週末に更新されます。 自動更新が行われた場合、アプリケーションの監査ログにはユーザー Anypoint Staff によるエントリが追加され、更新が行われた日時と更新に成功したかどうかが示されます。 更新に成功した場合、アクションは必要ありません。アプリケーションでダウンタイムなしの更新がサポートされないか、手動での更新が必要な場合、月の第 1 週にリリースされた日付パッチを第 1 週または第 2 週に手動で適用できます。​[手動でのランタイムバージョンの更新](#update-the-runtime-version-manually)​を参照してください。 ## [](#mule-用の-edge-および-lts-リリース)Mule 用の Edge および LTS リリース Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel Type Release Cadence Differentiators Support Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support
If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).
For information about the monthly patch update process, see Update Patches to Mule.
## [](#edge_channel)Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## [](#lts_channel)LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. For CloudHub and CloudHub 2.0 customers, once Standard Support for Mule 4.4 ends, if you want to deploy new apps, you must do so on Mule 4.6 LTS or Mule 4.8 Edge. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## [](#switch-from-an-edge-version-to-an-lts-version)Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## [](#mule-runtime-リリースケイデンスサポート)Mule Runtime リリースケイデンスサポート 次の表に、CloudHub 2.0 の Mule Runtime リリースケイデンスサポートを示します。
Mule Version Release Date Java Version End of Standard Support End of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024
MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility with Java 8, 11, and 17.
CloudHub または CloudHub 2.0 ユーザーが Anypoint Studio で Mule 4.6 アプリケーションを作成またはテストする場合、必要な Studio バージョンは 3 月の次に予定されているリリースになります。一方、MuleSoft では、2 月 14 日から 4 月 19 日まで API、Mule Maven プラグイン、Anypoint Platform CLI を介して Mule Runtime 4.5e バージョンに新しいアプリケーションをデプロイできます。CloudHub および CloudHub 2.0 アプリケーションでは、2 月ではなく 4 月に Mule 4.5 Edge から Mule 4.6 Edge への自動アップグレードが実行されます。 「Mule 4.5 Edge の自動アップグレードおよび新しいアプリケーションデプロイメントの一時的な変更」​を参照してください。
## [](#deployment-models-and-application-lifecycle-management)Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
アクション CloudHub 2.0

新規アプリケーションのデプロイ

Deploy to the latest minor-patch version available under Standard Support of each channel.

自動アップグレード

MuleSoft applies two distinct types of automatic updates:

  • Auto-patching (within the same minor version): Every month, apps in both the Edge and LTS channels are automatically updated to the latest available patch of their current minor version, as long as the app’s TLS version is compatible with the new patch. For example, an app can be updated from Mule 4.9.19 to 4.9.20. Monthly auto-patching doesn’t change the minor version. Patches are backward compatible and include bug fixes and security updates. Security updates can also be applied outside the regular schedule to address critical vulnerabilities. See the patching schedule for CloudHub and CloudHub 2.0.

  • Auto-upgrade (to a new minor version): When a minor version reaches End of Standard Support, apps are handled differently depending on the release channel:

    • Edge: Apps are automatically upgraded to the latest minor version in the Edge channel. The auto-upgrade occurs six weeks after the version reaches End of Standard Support, during that month’s patching schedule. Before the auto-upgrade, you have a self-upgrade window to move to the new minor version yourself.

    • LTS: Apps aren’t automatically upgraded to a new minor version when the version reaches End of Standard Support. To move to a later LTS minor version, upgrade your application manually. Apps that remain on a version through End of Extended Support are subject to the forced-upgrade behavior described in End of Extended Support.

Runtime version compatibility: Apps running Mule runtime 4.9 or earlier aren’t auto-upgraded to Mule runtime 4.10 or later. Mule 4.10 removes support for TLS 1.0 and 1.1, which can cause compatibility issues and break existing applications if upgraded automatically. Apps running earlier versions, such as Mule 4.6, can be auto-upgraded only as far as the Mule 4.9 release line and are moved to the latest available Mule 4.9 patch. To use Mule runtime 4.10 or later, upgrade your application manually.

自己アップグレード

For apps in the Edge channel, you can manually upgrade during the fixed window after the runtime version reaches End of Standard Support. See patching schedule for CloudHub and CloudHub 2.0.

  • Edge: Six weeks

  • LTS: Manual upgrade only (no automatic minor upgrade schedule)

ロールバック

Available to the previously used version

アプリケーションの再起動

Always

アプリケーションの実行維持

Until End of Extended Support

延長サポートの終了

Shutdown running apps.
Starting with Mule 4.7, CloudHub and CloudHub 2.0 applications in the Edge or LTS channels that are still running End of Life versions will undergo a forced upgrade to the latest version during the monthly upgrade window (See upgrade window for CloudHub and CloudHub 2.0).

廃止

Mule apps don’t reach End of Life because they’re always auto-upgraded.

サポート可能性

All Mule apps are under Standard Support.
## [](#mule-runtime-version-naming-changes)Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. ### [](#cloudhub-2-0)CloudHub 2.0 The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 CloudHub 2.0 では、 regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid Standalone CloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)
The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. ## [](#通知の更新)通知の更新 最新のランタイムバージョンが使用できる場合: - **\[Applications (アプリケーション)\]**​ ページには、アプリケーションの使用可能な更新があるかどうかを示す ​**\[Update Available (更新が使用可能)\]**​ 列が表示されます。 ![ch2 update available column](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-update-available-column.png) - ​**\[Update available (更新が使用可能)\]**​ と新しい使用可能な更新がアプリケーションの ​**\[Settings (設定)\]**​ ページの ​**\[Deployment Target (デプロイメント対象)\]**​ タブに表示されます。 ![ch2 update available field](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-update-available-field.png) MuleSoft によって、パブリッシュされたスケジュールに基づいて更新が自動的に適用されます。 必要があれば、都合に合わせて手動で更新できます。 ## [](#手動でのランタイムバージョンの更新)手動でのランタイムバージョンの更新 1. Anypoint Platform にログインします。 2. Runtime Manager に移動します。 3. Runtime Manager のナビゲーションメニューで ​**\[Applications (アプリケーション)\]**​ をクリックします。 4. 更新するアプリケーションを選択します。 5. **\[Settings (設定)\]**​ の ​**\[Deployment Target (デプロイメント対象)\]**​ タブで、​**\[Runtime Version (ランタイムバージョン)\]**​ ドロップダウンをクリックします。 6. バージョンの最新ビルドを選択します。 7. **\[Deploy (デプロイ)\]**​ をクリックします。 アプリケーションが新しいランタイムバージョンで再デプロイされます。 Edge リリースチャネルを選択すると、次の自動更新の日付を示すバナーが表示されます。 ![Edge リリースチャネルの自動更新の日付を示すバナー。](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-app-edge-auto-update.png) ## [](#ps-status)非公開スペースのアップグレードおよび更新の可能な状況種別 **\[Private Space (非公開スペース)\]**​ ページの ​**\[Infra Status (インフラ状況)\]**​ 列には、非公開スペースのインフラストラクチャのアップグレードの状況が表示されます。
状況 説明

Latest (最新)

非公開スペースでは、最新の使用可能なインフラストラクチャバージョンが実行されています。インフラストラクチャのアップグレードまたは設定の更新は現在行われていません。

Upgrade Available (アップグレードが使用可能)

非公開スペースのアップグレードが使用可能です。アップグレードをすぐに実行するか、アップグレードを開始する時刻をスケジュールできます。

Upgrade Scheduled (アップグレードがスケジュール済み)

非公開スペースのアップグレードが将来日付にスケジュールされています。

Queued (キュー内)

スケジュールまたは起動されたアップグレードがまもなく開始されます。スケジュールの変更やアップグレードの中断を行うことができなくなりました。

Upgrading (アップグレード中)

非公開スペースでは、スケジュールされたか、自己トリガーされたか、月 1 回のインフラストラクチャアップグレードの一環として、インフラストラクチャアップグレードが行われています。

Updating (更新中)

非公開ワークスペースでは、設定の変更によってトリガーされた更新が行われています。

Failed (失敗)

非公開スペースでは、スケジュールされたか、自己トリガーされたか、月 1 回のインフラストラクチャアップグレードの一環として、ユーザー設定の更新、またはインフラストラクチャのアップグレードに関連している可能性がある障害が発生しました。

Degraded (低下)

非公開スペースは、低下状態になっています。

 — 

非公開スペースの状況の詳細を取得できないため、状況が不明です。
## [](#セキュリティの更新)セキュリティの更新 MuleSoft では定期的にスキャンを実行し、JVM および基礎となるオペレーティングシステムのセキュリティ脆弱性を特定し、次の SLA に基づいて自動的にセキュリティパッチを適用します。
重要度レベル 重要度の定義 パッチの適用期間

P0

Critical (重大)

7 日

P1

高

30 日
## [](#更新後のアプリケーション状況の確認)更新後のアプリケーション状況の確認 新しい更新が行われた後で、Runtime Manager の ​**\[Applications (アプリケーション)\]**​ タブの ​**\[Status (状況)\]**​ 列で​[アプリケーション状況の状態](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps#replica-statuses)​を確認できます。 また、アプリケーションログをチェックして、アプリケーションが正しくデプロイされたかどうかを確認し、一部の自動マイナー更新関連の問題が発生した場合に修正アクションを実行することもできます。詳細は、[デプロイ済みアプリケーションのログデータの表示](https://docs.mulesoft.com/jp/cloudhub-2/ch2-view-logs)を参照してください。 ## [](#関連情報)関連情報 - [Edge and LTS Releases for Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence)。