REST指向での標準仕様設計方法について

最近の標準化ではREST指向を採用されているケースが多い。ETSI NFVもO-RANもどちらもREST指向で標準仕様を制定している。最近の標準化の世界では、SBAというのも流行している。本日は、REST指向での標準仕様設計の現場を紹介したい。

テレコム系の標準化における設計方法

標準化の一番の目的は、異なる装置間を接続するため(interoperability)の仕様を制定することであり、多種多様な装置を接続できる仕様が良い標準仕様と言われている。良い標準仕様を円滑に制定するために、テレコム系の標準化ではITUのI.130に定義されている3 Stage法を採用しているケースが多い。

  • Stage1: UsecaseやFunctional Requirementを合意する。Goalと前提条件を定義し、そのGoalに向けた手順(Procedure)を定義したり、各機能部の要求条件を記載することが多い。ETSI NFVではIFA010が該当する。
  • Stage2: Stage1のFunctional Requirementを元に、Information flow(シーケンス)や各機能部間でやり取りするキーパラメータを定義する。ETSI NFVではIFA010を除く多くのGS IFAがStage2に該当する。
  • Stage3: Stage2のキーパラメータをやり取りするためのプロトコルを定義する。ETSI NFVではSOLがStage3に該当する。
  • Stage4: 最近ETSI NFV等の団体ではテスト仕様を(非公式に)Stage4と呼んだりするようだ。Stage2やStage3をテストするためのテスト仕様を定義する。ETSI NFVではTSTがStage4に該当する。

Stage1やStage2によって様々な特徴の装置の要件を集めることになるが、一般的に”装置間を接続するための標準仕様”として実際の開発で利用する仕様はStage3が多いだろう。

何故今RESTか？

IT業界では、サービスの継続期間が短く、数日〜数カ月でサービスの入れ替わりが起きる。そのため、なるべく疎な結合(他の機能やコンポーネントに影響を与えない)により、既存の機能やコンポーネント、サービスを再利用しやすいように設計する必要がある。その中で、RESTはWebの世界では相性が良かったようだ。

過去の設計手法の歴史

  • 初期：手続き型(Ex.ALGOL,BASIC,C言語,PERL)
    • データ構造(メモリ)とルーチン(CPU)によって構成されており、コンピュータのアーキテクチャと親和性の高い開発が可能
    • モジュールとして再利用可能であるが、モジュール間の結合が密になりがち
    • 全体を理解している必要があり大規模開発を行うためには高スキルが必要
  • 1990〜2010年：オブジェクト指向(Ex.Smalltalk,Ada,JAVA,C++)
    • コンピュータの性能向上に伴い大規模なシステムが開発されコードが複雑化
    • オブジェクト(インスタンス＆メソッド)とメッセージによって構成することで、オブジェクト単位に設計＆開発を行い大規模開発が可能なアーキテクチャ
  • 2005〜年：サービス指向(Ex.SOAP,JBoss)
    • オブジェクト指向ではオブジェクト間の連携手続きが煩雑であることから、未知のオブジェクトとの連携が困難
    • インターネットの普及等によりシステム自体を再利用することで業務変化に早く追従できるアーキテクチャが求められる
    • 業務上の1処理を1つの単位(サービス)とし、オープンな技術仕様でサービスを連携させる考え方
  • 2010頃〜：リソース指向(Ex.REST)
    • サービス指向はプログラムを業務に抽象化し、オブジェクト通信で互いに疎なシステムを構築可能であるが、設計〜試験が抽象化している分各レイヤ毎での検討が必要なため複雑である
    • 汎用的な技術(URI＆HTTP)を利用しリソースとそのリソースに対する操作のみを設計することで、設計〜試験をシンプル化

テレコムでRESTが採用され始めている背景

3GPPにおいてCUPSが採用されたことで、実際のユーザの通信が流れるパス(User Plane)とそのUser Planeを構築するためのControl Planeが分離された。3GPPのサイトに記載されているとおり、User Planeはトラヒック量に依存して増えるが、Control Planeはユーザ数やテレコムサービスの種類に依存して増えるため、特性が異なる。User PlaneはよりNW機器に近くなり高速大容量が求められ、Control PlaneはよりWebサービスに近くなってきたのだろう。Conrol PlaneはRESTを適用することでNetwork Function間を疎な結合にして新サービスを導入しやすくすることを狙っているようだ。

