フェンリル

2016.05.30

見えない部分をどう見るか
~サーバサイド非機能要件の考察

初めまして、ウェブ共同開発部の岩瀬です。本コラムでは非機能要件、特にサーバサイドの部分に関して書こうと思います。

私は普段の業務では主にウェブサービスや、スマートフォン向けのネイティブアプリケーションのバックエンド開発を担当しています。

フェンリルで開発しているスマートフォンアプリケーションは BtoB / BtoC / CtoC などさまざまですが、多くのアプリケーションは数々の処理をサーバーと連動して実行します。アプリケーションで表示している情報の検索動作や登録動作などは、アプリケーションがサーバー側に用意された API を呼び出すことで実現しているのです。そのためサーバサイドでの非機能要件も非常に重要な要素となります。

さて、非機能要件とは一旦なんなのでしょう? 「非」のつかない「機能要件」は、作り上げるシステムが実現する機能に関する要件です。読んで字のごとくですね。機能なので、画面に表示する内容や検索機能での検索内容などは機能要件にあたります。では非機能要件はというと機能に定義されていない要件のことになります。例えば性能や運用性などがそれにあたります。

このように、非機能要件は機能的に見えない部分にもかかわらず、システム(アプリケーション)を開発、運用する上では非常に重要なものとなります。性能を無視した機能要件や運用性を無視した実装などをしてしまうと、後から非常に対応の難しい問題をシステムに含んでしまうことになります。

では、アプリケーションを開発する上でどのような非機能要件を考えれば良いのでしょう?

性能と運用の 2 つのパターンを、利用者側・システム側の 2 つの視点から考えてみましょう。

コラム アプリケーション開発におけるサーバサイド非機能要件 イメージ

性能面から見る非機能要件

私自身が非常に興味があるということもあり、まず性能面から考えてみます。

「システム」で「性能」といえばまず何が思い浮かびますか?

私は真っ先にデータベースではないかと思います。データベースと一言でいっても現在はいろいろなものが利用されています。最も代表的なものは RDBMS ではないでしょうか? 私自身が担当するシステムも Oracle や MySQL、PostgreSQL などの RDBMS を必ずといっていいほど利用しています。またアプリケーションのプラットフォームである iOS や Android にもデータベースが存在します。最近では Realm などが盛り上がっていますね。

性能を利用者の視点で考えると速いにこしたことはないのではないでしょう。サクサク動くアプリケーションは良いアプリケーションの重要項目ともいえます。

では、サクサク動くアプリケーションをシステムの側面からみるとどうなるでしょう?

アプリケーションはサーバ側に用意された API と連携し機能を実現しています。そのため、”サクサク動く = API の呼出し回数の増加”に繋がります。

API の処理にはデータベースへのアクセスが含まれることが多いため API の呼出し回数が増えることはデータベースアクセスの増加ともいえます。システムには過酷な状態になり性能の良いサーバ資源や、洗練されたアクセスクエリなどを用意する必要が出てきます。

これらを全てのシステムで用意出来れば良いのですが、当然難しいためアプリケーションでの処理分担を積極的に取り入れるようにしています。具体的にはアプリケーションのプラットフォームが持つデータベースを利用し、全ての処理を API に任せるのではなく適度にアプリケーションにも処理を分担することで性能面を高めるようにしています。

例えば、アプリケーションは個人所有の端末で利用することが基本であるため、個人の設定などは都度 API で問い合わせなくともアプリケーション内で保存しておき、変更が発生した場合に同期・非同期いずれかで API を呼出して保存する方法などです。

アプリケーションにおける性能面の非機能要件は API (サーバサイド)の性能にとどまらず、アプリケーションも処理も含めて検討・決定する必要があるといえます。

コラム アプリケーション開発におけるサーバサイド非機能要件 イメージ

運用面から見る非機能要件

次は運用での非機能要件を考えてみたいと思います。

運用となると多くのユースケースがあるのですが、ここはアプリケーションという特性をもとにバージョンアップやメンテナンス時を取り上げたいと思います。

これら 2 つは何もアプリケーション固有の物ではありません、Web サイトなどでも同様にアップデートやメンテナンスは発生しますのでまずそちらを考えてみたいと思います。通常 Web サイトなどでアップデートやメンテナンスを行う場合は、事前にサイトのヘッダーなどに告知文などを表示し、特定の時間に一時的にシステムを停止してメンテナンスを実施する方法や、サイト停止を伴わず機能の一部を少しずつ入れ替えていく方法があります。

では、このユースケースにはどのような非機能要件があるのでしょうか?

事前にユーザーに通知する機能などは、機能要件として考えることができるため、アプリケーションでも同様でしょう。では、システムを止める部分はどうでしょう?

Web サイトなどの場合、メンテナンス画面を用意し、停止時に URL をリダイレクトすることで実現が可能です。これは View の部分をサーバより配信している Web サイトだからこそできる機能と言えます。アプリケーションの場合、 API を停止したり別の結果を返してしまうとアプリケーション側でエラーとなってしまいます。そのためメンテナンス時は API の返却値でどのような HTTP コードを返すかや、レスポンスのデータにメンテナンスの時間を含めて返すなどの取り決めを定義しておく必要が出てきます。

バージョンアップ時に関してはバージョンアップ後の API を利用するアプリケーションが、必ずしも意図したバージョンでは無い可能性を考慮する必要が出てきます。これはアプリケーションのバージョンアップの可否は利用ユーザに一任されるためです。バージョン判定用の API を用意したり、強制アップデートの可否を返却する API を用意する必要が出てくるため、やはりこちらも非機能要件で定義しておく必要があります。

このように運用面の一部のユースケースを取って考えても、これだけの要件が存在することが分かります。

さて、ここまで非機能要件を性能面/運用面で見てきました。双方に言えることとして、アプリケーションとサーバサイド(API)の両方を合わせて考えて、初めて見えてくるものが多くあることが分かりました。 今後、サーバサイドでの非機能要件を考える際は、アプリケーション/サーバサイド両方の視点を持って考えることが重要と言えるでしょう。