基幹システムのクラウド化が進む中、国内企業のアプリケーションモダナイゼーションの進捗（しんちょく）率は41％にとどまっている。筆者の所属するTricentisが2024年に実施した調査では、企業は複雑なアプリケーションエコシステムを開発し、保守・運用管理している一方で、現在使用されている多くのアプリケーションは古いままか、改善が必要であることが示されている。
調査でモダナイゼーションの最大の障壁として、質と量における人材不足が挙げられている中で、ソフトウェアテスト自動化を実施した企業の約3分の2はIT人材不足の解消を実感している。アプリケーションのテスト自動化フレームワークを確立することは、重要な施策であり、高品質のソフトウェアの開発とデリバリーを維持しつつ、コストと時間の削減を実現できると期待される。
⇧ そもそもとして、「ソフトウェアテスト自動化」以前の問題として、「アプリケーション」が動作する開発環境の構築方法が属人化している現場がほとんどなので、「ソフトウェアテスト」が実施できる状態にするまでに、「コスト」がかかるのよね...
開発に取り掛かれる環境の準備について、「冪等性」が担保された手順が確立されていれば、自動化する障壁も少ないのでしょうけど、不明瞭な情報が多い状態のままで作業フローが確立されていない状況の改善から始めないといけないので、「利益」の生み出さない作業に「工数」はかかりますと...
「Git」のような「バージョン管理システム」が導入されていない開発現場もあったりするし、導入されていたとしても「tarball」の中身の構成と「Git」で管理してる構成と差分があったり、所謂「属人化」された情報のオンパレードでカオスな開発現場が多くて、開発に注力できないあるあるが多過ぎて、「人材不足」云々の話とは関係ない問題が障壁となっている気がするのよね...
一部の悪質な「開発ベンダー」によっては、契約継続のために競合他社の手に負えないように意図的に複雑な開発フローにしているって噂も聞きますし、後進に皺寄せが行く構造になっている状況もありますと...
まぁ、「ソフトウェア品質保証」の話の前段階として、対応が必要なことが多過ぎるのよね...
まずもって、誰が作ったか分からない「アプリケーション」を動作させるための環境構築から取り掛からないといけないところが、ソフトウェアエンジニアを疲弊させるのよね...
新規開発とかであれば、自分たちで全て情報を把握できるから、自己責任ではあるが、解釈に迷うことは無いと思われるが...
昨今は、「分散システム」の構造になっている「アプリケーション」がほとんどだと思うので、「アプリケーション」が動作する環境を構築するのが大変なのよね...
ServiceNowのMID Serverって結局、通知を受け取るのか取りに行くのかどっちなんだい？
前に、
⇧ 上記の時の記事で、「ServiceNow」の提供している「Java」製のソフトウェアである「MID Server」というものについて調査してましたと。
で、ネット上の情報が錯綜しており、
- ServiceNow側のインスタンスのある環境
- MID Serverがインストールされたマシンが配置されている環境
の間の通信の仕組みが「ブラックボックス」になっていた。
ネットの情報を漁っていたところ、
ECC キューと AMB チャネル
外部通信チャネル (ECC) キューは、インスタンスと MID Server間の接続ポイントです。MID サーバーが実行する必要があるジョブは、MID サーバーがそれらを処理できる状態になるまでこのキューに保存されます。
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1437040
MID Serverは、非同期メッセージ バス (AMB) によって発行されたメッセージに登録し、MID Serverに保留中のタスクが ECC キューにあることを通知します。その MID Serverの ECC キューにジョブが存在する場合、MID Serverはステータスを「処理中」に設定します。要求されたジョブの処理が終了すると、MID サーバーは結果とともに ECC キューにレポートします。
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1437040
MID サーバーは、AMB)Client を介してインスタンスへの永続的な接続を開き、 /mid/server/<mid_sys_id> AMB チャネルでリッスンします。出力レコードがキュー [ecc_queue] テーブルに挿入されると、AMB メッセージが MID サーバーのチャネルに送信されます。MID Serverはこのメッセージを受信し、直ちに [ecc_queue] テーブルを作業用にポーリングします。
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1437040
MID サーバーは、AMB メッセージアクティビティに関係なく、mid.poll.time 設定パラメーターで定義された一定の間隔で ECC キューをポーリングします。デフォルトのポーリング間隔は 40 秒に設定されていますが、再設定できます。この定期的な間隔での ECC キューのポーリングは、AMB 接続が切断された場合に行われます。
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1437040
⇧ 上記のような情報が見つかった。
つまり、
- 正常時（AMB ※ 接続が確立されてる状態）
- ServiceNow側からの通知を待機
- 通知の方向：【送信元】ServiceNow側 → 【送信先】MID Server側
- 異常時（AMB ※ 接続の切断時。つまり、AMB ※ 接続が確立されていない状態）
※ Asynchronous Message Busの略らしい。
のような仕様らしい。
なのだが、いまいち、正常時の方の挙動が、
- AMB メッセージの受信は初回のみ
- AMB メッセージの受信後、ポーリングが開始されたら、AMB メッセージの受信はされなくなる。
- AMB メッセージの受信は継続的に続く
- AMB メッセージの受信後、ポーリングが開始されてからも、AMB メッセージの受信は継続される。
のどちらになるのかがハッキリしない...
つまり、「ポーリング」のプロセスの生存期間が分からないのである...
とりあえず、公式のドキュメントで、このあたりの情報が見つけ辛いのだが、
MID サーバーの ECC キュー
外部通信チャネル (ECC) キューは、インスタンスと MID サーバー間の接続ポイントです。MID サーバーが実行する必要があるジョブは、MID サーバーがそれらを処理できる状態になるまでこのキューに保存されます。
Asynchronous Message Bus
MID サーバーは Asynchronous Message Bus (AMB) によって発行されたメッセージに登録し、MID サーバーに処理待ちのタスクレコードが ECC キューにあることを通知します。その MID サーバーの ECC キューにタスクが存在する場合、MID サーバーはステータスを「処理中」に設定します。要求されたジョブの処理が終了すると、MID サーバーは結果とともに ECC キューにレポートします。
MID サーバーは AMB クライアントを介してインスタンスへの永続的な接続を開き、/mid/server/<mid_sys_id> AMB チャネルでリッスンします。出力レコードがキュー [ecc_queue] テーブルに挿入されると、AMB メッセージが MID サーバーのチャネルに送信されます。MID サーバーは、このメッセージを受信し、MID サーバーがビジー状態で、メッセージの優先度レベルがインタラクティブでない場合を除き、直ちに作業のために ecc_queue テーブルをポーリングします。
MID サーバーは、AMB メッセージアクティビティに関係なく、mid.poll.time 設定パラメーターで定義された最大の定期的な間隔 (デフォルトで 40 秒) で ECC キューをポーリングします。MID がビジー状態で、インタラクティブ以外の優先度レベルの AMB メッセージを受信した場合、キューのポーリング時間は mid.poll.time.standard (デフォルトで 5 秒) に変更されます。この定期的な間隔での ECC キューのポーリングは、AMB 接続が切断された場合に行われます。
MID サーバーの ECC キューのポーリング プロセス
注: MID サーバー上の AMB クライアントはすべての環境で動作するわけではなく、パフォーマンスの問題を避けるために無効にする必要がある場合もあります。環境内の AMB を無効にするには、mid.disable_amb パラメーターを true に設定します。AMB を無効にすると、MID サーバーは新しい各 ECC キュー出力レコードの通知を受信しなくなります。詳細については、MID サーバーパラメーター の mid.poll.time を参照してください。
⇧ 上記のページに記載があった。
なのだが、結局のところ、
- AMB メッセージの受信の処理のプロセス
- ポーリングの処理のプロセス
の関係性が不明瞭なのよね...
何と言うか、
- 正常時
- 異常時
で「シーケンス図」を公開してくれれば、処理の流れがハッキリするし、「送信元」と「送信先」も明確になって、「AMB メッセージの受信の処理のプロセス」と「ポーリングの処理のプロセス」の関係とかも一目瞭然となる気がするんだけどなぁ...
う～む...、ドキュメントの「ファインダビリティ（Findability）」が酷いのよね...
とりあえず、「MID Server」側で通知のリクエストを待ち受けているということは、「ServiceNow」側で「MID Server」に通知のリクエストが送信されるような設定が必要な気がするのだが、そのあたりがよく分からない...
必要な情報が探し辛過ぎるのよな...
結局のところ、「ServiceNow」の提供している「ソフトウェア」である「MID Server」の処理フローが「ブラックボックス」なんよなぁ...
一次情報の意味が無いんよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
