クラスタリングの設定

クラスタ環境では複数の Content Services インスタンスを実装できます。
クラスタはノードの集合です。クラスタリングは、高い拡張性と復元性を実現するために実装されます。他のノードで障害が発生すると冗長ノードを介してサービスが提供されます。これにより、さらなるパフォーマンスの向上が図れます。ロードバランサーと組み合わせて使用すると、サーバーの作業負荷を複数のノードに分散（負荷分散）され、これによりパフォーマンスが強化されます。

アップグレードの前提条件

クラスタ環境で4.2より前のバージョンの Content Services からアップグレードする場合は、いくつかの前提条件があります。
アップグレードする前に、すべてのファイルと構成がバックアップされていることを確認してください。カスタムキャッシュの作成など、これまでに行ったカスタマイズについては、新しい Content Services のクラスタリングインフラストラクチャを使用して再適用することが必要な場合があります。
次に示すライブラリは、Content Services 4.2以降では使用されていないため、アップグレード前にこれらのライブラリに関連する構成を削除しておく必要があります。

• JGroups

• EHCache

注：Content Services 4.2からのアップグレードでは、以下の手順を実行する必要はありません。ここでは、4.2よりも前のバージョンからアップグレードする場合の手順について説明します。

次の手順に従い、バージョン7.0ではサポートされていない構成を削除します。

1. <classpathRoot>ディレクトリを参照します。
   たとえば、Tomcat 7の場合、$TOMCAT_HOME/shared/classes/alfresco/extension/ディレクトリを参照します。

2. ehcache-custom.xml ファイルを削除します。

3. <classpathRoot>ディレクトリを参照します。
   たとえば、Tomcat 7の場合、$TOMCAT_HOME/shared/classes/ディレクトリを参照します。

4. alfresco-global.propertiesファイルを開きます。

5. alfresco-global.propertiesファイルから、次に示すレガシープロパティを削除します。

   • alfresco.ehcache.rmi.hostname

   • alfresco.ehcache.rmi.port

   • alfresco.ehcache.rmi.remoteObjectPort

   • alfresco.jgroups.defaultProtocol

   • alfresco.jgroups.bind_address

   • alfresco.jgroups.bind_interface

   • alfresco.tcp.start_port

   • alfresco.tcp.initial_hosts

   • alfresco.tcp.port_range

   • alfresco.udp.mcast_addr

   • alfresco.udp.mcast_port

   • alfresco.udp.ip_ttl

   • filesystem.cluster.enabled

   • filesystem.cluster.configFile

6. <classpathRoot>ディレクトリを参照します。
   たとえば、Tomcat 7 の場合、$TOMCAT_HOME/shared/classes/alfresco/extensionディレクトリを参照します。
   一元的構成がalfresco.warという展開用アーカイブ内に含まれるようになったため、Hazelcast 構成ファイルである

7. hazelcastConfig.xml は削除します。
   手順5で述べた filesystem.cluster.configFile プロパティは、hazelcastConfig.xmlファイルを参照しています。

8. 上記の手順をすべて実行した後、クラスタリングを開始する場合は、リポジトリサーバークラスタを設定するを参照してください。
   
   

Content Services ソリューションのコンポーネント

ここでは、Content Services ソリューションの主なコンポーネントについて概説します。
ソリューションには、Alfresco Share、Content Services、データベース、インデックス（Solr）、変換、コンテンツストアなどのコンポーネントがあります。次の図に示すように、これらのコンポーネントの中には、クラスタ化できるものもあれば、オプションとして提供されているものもあります。

Open

必要なインストールの数を決め、指定されたコンポーネントをそれぞれどのノードに配置するかを判断することが重要です。

例を挙げてさらに詳しく説明します。アプリケーションに6つのノードがあるとします。理想的には、各ノードに1つずつコンポーネントを配置することが推奨されます。たとえば、node 1 にはデータベース、node 2 にはコンテンツストア、node 3 にはContent Services、node 4 には Alfresco Share、node 5にはSolr、そしてnode 6 には変換サーバーを配置する、といったイメージです。

次の表を、ソリューション設計用のテンプレートとして活用してください。

ただし、分散を別の構成にすることは可能です。分散やクラスタリングのためのソリューションにはそれぞれメリットとデメリットがあります。分散とクラスタリングの最適な構成については、リックソフト株式会社にお問い合わせください。

