TPG Telecom: Apigee を使用して API の配信時間を 50% 短縮

※この投稿は米国時間 2024 年 3 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

TPG Telecom は、大規模な合併および買収（M&A）と有機的成長に基づいた戦略を掲げるオーストラリア通信業界の新星です。Vodafone、TPG、iiNet、AAPT などのブランドを擁する TPG は、広範なモバイルおよびファイバー ネットワークを通じて 500 万人のモバイル ユーザーと 220 万人の固定ブロードバンド利用者に各種サービスを提供しています。

API は 3 つの意味で TPG のビジネスに不可欠です。顧客体験の観点からは、顧客関連のサービスを中心に統合型 API が運用されています。また、ネットワークや支払い関連のサービスにも API が使用されています。M&A ベースの成長戦略を採用している TPG では、API 機能を備えた複数の技術スタックとシステムを運用しなければなりませんでした。クロスセルを通じて既存のビジネスと買収後のビジネスのメリットを実現するなど、さまざまな理由から最新の API 管理プラットフォームに移行する必要があったのです。TPG は複数の顧客管理（CRM）システムや課金システムを通じて、モバイル、固定ブロードバンド、ワイヤレスの利用者を支援しており、こうしたシステムは、さまざまな形式とプロトコルで API を提供しています。そのため、多様な API 配信プラットフォームのサポートと API 全体の可視性は TPG にとってなくてはならないものです。API ゲートウェイとして Apigee を使用することで、TPG は一貫した形式で API をデジタル消費者システムに公開しています。こうしたデジタル システムのおかげで、複数の API プロトコルをサポートする複雑な仕組みの実装に煩わされることなくデジタル体験の充実に集中することができ、さまざまなバックエンド システムへの統合も容易になります。

TPG では API ガバナンスが重要な要素になっています。これは、利用された API から得られるフィードバックに基づいて API がどのように利用され、それがどのようなパフォーマンスを示しているかを理解し、API の利用体験を継続的に向上させる必要があるためです。API 関連の指標を使用してアラームをトリガーすることで、ダウンストリーム システムの問題を事前に特定して解決することが可能になりました。

TPG は、より広範なビジネスの方向性に合わせて、主にオンプレミスの API 管理ソリューションで賄っていた要素を分散型のクラウドネイティブ プラットフォームに置き換えたいと考えていました。また、シームレスかつ一貫した方法で API を配信できるように、アウトソーシングされた多様な開発モデルから、アジャイルで集中型の DevSecOps に移行することも模索していました。

さまざまな言語またはフレームワークで API を構築し、ユーザー向けの機能を一貫して公開できるソリューションを提供している別のクラウド プロバイダとの連携を求めていました。さまざまなバックエンドの統合をサポートするとともに、優先パートナーのランタイムを確保しながら、TPG のオンプレミス サービスとパートナーのクラウド サービスにおけるアカウント間のシームレスな統合を進めなければなりません。さらに、可視性を高めるために、すべての API を共通のガバナンス プラットフォーム下に置く必要がありました。

Apigee を選択した理由

複数の API 管理プラットフォームを評価したうえで、TPG は Apigee を選びました。Apigee は、直観的な設計と包括的な機能群によりマーケット リーダーの座を占めているという事実などの複数の理由から TPG に最適なサービスでした。Apigee のライセンス モデルを使用すれば、ライセンスにかかる費用をより適切に予測できるようにもなります。

また、API を公開して保護し、自動化された CI / CD パイプラインを有効にすることで、より迅速かつ効率的にデプロイするための労力が大幅に軽減されました。加えて、AI、Kubernetes、サービス メッシュなどのテクノロジーに対する Google Cloud の投資と習熟度、ビジネスに役立つ豊富なアプリケーションを備えたすべてのテクノロジーが TPG の選択を後押ししました。

さらに、Apigee は柔軟なデプロイ オプションを提供しているため、TPG は Apigee ハイブリッドを選ぶことにより、マルチクラウド環境とオンプレミス環境を横断したランタイムの統合を実現しました。Apigee のおかげで、ビジネス全体のすべての API に対して共通のガバナンス プラットフォームを確立できています。

2022 年末に最初の API セットを使用して Apigee を稼働させた TPG Telecom は、現在 6 つのプラットフォームを最大 300 の基盤システムに接続すべく数年にわたる取り組みを進めています。TPG は、社内外の利用者に向けて自らが公開した API を使用するという経験を一貫して積んできました。さらに、Apigee プラットフォームに組み込まれたセキュリティ機能を通じて、使用される API に脆弱性がないことを保証するとともに、パフォーマンスや可用性の問題を検出できるよう、リアルタイムのモニタリングを実施しています。その結果、統合を大幅に加速できました。

Apigee の使用を一元的に進めるのではなく、社内での価値の実証に基づいて TPG 全体での採用を拡大しています。別の言い方をすれば、API を Apigee にオンボーディングする機会を各チームと連携して模索しているということです。

下の図は TPG における現在の Apigee アーキテクチャの全体像と API を外部サービス プロバイダと統合する方途を示しています。

現在のアーキテクチャ - Apigee

API の可視性と重複の課題を克服する

