Ericssonにおけるテレコムソフトウェアの継続的デリバリー

近年、テレコム業界は、DevOpsの原則とツールの導入により、サービスデリバリープロセスを変えている。ロンドンで開催されたDevOps Enterprise Summit 2017におけるEricssonの講演、ならびに、彼らの継続的デリバリーに関するペーパーは、彼らが直面した課題とその克服方法について説明している。

テレコムシステムベンダーがシステムをデプロイする際に直面しているハードルは、そのスケール、規制上の制約、堅牢性、可用性の要件という点で、独特だ。Ericssonは、テストに7週、デプロイに6ヶ月、開発に2、3年というモデルから、テストに90分、デプロイに3週、開発に6週というサイクルのモデルに移行した。テレコムソフトウェアの新しいリリースは、複数のネットワーク事業者に展開される。新しいプラクティスを導入した当初は問題もあったが、時が経つにつれて改善した。一般向けリリース公開と事業者ノードへの展開との間の時間は、徐々に削減された。フィーチャーリリースは毎月だが、ネットワーク事業者は、毎月もしくは四半期ごとにデプロイすることを選択できる。

画像使用許可 - http://cloudpages.ericsson.com/continuous-delivery

最初に変えたのは開発モデルだった。複数の並列したリリースチェーンから、シングルトラックへと変更した。この変更を導入した最初の製品は、Serving GPRS Support Node – Mobility Management Entityソフトウェア (SGSN-MME) で、その後、Evolved Packet Gateway製品が続いた。Evolved Packet Coreというのは、4Gネットワーク上で音声とデータの統合サービスを提供するための通信フレームワークだ。データと音声に、それぞれパケット交換、回線交換という別方式を使うものとは異なっている。

変革は2009年に開始された。まずはプロセス変更が行われ、小さな職務横断型のチーム、プロダクトオーナーのアサイン、スクラムマスターの導入がなされた。そして、リーンプロセスが導入された。有効性を評価するため、彼らはコードのコミット頻度などのメトリクスを計測した。ところが、これはメトリクスの誤用を招いた。いくつかの変更が有望だとわかると、チーム数を増やすという上からのプレッシャーがあった。このことは、チームの急増、必要なプラットフォーム変更の過小評価など、さらなる問題を招くことになった。クラウドレディであればこの点で貢献してくれただろうが、彼らのプラットフォームはそうではなかった。開発環境とCI（継続的インテグレーション）プラクティスも未熟で、未熟なプログラム構造とあいまって、チームの進捗はよく見えなくなっていた。チームの合計ベロシティは以前よりも低下した。2015年の棚卸しで、こうした問題が明らかになった。

問題を解決するため、いくつかの変更が行われた。スピードよりも品質を優先し、品質受け入れテストに焦点が当てられた。新しいプロセスが新しいチームとメンバーに導入された。ツール面では、チームはKVM（Kernel Virtual Machine）を用いた仮想化を利用するようになった。これにより、アップグレード時間は22時間から3時間に短縮された。KVMは、Linuxカーネル内でハイパーバイザーとして動作するフレームワークで、Ericssonのクラウドプラットフォームの重要な部分になっている。Dockerベースのものとともに、継続的インテグレーションフレームワークが導入された。要求に応じてリソースを割り当てる、集中型のハードウェア割り当てモデルが導入された。これにより、管理が簡単になり、ハードウェア全体の利用効率は高まった。組織的な変更には、プロジェクトマネジメントプラクティス、計画の改善、フィーチャーチーム、デイリーのスタンドアップミーティング、知識共有のためのコーチング（メンタリング）ネットワークなどが含まれる。

CDモデルは、他のEricsson製品にも導入されている。これはテレコム業界における大きなトレンドの一部だ。従来のサービスデリバリープラクティスは、DevOpsに取って代わられた。これまでハードウェアベースだったネットワークサービス機能のソフトウェア仮想化（NFV）も、このトレンドを促進している。ますます多くの機能がソフトウェア実装へと移行しており、おかげで、DevOpsのツールとプラクティスは導入しやすくなってきている。