高可用性と高スループットを実現するためのクラスタリングの開始について理解を深めるために、シナリオ：冗長化を実現するクラスタリングとシナリオ：高スループットを実現するクラスタリングを参照してください。

分割アーキテクチャに関する推奨事項

分散環境またはクラスタ環境で Content Services アーキテクチャを分割する場合、いくつかの推奨事項があります。
一般に、インストールを分散またはクラスタリングすることには、2つの補完的な目的があります。

• 冗長性または高可用性を実現する

• 高パフォーマンスまたは高スループット（またはその両方）を実現する

分割すべき状況とその方法を判断することが重要です。

分割化を必要性とする状況：どのような場合にアーキテクチャを単一ノード環境から分散ノード環境へ分割すべきかを判断するのに役立つ指標がいくつかあります。確認すべき指標の一部を以下に挙げます。

• ディスク領域の不足・・・ディスク領域の不足は、必ずしも分散化を必要としませんが稼働するサーバーの制限によってディスク容量を増やせない場合は、分散化を検討してください。

• メモリ領域の不足・・・・メモリ領域の不足は、必ずしも分散化を必要としませんが稼働するサーバーの制限によってメモリ容量を増やせない場合やメモリ使用領域に限界があった場合などは分散化を検討してください。

• CPU のメモリ不足・・・・CPU のクロック数やコア数など CPU 性能の不足に至った場合は分散化を検討してください。

• インデックス化の負荷増大・・・コンテンツ数を多くなるとインデックス化によってシステムリソースが不足したり、長時間処理となったりする場合はスケールアップ、もしくはスケールアウト（分散化）が必要になります。
  
  

分割する方法：単一ノード環境から分散環境またはクラスタ環境へのアップグレードを決定したら、アーキテクチャのクラスタ化に最も適した方法を特定する必要があります。
クラスタの設定とクラスタへの Solr のインストールについて、次のシナリオを検討してみてください。

シナリオ：冗長化を実現するためのクラスタリング（アクティブースタンバイ）

このシナリオでは、可用性のみを実現します。この方式についてはクラスタリング機能はクラスタソフトウェアに依存するため、クラスタ動作については Hyland 社ではサポート対象外となります。参考までに、このシナリオについて説明します。

このシナリオでは、Alfresco は Node1 でサービスが稼働し、Node2 ではサービスが停止した状態、Alfresco の配下にリポジトリデータベースとコンテンツストアが別々のノード（マシン）、もしくは１つのノード（マシン）で動作しています。

Cluster Software は、Node1 で稼働する Alfresco を監視し、障害を検知したら Node1 をシャットダウンもしくは強制停止させ Node2（Standby）の Alfresco を起動させて継続利用を行います。

この方式では Cluster Software が Node1 から Node2 に切り替えする間はサービスは停止され、クライアントのセッションを切断され、サービス復旧の際には再度ログインが必要になります。

注：この方式はCluster Softwareの動作を説明したものでAlfresco機能ではありません。

Open

シナリオ：冗長化を実現するためのクラスタリング（アクティブーアクティブ）

ここでは、Content Services サービスの冗長性と高可用性を実現するクラスタリングアーキテクチャについて、シナリオに基づいて説明します。
このシナリオでは、リポジトリデータベースとコンテンツストアが1つずつあり、2つの別個のマシンに搭載された Tomcat ノード/ Web サーバーが同時にコンテンツにアクセスしています。この構成では、コンテンツストアまたはデータベースに障害が発生した場合の対策は講じられていませんが、複数のサーバーによって Web の負荷を分散し、サーバー障害に備えた冗長化を実現しています。それぞれのサーバーが、（ローカルコンテンツストア内に）ローカルインデックスを持っています。
これは、最も簡単にセットアップできるクラスタで、小規模なインストールに適しています。連携して動作する2台以上のマシンで構成されるクラスタは、単一ノードと比較し、より高いレベルの可用性、信頼性、拡張性を実現します。

ハードウェアのロードバランサーは、複数のサーバー間でWeb要求を分散処理します。ロードバランサーは、各クライアントがセッション中に常に同じサーバーに接続するように、「固定」セッションをサポートする必要があります。コンテンツストアとデータベースは別々のサーバーに設置されるため、コンテンツストアとデータベースのレプリケーションには別の手段を用いることができます。
注：クラスタ内のすべてのサーバーに、静的IPアドレスが割り当てられている必要があります。

