比較的小容量の複数のサーバー間で負荷を分散する技術は、CachéDBMSの標準機能として長い間使用されてきました。 分散キャッシュプロトコルECP（エンタープライズキャッシュプロトコル）に基づいています。 ここで意味するのは「キャッシュ」（「キャッシュ」）であり、「キャッシュ」（「キャッシュE」）ではありません。 ECPは、アプリケーションシステムの水平スケーリングの豊富な機会を提供し、障害に対する高い抵抗力を維持しながら高いパフォーマンスを提供し、プロジェクト予算をかなり控えめなフレームワークのままにします。 ECPネットワークの利点には、DBMS構成の中にアーキテクチャの機能を隠す可能性が含まれるので、従来の（垂直）アーキテクチャ用に開発されたアプリケーションは通常、水平ECP環境に容易に移行できます。 この軽さはとても魅力的で、常にこのようにしたいです。 たとえば、現在のプロセスだけでなく「外部」のCachéプロセスを制御する機能には誰もが慣れています。$ Jobシステム変数および関連する関数とクラスの熟練者は、「驚異を働かせる」ことができます。 停止しますが、プロセスは異なるCachéサーバー上に配置できます...以下は、ECP環境でプロセスを管理する際に、それを使用しない場合とほぼ同じ透過性を達成する方法です。

ECPの用語

トピックを掘り下げる前に、ECPに関連する基本概念を思い出してください。

ECP 、または分散キャッシュプロトコルは、データサーバーとアプリケーションサーバー間の相互作用の中核です。 信頼性の高いパケット転送を提供するTCP / IPの上で実行されます。 ECPはインターシステムズが所有しています。

データサーバー（DBMS）（ECPサーバーとも呼ばれる）は、ローカルアプリケーションデータベースをホストする一般的なCachéインストールです。 「located」という動詞は、文字どおりに解釈しないでください。たとえば、iSCSIまたはFCを介してアクセス可能なネットワークストレージシステム上にデータベースを物理的に配置できます。 DBMSがそれらをローカルと見なすことが重要です。

ECPクライアントと呼ばれることもあるアプリケーションサーバー（SP）は、アプリケーションシステムユーザーにサービスを提供するプロセスを実行する一般的なCachéインストールです。 言い換えると、アプリケーションコードはアプリケーションサーバー上で実行されます（そのため、その名前です）。 これらは一般的なCachéインストールであるため、CACHESYS、CA​​CHELIB、CACHETEMPなどのシステムローカルデータベースの標準セットがあります。 これは重要ですが、重要なことではありません。 データサーバーに対してローカルなアプリケーションデータベースが、アプリケーションサーバー上のリモートデータベースとしてマウントされることは、はるかに重要です。 一般に、相互作用スキームは図に示されています。





ECPの主要コンポーネント



データキャッシュとは何ですか、説明する必要はありません。 ECPプロトコルの名前に表示される分散キャッシュは、一般的には比metaに過ぎません。キャッシュは、もちろんローカルです。 ただし、リモートグローバルノードがアプリケーションサーバーで読み取られると、対応するブロックがデータサーバーキャッシュからアプリケーションサーバーキャッシュにコピーされるため、同じグローバルの隣接ノードへの繰り返し呼び出しがローカルで発生し、ネットワークとデータサーバーに再度アクセスする必要はありません。 システムが長く動作するほど、ジョイントベンチャーのローカルキャッシュを埋める関連性が高くなり（「ヒート」が向上するほど）、ネットワークアクセス操作が発生する頻度が少なくなります。 理想的には、データサーバーからの繰り返し読み取りには、変更されたデータのみが必要です。 分散（サーバー間）キャッシュの存在の錯覚があります。

記録はやや複雑です。書き込み要求はデータサーバーに送られます。 データサーバーは、キャッシュからブロックを消去するコマンドを送信し、以前にキャッシュ内のこのブロックの前の状態を読み取ったアプリケーションサーバーにのみ送信します。 おそらく誰もそれを必要としないので、変更されたブロック自体が強制的に送信されないことが重要です。 再度その必要がある場合、ブロックは再びデータサーバーから要求され、前述のようにアプリケーションサーバーのローカルキャッシュに再び落ちます。

