Communication service providers (CSPs) increasingly realize that edge computing will play an important role in creating and deploying the next generation of digital-communications-dependent services.
Vodafone’s paper focuses on three key areas: Distributed Lab, Pre-staging, and Operations. It calls for greater co-operation and systems integration across the industry as mobile network operators commit to rolling out Open RAN more widely. Earlier this year, Vodafone pledged to have around 30% of its European network running on Open RAN by 2030.
前回のPart1では、DevOpsのプラクティスをレベルアップするための課題について取り上げ、ROIにアプローチする方法をご紹介しました。また、インテリジェントエッジ向けの開発では、ハードウェアが課題になることと、シミュレーションがその答えになるということをお伝えしました。今回は、ハードウェアが引き起こす可能性がある問題の4つの要因と、シミュレーションによってそれを解決する方法をご紹介します。では、さっそく始めましょう。
1. 開発ライフサイクルを阻むボトルネック
例えば、設計チームが、設計中のデバイスやシステムに最適なプロセッサとOSの組み合わせで、まだ広く生産されていないコンポーネントが含まれていると判断したとします。あるいは、使用予定のハードウェアは生産されてはいるものの、コストが高すぎて、各チームメンバーがラボで作業ができない状況かもしれません。一方で、すぐに開発に着手しなければ、納期に間に合わないというリスクがあります。 このシナリオに、やっと設計・実装した、待ち望んでいたDevOpsパイプラインを追加したとしましょう。この状況は、どこにも売っていない特定の種類の燃料しか燃やせない高級スポーツカーを所有しているようなものです。
似たようなハードウェアを入手できれば、開発したいものによってはそれで十分かもしれません。しかし、お客様の多くは、100万回以上正確に失敗なくタスクを実行する必要のある産業用ロボットや、何百人もの乗客をA地点からB地点まで安全に運ぶ航空機など、高度な技術を要するデバイスの製造を担っています。このようなお客様にとっては、「十分である」という言葉は通用しません。
２. 精度 vs スピード
一部の企業は、ハードウェアがないという問題に対して、ハードウェアやシステムのモデルやシミュレーションを何らかの形で利用することで対処しています。モデルを選択する際、精度とスピードの間に境界があり、一方が他方にトレードオフされると考える人もいます。しかし、私は2つの理由から、それほど単純な話ではないと思っています。すべてのユースケースで同じモデルを使えるわけではないことや、中にはモデルをまったく使わないこともあるためです。ユースケースによって、モデルに必要な明確さのレベルを決める必要があります。例えば、入手できないインテル®チップをベースにした特定のSoCを開発する場合、エミュレートしたx86システムで開発とテストを行うのか、類似のデバイスでより一般的なx86ベースの開発をするのかです。不具合が見つかったり、自分の設計が確かであるという誤った安心感を持つこともあるかもしれません。しかし、最終的なボードで開発することができれば、それは根拠のないものであるとわかります。
設計の微調整をおこないたい場合や、ソリューションがデプロイされる実際のデバイスや周辺機器に関する複雑なロジックを構築して早期にテストを開始したい場合は、開発の早い段階でDevOpsパイプラインに統合できる忠実度が高いモデルを持つことが優れた選択となります。
よりモデルが鮮明であれば、テストの精度も上がり、結果に対する信頼度も高くなります。もし、低解像度のモデルで合格率が80％だったら、どれだけ安心できるでしょうか？もし、精度の高いモデルであれば、その80％の合格率にもっと安心できるはずです。つまり、DevOpsパイプラインのシミュレーションの精度が高ければ高いほど、コードやソフトウェア出荷の準備に対する信頼度が高くなるということです。
この精度の高さは、認証取得の準備をする際にも重要になります。ほとんどの場合、実際の認証にシミュレーションを使用することはできませんが、認証に至るまでのテストにシミュレーションを使用することで、より信頼性の高い（そしてより迅速な）認証取得に備えることができます。
３. 非破壊検査
非破壊検査は、シミュレーションの利点が明白な分野です。前述のように、デバイスの認証が必要な場合があります。繰り返しになりますが、実際の認証にシミュレーションを使うことはできないかもしれません。しかし認証取得の準備には、ハードウェアを破壊する可能性のあるすべての脆弱性を探す必要があります。デバイスにストレスを与える可能性のある様々なシナリオを想定し、起こりうることを確認する必要があります。問題は、ラボを破壊したり、デバイスの物理モデルや実機そのものを壊すことなく、どのようにストレステストを行ったらいいかということです。デバイスを繰り返しテストして破壊し、すべての脆弱性を見つけなければならないとしたら、危険であることは言うまでもありませんが、相当の費用がかかるでしょう。
シミュレーションを活用すれば、DevOps実践の価値を高め、認証への道を早めると同時に、ハードウェアラボのコストを削減することができます。プリフライトシミュレーションを行うことにより、事実上無限のシナリオの組み合わせを限度なくテストすることができます。夜間に実行し、翌朝ログインしたときに結果が表示されるよう、テストを自動化設定することもできます。サーバーに影響を与えることはありません。
４. １台のデバイスか、複数のデバイスか
1台のデバイスで実行するテストをセットアップするのは、簡単とは言いませんが、たった1台でしかありません。もし、複数のデバイスを含むシステムを構築するのであればどうでしょうか？それぞれのデバイスが異なる環境にあったり、異なることをする必要があるにもかかわらず、ネットワークに接続されていたり、ネットワークに依存していたりするとしたらどうでしょうか？10台、100台、1000台以上のデバイスを接続したラボを立ち上げてテストを行うことは可能ですが、簡単ではありません。あるお客様は、会社全体にあるネットワークにすべてのテストデバイスを接続することで、それを実現しました。テストは成功しましたが、かなりの手間とコストがかかりました。複数のデバイスを購入し、そのすべてをネットワークに接続する時間を要しました。オフィスの隅々にまでデバイスが散らばっていないとしても、最良のシナリオはあらゆる方向に配線接続されたラボをもつことです。しかし、それは混乱するだけでなく、管理上とても難しいことです。
では、物理的なラボをセットアップした後、変更が必要になったとき、DevOpsパイプラインはどうなるのでしょうか？単一のボックス上でコードの一部をテストすることは、それ自体十分に困難なことですが、ネットワーク上で作業している場合はそれだけでは不十分です。すべてのハードウェアを、可能な限り、デプロイされる環境でテストする必要があります。
もう一つ重要なことは、テストの頻度です。複数のコンポーネントを設置した物理的なテストラボがある場合、どれくらいの頻度でテストを行うことができるでしょうか？より頻繁なデプロイを目標としている場合に、毎月、毎週、毎日、あるいは1日に何度もテストすることができるでしょうか。
シミュレーションを活用すれば、必要な数のデバイスを無制限に、完全な環境にセットアップすることができます。1台のデバイスでも1,000台のデバイスでも、一度環境を構築すれば、必要に応じてデバイスを追加したり、設定を変更したりすることが簡単にできます。新しい設定や変数をテストしたい場合も、問題ありません。元の設定に戻したい場合も簡単です。どの配線がどのデバイスに繋がっているのかを確認する必要はありません。さらに、すべてのモデルをシミュレーションすることで、より頻繁にテストを行うことができ、テストの信頼性が高まり、製品の品質も向上します。
繰り返しになりますが、インテリジェントエッジ向けの開発を行う場合、ハードウェアが課題です。良いニュースは、シミュレーションがその問題を解決してくれるということです。
物理的なデバイスでテストすることは可能ですが、それが最適ではない理由はたくさんあります。物理的なハードウェアに依存すると、コストとデプロイに要する時間が増加し、同時に信頼性と品質が低下する危険性があります。ハードウェアの可用性に起因するボトルネックは、出荷日を遅らせたり、完全なテストをおこなう能力を制限します。市場投入時期の遅れは、競合他社に追いつかれる可能性をつくり、顧客の不満につながります。一方、納期を守っても、十分なテスト時間を確保できなければ、顧客のニーズを満たさない製品を提供するリスクが高まります。
シミュレーションモデルを決定する際に、正確さよりもスピードを優先させると、実際に納品遅れを招く危険性があります。低解像度や不正確なものを使うと、信頼できるテスト結果を得ることができず、結局はより多くの作業を行う必要性がでてくるのです。
非破壊検査がおのずと示すのは、ハードウェアを破壊するたびにコストは上昇するということです。
多くのデバイスをテストする場合、デバイスを追加するたびにコストを押し上げることになります。また、デバイスのコストだけでなく、テストする物理ネットワークの接続や管理にもコストがかかります。
一方、Simicsを使ったシミュレーションは、最初から正確なモデルを使って、すぐに作業を開始することができます。サプライヤーからハードウェアが入手できるようになるのを待ったり、それを必要とするエンジニアのためにラボの時間を確保する必要はないのです。始めから精度の高いモデルで作業することができるため、必要なすべてのテストシナリオを実行するための十分な時間を確保しながら、納期に間に合わせることができます。また、これらのテストを自動化することで、各変更をDevOpsパイプラインに直接フィードし、必要な頻度でデプロイすることが可能になります。
シミュレーションしたモデルが壊れても、ボタンを押せば瞬時に復旧できます。さらに、自動でセットアップと再度実行するように設定すれば、結果を確認するだけでよいのです。
ネットワークのテストが必要な場合はどうでしょう？必要なだけコンポーネントを追加してください。基本的にコピー＆ペーストで追加することができます。ユースケースによっては、他のネットワークや物理デバイスにリンクし、テストすることも可能です。
このシリーズを紹介する動画を作成しました。以下からご覧いただけます。
https://www.windriver.com/resources/webinars/devops-with-simulation-can-solve-your-hardware-problem
Wind River Simicsについての詳細は以下をご覧ください。
https://www.windriver.com/japan/products/simics
もしあなたが、将来インテリジェントエッジで動作するデバイスやシステムのソフトウェアを開発する予定があり、DevOpsが価値ある取り組みであるという考えをお持ちで、開発を次のレベルに引き上げる方法を知りたいと思っているのであれば、この記事は正しい場所です。
Google DevOps, Research, and Assessment (DORA) チームが発表した最新の「State of DevOps」レポートによると、パフォーマンスの低いDevOpsチームは、ソフトウェアの本番環境へのデプロイ頻度が6ヶ月に満たないということです。その場合、おそらく16%～30%の割合で変更に失敗しており、コードから本番環境に移行するには最大で6ヶ月のリードタイムが必要となります。変更の頻度が低く、何かを壊すリスクが比較的高く、次の更新に6ヶ月かかっているのです。
これを、973倍の頻度でデプロイすることができ（基本的に1日に何度もオンデマンドで行う）、コミットからデプロイまでのリードタイムが6,570倍速く、インシデントからの回復も速く、変更の失敗が30％少ない、パフォーマンスの高い優秀なチームと比較してみてください。
この数字は素晴らしいものですが、少し抽象的かもしれません。失敗を金額に換算するとどうなるでしょうか。
Consortium for IT Software Quality（CISQ）が発表した2018年のレポートによると、米国における品質の低いソフトウェアの総コストは2兆8400億ドルでした。これは、失敗したプロジェクト1件あたり、平均で約5000万ドル（約55億円）に相当します。この金額は大袈裟かもしれませんが、本当にそれだけのお金を失う余裕があるのか、考えてみてください。
なぜ、高品質のソフトウェアをリリースすることは難しいのでしょうか？
お客様の要望を理解し、それにタイムリーに応えることは、組織にとって難しいというのが一般的な認識です。アジャイルやその他の最新の開発プロセスはリスクを減らすことを目的としていますが、組織全体でどのようにして関連性のあるスピードで価値を提供し続けることができるのでしょうか。
つまり、DevOpsを行うことは良いことであり、それをより良く行うことで真の利益が得られるということです。
では、何が必要で、どのように行えばいいのでしょうか？
DevOpsの基本はすでに実証済みであると仮定します。
あなたのチームはおそらく、よりアジャイルで、より連携が取れ、コラボレーションが改善されていることでしょう。もしかしたら、以前よりも早く、より質の高いコードを本番環境に投入できるようになっているかもしれません。あなたがその実現に一役買ったのであれば、大変すばらしいです！
しかしこの時点で、改善効果が安定しているかもしれませんが、経営陣の期待値に達していない可能性があります。その場合、次の一手を考える必要があります。
ROI を証明する必要があるという問題があります。次の変化は、初期のフェーズで見ることができたような深遠なものにはならないかもしれないという懸念もあります。では、DevOpsの効果を加速させるような漸進的な変化は、どのように行ったらよいのでしょうか。変更を行う際、おそらく次の問題のいずれか、または両方に遭遇するのではないでしょうか。
1. 抵抗の克服：新しいDevOpsプラクティスを導入したいとチームに提案しても、チームではすでに現在のプラクティスを中心にワークフローを設計してしまっているケースがあります。特に、前回の変更に慣れてきたところで、変更を求めることは難しいものです。
2. 経営陣の過大な期待：経営陣の期待は非常に高く、作業がどれほど複雑なものであるかを理解していないのではないかと思えることがしばしばあるという経験があるのではないでしょうか？常に革新的でなければならないというプレッシャーもあります。「より迅速に」は、現実的には良い問題かもしれません。しかし、問題はそれについていけるかどうかです。
抵抗とプレッシャーという2つの問題に対処する方法が１つあります。「care abouts（関心ごと）」を特定し、変更したい指標を見つけることです。誰も、「ソフトウェアを悪くするためにプロセスを変えろ」とは言いません。しかし、単に「より良く、より速く」というのも、問題解決には有用ではありません。
ROIの構築方法やDevOpsへの投資を増やすためのケースを検討する際の測定可能なことと不可能なことを見てみましょう。
ほとんどの企業は、顧客から報告された不具合を解決するために、どれだけのコストがかかるかを試算することができます。自動テストが増加すれば、不具合はより早く発見され、より低コストで修正できます。もし、出荷時の不具合を5%～10%減らすことができれば、それは現在持っている（あるいは見つけることができる）データに基づいた見積もり可能な価値となります。
不具合を修正する作業が必要ですので、節約分を二重に計上しないことに注意してください。
測定は難しいけれども、時間とともに変化し、追跡する価値のあるものもあります。そのよい例がレピュテーション（評判）です。企業の評判を測る方法はさまざまです。ウインドリバーでは、ネットプロモータースコア（NPS）、または、お客様が当社を誰かに推薦する可能性がどの程度あるかという尺度を使用して測定しています。あなたの会社では、別の測定基準を使用しているかもしれません。重要なのは、この指標を使用して市場での評判を追跡することができるということです。品質が向上したためなのか、あるいは他の市場の力によってなのか、評判の因果関係を証明するのは難しいことです。しかし、この指標を長期的に追跡すれば、肯定的または否定的な傾向を特定できます。
評判は売上に影響を与えるものであり、そのデータにアクセスできれば、傾向を知ることも可能です。満足度の高いお客様の契約更新の増加、既存顧客の他プロジェクトへの横展開、あるいはポジティブな報道からもたらされるリードなどは、営業チームやマーケティングチームが追跡可能なものです。繰り返しになりますが、因果関係を証明することは困難ですが、追跡する価値はあります。
そして、最終的な収益を向上させるコスト削減を中心に、良い例を作ることができます。また、経営陣に改善を示すために、貴社がすでに追跡している測定しにくい指標を強化することができます。
さて、何を求めたらよいのか、そしてDevOpsを改善することでどのようにそれを実現することができるのかを理解したところで、悪い知らせがあります。
インテリジェントエッジ向け開発のハードウェア問題です。しかし、シミュレーションがその問題を解決してくれるとうい良いニュースもあります。
次回は、ハードウェアが引き起こす可能性のある問題の具体的な例と、それを解決するためのシミュレーションについてご紹介します。
また、このトピックスを紹介する動画を作成しました。以下でご覧いただけます。
https://www.windriver.com/resources/webinars/devops-with-simulation-can-solve-your-hardware-problem
Wind River Simicsについての詳細は以下をご覧ください。
https://www.windriver.com/japan/products/simics
Wind River Studio provides a complete cloud-native infrastructure software stack, based on the StarlingX open source project.
Future use cases including IIoT, telecom, video delivery, and other demanding, low-latency applications require the complete Kubernetes-based cloud infrastructure software stack for the edge provided by Wind River Studio Cloud Platform.
Heterogeneous distribution of Kubernetes clouds. Includes a central cloud (system controller) and remote, geographically dispersed edge clouds. Supports centralized deployment of a container platform on sub-clouds with sub-cloud health monitoring and management.
Provides full lifecycle management of the host. Detects and automatically handles host failures and initiates recovery. Also provides monitoring and fault reporting for cluster connectivity, critical process failures, resource utilization thresholds, interface states, and more.
Provides a framework for infrastructure services via API to set, clear, and query customer alarms as well as generate logs for significant events. Maintains an active alarm list and provides a REST API to query alarms and events.
Automated deployment of software updates for security and/or new functionality. Includes end-to-end rolling upgrade solution and supports in-service and reboot required patches.
HManages installation through auto-discovery of new nodes, managing installation parameters, and bulk provisioning of nodes through the XML file. Also handles nodal configuration and inventory discovery.
Includes a high availability manager with an N+M redundancy model or N across multiple nodes. Uses multiple messaging paths to avoid split-brain communication failures. Also provides active or passive monitoring of services.
Use cloud strategy orchestration to patch a thousand sub-clouds with a single click.
See how automated patching keeps your sub-clouds in sync.
Elisaとウインドリバーは、欧州初の分散型かつ完全自動化された5G向けファーエッジクラウドを構築するために協業しました。このパートナーシップは、大規模な5Gの立ち上げに拍車をかけ、ヨーロッパ全体のデジタル変革の次の波を先導するものとなると確信しています。具体的には、Wind River Studioは、低遅延と高スループットが求められる高度な5Gユースケース向けに、ミッションクリティカルなネットワーク機能とアプリケーションをホスティングする分散型クラウドネイティブプラットフォームを提供するクラウド基盤技術として機能することになります。また、分散型クラウドプラットフォームの一部として、このような分散型ネットワークを大規模に運用するために必要な自動化およびアナリティクス機能も提供します。
Elisaは、フィンランドにおける通信事業のマーケットリーダーであり、5Gとデジタルサービスのパイオニア的存在です。Elisaは、継続的な開発、イノベーション、さまざまな分野のパートナーとの協業によって未来のサービスが構築される業界で事業を展開しています。
ElisaのエグゼクティブバイスプレジデントであるSami Komulainen氏は、次のように述べています。「欧州発の分散型および完全自動化された5Gエッジ商用デプロイメントという重要なマイルストーンにおいて、ウインドリバーと協業できることを嬉しく思います。フィンランドでは5Gが大きく普及しつつあり、当社の5Gのお客様は最も満足度の高いお客様です。Wind River Studioによるエッジクラウド機能は、新サービスや顧客体験の向上という形で当社の顧客満足度をさらに向上させ、業務の自動化におけるデジタルサービスプロバイダーのリーディングカンパニーとしてのElisaの地位を強化するものと考えています」
未来の5Gを成功させるための分散型クラウド
Elisaはプライベートモバイルネットワーキングなどの新しい5Gサービスで効果的にビジネスチャンスを獲得するために、拡張性、低遅延、高性能、容量に加え、高度な自動化と監視を含む新しい運用モデルを必要としています。したがって、エッジインフラストラクチャで5Gサービスを提供するためには、ユーザと近い場所で超低遅延でデータを処理する必要があるため、エッジクラウドインフラテクノロジーが重要な投資分野となります。
Elisaの目標は、エッジクラウドのネイティブなインフラストラクチャにより、一元化されたクラウドからエッジクラウドを定義、委託、管理する能力を使った、「オペレータが関与しないゼロタッチのデプロイメント、設定、有効化」です。Elisaは、概念実証（PoC）の選定プロセスを経て、ウインドリバーを分散型クラウドのパートナーとして選定しました。
Elisaとウインドリバーのエッジクラウド検証活動
Elisaの5G向けエッジクラウドインフラストラクチャは現在生産計画段階で、2022年中のデプロイメントを目標としています。初期のスコープは、Elisaの現在の5Gコアベンダーによる完全にコンテナ化された5G UPFのサポートです。これに続いて、ネットワークのファーエッジでリアルタイム処理が必要なユースケースを対象とした一連の技術評価（O-RANなど）が行われる予定です。
Wind River Studioは、分散型コアおよび無線機能のクラウド化をさらに進めるために、複数のベンダーと複数の技術をホストする共通の分散型クラウドプラットフォームとして使用される予定です。
ウインドリバーはElisaと密接に協力し、ネイティブエッジクラウドソリューションの加速と革新、そしてオープン性とエコシステムのダイバーシティを促進できることを楽しみにしています。
ウインドリバーは、5G市場におけるリーダーとして、Verizon、Vodafone、KDDI、そして今回のElisaなどのグローバル通信事業者とともに、5G vRAN/ORANの展開を促進していることを誇りにしています。Wind River Studioは、物理的に分散した超低遅延のクラウドネイティブインフラストラクチャのデプロイと管理といった、サービスプロバイダの複雑な課題に対応します。
Wind River Studioは、ミッションクリティカルなインテリジェントエッジシステムの開発、デプロイ、運用、サービスを行うためのクラウドネイティブプラットフォームです。Wind River Studio cloud platform は、StarlingXプロジェクトをベースとし、完全にクラウドネイティブなKubernetesおよびコンテナベースのアーキテクチャにより、大規模な分散エッジネットワークに対応しています。Wind River Studioは、クラウドネイティブのvRAN/ORANインフラストラクチャのデプロイと管理の複雑性に対応します。地理的に分散したマネージドソリューション基盤を提供し、物理的な場所に関係なく、一元集中管理（SPoG）によって何千ものノードをゼロタッチで自動管理し、Day1とDay2の運用の簡素化を実現します。
Wind River Studioの詳細については、以下をご覧ください。
https://www.windriver.com/japan/studio