別の側面としてよく聞く話に、テレコム系の人材が不足しているためIT系の人材を獲得しやすい環境作りが必要だと考えている人もいるようだ。そのため、なるべくIT系の技術をテレコムでも取り入れることで、IT系の人材を確保しやすいようにしているという側面もあるだろう。

RESTの設計方法

RESTでは”リソース”の設計(Information Model)に主眼がおかれ、APIはCRUD(Create/Read/Update/Delete)のみのシンプルな設計となることが重要である。

  1. Usecaseを決める (Stage1)
    • Actor, Procedureを決める
    • 各機能部/コンポーネントのFunctional requirementsを決める
    • 各機能部がAPIをcallされた時の作用(side effect)を決める
  2. 誰がどのようなリソースを持つべきか(Information model)洗い出す(Stage2)
    • 対象のデータを抽出
    • データをリソースに分解する
    • リソース間の関係性をまとめる(ER図等)
  3. リソースにURLを割り当てる(以降Stage3)
    • リソースを”名詞”と”動詞(名詞の状態を変える操作)”に分解する
    • ”名詞”の階層構造を作成する
    • リソースの内容が分かるリソース名をURLとして割り当てる
  4. リソースに対する操作(operation)を決める
    • リソースの”動詞”からCRUDを定義する
    • 各CRUDの処理概要を決める
    • CRUDで表現しきれない”動詞”をリソースとして追加する(乱用しない＆例外であることを明記)
  5. 各操作のリクエスト/レスポンスのメディアタイプを決める
    • json/xml/等を決める
  6. リソース間の連携を決める
    • リソース間のハイパーリンクを決める
    • リソースをクライアントとサーバに分割する
    • リソースを取得する手法を決める
  7. 正常系を決める
    • ステータスコードを決める
    • 応答するパラメータを決める
    • リクエストパラメータを決める
  8. 異常系を決める
    • ステータスコードを決める
    • ステータスコードとエラーハンドリングを対応付ける

テレコムではシーケンスベースで仕様を検討したくなるが、RESTはCRUDとして仕様をシンプル化することで各機能部やコンポーネントの再利用性が高くなる。一方で、あまりに柔軟性を高くし組み合わせを増やしてしまうと、当初の標準化の目的の異なる装置間の相互接続性(interoperability)が失われる。最近では、RESTより更に柔軟性を求めて標準化の世界でもSBAを指向し始めている仕様も見受けられる。interoperability vs felexibilityは標準化における永遠の課題かもしれない。



コメント

コメントを投稿

このブログの人気の投稿

CISMとは？CCMとは？NFVでコンテナ管理はどうやるの？

イメージ
ETSI-NFV仕様の各Release機能 の通り、ETSI-NFVのRelease4ではコンテナの制御が追加される。Release4は IFA039のSBA の影響でService Baseの仕様が入っており、ETSI-NFVにおけるコンテナ管理は様々なバリエーションがある。そのため、どのように各仕様を使うかを理解するのは非常に難易度が高いだろう。なお、コンテナとは何か？については こちら を参照して頂きたい。 Kubernetesによるクラウド管理 Kubernetesは、コンテナという技術と各種管理機能を使ってプログラム(APL)を抽象化し、クラウド上でAPLを制御するフレームワークとそれを支える管理機能群である。ここでのクラウドとは、APLを抽象化することでインフラの制御を含む様々な資源を共通機能化し、それらをAPIでソフトウェア的に制御できるようにしていることだが、それを仮想化とクラウドの違いから図でまとめてみた。 仮想化だけした場合(単純仮想化)は、基本的にはAPLは物理装置自体と同じ構造であり、それをインストールしたり故障時の修理をしたりする作業も物理装置と同じ手順が必要だった。しかし、せっかくAPLを仮想化によりソフトウェア化し、HWとの依存関係を無くしている(抽象化している)ので、例えば初期構築やHW故障時の対応をAPI化したい。これがIaaS(Infrastructure As A Service)と呼ばれ、サーバやNW機能の一部を管理機能(ETSI-NFVの場合はVIM)で制御できるようにしている。これにより、物理装置の変更に伴う各種作業は削減され、VMだけ考慮すればよくなった。さらに一歩進んで、LBやDBなどの共通機能をインフラの一部として提供する(PaaS)ことで、HWに依存しない新しいタイプのAPLとプラットフォームへ進化することができ、この“何か分らない雲のようなところにリクエストを出すとサービスを得られる“というものがクラウドである。 Kubernetesは、このクラウドの効果を最大化するために、APLの範囲を最小限化している。 Kubernetesの世界では、APLはDataを持たず、Logicのみをコンテナとしてカプセル化しPodという単位で管理することで、外部から容易かつ高速に起動/停止が可能となっている。そのため、APLの冗長...
続きを読む

