投稿

データベースって何?ストレージとの関係は?①

イメージ
RESTをはじめとした最近のフレームワークや実装では、データベース(DB)やストレージはシステムの中の実装オプションの一例というレベルではなく非常に存在感を増した技術になってきている。一方で、DBやストレージはデータを破損させないように非常に多岐に渡る技術が蓄積されているため、なかなか理解するのにハードルが高い。そこでDBとストレージを勉強する上での入り口になるように概要を説明してみたい。厳密には正しくない部分があるが、分かりやすさ重視のため、その点はご了承頂きたい。 システム開発のフレームワークとデータの関係 突き詰めるとプログラムとは何か?システムとは何か?というと、与えられた 情報 を元に、定められた ロジック によって、問題を解決するもの、である。最初は暗号解読や天気予報など特定の問題を解決するために使われてきたが、段々プログラム言語が開発されプログラムが汎用化されたり、ハードウェアの性能が上がって問題解決のパワーが増したことで、解決できる問題のバリエーションも量も激増してきた。その結果、システム開発の定石(フレームワーク)も変わってきた。 システム開発のフレームワークには様々な評価軸があるが、ここでは問題解決のスケールとして、データ量と処理量に着目してみたい。初期のプログラムはテープにデータとルーティン処理が記録された専用計算機だったものが、プログラムの汎用化とハードウェアの高性能化によって、①扱うデータが増えたことでデータベース化する流れと、②処理量が増えたことに対するマルチプロセス化という2つの流れができる。その結果、一昔前の典型的なフレームワークとしては、データは全てストレージ+データーベスへ格納しデータの管理に特化したプログラムと、そのデータを加工する処理ロジックに特化したプログラムに分離する流れができた。 しかし、このアーキテクチャは、ストレージのサイズやDBの性能にボトルネックが来たり、処理ロジックが変更になった時に他のロジックへの影響も含めて見直しが必要だったりして、問題(=要件)の変化に追従し続けるメンテナンスも大変だった。特にデータ量を拡張したり処理量を拡張する場合は、大型サーバのスケールアップ(CPUやメモリやディスクを増やす)が主な方法となっておりコストも増加した。そこで、データとロジックを一つのオブジェクトとして隠蔽し、オブジェクト...

NFV#40(2022年12月)@London & O-RAN F2F@Madrid(2022年10月)会合サマリ

イメージ
 9月の会合から段々と現地参加型の会合の形式に変わってきた。オンライン参加者もまだまだ多く今回10月のO-RANと12月のNFV#40は現地とオンラインのハイブリッドでの開催ではあるが、概ねどこの企業も最低でも数名は現地で参加しているようだ。HuaweiやZTE等の中国企業も代表者は現地で参加していた。 今回のNFV#40はLayer123との同時開催となり、様々なグローバル動向の議論があった。そのNFV、O-RAN、Layer123の議論を聞く限り、昨今の方向性は"コンテナ化"から"統一プラットフォーム + 自動化"になってきているように感じる。 NFV#40のサマリ NFVの各Releaseの概要は NFV IFA&SOL(2021年10月)会合サマリ と ETSI NFV仕様の各リリース機能 、詳細は ReleaseDocument 、各仕様の最新状況は Openbox と Feature Wiki を参照して頂きたいが、前回 NFV#39 からの更新は Release2(v2.8.1)に続き、Release3(v3.7.1)もメンテナンス終了となってきた。WIMのStage 3 IF Or-Wi( SOL019 )は完成しなかったため、Release4へ延期となる。 新ETSI NFV ISG議長中島さんのChairman perspectiveが発表された Release4(コンテナ対応): 4.4.1に向けてCIS Cluster管理のためのCCM (CIS Cluster mgmt)を中心にStage2/3の仕様化 FEAT17 (Clust-native): CCMのStage3 IFとしてSOL020が提案&承認された CIS Cluster (Kubernetes Master Node + Worker Node)を構築&運用する機能部としてCIS Cluster Management Function (CCM)が定義 CCMはCIS ClusterのLCMやFCAPS、更にはKubernetesのCRD(Custom Resource Definition)も構築&管理する IFA036のアーキテクチャや機能分担を満たせるデファクトソリューションはないため、GAP分析からスタート Cluster AP...

NFV#39(2022年9月)会合サマリ

