記事
Toshihiko Minamoto · 2021年9月16日 10m read

InterSystems IRIS for Health 2020.1 の HL7 のベンチマーク

はじめに

InterSystemsは最近、HL7バージョン2の相互運用性に焦点を当てた、IRIS for Health 2020.1のパフォーマンスとスケーラビリティのベンチマークを完了しました。 この記事では、さまざまなワークロードで観察されたスループットを説明し、IRIS for HealthをHL7v2メッセージングの相互運用性エンジンとして使用しているシステムの一般的な構成とサイジングのガイドラインを提供します。

ベンチマークは本番環境にほぼ一致するように設計されたワークロードをシミュレーションしています。 シミュレーションの詳細は、「ワークロードの説明と方法」セクションで説明しています。 テストされたワークロードは、HL7v2 Patient Administration(ADT)とObservation Result(ORU)ペイロードで構成され、変換と再ルーティングが含まれました。

IRIS for Healthの2020.1バージョンは、第2世代のIntel® Xeon® スケーラブルプロセッサとIntel® Optane™ SSD DC P4800XシリーズSSDストレージを使用したコモディティサーバーで、1日当たり23億件を超えるメッセージ(インバウンドとアウトバウンドの合計)スループットの持続を実証しました。 これらの結果は、以前のEnsemble 2017.1 HL7v2スループットベンチマークのスケーラビリティの2倍以上です。

これらのテストでは、IRIS for Healthは、先入先出(FIFO)の順序を保持し、インバウンドメッセージとアウトバウンドメッセージのメッセージとキューを完全に永続化するように構成されました。 キューとメッセージを永続化することで、IRIS for Healthはシステムがクラッシュした際に、データ保護と、履歴メッセージの完全な検索と再送機能を提供することがでます。

さらに、構成ガイドラインは以下のセクションで説明されており、ワークロードのパフォーマンスとスケーラビリティの要件を適切に満たす構成とデプロイを選択する上で役立てられます。

この結果は、IRIS for Healthがコモディティハードウェアで極端なメッセージングスループットを満たすことができ、ほとんどの場合において、1つの小さなサーバーで組織全体にHL7の相互運用性を提供できることを示しています。


結果の概要

HL7相互運用性アクティビティのさまざまな側面を表すために、次の3つのワークロードが使用されました。

  • T1ワークロード: 単純なHL7メッセージのパススルーを使用します。インバウンドメッセージごとに1つのアウトバウンドメッセージが使用されます。 メッセージは、ルーティングエンジンを使用せずに、Ensemble Business Serviceから直接Ensemble Business Operationに渡されました。 ルーティングルールは使用されず、変換も実行されませんでした。 データベースには、インバウンドメッセージごとに1つのHL7メッセージインスタンスが作成されました。
  • T2ワークロード: ルーティングエンジンを使って、インバウンドメッセージの平均4つのセグメントを変更し、それを1つのアウトバウンドインターフェースにルーティングします (変換を使用して1対1)。 各インバウンドメッセージでは、1つのデータ変換が実行され、2つのHL7メッセージオブジェクトがデータベースに作成されました。
  • T4ワークロード: ルーティングエンジンを使用して、個別に変換されたメッセージをそれぞれ4つのアウトバウンドインターフェースにルーティングします。 平均して、インバウンドメッセージの4つのセグメントが変換ごとに変更されました(4 つの変換で1件のインバウンドから4件のアウトバウンド)。 各インバウンドメッセージでは、4つのデータ変換の実行により4つのメッセージがアウトバウンドに送信され、5つのHL7メッセージオブジェクトがデータベースに作成されました。

上記の3つのワークロードは、Red Hat Enterprise Linux 8を実行する2つの750GB 2つのIntel® Optane™ SSD DC P4800X SSDドライブとIntel® Scalable Gold 6252プロセッサを備えた物理48コアシステムで実行されました。 データは、1秒当たり(および1時間当たり)のインバウンドごとのメッセージ数、1秒当たりの(および1時間当たり)のアウトバウンドごとのメッセージ数、および1日10時間のメッセージ合計数(インバウンドとアウトバウンド)で表示されています。 また、特定のレベルのスループットにおいて利用可能なシステムリソースの測定値として、CPU使用率が表示されています。 

スケーラビリティの結果

表1: このテスト済みのハードウェア構成における4つのワークロードのスループットの要約:

* 25%のT1/ 25%のT2 / 50%のT4ワークロードの比率で組み合わされたワークロード


ワークロードの説明と方法

テストされたワークロードには、HL7v2 Patient Administration(ADT)とObservation Result(ORU)メッセージが含まれ、平均1.2 KBのサイズと平均14のセグメントが含まれました。 変換によっておよそ4つのセグメントが変更されました(T2およびT4ワークロード)。 テストは、TCP/IPを介してメッセージを送受信する48件から128件のインバウンドと48件から128件のアウトバウンドのインターフェースを表します。

T1ワークロードでは、それぞれに16個のインターフェースを持つ4つの個別のネームスペースが使用され、T2ワークロードでは、それぞれに16個のインターフェースを持つ3つのネームスペースが使用され、T4ワークロードでは、それぞれに32個のインターフェースを持つ4つのネームスペースが使用され、最後の「混合ワークロード」では、T1ワークロードに16個、T2ワークロードに16個、T4ワークロードに32個を持つ3つのネームスペースが使用されました。

スケーラビリティは、各インターフェースのトラフィックを徐々に増やして許容可能なパフォーマンス基準で最高のスループットを見つけることで測定されました。 許容可能なパフォーマンスを得るには、メッセージがキューイングやメッセージの配信に測定可能な遅延のない持続的な速度で処理され、平均CPU使用率が80%未満である必要があります。