建築家の目から見たECP

商業的中断：ECPを使用した水平スケーリングの利点について少し説明します。 10,000ユーザーのシステムを計画する必要があるとし、1 CPUコアと10 GB RAMの量で50ユーザーごとにコンピューティングリソースが必要であることがわかっているとします。 選択肢を比較します。 SBD＆SPテーブルには、従来のCachéサーバーがあります（データおよびアプリケーションサーバーは「1つのボトルに」）。 フォールトトレランスの理由から、2つの計画が必要です。

垂直対 水平スケーリング

垂直スケーリング		水平スケーリング
サーバーオプション	サーバーの数	サーバーオプション	サーバーの数
200 CPUコア、2 TB RAM	2 SBDおよびSP	16コアCPU、160 GB RAM	13 SP、2 SBD

水平スケーリングのスキームでは、同じ理由で、2台のデータサーバーを計画しますが、このスキームの価格優位性を以前のものよりも納得させる必要はないと思います...ボーナスとして、ECPとミラーリングの併用の素晴らしい機能を取得します：データサーバーを切り替えるとき-ミラーペアのノード-アプリケーションサーバーのユーザーは、作業の一時停止（秒単位で測定）のみを経験し、その後はセッションが継続します。 縦の図では、クライアントプロセスはデータサーバーに直接接続されているため、サーバーを切り替えるとき、ユーザーセッションの中断は避けられません。





ECPとミラーの共有



各アプリケーションサーバーにはローカルデータベースもあるため、中間データのストレージはこれらのデータベースに自然に転送されることを思い出してください。 そのような作業は非常に激しい可能性があります。つまり、多数の低コストのディスクを含めることで中央ストレージシステム（SHD）をオフロードできるため、中間データ用の別の高価なストレージシステムを使用せずにディスク操作を待機（待機）する時間を短縮できます。

プログラマーから見たECP

「通常の」プログラムはエリアで機能するため、次の形式の構造を変更する必要はありません^ | "^^ c：\ intersystems \ cache \ mgr \ qmsperf" | QNaz to ^ | "^ PERF ^ c：\ intersystems \ cache \ mgr \ qmsperf "| QNaz。 これらの機能はすべて、リモートデータサーバーとリモートデータベースの定義のCaché構成に隠されています。 プロセスの現在の領域以外の領域のグローバルを参照する必要がある場合でも、そのような呼び出しの構文（^ | "qmsperf" | QNaz）は変わりません。

グローバルデータを操作するセマンティクスも実際には変更されません。ローカルデータベースを操作するだけで、通常は考えていません。 主なポイントをリストします。

•すべての操作は、同期（すべての読み取り関数：$ Get、$ Orderなど、Lockおよび$ Increment）と非同期（データ記録：Set、Killなど）に分けられます。 プログラムをさらに実行しても、非同期操作の完了を待つ必要はありません。 同期操作の場合、これは当てはまりません。 ECPの場合、データブロックがローカルキャッシュにない場合、データサーバーへの追加アクセスが必要になる場合があります。

•同期操作は、同じアプリケーションサーバーによって開始された非同期操作の完了を待機しません。

•Lockコマンドは、前のロックマスターによって開始されたデータレコードが完了するまで待機します。

•ロックタイムアウトの期限は、他の誰かがロックを所有していることを保証するものではありません。



そして、ここにいくつかの異常な瞬間があります：

•ブロックサイズの半分より長い行は、アプリケーションサーバーにキャッシュされません。 実際、8 KBブロック（3900バイト）の場合、このしきい値はわずかに低くなります。 この決定は、キャッシュをBLOBおよびCLOBで詰まらせないために開発者によって行われました。通常、このようなデータは1回書き込まれ、その後非常にまれにしか読み取られません。 残念ながら、この決定はビットマップインデックスの処理に悪影響を与えました。これも原則として長い文字列です。 それらを使用する場合、チャンクのサイズを小さくするか、ブロックのサイズを大きくする必要があります。 最適な選択は、テスト結果に基づいてのみ行うことができます。



•割り当て

set i = $ Increment （^ a）

機能的に近いものよりも高価になる場合があります。

