(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-25
(45)【発行日】2024-11-05
(54)【発明の名称】SSL通信処理装置及びSSL通信処理方法
(51)【国際特許分類】
G06F 9/48 20060101AFI20241028BHJP
G06F 9/50 20060101ALI20241028BHJP
【FI】
G06F9/48 300B
G06F9/50 120A
(21)【出願番号】P 2021045850
(22)【出願日】2021-03-19
【審査請求日】2023-12-15
(73)【特許権者】
【識別番号】000136136
【氏名又は名称】株式会社PFU
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】小木戸 諒
【審査官】坂東 博司
(56)【参考文献】
【文献】特表2017-521806(JP,A)
【文献】特開2001-292172(JP,A)
【文献】山下 克司,困ったときの現場ノウハウ,日経コミュニケーション 第392号,日本,日経BP社,2003年06月09日,第392号,pp.126-129,技術雑誌(国内) 2004-00524-007
【文献】山下 克司,つなぐだけではもう通用しない 理論派ネットワーキング 第3部 ネットワークとアプリケーション(2),日経コミュニケーション 第460号,日本,日経BP社,2006年04月15日,第460号,pp.114-119,技術雑誌(国内) 2006-01125-005
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/48
G06F 9/50
(57)【特許請求の範囲】
【請求項1】
SSL通信の暗号化処理又は復号化処理のリクエストを発行するリクエスト発行コアと、
前記リクエスト発行コアにより発行されたリクエストをキューイングするリクエストキューを複数含むリクエストキュー集合体と、
前記リクエストキューにキューイングされたリクエストを処理するデバイスと
を有し、
一つの前記リクエスト発行コアに対して、グループ化された複数のリクエストキューが割り当てられている
SSL通信処理装置。
【請求項2】
前記リクエスト発行コアは、グループ化された複数のリクエストキューのうち、代表のリクエストキューに対してリクエストを発行し、
このグループ化されたリクエストキューのうち、ラウンドロビンで選択されたリクエストキューが、前記代表のリクエストキューに対して発行されたリクエストをキューイングする
請求項1に記載のSSL通信処理装置。
【請求項3】
前記デバイスは、互いに独立して並列処理できる複数の子デバイスを含み、
グループ化された複数のリクエストキューは、互いに異なる子デバイスに割り当てられている
請求項1に記載のSSL通信処理装置。
【請求項4】
前記デバイスは、前記リクエストキューよりも多いエンジンを含む
請求項2に記載のSSL通信処理装置。
【請求項5】
リクエスト発行コアが、SSL通信の暗号化処理又は復号化処理のリクエストを、このリクエスト発行コアに割り当てられたリクエストキューのグループに対して発行するステップと、
前記グループに属するいずれかのリクエストキューが、前記リクエスト発行コアにより発行されたリクエストをキューイングするステップと、
SSL通信の暗号化処理又は復号化処理を行うデバイスが、前記リクエストキューにキューイングされたリクエストを処理するステップと
を有するSSL通信処理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、SSL通信処理装置及びSSL通信処理方法に関する。
【背景技術】
【0002】
例えば、特許文献1には、マルチコアを有するネットワークサービスプロセッサ内のワークを順序づけ、同期化しかつスケジューリングする装置であって、各ひとまとまりのワークは、このワークがいかに同期化されかつ順序づけられるべきかを示すタグによって特定され、異なるタグを有するワークを異なるプロセッサコアで並列に処理することによって、スループットが向上し、パケット処理は種々のステージに分割されることができ、各ステージは、順序づけおよび同期化に関する制約に応じて、異なるタグを有し、コアによって開始されるタグスイッチ操作は、ステージに応じてタグを切り換え、専用のタグスイッチバスが、タグスイッチ操作の待ち時間を最小限に抑える装置が開示されている。
【0003】
また、特許文献2には、記憶部1aが、複数のリクエスト間の関連性に関する情報およびリクエストの送信に関する優先度を該リクエストに対応付けて記憶し、処理部1bが、処理の実行に関する第1のリクエストを受信すると、記憶部1aを参照して、第1のリクエストに関連する第2のリクエストと、第2のリクエストに対応する第1の優先度とを特定し、処理部1bが、第1のリクエストに応じた処理を実行する情報処理装置2に、第1の優先度よりも高い第2の優先度で第2のリクエストを送信する送信制御装置が開示されている。
【0004】
また、特許文献3には、セキュリティ・オペレーションを処理する方法であって、プロセッサは、セキュリティ・オペレーションに対するいくつかの要求を処理するいくつかの実行ユニットを含み、これらの実行ユニットは、いくつかの要求の結果を、その要求に格納されているポインタに基づいて、遠隔メモリ内の要求に関連する出力データ構造に出力し、この実行ユニットは、要求待ち行列内の要求の順番とは異なる順番で結果を出力することができ、プロセッサは実行ユニットに結合されている要求ユニットも含み、要求ユニットは、要求の一部を遠隔メモリ内の要求待ち行列から取り出し、要求の一部に対する関連する入力データ構造を遠隔メモリから取り出し、さらに、要求ユニットは、取り出した要求を実行ユニットによる処理の可用性に基づいていくつかの実行ユニットに分配する方法が開示されている。
【先行技術文献】
【特許文献】
【0005】
【文献】特表2008-512950
【文献】特開2019-040344
【文献】特表2003-216591
【発明の概要】
【発明が解決しようとする課題】
【0006】
SSL通信の暗号化処理又は復号化処理を行うデバイスの性能を十分に発揮させるSSL通信処理装置を提供することを目的とする。
【課題を解決するための手段】
【0007】
本発明に係るSSL通信処理装置は、SSL通信の暗号化処理又は復号化処理のリクエストを発行するリクエスト発行コアと、前記リクエスト発行コアにより発行されたリクエストをキューイングするリクエストキューを複数含むリクエストキュー集合体と、前記リクエストキューにキューイングされたリクエストを処理するデバイスとを有し、一つの前記リクエスト発行コアに対して、グループ化された複数のリクエストキューが割り当てられている。
【0008】
好適には、前記リクエスト発行コアは、グループ化された複数のリクエストキューのうち、代表のリクエストキューに対してリクエストを発行し、このグループ化されたリクエストキューのうち、ラウンドロビンで選択されたリクエストキューが、前記代表のリクエストキューに対して発行されたリクエストをキューイングする。
【0009】
好適には、前記デバイスは、互いに独立して並列処理できる複数の子デバイスを含み、グループ化された複数のリクエストキューは、互いに異なる子デバイスに割り当てられている。
【0010】
好適には、前記デバイスは、前記リクエストキューよりも多いエンジンを含む。
【0011】
また、本発明に係るSSL通信処理方法は、リクエスト発行コアが、SSL通信の暗号化処理又は復号化処理のリクエストを、このリクエスト発行コアに割り当てられたリクエストキューのグループに対して発行するステップと、前記グループに属するいずれかのリクエストキューが、前記リクエスト発行コアにより発行されたリクエストをキューイングするステップと、SSL通信の暗号化処理又は復号化処理を行うデバイスが、前記リクエストキューにキューイングされたリクエストを処理するステップとを有する。
【発明の効果】
【0012】
SSL通信の暗号化処理又は復号化処理を行うデバイスの性能を十分に発揮させることができる。
【図面の簡単な説明】
【0013】
【
図1】ネットワーク装置1のハードウェア構成を例示する図である。
【
図2】ネットワーク装置1の機能構成を例示する図である。
【
図3】ネットワーク装置1におけるSSL処理(S10)を説明するフローチャートである。
【
図4】変形例におけるネットワーク装置1の機能構成を例示する図である。
【
図5】比較例1におけるネットワーク装置の機能構成を示す図である。
【
図6】比較例2におけるネットワーク装置の機能構成を示す図である。
【発明を実施するための形態】
【0014】
本発明の実施形態を、図面を参照して説明する。
図1は、ネットワーク装置1のハードウェア構成を例示する図である。
図1に例示するように、ネットワーク装置1は、リクエスト発行コア10と、リクエストキュー集合体12と、SSL処理デバイス14とを有する。
リクエスト発行コア10は、SSL(Secure Sockets Layer)通信の暗号化処理又は復号化処理のリクエストを発行する。例えば、リクエスト発行コア10は、複数のリクエスト発行コアを含み、これらのコアが並行してリクエストを発行する。
リクエストキュー集合体12は、複数のリクエストキュー120を含み、リクエスト発行コア10から発行されたリクエストをキューイングする。キューイングとは、先入れ先出し方式で、リクエストを保持することである。
SSL処理デバイス14は、SSL通信の暗号化処理又は復号化処理を行うエンジンを複数含むエンジン集合体であり、リクエストキュー集合体12にキューイングされたリクエストを順に処理する。
上記構成において、ネットワーク装置1のリクエスト発行コア10から、APIを介して、SSLアクセラレータのリクエストキュー(リクエストキュー120)に対して、暗号処理又は復号処理などのリクエストが発行される。
リクエストキュー120にキューイングされたリクエストは、SSLアクセラレータのエンジン(SSL処理デバイス14のエンジン)を使って処理され、リクエストが完了する。
リクエストの発行と完了は非同期であり、ネットワーク装置1が受けたデータを暗号化又は復号化する度に、リクエストを発行する。
【0015】
(背景)
図5に示される比較例1のように、リクエスト発行コアと、リクエストキューが1対1で対応する設計とすることも考えられる。このような設計の場合、リクエストキューの数が エンジンの数以上であるときは、問題ないが、リクエストキューの数がエンジンの数よりも少ないと、エンジンが余り、有効活用されない。
また、リクエストキューはその時点で空いている1つのエンジンを使用して、1リクエストを処理する。使用する空きエンジンは自動的に割り当てられ、ソフトウェアでは制御できない。
すなわち、
図5に示すように、使用可能なリクエストキュー数がエンジン数より少ないため、空きエンジンが発生する。エンジンをフル活用できないため、SSLアクセラレータは本来の性能を発揮できない。
図5の例では、リクエスト発行コア数が6個、リクエストキュー数が30個(そのうち6個使用可能)であり、エンジンのEN7~EN30は使えない。
なお、リクエストキューの番号と、エンジンの番号に関連性はなく、空いているエンジンが自動的に割り当てられる。
【0016】
そこで、本実施形態のネットワーク装置1では、SSLアクセラレータにおいて、複数のリクエストキューをグループ化し、そのグループの代表リクエストキューに対してリクエストを発行することでリクエスト処理を実行可能とする。
【0017】
図2は、ネットワーク装置1の機能構成を例示する図である。
図2に例示するように、ネットワーク装置1は、複数のリクエスト発行コア10と、グループ化されたリクエストキュー120と、複数のエンジン140が含まれたSSL処理デバイス14とを有し、リクエスト発行コア10それぞれに、グループ化されたリクエストキュー120が割り当てられている。
より具体的には、複数のリクエストキュー120をまとめたグループをノードとし、リクエスト発行コア10と同数のノードを作成する。1つのノードにつき、1つの代表リクエストキュー122が設定される。
【0018】
図3は、ネットワーク装置1におけるSSL処理(S10)を説明するフローチャートである。なお、本フローチャートでは、
図2の1つのリクエスト発行コア10に着目して説明する。他のリクエスト発行コア10も同様に並行して処理を行っている。
図3に例示するように、ステップ100(S100)において、リクエスト発行コア10は、割り当てられたリクエストキューのグループ(ノード)の代表リクエストキュー122に対してリクエストを発行する。
ステップ110(S110)において、代表リクエストキュー122は、自身が属するグループ(ノード)内に割り当てられているリクエストキュー120を選んでリクエストを発行する。選び方はラウンドロビンとする。
【0019】
ステップ120(S120)において、選ばれたリクエストキュー120は、発行されたリクエストをキューイングする。
ステップ130(S130)において、SSL処理デバイス14のエンジン140は、リクエストキュー120にキューイングされたリクエストを、処理する。
【0020】
以上説明したように、本実施形態のネットワーク装置1によれば、SSLアクセラレータで使用されるリクエストキュー140を増やし、発行するリクエスト数を増やすことでエンジン140を有効に活用し、SSLアクセラレータの性能を発揮することができる。すなわち、リクエストキュー120の数が、エンジン140の数、以上の状態をつくることができ、リクエスト発行コアとリクエストキューの関係が、1:多になる。
これにより、
図2の通り、リクエスト発行コア10がリクエストキュー120又はエンジン140の数より少なくとも、複数のリクエストキュー120から、リクエストを発行することができる。例えば、1番の代表リクエストキュー122にキューイングされた場合は、代表リクエストキューを含む、1番,7番,13番,19番,25番の5つのリクエストキュー120の内から1つを選択し、リクエストを発行する。
図2では、1番のリクエスト発行コア10から発行されるリクエストについて、リクエストキュー120からエンジンに矢印を引いたが、他のリクエスト発行コア10から発行されるリクエストについても同様に、リクエストキュー120からエンジン140に対して矢印を引ける。これより、エンジンを余すことなく有効活用できる。なお、リクエストキュー120の番号と、エンジン140の番号に関連性はなく、空いているエンジン140が自動的に割り当てられる。
【0021】
(変形例)
次に、上記実施形態の変形例として、SSLアクセラレータが、物理的には1つのデバイスだが、内部的に3つの子デバイスを持つ構造となっている場合を説明する。
この場合、
図6に示すように、通信時、使用されるリクエスト発行コアに偏りが出た場合には、使用される子デバイスに偏りが生じる。より具体的には、
図6において、3つの子デバイスA、B、Cに対し、リクエスト発行コアを均等に2つずつ割り当てた場合を比較例2として説明する。
各子デバイスのエンジンについては、A1~A10、B11~B20、C21~C30で示す。ここで、リクエスト発行コア1~4に偏った場合を考えると、リクエスト発行コア1及び2については、子デバイスAのみに割り当てられている。この時、A1~A10のエンジンのうち、空いているエンジンが自動的に割り当てられ、使用される。また、リクエスト発行コア3及び4については、子デバイスBのみに割り当てられている。ここで、B11~B20のエンジンのうち、空いているエンジンが使用される。その結果、子デバイスA、子デバイスBに偏って使用され、子デバイスCは、ほぼ使用されず、SSLアクセラレータとして、本来の3分の2程度の性能しか発揮されない。
【0022】
性能が発揮されないことについては、下記2つの側面がある。
・エンジンに対する負荷が高い場合に性能発揮できない
例えば、30個全てのエンジンでの処理を必要とするほどに、リクエスト量が多い且つ計算量が重いリクエストが集中した場合、子デバイスA及びBにリクエストが偏ってしまうと、使用できるエンジンは、A1~A10及びB11~B20の20個となってしまう。30個全てのエンジンを使用できないため、SSLアクセラレータ本来の性能を発揮できない。
・各子デバイスが持つ固有機能をフル活用できない
各子デバイスにはエンジン以外にも、固有の機能が存在している。例えば、特定の暗号種別について処理時、エンジンとは別に各子デバイスが持つ固有の回路を使用して計算されることが考えられる。そのため、全デバイスでは3回路使用できるが、2デバイスでは2回路しか使用されず、性能が発揮できない。この問題は上記のような高負荷時に限らず発生する。
【0023】
そこで、本変形例のネットワーク装置1では、グループ化された複数のリクエストキュー120が、互いに異なる子デバイスに割り当てられている。換言すると、グループ内の複数のリクエストキュー120が、複数の子デバイスにまたがって割り当てられている。より具体的には、
図4に示すように、各子デバイスのリクエストキュー120及びエンジン140をなるべく均等に使用し、性能を発揮するよう構成されている。
【0024】
具体的には、子デバイスを複数持つSSLアクセラレータとして、例えば、Silicom社のPE3ISLBTL(PCIe 3.0, x8 Crypto / Compression LBG Server Adapter)が挙げられる。このようなSSLアクセラレータにおいて、各子デバイスのリクエストキュー120をなるべく均等に使用するように、リクエスト発行コア10に対して割り当てる設計とする。
本変形例では、リクエスト発行コア10の数が6個、子デバイスの数が3個、子デバイスAのリクエストキュー120が1~10、子デバイスAのエンジン群15AがA1~A10、子デバイスBのリクエストキュー120が11~20、子デバイスBのエンジン群15BがB11~B20、子デバイスCのリクエストキューが21~30、子デバイスCのエンジン群15CがC21~C30である場合を説明する。なお、代表リクエストキュー122はキュー番号を丸で囲んで示す。また、リクエストキュー120の番号と、エンジン140の番号に関連性はなく、リクエストキュー120にキューイングされたリクエストは、そのリクエストキュー120と同じハッチングパターンで示されるエンジン140の中から、空いているエンジン140が自動的に割り当てられる。
【0025】
上記設定により、下記の効果がある。
・使用されるリクエスト発行コア10に偏りが出ても、子デバイスを分散して処理できるため、SSL処理デバイス14側の性能を落とさずに処理ができる。例えば、リクエスト発行コアが1番~4番に偏った場合でも、本変形例では、各リクエスト発行コア10に対応するリクエストキュー120から、子デバイスA~Cの3つ全てを使用できるため、全ての子デバイスの固有機能を使用できる。また、全ての子デバイスの全エンジン140を使用できる。よって、全ての子デバイスを使わない場合と比べて、性能劣化を軽減できる。
・1つの子デバイスにエラーが起こり、一時的に処理不可状態となる時でも、他の子デバイスがリクエスト処理可能となるので、処理を継続できる。例えば、子デバイスAが処理不可能となった場合には、リクエストキュー120の1番~10番が使用不可能となるが、11番~30番のリクエストキュー120については使用できるため、全てのリクエスト発行コア10について、リクエストの発行と処理を継続できる。
【0026】
このように、本変形例のネットワーク装置1によれば、使用されるリクエスト発行コア10に偏りが出ても、子デバイスを分散して処理できるため、SSLアクセラレータ全体としての性能を落とさずに処理ができる。
さらに、1つの子デバイスにエラーが起こり、一時的に処理不可状態になる場合でも、他の子デバイスがリクエスト処理を実行できるため、処理を継続できる。
【符号の説明】
【0027】
1…ネットワーク装置
10…リクエスト発行コア
12…リクエストキュー集合体
120…リクエストキュー
122…代表リクエストキュー
14…SSL処理デバイス
140…エンジン
15…エンジン群