世界最大級のモバイルISPシステムを実現したOMCSの超並列システムモデル

全文

(1)情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). コンシューマ・サービス論文. 世界最大級のモバイル ISP システムを実現した OMCS の超並列システムモデル相澤正俊1. 東健二2. 大藤豊喜2. 川浦立志2,a). 受付日 2012年5月18日, 採録日 2012年12月7日. 概要：NTT ドコモの i モードシステムに代表される大規模 ISP（Internet Service Provider）システムを実現するために，サーバあたり 10000 スレッドを稼動させるべく，ミドルウェアの開発を行い，同時に，. OS のネック解消のために，OS 改造を行った．また，大規模 ISP システムを 3 つの層に分解し，個々の層を構成するサーバ群を 10000 スレッドが稼動できるサーバをベースに構成し，かつ，サーバ群に負荷を均等に分散させる仕組みを導入し，さらに，メールボックスのファイルシステムを高速化することで，大規模 ISP を構築するためのシステムモデルを確立した．キーワード：並列処理，ミッションクリティカル，システムモデル，ISP，OMCS. Ultra Parallel System Model of OMCS Adopted in Large Wireless ISP Masatoshi Aizawa1. Kenji Higashi2. Toyoki Ohtoh2. Tatsushi Kawaura2,a). Received: May 18, 2012, Accepted: December 7, 2012. Abstract: We established System Model for large-scale ISP (Internet Service Provider) such as i-mode system of NTT DoCoMo by following technical improvement. 1) development of middleware to operate 10000 threads on one server. 2) improvement of OS to resolute OS bottleneck. 3) introduction of 3 Tier Architecture to ISP system and adoption of load balancing mechanism. 4) improvement of access speed to Mail Box file system. Keywords: parallel processing, mission critical, system model, ISP, OMCS. 1. はじめに. システムモデルの元となった事例はいずれも当時世界最先端のシステムであった．超高信頼性モデルは地銀向けバン. OMCS（Open Mission Critical System）とは，オープン. キングシステム（事例：八千代銀行勘定系ほか）に代表さ. 製品やオープン技術を駆使して構築された大規模基幹シス. れるシステムで，文献 [3] に詳しい．また，大規模 SPF *1 モ. テムと，それらを構築するための製品群および SI（System. デルの PSA *2 システムモデルは，通信事業者の加入者料. Integration）技術の方法論の総称である [1]．OMCS で構. 金計算をリアルタイム化するために開発された技術で，巨. 築されたシステムのうち，重要なものはモデル化され，シ. 大なビリングシステムの構築に貢献した（事例：NTT ド. ステムモデルと呼ばれている．システムモデルについては. コモの MoBills ほか）．PSA システムモデルについては文. 文献 [2] に詳しい．. 献 [4] に詳しい．本論文は，大規模 SPF モデルの超並列シ. 図 1 に代表的 OMCS システムモデルの変遷を示す．各 1. 2 a). ステムモデルについて述べるものである．. 1990 年代，PC とインターネットの普及により，ネット国際社会経済研究所 Institute for International Socio-Economic Studies, Minato, Tokyo 108–0073, Japan 日本電気株式会社 NEC Corporation, Minato, Tokyo 108–8001, Japan [email protected]. c 2013 Information Processing Society of Japan . ワークを介した情報の共有や検索が一般化したが，その後，携帯電話からのインターネット接続が普及することで，そ *1 *2. Service PlatForm Parallel Stream Architecture. 21.

(2) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). 図 1 代表的 OMCS システムモデルの変遷. Fig. 1 Typical OMCS system model.. の利用者数は飛躍的に伸張し，さらにここ数年のスマー. の接続会員数は，約 500 万人（コンテンツ会員*3 を合わせ. トフォン急増により，従来の参照系主体の処理に加え，商. て 684 万人）となっていた．接続会員の大幅な増加は見込. 品購買にともなう決済処理や口座間の資金移動等，高い. むことができず，パソコン向け ISP はコンテンツの販売を. サービス品質が必要とされる処理が増加傾向にあり，コン. 主力ビジネスとすべく，経営方針を変更しつつある時代で. シューマ向けのサービスを提供するシステムには，従来以. あった．. 上の高性能，高拡張性，高信頼性が求められようになってきている．. NEC では 1990 年代から他社に先駆けて，オープン製品. 一方，携帯電話によるインターネット接続サービスは，. 1999 年にサービス開始された NTT ドコモの i モードのヒット，ならびにキャリア各社の追随により，2003 年の総. やオープン技術を駆使した大規模基幹システムの構築技術. 務省による調査で，利用者 4,482 万人（全キャリアの総数）. の開発に着手し，多様なプロジェクトの実践を通し SI 技術. と急速かつ爆発的な発展をとげた．. を確立してきた．その成果の代表事例は，NTT ドコモの i. パソコン向け ISP と異なり，携帯電話向け ISP はキャリ. モードシステムである．このシステムに大きな障害が発生. アが独占する形態をとっているがゆえに，特に NTT ドコ. した場合の社会的インパクトは容易に想像できるだろう．. モにおける爆発的なユーザの増加は，サービス開始当初採. こういった大規模基幹システムを安全かつ確実に構築する. 用されていたシステムの許容量を超えることが予想され，. ことを支えたのが，OMCS の SI 技術であり，今後ますま. 早急な対応が求められた．新システムの稼動時期を 2003. す多様化するコンシューマ向けサービスを提供するシステ. 年 4 月と目標設定し，2000 年より真の携帯電話向け ISP. ムの構築に必須の技術である．特に参考文献 [2] にある，. の構築の検討が開始されたのである [6], [7], [8]．NEC は. システム要件の分析から始まり，システムをいくつかの部. 2001 年より検討に参加することとなった．. 品（ユニット）に分割してシステムを構築する手法（システムモデルによる構築手法）は重要である．. 3. ISP の基本的な処理動作図 2 は，ISP の基本的な処理動作を示したものである．. 本論文では i モードシステムに代表される大規模 ISP （Internet Service Provider）システム構築の技術的工夫に. 1 は，ポータル画面出力に代表される自 ISP シ図 2 の. ついてと，それにより確立された大規模 SPF モデルの超. 2 は，インターステム内で完結する折り返し処理である．. 並列システムモデルについて述べる．. 2. 背景. ネット上の WEB サイトへのゲートウェイ処理である．他の WEB サイトからの応答が入力元の端末に返却される．この処理は，携帯電話向けの ISP として特徴的な動作であ. 平成 15 年（2003 年）の総務省の調査 [5] では，パソコン. 3 ， 4 はメールの処理である．ある宛先に向けて発信る．. からのインターネット利用者は，6,164 万人，携帯電話か. されたメールを，該当宛先のメールボックスに格納する処. らの利用者は 4,484 万人となっている．当時パソコン向け. 3 ）と，メールボックスに格納されたメールを取り出理（. の ISP はすでに 20 社あまり存在し，互いに会員数を奪い. 4 ）である．して受け取り先に届ける処理（. 合っていたため，たとえば，2001 年 3 月時点の BIGLOBE. c 2013 Information Processing Society of Japan . *3. 接続は他の ISP を利用し，コンテンツの購入のみに BIGLOBE を利用する会員．. 22.