以前のテストでは、使用されたHL7メッセージのタイプはEnsembleのパフォーマンスやスケーラビリティにとって重要ではありませんでしたが、インバウンドメッセージ数、インバウンドとアウトバウンドメッセージのサイズ、ルーティングエンジンで作成される新しいメッセージの数、および変更されたセグメント数が重要でした。

さらに、以前のテストでは、データ変換でHL7メッセージの個別のフィールドを処理することは、通常、パフォーマンスに影響がないことが示されています。 これらテストの変換では、かなり単純な割り当てを使用して、新しいメッセージが作成されています。 複雑な処理(データ変換での広範なSQLクエリの使用など)によって、結果が異なる場合があることに注意してください。

以前のテストではまた、ルール処理は通常重要でないことも確認されています。 これらのテストで使用されたルーティングルールセットは平均32個のルールで、すべてのルールは単純です。 ルールセットが極端に大きいか複雑な場合は、結果が異なる場合があります。 

ハードウェア 

サーバーの構成

テストでは、2.1 GHzの48コアの2ソケットシステムで、192 GB DDR4-2933 DRAMと10 Gb Ethernetネットワークインターフェースを使用するソケットごとに24コアを提供する第2世代Intel® Scalable Gold 6252「Cascade Lake」プロセッサを搭載したサーバーが使用されました。 このテストでは、Red Hat Enterprise Linux Server 8オペレーティングシステムでInterSystems IRIS for Health 2020.1を使用しました。

ディスクの構成

IRIS for Healthを通過するメッセージは、ディスクに完全に永続されます。 このテストの場合、システム内部の2つのIntel 750GB Intel® Optane™ SSD DC P4800X SSDドライブを使用して、片方をデータベース用、もう片方をジャーナル用として分割しました。 さらに、実際の比較を実現できるにように、ジャーナルの同期コミットを有効にして、データの耐久性を強化しています。 前述のT4ワークロードの場合、各インバウンドHL7メッセージはおよそ50 KBのデータを生成しますが、これを表2に説明するように分類できます。 トランザクションジャーナルは通常、メッセージデータやログよりも短い時間オンラインに保持されるため、必要な合計ディスク容量を計算する際に、このことを考慮する必要があります。

表2: インバウンドHL7 T4メッセージあたりのディスク要件

項目 データ要件
セグメントデータ 4.5 KB
HL7メッセージオブジェクト 2 KB
メッセージヘッダー 1.0 KB
ルーティングルールログ 0.5 KB
トランザクションジャーナル 42 KB
合計 50 KB

 

T4ワークロードはルーティングエンジンを使用して、個別に変換されたメッセージをそれぞれ4つのアウトバウンドインターフェースにルーティングすることを思い出しましょう。 平均して、インバウンドメッセージの4つのセグメントが変換ごとに変更されました(4 つの変換で1件のインバウンドから4件のアウトバウンド)。 各インバウンドメッセージでは、4 つのデータ変換の実行により 4 つのメッセージがアウトバウンドに送信され、5 つの HL7 メッセージオブジェクトがデータベースに作成されました。

本番環境で使用するシステムを構成する場合、HL7メッセージの1日あたりのインバンドボリュームとパージスケジュール、およびジャーナルファイルの保持ポリシーを考慮して、正味要件を計算する必要があります。 また、適切なジャーナルファイルの容量は、ジャーナルディスクボリュームがいっぱいになるのを防ぐようにして構成する必要があります。 ジャーナルファイルは、パフォーマンスと信頼性を考慮して、データベースファイルから物理的に離れたディスクに存在する必要があります。

まとめ

これらのテストで示されたInterSystems IRIS for Health HL7v2メッセージスループットは、適度な2ソケットコモディティサーバー構成での大規模なスループット性能によって、組織における要求の最も厳しいメッセージワークロードをサポートできることを示しています。 また、InterSystemsは、最新のサーバーとクラウドテクノロジーを活用しながら、バージョンごとにパフォーマンスとスケーラビリティを改善することに絶えず取り組んでいます。

以下のグラフでは、スループットの増加について、Intel® E5-2600 v3(Haswell)を使用したEnsemble 2015.1とEnsemble 2017.1のベンチマークと第1世代Intel® Scalable Platinum Series(Skylake)プロセッサを使用したEnsemble 2017.1のベンチマークをそれぞれ第2世代Intel® Scalable Gold Series(Cascade Lake)プロセッサでIRIS for Health 2020.1を実行した場合の最新の結果と比較しています。

グラフ1: 単一サーバーでの1日10時間当たりのメッセージスループット(百万単位)。

InterSystems IRIS for Healthは、バージョンが上がるたびに、接続機能の柔軟性を提供するとともに、相互運用性スループットの水準を引き上げ続けています。 上記のグラフからわかるように、メッセージスループットは大きく増加しており、同じ10時間の期間と、23億件以上という24時間の合計メッセージ速度を維持したまま、T2ワークロードの場合には2017の2倍、2015と比較すると3倍以上に増加しています。

IRIS for Healthの進歩を示すもう1つの重要な指標は、T1ワークロードの純粋なパススルー操作とは対照に、変換とルーティングルーツが組み込まれたより複雑なT2とT4ワークロードでのスループットの向上です。  

InterSystemsでは、企業や組織におけるインターオペラビリティ(相互運用性)のニーズに対するソリューションのご相談をお待ちしております。

00
2 0 0 14
Log in or sign up to continue