こんにちは。中村です。
ウノウで運用しているまちつく！はモバイル向けソーシャルアプリとしてmixi版、モバゲー版をそれぞれ展開しています。
開発するにあたって通常のウェブサイトとはいくつか違うポイントに注意しています。プロフィールや友達などの情報を取得するためにプロバイダが提供するAPIを利用することになりますし、通信も「携帯電話 <= プロバイダサーバ => SAPサーバ」という経路になるため、様々な箇所でプロバイダを意識した開発を行う必要があります。
今回は特にAPIを利用する際に注意しているポイントをいくつかピックアップしたいと思います。
APIアクセスをできるだけ減らす
オープンソーシャルモバイルに限らず基本的なことですが、APIへのアクセスを可能な限り減らすことでSAP・プロバイダ双方の負荷軽減になり、かつリクエスト毎のレスポンス向上に繋がります。まちつく！ではプロバイダからキャッシュすることが許されているデータをできるだけmemcachedにキャッシュするようにしています。
大量データをAPIから取得する場合は非同期にする
ひとつひとつはコンパクトなデータであっても、1回のリクエストで数百～数千件のデータとなるとオンラインで取得するのが主に速度面で難しい場合があります。まちつく！ではQ4Mを使って、いくつかのAPIアクセスをキュー処理にして非同期にデータを取得しています。
非同期で取得したデータは通常のAPIアクセスと同じようにmemcachedにキャッシュしていますが、既に十分に新しいキャッシュがある場合には負荷軽減のため重複してデータを取得しないようにしています。
オープンソーシャルから話は外れますが、PHPからQ4Mの利用についてウノウラボに過去記事がありますので、ご興味があればご参照ください。
PHP版 Parallel::Prefork で奥一穂さんと親に感謝しよう
APIアクセスにタイムアウトを設定する
APIのレスポンスに一定以上の時間がかかった場合、タイムアウトを設定していないとSAPの処理が軽くてもユーザーにレスポンスを返すことができなくなってしまいます。まちつく！ではできるだけユーザーにレスポンスを返すことができるようにタイムアウトを数秒にして調整しています。
タイムアウトを設定していないと処理待ちのプロセスが増えることにもなりますので、ユーザーのリクエスト中にAPIアクセスする場合にはApacheのプロセス数など注意が必要です。
APIアクセスに失敗してもできるだけ画面を表示する
APIアクセスがタイムアウトなど何かしらの理由で失敗した場合に例えば「通信に失敗しました」などのエラーメッセージだけが表示されてしまうと、ユーザーから見たときに何が起きているのかわかりません。APIアクセスに失敗することを想定に入れて、APIに関係しない部分は表示するなど工夫して、ユーザーが画面を閲覧できない状態をできるだけ防ぐようにしています。
ただし、登録処理の失敗など、ユーザーに失敗したことをしっかり通知する必要のある場合もありますので、主に参照画面での話になると思います。
APIレスポンスにあるべき情報をチェックする
APIレスポンスは頻繁にキャッシュすることになると思いますが、もしあるはずのデータがなかったりすると、そのままの状態でキャッシュされ長い間影響が出る可能性があります。キャッシュする前に必要なデータが存在しているかチェックしてから利用するようにしています。
まとめ
APIを利用するにあたって通常はまずパフォーマンスが悪化しないように注意することが必要ですが、何か問題があったときにもできるだけ画面表示を行うように考慮することも大切だと思います。