スマホアプリ向けのAPIサーバの品質ガイドライン
ふと思い立ってかいた。
スマホアプリを開発する際、mixiさんが公開しているようなスマホ向けガイドラインと同様にAPIサーバでも、ある程度の確認用のガイドラインを個人的に設けていますので、メモとして公開してみます。クラウド環境の登場により誰でも簡単にサービス公開できるようになりましたが、結局のところインフラ構築コストが無くなるだけであり、サーバ品質は自身で担保しないとなりません。
前提
- 本ガイドラインの目的
- 対象
- 環境
- 前提
- 結合試験レベルまでの機能レベルテストは完了していること。条件網羅系試験、境界値試験、同値分割、フルパス等一般的な試験は実施済みであることが前提です。
全体的な機能確認
- 実データ確認
- 本番環境、若しくはそれに近い実データでオンライン処理、バッチ処理を実行させ基本機能が実現できることを確認
- オンライン・バッチ連動
- 業務処理・運用処理連動
- マスタメンテ等の運用系機能からデータを設定し、それがオンライン処理側で利用できることが確認できていること。
- アプリ連携
- アプリ to アプリ、アプリ to ブラウザ、ブラウザ to アプリのようにアプリ連携するようなサービスはそれらの全パスを網羅し確認出来ていること
- 環境差分
- 開発環境と本番環境の差による確認が出来ていること。
- パス等は全て本番に向いていること。
- 外部API接続アカウントは本番用になっていること。
- 国際化
- アプリ、サーバ、バッチ全てにおいて国際化が行われていること。
- ここで言う国際化は文言だけではなく、データフォーマット、文化による振る舞いの変化等も含む。
☆あるある：本番データを入れると動かない。本番環境の0件データ状態だと落ちる。
☆あるある：オンライン側の処理の入力チェック仕様とマスタメンテの入力チェック仕様が不整合。
対外接続確認
性能確認
- 単性能
- スケール前の最小構成にて、レイテンシーが許容値以内である確認が出来ていること。
- 最大性能
- スケール前の最小構成にて、性能の最大値を把握できていること。
- ボトルネックになる部分を把握していること。
- 過負荷
- 負荷をかけた状態にて、通常の処理の確認が出来ていること。
- 最大データ量
- 想定される最大データをDB等に設定し、機能の確認が行えていること。
☆あるある：データが多くなりバッチ処理時間が伸び、後続バッチ、またはそれを必要とするオンライン処理の開始時刻に間に合わなくなる。
☆あるある：大量データのCSVアップロード、ダウンロードでセッションタイムを超えたときに切断してしまう。
拡張性確認
- スケール
- スケーラブルな実装になっていること。
- ElastiCache、DynamoDB等オートスケールしないものに対するスケール性の担保の仕方が決定し、対策が講じられていること。
- EC2起動時に必要な全てのサービスが起動するようになっていること
- スケールインする際に必要なログ等のデータはストレージに退避するようになっていること
☆あるある：push用のバッチもAPIサーバで稼働しており、スケールさせるとバッチ処理がサーバ毎に重複起動し同じプッシュがユーザに複数配信される。
可用性確認
- 耐障害性
- 障害時に復旧するための手順があり、それの確認が出来ていること
- 障害時に自動復旧する仕組みが講じられていること。
- SPOF
- あるサーバの停止がシステム全体を止めてしまわないこと。
- あるモジュールの停止がサーバを止めてしまわないこと。
☆あるある：オンライン処理とバッチ処理を同一サーバ上にで実行している場合、バッチの過負荷によりオンライン側が停止。
運用確認
- バックアップ
- 必要なデータがバックアップ出来ていること、またそれをリカバルする方法が決まっており、確認が出来ていること
- 監視
- システムの状態を監視する仕組みがあること。
- 不具合の解析に必要な情報がログから取得出来るようになっていること。
- 日廻し試験
- スケジュール通り日次バッチ処理が動いていること。
- 月廻し試験
- 上記同様
- 特定日試験
- 祝日、祭日、閏年等により振る舞いを変える場合、その動作が確認出来ていること。
- 問い合わせ運用確認
- データ削除等のユーザからの問い合わせによる運用がある場合、運用担当者を交え、運用手順に従い運用を実施出来ることを確認できていること。
- ユーザ問い合わせへの調査に必要な情報がログから取得出来るようになっていること。
- ログ運用
- ローテーション、退避。
- 長時間運用時の資源
- サーバの再起動無しで長時間運用され続けている状況で、資源（メモリ、CPU、ディスク、..etc）の枯渇を起こさないことが確認できていること。
☆あるある：ログローテートが出来ておらず（またはファイルサイズ見積もりが甘く）、サーバ容量を圧迫し、サーバ停止。
セキュリティ確認
- 一般的なセキュリティ観点に対する対策
- バッファオーバーフロー対策、クロスサイトスクリプティング対策、パラメータ改ざん対策、バックドア・デバッグオプション対策、強制的ブラウズ対策、セッションハイジャック/リプレイ/Fixation対策、クロスサイトリクエストフォージェリー対策、ディレクトリトラバーサル対策、SQLインジェクション対策、OSコマンドインジェクション対策...等々
- クラウドを使う上でのチェックポイント
- 内部の運用管理ツールが公開されていないこと。
- DBへのアクセスがアプリケーションサーバからだけ等の制限をかけられていること。
- セキュリティグループの設定が0.0.0.0/0ではなく、接続元のSGやサーバIP等が絞られていること。
上記の確認ポイントを確認しつつ、バグが見つかった場合は、以下のような基本動作の徹底が必要です。
バグ発生時の基本動作
開発終盤になってくるとバグチケットの山になり、それに埋もれた終わりの見えない状態になると思いますが、そんなときこそ、基本動作を徹底することは大切です。バグでましたーなおしますー、こっちでも出ましたーなおしますーという場当たり的な修正ではなく、品質を作り込むことを意識しないといけません。今回のさいごの仕上げ部分に閉じず、どの試験でも同じスタンスが必要です。
- バグに対して、以下の切り分けを行うこと
- このバグを発見するための試験観点があり、それによって検出された場合
- その場合はハッピーですね。摘出すべくして、摘出した。試験項目がヒットしたということです。
- このバグは既に試験実施済みの観点なのにも関わらず、検出された場合
- これは、完全に試験すり抜けなので、何故すり抜けたかを原因を確認し、必要であれば、その観点で再試験が必要です。実施済み観点でバグが出てしまうと、今までやった試験自体の信頼性を疑わざるを得ない状況になってしまいます。
- このバグが試験をしていない観点のバグであった場合
- 観点漏れです。試験観点を追加し、追加試験の実施が必要です。
- このバグを発見するための試験観点があり、それによって検出された場合