イメージ
 今回のNFV#39では、旧議長陣が引退し選挙が行われたり、次期NFVのコンセプトについてWorkshopがあったりと、ETSI NFVが大きく飛躍する期待を受けた。 NFV#39のサマリ NFVの各Releaseの概要は NFV IFA&SOL(2021年10月)会合サマリとETSI NFV仕様の各リリース機能 、詳細は ReleaseDocument を参照して頂きたいが、前回 NFV#38 からの更新は Release2 (VNF LCMの基本機能): v2.8.1を最終バージョンとして終了(変化なし) Release3 (自動化やNWの制御): v3.7.1を最終バージョンとして最終メンテナンス中(WIM  IFを除く) SOL APIで参照しているREST系のRFCについて、RFC 9110 “HTTP Semantics”とRFC 8446 “TLS Version 1.3”によりいくつかの仕様が変更になった RFC 7231、RFC 7232、RFC 7233、RFC 7235が廃止(Obsoleted)されたことで、“payload body” -> “message content”、”422 Unprocessable Entity” -> “422 Unprocessable Content”と名称が変わった HTTP conditional requestsが導入され、GETやPatchでの”E-tag”や”Last-Modified”によるキャッシュの仕様が明確になった(既存仕様でも考慮はされていたが不透明な仕様だった) RFC 8446ではRFC 5246 “TLS Version 1.2”は廃止(Obsolted)になっているが、SOL  API Rel3はTLS 1.2を継続利用することになった SOL005 Os-Ma-NfvoにおけるImageのUpload/Download時にBASIC認証も利用できたが、OAuth2.0のみとなった SOL002 Ve-VnfmにおけるVNF/VNFC Configuration Dataにおいて、DHCP ServerのIP Addressは不要(DHCP DISCOVER/DHCP REQUESTはBroadcast)のため、dhcpServer a...

グローバルでチームを牽引するためには

イメージ
グローバル人材に向けて必要なスキルとは や 基礎情報収集 においてグローバルで必要となる知識やスキルについて紹介したが、今回はグローバルでチームを牽引するケースについて考えたい。 グローバルでチームを牽引する場合も、国内同様にステークホルダーを意識し、チームのアウトプット(作業スコープ)の明確化と作業全体の可視化は非常に重要であるが、それに追加して現作業のアウトプットが次の作業やプロジェクトに連続的に続くビジョンを描き続けることがチーム内のメンバーから信頼を得るためには重要だと感じる。 グローバルでチームを牽引するときのスキルセット グローバルであろうと、チームを牽引するためにはステークホルダー (お客様や依頼元、チーム内、幹部などの意思決定組織、自チームの作業の周辺作業のチーム等)からの“信頼“が必須となる。信頼を得るためには、スキルと実績が必要である。立場によるのかもしれないが、国内では実績に重きを置かれがちだが、海外ではスキルと与えられた権限に重きが置かれているように感じる。 ビジネススキルについては グローバル人材に向けて必要なスキルとは を参照して欲しいが、ビジネススキルのThink/Collaboration/Actionが揺らぐとなかなかチームを牽引することは難しい。これらのスキルスタックを基にステークホルダーから信用や信頼を得ることが、チームを牽引するスキルセットの第一歩となる。そして、リーダーとしてチームを牽引し続けるためには、お客様をはじめとした業務の依頼元との調整、チーム内の管理、そして自分自身のマインドセットの維持・向上を継続することが必要となってくる。 実はこれらのスキルセットや必要な能力は、実質国内の管理者やリーダー的存在のスキルセットと変わらない。しかし、各スキルや能力の濃淡には少し違いがある。例えば、グローバルではステークホルダーのバックグラウンドやモチベーションが異なるため、資本管理やメンバー管理といったマネジメントスキルより、ビジョンを掲げそのGAPを主張し続けられる人の方がリーダーとして信頼を得やすいように感じる。同様の背景から、反対意見を含む様々な意見や考えがある中でも最後までやり遂げられるタフさや、チームの活動内容を明確化するための作業スコープのIN/OUTを即時できる決断力を持った人が好まれる傾向にある気がする。 チームを...

