読者です 読者をやめる 読者になる 読者になる

スマホアプリ向けのAPIサーバの品質ガイドライン

テスト

ふと思い立ってかいた。

スマホアプリを開発する際、mixiさんが公開しているようなスマホ向けガイドラインと同様にAPIサーバでも、ある程度の確認用のガイドラインを個人的に設けていますので、メモとして公開してみます。クラウド環境の登場により誰でも簡単にサービス公開できるようになりましたが、結局のところインフラ構築コストが無くなるだけであり、サーバ品質は自身で担保しないとなりません。

前提

  • 本ガイドラインの目的
    • リリースしてから、問題が発見されるようなことが無いように、サービスを運用する上で確認すべきことをリスト化しています。機能要件の試験は済んでいることを前提とし、運用レベル確認のためのリストになっています。当然、品質目標はミッションクリティカルなレベルの品質ではなく、toC向けの無料スマホアプリレベル品質になります。
  • 対象
    • スマホアプリ向けAPIサーバ
  • 環境
    • AWS等のスケーラブルなクラウド環境。私がAWSユーザなので、AWSベースに表記が一部なっています。
  • 前提
    • 結合試験レベルまでの機能レベルテストは完了していること。条件網羅系試験、境界値試験、同値分割、フルパス等一般的な試験は実施済みであることが前提です。

全体的な機能確認

  • 実データ確認
    • 本番環境、若しくはそれに近い実データでオンライン処理、バッチ処理を実行させ基本機能が実現できることを確認
  • オンライン・バッチ連動
    • オンライン処理データをバッチ処理で加工し、またオンライン処理で使う等の場合、オンライン→データベース→バッチ処理→データベース→オンラインとデータが正しく引き継がれ、処理が実行されること
  • 業務処理・運用処理連動
    • マスタメンテ等の運用系機能からデータを設定し、それがオンライン処理側で利用できることが確認できていること。
  • アプリ連携
    • アプリ to アプリ、アプリ to ブラウザ、ブラウザ to アプリのようにアプリ連携するようなサービスはそれらの全パスを網羅し確認出来ていること
  • 環境差分
    • 開発環境と本番環境の差による確認が出来ていること。
    • パス等は全て本番に向いていること。
    • 外部API接続アカウントは本番用になっていること。
  • 国際化
    • アプリ、サーバ、バッチ全てにおいて国際化が行われていること。
    • ここで言う国際化は文言だけではなく、データフォーマット、文化による振る舞いの変化等も含む。

☆あるある:本番データを入れると動かない。本番環境の0件データ状態だと落ちる。
☆あるある:オンライン側の処理の入力チェック仕様とマスタメンテの入力チェック仕様が不整合。

対外接続確認

  • 疎結合
    • 接続先外部サービス(TwitterFacebook等)が落ちている場合、その影響を受け、自身のシステムが利用停止にならないこと。
    • 接続先からエラーが出た場合に、丸め込み等が出来ていること。
  • 性能確認
    • 接続先サービスの性能限界(TwitterAPIでいうRateLimit)を把握しており、それにあわせた対応実装がなされていること。
  • 規約遵守
    • 接続先サービスのプラットフォームポリシーガイドライン等に準拠していることが確認できていること。|

☆あるある:Facebookプラットフォームポリシーガイドラインに準拠せずにアプリ登録をBANされる。

性能確認

  • 単性能
    • スケール前の最小構成にて、レイテンシーが許容値以内である確認が出来ていること。
  • 最大性能
    • スケール前の最小構成にて、性能の最大値を把握できていること。
    • ボトルネックになる部分を把握していること。
  • 過負荷
    • 負荷をかけた状態にて、通常の処理の確認が出来ていること。
  • 最大データ量
    • 想定される最大データをDB等に設定し、機能の確認が行えていること。

☆あるある:データが多くなりバッチ処理時間が伸び、後続バッチ、またはそれを必要とするオンライン処理の開始時刻に間に合わなくなる。

