今回は、分析システムの非機能要件について紹介します。

データ分析にはやはりITシステムがつきものです。データ分析者にはSE経験がお有りの方もいらっしゃるかと思いますが、そうでない方も非常に多いと思います。本記事はそんな「非機能要件って何？」「データ分析システムを作るのだけれど、非機能要件ってどこから手を付けたらいいの？」といった方々を対象にしています。

今から考える分析システムは、社内のデータを分析するためのシステムで、利用者としては分析部門の方たちを想定します。 また、構築環境についてはオンプレミスではなくクラウドを利用するとしましょう。

まず、非機能要件とは何かを簡単に説明します。

非機能要件とは

非機能要件とは、情報システムやソフトウェアの開発に際して定義される要件のうち、機能面以外のもの全般。性能や信頼性、拡張性、運用性、セキュリティなどに関する要件が含まれる。

引用元:http://e-words.jp/w/非機能要件.html

機能要件以外のもの全般と定義されていますね。それでは機能要件とは何でしょうか。

機能要件とは

機能要件とは、情報システムやソフトウェアの開発に際して定義される要件のうち、機能に関するもの。
業務においてそのシステムやソフトウェアで何ができるのかをまとめたもので、扱うデータの種類や構造、処理内容、画面表示や操作の方法、帳票などの出力の形式などが含まれる。
これに対し、機能面以外の要件を「非機能要件」(non-functional requirement)と呼び、性能や信頼性、拡張性、運用性、セキュリティなどに関する要件が含まれる。

引用元:http://e-words.jp/w/機能要件.html

機能要件とは、そのシステムでできなければならないことをまとめたものです。具体例を分析システムであげると、そもそもデータ分析ができること、レポートを作成できること、グラフを表示できること、などが考えられます。

では、肝心の非機能要件というと、データが分析できるという機能だけではなく、分析の速度が1万件に対して1秒以内に終わる、というパフォーマンスの要件であったり、データは暗号化してセキュリティを高めて欲しい、などが考えられます。

このように、非機能要件とは「機能要件以外のもの」というざっくりとした定義なので様々な事柄が考えられます。何もない状態から漏れのないように挙げていくのは大変な作業ですので、何か基準や指標があったら便利ですよね。そこで「非機能要求グレード」と呼ばれる、情報処理推進機構が策定した非機能要件の一覧が無料で公開されていますので、そちらを紹介したいと思います。非機能要求グレードはIT業界では非常に有名な資料で、実際に業務システムを構築する際に使われているものです。この記事でも非機能要求グレードに沿って非機能要件を考えていきます。

非機能要求グレードの活用

非機能要求グレードはこちらからダウンロードできます。

さっそく非機能要求グレードについて中身を見てみましょう。こちらが非機能要求グレードの1行目です。(一部レイアウトを変えています)

非機能要件について大項目、中項目、小項目と分類がされています。そして右の列を見ていくと、その要件に対してレベルが6段階でふられていて、システムの社会的影響に合わせて、その要件ではどのレベルが適切かを予め示してくれています。

例えば、銀行のシステムやコンビニのPOSシステムなど、常に動き続けていないと大きな被害をもたらせてしまうようなものを構築するときは、社会的影響が極めて大きいシステムであると判断して、運用スケジュールのレベルは5(24時間無停止)を選択します。そして他の項目についてもレベルを選択していくと、非機能要件が定まってくるということですね。

これを使って検討していくわけですが、実際には非機能要求グレードはかなり細かい内容が含まれていますので、全部をきっちり考えるかというと必ずしもそうではないです。これは非機能要件の網羅であって、そこから検討すべき項目を適宜抜き出してくる、といった使い方がされています。

非機能要求グレードから大項目を取りだしてみましょう。すると以下の6つになります。

今回はこれら6つの大項目に対して、分析システムという観点から、非機能要件を考慮してみたいと思います。

1.可用性

分析システムは、常に動き続けていていつでも使える状態でないと、重要な業務が止まってしまうか、消費者様に対するサービスが停止するか、売上が止まり続けるか、といわれるとそうではないです。従って運用時間に関しては、定時内だけ動いていればいい、もしくは夜間バッチなら夜間だけ動いていればいい、というレベルになると思います。障害が起こってからの復旧時間や、災害対策についても同様に基本的には低めのレベルで大丈夫でしょう。

