APIは、日本政府が推進するキャッシュレス決済をも支える中核仕様の一つにもなっており、現在のアプリケーションアーキテクチャの重要なコンポーネントのひとつになっています。そして、多くのシステム開発者がアプリケーション毎に平均10～15個のAPIを使用していると推測されています。これらのAPI中心のアプリケーションがクラウドに移行し分散するにつれて、様々なサービスを提供するプロバイダーやインターネットなどの外部環境への依存度は増大し、アプリケーションパフォーマンスとエンドユーザーの体感品質の管理を担当するITチームにとって大きな課題となりつつあります。この断片化されたエコシステムの中で、顧客の体感品質を見失うことなく、アプリケーションのパフォーマンスとAPIの依存関係をどのように監視できるでしょうか？
このブログでは、現代のアプリアーキテクチャの変化が、マルチクラウド環境でのアプリケーションパフォーマンスにどのように影響を与えるかを掘り下げ、これら外部リソース間の依存関係を監視する方法を説明します。
マルチクラウド：API主導型の現実
インターネットを介して複数のクラウドを横断するAPIコールは、アプリケーションのパフォーマンスに大きな影響を与える新たな要素となっています。そもそもインターネットは、SLAが求められる企業通信用に構築されたものではなく、ベストエフォート型のネットワークであり、脆弱で不安定な側面を持っています。 2017年、インターネット協会は14,000件を超えるルーティングエラーと障害があったと報告しています。このようにクラウドベースおよびAPI主導型のアーキテクチャを備えた外部環境への依存度が高まっているため、クラウド環境の監視がこれまで以上に困難になっています。
クラウドプロバイダが提供する監視ツールの使い心地はいかがですか？
CloudWatchなどのモニタリングツールは、ログ、評価基準データ、各種イベントを通じて運用データとモニタリングデータの提供に優れています。 一方、AWSリソースのパフォーマンスを示す統一されたビューは提供されますが、ユーザー視点のエンドツーエンドのパフォーマンスビューはありません。 さらにCloudWatchは、インターネットやクラウドのネットワークパフォーマンス、あるいはマルチクラウド間のネットワークパスの可視化ができないため、必要とされるマルチレイヤ監視の機能に重大なギャップが生じます。さらに、クラウドプロバイダーが提供する監視サービスに依存した場合、プロバイダ自体の稼働率も一般的な懸念事項となります。たとえば、クラウドプロバイダー自身で障害が発生した場合、そこでホストされている監視サービスも停止する可能性があります。例えば、2017年に内部エラーが原因でAWS S3が停止したケースでも監視サービスに影響を与え、企業は状況を把握することができませんでした。
クラウド型BIダッシュボード「GoodData」：API接続の問題例
AWS上のアプリケーションが、RackspaceにホストされているGoodDataと呼ばれる外部BIプラットフォームとやり取りするシナリオを見てみましょう。次の例では、監視ポイントとなるエージェントが、グローバルに展開されたAWSリージョン内の複数のVPCで稼働しており、これにより、アクセス元の視点から外部APIの可用性とパフォーマンスを監視できます。
午前7時40分(PST)、AWSからみた外部APIエンドポイントの可用性が低下していることがわかります。マップビューは、この可用性の低下が特定のAWSリージョンからのアクセスのみで発生しているのではなく、グローバルな影響があることを示唆しています。 HTTP接続フェーズの内訳は、APIエンドポイントに接続できないことからSSLの問題まで、エラーの組み合わせを示しています。 ここでHTTPフェーズの接続エラーは、これが根本的なネットワークの問題である可能性を示しています。では、この仮説を検証するために、ネットワークレイヤをみてみましょう。
ネットワークレイヤを確認すると、同一時刻でのエンドツーエンドのパケットロスが52％に急上昇していたことがわかります。
ネットワークパスの可視化（図4）によるエンドツーエンドパスの詳細から、GoodDataのAPIエンドポイントがホストされているRackspace内で高いパケットロスがあったことがわかりました。一方、AWS内のネットワークパスと、AWSとRackspaceを接続するインターネットパスには、ネットワークのパケットロスや高遅延は見られませんでした。
この特定のシナリオでは、図4に示すように、問題がAWSあるいはインターネットではなく、GoodDataのホスティングプロバイダーであるRackspace内にあったということがわかりました。ただし過去には、クラウドプロバイダーやアップストリームのISP内の障害がアプリケーション停止の原因となった事象もあるので、常に同様のケースが当てはまるわけではありません。また、ハイブリッドクラウドやマルチクラウドなどの分散環境では、問題の場所を把握することが非常に難しい場合があります。
クラウドが新しいデータセンターとなり、インターネット（あるいはクラウドプロバイダーのバックボーン）が次世代の企業ネットワークとなりゆく今日の企業IT環境では、これらのインフラを自社システムであるかのように監視・管理できることが非常に重要です。 ThousandEyesは、顧客や従業員のワークロードがプライベートネットワークからインターネットを介したクラウドプロバイダーネットワークまで、アプリケーションとサービスにどのように到達し、体験するかをリアルタイムで可視化します。
AWSからAPIエンドポイントとマルチクラウドパスを監視する方法
ThousandEyes のEnterprise エージェントをクラウドプロバイダーネットワーク内に展開し、外部APIおよびマルチクラウド間の相互接続とその通信パスを可視化できます。さまざまなシステム環境（物理/仮想アプライアンス、ドッカー、Linuxパッケージなど）で利用可能なEnterpriseエージェントをクラウド環境内に展開すると、アプリケーションとマイクロサービスの監視が可能になります。これらのエージェントは、AWS内に単純なEC2インスタンスとしてインストールでき、ごくわずかなリソースで利用が可能です。たとえば、Enterprise エージェントは、VPC内に2 vCPUと4GBのRAMを持つt2.mediumインスタンスとしてインストールできます。さらに、事前に定義および設定されたAWS CloudFormationテンプレートの活用により、簡単にエージェントを起動して実行することができ、展開が非常に楽になります。それぞれの手順については、ThousandEyesのオンラインガイドを参照してください。
EnterpriseエージェントはVPCの「内部」からの可視性を提供する一方、ThousandEyes のCloudエージェントは「外部」からの可視性を提供し、顧客のアプリケーションへの接続を可視化します。 Cloudエージェントは世界中のTier 2およびTier 3 ISPおよびモバイルプロバイダーにインストールされており、AWSリージョンのパフォーマンスも監視できます。
新しい攻めのアプローチ
クラウドプロバイダが提供する監視ツールでは、プロバイダー自身のネットワーク以外は監視対象とならないため、特にAPI通信によるエコシステムを多用するアプリケーションの監視には積極的なアプローチが必要となります。なぜなら、マルチクラウド環境とベストエフォート型のインターネットに依存する環境では、急速に変化するパフォーマンス基準値（ベースライン）や、自らが制御できないネットワークやアプリケーションの変化を考慮しなければならないからです。
ThousandEyesは、下記の通り監視への継続的なライフサイクルアプローチを推奨しています。
- データ手動型のアプローチの採用により、本番展開前のAPIを多用するアプリケーションを監視することで準備を整えます。 AtlassianやIntuitのようなお客様がThousandEyesを使用して、AWSおよびハイブリッドクラウド環境を監視し、準備フェーズでの可視化を活用しています。
- 本番展開の明確な成功基準を確立し、DevOpsおよびITチームに新しいエスカレーションプロセスを構築します。チームは、エンドユーザーのアプリーケーションレベルの体感品質を重視して運用します。
- アプリのパフォーマンスの監視とベンチマークを継続し、エンドユーザー視点での監視により、問題を先取りし、優れたユーザーエクスペリエンスを確保します。
ThousandEyesの無料トライアルでビジネスクリティカルなAPIベースのアプリケーションの監視を今すぐ開始し、マルチクラウド導入を成功させましょう。