(3) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). 図 2 ISP の基本的な処理動作イメージ. Fig. 2 Typical behavior of ISP.. 4. 求められたシステム要件. これらの諸条件に，具体的目標*6 [8] を加えると，以下のようになる．. 携帯電話向けの ISP の特徴として以下がある．. • 4,700 万の利用者に対して，サービスを提供できること. • バンキングシステム等の一般のオンライン処理. • 高負荷時，75,000 件/秒の処理ができること. （OLTP *4 ）に比べ，処理が軽い．代表的処理は，ポー. • 利用者の増加に対して，システムを停止することなく，. タル画面の出力，他のシステムへのゲートウェイ，メールの送受信が中心であり，処理自体は軽いと考えてよい．. • 利用者数（端末数）が極端に多い. 対応可能であること. • アクセスの集中に対応できること. 5. 基本的なアーキテクチャ. 多くの ISP 業者が事業展開を行っているパソコン向け. このような大規模システムを実現するときの基本的な考. ISP の場合に比べ，携帯電話の場合にはキャリアによ. え方は，複数のサーバを利用した分散システムを構築す. り独占されており，1 つの ISP が処理すべき利用者数. ることであり，その基本的なアイディアは 3 層アーキテ. （端末数）はパソコン向け ISP の 10 倍，バンキングシ. クチャ（3 Tier Architecture）[9] である．3 層アーキテク. ステムの 10,000 倍*5 以上になっている．. • 利用者増加のスピードが速い. チャがクライアントサーバ型の処理を，プレゼンテーション，アプリケーションロジック，DB アクセス（管理）の. 携帯電話の価格の安さから，いったん，普及に拍車が. 3 つの層に分解することにより，自由度の高いシステム構. かかると，利用者数の増加のスピードは，パソコンに. 築を可能にしたことと同様に，ISP のシステムの内部を以. 比べてはるかに速い．このため，拡張性の富んだシス. 下の 3 つの機能層に分解することとした．. テムが求められる．. • 端末制御：端末からの要求を受け取り，後段の処理へ. • アクセスが集中する傾向が強い. 回す機能. 常時携帯するコミュニケーションツールの常として，. • メール処理：メール処理を行う機能. 緊急時や正月等のイベント時にアクセスが集中する傾. • メールボックス：メールの格納を行う機能. 向が顕著であり，利用者数が多いこととあいまって，. 図 3 は，そのイメージである．. システムに与える影響は大きい．アクセスの集中に対. メールボックス層を構成するサーバは，メールの格納・. する対策が必要である．. • 高いミッションクリティカル性が求められる. 取り出しに専念させる．個々のサーバは決められた利用者向けのメールボックスを管理する．. 障害の発生によるサービスの中断や停止が社会に与え. メール処理層を構成するサーバは，メール処理自体に専. る影響は大きく，24 時間，365 日の安定稼動が必要で. 念させる．個々のサーバはメールボックス層を構成するす. あり，計画停止も認められない．. べてのサーバにアクセス可能とし，誰宛てのメールでも処. • 商用システムとして，妥当な投資でシステム構築でき. 理できる構造とする．. ること *4 *5. OnLine Transaction Processing バンキングシステムの場合には，店舗数 × 店舗あたりの端末数で決まるため，多くて数千台のレベルであり，5,000 台以下である．. c 2013 Information Processing Society of Japan . 端末制御層を構成するサーバ群は，自システム内での折 *6. ここでは NTT ドコモの i モードシステムの目標値を提示することとした．. 23.