シナリオ：高スループットを実現するためのクラスタリング

ここでは、Content Services サービスのスループットの最大化を実現するクラスタリングアーキテクチャについて、シナリオに基づいて説明します。
このシナリオの構成では、リポジトリデータベースとコンテンツストアが1つずつあります。Content Services/Alfresco Share のノードが4つ、Solrノードが2つあり、これらがすべて同時にコンテンツにアクセスしています。この構成により、より高度な可用性、信頼性、拡張性を実現し、各種サービスのスループットを最大化しています。クラスタ内のノードはロードバランサーの背後に配置され、ロードバランサーは、負荷処理に対する各クラスタメンバーの能力/可用性に基づいて各メンバーに要求を委任します。
各 Share インスタンスは、独自の Tomcat サーブレットコンテナに展開されます。Content Services のサービスと CPU ランタイムのフットプリントが最適化され、このような展開が多数同時実行される中で高いスループットを実現しています。クラスタの前面にあるロードバランサーは、現在の要求に対して最も高い処理能力を持つクラスタメンバーにトラフィックを誘導します。

注：クラスタ内のすべてのサーバーに、静的IPアドレスが割り当てられている必要があります。

この展開シナリオには、以下のフローが存在します。

• クライアントからのアクセスの流れ

  • クライアントは、Share アプリケーションに到達するために、前段ロードバランサーに要求を送信します。

  • 前段ロードバランサーは負荷を分析（※）し、Node1〜Node4 内の1つにクライアントをリダイレクトします。

  • 前段ロードバランサーは JSESSIONID クッキーを使用して、クライアントを Share ノードの1つに固定します。

  • Share は Web スクリプトの要求をローカルリポジトリインスタンスに送り、ページをレンダリングし、そのレンダリングしたページをメインロードバランサーを介してユーザーに返します。

※ロードバランサーの機能によって負荷分散方式は異なります。一般的には「ラウンドロビン」「重み付けラウンドロビン」「最速応答時間」「最小接続数」「アダプティブ」の5つの負荷分散方式がありますが、ロードバランサー側の負荷や可用性を考慮した設計が必要です。

• Content Services の内部フロー

  • リポジトリ間では、キャッシュのレプリケートを実行するための相互通信が、Hazelcast を介して行われます。

  • 各リポジトリは、NFS/SAMBA の共有を介して利用可能な同一のコンテンツストアを共有します。

  • 各リポジトリは同じデータベーススキーマを共有します。

• Solr フロー

  • 追跡層：2つの Solr インスタンスが定期的にリポジトリに問い合わせを行うことにより、新しいトランザクションを検出し、新しいコンテンツを取得し、ローカルインデックスを構築します。追跡は、Solr のロードバランサーを介して実行されます。これにより、負荷が解析されリポジトリに分散されます。

  • 検索層：4つのリポジトリインスタンスが、Solr ロードバランサーを介して、2つの Solr インスタンスに対し、オンデマンドでクエリを実行します。

Alfresco Share クラスタの設定

ここでは、Share 用のクラスタを設定する方法について説明します。

Alfresco Share インスタンス間の Hazelcast を設定する

ここでは、Share のインスタンス間の Hazelcast クラスタリングの設定について説明します。
負荷分散環境では、Share は現在 Hazelcast を使用してWeb層のノード間のマルチキャストメッセージングを実現しています。その結果、どのノードに対してもShare キャッシュを無効にする必要がなくなり、必要に応じてシンプルなキャッシュ無効化メッセージが全ノードに送られます。各ノードが実質的に1つの Share インスタンスと同等の速度で動作し、Share全体のパフォーマンスを向上させています。

Share インスタンス間の Hazelcast のクラスタリングを有効にするには、<TOMCAT-HOME>/shared/classes/alfresco/web-extensionにあるcustom-slingshot-application-context.xmlファイルを設定します。このファイルは、Share 用の Spring のアプリケーションコンテキスト Bean をオーバーライドするために使用されます。

注：配布物として提供されるサンプルファイルのcustom-slingshot-application-context.xml.sampleに、この設定が含まれるようになりました。

Hazelcast のクラスタメッセージングを有効にするには、各Share Tomcatインスタンスで次のセクションを編集します。

