イベント
通信事業者のネットワークインフラの進化に関するカンファレンス「CNTOM 2022」、オンラインの部をレポート
Nianticの5Gへの期待、KDDIが仮想化した交換機を1年使ってみた話、など
2022年11月7日 06:15
5G時代に向けた通信（テレコム）事業者のネットワークのオープン化やクラウド化に関するカンファレンスイベント「Cloud Native Telecom Operator Meetup（CNTOM） 2022」が開催されている。
第3回となる今回はオンラインイベントとリアルイベントの組み合わせでの開催となった。10月25日にはオンラインイベントが開かれ、11月11日には東京大学武田ホールでリアルイベントが開かれる。
ここでは10月25日のオンラインイベントの模様をレポートする。
Nianticの河合敬一氏が5Gへの期待を語る
セッション「Nianticのリアルワールド・メタバースと5Gへの期待」では、Niantic Inc.のCPO（最高プロダクト責任者）の河合敬一氏が登壇した。
Nianticは、「ポケモンGO」「ピクミンブルーム」「Ingress」などの会社だ。また、そうしたARの開発基盤も提供している。河合氏は、多くの人が外に出てクラウドにつながって遊ぶゲームの立場から、ネットワーク、特に5Gモバイルに対して期待することなどを語った。
これらのゲームは175カ国以上で配信され、ユーザーはMAU（月間アクティブユーザー）数千万人、合計の歩行距離は230億kmにおよぶという。
そのほか、位置情報にARを足すのではなくARファーストで開発した「Peridot」も河合氏は紹介した。Peridotでは、カメラに写った町並みなどを三次元で認識し、地面などの特性も判定してキャラクターが動く。
Peridotの処理の多くはローカルのスマートフォン側で行われているが、できればサーバーで肩代わりさせたいと河合氏。また、マルチプレイヤーでお互いのキャラクターが正しく見える機能もあり、いまは米国のサーバーで遅延があるのでピアツーピアの通信でごまかしているが、これも低遅延の通信があればサーバーでやりたい、とも河合氏は語った。
AR開発プラットフォーム「Lightship」も同様に、位置情報やカメラから、どこにいてどちらを向いているかを特定する機能を持つと河合氏は紹介した。
さらに現在Nianticで実際に動いている実験として、5Gを使ったARゲームのデモ動画（画面にはコード名「URBAN LEGENDS」と出た）も河合氏は紹介した。実世界の中で、モバイルエッジ（MEC）と5Gを使い、複数の携帯がお互いの位置を相互に認識しながら、ARでドッジボールのように撃ち合いをするものだ。
「モバイルエッジによって遅延が減って経験がよくなることを確認した」と河合氏は説明した。なお言葉での説明は省略されたが、スライドでは、レイテンシーの改善3倍、無線帯域の容量6倍、バッテリー効率1.5倍という数字が示された。
最後に河合氏は、「通信会社さんとは、いろいろなことができると思う。ユースケースを開発していくところを、いっしょにやっていきたいと思っている」と語った。例えば現在でいうと、ポケモンGOでは広帯域は必要ないが、リアルイベントで多数の人が集まるときのQoSのような制御があるとよい。また、将来でいうと、ARで協調するゲームでは低遅延なネットワークが必要になり、5Gに期待するという。「ユースケースがドライブするところがあるので、ぜひ、いろいろ楽しいことができたらいいなと思っている」（河合氏）。
5Gコアのアーキテクチャをインターネット技術者が再考するとどうなる？
セッション「テレコムのクラウドネイティブ化について最近思っていること」では、関谷勇司氏（東京大学 大学院情報理工学系研究科 情報理工学教育研究センター／デジタル庁 シニアネットワークエンジニア）が、現在の5GのモバイルコアにおけるNFVアーキテクチャについて、インターネットインフラ技術者の視点から問題を提起した。
最初に関谷氏は5Gの現状にコメント。まず仮想基盤の上に永続的に運用可能なコアを作るためにサーバー技術とテレコム技術がより親和性を持っていく必要があるとした。また、1つのネットワークを仮想的に複数に分割する「ネットワークスライシング」について、決められた規格をどう実現するかがエンジニアの腕の見せ所だとも話す。
MECについては、アプリケーション事業者に貸し出すときの分離モデルなどのセキュリティモデルをきちんと考えなければならないと指摘した。
そのうえで、5GからBeyond 5G、6G、7Gと先を見てアーキテクチャについて考えることとして、すべてをステートで管理するという従来のアーキテクチャを引きずっていて、「インターネット屋から見ると集中管理が多いと思う」と関谷氏は述べ、「リアーキテクチャ（アーキテクチャの再考）が必要なのではないか」と語った。
ここから関谷氏は現状のモバイルコアの“イケていない”点をいくつか挙げた。
まずは「ファンクションが多すぎる」。スライシングでコアが増えたときに、このファンクションの多さでやっていけるかというのが1つ。また、UPF（User Plane Function）に集約される中央集権のモデルになっていることも問題として挙げた。
2つめは「電話のアーキテクチャを引きずっている」こと。昔のファンクションの単位をそのまま仮想化したため、そこに無理が生じているのではないかと関谷氏は言う。
3つめは「トンネルにつぐトンネル」。これも電話の回線交換モデルを引きずっているからで、このままBeyond 5Gや6Gや7Gに行くのか？ と関谷氏は疑問を呈した。
これに対する関谷氏の意見が「いろいろ諦めてみたら？」ということだ。電話通信のすべてのステートを管理する世界の上でデータ通信を実現すると複雑になるため、割り切って電話とデータ通信を分けてもいいのでは、と氏は言う。
また、よりシンプルなアーキテクチャとして、インターがもつ自律分散をもってこられないか、とも言う。
例えばルーティングにおいて、テレコムとインターネットそれぞれの利点を融合させたルーティングプロトコルのようなものを6G・7Gに入れていけないかと関谷氏は述べた。
また、いままでの電話機能＝ファンクション、としていたのを見直して、役割ごとに分解して組み立てなおしてもいいのではないか、と関谷氏は指摘。例えば、ファンクションの連携が必要なところは1つのファンクションにしてもいいのではないか、と語った。
最後に関谷氏は、テレコムで言われるクラウドネイティブは仮想化だが、クラウドに乗せられるような形に再設計することがテレコムの未来のために必要ではないかと述べて、「新しく試作するというのを研究者として考えている」と語った。
AWSのテレコム向けサポートを紹介
セッション「5G Network Evolution with AWS」では、AWSの中村哲也氏（Principal Partner Solutions Architect, Teleco Specialist SA Leader）が、AWSのテレコム向けサポートを紹介した。
中村氏はまずAWSのテレコムでのフォーカス領域について、ネットワークの「cloudified（クラウド化）」、オペレーションの「simplified（自動化）」、カスタマーエクスペリエンスの「reimagined（AI/MLなど）」、成長の「unlocked（マネタイズの加速）」の4つを挙げた。
そして、AWSはクラウドのエンドツーエンドの一貫性を提供すると中村氏は語った。テレコムで使えるインフラとしては、通常のアベイラビリティゾーンやローカルゾーン、オンプレミスや通信事業者で動くAWS OutpostやAWS Wavelength、データ移行デバイスのAWS Snowファミリー、AWSから届かないところでネットワークファンクションのコンテナを動かすAWS EKS Anywhereを紹介した。
こうしたインフラを使った構成の例として、複数のリージョンそれぞれの中で複数のアベイラビリティゾーンにまたがってEKSクラスターを構成する例や、プライベートネットワーク内でAWS Outpostで構成する例などが挙げられた。
オペレーションの自動化についても、VPC作成や、EKSでのKubernetesクラスター作成、Helmデプロイ、CNF（Container Network functions）構成と、一連のデプロイの流れをAWS上で自動化できることを説明した。
最後に中村氏は、Build、Operate、Orchestrate、Monetizeをエンドツーエンドで、パートナーと組んで実現できるのがAWSの強みであるとまとめた。
自動車でリアルタイム処理するためのトヨタのエッジコンピューティング研究
セッション「エッジコンピューティングの取り組みとCloud-Nativeエッジ基盤への期待」では、トヨタ自動車株式会社の古澤徹氏（コネクティッド先行開発部 InfoTech E2EコンピューティングG）が、トヨタのコネクテッドカーへの取り組みを紹介した。
現在の車はすでにネットワークにつながっており、車両ビッグデータを解析することによるモビリティサービスの開発に取り組んでいると古澤氏は語った。
例えば、リアルタイムの交通情報サービスや、災害時の通れた道マップ、凍結路の視える化、特定の曜日・時間帯・気象条件等で危険度が高まる地点の推定、保険における運転状況のスコア化などがある。
こうしたコネクテッド技術開発の将来の課題として、ますます膨大になるデータをリアルタイム処理することが求められることがある。これに対して「エッジコンピューティングがその1つの鍵になると期待している」と古澤氏は述べた。
こうしたエッジに関するトヨタの技術開発の中から、古澤氏は2つを紹介した。1つは、エッジのリソースが限られる問題に対し、Kubernetesにより近傍のエッジサーバーが協調して負荷分散する手法だ。もう1つは、セルラーやWi-Fi、衛星など複数の回線を併用した切れない無線通信技術だ。
古澤氏は最後に、今後のエッジに期待することを語った。1つめはクラウドと同様のオンデマンドなリソースプロビジョニングで、これは「アプリケーション固有の要件があるので自分たちで作っていく」という。
もう1つは、Wi-Fi経由でのエッジ（MEC）接続だ。現在のMECサービスはモバイル回線、特に同一キャリアからのみアクセス可能なものが多いが、それをWi-Fi経由でもアクセスできるようにしたいと古澤氏は語った。
固定電話系交換機を仮想化とgit管理に更改した経験
セッション「仮想化した交換機を丸1年運用してみた感想」では、KDDI株式会社の山中貴司氏（コアネットワーク部）が、固定電話系交換機を更改し運用自動化を取り入れて変わったことについて紹介した。
固定系交換機は、約1200万の顧客を収容する加入者交換機で、緊急通報を扱えるプライマリ電話サービスだ。更改プロジェクトは、2016年の11月ごろから2021年の10月ごろまで実施され、今回は設備更改完了から1年たってのまとめとなる。
変わったことその1は、障害対応だ。まず、基盤のハードウェアが故障しても冗長構成を崩さずにオートヒーリングで自動復旧するようになった。
また、基盤で怪しいアラートがあっても予防保全対処をすぐに実行するようになった。コントロールできるうちにマニュアルヒーリングで仮想マシンを別コンピュート（サーバー）に退避するようになったという。
この2点で山中氏が個人的に一番よかったことして、故障対応時に強制的に時間を取られなくなったことを挙げた。一方で複雑になったこととして、コンピュートに障害が起きて仮想マシンが全部移動されたときに、すべてについて正常性確認を実施する必要があることが挙げられた。
変わったことその2は、交換機のconfigデータをgitで保管・管理するようになったことだ。これまでは、サーバーの動いているデータがマスターになっており、全サーバーからデータを吸い上げて、Excel用に落とし込んで、Excelで設計してコマンドファイルを作成して専用GUIで交換機へデータ投入するという面倒な手順が必要だったという。
これを、gitでconfigを管理して変更をプッシュし、Ansibleプレイブックでデータを投入するようにした。
gitにして、当初想定していなかったがよかったこととして、実サーバーからデータを吸い上げる必要がなくなったことや、ブランチを切ってプレイブックに流すので戻すときのデータ作成が不要になったことなどを山中氏は挙げた。一方、よくなかったこととしては、データが多くなってくるとgit上での差分比較が難しくなることが挙げられた。
変わったことその3は、増設対応だ。仮想化したことで、増設したときに時間のボトルネックだった工事が不要になり、時間とコストが節約できることになったという。山中氏はその空いた時間で運用改善に取り組みやすくなったと語った。
ネットワーク仮想化の内製化による「コントロール可能な領域の拡大」「より楽しいエンジニアリング」
セッション「開発の内製化、手の内化の現状 ～現場の苦労、収穫、そして楽しさ～」では、NTTコミュニケーションズ株式会社の飛岡良明氏（エバンジェリスト）が、ネットワーク仮想化の開発を内製化した経験を語った。
対象は、NTTコミュニケーションがエンタープライズ顧客に提供しているIaaS「Smart Data Platform（SDPF）クラウド」だ。規模は、物理ネットワーク機器が3000台、物理サーバーが5000台、仮想マシンが4万台だという。
内製化で経験したことその1は、「事件は現場で起こっている」ということだ。特定のパケットや特定のシーケンスでのみ障害が発生するものは、メーカーに問い合わせても再現できないことがあるという。
これを飛岡氏は将棋盤にたとえ、「将棋盤で起こることをすべて予測するのは難しいが、現場で盤を見れば1手前を把握できる」ということから、「われわれのシステムで起きている問題は、最前線のわれわれが一番くわしい」と語った。
内製化で経験したことその2は、「コントロール可能な領域の拡大」だ。不具合の修正やパフォーマンスがい出なときなどに、メーカーなどに送付して改修を依頼すると、原因・影響調査や修正などはメーカー対応になる。そのため、自分たちのコントロール外となる。
これに対して、事象の根本原因より直接原因をメーカーに伝えることにより、将棋の例でいう「1手前で何が起きたか」を伝えるようにすることを飛岡氏は紹介した。そして、自分たちが現場で実施する内容を少しずつ増やすことで、コントロール可能な領域が少しずつ拡大すると語った。
内製化で経験したことその3は、「より楽しいエンジニアリング」だ。これまでの開発・試験ではブラックボックスだったものを、ホワイトボックス化する。それにより自分たちでコントロール可能な範囲を増やし、自分たちで問題解決できる楽しさを飛岡氏は挙げ、「エンジニアのモチベーションとしてあるべき道ではないかと思う」と語った。
ヤフーのIaaSチームにおけるCloudNativeとDevOps
セッション「「CloudNative」の前に考えたい「DevOps」の話」では、ヤフー株式会社の奥村司氏（テクノロジーグループ システム統括本部 クラウドプラットフォーム本部 技術1部）が、CloudNativeとDevOpsについて語った。前半は両者の関係について論じ、後半はヤフーのIaaSチームにおけるDevOpsの実践を紹介した。
まずはCloudNativeとDevOpsについて。
奥村氏は、CloudNativeによってもたらされる能力は、ある思想を実現する手段であり、目的ではなとい語った。そして、自分が使うツールがどういう思想で何を目的として作られたのかを正しく理解してツールを利用する必要があり、その思想と目的がDevOpsだと述べた。
DevOpsについて奥村氏は「ITバリューストリームの品質向上に寄与する文化運動」という解釈を語った。あくまでも重要なのは人や組織文化であって、ツールやプロセスはこれらがあって初めて価値を生み出すことができるという。
そして、DevOpsの3つの原則として「ITバリューチェーンの早く確実な実行」「システムの問題をすばやくフィードバック」「実践と学習の反復」を挙げた。
ここで奥村氏は、CloudNativeなシステムやその運用で使用される代表的なソフトウェアを挙げ、「これらのソフトウェアは共通して、“DevOpsの3原則のいずれかがより効率的に実践できるようにデザインされている”という特徴がある」と指摘。「CloudNative化しようと決めたら、仮想化のツールの前に、DevOpsを理解する必要がある」と語った。
続いて、ヤフーのIaaSチームにおけるDevOpsの実践の話だ。
Practice.1は「実践と学習の反復」だ。IaaSチームは、機能ごとに分割された複数のチームからなるが、タスクはチームではなく個人へ割り当てられるという。つまり、機能横断組織ではなく、個人に機能横断なタスクが割り当てられるという形だ。これにより、仕組みとしてサイロ化が抑制されているという。
このIaaSチームでは、ほとんどのメンバーがアラート／問い合わせ対応を当番制で担当し、付随する後続の対応も1人で担当する。これにより「反復的な実践と学習」「学びと発見」につなげているという。
Practice. 2は「ITバリューチェーンのすばやい実行」だ。言い換えると「とにかく早くデプロイしたい」となる。そのためには、承認フローと自動化が鍵となる。
まず、承認完了からデプロイ完了までの時間を短くしても、承認の時間が長くなるとデプロイに時間がかかってしまう。そのため、承認フローを合理化する必要がある。
具体的には、安全に寄与しない承認や確認は排除すべきであること、合意形成のシステム化が重要であること、事故再発防止のための承認の追加などは逆行なので行わないことを奥村氏は語った。
一方自動化については、自動化は事故の可能性があって危険で、メリットよりコストが高いという考えを奥村氏は誤解とする。そして、自動化は作業をやればやるほど安全になっていくのに対して、人間は作業をやればやるほど事故のリスクは高まるという特性は語った。