(4) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). 6. 具体的課題とそれに対する対策 6.1 サーバの並行動作性の向上：10000 スレッド/サーバの実現本論文で述べる大規模システムを商用システムとして妥当な投資での実現することを考えると，利用するサーバの数を少なくすることがきわめて重要である．従来のバンキングシステムやパソコン向けの ISP システムでは，おおむね 3,000 件/秒の処理が最高であり，75,000 件/秒という，その 20 倍以上の処理を実現するために，20 倍の数のサーバを用意することは現実的ではない．このため，サーバあたりの処理量を高めることを目指した．従来のバンキングシステムは，プロセス指向のシステムといってよい．多くの異なる業務処理が行われることから，業務どうしがお互いに干渉しあわないように，メモリ空間がそれぞれ保護されているプロセスを利用することが図 3 3 つの機能への分割イメージ. Fig. 3 Split image to 3 Tier function.. 通常である．一方，ISP システムの場合には，動作するアプリケーションの種類が限られており，処理自身が軽いのでアプリケー. り返し，ならびに，後段のメール処理層を構成するサーバ. ションの品質自体を高めることも比較的容易であることか. 群へのゲートウェイ，インターネット上の WEB サイトへ. ら，メモリ空間が保護されていることの利点よりもメモリ. のゲートウェイを実行する．. 空間自身を節約できる利点を優先して，スレッドを利用す. このようなアーキテクチャを基本として，以下のような大きな課題をクリアしなければならならない．. • 各層を構成するサーバの並行動作性を向上させ，かつ CPU を使いきれるようにしなければならない．. る並列処理が採用されるケースが多い．いずれの方式も，数百件/秒の処理能力を実現している事例がある [10], [11] が，今回目標とする，システム性能にはほど遠い状況にある．. 商用のシステムでは，同じサーバの処理能力が 2 倍に. さらに，IPS の処理の特徴を分析してみると，大きく分. なれば，費用は半分になるといえる．本論文で述べる. けて 2 つのタイプに分けることができる．1 つは，自シス. ような巨大なシステムでは，個々のサーバの処理能力. テム内で処理が完結するタイプのもので，ポータル画面の. を限界まで引き出すことは非常に重要なことである．. 出力やメールの送受信等がそれにあたる．もう 1 つは，他. • サーバ間の負荷バランスを均一にすること. システムへの要求の送出とその応答の待ち合わせを必要と. 特に端末制御層を構成するサーバとメール処理層を構. する処理である．たとえば携帯電話から一般の WEB サイ. 成するサーバとの間で，適切な負荷バランスを図り，. トの参照が行われると，携帯電話からの要求は ISP により. メール処理層を構成する特定のサーバに負荷が集中す. 一般の WEB サイトに迂回され，一般の WEB サイトから. ることがないようにする必要がある．これは，個々の. の応答が返却されると，ISP により携帯電話にその応答が. サーバの処理能力を高めることとあいまって，急なア. 返却されるのである．これがいわゆるゲートウェイ処理で. クセス集中に対する対策にもなる．. ある．. • メールボックス処理の高速化. ゲートウェイ処理は，相手のシステムの都合により，応. メールボックス層を構成するサーバは，I/O をともな. 答時間が長くかかる可能性があるが，それは自システムで. う処理を行うので，一般的には最も遅い処理となる．. は判断できないことであり，また，そういったゲートウェ. この処理を極力軽くし，高速化することで，メール. イ処理の要求が携帯電話から行われる頻度についても，自. ボックス層を構成するサーバ群の数を減らすことを目. システムでは判断できない（つまり外部要因である）．. 指す必要がある．次章で，上記 3 点の課題について，詳しく説明する．. こういった外部要因による不確定要素に対応するために，十分な処理能力を持つことと同時に，資源を有効に使う仕組みの導入が必要であろう．そこで，パソコン向け ISP と同様にスレッド方式を採用することとし，サーバあたりの処理能力を高めるために，10000 スレッドを稼動させることに挑戦した．表 1 は，本論文で目指す ISP とそれ以前の. c 2013 Information Processing Society of Japan . 24.

(5) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). 図 4 メールの格納先としてのファイルシステムと DBMS との比較. Fig. 4 Comparison of file system and DBMS as mail box. 表 1. 代表的処理の多重度の規模感. Table 1 Scale of typical processing.. 本論文で述べる 2 番目の技術的工夫点は，適切な負荷分散を実現する方式の実現についてである．なお，個々のサーバの並列動作性を高めることとあいまって，個々のサーバへの負荷を均一にすることが，急激なアクセス集中に対する解決策の 1 つといえる．. 6.3 メールボックス処理の高速化 ISP の処理において，I/O 性能が最も影響を及ぼすのは，代表的処理との多重度の比較を示したものであり，多重度の規模は社内実績値を採用している．サーバあたり 10000 スレッドの多重度の実現は，挑戦的なものであることが理解できる．なお，単に 10000 スレッドを起動することに意味があるのではなく，きちんと稼動し，CPU を使いきれるようにすることが必要である．本論文で述べる最初の技術的工夫点は，サーバあたり. 10000 スレッドを稼動させ，CPU を使いきるための工夫点である．本論文では，このサーバを超並列ユニットと呼称することとする．. 6.2 負荷分散への工夫 3 層アーキテクチャ（3 Tier Architecture）のような分散システムでは，各層を構成するサーバ群に対して，いかに均等に負荷を分散させるかが重要な課題になる．一般に，処理の前段にいる層の個々のサーバが，処理の後段にいる層の個々のサーバに対して，均等に処理を振り分けるラウンドロビン方式が採用されることが多い．しかし，この方式は，いったん負荷バランスの乱れが発生する. メールの格納，読み出しを行うメールボックス処理である．従来，メールの格納先に DB を利用するケースが見られた．これはディスク障害やサーバの障害の際の復旧手段が，DBMS 製品ならびに関連する製品により確立されており，設計上の考慮が少なくてすむからである．一方，性能面では不利であり，メールの格納先にファイルシステム利用するケースに比べ，明らかに劣っている．図 4 はメールの格納先としてのファイルシステムと DBMS と比較である．測定環境は図 5 に示した．図 4 の左のグラクにおける，縦軸の n は，縦軸の値が相対値であることを示している．. DBMS の場合には特に大きなメールデータでの極端な性能劣化が認められる．写真の添付等により，メールデータが大きくなる傾向が高まっている現在，DBMS を利用することはあまり得策ではない．ファイルシステムは DBMS に比べ，性能的に優れているが，ファイルシステムを利用した場合でも，サーバあたり 200 件程度が限界であることが分かる．また，文献 [11] にあるようにファイルシステム，マルチスレッドを採用した DEEPMail エンジンでの. と，それが助長される傾向にある．これは前段の層の個々のサーバが個々の判断で後段にあるサーバを選択している. *9. ために発生する問題であり，振り分けの方式（ラウンドロビン*8 ，重み付け方式*9 ，サーバレスポンス方式*10 ）に依存するものではない．この問題を解決するために，後段のサーバの負荷を 1 カ所で管理する方式を採用し，実現した． *7 *8. NEC の汎用メインフレーム ACOS-4 の実績．ラウンドロビン方式では，後段のサーバの負荷状態の判断が行われないので，いったん負荷のバランスが崩れると，負荷の高いシステムに対しても均一にデータを投入しようとすることになり，負荷バランスの乱れが助長される傾向にある．. c 2013 Information Processing Society of Japan . *10. 負荷分散対象の各サーバの処理能力に応じて，ウェイト値を設定することで負荷分散を行う方式．一般的には処理性能が違うサーバが存在する際，処理性能が高いサーバにはトラフィックを多く流し，処理性能が低いサーバにはトラフィックを制限した形で負荷分散する．大規模 ISP では同じタイプのサーバを利用するので，この方式による利点はなく，ラウンドロビン方式と同じ問題が発生する．サーバからのレスポンス時間（応答速度）が最も短いサーバへリクエストが送信する方式．一般的には各サーバの性能にばらつきがある場合に採用される．同一のサーバ構成で多量の処理を行うとき，応答時間はほぼ変わらない状態になることが予想され，結果，ラウンドロビンと変わらなくなる．. 25.

