初めに
前回までに簡単なアプリの画面イメージとAWSのアカウント開設・初期設定まで行いました。かなり雑ですが、プレイリストシステム①の記事での画面イメージなどを機能要件として今回は非機能要件を定義していきたいと思います。
非機能要件とは
まず簡単に非機能要件とはについて簡単にまとめます。
非機能要件とは、その名の通り「機能以外のすべての要件」のこと。
性能や可用性、セキュリティなどの「必要とする機能以外の要件」を指す。
構築したシステムが顧客の希望する機能をすべて実装していたとしても、処理の性能が悪かったり、障害から復旧するのに時間がかかったりなどでは運用に耐えられないので、これらについても要件をしっかりと定義することが大事。
非機能要件で定義すべき項目
①可用性
システムが継続して利用できるかどうかです。
AWS上では可用性を高めるために片AZがダメになった時に別のAZにもサーバーを構築したりします。このシステムでも複数AZに跨る構成とします(マルチAZ)
②性能・拡張性
システムの処理性能および拡張に関する要件です。構築するシステムで処理するトランザクション数や利用ユーザー数、負荷などを決めます。また、将来のキャパシティ・プランニングを検討します。
そんな凝ったアプリは作らないのでほぼほぼ自分しかアクセスが来ない想定で以下の数字を想定しました。
ピーク時
利用ユーザー数:2人/1時間
トランザクション数:20/1時間
③運用・保守性
システムの運用・保守に関する要件です。システムの監視方法やバックアップ方法、問題発生時の体制などを決めておきます。
監視はec2、rdsの標準的なメトリクスを取得します。
バックアップはec2、rdsを週1回とります。書きながら思ったんですが、ec2に関してはアプリの回収やインストールされているソフトなどサーバーに対して何かしら変更を加えない限り必ずしもしなくてもよいのかな？と思ったのでこれもまた調べてみます。
運用については商用システムではないので一旦スルーとさせていただきます。
④移行性
現行システムからの移行に関する要件です。新システムへ移行するための移行期間、移行体制、移行リハーサルなど、移行計画についての要件を定義します。
現行のシステムがあるわけではなく、新規にaws上に構築するので以降に関しては今回考慮しなくて大丈夫そうです。
⑤セキュリティ
システムのセキュリティ確保について定義します。アクセス制限や不正検知・監視の方法、システム運用者に対する情報セキュリティ教育について定義します。
セキュリティソフトは使用せずawsサービスを使ってアクセス制御やDDOS対策などを行っていきたいと思います。また、運用者のセキュリティ教育も商用ではないので一旦スルーで。
⑥環境・エコロジー
システムを設置する環境・エコロジーに関する要件を定義します。環境負荷を低減する構成や、電気設備・規格の適合性について定義します。
今回はaws上にシステムを構築するのでこちらでは実際の設備は触れることができないのでこちらも特に考慮はしない事にします。
まとめ
ざっくりでしたが今回はシステムの要件を決めました。実際の要件定義は顧客の要望だったり、クラウドにシフトする際は現行のシステムの要件だったりを考慮する必要がありますが個人で勉強ついでに作るので色々とざっくりでした。
次回はこの要件をもとにaws上でどういった設定をするかの方式設計とパラメータシートの中間みたいなイメージの項目を決めていきたいと思います。