この設定により、Hazelcast の Spring 統合が有効になり、Hazelcast サーバーが起動します。Hazelcast サーバーは簡単に設定でき、必要に応じてマルチキャスト（デフォルト）、または TCP/IP による直接通信のいずれかを使用することができます。詳しくは、Hazelcast の文書を参照してください。

この設定を有効にすると、Share インスタンスがクラスタノードになり、Hazelcast が起動されます。この設定が無効になっていると（デフォルトのインストールの場合など）、Hazelcast は起動しません。Share の使用中は、以下のいずれかのアクションが発生した場合のみ、影響を受けるノードからクラスタ内の他のノードにキャッシュ無効化メッセージが送信されます。

• 既存のサイト/ユーザーダッシュボードのレイアウトが変更される

• 新しいサイト/ユーザーダッシュボードが作成される

• ランタイムアプリケーションのプロパティが変更される

注：デフォルトの設定を有効にするには、各 Share ノードに同じ設定が適用されます。
以下は、Share の起動時の出力例です。

このメッセージは、設定によって Share インスタンス間の Hazelcast が正常に初期化されたことを示しています。

Alfresco Share のクラスタリングを設定する

ここでは、Share のクラスタ構成を設定するのに必要な手順について説明します。クラスタ化されたインストールの前面で HTTP 負荷分散メカニズムを使用している場合、Share 層からリポジトリ層（/alfrescoアプリケーション）へのHTTP要求に対して「固定」ルーティングを有効にする必要があります。

次に示す2つの方法のうち、いずれか1つを使用して固定ルーティングを有効にできます。

1. 各/share インスタンスを、ロードバランサーを介さずに、独自の/alfrescoインスタンスにハードワイヤー接続します。
   これは、各share-config-custom.xmlファイルに、負荷分散メカニズムの背後にないホスト名とポート番号を読み込むことで実現することができます。
   SSO で Kerberos 認証が有効になっている場合、Share ではクッキーベースのセッションが使用され、JSESSIONIDクッキーを使用してロードバランサーが固定ルーティングを使用するように設定できます。

2. SSO で Kerberos を有効にするには、Configuring authentication の手順を参照してalfrescoNtlmまたは Kerberos 認証を設定し、（kerberos.authentication.sso.enabled=true）を設定します。
   注：クラスタを設定する場合は、クラスタリングの設定を参照してください。

リポジトリサーバークラスタを設定する

ここでは、リポジトリサーバークラスタの実装方法について説明します。

リポジトリサーバークラスタは、次のコンポーネントで構成されています。

• データベースサーバー

• コンテンツストア

• Solr サーバー

• ロードバランサー

Content Services ノードのインストールと設定を行う

ここでは、「高スループットを実現するクラスタリング」で説明したシナリオに基づいて、クラスタのノードをインストールおよび設定する方法について説明します。

• Content Services ノードをインストールします。
  詳しくは、https://docs.alfresco.com/governance-services/community/install/zip/ を参照してください。

• クラスタ環境で複数の Content Services インスタンスを設定します。

Solr ノードのインストールと設定を行う

ここでは、クラスタの Solr ノードをインストールおよび設定する手順について説明します。

1. Solr ノードを設定します。
   詳しくは https://docs.alfresco.com/search-services/latest/install/options/ を参照してください。

2. <SOLR_HOME>/solrhome/templates/rerank/conf/solrcore.properties ファイルを編集します。
   既にSolrを起動していて、コア（alfrescoとarchive）が存在する場合は、次のファイルを開きます。

   <SOLR_HOME>/solrhome/alfresco/conf/solrcore.properties <SOLR_HOME>/solrhome/archive/conf/solrcore.properties

3. solrcore.propertiesファイルで、次の Solr プロパティを設定します。

4. HTTPS トランスポートを使用している場合、ロードバランサーが Alfresco の証明書を使用するように設定されていることを確認してください。
   独自のbrowser.p12証明書を生成し、ロードバランサーの設定に追加する必要があります。

5. HTTP トランスポートを使用している場合は、<classpathRoot>/alfresco-global.properties で次のプロパティが設定されていることを確認してください。

リポジトリサーバークラスタを設定する

以下の手順に従って、リポジトリクラスタを設定します。
デフォルトでは、同じデータベースに接続されているすべてのエンタープライズサーバーは、リポジトリクラスタを形成します。

クラスタ内の各サーバーについて、以下の手順を実行します。