(6) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). 図 5 メールボックス処理の性能測定環境. Fig. 5 Performance test configuration for mail box.. サーバ（HP Blade Server BL20P）あたりの性能は 200∼. 300 件/秒である．この限界性能を 10 倍に引き上げるために，メモリキャッ. 表 2. 超並列処理ミドルウェア実装後の性能測定結果. Table 2 Performance measurement result on the ultra parallel middleware.. シュの利用をはじめとする対策を実施した．本論文で述べる 3 番目の技術的工夫点は，このメールボックス処理の実現である．. 7. 具体的対策の詳細. 数を削減する機能．. • アプリケーションがログ情報を書き出そうとするときに，そのログ情報を共有メモリ上にスタックして，後. 以下，6 章で述べた課題に対する対策を具体的に詳細に説明する．. 7.1 サーバの並行動作性の向上：10000 スレッド/サーバの実現. 刻，一括して書き出す機能．また，ISP のゲートウェイ処理では必ず発生する他システムからの応答待ち合わせの際に，資源を占有したままにしないように，以下の機能をミドルウェアに付加した．. • ゲートウェイ処理のために，長時間スレッドが占有さ. 6.1 節で説明したような不確定な外部要因に対応するた. れる場合に備え，一定の時間がたったら，該当スレッ. めには十分な余裕を持ったシステム構築が必要であると. ドの制御情報を退避し，該当スレッドを開放して他の. 考え，10000 スレッド/サーバを目指し，かつ CPU を使い. 処理にスレッドを活用し，応答が返却されたときに，. きることを目指すこととしたが，その実現にあたっては，. 退避したスレッドの制御情報を復旧して，処理を継続. オーバヘッドを極力少なくするために，通信 I/O，ディスク I/O 以外の OS のシステムコールを削減することが重要. させる機能．これらの機能を持ったミドルウェアを，超並列処理ミド. であると考え，以下のような機能を持つミドルウェアを開. ルウェアと呼ぶこととする．. 発した．. 7.1.1 超並列処理ミドルウェアによる対応の限界. • スレッドの生成・消滅に関する OS のオーバヘッドを. 10000 スレッドの環境下で，超並列処理ミドルウェアの. 削減するために，スレッドをあらかじめ生成し，プー. 性能評価を行った．その結果が表 2 である．測定環境は，. ル管理を行い，必要なときに，プールから取り出して. 以下のとおりである（図 6）．. スレッドを割り当てる機能．. • アプリケーションが各種用途に使用するメモリ領域を動的に確保する際の OS のオーバヘッドを削減するた. • 端末からのデータを，インターネット上の WEB サーバないし，後段のメール処理に中継するゲートウェイ処理を対象とする性能測定．. めに，あらかじめ作成しておいたメモリ領域を適当な. • 性能測定対象のサーバの前段に，端末からの電文送出. サイズに切り出してプール化し，アプリケーションの. をシミュレートするサーバ（負荷ジェネレータ群）を. 要求に応じて，プールから取り出して割り当てる機能．. 用意し，電文をランダム発生させる．. • スレッド間の通信を行う際，パイプ処理のような OS の. • 性能測定対象のサーバの次段にはインターネット WEB. 機能を利用した場合には，メモリ上のデータのコピー. サーバ，ないし，メールサーバをシミュレートする. が行われるが，そのコピーの回数を削減するために，. サーバを用意し，目標応答時間分の WAIT をさせて，. あらかじめプロセスをまたがって共有可能なメモリ領. 正しい応答電文を返却するようにする．. 域を適当なサイズに切り出してプール化し，スレッド. 表 2 に示すように，オーバヘッド削減を目指した超並. 間でその領域を受け渡すことで，データのコピーの回. 列処理ミドルウェアのみでは，10000 スレッド環境下で，. c 2013 Information Processing Society of Japan . 26.

(7) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). 図 6 マルチスレッドの性能測定環境. Fig. 6 Performance test configuration for multi thread.. CPU を使いきることができず，性能が 2,700 件/秒以上には上がらなかった．この原因を分析した結果，OS 内部の処理ネックのために性能が上がらないことが判明した．この問題の解決のためには HP 社の OS の改造をともなっており，ここで詳細に述べることはできないが，代表的 2 つの事例につき，以下に概略を説明する．. 7.1.2 mutex ロックの改善スレッド間の共有資源の確保時やシステム内一意のカウンタのカウントアップ等，極短い期間の排他制御のために，最も適しているのは mutex ロックである．なぜなら，. 図 7. mutex はユーザ空間上にある数バイトのデータを Test and. mutex ロック改善効果. Fig. 7 Improvement effect of mutex lock.. Set 等の HW 命令を使って操作するだけなので，排他資源の競合が少ないときは非常に少ない CPU 時間（マイクロ秒以下）でロック・アンロックが可能であるのがその理由である．しかし，アンロック待ちのスレッドが多くなると，いくつかのスレッドは sleep 状態に遷移する．その結果，ロックの FIFO を守ろうとする限り，sleep 状態のスレッドを. wake-up させてロックを渡すことが必要になる．この間ロックが保持されたままとなるので，ロック区間が長くなり，全体のスループットを落としてしまう．そこで，FIFO の原則を守らず，早い者勝ちでロックをとらせるオプション機能を用意することにした．これが，mutex ロックの改善の一部である．. 図 8 ソケット以下の TCP/IP 関連資源のキャッシュ化の効果. Fig. 8 Improvement effect of Cache of TCL/IP socket.. こういった改善を行った結果，mutex ロックの処理性能を改善前に比べ 10 倍に向上させることに成功した．図 7. るソケット以下の TCP/IP 関連資源を，OS 内部でキャッ. は，その改善効果を示したものである．. シュ化（プール化）し，生成・削減のオーバヘッドを削減. 図 7 中の n，m は，縦軸，横軸の値が相対値であること. するオプション機能を用意することとした．. を示している．測定環境は NX7000/N4000，8CPU，OS は. 結果，改善前に比べ，処理件数は 1.3 倍に改善された．. HP-UX11i である．1 個の mutex にロック，アンロック操. 図 8 は，その改善効果を示したものである．図 8 中の N，. 作を繰り返す複数スレッドの並列走行結果を示している．. m は，縦軸，横軸の値が相対値であることを示している．. 7.1.3 TCP/IP のソケットプールの実現. 測定環境は NX7000/N4000，8CPU，OS は HP-UX11i. ISP の場合比較的処理が軽いので，処理のつど発生する. である．スレッド数の変化に依存せず，処理量が改善し. TCP/IP の接続/切断の OS オーバヘッドが性能の足かせに. ていると同時に，CPU 使用率も改善されていることが分. なることが判明した．そこで，OS の内部で生成・削除され. かる．. c 2013 Information Processing Society of Japan . 27.