Apigee は、ビジネスに API を活用するなかで直面するさまざまな課題の克服に役立ちます。たとえば、TPG では API とその使用量の可視性が限られていたため、ポリシーの作成が困難となり、脆弱性の修正が遅れて API のテストとリリースが減速し、ひいては市場投入までのペースが大幅に鈍化していました。さらに、ビジネス ユニット間の可視性が欠如していたために、API ベースのプロダクトやサービスの重複がさまざまなビジネスやブランドにわたって広範に認められました。API を公開する単一のプラットフォームがないため、外部の利用者が TPG のサービスを利用すると、API リクエストが複数の統合ポイントを通過することになり、応答時間が遅くなります。また、プロセスと実装ルールを標準化、明確化するための文書化アプローチを改善するとともに、ルール、パターン、統合スタイルに関連する API アーティファクトを保存するための統合リポジトリを提供する必要もありました。

Apigee と API Hub により、API を設計、公開するための一元的な場所を得ることができました。そこでは、文書化が尽くされており、明確な仕様を閲覧できます。また、複雑さを低減し、作成時間を短縮できるよう、今後は単一の API 形式に移行する予定です。

Apigee 以前、重複はセキュリティ制御にも広がっていました。API 利用者に抽象化レイヤを提供する統合型の API 管理体制および API ソリューションが欠けていたため、さまざまな侵入テストチームとセキュリティ チームを関与させたうえで、バックエンド システム、ネットワーク、顧客体験アプリケーションを個別にテストする必要があったのです。異なるプラットフォームに同じ制御を実装するのに必要な時間を短縮することが最優先事項でした。なぜなら、侵入テスト サイクルが 2 つのスプリントで実行されるからです。一つはアプリケーションのセキュリティ対策の推奨に関わるもので、もう一つはそれらの対策が実装されていることを確認するものでした。

今では Apigee の Advanced API Security を単一の制御プレーンとして使用して、公開されている数百の API 全体のセキュリティを管理しています。Apigee の Advanced API Security ソリューションによって提供されるセキュリティ制御の推奨事項と修復により、重要なセキュリティ制御を一貫して適用するプロセスも合理化できました。

Apigee の実装以前、API 管理の状況は断片的で複雑なものでした。複数のソリューションがあるため、CI / CD、オブザーバビリティ、ガバナンスなどのプラットフォーム エンジニアリング上のベスト プラクティスに投資することは困難でした。New Relic、Splunk などのサービスを通じてオブザーバビリティを実装することは叶わず、問題を特定して適切な担当者に対応を通知するためのアクティブなモニタリングも実施していませんでした。自動化された CI / CD がなければ、こうしたプラットフォームに手動の手順が多く含まれるビルドとデプロイのプロセスが必要となり、コードのバージョニングの維持と管理が容易ではなく、ソリューションの本番環境へのデプロイが数週間遅れたことも多々あります。

また、Apigee のおかげでロギングとモニタリングを標準化できたことで、すべての API が共通のパターンに従うことになり、Apigee ログが Splunk に送信されてプラットフォーム全体でオブザーバビリティを確保できます。現在は、システムにタイムアウトや遅延などの問題が発生しているかどうかを特定するためのアラートやモニタリング システムをいくつか構成しており、関連チームと迅速に連携してこうした問題を解決できるようになりました。

以前のプラットフォームでは、実行ロジックは API の開発とデプロイの間で密結合されていました。つまり、開発者は API サービスを外部の利用者に提供するまでに、かなりの量のビジネス ロジックを理解する必要があったのです。開発者に最新の情報を提供しなければならず、オーバーヘッドが不必要に増加していました。今では Apigee を使用することで、疎結合アーキテクチャを実装し、デプロイ、標準、ランタイムの運用に重点を置く一元的 API チームを組織して、開発関連のオーバーヘッドを削減し、リリース サイクルを加速させています。

Apigee を使用することで、TPG は API の標準化、セキュリティ、一貫した統合プロセスを実装できました。新しいスマートフォンの発売などの特別なイベントやプロモーションを計画するとき、TPG はリクエストの量と予想される発売関連のトラフィックを捕捉し、その他のビジネス指標を記録して、EKS クラスタの自動スケーリング特性を決定しています。Apigee ハイブリッドを使用すれば、パフォーマンスや可用性に影響が生じることなく、非常にうまくスケーリングができます。

API を本番環境に 2 倍の速さでオンボーディング

現在、統合、オブザーバビリティ、関連する自動化を含め、わずか 2 週間で API を本番環境にオンボーディングしています。以前の API 管理プラットフォームでは、これに最大 4 週間かかっていました。Apigee の Advanced API Security を使用すれば、侵入テストを実行する前に各 API のセキュリティ スコアを評価し、多くの問題を特定、修正できるため、基本的なセキュリティ制御で本番環境 API を保護できているという十分な確信が得られます。

TPG は現在、社内外の API 利用者向けに企業全体で Apigee の導入を推し進めるとともに、TPG Telecom 傘下のクロスセルやアップセルの機会を生み出す API の潜在可能性を具体的な形にしていく体制を整えています。

-TPG Telecom、インテグレーション、プラットフォーム エンジニアリング、自動化担当ドメイン マネージャー Nitin Nair 氏

-Google Cloud、Apigee 担当ソリューション エンジニアリング プリンシパル Ivan Niccolai