1. リポジトリサーバーをインストールして設定します。Content Services（alfresco.war）の展開については、インストールマニュアルを参照してください。また、次の点について確認してください。

   • クラスタ内のすべてのメンバーが、コンテンツストアを利用できるようになっている必要があります。

   • 各クラスタメンバーが、alfresco-global.properties で指定されているのと同じデータベースプロパティを使用して、同じデータベースにアクセスできるように設定されている必要があります。

   • クラスタ全体で使用する Solr インデックスサーバーを展開し、このSolrサーバーを利用するように各クラスタメンバーのプロパティを設定します。

2. 各リポジトリサーバーで、ポート番号5701（デフォルトのクラスタリングポート）が、クラスタ内の他のすべてのリポジトリサーバーからアクセス可能であることを確認します。

3. 使用するクラスタリング用ネットワークインターフェイスのワイルドカード（たとえば10.50..）または正確なIPアドレス（たとえば192.168.1.100）を指定します。
   ワイルドカードIPアドレスを使用する利点は、ローカルで変更を加えることなく、複数のサーバーで設定を使用できることです。使用する Java プロパティ名は、alfresco.cluster.interface（任意）です。

4. （任意）Hazelcast 独自の JMX レポートを有効にするために、次の Java プロパティを設定します。

5. alfresco-global.properties ファイルを開きます。

   1. 次のリポジトリプロパティを設定します。

   2. 相互TLS（httpsなど）用に次の検索プロパティを設定します。

   3. 相互TLS（httpなど）を使用しない場合は、次の検索プロパティを設定します。

リポジトリサーバークラスタを起動する

ここでは、リポジトリサーバークラスタを起動する方法について説明します。

ほとんどの場合、クラスタリング固有の設定を適用する必要はなく、サーバーを起動するだけでクラスタが形成されます。10.244.50.101と10.244.50.102というIPアドレスに、2つのクラスタメンバーがいるとします。1番目のメンバーを起動すると、次のようなログメッセージが表示されます。

このメッセージは、リポジトリ名（MainRepository）と UUID（ランダム/ユニークな識別子）に基づき、クラスタ名が自動生成されたことを示しています。最終的に、クラスタが開始されると、クラスタメンバーが一覧表示されます。ログメッセージに示されているように、現在存在しているクラスタメンバーは1つのみです。
2番目のメンバーを起動すると、次のようなログメッセージが表示されます。

このログメッセージは、両方のサーバーが同じクラスタのメンバーになっていることを示しています。

注：クラスタ環境を起動する場合、クラスタ内のノードはローリングスタートで起動するようにしてください。つまり、クラスタ内の各ノードは、最初のノードが完全に起動してから次のノードが起動するようにします。これにより、リソース/負荷の同時実行の競合を回避することができます。

クラスタのメンバーを管理する

リポジトリサーバーのクラスタリングには、リポジトリ管理コンソールを使用します。
通常、同じデータベースインスタンスに接続されているサーバーは、自動的にクラスタ化されます。ほとんどの場合、追加の設定は必要ありません。

注：お使いのライセンスでクラスタリングが有効になっていることを確認してください。

1. リポジトリ管理コンソールを開きます。

2. Repository Services セクションで、Repository Server Clustering をクリックします。
   Repository Server Clustering ページが表示されます。

3. クラスタリングのプロパティを設定します。
   ホストサーバーの場合

クラスタメンバーの場合：サーバーの詳細

オフラインクラスタメンバーの場合：サーバーの詳細

4. 特定のクラスタメンバーを使用停止にする場合は、Remove from list（リストから削除）をクリックします。

オフラインクラスタメンバーは、Offline Cluster Membersリストに表示されなくなります。

5. Connected Non-Clustered Server(s) のクラスタリングプロパティを設定します。

例外的に、他のクラスタメンバーと同じデータベースに接続されているサーバーでも、リポジトリクラスタのメンバーではない場合があります。つまり、クラスタリングが無効化されている場合があります。このようなサーバーのことを、接続された非クラスタ化サーバーと呼びます。

6. クラスタリングが正しく動作しているかどうかを確認するには、Validate Cluster をクリックします。