(8) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). 表 3 OS 改造後の性能測定結果. Table 3 Performance measurement result after OS improvement.. サーバに負荷が集中してしまうことが発生する．これを解決する手段としては，均等性を判断する箇所を. 1 つにする，つまり，端末制御ユニットを構成する個々のサーバからの要求をいったんすべて受け止め，均一性を保つように振り分けを行う役割を専門的に果たすものを用意することである．また均一性を保つための判断基準はいくつか方式が考え. 7.1.4 改善の効果. られる [12] *11 が，個々の要求のサイズがほぼ一定である. 前述のような OS の改善を行った結果，表 3 のような. ISP の場合には，Least Connection 方式，つまり「処理中. 処理性能を達成することができた．測定環境については，. の要求の数が最も少ないサーバを優先して処理を要求する」. 7.1.1 項で述べたものと同じである．. 方式が有効である．ただし，処理中の要求の数が最も少な. 以上の改善によって，10000 スレッドを稼動させ，CPU を使いきれる環境を整備できたことになる．このように並行動作性を向上させたサーバ，OS，超並列処理ミドルウェアのセットを，超並列ユニットと呼称している．. 7.1.5 超並列ユニットの活用. いことが一元的に（1 カ所で）管理されて初めて効果を出す方式であり，端末制御ユニットを構成する個々のサーバが，個々に Least Connection 方式で判断しても，負荷が均一にならないことは明らかであろう．この方式では，すべての要求がその 1 カ所に集中することから，より高い処理能力を持った装置が必要となる．超. ISP の処理を 3 つの機能層に分解するアーキテクチャに. 並列ユニットによる実現も考えられるが，よりオーバヘッ. ついて，5 章で述べたが，それぞれの層を構成するサーバ. ドが少なく，回線スピードで処理可能な L4 スイッチ*12 で. を超並列ユニットで作成し，それぞれの層を構成するサー. 実現することを目指した．. バの並列動作性を確保することとした．すなわち，. • 端末制御については，端末制御を実現するアプリケー. しかし，現実的には，対応可能な L4 スイッチは存在せず，既存の L4 スイッチに以下のような製品強化を行うこ. ションの実行基盤として，超並列ユニットを利用する. とで，実現している．これは，Foundry 社（現 Brocade 社）. こととした，超並列ユニットに端末制御を行うアプリ. の製品の改造をともなっており，詳しく説明することはで. ケーションを付加したものを，端末制御ユニットと呼. きないが，概略は以下のとおりである．. 称することにする．. • UDP にセッションの概念を導入. • メール処理については，メール処理を実現するアプリ. 一般に，TCP/IP の通信に比べ，UDP/IP はオーバ. ケーションの実行基盤として超並列ユニットを利用す. ヘッドが低いことが知られている．そのため，各ユ. ることとし，超並列ユニットにメール処理を行うアプ. ニットを構成するサーバ間の通信に UDP/IP を使用. リケーションを付加したものを，メール処理ユニット. している部分がある．しかし，UDP/IP の場合には，. と呼称することとする．. セッションの概念がないために，Least Connection の. • メールボックスについては，超並列ユニットに，メー. 判定自体をすることができない．. ルを格納するためのファイルシステムを付加し，同時. これを解決するために，UDP/IP でも通信先と要求中. に，6.3 節で述べた課題に対応することとした．これ. のリクエストの数を管理して，Least Connection 方式. らをまとめてメールボックスユニットと呼称すること. を実現できるように製品の改造を行った．. にする．. • L4 スイッチ内のカレントコネクション情報の鮮度（新しさ）向上. このように，ISP の処理を，超並列ユニット，端末制御ユニット，メール処理ユニット，メールボックスユニット. 一般に高速な L4 スイッチの場合，内部に複数の CPU. に機能分割して構築する考え方が，システムモデルにおけ. を搭載して処理を行っている．個々の CPU が独立に. るマルチユニットアーキテクチャの考え方である．システ. コネクションの数を管理していると，負荷が均等にな. ムモデル，ならびに，マルチユニットアーキテクチャにつ. らない．また，要求に対する応答時間が短いケースで. いては，文献 [2] に詳しい．. *11. 7.2 負荷分散への工夫（L4 スイッチによる Least Connection 方式の実現） 6.2 節で述べたように，端末制御ユニットを構成するサーバが個々の判断（ラウンドロビン等）でメール処理ユニットを構成するサーバに負荷分散を試みると，ある特定の. c 2013 Information Processing Society of Japan . *12. 負荷分散の方式の研究として文献 [12] にはリクエストファイルサイズを利用して各サーバの負荷を均等にする方式が提案されているが，本論文が対象とする携帯端末向けの ISP では各リクエストのサイズに大きな差はないので，サーバあたりのコネクション数をベースに負荷分散する方式を採用している． L3 スイッチが IP ヘッダまでの解析を行うのに対し，L4 スイッチは TCP ヘッダ等のプロトコルヘッダ内の情報を解析したり，書き換えを行ったりすることでトラフィックの分散や最適化を行うことを目指した装置のこと．. 28.