NFV#38(2022年5月)とO-RAN WG6 F2F Denver(2022年5月)の会合サマリ

  今回のNFV#38(5/30〜6/3)は久しぶりの現地(ETSI本部@フランス・ニース近郊)となった。今回はOpenStack TackerもIFA/SEC/SOLもEnh01.01 Certificate Managementが一つの大きなトピックではあったが、それ意外もRelease4/5ともに 仕様検討が大きく進んだ。やはりFace To Faceの会議は、各社の意向を擦り合わせるのが難しい議論の進展には重要なのもかもしれない。 最新のNFV仕様の全体像は こちら (ETSI-NFVのOpen area)で、現在のNFVのリリース機能の状況は NFV中間会合(10月)サマリ 、前々回のNFV会合の説明は NFV#36サマリ (NFV#37 2022年2月会合は筆者の執筆漏れ)を確認して頂きたい。 NFV#38のサマリ NFV#36やNFV#37と比較した重要な活動結果としては、 Release2はETSI-NFVとしてはv2.8.1を最終バージョンとしメンテナンスも終了 Release3はSOL019を除き、v3.6.1で既存仕様(Stage2/Stage3/Stage4)のReleae3対応は全て終了 Stage3/Stage4はv3.7.1のメンテナンスは継続 残仕様はFEAT10 (Multi-Site Connectivity Service)のSOL019 (MSCS Stage3) WIM向けIFの追加(v3.7.1(7月) or v3.8.1(12月)予定) Release4はdrop3としてv4.3.1のIFA/SOLの仕様が完成(Finalize中) Enh02.01 (SDN integration): Layer3のvRouter相当の記述をできるようにSOL001(NFV Descriptor)へRoutingResourceDataの追加 Enh02.02 (NS feasibility check): 時間のかかるNSのInstantiateの処理の前にInstantiateNSの事前チェック/リソース予約のためにSOL005(Os-Ma-Nfvo)へFeasibility Check/Reserveの追加 Enh02.03 (Data flow mirroring): VNFのTroubleshootingのための通信...

モバイル装置の開発手法の基本② 〜機能設計編〜

イメージ
モバイル装置の開発は正常ルート1に対して異常ルート9の設計が必要と言われているように、1機能を実現するために必要な設計・製造・試験のコストが大きく、装置の導入や変更にも多大なコストが発生する。そのため、一度新装置を導入すると、なかなか大きな変更や撤去ができなくなる。そのため、『 モバイル装置の開発手法の基本① 〜開発工程編〜 』の通り、法律や運用条件などの様々な要件から外部設計を行い、SLA99.999%を10年継続できるように機能設計を行なっていく必要がある。また、最近では『 ネットワーク仮想化基盤におけるETSI NFV Stage3仕様に準拠したマルチベンダ対応MANOへの移行 』の通り、製造請負と呼ばれる自社での開発から、標準化やOpen Sourceを利用した製品を利用した開発に開発方法も変わってきている。今回はそのようなモバイルにおける機能設計の基本について書いてみたい。 モバイル装置における機能設計の基本 『モバイル装置の開発手法の基本①』において長期スパンを見越した課題に対する外部設計が完成すると、そこから機能設計になる。外部設計では、主に対象の業務や必要なサービスなどの“解決する課題“、GUIや他装置や既存装置と接続するための“インタフェース”、法的ルールやSLAなどの”条件”、そして性能や拡張性などの“開発ポリシー”の4つを中心に設計することになる。ここから機能設計をするためには、基本的には“機能の定義“が必要となる。 モバイルにおける“機能の定義“では、全ての装置や通信を新規の装置に全て置き換えることは技術的にもコスト面でも難しいため、既存の装置が既に持っている機能を最大限再活用することが求められることが多い。そのため、まず最初に行う機能定義は 既存装置と新規/変更する装置での機能分担 が行われる。モバイルの場合は、これらをシーケンス図(Information flow / Procedure)で記載することが多い。 シーケンス図によって、既存装置を含む周辺装置と新規/変更する装置の機能分担と、どの装置にどんな入力データ&出力データが必要かを設計する。この入出力データはIF仕様書と言われ、具体的に装置間でやりとりするデータやそのデータを届けるための約束事(プロトコル)を規定したりする。特に、装置やネットワークの故障や過負荷などで正常にデータが届...

モバイル装置の開発手法の基本① 〜開発工程編〜