Cluster Validation ページが表示されます。このページには、クラスタの検証結果が表示されます。
クラスタ検証では、クラスタメンバー間の通信が正しく行われているかどうかを確認するためのチェックが実行されます。クラスタメンバーすべてのステータスが「成功」になった場合、クラスタが有効であるとみなされます。2台のサーバーで構成されるクラスタで、1台のサーバーで通信が正しく行われなかった場合、両方のサーバーが「失敗」としてマークされます。
7. Close をクリックします。

クラスタをテストする

リポジトリサーバーのクラスタリングのテストには、いくつかの手順があります。
最も迅速かつ簡単にクラスタをテストするには、リポジトリ管理コンソールを使用します。
Content Services が起動していることを確認します。

1. ブラウザウィンドウに次の URL を入力します。

   ここで、<your-host-name>はサーバーを稼動させているホスト名です。
   Authentication Required のプロンプトが表示され、サーバーの IP アドレスまたは名前とポート番号が表示されます。

2. ユーザー名とパスワードを入力してください。
   管理者権限を持つアカウントのユーザー名とパスワードを入力する必要があります。
   ブラウザウィンドウに管理コンソールが表示されます。最初に、システムの概要ページが表示されます。

3. Repository Services セクションで、Repository Server Clustering をクリックします。
   Repository Server Clustering ページが表示されます。
   Cluster Members セクションの下に、現在のクラスタメンバーに関する情報が表示されます。

4. Validate Cluster をクリックして簡単なテストを開始し、クラスタメンバーの各組み合わせの間で通信が可能であることを確認します。
   Cluster Validation ページが表示されます。クラスタ通信のテスト結果（Success（成功）またはFailure（失敗））がマトリックス形式で表示されます。

クラスタリングプロパティ

ここで説明するプロパティを alfresco-global.properties ファイルに設定して、リポジトリサーバークラスタを設定します。

注：以下のプロパティの設定は任意となり、必須ではありません。

クラスタリングの問題を追跡する

ここでは、クラスタリングの問題を追跡する方法について説明します。

• メインのクラスタリングデバッグ情報は、次に示すように、log4j を設定することでカスタマイズできます（デフォルト値は INFO）。

• 次のカテゴリを設定することにより、制御が向上し、より詳細なクラスタリングデバッグ情報を得ることができます。

  この設定は、クラスタリングの初期化とシャットダウンを制御します。INFO レベルのスタートアップメッセージとシャットダウンメッセージが表示されます。また、クラスタリングが無効な場合または無効なライセンスがインストールされている場合は、WARN レベルのメッセージも表示されます。
  以下が出力例となります。

• クラスタメンバーが脱退または参加すると、次に示すクラスにより、INFO のメッセージが生成され、情報が提供されます。

  
  以下が出力例となります。

• クラスタリングで重要となるのは、キャッシュです。キャッシュ作成のログを記録する（たとえば、キャッシュ関連のログを DEBUG レベルに上げる）には、次に示すログカテゴリを有効にします。

• 基本的なクラスタリング技術（Hazelcast）では、ログの記録にlog4jを使用するよう設定されています。したがって、次に示すように、Hazelcast 最上位パッケージ全体に対してログの記録を設定することができます。

• Hazelcast メンバー参加メカニズムからのログを増やす（デバッグモード）には、次に示すログカテゴリを有効にします。

• Alfresco は、クラスタリングのデータ同期のために、内部で Hazelcast ライブラリを使用しています。Java 11モジュールの追加に伴い、リポジトリアプリのアプリケーション起動ログに、次に示すような警告が表示されるようになりました。

  詳しくは、Hazelcast Documentation を参照してください。
  これらのパラメータを使用する危険性の詳細については、https://openjdk.java.net/jeps/261 を参照してください。このページに記載されている注意事項の内容に注意してください。

注：--add-exportsオプションと--add-opensオプションの使用には十分な注意を払うようにしてください。これらのオプションを使用すると、ライブラリモジュールまたはJDK自体の内部APIにアクセスできますが、あくまでも自己責任で行ってください。その内部APIが変更または削除されると、ライブラリまたはアプリケーションが機能しなくなります。
当社は、この警告を非表示にしないことにしました。非表示にすると、コードの他の部分にある他の問題までもが非表示になってしまうためです。この決定が、リポジトリアプリのパフォーマンスやセキュリティに影響を及ぼすことはありません。必要な修正については、次のJavaリリースが利用可能になったときにレビューして対応します。Hazelcastでも同様の対応が取られるものと想定されます。