lock + ^ a セット （ i 、^ a）= ^ a + 1 lock- ^ a

実際には、$ Increment関数は常にデータサーバーで実行されるため、ラウンドトリップパケットの移動の完了を待つことは避けられません。また、ロックは、さまざまなアプリケーションサーバーからのプロセスが要求した場合にのみ同様の効果を引き起こします。



•<NETWORK>エラーを処理します。 このようなエラーは、 リカバリを待機する時間 （デフォルトでは1200秒）の間、アプリケーションサーバーが失われたECP接続を復元できない場合に発生します。 これを処理する正しい方法は、開始したトランザクションをロールバックして、再試行することです。

ECPおよびプロセス管理

ECPの基本概念を更新し、記事のメイントピックに移りましょう。 プロセス管理は広義に解釈されます。 対処しなければならないアプリケーションプログラマの実際のニーズ、およびそれらを「すぐに」満足させるために利用できるシステムツールについては、以下を参照してください。

主要なアプリケーションプロセス管理のニーズ

機能	ECPなし	ECPを使用
バックグラウンドプロセスの実行。	仕事 $ job、$ zchild、$ zparent	Jobコマンドはネットワーク上で機能しますが、パラメーターを渡しません。 プロセス番号は、各サーバー内でのみ一意です。
プロセスの「活気」を追跡します。	$データ（^ $ジョブ（pid））	別のサーバーのプロセステーブルへのアクセスはありません。
プロセスのリストを取得します。	$注文（^ $ジョブ（pid）） $ zjob（pid）	上記を参照してください。
他のプロセスのプロパティへのアクセス。	クラス％SYS.ProcessQuery	上記を参照してください。
別のプロセスの完了。	クラスSYS.Process	別のサーバーでプロセスを完了することはできません。

これらの「課題」に対する答えは、Util.Procクラスの形式で実装されたプロセス制御APIの開発でした。

さらに読みやすくするために、APIを使用した簡単なコード例をいくつか紹介します。

Util.Proc APIの例

•医療情報システム（MIS）の領域とユーザー名を示すプロセスのリストを表示し、自分の（現在の）プロセスに「*」をマークします。

cnt = 0を 設定

{

set proc = ## class （ Util.Proc ）。 NextProc （ proc 、。Sc ） quit ： proc = "" || ' sc //次のプロセス

write proc _ $ select （ ## class （ Util.Proc ） 。ProcIsMy （ proc ）： "*" 、1： "" ） //自分自身に「*」をマーク

「スコープ：」と 書く

##クラス （ Util.Proc ）を 記述し ます。 GetProcProp （ proc 、 "NameSpace" ） //プロセスプロパティ：現在のスコープ

「user：」と 書く

##クラス （ Util.Proc ）を 記述し ます。 GetProcVar （ proc 、 $ name （ qARM （ "User" ））））！ //プロセス変数：MISユーザー名

cnt = cnt +1を 設定

}

「合計：」 _ cnt _ 「プロセス 」と 書き込み ます。



•同じMISユーザー名で実行されている場合、現在のプロセス以外のプロセスを削除します（ユーザーが再入力できないようにします）。

if ' ##クラス （ Util.Proc ）。 ProcIsMy （ proc ）、

##クラス （ Util.Proc ）。 GetProcVar （ proc 、 $ name （ qARM （ "User" ）））= $ name （ qARM （ "User" ）） {

set res = ## class （ Util.Proc ）。 KillProc （ proc ）

}

ネットワーク上のプロセスのアドレス指定

APIを開発するとき、ECPネットワーク内のプロセスをアドレス指定する方法を選択する必要がありました。

•ローカルネットワーク内のアドレスの一意性、

•最小限の変換で住所を直接使用する機能、

•読みやすい形式。



ネットワーク上のサーバーのアドレスを指定するには、その名前（ホスト名）またはIPアドレスを使用できます。 識別子としての名前の選択は、魅力的ではありますが、ネームサービスの非の打ちどころのない追加の要件を課します。 通常、Cachéの構成時にこのような要件は課されないため、新しい制限を導入したくありませんでした。 さらに、さまざまなオペレーティングシステムでは、ホスト名の形式が異なる場合があり、その後のプロセス記述子の分析が複雑になります。 これらの考慮事項に基づいて、IPv4アドレスを使用することを好みました。