(9) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). 図 9 ロードバランスユニットによる負荷分散. Fig. 9 Load balancing by Load-Balancing-Unit.. は，つどコネクション数を正確にカウントして，正しいカウントに基づいて負荷分散を行わなければ負荷が均等にならない．このために，コネクションの数のカウントアップ，カウントダウンのタイミングを正確にし（コネクション情報の鮮度の向上），かつ，複数の CPU 間での共有を. 図 10 ロードバランスユニットのスロースタート方式. 可能とするよう，製品の改造を行った．. Fig. 10 Slow start mode of Load-Balancing-Unit.. 以上のような負荷分散機能を有する L4 スイッチのことを，ロードバランスユニットと呼称することにする．図 9 はロードバランスユニットによる負荷分散の結果を示したものである．. スロースタート方式を採用している．これは Foundry 社（現 Brocade 社）の製品の機能で実現されている．図 10 はスロースタート方式のイメージを示したものである．新. 測定環境は，L4 スイッチは SS8000/250，サーバは. しくサーバが処理に参加してきたとき，一定時間が経過す. NX7000/N4000 8CPU，OS は HP-UX11i．2 台のサーバへ. るまでは，該当サーバへの負荷を抑え，一定の時間が経過. の負荷分散結果の一例であり，6,000 件/秒，8,000 件/秒，. した後に，他のサーバと同様に負荷をかける方式である．. 8,800 件/秒の入力トランザクションを 2 台のサーバでほぼ均等に処理できていることを示している．なお，9 章でも述べるが，実際の適用システムでは，前段のサーバ 64 台，後段のサーバ 6 台の環境で，均等に負荷分散を実現できている．. 7.2.1 Least Connection 方式の欠点の克服 Least Connection 方式により，負荷分散が図れることは. スロースタート方式は，障害が発生したサーバの復旧時だけでなく，負荷の増加に対するサーバ追加の際にも有効であることはいうまでもない．スロースタート方式の実装例について具体的に補足説明する*13 ．「新しいサーバが処理に加わったときに，一定時間 t ごとに，定常時の n%の負荷をかける」ということをあらかじめ定めておく．たとえば，10 秒ごとに，20%，40%，. 示せたが，実際のシステム運用を考えると Least Connection. 60%，80%，100%と負荷を増やしてゆくというような設定. 方式には以下のような欠点がある．. を行い，その設定に従って負荷分散を行うことになる．. 一般に，複数のサーバによる分散処理を実現する場合には，あるサーバが障害になったときに残りのサーバで処理を継続し，障害になったサーバを復旧させ改めて処理に参. 7.3 メールボックス処理の高速化メールボックスユニットは超並列ユニットを実行基盤と. 加させる方式をとる．この場合，障害から復旧した直後の. して採用していることは 7.1.5 項ですでに述べた．これに. サーバへの要求数は 0 であるからロードバランスユニット. より，メールボックスの書き込み，読み出し，削除の各処. は，障害が復旧したサーバに集中的に負荷をかけてしまう．. 理の並列実行性は，十分に確保できている．. 一般にサーバの起動時には，初期化を含む各種の処理が動作しており，その時点で極端に負荷がかかることは，サーバの安定的運転にとってけっしてプラスではなく，結果，. 加えて，以下の対策を実施することにより，性能を確保した．. • ファイルディレクトリのメモリキャッシュ化. サーバの運転が不安定になることが判明した．そこでこの問題を解決するために，サーバがフル稼働可能状態になるまでの間，そのサーバへの負荷を少し控える. c 2013 Information Processing Society of Japan . メールの格納にファイルシステムを利用する場合，加 *13. Foundry 社（現 Brocade 社）の製品に組み込まれたロジックとは異なるが，考え方は同じである．. 29.

(10) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). 入者ごとにディレクトリを作成し，個々のメールデー. ムの 19 倍である．. タは加入者ごとのディレクトリ配下にファイルとして. なお，参考として表 4 に，性能測定時のプロセス/スレッ. 格納していく方式を採用するのが一般的であるが，こ. ドの数を記載した．従来の DBMS やファイルシステムで. の場合，ディレクトリファイルのサイズは，同時に格. は，100 多重での動作で DBMS やファイルシステムに限界. 納されたメール通数の最大数によって決定されてしま. があり，性能が上がらなかった（6.3 節で提示した情報）．. い，メールが格納されたファイルを削除しても，ディ. 改善後は従来のファイルシステムの 20 倍の 2000 多重で稼. レクトリファイルサイズは小さくならず，ファイル. 動し，19 倍の性能を得た．ただし，これ以上多重度を上げ. ディレクトリのメモリキャッシュ漏れが発生すること. ても，測定環境のストレージの I/O 能力の限界により，性. があった．この問題を解決するために，ディレクトリ. 能が上がらなかった．. を階層構造とし，1 ディレクトリ配下のファイル数を減らすことで，ディレクトリのサイズの肥大化を抑制し，ディレクトリをキャッシュに載りやすくする工夫を行った．. • ファイルシステムのブロックサイズのチューニング. 8. システムモデルとしてのまとめ以上のような検討と改善により，以下のようなユニットからなるシステムモデルが確立した．. • 超並列ユニット. モバイル端末でのメールのサイズが小さいことに着目. サーバあたり 10000 スレッドの稼動を可能とし，同時. し，通常 4∼8 K バイトのファイルシステムのブロッ. に，CPU を使いきれるように改善を行ったサーバ．. クサイズを小さい値（2 K バイト）に変更することで，. I/O 量の削減，メモリキャッシュサイズの削減を図っている．さらに，以下の観点で OS を改造することで，性能を確保している．これは HP 社の製品（OS）の改造をともなう. • 端末制御ユニット端末からの電文を処理し，後段のインターネット上の. WEB サーバやメール処理を行うメールユニットに処理を中継するサーバ．超並列ユニット上に構築される．. • メール処理ユニット. もので，詳細に説明することは難しいが，概略は以下のと. メール処理を行うサーバ．超並列ユニット上に構築さ. おりである．. れる．. • OS のディレクトリ内の排他制御の改善 OS のディレクトリ操作内で使っている排他制御の機構をオーバヘッドの低い方式に変更する等の改善を行っている．. • OS の Sync デーモンの起動間隔の変更 Sync デーモンは，メモリキャッシュ上の更新データを. • メールボックスユニットメールが格納されるサーバ．超並列ユニット上に構築される．. • ロードバランスユニット均一な負荷分散を実現する L4 スイッチ．図 11 は，これらのユニットの関係を示したものである．. ディスク上に反映する処理を行うものである．Sync. これらのユニットから構成されるシステムモデルを超並列. デーモンは 30 秒ごとに動作するのが規定値であるが，. システムモデルと呼ぶ．. 高いトランザクション負荷の場合，30 秒の間に大量の. 端末制御ユニット，メール処理ユニット，メールボック. 更新データが蓄積され Sync デーモンの動作時の処理. スユニットを構成するサーバは超並列ユニットを利用して. が重くなり，トランザクション処理に影響が出る可能. おり，10000 スレッドが動作可能な環境を継承している．. 性がある．そこで Sync デーモンの起動間隔を 5 秒に. またこれらのサーバは負荷に応じて複数用意することが可. 変更し，メモリキャッシュ上の更新データをディスク. 能で，負荷の増加や加入者の増加に対して，柔軟に対応で. 上に反映する処理の平準化を行っている．. きる．このように，ISP の処理を，超並列ユニット，端末制. 以上 4 点の対策を行うことにより，大幅な性能改善を実. 御ユニット，メール処理ユニット，メールボックスユニッ. 現した．表 4 は，メールボックス処理の性能向上結果を示. ト，ロードバランスユニットに機能分割して構築する考え. したものである．測定環境は，6.3 節で述べた環境と同様. 方が，システムモデルにおけるマルチユニットアーキテク. であり，メールデータが 2 K バイトのケースでの処理件数である．改善効果は DBMS の 25 倍，従来ファイルシステ表 4 メールボックスサーバの処理件数. Table 4 Performance measurement result of mail box server.. 図 11 超並列システムモデル. Fig. 11 Ultra-Parallel System Model.. c 2013 Information Processing Society of Japan . 30.

