最初はページの集まりにすぎなかったWebだが、今ではそれは、あるサイトから別のサイトへと自由に流れていくプログラマブルな…プログラムによって操作可能な…データの貯蔵庫群になっている。それを可能にしたのが、各サイトが提供し公開しているAPIだが、しかし今Web上にあふれている何千というAPIを正しく把握し管理することはとても難しい。APIのためのGoogle Analyticsのようなツールが、どこかにないだろうか？

今日（米国時間8/25）、Sonoa Systemsがベータを立ち上げたApigeeは、まさにそれを志向する（デベロッパはここでベータテストへの参加を登録できる）。Sonoaはこのサービスを、スケーラビリティに富むAPI探索コードを軸に構築した。ApigeeはWebデベロッパに、自分たちが提供しているAPIと、自分たちが利用しているAPIの両方を管理するためのダッシュボードを提供する。

たとえば、自分のこのマッシュアップは5つのAPIを使っているが、不調の原因になっているのはどのAPIだろう？　あるいは、この巨大なWebサイトは熱心すぎるデベロッパたちが山のように大量のAPIを呼び出しているが、ときどきダウンするのはどのAPIのせいだろう？　こういう問題のためにApigeeは、各APIの振る舞いを分かりやすい図表やグラフで見せてくれる。ApigeeのゼネラルマネージャBrian Mulloyは、“われわれはWeb上のAPI群を、インターネットという宇宙の暗黒物質のようなものだと思っている”と言う。“つまり、あることは分かっているが、その振る舞いを直接観察することができないもの、それが暗黒物質だ”。

さっきの、5つのAPIを使っているマッシュアップの例では、Apigeeは各APIのレスポンスタイムやエラーレート、呼び出しリクエストの総数（デベロッパが限度を超えた呼び出しをしていないか）などを監視する。下のスクリーンショットは”PhotoTwitty”という架空のアプリケーションの例だが、Twitter、Twitter Search、Flickr、Google、4PayPrintsという計5つのAPIを呼び出しているマッシュアップだ。PhotoTwittyが正常に動くためには、これら5つのAPIの呼び出しがどれも正常に動作しなければならない。

人気の高いAPIを多数使っている大型サイトは、また別の問題を抱えている。サーバがクラッシュしないためにリミットを設けても、ときには一人か二人のヘビーユーザのよってダウンすることがある。また、APIの提供者がリミットを設けていても、そのリミットをユーザに強制できる能力は持っていない。しかしApigeeを使うと、画面上のスライダーを操作することによってAPIのリミットを簡単に加減できる。そして呼び出しがそのリミットを超えそうになったら、その呼び出しに待ったをかける。

Apigeeはそういう操作を、各APIのプロキシを作ることによって行っている。“すべてのAPI呼び出しがわれわれのプロキシを介して行われる”とMulloyは言う。プロキシはSonoraのAPI探索コードを使って作られており、それによりすべてのAPI呼び出しがApigeeを経由して行われる。プロキシの動作は双方向的で、APIの提供者と消費者の両方が監視と管理のために利用できる。一般のWebサイトと違ってAPI呼び出しではJavaScriptのビーコンを外せないから、APIの広範な使われ方を計測するにはこれが唯一の方法なのだ。

十分な量のAPIがApigeeのプロキシを経由して動き出し、ユーザがデータを匿名的かつ集積的に共有化できるように…つまりいちばん単純な形に…設定すると、最後にApigeeは、APIの利用とアップタイムに関する公開データをユーザに提供し、それとあわせてAlexaふうのサービスを作り出す。

Apigeeの欠点は、プロキシであるためにシステム全体に遅れ（待ち時間, latency）を持ち込むことだ。Mulloyの推計では、この遅れはせいぜい200〜300ミリ秒程度だから、ほとんどのアプリにとって許容範囲だろう。ただし、Twitterのようなリアルタイムのアプリケーションでは問題になる。たとえばURL短縮サービスでは、300ミリ秒が遅れの許容範囲の限界だ。しかし、APIの状態を視覚化して見れるのだから、これぐらいの遅れは我慢すべきだろう。

なお、APIの呼び出しが1時間に1万回を超えるようなアプリケーションは、Apigeeの利用が有料になる（最大で月額100ドル）。それ未満なら、無料だ。類似のサービスとして、Masheryや3Scaleなどがある。

[原文へ]

（翻訳：iwatani(a.k.a. hiwa)）