拡張性確認

  • スケール
    • スケーラブルな実装になっていること。
    • ElastiCache、DynamoDB等オートスケールしないものに対するスケール性の担保の仕方が決定し、対策が講じられていること。
    • EC2起動時に必要な全てのサービスが起動するようになっていること
    • スケールインする際に必要なログ等のデータはストレージに退避するようになっていること

☆あるある:push用のバッチもAPIサーバで稼働しており、スケールさせるとバッチ処理がサーバ毎に重複起動し同じプッシュがユーザに複数配信される。

可用性確認

  • 耐障害性
    • 障害時に復旧するための手順があり、それの確認が出来ていること
    • 障害時に自動復旧する仕組みが講じられていること。
  • SPOF
    • あるサーバの停止がシステム全体を止めてしまわないこと。
    • あるモジュールの停止がサーバを止めてしまわないこと。

☆あるある:オンライン処理とバッチ処理を同一サーバ上にで実行している場合、バッチの過負荷によりオンライン側が停止。

運用確認

  • バックアップ
    • 必要なデータがバックアップ出来ていること、またそれをリカバルする方法が決まっており、確認が出来ていること
  • 監視
    • システムの状態を監視する仕組みがあること。
    • 不具合の解析に必要な情報がログから取得出来るようになっていること。
  • 日廻し試験
    • スケジュール通り日次バッチ処理が動いていること。
  • 月廻し試験
    • 上記同様
  • 特定日試験
    • 祝日、祭日、閏年等により振る舞いを変える場合、その動作が確認出来ていること。
  • 問い合わせ運用確認
    • データ削除等のユーザからの問い合わせによる運用がある場合、運用担当者を交え、運用手順に従い運用を実施出来ることを確認できていること。
    • ユーザ問い合わせへの調査に必要な情報がログから取得出来るようになっていること。
  • ログ運用
    • ローテーション、退避。
  • 長時間運用時の資源
    • サーバの再起動無しで長時間運用され続けている状況で、資源(メモリ、CPU、ディスク、..etc)の枯渇を起こさないことが確認できていること。

☆あるある:ログローテートが出来ておらず(またはファイルサイズ見積もりが甘く)、サーバ容量を圧迫し、サーバ停止。

セキュリティ確認

上記の確認ポイントを確認しつつ、バグが見つかった場合は、以下のような基本動作の徹底が必要です。

バグ発生時の基本動作

開発終盤になってくるとバグチケットの山になり、それに埋もれた終わりの見えない状態になると思いますが、そんなときこそ、基本動作を徹底することは大切です。バグでましたーなおしますー、こっちでも出ましたーなおしますーという場当たり的な修正ではなく、品質を作り込むことを意識しないといけません。今回のさいごの仕上げ部分に閉じず、どの試験でも同じスタンスが必要です。

  • バグに対して、以下の切り分けを行うこと
    • このバグを発見するための試験観点があり、それによって検出された場合
      • その場合はハッピーですね。摘出すべくして、摘出した。試験項目がヒットしたということです。
    • このバグは既に試験実施済みの観点なのにも関わらず、検出された場合
      • これは、完全に試験すり抜けなので、何故すり抜けたかを原因を確認し、必要であれば、その観点で再試験が必要です。実施済み観点でバグが出てしまうと、今までやった試験自体の信頼性を疑わざるを得ない状況になってしまいます。
    • このバグが試験をしていない観点のバグであった場合
      • 観点漏れです。試験観点を追加し、追加試験の実施が必要です。
  • 横並びチェック・歯止め・真の原因の追求
    • また、不具合に対してはある程度真の原因を追求し、その原因に対する歯止めの実施、および影響範囲を洗い出し横並びチェックを実施すべきです。横並びチェックとしては、究極的に、同じ開発者が同じ勘違いを複数箇所でしていた場合は、その開発者のコミットしたソースを全部確認する(自動or手動)ことになります。こういう泥臭いことを行わないと、結局、デグレード、同じようなバグの発生が止まらない、とかとか、結局バグ発生曲線が収束しないのです。そして、同じような確認を何度も再帰的に行うので、テストを自動化しておけば良かったということになります。