モバイルネットワークの保守運用の基礎

イメージ
O-RANや Sliceの管理 によって、最近モバイルネットワークの保守運用が脚光を浴びるようになってきた。しかし、運用方法や保守系装置は“オペレータやベンダ毎に異なる領域“というイメージであり、なかなかまとまったドキュメントや資料が見つからない。 保守運用の基本 これまでネットワークの保守運用のデファクトや標準仕様と言えばTM Forumの eTOM 程度しか無かったと思う。eTOMや各種標準化機能やOpen Sourceを踏まえると、大きく以下のような考え方がありそうだ。 保守運用のプロセス strategy： 新サービス導入やユーザの利用状況を踏まえた設備計画 保守運用の観点から見るとfulfillmentのInput情報 fulfilment(fulfillment)：設備計画に基づいたネットワーク装置(NF)や、それらを接続するネットワーク(NW)の設計・工事 assurance：運用しているNFやサービスの監視や復旧、更新作業 4Gまでの保守運用というと、assuranceを指すことが billing：利用状況に基づいた課金 保守運用の観点から見ると運用結果のOutput 保守運用レイヤ Business Management System (BMS)： 顧客の契約情報を管理 一般的にBusiness Support System (BSS)を利用 Service Management System (SMS)： 提供サービスの管理運用 Network Management System (NMS)： (サービスを実現する)NFの接続性の管理運用 4GまでのOperation Support System (OSS)と言うとNMSのことを指すことが多かったようだ Element Management System (EMS)： NF自体の管理運用 NFのFCAPSと言えば、EMSのことを指すことが多い 一般的にネットワークの保守運用というと、EMSまたはNMSのレイヤのfulfilment＋assuranceを指すことが多いように感じる。しかしながら、システムによる実装と人手での運用という観点では、4GまではEMSのassuranceまでを実装し、残りは手作業ということも多かったようだ。規模が大きな企業では、NMSやSMSの一部を取り入れてOSSを導入し...
続きを読む

VNF Lifecycle Management (LCM)とは？

イメージ
NFVの登場によりLifecycle Management (LCM)というキーワードが頻繁に登場するようになったが、NFVの用語定義( NFV003 )を見ても”set of functions required to manage the instantiation, maintenance and termination of a VNF or NS“としか書かれておらず、なかなか意味が分からない。NFVの仕様の基本であるLCMについて解説していきたい。 LCMとは？   標準化仕様について①「基本仕様の見分け方」 でも記載した通り、NFVの仕様の基本であり、仮想化されたNetwork Function(VNF)に対してInstantiation/Healing/Scaling/Termination等の制御を行うことである。元々は IT系のLCM  Service という考え方であり、それをNFVでテレコムやモバイル系装置にも同じ概念を適用したようだ。 NFVにおいては、これらの計画・設計 〜 導入・工事 〜 運用・更新 〜 廃止・撤去をそれぞれAPI化し、 モバイルの運用 でも利用可能なように機能を拡充している。 IT系と異なる点 としては 仮想リソース(VMやVirtual Storage)の設定や設計をインフラではなく、Network FunctionのApplication  Provider (VNF Provider)が決めている IT系では、Compute FlavourやGuest OSはインフラ提供者が決め、Cloudの運用効率最大化を指向することが多い NFVでは、性能向上のためにGuest OSの使い方がVNF毎に特殊だったり、そもそも独自OSを利用していたりするため、Guest OSや仮想リソースの設定・設計(Descriptor)はVNF Providerが用意する Cloudのネットワーク機能を利用せず、VNF自身がネットワークを制御する IT系では、CloudのDNSやOverlay Networkingの機能を利用しApplicationはNetworkを意識しない方向で設計や運用をすることが多い NFVでは、VNF自体がRouterのようなものなのでAddressingやTunnelingもVNF...
続きを読む