(11) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). i モードシステム*14 である．このシステムで提供される i モードサービスは，加入者 4,568 万人（2006 年 1 月 1 日時点）が「世界最大のワイヤレスインターネットプロバイダ」として認められ，2006 年 3 月に NTT ドコモがギネス認定を受けている [13]．2006 年 1 月 1 日時点の処理能力は．メール送受信 25,000 通/秒，Web アクセス 50,000 PV/秒の処理能力であった [6], [8]．これらの実績により，本論文での目標値が達成できていることが分かる．なお，i モードシステムの一部分であるが，ロードバラ図 12 超並列処理ミドルウェアと L4 スイッチによる負荷分散. Fig. 12 Load balancing by Ultra-Parallel Middleware and L4 switch.. ンスユニットに関する実績データとしては，以下のようなものがある．. • 前段のサーバ台数 64 台，後段のサーバ台数 6 台，L4 スイッチの処理量 4 万件/秒．実システムでの実績値. チャの考え方である．システムモデル，ならびに，マルチ. ゆえ，詳細に公開することはできないが，後段の 6 台. ユニットアーキテクチャについては，文献 [2] に詳しい．. のサーバには，均等に負荷分散が実現されている．な. ロードバランスユニットは，L4 スイッチで実現される. お，ロードバランスユニットの能力は，まだ許容範囲. ため，高速な処理が可能であるが，万一，L4 スイッチが性. 内であり，8 章で述べた，超並列処理ミドルウェアと. 能ネックになる場合には，以下の 2 つの方法によって拡張. L4 スイッチを組み合わせた負荷バランスは，採用されていない．. 性を確保する．. • より高速な L4 スイッチに置換する. 超並列ユニットとして確立された技術は，PSA *15 の基. HW の高速化は年々行われており，より高速な L4 ス. 盤となっている．PSA とは，携帯電話の課金情報やスマー. イッチへの交換が性能ネック解消の最も単純な対策で. トメータから発生する電力消費情報等，大量に発生する情. ある．. 報を効率的に処理するための手法で，多くのスレッドを並. • 超並列ユニットを構成する超並列処理ミドルウェア. 行稼動させることで実現している．このスレッドの並行稼. （7.1 節で説明したミドルウェア）と複数の L4 スイッ. 動の実現の基盤として活用されているのが，超並列ユニッ. チを組み合わせて負荷分散を実現する. トで確立された技術である．PSA については文献 [4] に詳. 高速な HW が入手できない場合に備えて，超並列処理. しい．. ミドルウェアには，複数の L4 スイッチに対して負荷分散を行うロジックが組み込まれている．図 12 は，超並列処理ミドルウェアと複数の L4 スイッチの組合. 10. まとめ超並列ユニットを確立させた技術と，それをベースとし. せのイメージである．. た超並列システムモデルの確立は，大規模 ISP 構築に大き. • 端末制御ユニットを構成するサーバは，複数の L4. く貢献した．これは，システムモデルに基づくシステム構. スイッチに接続されており，超並列処理ミドルウェ. 築の有効性を示すものと考える．この検討の過程で，一定. アが L4 スイッチ間の負荷バランスをとりながら電. 以上の負荷がかかった場合，OS の改善や L4 スイッチの改. 文を振り分ける．. 善等を行わなければ，目的を達成できなかったことは注目. • 端末制御ユニットを構成するサーバが個別に負荷. に値する．個々の改善自体は小さな改善かもしれないが，. 分散を行うので，L4 スイッチの負荷を均一にする. これらの改善がまとまって，大規模 ISP の実績という成果. ことは必ずしもできないが，後段のメール処理ユ. に結び付いた．これこそが，実際のモデルに基づいたエン. ニットを構成するサーバへの負荷は均等化できる. ジニアリングの成果であると考える．. ので，当初の目的は達しているといえる．. 今後のスマートフォンの普及は，ISP システムへの負荷. このように，超並列システムモデルは，大量高速処理と. を高めることになると考えられる．特に，スマートフォン. 拡張性を有し，まさに巨大 ISP の構築に適したシステムモ. は ISP システムとの間で TCP/IP コネクションを張って. デルである．本論文で述べた各種の検討や改善は，このシ. いる時間が長く，データの交換を行っていないときでも，. ステムモデルとして集約され，具現化されたのである．. コネクションを張り続けている．こういった場合，スレッ. 9. 具体的実施例. *14. 本論文で述べた検討や改善が集約された超並列システムモデルの適用事例として代表的なものは，NTT ドコモの. c 2013 Information Processing Society of Japan . *15. KDDI や Softbank モバイルのシステムについては，詳細な情報は公開されておらず，いかなるシステム構成をとっているか不明である [7]． Parallel Stream Architecture. 31.

