仮想化と柔軟なライセンス体系がCSGの大規模なモダナイゼーションを後押し

ほとんどの企業が、オンプレミスからクラウドへ、物理環境から仮想環境へと、IT運用の変革を進めています。さらに、COVID-19の発生を受け、ほぼすべての企業がモダナイゼーションの取り組みを加速させています。

通信・ケーブル業界向けに顧客エンゲージメントサービスを35年にわたり提供してきたCSGも、その一例です。同社は北米最大手のケーブル事業者に、顧客関係、請求、業務をより効率的に管理するためのデジタルソリューションを提供しています。

数年前、CSGは旧態化したプロセスの制約に加え、新たなアプリケーションオーナーの関与不足にも直面し、業務に大きな負荷がかかっていました。CSGがお客さまのモダナイゼーションを支援しているように、自社の業務も進化させる時期を迎えていました。

CSGのソフトウェアエンジニアリング担当バイスプレジデントであるErica Morrison氏は、それまでソフトウェア分野でしか業務経験がなかったにもかかわらず、CSGのOperational EngineeringチームによるDevOps組織と文化の確立を支援する任務を担いました。

「開発者が突然運用の世界に放り込まれ、運用チームが直面する課題を目の当たりにするのは、大きな衝撃です」と彼女は語ります。「この経験を通じて、当社のすべての運用チームが担っている仕事への理解と感謝が、間違いなく深まりました」

従来は運用のみを担っていたチームに開発のベストプラクティスを導入したことで、CSGはさまざまな課題に取り組める体制を整えました。これには、これまで利用していなかったF5の機能の活用、新しいツールの追加、必要な柔軟性をもたらすエンタープライズライセンス契約の採用が含まれます。

数々の課題

当時、Erin Garrigan氏はチームのスクラムマスターを務めていました。現在はスーパーバイザーを務める同氏が振り返る複数の取り組みは、2016年当時にCSGが5年、さらには10年かかると想定していた計画に相当するものでした。

「技術的な観点では、変更に伴う手作業のプロセスが多すぎたうえ、誰が何をしているのかを十分に把握できていませんでした」と彼女は語ります。「さまざまなチームが当社のデバイスにアクセスできる状態でしたが、それを適切に管理するために必要な堅牢な制御が整っていませんでした」

問題はこれだけではありませんでした。インフラストラクチャ全体が不安定なうえ、全般的な稼働状況の監視とアラート機能が不足していたため、クライアントから問題の報告を受けるまで、デバイスの状態が悪化していることにチームが気付かないケースも少なくありませんでした。ハードウェアのモダナイゼーションも重要な課題でした。

Infrastructure as Codeによる変革

チームが最初に取り組んだ最大のプロジェクトは、F5 iAppsを使用してすべてをソースコード化することでした。CSGのプロセスは手作業だったため、まずデバイス構成を毎晩エクスポートする仕組みを導入し、構成を可視化しました。最終的には、ソースコードによってデバイス上の構成を管理する新たなパラダイムへと移行しました。

「手作業による変更とInfrastructure as Codeの考え方を基に、1年以内に100を超えるiAppsを作成しました」とGarrigan氏は述べています。「手作業で行っていたすべての設定をiAppsとしてコード化するには膨大な労力が必要でしたが、いくつかのツールを作成し、時間をかけて取り組みました」

インフラストラクチャをコードとして定義したことで、チームはアプリケーションの機能を分離できるようになりました。運用エンジニアリング部門は、1日に複数の変更リクエストが寄せられる動的なサーバー環境で、数十のアプリケーションチームを支援しています。セルフサービスプロセスを導入したことで、CSGのアプリケーションチームの社内ユーザーは、サンドボックス環境のBIG-IPデバイスを使用して変更を設定・確認し、検証とコードレビューのためにパイプラインへ送信できるようになりました。また、ユーザー自身が変更を本番環境に反映できる別のツールも作成しました。

「その時点で、私たちは実質的に、ロードバランシングとアプリケーションデリバリーをサービスとして提供していました」と、CSGのソフトウェア開発担当ディレクターであるPhil Todd氏は述べています。「自動化されたセルフサービス機能の大半とレポート機能には、Jenkinsを使用しています。また、その機能をバックエンドで実装するために、独自のC#コードも作成しました」

BIG-IQによる可視化と変更管理

CSGが運用する大規模かつ多様なアプリケーション群では、こうした変更を可視化することも重要な要件でした。以前の手作業による環境では、アプリケーションチーム間で変更が重複し、互いの作業に影響を及ぼす可能性がありました。そのため、問題のあるコードの特定が必要以上に複雑になっていました。

「環境内で何かがおかしくなっていることは分かっても、なぜそうなったのかは分からず、誰かが何かをしたに違いないとしか言えませんでした」とGarrigan氏は語ります。

手作業のプロセスでは、問題が特定された後、その全容を把握するために、変更を行った担当者を突き止めなければならないことも少なくありませんでした。

