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