デジタルビジネスにおけるソフトウェアの構築と提供の方法は大きく変化しています。アプリケーションが社内ツールのみに依存していたのは過去の話です。今や、アプリケーションは外部のAPIやサードパーティのアプリケーションプロバイダーへの依存度を増しており、それがさらに他のAPIやアプリケーションにも依存しています。
このようなモジュラー方式は製品に柔軟性を与え、開発を迅速化しますが、その一方で問題が発生したときの対処が困難になる可能性があります。この方式では、依存の連鎖に連なるコンポーネントが1つでも問題を起こすと、それに依存するすべてのコンポーネントがドミノ倒しのように影響を受けることになるのです。これは、従来のクローズドシステムでは個別のインシデントとして発生するだけですむ問題でした。
この問題を重大化させるのがマイクロサービスです。マイクロサービスのアプローチでは、アプリケーションの他のコンポーネントが完成するのを待つことなく、サービスを単体でデプロイできます。従来設計のコンポーネントは大規模で、1つのレイヤー内で多くの機能を提供していましたが、マイクロサービスの分散性によってコンポーネントは軽量化し、求められる負荷の上昇に応じて迅速に拡張することも可能になりました。しかしマイクロサービスによって障害点が飛躍的に増加するため、適切なツールがなければトラブルシューティングはきわめて困難になります。
したがって、製品が外部APIに依存している場合は、可用性のみならず、それ以外の項目もテストおよび監視していくことが重要になります。パフォーマンス、データの検証やプロセス、機能変更、セキュリティなどについても目を光らせていく必要があるでしょう。
APIのパフォーマンステストが重要である理由
API障害によって自社サイトのパフォーマンスやユーザーエクスペリエンスが低下すると、企業全体に悪影響が及びます。それがサードパーティプロバイダーが引き起こした障害だったとしてもです。また、トランザクションプロセスにおけるそのAPIの重要度によっては、その障害が収益にすぐさま影響を与える可能性もあります。
たとえば、Webサイトの決済プロセスでの重要なコンポーネントがロケーションベースのサーチ機能であり、それをサードパーティAPIによって提供している場合、そのAPIが正常に動作しなければ、顧客は決済を完了させることができません。
Parkmobile社は複数のAPIを利用して、顧客向けに空いているパーキングの場所を表示しています。
あるいは、ソーシャルメディアプラットフォームから認証を行う必要があるアプリケーションを開発したとします。そのソーシャルメディアプラットフォームがダウンしてしまった場合、ユーザーはあなたのシステムにログインすることができなくなるでしょう。
開発者やサイトオーナーはそれでも、サードパーティのサービスを利用するメリットの方が、このような障害によるリスクに勝ると考えるかもしれません。リスクを正確に評価し、これらのサービスが受ける影響を経時的に可視化するうえでは、サイトのユーザーフローの中でも、APIに依存している部分を監視することが重要です。
このようなユーザーフローや、ブラウザ内での多段階のユーザーフローを伴うトランザクションも、監視できないことはありません。しかしトランザクションが複数のAPIリクエストで構成されており、APIレスポンスのさまざまな定性的コンポーネントに基づくバリエーションに富んだアサーションを使用しているような場合、ただ監視するだけでは不十分です。これに対し、1つのユーザーフローをさまざまなコンポーネントに分解してくれるAPI監視製品なら、テストがどのステップで失敗したかを見れば問題点がわかるため、具体的なインサイトが得られます。
APIをテストする際には、自社のWebサイトやネイティブアプリが重要なデータやプロセスのために利用しているAPI (他社のAPIを含む)と、顧客、エンドユーザー、または開発者がデータやプロセスのために利用している自社管理のAPIの両方を考慮する必要があります。
テストするべき内容
可用性
最も基本的なレベルでは、APIのテストと監視により、リソースが利用可能かどうか(つまり呼び出しに応答するかどうか)をチェックします。しかし、アプリケーションが他のアプリケーションやサービスと相互依存する度合いが高まっていることを考えると、APIが依存しているリソースの可用性をテストすることも真剣に検討する必要があります。依存関係の連鎖に障害が発生している可能性が通知されれば、他の場所で障害が発生したとしても、自社のサイトやアプリケーションはオンライン状態を維持できるように適切な措置を講じることができます。
応答時間
APIのレスポンスの速度はどれぐらいでしょうか？応答時間をテストすれば、本番前環境よりも本番環境の方が遅くなっていないか確認できます。さらに監視を行えば、時間の経過に伴って応答時間が遅くなっていないか確認することもできます。
データ検証
APIが利用可能でリクエストに応答していても、送られてくるデータが正しくなかったり、想定外のフォーマットであるといったこともあり得ます。そのために、テストを定期的に行って、タスクの実行に必要なデータを取得できているかどうか、確認する必要があります。APIリクエストヘッダーの詳細についてはこちらをご覧ください。
多段階プロセス
応答の受信後に実行される多段階のプロセスが想定どおりに動作しているかどうかも確認する必要があります。APIへの呼び出し回数を減らすために、呼び出しで取得されるデータはキャッシュできているか、認証は想定どおりに機能しているかなどについてです。
サードパーティおよびパートナーのAPIとの統合のテスト
すでに触れたように、アプリケーションやサービスは自社管理のAPIとサードパーティAPIの両方を利用していることが多く、ユーザーがこの2つの違いを区別できないこともよくあります。そのため、監視ソリューションでは、自社が管理するAPIだけでなく、サードパーティやパートナーのパフォーマンスも可視化できることが重要になります。こうすることで、パートナーの責任を徹底できるだけでなく、何か問題が発生した際に、誰に連絡すべきかも明確になります。
機能変更のテスト
外部サービスのパフォーマンスに依存する機能がある場合は、アプリケーションとそのサービスとの互換性が保たれているか、確かめる必要があるでしょう。変更が新規リリースによるものか、バグフィックスによるものかにかかわらず、サービスの世代交代があるとベースコードが動作しなくなることがあります。
本番環境でのテストが重要であることは言うまでもありませんが、バグはデプロイ前に取り除いておくに越したことはありません。したがって、他のユーザーが利用できるようにAPIをホストしている場合は、本番前および本番環境の両方でそのAPIをプロアクティブに監視するようにしてください。
まとめ
自前のAPIを監視する場合であれ、利用している外部サービスによる影響を確認する場合であれ、APIの可用性、機能、スピード、パフォーマンスをテストすることが重要です。過去の動作から信頼性に疑問のあるAPIがあり、そのAPIに対しプロアクティブな監視を行っていないのであれば、すぐにでもチームで検討を開始し、そのAPIの監視を始める計画を立てましょう。
What is Splunk? (Splunkとは)
これは私独自の記事であり、必ずしもSplunkの姿勢、戦略、見解を代弁するものではありません。
このブログはこちらの英語ブログの翻訳です。