この問題を解決するため、チームはF5 BIG-IQを導入し、変更プロセス自体の改革に着手しました。システムの健全性と変更による全体的な影響を把握するため、自動レポートも導入しました。また、変更の検証を支援するため、1,000を超えるエンドポイントを監視するGrafanaダッシュボードを作成しました。構成をコード化し、デプロイを自動化したことで、CSGは実施されたすべての変更を明確に把握できるようになりました。

Todd氏によると、これにより、現在のCSGの環境と従来の手動プロセスとの間に大きな違いが生まれました。変更によって問題が発生した場合、以前はチームが問題を調査して解決するまでに数時間かかることもありましたが、現在では平均修復時間を数分に短縮できるようになりました。

「Kibanaにログインすると、デプロイされたバージョンやその前のバージョンなど、すべての変更が記録されています」とTodd氏は話します。「そのため、動作しない原因を延々と考えることなく、Jenkinsでボタンを押すだけで、以前のバージョンのコードをデプロイできます」

仮想化が鍵

次の進化では、インフラストラクチャの拡張性、柔軟性、安定性への対応が課題となりました。F5 VIPRIONSを含む数十台の物理ハードウェアデバイスを運用していたものの、アプリケーショントラフィックの大半は、インターネットからの外部トラフィック用と内部トラフィック用のわずか2台を経由していました。

その結果、グループの規模が大きくなり、障害発生時に組織が直面するリスクも増大しました。Todd氏は、「これらのデバイスのいずれかが停止すると、実質的にすべての製品とすべてのお客さまに影響が及びました」と述べています。

同時に、CSGのアプリケーションは社内のプライベートクラウドやパブリッククラウドへの移行を開始していました。しかし、このシステムはそうした環境への拡張性が限られており、AWSへの移行にも対応していませんでした。

こうした課題への対応にも、仮想化が大きな役割を果たしました。iAppsでインフラストラクチャをコードとして管理することで、障害グループ全体の規模を縮小できる柔軟性が得られ、アプリケーションごとに最適化したロードバランシングを実現できました。また、必要に応じて最終的にパブリッククラウドへ移行する道も開かれました。

「最近、障害が発生しましたが、影響を受けたのは1つの製品だけでした」とMorrison氏は述べています。「1年余り前であれば、すべての製品に影響が及んでいたでしょう。より多くのインスタンスを小規模なグループに分割したことで、必要に応じてフェイルオーバーできるようになり、影響範囲もごく小さく抑えられています。安定性への投資は、社内外のお客さまにすでに良い成果をもたらしています」

エンタープライズライセンスが必要な柔軟性を実現

CSGは、F5 BIG-IP Virtual Editionsから新しいF5エンタープライズライセンス契約（ELA）に移行することで、運用の柔軟性をさらに高め、コストを削減しました。以前は、主にオマハ本社の1つのデータセンター内で業務を行っていました。災害復旧ソリューションは、必要な事態が発生した場合に、サードパーティのデータセンターでサービスを立ち上げるというシンプルなものでした。

数年前にチームが2つ目のデータセンターを構築したことで、データセンター間の高可用性を検討できる体制が整いました。しかし、従来のライセンス契約と物理ハードウェアによって、選択肢は限られていました。固定構成のハードウェアでは、スケーラビリティ、可用性、パブリッククラウドへの拡張性に課題がありました。

「F5のエンタープライズライセンス契約と仮想ソリューションに移行したことで、必要なものを必要なときに立ち上げ、第2のデータセンターを追加できる柔軟性が得られました」とTodd氏は語ります。「さらに、さまざまな可能性を検討し、社内のお客さまのニーズに迅速に対応できるようになりました」

現在、チームはさまざまなサービスを柔軟に進化させ、高可用性を実現できるようになりました。

今後の展望：クラウドでのアプリケーションデリバリ

環境のモダナイゼーションを終えたCSGのオペレーションエンジニアリングチームは、将来に向けた計画を立てる余裕が生まれました。同チームは、F5のセキュリティ機能をさらに活用し、BIG-IPとAmazon Web Services（AWS）を使用するためのリファレンスアーキテクチャを策定するとともに、NGINXで新たな機能を導入したいと考えています。また、ELAにより、既存の予算を新しいアーキテクチャや機能セットに振り向けることができました。

Morrison氏は、これまでの成果をさらに発展させるため、CSGのプロダクトオーナーとともに新たなロードマップの策定にも取り組んでいます。具体的には、システムの監視とアラートの改善、新たなモニターの追加、アプリケーションデリバリに関するセンターオブエクセレンスモデルの構築を進めています。

全体像という観点では、望ましい段階に到達したとMorrison氏は語ります。現時点で、チームは当初の5カ年構想に盛り込まれたプロジェクトのほぼすべてを実現しています。これまでに構築したパートナーシップ、セルフサービス機能、構成を基盤として、残るのはアプリの管理権限を各アプリチームにさらに移管することです。

「『次に何をすべきか』を初めて考えられる段階に来ました」と彼女は語ります。「大きな進展を遂げ、もはや目の前の問題への対応に追われる状況ではありません。今後は、これまで築いてきた強固な基盤を生かし、先を見据えて取り組んでいくことが重要です」