イントロダクション
RFI・RFPの話の７回目になります。
分量が多くなってきたのと、だんだん「RFI・RFP」というよりは「非機能要件」に特化した話になってきたので、どこかのタイミングで分類を分けなおそうと思います。
今回は非機能要件の性能・拡張性についての２回目です。
前回はシステムの性能について、利用条件や保証する範囲についてお話しました。
非機能要件は、業務部門にしてみれば「できててあたりまえ」のように捉えられることが多い部分ですが、機能要件と比較すると「〇〇ができること」の「〇〇」が専門性を要する内容であることから、定義が曖昧になったり、わからないまま進んで失敗することもあります。
かといって100点満点全てを覚えなくても、70点くらいまで覚えて、後は実地で応用する、くらいが良いのではないかと思います。
覚えてなんぼではなく、使えてなんぼです。使える知識にしていきましょう。
拡張性について
システム開発における拡張性とは
前回の性能要件で、現在の利用状況をきちんと反映した条件にすることをお話しましたが、これはあくまで「現在」です。将来、利用者が増えたり、機能が追加されたりした場合には、当然条件自体が変わります。
とはいえ今回の調達スコープにそこまで見越したスペックを準備しておくのは費用がかさみます。また、まだ計画が承認されているわけではないので、今導入しても結局増強の必要が無かった、ということも起こりえます。
そこで「将来的に利用の条件が変わっても、柔軟に変更が可能な構成にしましょうね」というのが「拡張性」なのです。
ソフトだってアドオンでのサービス提供＝拡張です。特にパッケージ導入の場合、一度に全てのサブシステムを調達せずに徐々に増やしていくようなやり方ができます。
アドオンが容易に追加できるような仕組みを有していることも、拡張性なのです。
ハードについても所謂アドオンのような形と、既存機能の強化のような形をとることができます。
前者が「スケールイン・スケールアウト」という方法、後者が「スケールアップ・スケールダウン」という方法になります。
スケールイン・スケールアウト
可用性についての話でも少しだけ単語が出てきました。例えば負荷分散クラスタ構成で、現在2台のWebサーバで運用しているシステムがあります。
例えば、3年後には利用者の範囲を現在の1,000人規模から2,000人規模に拡大することを計画している場合、Webサーバ2台で1,000人なのですから、2,000人なら4台必要になります。2台を後から追加することを「スケールアウト」といいます。
逆に、5年を目途に次期システムへの段階的な移行を想定しているので、半分の移行が完了した時点でWebサーバを2台から1台に減らして運用するような場合を「スケールイン」というのです。
これらは主に負荷分散クラスタとセットになります。負荷分散クラスタの場合、クラスタリングしている複数サーバは基本的に同じ役割なので、そこにもう１台サーバを増やすことは比較的容易に行えます。
減らす場合も同様です。使ってもいないサーバにラックユニットと電力を食われないように、きちんとスケールインも行うようにしましょう。
スケールアップ・スケールダウン
スケールイン・スケールアウトは、利用状況がそれこそ倍・半分になるような大規模な変動を想定した方法ですが、そこまでではないような拡大・縮小もあります。
1,000人の利用者が800人になったり、1,200人になったりというような割合での増減であれば、サーバを増やしたり減らしたりするのではなく、サーバ自体の性能を強化したり縮小することで対応できます。
たとえばメモリを増設したり、CPUのコア数を増やしたり、ハードディスクを増設する等の場合が「スケールアップ」、逆にメモリを減らしたり、CPUのコア数を減らしたりする場合が「スケールダウン」です。
スケールアップ・スケールダウンは、スケールイン・スケールアウトと比較すると規模は小さいですが、メモリスロットの空きや搭載できるHDDドライブの数等、初期導入するサーバの要件に反映させなければいけません。
決して行き当たりばったりに増強をする、という意味ではないので勘違いしないようにしましょう。
性能・拡張性とクラウドサービス
性能・拡張性について、全てのシステムで性能要件を達成したり拡張性を担保した機器構成を行うことは困難です。といっても小規模なシステムだから性能が出なくても良いかというとそういうわけではないでしょう。
可用性の話の時も出てきましたが、クラウドサービスはこれらを解消する一つの方法になります。性能についてはインターネットを経由するため正確なレスポンスタイムを求めることは難しいですが、推奨環境下であれば基本的な性能は保証されています。また拡張性についてもリソースの量により価格帯が分かれる料金体系であることが多く、拡張・縮小の作業も非常に手軽に行えます。
後書き
本質を理解することの重要さ
ただ、クラウドサービスが性能・拡張性を全て解決してくれるわけではありません。
どれくらいのリソースが必要なのかは、結局利用方法や利用範囲から調査する必要があります。拡張性についても、初期契約時のリソースと費用、追加契約時のリソースと費用が今後の拡張性とマッチしているか検証しなければいけません。
可用性の時といい、「だからクラウドの方がいいですよ」みたいな話になるのが嫌で、あえてこういう書き方をしていますが、私自身は本当はクラウド利用を推進していきたいです。
しかし日本人の悪い風潮で、何か流行りだすとそれが全部解決してくれるみたいな思い込みが先行して、実際には期待した効果は出ず、勝手に落胆してブームが去る、みたいなところがあります。
クラウドが全て解決してくれる。
AIが全部仕事してくれる。
RPAが入れば生産性が著しく向上する。
ベースにある技術を理解せず、これらのブームに踊らされれば、本当の利便性を手に入れる前にサービスそのものが廃れてしまいかねません。
本質を理解した上で、ベンダーとユーザーが相互に高めあって良いサービスに育てていかなければいけないと思うのです。
RFI・RFP／プロジェクト管理関連の記事を纏めています。
この記事が気に入ったら
いいね！をお願いします