2.性能・拡張性

一般のECサイトなどのシステムでは、同時アクセスユーザー数が時間帯で変わったり、会員数の増加によって長いスパンで見るとどんどん応答速度が遅くなったり、セールやメディアで商品が取り上げられた場合などには普段とは違ったアクセス数があったりします。そうしたときにも応答速度が下がらないようするにする、などの要件を実現する仕組みを考える必要があります。

一方でこの分析システムは、利用ユーザーが社内の限られた人たちだけで、同時アクセス数も上限があります。したがって、業務処理量・性能目標値については考慮しやすくなります。

ただ、処理するデータ量については分析する内容によってかなり左右されますので注意が必要です。1ユーザーからの要求であっても、データを総なめするような分析を行うと非常に大量のデータを処理しなければなりません。また、分析にかかる待ち時間は極力少なくしたほうが使い心地が良いのは間違いありません。ですので、データ処理に関する業務処理量・性能目標値については高いレベルの要求になります。リソース拡張性については、データの増加に柔軟に対応できるようにしなければなりません。

GoogleのBigQueryやAmazonのRedshiftを使うとTB級の大規模データでも非常に早い速度で返ってきます。やはりストレージの容量の拡張性についても、足りなくなったときに簡単に増やすことができるのでおすすめです。

また、性能を高めるにはハードウェアだけではなく、テーブルの設計や投げるQueryも考慮することが非常に重要です。

3.運用・保守性

通常運用については、先程も触れましたが、定時内と夜間バッチだけ動いていればよいので要求レベルは低いです。運用保守は、24時間365日のシステムではないので計画停止をして行えます。障害時運用は最悪止まってしまっても消費者の方々に大きな損害がでるというものではないので、高レベルではありません。その他に関しても、試験環境は必要ありませんし、常駐サポートも必要ないので、要求レベルは低くなります。

4.移行性

移行性については、計画停止も認められますし、クラウドなので物的な移動のことは考慮する必要がありません。注意が必要なのはデータの移行ですね。データ分析なので保有するデータ量は非常に大きなものになります。

5.セキュリティ

セキュリティに関しては、一般公開するものではなく、内部向けの閉じたシステムになりますので、リスク管理は比較的し易いものになります。しかし扱っているデータは個人情報が含まれていたり、分析結果は企業の戦略上外には出せない非常に重要度が高いものになりますので、セキュリティについては高いレベルの要求がされます。ただ、セキュリティと利便性というのは多くの場合相反するものです。

例えばデータの暗号化を行ってデータベースに格納すると、分析のたびに解読を行わなければならないのでパフォーマンスに大きな影響がでてしまいます。セキュリティをどれだけ強くするかは、実際に使用するユーザーの方々と綿密に打ち合わせをする必要がある部分です。データベースにアクセスできるコンピュータの限定と、外部記録媒体の接続の禁止、ネットワーク経路の暗号化、これらは最低限必要だと思います。マスターデータは暗号化して保存し、個人情報などを取り除いたデータを分析用に用意する、というのも一つの選択肢です。

6.システム環境・エコロジー

システム構築の際には法規制についても考える必要があります。機材の免震性・重量・騒音といった設備的な話についてはクラウドで構築してしまうので考慮する必要はありあせん。

しかし、データ分析の特性上、個人情報が含まれたデータを保有することになるので、個人情報への保護規制には日本国内だけではなく海外の法律も注意が必要です。例えば、EUには「一般データ保護規則」というEU域以外への個人情報を厳しく制限する規制があります。EU内のデータを扱うときはEU内のデータセンターを選択するということも検討すべきです。このように海外に係る場合はそこの法規制・商習慣なども考慮する必要があります。

まとめ

今回は分析システムの非機能要件について見てきました。ポイントとしては、可用性や運用保守性は要求レベルが低いが、データの量そのものの大きさと処理量の大きさ、そしてセキュリティについては慎重に考える必要があるというところです。

最後までお読み頂き、ありがとうございました。