イメージ
 NFV(クラウド技術)の導入やモバイル内の信号のREST化によって、モバイル装置の開発とWeb系の開発の境界が段々薄くなってきているように感じる。ETSI NFVやO-RANでもCloud-Native ( ETSI GS NFV EVE 019 ) やCICD ( ETSI GR NFV TST 006 )という話が出てきたり、OpenStackやKubernetes、 Free5GC 、 O-RAN SC というOpen Sourceを(部分的でも)利用したり、リファレンス実装として仕様調整として参考にされたりしており、従来のような専用装置を開発する開発スタイルから変わりつつある。 一方で、モバイルサービスの特徴そのものは変わっていないので、開発で求められる要件は変わっていない。今回は、変わりつつあるテレコムの開発スタイルを横目で見つつ、モバイル開発の基本とその特徴について書いてみたい。 モバイル装置を開発する上での基本的要件 モバイルネットワークの保守運用の基礎 にも記載している通り、モバイル装置は各国で法規制がありつつ、目標SLA 99.999%(年間停止許容時間5分程度)を目指した様々な運用条件や保守要件がある。Web系システムの場合は目標SLAを99.9%(年間停止許容時間9時間弱)と設定していることが多いので、この目標SLAの違いがそのままシステム設計の基本原則や運用条件の違いとして染み出してくる。 また、モバイルサービスは、2G、3G、4Gがそれぞれ10年近くサービスを提供し続けている通り、同一サービスを長期間提供し続ける必要がある。モバイルサービスは、多くの場合途中でのサービス追加などを求められることはなく、安定した通信を値上がりすることなく継続利用できることが求められる。 この、目標SLA99.999%を実現することと、10年単位でのサービス継続のために、各モバイルオペレータやベンダは様々な開発ノウハウを保有しており、それらに基づいてこれまで開発してきた。また、日本の場合は総務省が「電気通信事故検証会議」として毎年その年の通信事故の検証結果を報告書としてまとめており、その中に再発防止策や教訓が記載されている。最新の取り組みは電気通信事故検証会議の報告を参照するとして、各モバイルオペレータが取り組むべき品質改善策の全体像については、少し古...

MECとは?vRANやNFVとの関係は?

イメージ
 O-RAN/vRAN (virtual Radio Access Network)と並んで、最近注目を集めている技術にMEC (Multi-access Edge Computing)がある。AWSやGoogleなどのHyperscalerと呼ばれる巨大なパブリッククラウドビジネスがある中で、小規模分散型のMECが騒がれている理由について見てみたい。 MECが想定するビジネス iGillottResearchの『 小売業界におけるMECのビジネスユースケース 』や、NECの『 ユースケースによるMEC導入効果とメリット 』に想定されるビジネスが記載され始めているが、これらのユースケースによれば各企業のシステムを自社(オンプレミス)〜ネットワーク(MEC)〜クラウドのどこに置くかによって“企業のコスト構造の変更によるコスト削減“に見える。 一般的にビジネス性と言えば、「(収入ーコスト)×ビジネス継続期間」となるので、①新規収入(収入UP)、②コスト削減、③SLA/品質/安全性向上(ビジネス継続)のいずれかとなる。MECにおいては各企業のシステムを構築する環境(クラウド)の提供形態となるので、 ITとモバイルの保守の違いとは? での説明の通り本来物理装置を集約することでコストを極限まで下げることで成り立つビジネスのはずである。しかし、MECは分散することで②のコスト削減や③の品質や安全性の向上を狙っているので、分散クラウドによる維持コスト増加とのバランスにおいてビジネス性のあるユースケースがなかなか出てきていない。総務省の『 ネットワーク設備委員会 』においても、この分散クラウドとパブリッククラウドの効果とコストのトレードオフの関係は議論されているようだ。 交換機に近い場所では、モバイルオペレータ観点では設備の効率化は可能だが必要となるリソースのパブリッククラウドとの差が小さくなるため、大きな費用構造の差は無いだろう。パブリッククラウドの場合ネットワーク帯域の使用料が比較的高額なケースが多いため、そのような高額なリソースの種類によってはMECが競合相手になる可能性がある。 一方で、中継局や基地局のような箇所にMECを置くことが出来れば、ネットワークリソースなどを省略し、費用構造を変えることができるだろう。ただし、MECを基地局サイドに近付けるほどアーキテクチャ...