(12) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). ドも占有されることが多いが，本論文の 7.1 節で説明した超並列処理ミドルウェアは応答待ちのスレッドをプールに. [15]. 戻し，再利用する機能を持っており，スレッドの枯渇を防. [16]. ぐことが期待できる．また，今後は M to M と呼ばれる，たとえば多量に配置されたセンサ等から集められる多量なデータの集計処理が必要になると考えられるが，これらについても本論文で確立したシステムモデルは有効と考えている．謝辞超並列システムモデルの実現にあたっては，製品そのものへの改造も必要となり，OS については HP 社に，. [17]. 例，ProVISION, No.39 (Fall 2003). 武知保秀：Linux を活用した BIGLOBE メールサーバ， NEC 技報，Vol.54, No.12 (2001). NTT ドコモの新規 i モードゲートウェアシステム “CiRCUS” 構築完了，NEC プレスリリース (2003 年 4 月 28 日). 相澤正俊，上窪真一，小河原孝一：OMCS 構築のプロジェクト管理における見える化，情報処理学会 CDS，Vol.2, No.2, pp.29–39 (July 2012).. 商標について OMCS，PSA は NEC の日本国内における登録商標です．. L4 スイッチについては Foundry 社（現 Brocade 社）に全. BIGLOBE は NEC ビッグローブ株式会社の登録商標です．. 面的に協力をいただいた．さらにアーキテクチャの検討に. i モードは株式会社 NTT ドコモの登録商標です．CiR-. おいては，社内の PC 向け ISP である BIGLOBE の関係. CUS は株式会社 NTT ドコモの i モードサービスのシステ. 各位にいろいろとご教示いただいた．最後に，超超並列シ. ム名称です．. ステムモデルを実際構築する機会をいただいた NTT ドコ. HP-UX は米国における米国 Hewlett-Packard Company. モ様，ならびにシステム構築の共同パートナの NTT デー. の登録商標です．Oracle は Oracle Corporation およびそ. タ様にも様々なご意見，ご教示をいただいた．皆様に深く. の関連企業の登録商標です．その他の名称は，それぞれの. 感謝申し上げる．. 所有者の商標または登録商標です．. 参考文献 [1] [2]. [3]. [4]. [5] [6] [7] [8]. [9] [10]. [11]. [12]. [13] [14]. 相澤正俊，東健二，川浦立志：OMCS 構築技術の研究，情報処理学会 CDS 研究会，CDS3-11 (2012). 相澤正俊，東健二：OMCS のシステムモデルによるプラットフォーム構築，情報処理学会 CDS, Vol.2, No.3, pp.1–15 (2012). 相澤正俊，富山卓二，斎川幸貴，川浦立志：オープンバンキングシステムを実現した OMCS の超高信頼性システムモデル，情報処理学会 DICOMO2012, pp.1329–1340 (2012). 相澤正俊，富山卓二，斎川幸貴：メモリ DB を活用したスーパー OLTP を実現する OMCS の PSA システムモデル，情報処理学会 CDS，Vol.2, No.2, pp.40–53 (2012). 総務省：インターネット接続サービスの利用者数等の推移（速報）平成 14 年 12 月 27 日．【平成 14 年 11 月末現在】伝説の「i モード」プロジェクトに見る落ちない基盤の作り方，日経コンピュータ (2007.7.23). NTT ドコモ vs. KDDI vs. ソフトバンクモバイル「落ちない」メール，実装は三様，日経コンピュータ (2007.10.1). i モードサービスを提供するミッションクリティカルサーバシステム「CiRCUS」，日経ビジネスコミュニケーション 2007, Vol.44, No.2 (2007). Wikipedia, Multitier architecture, available from http://en.wikipedia.org/wiki/Multitier architecture. 平野敬幸，安室秀則：BANCS 接続システム（3）オンライン処理に要求される信頼性・パフォーマンスの実現， UNISYS TECHNOLOGY REVIEW, No.75 (Nov. 2002). DEEPSoft, DEEP Mail（カスタマイズ可能な大規模メールシステム）での性能，入手先 http://www.deepsoft.co.jp/products/DEEPMail/ deepmail01.html. 佐竹伸介，稲井寛：Web サーバクラスタにおけるリクエストファイルサイズを利用したサーバ負荷推定に関する検討，信学技報，IEICE Technical Report, NS2005-154, 電子情報通信学会 (2006. 1). i モードコンテンツの市場規模，NTT ドコモレポート， No.51 (2006.11.30). 室住正晴：CICS-UDB 高性能基幹 OLTP システム構築事. 相澤正俊（正会員） 1971 年東北大学大学院工学研究科電気通信工学専攻修士課程を修了し，. 1972 年日本電気株式会社に入社．主に基本ソフト（OS）開発と IT ソリューション事業を担当．2008 年代表取締役執行役員副社長に就任，2011 年より株式会社国際社会経済研究所（NEC グループ会社）理事長に就任．2012 年より同社顧問．. 東健二（正会員） 1985 年関西大学大学院工学研究科電子工学特論博士課程前期修了し，同年日本電気株式会社に入社．OSI 通信系ソフト開発や UNIX 系 OS 開発を担当後，オープン系大規模分散システム開発に従事．2010 年 OMCS 事業本部長に就任．. 大藤豊喜（正会員） 1968 年高知工業高校卒業．同年 4 月日本電気株式会社に入社．日本電気にて各種の OS，ミドルウェアの設計・開発，大規模システムのインフラのアーキテクチャ設計・構築等に従事．. c 2013 Information Processing Society of Japan . 32.

(13) 情報処理学会論文誌. コンシューマ・デバイス & システム. Vol.3 No.1 21–33 (Mar. 2013). 川浦立志（正会員） 1983 年東北大学大学院理学研究科数学専攻修士課程を修了し，日本電気株式会社に入社．主にメインフレーム，ストレージの基本ソフト開発と組込みソフト事業を含む IT ソリューション事業を担当．. c 2013 Information Processing Society of Japan . 33.

(14)