[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

JP7277168B2 - リソースサービスシステム、及び、制御方法 - Google Patents

リソースサービスシステム、及び、制御方法 Download PDF

Info

Publication number
JP7277168B2
JP7277168B2 JP2019028392A JP2019028392A JP7277168B2 JP 7277168 B2 JP7277168 B2 JP 7277168B2 JP 2019028392 A JP2019028392 A JP 2019028392A JP 2019028392 A JP2019028392 A JP 2019028392A JP 7277168 B2 JP7277168 B2 JP 7277168B2
Authority
JP
Japan
Prior art keywords
data
module
receiving
processing
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019028392A
Other languages
English (en)
Other versions
JP2020135441A (ja
JP2020135441A5 (ja
Inventor
百重 内田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2019028392A priority Critical patent/JP7277168B2/ja
Priority to US16/787,622 priority patent/US11003400B2/en
Publication of JP2020135441A publication Critical patent/JP2020135441A/ja
Priority to US17/232,918 priority patent/US11537336B2/en
Publication of JP2020135441A5 publication Critical patent/JP2020135441A5/ja
Application granted granted Critical
Publication of JP7277168B2 publication Critical patent/JP7277168B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201Dedicated interfaces to print systems
    • G06F3/1202Dedicated interfaces to print systems specifically adapted to achieve a particular effect
    • G06F3/1218Reducing or saving of used resources, e.g. avoiding waste of consumables or improving usage of hardware resources
    • G06F3/122Reducing or saving of used resources, e.g. avoiding waste of consumables or improving usage of hardware resources with regard to computing resources, e.g. memory, CPU
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/02Capturing of monitoring data
    • H04L43/028Capturing of monitoring data by filtering
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201Dedicated interfaces to print systems
    • G06F3/1223Dedicated interfaces to print systems specifically adapted to use a particular technique
    • G06F3/1237Print job management
    • G06F3/1267Job repository, e.g. non-scheduled jobs, delay printing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201Dedicated interfaces to print systems
    • G06F3/1223Dedicated interfaces to print systems specifically adapted to use a particular technique
    • G06F3/1237Print job management
    • G06F3/1274Deleting of print job
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16YINFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y20/00Information sensed or collected by the things
    • G16Y20/30Information sensed or collected by the things relating to resources, e.g. consumed power
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0896Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/20Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Computer And Data Communications (AREA)

Description

本発明は、受信サービスシステムと非同期でデータを処理するリソースサービスシステム、制御方法、及びプログラムに関する。
近年、家電製品や自動車などをクライアント端末としてインターネットに接続する「Internet of Things」(以降、IoTと称する)を実現するシステムが利用されている。
また、画像形成装置の多機能化が進み、Multi Function Printer(以降、MFPと称する)と呼ばれる複合機もIoTクライアントとして対応することが可能となった。IoTシステムはクライアントに接続されたセンサー情報など膨大な量のデータを収集、分析することで、IoTクライアント及びそれを利用するユーザーに対してサービス、付加価値を提供する。
IoTシステムにおいては、前述した膨大な量のデータを、同じく膨大な数のIoTクライアント(単にクライアントとも称する)から受信するようになってきている。このようなデータをリアルタイムに受信して処理するようなストリーム処理では、刻一刻と変動する膨大なトラフィックが発生する。このようなトラフィックのデータを受信するサーバーは従来型のAPIを備えたリソースサーバーが単独で対応することは困難である。そこで、データの収集には、ストリーム処理専用の受信サービス(単に受信サービスとも称する)を利用し、サービスを提供する処理(リソースサービスと称する)は非同期処理として分離して対応することが一般的になりつつある。IoTクライアントはストリーム受信サービスにデータを送信し、ストリーム受信サービスはデータをバッファリングし、リソースサービスからのデータ受信要求に対してバッファリングからデータを供給する。このようにして、リソースサービスはIoTクライアントからの変動する膨大なトラフィックを意識することなく、データの処理に専念することができる。
また、ストリーム受信サービスからデータを転送されるリソースサービスは、複数存在することが可能である。リソースサービスはストリーム受信サービスとは非同期で処理を実行しているため、IoTシステムの開発において、提供するサービスの種類ごとに柔軟にリソースサービスを追加することができる。
特開2015-088130号公報
あるクライアントが、たとえばハードディスク故障などで、エラーに関するデータなどを通常とは異なる高頻度で受信サービスに送信する場合がある。そのような場合であっても、リソースサービスの負荷を考慮することなく受信サービスはデータを受信し、受信サービスにデータが存在する限り、リソースサービスは非同期でデータ処理を実行し続ける。一方で、リソースサービスが単位時間あたりに処理可能なデータ量には制限がある。そのため、一部のクライアントが通常とは異なる頻度で大量のデータを送信すると、リソースサービスが処理すべきデータ量が増え、結果として、他の正常なクライアントからのデータの処理に遅延が生じてしまう。
上述した特許文献1では、クライアントから管理システムへのデータの送信を中継する監視装置が、保存するデータの一部を削除してから管理システムへ送信することで、送信するデータ量を制御する方法を提案しているが、上記課題を解決するものではない。
そこで本発明は、リソースサービスシステムでの処理において、所定のクライアントから大量のデータが送信された場合に、他のクライアントのデータ処理を遅延させないための仕組みを提供することを目的とする。
上記課題を解決するために、本発明は、複数のクライアントからデータを受信する受信サービスシステムと通信可能な複数のリソースサービスシステムのうちの一つのリソースサービスシステムであって、複数のクライアントのいずれかからのデータであって、該データが所定の条件を満たすことに応じて前記受信サービスシステムが送信してきたデータに対応するメッセージを受信する受信手段と、前記受信手段が受信したメッセージに基づきデータ処理を実行する処理手段と、単位時間あたりに前記受信手段が受信した所定のクライアントからのデータに対応するメッセージの数が第1の所定数を超えるか否かを判定する判定手段と、前記処理手段によるデータ処理の対象としないメッセージを格納するためのキューを起動する起動手段と、前記判定手段により単位時間あたりに前記受信手段が受信した前記所定のクライアントからのデータに対応するメッセージの数が前記第1の所定数を超えると判定された場合に、前記受信サービスシステムから送信されてくる前記所定のクライアントからのデータに対応するメッセージが前記キューに格納されるよう設定する設定手段と、を有することを特徴とする。
本発明により、リソースサービスシステムでの処理において、所定のクライアントから大量のデータが送信された場合に、他のクライアントのデータ処理が遅延することを回避できる。
本発明の実施形態におけるシステムの全体図 ハードウェア構成図 ソフトウェア構成図 クライアント端末がストリーム受信サーバーに送信するストリームデータの一例 クライアント端末がストリーム受信サーバーにデータを送信する処理のシーケンス図 リソースサーバーがストリーム受信サーバーからメッセージサーバーを経由してデータを取得する処理のシーケンス図 リソースサーバーがクライアント端末の異常を検知する際のフローチャート リソースサーバーが異常データの処理を終了する際のフローチャート リソースサーバーが異常データの処理を終了する際にクライアント端末情報を保存する処理のフローチャート
以下、本発明を実施するための最良の形態について図面を用いて説明する。
(実施例1)
本実施例においては、ネットワーク上の各サーバーにアプリケーションが設置されていることとする。また、各アプリケーションはクライアント端末と連携し、様々な機能を提供することとする。このような機能を提供する実体をサービスと呼称し、機能をクライアント端末に提供することをサービスの提供と呼称する。また、複数のサーバーと複数のアプリケーションから複数のサービスを連携しあい提供するサービスを統合サービスと呼称する。
図1は、本実施例に係る情報処理システムであるデータ収集基盤システムの全体構成を示す図である。本実施例に係る情報処理システムは、クライアント端末のデータを受信する受信サービスシステム、および、受信したデータを処理してサービスを提供する複数のリソースサービスシステムを含む。受信サービスシステムと各リソースサービスシステムとは、非同期でデータ処理を行っている。本実施例に係る情報処理システムで提供されるサービスは、例えば、クライアント端末のデータをバックアップするサービスや、クライアント端末に接続されたセンサー情報から稼働状況を分析するサービスなどがある。
ネットワーク100は本システムの各構成要素を接続するWide Area Network(以降、WANと称する)である。
ネットワーク101、102、103は本システムの各構成要素を接続するLocal Area Network(以降、LANと称する)である。
クライアント端末104は、サービスを利用するためのパソコン、モバイル端末、画像形成装置などの機器である。
認証認可サーバー105は、クライアント端末104がサービスを利用するために必要となる認証・認可を実現するためのサーバーである。認証認可サーバー105は、クライアント端末104のリソースサーバー106、111へのアクセスを制御する。
リソースサーバー106、111は、クライアント端末104に対して様々なサービスを提供するサーバーである。例えば、リソースサーバー106はクライアント端末104のデータをバックアップするサービスや、クライアント端末104に接続されたセンサー情報を分析するサービスなどがある。
認証認可サーバー107は、認証認可サーバー105とは異なるサーバーであり、ストリーム受信サーバー108、ストリーム監視サーバー109、メッセージサーバー110への認証・認可を実現し、アクセスを制御するサーバーである。
ストリーム受信サーバー108は、ストリームにより連続的にデータ受信を行うサーバーであり、クライアント端末104が送信するストリームデータを受信する。
ストリーム監視サーバー109は、ストリーム受信サーバー108のデータ受信状況を定期的に確認し、ストリーム受信サーバー108がデータを受信したことを確認した場合に、メッセージサーバー110へ受信データを転送するサーバーである。
メッセージサーバー110は、本システムを構成するクライアント端末及び各サーバーで生成されたメッセージを通知するサーバーである。ここでのメッセージは、リソースサーバー106、111での処理対象となるデータを指す。メッセージサーバー110は、登録された通知先と、通知する条件に基づき、本システムの構成要素のいずれかが生成したメッセージを通知先に対してプッシュ通知を行う。
本実施例において、ストリーム受信サーバー108、ストリーム監視サーバー109、メッセージサーバー110によって、クライアントからのデータを受信する受信サービスシステムが構成される。また、リソースサーバー106、111のそれぞれが、クライアントのデータを処理してサービスを提供するリソースサービスシステムとして機能する。また本実施例において、クライアント端末104及び各サーバー105~111はそれぞれ1台で図示しているが、複数台で構成されていても良い。
図2は、クライアント端末104、認証認可サーバー105、107、リソースサーバー106、111、ストリーム受信サーバー108、ストリーム監視サーバー109、メッセージサーバー110を構成する情報処理装置の一般的なハードウェア構成である。なお、リソースサーバー106、111については、図2に示す各ハードウェアの機能はそれぞれ、仮想マシンソフトウェアによってアプリケーションソフトウェアとして実現され、物理ハードウェア要素と同様の挙動をとるものとする。認証認可サーバー105、107、ストリーム受信サーバー108、ストリーム監視サーバー109、メッセージサーバー110についても同様である。
CPU201は、ROM203のプログラROMに記憶された、あるいはハードディスクなどの外部メモリ211からRAM202にロードされたオペレーティングシステム(以降、OSと呼称する)やアプリケーションなどのプログラムを実行する。またCPU201は、システムバス204に接続される各ブロックを制御する。後述する各シーケンスの処理は、CPU201が実行するプログラムによって実現される。
RAM202は、CPU201の主メモリ、ワークエリアなどとして機能する。
操作部I/F205は、操作部209からの入力を制御する。
CRTコントローラー(CRTC)206は、CRTディスプレイ210の表示を制御する。
ディスクコントローラー(DKC)207は各種データを記憶するハードディスクなどの外部メモリ211におけるデータアクセスを制御する。
ネットワークコントローラー208は、WAN100あるいはLAN101、102、103を介して接続されたサーバーや他の機器との通信制御処理を実行する。
なお、後述する全ての説明においては、特に断りのない限り実行のハードウェア上の主体はCPU201であり、ソフトウェア上の主体は外部メモリ211にインストールされたアプリケーションプログラムである。
図3は、本実施例に係るクライアント端末104、認証認可サーバー105、107、リソースサーバー106、111、ストリーム受信サーバー108、ストリーム監視サーバー109、メッセージサーバー110、それぞれのソフトウェア構成を示す図である。各々のモジュールが実行されることで各々の機能が実現される。なお、図3で示す構成には、ハードウェアの構成を一部含む。
図3(a)で示すクライアント端末104は、トークンプロバイダー311、データ送信アプリケーション312を持つ。
トークンプロバイダー311は、認証認可サーバー105に対して、クライアント端末の認証要求、アクセストークンの発行依頼や取得を行う。データ送信アプリケーション312は、リソースサーバー106、111が提供するサービスを利用したり、クライアント端末104のデータをストリーム受信サーバー108に送信したりする。
図3(b)で示す認証認可サーバー105は、認証認可モジュール321、クライアント管理モジュール322を持つ。
認証認可モジュール321は、クライアント端末104からの認証要求に対する処理、認証されたクライアント端末104の認可処理を行う。クライアント管理モジュール322は、認証処理及び認可処理を行ったクライアント端末104を管理し、クライアント端末のIDや認証処理や認可処理に必要な情報を管理する。
図3(c)で示すリソースサーバー106、111は、リソースサーバーモジュール331、キューモジュール332、ストレージ333、退避用キューモジュール334、監視モジュール335を持つ。
リソースサーバーモジュール331は、ストリーム受信サーバー108がクライアント端末104のデータを受信した際にメッセージを通知するよう、メッセージサーバー110に通知先クライアントとして自身を登録する。また、キューモジュール332に蓄積されたストリームデータを取得し、そのデータを利用した様々な機能を実現する。例えば、リソースサーバーモジュール331は、受信したストリームデータをストレージ333に永続化したり、受信したストリームデータの内容に任意の値が含まれていた場合、別のリソースサーバーに通知を送信したりする。また、WebサービスとしてAPIを公開し、クライアント端末104からの要求を受け付け、サービスを提供する。
さらに、図7で後述するが、リソースサーバーモジュール331は、クライアント端末104の異常状態を検知し、他のクライアント端末のデータ処理に影響させないための制御を実施する。
キューモジュール332は、メッセージサーバー110経由でストリームデータを受信して格納する格納部として機能する。リソースサーバーモジュール331がメッセージサーバー110へ通知先クライアントとして自身を登録すると、クライアント端末104がストリーム受信サーバー108へデータを送信するたびにメッセージサーバー110経由でストリームデータを受信する。受信したストリームデータはリソースサーバーモジュール331が削除指示するまで蓄積する。
ストレージ333は、リソースサーバーモジュール331が処理したデータを永続化する。退避用キューモジュール334および監視モジュール335は、リソースサーバーモジュール331により起動されるモジュールであり、特定のクライアントに関わるメッセージを格納する。詳細は図7を用いて後述する。
なお、リソースサーバーモジュール331および監視モジュール335は、イベント駆動型コンピューティングサービスによってその機能が実現されても良い。クラウドコンピューティングサービスにおいて、特定のコンピューティングリソースに対して発生したイベントに応じて、軽量な処理を実行するサービスが提供されている。このようなサービスは、ハードウェアを関数単位で共有することで、サーバーの利用効率を更に高める、サーバレスと呼ばれる技術である。このサーバレスのサービスを用いると、常駐のサービスを構築して実現するよりも、コストを安く抑えることができる。具体的には、AWS Lambda、Google Cloud Functions、Microsoft Azure Functions等がある。
これらのサービスでは、クラウドコンピューティングサービスに対して所望の処理を実現するためのプログラムコードを、そのプログラムコードを実行する仮想マシンのCPUやメモリ等のスペックを指定して事前に登録する。そして、登録したプログラムコードをコンピューティングリソースとそのコンピューティングリソースに対して発生する特定のイベントと関連付ける。
図3の説明に戻る。認証認可サーバー105は、表1のクライアント管理テーブルに示すように、クライアントを一意に識別するためのクライアントIDとクライアントを認証するための公開鍵、さらにはクライアント端末104を一意に識別するためのデバイスシリアルを管理する。
認証認可モジュール321は、クライアントIDと公開鍵を元にクライアント端末104を認証し、クライアント端末104のデバイスシリアルを特定する。
Figure 0007277168000001
クライアント端末104のトークンプロバイダー311は表2のクライアント管理テーブルに示すように、自らの端末用のクライアントIDと秘密鍵を保持している。
Figure 0007277168000002
本実施例では、クライアントIDと非対称鍵を用いた認証を前提として説明するが、前述の通り認証方式は特に問わず、クライアントIDとシークレットによる認証といった他の方法でも良い。
また、クライアント端末104へのクライアントIDと秘密鍵の登録に関してクライアント端末の利用開始時に動的に登録する方法や、事前に登録しておくといった方法がある。例えば、動的に登録する場合、クライアント端末104に秘密の情報を保持させておき、その秘密の情報を認証認可サーバー105にリクエストすると、クライアントIDと非対称鍵が動的に生成される。クライアント端末104は認証認可サーバー105で生成されたクライアントIDと秘密鍵をレスポンスで取得し、クライアント管理テーブルで管理する。
図3(d)で示す認証認可サーバー107は、表3のクライアント管理テーブルに示すように、クライアントを一意に識別するクライアントIDとクライアントを認証するためのシークレットを管理している。そして、認証認可モジュール341はそれらの情報をもとにクライアント端末104を認証する。
Figure 0007277168000003
リソースサーバー106、111のリソースサーバーモジュール331は、表4のクライアント管理テーブルに示すように、認証を制御すべきクライアントのクライアントIDとシークレットを保持している。
Figure 0007277168000004
図3(e)で示すストリーム受信サーバー108は、ストリーム受信モジュール351を持つ。ストリーム受信モジュール351は、クライアント端末104からストリームデータの受信を行う。
ストリームデータの一例を図4で示す。ストリームデータ400は、データ発生時刻401、トピックID402、クライアント端末ID403、データ404の要素で構成される。
データ発生時刻401は、クライアント端末104がデータを生成した時刻が格納される。なお、本実施例においては日時表記をISO8601標準形式としているが、表記ルールを限定することはない。トピックID402には、クライアント端末104が生成したデータが関連するトピックを特定するIDが格納される。クライアント端末ID403は、ストリームデータを生成したクライアント端末を一意に特定するデバイスシリアルが格納される。データ404には、実データが格納される。
ストリーム監視サーバー109は、ストリーム監視モジュール361を持つ。
ストリーム監視モジュール361は、ストリーム受信サーバー108がクライアント端末104からストリームデータを受信したかどうか定期的に監視する。ストリーム受信サーバー108がストリームデータを受信したことを検知すると、ストリーム監視モジュール361はストリーム受信サーバー108からストリームデータを取得する。取得したストリームデータからトピックID402を確認し、メッセージサーバー110へトピックID402と関連付けてストリームデータを転送する。
図3(g)で示すメッセージサーバー110は、メッセージモジュール371、送信管理モジュール372、フィルタ管理モジュール373を持つ。
メッセージモジュール371は、ストリーム監視サーバー109経由でストリームデータを受信する。また、送信管理モジュール372で管理される通知先クライアント情報に従い、受信したストリームデータをクライアントへ通知する。
送信管理モジュール372は、メッセージモジュール371が受信するデータの通知先クライアントを管理する。
フィルタ管理モジュール373は、送信管理モジュール372で通知先クライアントに設定されているクライアントごとにメッセージ通知方法の制御を行うためのモジュールである。具体的には、リソースサーバー106、111がクライアント端末104の異常を検知した際、異常なクライアント端末104から送信されたストリームデータの通知方法をリソースサーバー106、111ごとに制御するために利用される。詳細は図7で後述する。
図5と図6にて、クライアント端末104がストリーム受信サーバー108へデータを送信する処理と、リソースサーバー106、111がメッセージサーバー110を経由してストリーム受信サーバー108からデータを取得して利用する処理の流れを説明する。
図5は、クライアント端末104がストリーム受信サーバー108へデータを送信する処理の流れを示したシーケンス図である。
S501において、クライアント端末104のデータ送信アプリケーション312は、トークンプロバイダー311にトークンの発行要求を送信する。トークンプロバイダー311は、表2で管理するクライアントIDと秘密鍵を利用してアサーションを作成し、アサーションとともにトークン発行リクエストを生成する。本実施例では、アサーションはRFC7519にて決められたJSON Web Token(以降、JWTと称する)を想定しており、JWTにはクライアントIDなどの情報が含まれる。
S502において、トークンプロバイダー311は認証認可サーバー105の認証認可モジュール321にアサーションを送信する。
認証認可モジュール321は、S502においてアサーションを送信したクライアント端末に該当する公開鍵を表1から取得して、アサーションの署名検証を行う。検証に成功した場合、認証認可モジュール321は、アクセストークンA1を発行し、S503においてレスポンスする。レスポンスを受信したトークンプロバイダー311は、S504においてアクセストークンA1をデータ送信アプリケーション312にレスポンスする。アクセストークンA1は、認証認可サーバー105によってアクセス制御が行われるリソースサーバー106、111へのクライアント端末104がアクセスするためのものである。
本実施例では、アクセストークンはJWTを想定しており、クライアントIDやクライアント端末104のデバイスシリアルといった情報、トークンの有効期限などの情報が含まれる。
S505において、データ送信アプリケーション312はS504で受信したアクセストークンA1を利用して、リソースサーバー106のリソースサーバーモジュール331にトークン発行要求を送信する。
S506において、リソースサーバーモジュール331は受信したトークン発行要求に含まれるアクセストークンA1の検証を行う。リソースサーバーモジュール331は認証認可モジュール321が発行したJWTを検証するための公開鍵を保持しており、JWTを検証することでクライアントの認可を行う。JWTの検証では、リソースサーバーモジュール331はJWTの署名が正しいかを公開鍵を用いて検証し、さらにJWTの有効期間中かどうかを検証する。また、アクセストークンA1を検証した結果、クライアント情報を取得することが可能であり、アクセス元のクライアント端末104をデバイスシリアルで識別できる。なお、リソースサーバーモジュール331は認証認可モジュール321にトークンの検証を依頼し、検証結果とクライアント情報を取得するといった別の実施形でも良い。リクエストを受けたリソースサーバーモジュール331はS507、S509において受信したリクエストに対する処理を行う。
S507において、リソースサーバーモジュール331は認証認可サーバー107の認証認可モジュール341にトークン発行要求を送信する。トークン発行要求は表4のクライアントIDとシークレットとともに送信する。トークン発行要求を受信した認証認可モジュール341は、表3で管理するクライアントIDとシークレットと、トークン発行要求に含まれるクライアントIDとシークレットとが一致する場合には、S508においてアクセストークンBを発行してレスポンスする。アクセストークンBは、認証認可サーバー107にアクセスするためのものである。
S509において、アクセストークンBを取得したリソースサーバーモジュール331は、認証認可モジュール341に対して、IDトークン発行要求を送信する。IDトークン発行要求では、リソースサーバーモジュール331はアクセストークンBとS506の検証結果から取得したクライアント端末104のクライアントIDを送信する。認証認可モジュール341は、S510において受信したクライアントID用のIDトークンを発行する。レスポンスを受信したリソースサーバーモジュール331は、S511においてIDトークンをデータ送信アプリケーション312にレスポンスする。
IDトークンとは、クライアント端末104を確かに認証したことを証明するトークンである。本実施例では、クライアント端末104の認証は、S506においてリソースサーバーモジュール331がアクセストークンA1を検証することで確認している。認証認可モジュール341はリソースサーバーモジュール331に対してクライアントIDとシークレットを提供する形で信頼関係を結んでおり、リソースサーバーモジュール331がクライアント端末104を認証した結果を信頼する。認証認可モジュール341はその信頼をもとにIDトークンを発行している形となる。また、IDトークンはJWT形式を想定しており、認証認可モジュール321は署名を検証することでIDトークンを検証可能である。
S512において、IDトークンを受信したクライアント端末104のデータ送信アプリケーション312は、認証認可サーバー107の認証認可モジュール341にトークン発行要求を行う。この要求にはS506で取得したIDトークンを含める。要求を受けた認証認可モジュール341はIDトークンの検証を行い、S513においてアクセストークンCを発行しレスポンスする。アクセストークンCは、ストリーム受信サーバー108、メッセージサーバー110へアクセスするためのものである。
S514において、アクセストークンCを受信したクライアント端末104のデータ送信アプリケーション312は、ストリーム受信サーバー108のストリーム受信モジュール351にデータ送信を行う。本データ送信ではアクセストークンCと、アクセストークンA1とを送信する。データ送信要求を受信したストリーム受信モジュール351はアクセストークンCを検証して問題が無ければ、アクセストークンA1とデータのペアを保持し、S515において結果をレスポンスする。
以上により、クライアント端末104はストリーム受信サーバー108へのデータ送信を完了する。
図5で示した処理が完了した際にストリーム受信サーバー108が保持するデータの一例を表5で示す。ストリーム受信サーバー108においてデータを一意に識別するID、データを受信した受信日時、受信したアクセストークンとデータと識別情報一式が1つのレコードとして管理され、受信日時順にソートされて保存されている。
また、これらレコードは受信後一定時間経過すると表5のストリームデータ保持テーブルから自動的に削除される。なお、削除前に外部のストレージサーバーへストリームデータを転送しても良い。外部のストレージサーバーとの連携については、実施例2で後述する。
Figure 0007277168000005
図6は、リソースサーバー106、111がストリーム受信サーバー108からストリームデータを取得し、リソースサーバー106、111が提供するサービスを実現するための処理を実行するまでの一連の流れを示したシーケンス図である。
S601からS606までの処理は、メッセージ通知先としてリソースサーバー106、111をメッセージサーバー110へ登録するまでの一連の処理である。
S601において、リソースサーバー106、111のリソースサーバーモジュール331は、認証認可サーバー107にトークン発行要求を送信する。本処理はS507と同様の処理である。認証認可サーバー107の認証認可モジュール341は、トークン発行要求を受信して、ストリーム受信サーバー108にアクセスするために必要なアクセストークンBを発行し、S602においてリソースサーバーモジュール331にレスポンスする。
S603において、リソースサーバーモジュール331は、メッセージサーバー110にクライアント端末104がストリーム受信サーバー108へデータ送信した際の通知先として自身の登録要求を送信する。本要求の送信においては、アクセストークンBとリソースサーバー106、111のクライアントID、通知を受ける条件など合わせて送信する。通知を受ける条件は、本実施例ではクライアント端末104が送信するデータでリソースサーバー106、111の関心のあるトピック情報、となる。メッセージサーバー110のメッセージモジュール371は、アクセストークンBを検証して問題がなければ、受信した登録要求を送信管理モジュール372に渡す。
S604において、送信管理モジュール372は、受信したリソースサーバー106、111の登録要求に含まれる各情報を保存する。送信管理モジュール372が保持する送信管理データの一例を表6に示す。
Figure 0007277168000006
送信管理データはストリームデータの種別を識別するトピックID、そのメッセージの通知先となるクライアントIDとを関連付けて1つのレコードとして保存される。
S605において、送信管理モジュール372は送信管理データを保存したことをメッセージモジュール371へレスポンスする。レスポンスを受信したメッセージモジュール371は、S606においてリソースサーバーモジュール331へ結果をレスポンスする。
S607からS616までの処理は、メッセージサーバー110経由でクライアント端末104が送信したデータをリソースサーバー106、111へメッセージ通知するまでの一連の処理である。
S607およびS608は、ストリーム監視サーバー109のストリーム監視モジュール361が認証認可サーバー107にトークン発行要求を行う処理で、S501およびS502と同様のため説明を省略する。
S609において、ストリーム監視モジュール361はストリーム受信サーバー108がクライアント端末104からデータを受信したかどうかを確認する。S609の処理は一定間隔おきに実施され、ストリーム受信サーバー108がクライアント端末104からデータを受信すると、ストリーム受信モジュール351は受信したデータをS610においてストリーム監視モジュール361へレスポンスする。データを受信したストリーム監視モジュール361は、受信したストリームデータからトピックIDを確認し、S611において、トピックIDとストリームデータとを関連付けてメッセージサーバー110へ送信する。トピックIDとストリームデータを受信したメッセージモジュール371は、トピックIDとストリームデータとを関連付けて保存し、S612において結果をレスポンスする。メッセージモジュール371が保存するデータの一例を表7に示す。
Figure 0007277168000007
メッセージモジュール371は受信したトピックIDとストリームデータを関連付けて1つのレコードとしてメッセージテーブルに保存する。
S613において、メッセージモジュール371はメッセージテーブルに保存されたレコードのトピックIDの値に該当するレコードが存在するか送信管理モジュール372へ問い合わせる。送信管理モジュール372は、表6の送信管理データテーブルを確認し、S614において結果をレスポンスする。
表6の送信管理データテーブルに該当するレコードが存在していた場合は、メッセージモジュール371は、S615においてS614で取得したメッセージの送信対象のクライアントIDを確認する。そして、メッセージモジュール371は、対応するリソースサーバー106、111にストリームデータ400をメッセージとして送信する。
S616において、メッセージサーバー110からメッセージを受信したリソースサーバー106、111のキューモジュール332は受信したメッセージを保存する。
S617からS622までの処理は、リソースサーバー106、111が提供するサービスを実現するための一連の処理である。なお、S617以降の処理は、S616までの処理とは独立して非同期で実施されるものとする。
S617において、リソースサーバーモジュール331は定期的にキューモジュール332に未処理のメッセージが存在するかを問い合わせる。未処理のメッセージが存在する場合、キューモジュール332はS618において、リソースサーバーモジュール331へメッセージを送信する。
S619において、リソースサーバーモジュール331は提供するサービスに応じてデータ処理を行い、処理後のデータをストレージ333へ保存する。処理終了後、S620において、キューモジュール332へメッセージ削除要求を行う。メッセージ削除要求を受信したキューモジュール332はS621において、対象のメッセージを削除し、S622においてリソースサーバーモジュール331へ結果をレスポンスする。
図5、図6において、ストリーム受信サーバー108およびメッセージサーバー110を介して、クライアント端末104から送信されたデータをリソースサーバー106、111がそれぞれ処理するまでの一連の流れを示した。この処理では、クライアント端末104が行うデータ送信と、リソースサーバー106、111がサービス提供するために行うデータ処理とがそれぞれ独立して非同期に行われる。これによりクライアント端末104はリソースサーバー106、111でのデータ処理の結果を待たずに、自装置で作成されるデータを送信することができる。
しかし、クライアント端末104が何らかの原因によって故障し、たとえばエラーに関するデータを大量にストリーム受信サーバー108へ送信するケースがある。メッセージサーバー110からリソースサーバー106、111へのメッセージ通知処理は、クライアント端末104がデータを送信するたびに実施されるため、リソースサーバー106、111は大量のデータをキューモジュール332へ蓄積することになる。リソースサーバーモジュール331はキューモジュール332に蓄積されているメッセージデータを順次処理することになるが、リソースサーバーモジュール331が単位時間に処理可能なメッセージ数には上限がある。そのため、エラーデータを大量に送信するクライアント端末104が1台でも存在すると、正常なクライアント端末104のデータ処理に遅延が発生してしまう。
本実施例において、図7、図8を用いて、クライアント端末104の異常をリソースサーバー106、111で検知し、クライアント端末104が異常データを送信してきた際の処理フローについて説明する。
図6のS617以降の処理において、リソースサーバー106、111がクライアント端末104の異常を検知し、異常データを処理する詳細なフローチャートを図7に示す。図7で示すフローチャートはリソースサーバー106、111のリソースサーバーモジュール331が実施する処理であり、キューモジュール332からメッセージ受信を検知すると処理が開始される。
S701において、リソースサーバーモジュール331は、登録済みのトピックを利用してキューモジュール332からメッセージを取得した後、メッセージの内容に基づいてサービス提供のためのデータ処理を実施する。リソースサーバーモジュール331は、取得したストリームデータの内容からクライアント端末104を一意に識別するクライアント端末IDを特定する。
S702において、リソースサーバーモジュール331は、S701で処理した結果をストレージ333へ保存する。
S703において、リソースサーバーモジュール331は、S701で特定したクライアント端末IDに関するストレージ333への書き込み処理が単位時間当たりに閾値を超えたかどうか確認する。閾値を超えた場合、リソースサーバーモジュール331は、S704以降の処理を実施する。ここでの単位時間とは、例えば、13時から14時までの60分といったように定めても良いし、また、一日の中で特定クライアント端末からあるトピックのデータが初めて送られてきた時刻から30分おきといったように定めてもよい。
S703における処理は、メッセージモジュール371からキューモジュール332に送信されたデータが所定数を超えるかどうか判定するための処理である。メッセージモジュール371からキューモジュール332に送信されたデータが所定数以下である場合、図7のフローチャートの処理を終了する。
なお、本実施例では、ここでの判定に、リソースサーバーモジュール331が単位時間あたりに処理したメッセージの数を用いているが、代わりに、キューモジュール332内に格納されているメッセージの数を用いても良い。また、リソースサーバーごとにデータ処理能力などが異なるため、ここでの判定に用いられる閾値はリソースサーバーごとに異なるものとなる。
S704において、リソースサーバーモジュール331は、メッセージサーバー110のフィルタ管理モジュール373に対してフィルタ設定を行う。具体的には、リソースサーバーモジュール331は、S701で特定したクライアント端末104からのデータ受信のみを除外するという設定を行う。この除外フィルタ設定を実施することによって、異常なクライアント端末104から大量にデータが送信された場合であっても、メッセージサーバー110からキューモジュール332へのメッセージ通知を回避することができる。S704におけるフィルタ設定後のフィルタ管理モジュール373が保持するフィルタ管理データの一例を表8に示す。
Figure 0007277168000008
フィルタ管理データはストリームデータの種別を識別するトピックIDと、そのメッセージの通知先となるクライアントIDと、フィルタ情報とを関連付けて1つのレコードとして保存される。表8では、S701で特定したクライアント端末ID「123456789」がメッセージ通知対象外のクライアント端末104として追加された例を示している。
S705において、リソースサーバーモジュール331は、退避用キューモジュール334を起動する。退避用キューモジュール334は、S704でメッセージ通知を除外したクライアント端末104からのデータ受信のみを検知するためのキューモジュールである。退避用キューモジュール334は、クライアント端末104ごとに起動され、異常状態であると判断したクライアント端末104が複数ある場合はクライアント端末104と同じ数だけ起動される。また、S706の処理は退避用キューモジュール334ごとに実施するため、異常状態であると判断したクライアント端末104が複数ある場合は、複数のクライアント端末104に対応する退避用キューモジュール334ごとに実施される。
S706において、リソースサーバーモジュール331は、メッセージサーバー110に対して退避用キューモジュール334へのメッセージ通知設定を実施する。具体的には、リソースサーバーモジュール331は、メッセージサーバー110の送信管理モジュール372に退避用キューモジュールを登録し、フィルタ管理モジュール373に対してフィルタ設定を行う。S706におけるメッセージ通知設定後の送信管理モジュール372およびフィルタ管理モジュール373が保持する送信管理データの一例を表9、10に示す。
Figure 0007277168000009
トピックID「clientErr」の通知先クライアントIDとして、退避用キューモジュール334のクライアント端末ID「resourcesrv106_evacuation_123456789」が追加される。
Figure 0007277168000010
フィルタ管理データには、退避用キューモジュール334へ通知するメッセージのフィルタとして、S701で特定したクライアント端末ID「123456789」からのデータ受信のみ通知するようなフィルタ情報が追加される。
S707において、リソースサーバーモジュール331は、監視モジュール335の起動設定を行う。監視モジュール335は、退避用キューモジュール334のメッセージ数の推移を一定間隔で確認するモジュールで、S707ではどの程度の間隔でメッセージ数を確認するかの設定を行う。
以上の処理によって、リソースサーバー106、111がクライアント端末104の異常を検知し、異常データを通常のデータ処理対象外にすることが可能となる。しかし、異常なクライアント端末104は異常データを送信し続ける訳ではない。たとえばハードディスク故障で異常データを送信している場合には、ハードディスクを交換することでクライアント端末104は正常なデータ送信を行うことになる。他の原因による異常データ送信であっても、いつかは原因が特定されクライアント端末104は正常状態に戻る。図7で説明した処理では、リソースサーバー106、111で一度異常状態を検知すると、異常なクライアント端末104と判定されたクライアント端末104から受信するデータは処理対象外となる。図8において、異常と判断したクライアント端末104が正常状態に戻ったかどうかを判断し、正常状態に戻った場合にはデータ処理対象に戻すための方法について説明する。
S707において、監視モジュール335の起動設定が実施されると、設定情報に応じて定期的に監視モジュール335が起動される。図8で示したフローチャートはリソースサーバー106、111の監視モジュール335が実施する処理である。退避用キューモジュール334が複数存在する場合は、全ての退避用キューモジュール334が処理対象となる。
S801において、監視モジュール335は、退避用キューモジュール334のメッセージ総数を確認する。
S802において、監視モジュール335は、S801で確認したメッセージ数と前回確認したメッセージ総数との差分をとり、メッセージ総数の増分がある閾値以下になったかどうかの確認を行う。メッセージ総数の増分が閾値を超えている場合にはS806を実施し、閾値以下の場合にはS803以降の処理を実施する。S802における処理は、クライアント端末104が一定期間内に送信するデータ数を確認することで、クライアント端末104が正常になったかどうかを確認するための処理である。メッセージ総数の増分が閾値を超えている場合は、クライアント端末104はまだ異常状態であると判断する。メッセージ総数の増分が閾値以下の場合は、クライアント端末104が正常な状態になったと判断し、クライアント端末104から送信されるデータを処理対象に戻す処理を実施する。
S803において、監視モジュール335は、S706で設定した退避用キューモジュール334へのメッセージ通知設定を解除する。具体的には、監視モジュール335は、メッセージサーバー110のフィルタ管理モジュール373から退避用キューモジュールに関するフィルタ設定を削除し、送信管理モジュール372の通知先クライアントから退避用キューモジュールの削除依頼を実施する。
S803におけるメッセージ通知停止設定後の送信管理モジュール372およびフィルタ管理モジュール373が保持する送信管理データ、フィルタ管理データの一例を表11、12に示す。
Figure 0007277168000011
Figure 0007277168000012
S804において、監視モジュール335は、退避用キューモジュール334を削除する。この時、退避用キューモジュール334内に格納されているメッセージも削除される。
S805において、監視モジュール335は、メッセージサーバー110のフィルタ管理モジュールからクライアント端末104の除外フィルタ設定の削除を行う。
S806において、監視モジュール335は、未確認の退避用キューモジュール334が存在するか確認し、存在する場合は、未確認の退避用キューモジュール334に対してS801以降の処理を実施する。未確認の退避用キューモジュール334が存在しない場合は、監視モジュール335は、S807の処理を実施する。
S807において、監視モジュール335は、起動中の退避用キューモジュール334が存在するか確認し、存在する場合は処理を終了する。起動中の退避用キューモジュール334が存在しない場合は、S808において、S707で有効にされた監視モジュール335の起動設定が無効にされる。これにより、監視モジュール335が定期的に起動しなくなる。
以上の処理により、クライアント端末104が異常状態から正常状態に戻ったことを検知し、正常状態に戻った場合に、通常のデータ処理を再開することが可能となる。
図7を用いて、所定のクライアント端末104から大量のデータが送信された場合、他のクライアントのデータ処理が遅延することを回避できる仕組みを説明した。
さらに、図8を用いて、所定のクライアント端末104から送信されるデータの量が正常に戻ったと判断できた場合には、そのクライアント端末104のデータ処理を再開することができる仕組みも説明した。
以上の説明したように、本実施例では、所定のクライアント端末104から大量のデータが送信された場合、そのクライアントのデータを退避用キューに格納するようにした。これにより、キューモジュールに格納されている他のクライアントのデータの処理が遅延することを回避できる。
(実施例2)
実施例1に示した方法により、クライアント端末104が異常データを送信してきた場合であっても、リソースサーバー106、111は正常なクライアント端末104に対するサービス提供が可能であることを説明した。
しかしながら、実施例1で示した方法では、リソースサーバー106、111により異常であると判定されたクライアント端末104が送信するデータは、データ処理対象外のためストレージ333への書き込み処理が行われずにそのまま削除される。そのため、後から異常データを解析のために参照したいといったケースにおいて問題がある。
本実施例において、異常状態に陥ったクライアント端末104の状態を後から解析するために必要なデータを保持する方法について説明する。
本実施例において、ストリーム受信サーバー108が受信するストリームデータは、外部のストレージサーバーで保持されていること、また外部のストレージサーバーが保持するストレージデータを参照可能であることを前提とする。
図9は、本実施例における詳細なフローチャートである。S901からS903の処理については、実施例1の図8のS801からS803の処理と同様のため説明を省略する。
S904において監視モジュール335は、実施例1の図7で説明したS701で特定したクライアント端末IDと、S705で起動した退避用キューモジュール334の起動した時刻と、現在の時刻をストレージ333へ保存する。ストレージ333が保持する異常クライアント端末管理データの一例を表13に示す。
Figure 0007277168000013
異常クライアント端末管理データテーブルでは、クライアント端末ID、退避用キューモジュール334の動作を開始した開始日時、退避用キューモジュール334の動作を終了した終了日時を関連付けて1つのレコードとして保存される。なお、リソースサーバー106、111がクライアント端末104の異常を検知することで、リソースサーバーモジュール331によって退避用キューモジュール334は起動される。また、リソースサーバー106、111がクライアント端末104の異常解消を検知することで、監視モジュール335によって退避用キューモジュール334は削除される。
なお、本実施例においては日時表記をISO8601標準形式としているが、表記ルールを限定することはない。
S905からS909の処理については、実施例1の図8のS804からS808の処理と同様のため説明を省略する。
以上説明したように本実施例では、リソースサーバー106、111がクライアント端末104の識別情報および退避用キューモジュールが起動していた期間情報を保持する方法を示した。結果、ストレージサーバーで保持する異常データからクライアント端末104の異常状態解析に役立てることができる。
(他の実施例)
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。
ここで、本発明は、上述した実施形態の機能を実現する1つ以上のソフトウェア(プログラム)を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の1つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の1つ以上のコンピューター(CPUやMPU等)によりそのプログラムが読み出され、実行される。つまり、本発明の1つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピューターにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路(例えば、ASIC)によっても、本発明は実現可能である。
106、111 リソースサーバー
201 CPU
331 リソースサーバーモジュール
332 キューモジュール
334 退避用キューモジュール

Claims (6)

  1. 複数のクライアントからデータを受信する受信サービスシステムと通信可能な複数のリソースサービスシステムのうちの一つのリソースサービスシステムであって、
    複数のクライアントのいずれかからのデータであって、該データが所定の条件を満たすことに応じて前記受信サービスシステムが送信してきたデータに対応するメッセージを受信する受信手段と、
    前記受信手段が受信したメッセージに基づきデータ処理を実行する処理手段と、
    単位時間あたりに前記受信手段が受信した所定のクライアントからのデータに対応するメッセージの数が第1の所定数を超えるか否かを判定する判定手段と、
    前記処理手段によるデータ処理の対象としないメッセージを格納するためのキューを起動する起動手段と、
    前記判定手段により単位時間あたりに前記受信手段が受信した前記所定のクライアントからのデータに対応するメッセージの数が前記第1の所定数を超えると判定された場合に、前記受信サービスシステムから送信されてくる前記所定のクライアントからのデータに対応するメッセージが前記キューに格納されるよう設定する設定手段と、
    を有することを特徴とするリソースサービスシステム。
  2. 記処理手段による処理の結果に関する情報をストレージに保存する保存手段と、を更に有することを特徴とする請求項1に記載のリソースサービスシステム。
  3. 前記判定手段は、前記ストレージに保存される情報に基づき、単位時間あたりに前記受信手段が受信した前記所定のクライアントからのデータに対応するメッセージの数が前記第1の所定数を超えるかどうかを判定することを特徴とする請求項2に記載のリソースサービスシステム。
  4. 定期的に行われる前記キューに格納されていくメッセージの数の監視の結果に基づき、当該キューと、当該キューに格納されていた前記所定のクライアントからのデータに対応するメッセージとを削除する削除手段をさらに有し、
    前記キューが削除される場合には、前記設定手段による前記所定のクライアントからのデータに対応するメッセージが前記キューに格納されるようにする設定が解除されることを特徴とする請求項1乃至3のいずれか1項に記載のリソースサービスシステム。
  5. 前記処理手段は、単位時間あたりに前記受信手段が受信した前記所定のクライアントからのデータに対応するメッセージの数が前記第1の所定数を超えないと判定される場合に、前記受信手段が受信したメッセージに基づきデータ処理を実行することを特徴とする請求項1乃至4のいずれか1項に記載のリソースサービスシステム。
  6. 複数のクライアントからデータを受信する受信サービスシステムと通信可能な複数のリソースサービスシステムのうちの一つのリソースサービスシステムにおける制御方法であって、
    複数のクライアントのいずれかからのデータであって、該データが所定の条件を満たすことに応じて前記受信サービスシステムが送信してきたデータに対応するメッセージを受信する受信工程と、
    前記受信工程で受信されたメッセージに基づきデータ処理を実行する処理工程と、
    単位時間あたりに前記受信工程で受信された所定のクライアントからのデータに対応するメッセージの数が第1の所定数を超えるか否かを判定する判定工程と、
    前記処理工程でのデータ処理の対象としないメッセージを格納するためのキューを起動する起動工程と、
    前記判定工程で単位時間あたりに前記受信工程で受信された前記所定のクライアントからのデータに対応するメッセージの数が前記第1の所定数を超えると判定された場合に、前記受信サービスシステムから送信されてくる前記所定のクライアントからのデータに対応するメッセージが前記キューに格納されるよう設定する設定工程と、
    を有することを特徴とする制御方法。
JP2019028392A 2019-02-20 2019-02-20 リソースサービスシステム、及び、制御方法 Active JP7277168B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2019028392A JP7277168B2 (ja) 2019-02-20 2019-02-20 リソースサービスシステム、及び、制御方法
US16/787,622 US11003400B2 (en) 2019-02-20 2020-02-11 Resource service system, control method, and storage medium
US17/232,918 US11537336B2 (en) 2019-02-20 2021-04-16 Resource service system, control method, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019028392A JP7277168B2 (ja) 2019-02-20 2019-02-20 リソースサービスシステム、及び、制御方法

Publications (3)

Publication Number Publication Date
JP2020135441A JP2020135441A (ja) 2020-08-31
JP2020135441A5 JP2020135441A5 (ja) 2022-02-25
JP7277168B2 true JP7277168B2 (ja) 2023-05-18

Family

ID=72042079

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019028392A Active JP7277168B2 (ja) 2019-02-20 2019-02-20 リソースサービスシステム、及び、制御方法

Country Status (2)

Country Link
US (2) US11003400B2 (ja)
JP (1) JP7277168B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020144763A (ja) * 2019-03-08 2020-09-10 キヤノン株式会社 システム、および制御方法
CN114116187B (zh) * 2020-08-26 2024-02-02 中国电信股份有限公司 容器资源动态扩容方法和装置
CN112084090B (zh) * 2020-09-03 2024-02-23 深信服科技股份有限公司 服务器管理方法、服务器、管理终端及存储介质
CN113315718B (zh) * 2021-03-31 2023-11-14 阿里巴巴新加坡控股有限公司 自适应限流的系统、方法和装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197119A (ja) 2000-01-13 2001-07-19 Nec Corp サーバ装置、ネットワークシステム、及びその受信負荷制御方法
JP2001306511A (ja) 2000-04-25 2001-11-02 Pfu Ltd マシン情報の収集方法およびマシン情報の収集装置ならびにその記録媒体
JP2002016633A (ja) 2000-06-30 2002-01-18 Ntt Communications Kk 通信状態制御方法および通信状態制御システム
JP2002247114A (ja) 2001-02-14 2002-08-30 Nippon Telegr & Teleph Corp <Ntt> ゲートウェイ装置における過負荷防御方法及びその装置
JP2005197959A (ja) 2004-01-06 2005-07-21 Nec Access Technica Ltd ルータ
JP2006100874A (ja) 2004-09-28 2006-04-13 Nippon Telegr & Teleph Corp <Ntt> アプリケーション型サービス不能攻撃に対する防御方法およびエッジ・ルータ

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015088130A (ja) 2013-11-01 2015-05-07 キヤノン株式会社 監視装置、その制御方法およびプログラム
JP2016083870A (ja) * 2014-10-27 2016-05-19 キヤノン株式会社 画像形成装置及びその制御方法、システム
US9654501B1 (en) * 2014-12-15 2017-05-16 Amazon Technologies, Inc. Mitigation of distributed denial-of-service attacks
US10452328B2 (en) * 2016-08-31 2019-10-22 Vmware, Inc. Extensible token-based authorization

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197119A (ja) 2000-01-13 2001-07-19 Nec Corp サーバ装置、ネットワークシステム、及びその受信負荷制御方法
JP2001306511A (ja) 2000-04-25 2001-11-02 Pfu Ltd マシン情報の収集方法およびマシン情報の収集装置ならびにその記録媒体
JP2002016633A (ja) 2000-06-30 2002-01-18 Ntt Communications Kk 通信状態制御方法および通信状態制御システム
JP2002247114A (ja) 2001-02-14 2002-08-30 Nippon Telegr & Teleph Corp <Ntt> ゲートウェイ装置における過負荷防御方法及びその装置
JP2005197959A (ja) 2004-01-06 2005-07-21 Nec Access Technica Ltd ルータ
JP2006100874A (ja) 2004-09-28 2006-04-13 Nippon Telegr & Teleph Corp <Ntt> アプリケーション型サービス不能攻撃に対する防御方法およびエッジ・ルータ

Also Published As

Publication number Publication date
US20210232348A1 (en) 2021-07-29
JP2020135441A (ja) 2020-08-31
US11003400B2 (en) 2021-05-11
US11537336B2 (en) 2022-12-27
US20200264813A1 (en) 2020-08-20

Similar Documents

Publication Publication Date Title
JP7277168B2 (ja) リソースサービスシステム、及び、制御方法
US8321530B2 (en) Cloud computing system, server computer, device connection method, and storage medium
US11277404B2 (en) System and data processing method
WO2018036314A1 (zh) 一种单点登录认证方法及装置、存储介质
US11025425B2 (en) User security token invalidation
US9264414B2 (en) Retry and snapshot enabled cross-platform synchronized communication queue
JP6278651B2 (ja) ネットワークシステム、管理サーバシステム、制御方法及びプログラム
US10567492B1 (en) Methods for load balancing in a federated identity environment and devices thereof
US11570126B2 (en) System, client terminal, control method, and storage medium
US10659331B2 (en) Network system, device management method, network device, control method thereof, and non-transitory computer-readable medium
JP2009245268A (ja) 業務管理システム
US11388154B2 (en) Information processing apparatus, system, and non-transitory computer-readable storage medium
US20170017520A1 (en) System and control method
US11223578B2 (en) System and control method to direct transmission of event data to one of a plurality of reception queues
US20190037041A1 (en) Information processing system and control method
US10757172B2 (en) Management system and method
TWI818167B (zh) 通訊系統、資訊提供裝置、電腦可讀取記憶媒體及資訊提供方法
US20240171575A1 (en) Monitoring apparatus and control method thereof
JP2006309595A (ja) ネットワークシステム、情報処理装置、及び通信制御方法
JP2015141523A (ja) システム、システムの制御方法およびコンピュータプログラム
JP7304039B2 (ja) 通信システム
JP2017191997A (ja) 管理装置、撮影装置およびそれらの制御方法、撮影システム、プログラム
US10567341B2 (en) Information processing apparatus capable of receiving event, method of controlling the same, and storage medium
JP2020140431A (ja) 情報処理装置、情報処理システム、及び情報処理プログラム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220216

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220216

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20221007

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221018

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221214

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230404

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230508

R151 Written notification of patent or utility model registration

Ref document number: 7277168

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151