この記事は、CX の CTO である Rajiv Asati によるブログ「Rakuten Mobile & Cisco CX: Disrupting the Industry, Together」(2021/9/16)の抄訳です。
「お客様が買い求めているのは製品ではなく成果である」。これはシスコの COO である Maria Martinez の言葉ですが、業界を大きく変革するという成果を実現できたときの喜びはまさに格別です。
シスコは業界に変革をもたらす立役者として長年の実績を誇ります。現在、いくつかの業界が破壊的革新(ディスラプション)の好機を迎えていますが、楽天モバイル社などの通信事業者が登場して活気づく通信・メディア業界もそのうちの 1 つです。
楽天モバイル社とシスコは互いに連携してこの 3 年間で数多くの成果を挙げてきました。まず、IPv6 専用のクラウド ネイティブ モバイル ネットワークを世界で初めて構築しました。エンドツーエンドの自動化が実現されていて、プログラム可能なソフトウェアスタックを備えています。最近も、セグメントルーティングの導入という大きな前進を果たしており、未来に向けてより包括的で優れたインターネットを構築していく能力という点で楽天モバイル社は独自のポジションを確立しています。私たちは今後もさらなる高みを目指して歩んでいきます。
ここまでの道のりは困難に満ちたものでしたが、労力に値する成果が得られました。楽天グループの CTO である Tareq Amin 氏の次の言葉は、このことをいみじくも言い表しています。
「課題は山ほどありました。正直に申し上げて、これまでの道のりは苦労の連続でしたが、私たちは正しい道を歩んできたと思います。今手にしているのと同じ成果を得るためにまた一からやり直すことになっても、やはり同じ道を歩むでしょう。私たちは必要なことをしてきたのです」。
楽天モバイル社の案件は、シスコ カスタマー エクスペリエンス(CX)チームがお客様、シスコのテクノロジーグループ、他のさまざまなベンダーと密接に連携して大きな変革を成し遂げた素晴らしい事例となりました。楽天モバイル社とのこれまでの取り組みを振り返ると、成功への鍵として次の 3 つの原則が挙げられます。
1)先例のない取り組みに挑戦する
「何事も成功するまでは不可能に思えるものだ」というネルソン・マンデラの名言があります。エンドツーエンドで完全に仮想化された IPv6 専用の 5G 対応クラウドネイティブ モバイル ネットワークを世界で初めて構築するという目標は、厳しいタイムラインと予想されるギャップを考えると最初は不可能に思えました。実際、会議の場でも他の多くのベンダーがそのことを指摘しました。決定権のある役員の面々も健全な批判的精神を持っており、シスコの見通しに対して楽観論は聞かれませんでした。モバイルネットワークでこのようなことを成し遂げたことはなかったので、シスコにとっても難しい判断となりました。
慎重に検討を重ね、次に示す主要なアーキテクチャ戦略を策定しました。
- ネットワークのステートをスリムに保つ
- よりシンプルな設計を採用する
- 新機能やコード更新の効率的な増分展開を可能にする
- 複数のフォワーディング プレーン テクノロジー、トラフィック エンジニアリング、ネットワーク障害時の複雑なコンバージェンスパターンに起因する複雑さを回避する
これらの戦略を実現するために必要だったのが次のことです。
– 現状の打破。フォワーディング プレーン テクノロジーとして 10 年以上君臨し続けている MPLS は利用せず、よりシンプルな IPv6 テクノロジーを使用することにしました。
– ネットワークプレフィックスの数を小規模(数千のオーダー)に抑える。そのためには厳密な集約境界を指定し、パケットヘッダー自体(アドレスそのものの最初の 64 ビット)にサービスとサブスクライバの認識情報をエンコードする必要がありました。
– IGP とルートリフレクションを使用した BGP という広く理解されている組み合わせの活用。よりシンプルなルーティングトポロジを策定することで、運用チームがすぐに理解(および必要に応じて診断)できるようにするためです。
– ソフトウェアベースのコントローラとオーケストレータの導入。プログラム可能なクラウド化したインフラの活用を目指しました。
思索を重ねた結果、これまでの価値基準を打ち砕く「IPv4 でしか使えないのなら、使い物にはならない」という考えで全員が一致することになりました。とても大胆で革新的な姿勢ですが、「常識にとらわれず世界を変える」という楽天モバイル社のビジョンにも合っていました。これは不可能を可能にするための重要なモチベーションになります。
2)徹底的に透明化しデータに基づいて推奨事項を策定する
「不可能」を可能にするにはさまざまなことを変える必要がありました。それには月並みな透明化ではなく徹底的な透明化が必要でした。たいていの場合、求められていたのは大幅な向上であり、それはシスコだけでなくあらゆるベンダーに期待されていました。すべてをオープンにすることが求められていたのです。シスコでも、この目標を達成するためにいくつかのソリューション(クラウドプラットフォームなど)を速やかに進化させる必要がありました。私たちは 1 つのチームとして互いに連携し、チーム全体でギャップを特定、共有しました。そうしたギャップを素早く解決するには連携が欠かせなかったのです。
こうして徹底的な透明化を図ったことで、Cisco CX は PMO(プログラム マネジメント オフィス)としての役割を担うようになりました。楽天モバイル社からの要望に基づいて、プログラム管理とアーキテクチャ管理の両方の観点から計画を策定し、すべてのベンダーが 1 つのチームとして互いに連携して成功を目指すための基本ルールを確立しました。たとえば Cisco CX チームはそれぞれのアプリケーション ワークロード ベンダー(Radio、EMS、IMS など)と緊密に連携して準備を整え、効果的に導入できるようにしました。
さまざまな推奨事項をまとめて策定する態勢を整えることが非常に重要でした。そのためにデータに基づいて長所と短所を分析する徹底的な調査を行いました。専門家チームは会議において(エグゼクティブが出席しない会議でも)推奨事項に沿って議論を進め結論を導くように徹底しました。その一方で、新たな情報があればそれに基づいて微調整も加え、臨機応変に対応しました。これにより、戦略面でも実行面でも反復可能な方法によってさまざまな未決事項をまとめて決定できるようになり、大幅に時間を短縮できました。
3)前進し続ける
不可能な課題は次から次へと姿を現します。全員が次の課題に対して目を光らせ、聞き耳を立てておく必要があります。次の課題がやって来たらすぐに声を上げて、解決に向けて(多くの場合同時進行で)取り組む必要があります。
一例として、クラウド オーケストレーション ソフトウェア スタックの破壊的革新があります。キックオフ後の最初の数か月で、数千のファーエッジロケーション(分散型通信クラウドの展開としてはおそらく過去最大規模)といくつかのデータセンターロケーションをカバーするアプリケーション セントリックな楽天クラウドプラットフォーム(RCP)の設計を開始したのですが、推奨された仮想インフラストラクチャ管理(VIM)ソフトウェア プラットフォームをそのまま使用することはできないことに気付きました。原因はファーエッジロケーション固有の制約(主に電力面およびスペース面)と標準の x86 COTS サーバーにありました。一元化されたデータセンターロケーションであればそのような制約はなく、そのまま使用できていたはずです。
数週間以内に、マルチドメインの多機能チームがソフトウェアのみからなる革新的なソリューションを考案しました。アプリケーション ワークロードに対するエッジハードウェアリソースの使用率を 30% 未満から 90% 超に最大化するというものです。このソリューションでは、ストレージサービス(オブジェクトストレージなど)を分離してリモートロケーションに移動し、制御サービスとコンピューティングノードを結合しました。また Linux OS の確定的なパフォーマンスを確保し、リモート管理とリモートモニタリングを実現しました。さらに、VIM の分散ストレージとして使用する CDN 構造を使用したバックホール ネットワーク インフラストラクチャも考案しました。
その後数か月にわたって x86 COTS ハードウェアベンダーやアプリケーション ワークロード ベンダーなどと緊密に連携して、ソフトウェアスタックの機能を大幅に向上させました。
別の例として、楽天モバイル社の IPv6 ブロック認証があります。すべての通信事業者は IPv6 ブロックを取得する必要があり、楽天モバイル社は APNIC(アジア太平洋地域のアドレス割り当て機関)に要請して付与されていました。しかし、詳細な分析と予測の結果、割り当ての規模が不十分であることが分かりました。ワイヤレスサービスだけでなく有線サービスも拡大が見込まれていたからです。
ほとんどの通信事業者は自社のネットワークに制約されるのでこの割り当てで十分なのですが、楽天モバイル社はそうではありませんでした。というのは、ネットワーク、ストレージ、コンピューティング プラットフォーム向けに非常にフラットでシンプルかつ効率的なインフラを共同で考案、設計、展開していたからです。これによって楽天モバイル社はネットワークに負担をかけずに新しいサービスを大量に提供することが可能になります。ルーティングの集約と境界が明確に定義されているので変更は不要でした。
そこで Cisco CX は楽天モバイル社に代わって APNIC と交渉を行うという非常に珍しいアプローチを取りました。私たちはこのネットワークによって実現される素晴らしいサービスの 5 年先を見据えて、楽天モバイル社に必要なアドレスプールの規模をモデル化しました。シスコは話し合いを仲介し、楽天モバイル社が大幅に大きなアドレスブロックを必要としている理由を説明しました。
IPv6 専用という要件は絶対に譲らなかったわけではありません。この要件を緩和したケースもいくつかありました。厳しいタイムラインにもかかわらず、ほとんどのベンダーはアプリケーション ワークロードのコンプライアンスを維持していましたが、アプリケーション ワークロードでレイヤ 2 接続のみが必要となるいくつかのケースでは要件を緩和し、ロードマップの調整とコミットが行われるまでは IPv4 を一時的なソリューションとして認めました。
今回の事例はシスコにとっても得るところの多い案件となりました。現状を打破するアーキテクチャや設計の実現、構築、実装について多くの教訓を得ることができました。管理プレーンの到達可能性とフォワーディングプレーンの到達可能性の分離や、xHaul とデータセンターの交差といった新しい課題を早期に発見したおかげで、実現したネットワークはこれまでのところシンプルで復元力が高く、効率的であることが実証されています。シンプルさと一貫性の維持という点では今後も成長に伴って課題が発生するはずですが、引き続き取り組んでいきます。
今回の事例では、1)先例のない取り組みに挑戦する、2)徹底的に透明化する、3)前進し続けるという 3 つの原則をご紹介しました。この 3 つの原則は、Cisco CX がお客様と連携して進めていく取り組みの基盤となっています。まったく異なる成果を目指しているお客様もいるかもしれませんが、その成果に到達するためのコアバリューは同じです。
シスコと楽天モバイル社の詳細については、楽天グループの CTO である Tareq Amin 氏のビデオインタビューをご覧ください。