サーバー上のCachéインストールを識別するには、その名前（「CACHE」、「CACHEQMS」など）またはスーパーサーバーのポート番号（1972、56773など）を使用できます。 ただし、名前でCachéインストールに接続することはできないため、ポートを選択します。

その結果、プロセスの記述子（一意の識別子）として、10進数形式の文字列を使用することが決定されました：xx.yy.zz.uu.Port.PID、ここで

xx.yy.zz.uu-CachéサーバーのIPv4アドレス、

ポート-CachéスーパーサーバーのTCPポート、

PIDは、Cachéサーバー上のプロセス番号です。



有効なプロセス記述子の例：

192.168.11.19.56773.1760-IP = 192.168.11.19およびポート= 56773のCachéインストールでのPID = 1760のプロセス。

192.168.11.77.1972.62801-IP = 192.168.11.77およびポート= 1972のCachéインストールでのPID = 62801のプロセス

Util.Procクラスメソッド

その結果、Util.Procクラスが開発されました。そのパブリックメソッドを以下に示します。 すべてのメソッドはクラスメソッド（ClassMethod）です。

プロセス制御APIメソッドの要約

方法	機能
IsECP（）As％Bolean	ECPネットワークで、コードが実行されるかどうか。
NextProc（proc、ByRef sc As％Status）As％文字列	proc記述子を持つプロセスの後の次のプロセス。
DataProc（proc、ByRef sc As％Status）As％整数	##クラス（Util.Proc）.DataProc（proc）の場合、proc記述子を持つプロセスが存在します。
GetProcProp（proc、Prop、ByRef sc As％Status） As％String	proc記述子を使用して、プロセスのPropという名前のプロパティを取得します。 次のプロパティをポーリングできます（％SYS.ProcessQueryクラスを参照）。 Pid、ClientNodeName、UserName、ClientIPAddress、NameSpace、MemoryUsed、State、ClientExecutableName
GetProcVar（proc、var、ByRef sc As％Status）As％String	proc記述子を使用して、プロセスのvar変数の値を取得します。
KillProc（proc、ByRef sc As％Status）As％String	proc記述子でプロセスを終了します。
RunJob（EntryRef、Argv ...）As％リスト	EntryRefエントリポイントからデータサーバーでプロセスを開始し、必要な数の実際のパラメーター（Argv）を渡します。 $ lb（％Status、pid）を返します。ここで、pidはデータサーバーのプロセス番号です。
CheckJob（pid）As％リスト	データサーバー上のpid番号のプロセスが動作しているかどうかを確認します。
CCM（ClassMethodName、Argv ...）As％文字列	データサーバーでClassMethodNameクラス（または$$-関数）の任意のメソッドを実行し、必要な数の実際のパラメーター（Argv）を渡し、実行結果を受け取ります。

メソッドの概要とプロセス制御の基本的な応用ニーズの表を比較すると、ネットワーク環境でそれらを満足させることができたことがわかります。 CCM（）メソッドは後で追加されました：アプリケーション（地域医療情報システムqMS）をECP環境に転送するプロセスで、いくつかの機能ブロックがより便利で、データサーバー上で直接正しく実行されることが判明しました。 理由は異なる場合があります。

•大量のデータがアプリケーションサーバーに一度だけ転送されることを避けたいという要望。たとえば、レポートを生成するときなど。

•共通のリソース（たとえば、別のシステム（この場合はHealthShare）とメッセージを交換するためのキュー）を集中的に処理する必要性。



ほとんどのAPIメソッドはECP環境で動作するように設計されています。 ECPがなくても機能しますが、127.0.0.1.Port.pidという形式の無意味なプロセス記述子のみを受け入れ/返します。 例外は、データサーバーで動作するように指向されたメソッドです。RunJob（）、CheckJob（）、CCM（）。これらは、プロセス記述子（proc）ではなくデータサーバー上のその番号（pid）を返す/受け入れるためです。 したがって、これらのメソッドは、アプリケーションプログラマーの観点から汎用化されています。それらのインターフェイスは、ECP環境とそれ以外の両方で同じですが、もちろん異なる方法で動作します。

