はじめに
Salesforceの提案や要件定義時において、みなさん非機能要件の扱いはどうされていますか？
セールスフォース・ドットコム社がプラットフォームを提供し、継続的なバージョンアップや維持・運用、セキュリティ対策等を行うため、非機能要件への対応はユーザ企業や開発者にとって大きく負担を軽減してくれます。しかしながら、非機能要件の中にはユーザ企業や開発者自身が意識し、その対応を考慮すべき事項もあるでしょう。今回のブログでは、一般的によくある非機能要件から代表的なものを仮想要件に対するプラットフォーム視点、開発者視点での回答という形でお伝えしたいと思います。
※プラットフォーム視点の記載内容は一般公開されている情報をもとづきますが、セールスフォース・ドットコム社の正式な回答を記載しているものではありません。
レスポンスタイム
要件
画面操作は原則5秒以内にレスポンスがあること。
プラットフォーム視点
サーバに入ったリクエストは規定された閾値でレスポンスできるようリソースを監視している。ただし、これは標準機能を用いた場合であり、Visualforce／Apex等でカスタム開発した画面やロジックを使用する場合の遅延時間は実装に依存する。
開発者視点
パブリッククラウドによるサービス提供となるため、通信速度が十分に出る回線・ネットワークインフラキャパシティの確保が前提となる。大容量データを扱う場合や多段階に渡る複雑なアクセスコントロールを行う場合パフォーマンスが劣化する可能性があるため、十分考慮する必要がある。
同時アクセス／トランザクション量
要件
3000ユーザによる同時アクセスおよび発生するトランザクションを処理できること。
プラットフォーム視点
マルチテナント前提に設計されているため、大量ユーザの同時利用が性能に影響を与えることはない。日別のトランザクションとして、11億件以上のトランザクションを平均300ms以下で応答。詳細については、http://trust.salesforce.com/trust/jp/status/ にて常時稼働状況を公開しています。
開発者視点
ユーザからの処理リクエストはプラットフォームでロードバランスされるため受付けは可能。ただし、１つの組織内でサーバ上で5秒以上かかる処理が同時実行される場合、同期処理数の制限に抵触する可能性が生じるため、アプリケーション設計上考慮する必要がある。
アクセスログ
要件
ユーザの操作およびDBアクセスに関する全てのアクセスログの収集ができること
プラットフォーム視点
プラットフォームとして、アプリケーションに対するアクセスログ、DBアクセス、ルーター、ファイアーウォール、IDSなどのシステムログは厳密に収集され、リアルタイムに複数の異なるシステムにコピーされセキュアな環境で厳密に保管されている。
開発者視点
無償の範囲で提供されるログは限定的であり、Winter'15でリリースされたEvent Log Files（有償）で要件を満たすことができるかの確認は必要。また、画面キャプチャーや印刷などアプリケーションに直接関係しない操作ログは収集できないため、別途ソリューションの検討が必要である。
バックアップ
要件
バックアップ方法・タイミングについて具体的に示すこと
プラットフォーム視点
データのすべてはミラーリングされたデータベースに格納されるとともに、専用回線で接続されたディザスタリカバリセンターにもほぼリアルタイムにミラーリングされる。さらにデータは24時間ごとにテーブでバックアップされ、厳重な管理下で管理される。また、ユーザ自身によるバックアップ手段として、Weeklyエクスポートサービスも標準提供される。
開発者視点
バックアップのタイミングやバックアップ先を柔軟に対応する必要がある場合、個別に開発を行う必要がある。また、バックアップに対してリストアする機能は標準提供されていないため、リストアの要件がある場合、こちらの開発も必要となる。なお、リストアの機能を実装する場合、リストアすることができないオブジェクトや項目がある点は注意が必要。
アプリケーションリリース検証
要件
本番リリース前に負荷テストを含む品質確認ができる
プラットフォーム視点
同時アクセス／トランザクション量で記載した通り、プラットフォームとして十分なリソースが確保されている。負荷テストはマルチテナントシステムのため本番環境においては禁止される。Sandboxにおいては、セールスフォース・ドットコム社のサポートに事前連絡しながらの実施検討は可能。
開発者視点
開発者による開発コンポーネント群をリリースする際には、事前にSandboxを利用したリリーステストを行い、事前にシュミレーションを行うなどのリリースプロセスの検討は必要。また、複数ベンダーによる開発や開発～テスト環境を用途に応じて複数Sandboxで運用する場合、メタデータの同期／デプロイ、メタデータで設定できないデータの設定等、本番環境へのリリースに至るまでのプロセスの検討も必要。
バージョン管理
要件
アプリケーションのリリース履歴が管理できる。
プラットフォーム視点
プラットフォーム自体ではチーム開発やバージョン管理機能は提供していない。リリースに関しては設定変更履歴で見ることは可能。
開発者視点
開発において設定した情報やプログラムをメタデータとして取り出し、外部のGit等で別途管理するといった運用の検討が必要。
障害検知
要件
閾値超過および突発的な障害検知と監視が行われること
プラットフォーム視点
障害によりサービスの継続に影響を及ぼす可能性のある機器やソフトウェアに対して、即時に障害やその前兆を捕らえるべく、数種類の監視ソフトウェアやサードパーティによる外部からの監視サービスを組み合わせて24時間365日の常時監視を行っている。
開発者視点
開発を行ったアプリケーションに起因する障害発生は想定されるため、要件定義や設計においてエラーハンドリングや障害発生原因を早期に特定するための独自ログ機構などを要件レベルに応じて検討する必要がある。
おわりに
非機能要件について、代表的なものを例にユーザや開発者が意識したいことをお伝えしましたが、如何でしたでしょうか？
なお、2015年7月14日に発表された「Salesforce Shield」を使用することにより、より広範囲に非機能要件がサポートされることと思います。Salesforce Shieldは要チェックです！
