OpenTable: APIのベンチマークと本番環境でのテスト

http://trafficandweather.io/posts/2014/4/29/episode-24-i-dont-really-know-what-thats-referring-to

1 comment | 1 point | by WazanovaNews 約3年前 edited


Jshiike 約3年前 edited | ▲upvoteする | link

OpenTableはその名の通りレストランの予約サービスを提供していて、(おそらく)最大手。スタンドアロンのアプリもありますが、USのレストランのサイトで予約をするときに、OpenTableの機能が組み込まれていることが多いです。

RunscopeのJohn SheehanとDropboxのSteve Marxがやっているポッドキャスト「Traffic and Weather」(APIとクラウドのネタを取り上げるのでこの名前にしたとのこと。)で、OpenTableの開発チーム(場所はUKにあるんですね。知らなかった。)のブログを紹介しています。

1) APIのベンチマーク試験

APIのパフォーマンスを比較するNode.jsツールapi-benchmarkとそのGruntラッパーgrunt-api-benchmarkをオープンソースで提供。(参考画面

正しくセットアップする。

  • ベンチマーク試験は信頼性と比較検討のため、常に同じマシン、同じエージェント、同じ設定で実施する。
  • ベンチマーク試験に影響を与える制約がないかどうか確認するため、ネットワークのテストもする。試験の都度ネットワークテストはするべきで、帯域 / ホスト名確認 / OSの制約などもチェック。
  • アプリをホストしているのと同じマシンからは試験をしない。外部のマシンで実行すべきだが、別の地域のマシンにデプロイしたら、結果分析時に場所の違いを考慮にいれること。

負荷試験と性能試験は別だと認識する。

  • どうスケールできるか、問題が起きたらどう対処するかの知見を得るためには、パフォーマンスだけなく、限界値も把握する。
  • 10秒だと短い。1分はOK。5分だと更に良い。 レスポンス時間の差異を確認するために全てのルートをテストする。
  • 本番展開後にテストをする場合は、アプリのウォームアップが必要になることがある。ウォームアップのためのスクリプトを書くか、望ましい数値が取得できているか確認するために適切なタイムアウトをセットする。
  • 本番環境でのベンチマークテストは避けること。結果に影響を与える外部変数が多すぎるから。可能であれば、ベンチマークのためにまったく同じ設定のステージング環境を用意する。

必要あれば、デザインパターンの基本に倣ってAPIをテストしやすいかたちにする。

  • 結果は、サードパーティのAPIやDBへの同期コールに依存することがある。理想的には、ルートは外部依存をモックするオプションのパラメータが欲しい。
  • ベンチマーク試験完了後、データや環境設定に変更がでないことを確認する。そうすれば、本番展開後に新たな問題がでないことを担保でき、もし本番展開後 & トラフィックを振り向ける前にベンチマーク数値を再取得する必要がでた際に、本番環境でテストすることができる。

分析する。

  • 平均値ではだめ、ピーク値を確認すること。
  • 予想外の事態が起きれば、その問題に対処するために事象を再現すること。
  • 試験ごとにかなり違う結果がでた場合は、APIが予想できない依存関係を持ちすぎているということ。影響を与えている事象を見つけるまで、ベンチマークをローカルで実施したり、ソフトの小さな単位でのベンチマークを繰り返す。そしてそれを修正するか、どうしようもなければモックする。
  • 数値は読みやすく共有できるかたちでないと意味がない。結果を共有する適切なダッシュボードのツールを用意すること。

Steveの意見は、「できればend-to-endとmockは両方計測すべき。ユーザエクスペリエンスは結局はend-to-endでどうパフォーマンスがでるかだし、mockによって実装ロジックの確認がたやすくできるメリットもある。」

2) 本番環境でのテスト

  • 本番環境とまったく同じステージング環境を用意できるのがもちろん理想だが、(レストラン予約サイトであるOpenTableは、)世界中のレストランにあるマシンともやりとりしているので、現実的には難しい。予約のトラフィックは夜中は少ないので、その時間帯に本番環境を利用してテストすることがある。
  • 本番環境でのテストをしてなかったら、サーバの不具合やサービス間のやりとりの障害で見つけられなかったものもあったのではないかと思う。
  • もちろん細心の注意は必要。本番データにロギングする場合のバックアップ、安全を担保するためのコードの準備、リアルタイムで状況を監視。夜中の作業になるので、楽しいことではない。

Steve曰く「自分も内容を選んで本番でもテストするのは賛成。負荷の高いテストをやって、何か壊したりサービスがスローダウンするのを運営チームは恐れるが、それ以外でもやれる & やるべきテストはある。例えば、一定間隔でAPIにコールしてレスポンスを測るとか。複雑なシステムになっているサービスであれば色々得られるものはある。Dropboxでも内容を選んで実施している。」

#trafiicandweather #opentable #api

Back