実装について少し

異なるサーバーで実行されているプロセス間の対話方法を選択する必要がありました。 次の選択肢が検討されました。

•クラス％SYSTEM.Event。

o公式にはネットワーク上で動作しないため、そのネットワーク操作のサポートはいつでもインターシステムズによって中止される可能性があります。



•独自のTCPサーバー。

o基本的に、良いアイデアです。

o追加のTCPポート（スーパーサーバーポートを除く）を使用する必要があります。これは、必然的に、標準のCaché設定に加えて、追加のインストールおよび構成作業を必要とします。 そして、最小限の設定で対処したかった。



•Webサービス。

•Class％Net.RemoteConnection。 忘れている人のために：このクラスは、％Service_Bindingsクライアントと同じプロトコルを使用して、他のサーバーでリモートコード実行を提供します。 このサービスがシステムでクライアントを接続するためにすでに使用されている場合、追加の設定は必要ありません。これは私たちの場合です。 データ交換のオーバーヘッドは、通常、Webサービスの場合よりもわずかです。



これらの考慮事項に基づいて、Net.RemoteConnection％を選択しました。 私の意見では、その欠点の中で最も深刻なのは、32KBを超える行を返すことが許可されていないことですが、これはそれほど大きな障害にはなりませんでした。

私が直面しなければならなかったもう一つのそれほど面白くない問題：コードがネットワーク上で動作しているかどうかを判断する方法？ この質問に対する答えは、APIの内部ニーズ（プロセス記述子を適切に形成するため）と、アプリケーションプログラマーの間で非常に一般的なIsECP（）メソッドの記述の両方に必要です。 この人気の理由は非常に明白です。ユニバーサルAPIのプロセス間の相互作用に関連するコードのセクションを書き直そうとする人はあまりいませんでした（そのようなAPIは実装されていました）。 ECPのコードブランチを追加する方がはるかに簡単で自然なことがわかりました。 しかし、どの環境でコードが機能するかを判断する方法は？ 考慮されるオプション：

1.メインエリアデータベースはリモートです。

• 長所：それは非常に簡単です：

if $ piece （ ## class （ ％SYS.Namespace ） 。GetGlobalDest （）、 "^" ） '= "" // ECP環境にいます

• 短所：これはアプリケーションサーバーでのみ当てはまり、データサーバーでのネットワーク操作は除外されます。

2. 1または（領域のメインデータベースはリモートとして誰かによってマウントされます）。 短所：

• 高価です。
• ECPの動的な性質のため、これは信頼できません。

3. 1または（ネットワークインターフェイスの1つを介して、アプリケーションサーバーがデータサーバーに接続されます）。



オプション3で停止しました。これにより、質問に対する希望する回答を迅速かつ正確に取得できるためです。

アプリケーションサーバーとデータサーバーの両方でプロセス記述子を入力します。 このチェックをさらに高速化するために、各サーバーの肯定的な結果はグローバルに修正されています。

いくつかの結論

クラスノヤルスク地域の地域医療情報システムの一部としてのプロセス管理APIの実装の成功により、完全ではないにしても、少なくとも選択したアプローチの実行可能性が示されました。 このAPIを使用して、当社のスペシャリストはいくつかの重要な問題を解決しました。 それらのほんの一部をリストします。

•重複したユーザー入力の排除。

•ネットワーク全体の作業ユーザーのリストを取得します。

•ユーザー間のメッセージング。

•実験室の分析装置にサービスを提供するバックグラウンドプロセスの起動と制御。



結論として、コードのテスト、気づいたバグへの迅速な対応、特にそれらの一部の修正について、 SP.ARMの同僚に感謝します。 Util.Procクラスのメソッドの一部（CCM（）、RunJob（）、CheckJob（））は、アプリケーションソフトウェアから独立して作成されました。 これらはgithubリポジトリまたはInterSystemsユーザーコードベースからダウンロードできます。

はい、私はインターシステムズの従業員ではありませんが、この会社の技術を喜んで使用しています。これを患者の読者にも読んでもらいたいと思います。