ほとんどの企業は、オンプレミスからクラウドへ、物理から仮想へと IT 運用を変革している最中です。 そして、COVID-19の発生により、ほぼすべての企業が近代化の取り組みを加速させています。
通信およびケーブル業界向けに顧客エンゲージメント サービスを提供する 35 年の歴史を持つ CSG もその 1 つです。 同社は、北米最大手のケーブルプロバイダーにデジタルソリューションを提供し、顧客関係、請求、運用をより効率的に管理します。
数年前、CSG は老朽化したプロセスの制限に苦しみ、さらに新しいアプリケーション所有者の関与も不足していました。 CSG が顧客の近代化を支援するのと同じように、自社の業務を進化させる時期が来ていました。
CSG のソフトウェア エンジニアリング担当副社長 Erica Morrison 氏は、これまで社内のソフトウェア部門でのみ勤務していたにもかかわらず、CSG の運用エンジニアリング チームが DevOps 組織と文化を確立できるよう支援する任務を負っていました。
「開発者にとって、突然運用の世界に放り込まれ、直面する課題を目の当たりにするのは、システムにとって衝撃的なことです」と彼女は言います。 「これにより、当社のすべての運用チームの仕事に対する感謝の気持ちがさらに高まりました。」
従来は運用のみを担当していたチームに開発のベスト プラクティスを導入することで、CSG は、これまで使用していなかった F5 の機能を活用し、新しいツールを追加し、必要な柔軟性を提供するエンタープライズ ライセンス契約を採用するなど、さまざまな課題に取り組むことができました。
当時、チームのスクラムマスターはエリン・ギャリガンでした。 現在スーパーバイザーを務める彼女は、2016 年に CSG が 5 年計画、あるいは 10 年計画として構想した内容を実現したいくつかの取り組みについて語ります。
「技術的な観点から言えば、変更に関して手動のプロセスが多すぎて、誰が何を行っているかが十分に把握できていませんでした」と彼女は言います。 「さまざまなチームが当社のデバイスにアクセスしていたため、それに関して必要な堅牢な制御がありませんでした。」
問題はこれだけではありません。 インフラストラクチャ全体に不安定さがあり、全体的な健全性の監視とアラートが不足していたため、チームはクライアントから問題について聞くまで、デバイスの状態が悪いことに気付かないことがよくありました。 ハードウェアの近代化ももう一つの重要な懸念事項でした。
チームの最初の、そして最大のプロジェクトは、F5 iApps を使用してすべてをソース コードに取り込むことでした。 CSG のプロセスは手動で行われていたため、まずはデバイス構成の夜間エクスポートを導入し、チームが構成を可視化できるようにしました。最終的には、ソース コードがデバイス上のものを駆動するという新しいパラダイムに進みました。
「1 年以内に、手動による変更とインフラストラクチャ・アズ・コードの概念から 100 を超える iApp を作成しました」と Garrigan 氏は言います。 「すべての手動設定を iApps にコード化するには膨大な労力が必要でしたが、私たちはツールを作成し、時間をかけて取り組みました。」
インフラストラクチャがコードとして定義されたため、チームはアプリの機能を分割できるようになりました。 運用エンジニアリングは、1 日に複数の変更要求を受信する動的なサーバー環境で、数十のアプリケーション チームをサポートします。 セルフサービス プロセスを実装することで、CSG のアプリケーション チームの内部コンシューマーはサンドボックス BIG-IP デバイスを使用して変更を構成し、確認し、検証とコード レビューのためにパイプラインにプッシュできるようになりました。 また、ユーザーが変更を本番環境に自分でプッシュできるようにする別のツールも作成しました。
「その時点で、私たちは実際に負荷分散とアプリケーション配信をサービスとして提供していました」と、CSG のソフトウェア開発ディレクターの Phil Todd 氏は言います。 「当社では、自動化セルフサービス機能のほとんどとレポート機能の駆動に Jenkins を使用しています。 そして、その機能を舞台裏で実装するために、独自の C# コードをいくつか作成しました。」
こうした変更に対する可視性を高めることは、CSG の大規模で多様なアプリケーション セット全体にわたって重要なニーズでした。 以前は手動で行われていたため、アプリケーション チームは変更が重複して発生し、お互いに干渉し合う可能性がありました。 不正なコードを見つけることは、必要以上に複雑なパズルでした。
「環境に何か変なものが生まれるだけだ」とギャリガン氏は言う。 「なぜ不具合が生じたのかは分かりませんが、誰かが何かをしたに違いないということだけは分かります。」
また、手動のプロセスでは、問題が特定されると、チームは変更を行った個人を追跡して、その問題を完全に理解する必要があることもよくありました。
この問題を解決するために、チームは F5 BIG-IQ を実装し、変更プロセス自体の変更を開始し、システムの健全性と変更の全体的な影響に関する自動レポートを導入しました。 また、変更の検証をサポートするために、1,000 を超えるエンドポイントを監視する Grafana ダッシュボードも作成しました。 構成がコードとして作成され、デプロイメントを中心に自動化が構築されたことで、CSG は行われたすべての変更を実際に把握できるようになりました。
Todd 氏によると、これが CSG の現在の環境と過去の手動プロセスとの最大の違いの 1 つにつながったそうです。変更によって何かが壊れても、以前はチームが問題を調査して解決するまでに何時間もかかっていたのが、今では修復にかかる平均時間は数分で済むようになりました。
「Kibana にログインすると、デプロイされたバージョンや以前のバージョンなど、すべての変更が記録されます」と彼は言います。 「ですから、なぜ動作しないのかと悩む必要はなく、Jenkins のボタンを押すだけで、以前のバージョンのコードがデプロイされるのです。」
次の進化は、インフラストラクチャのスケーラビリティ、柔軟性、安定性に対処することでした。 F5 VIPRIONS を含む数十台の物理ハードウェア デバイスを実行していましたが、アプリケーションの大部分は、インターネットからの外部トラフィック用と内部トラフィック用の 2 つのデバイスのみを経由していました。
その結果、グループの規模が大きくなり、障害が発生した場合に組織にとってより大きなリスクが生じました。 「これらのデバイスの 1 つがダウンすると、基本的にすべての製品とすべての顧客に影響が及びます」とトッド氏は言います。
同時に、CSG のアプリケーションは同社のプライベートクラウドとパブリッククラウドに移行し始めていましたが、それらの環境への拡張に関してはシステムの能力が限られており、AWS への移行は許可されていませんでした。
仮想化はこれらの問題の解決にも役立ちました。 iApps にインフラストラクチャをコードとして組み込むことで、全体的な障害グループのサイズを縮小する柔軟性が得られ、よりアプリケーション固有の負荷分散を確立できるようになりました。 また、必要に応じて最終的にパブリック クラウドに進化する道も開かれました。
「最近、システム障害が発生し、ある製品に影響が出ました」とモリソン氏は言う。 「1年ちょっと前であれば、すべての製品に影響があったでしょう。 より多くのインスタンスをより小さなグループに分割することで、必要に応じてフェイルオーバーする機能も備わり、その影響範囲は非常に小さくなります。 そのため、安定性への投資は、すでに社内外の顧客にとって良いニュースをもたらしています。」
CSG は、F5 BIG-IP Virtual Editions から新しい F5 エンタープライズ ライセンス契約 (ELA) に移行することで、運用の柔軟性がさらに高まり、コストも削減されました。 以前、このグループは主に同社のオマハ本社の 1 つのデータセンター内で機能していました。 同社の災害復旧ソリューションは、必要になった場合にサードパーティのデータセンターでサービスを立ち上げるだけのものでした。
チームが数年前に 2 番目のデータ センターを構築したとき、それらのデータ センター全体で高可用性を模索する立場にありました。しかし、以前のライセンス契約と物理ハードウェアによって選択肢が制限されていました。 固定ハードウェアでは、同社はスケーラビリティ、可用性、パブリック クラウドへの拡張能力に関する課題に直面していました。
「F5 エンタープライズ ライセンス契約と仮想ソリューションに移行したことで、必要なときに必要なものを自由に立ち上げ、第 2 データ センターを追加できるようになりました」と Todd 氏は言います。 「これにより、社内の顧客のニーズを探求し、それに迅速に対応する自由が与えられました。」
現在、チームはより柔軟に進化し、さまざまなサービスの高可用性を実現しています。
環境を最新化したことで、CSG の運用エンジニアリング チームには将来に向けた計画を立てる余裕が生まれました。 チームは、セキュリティに関する F5 の機能をさらに活用し、BIG-IP と Amazon Web Services (AWS) を使用するためのリファレンス アーキテクチャをまとめ、NGINX で新しい機能を導入したいと考えています。また、ELA により、既存の予算を新しいアーキテクチャと機能セットにシフトすることができました。
モリソン氏はまた、CSG の製品オーナーと協力して、これまでの成果を基に、システムの監視とアラートの改善、新しいモニターの追加、アプリケーション配信のためのセンター オブ エクセレンス モデルの開発など、新しいロードマップの作成に取り組んでいます。
全体的な視点から見ると、ここは居心地のよい場所だと彼女は言う。 この時点で、チームは当初の 5 年間のビジョンのほぼすべてのプロジェクトを実現しました。 これまでに構築したパートナーシップ、セルフサービス機能、構成があれば、あとはアプリの所有権をアプリ チーム自身に引き渡すだけです。
「私たちは初めて、次に何をすべきか考えています」と彼女は言う。 「私たちは大きな進歩を遂げたので、もはや自分たちで脱出する必要はありません。 今は積極的に行動し、これまで築いてきた強固な基盤の上にさらに踏み込んでいくことが重要です。」