悩ましいが重要な課題～コストと性能の両立
システム開発のプロジェクトには様々な課題が出てきますが、大きな課題の1つはお金、つまり「開発コスト」でしょう。いきなり夢のない話ではありますが、近年、システム開発に対する企業の投資額は潤沢とは言えず、ベンダ間の価格競争もあって、コストカットのシビアなつばぜり合いが日夜行われています。
一方で、ポイントを外したダウンサイジングによってシステム品質を著しく損なう事例にも事欠きません。特に、私たち「まかせいのう」が専門とするパフォーマンスという領域は、ハードウェアやソフトウェアのリソース削減がダイレクトに性能問題発生に直結するため、ダウンサイジングには慎重を期す必要があります。
本稿では、このダウンサイジングの実例として、学生を対象に教育コンテンツを提供するモバイルアプリとサーバ側機能の開発プロジェクトを例に、システムキャパシティを最適化する性能設計とそのポイントを紹介します。
サイジングあれこれ
まかせいのうは本プロジェクトに初期フェーズから参画し、アーキテクチャデザインからサイジング、性能設計支援、性能試験、商用リリース支援まで一貫した支援を行いました。これらのうち、真っ先に実施したのがサイジングです。システムにどの程度のキャパシティが必要かが分からないと、システム全体のアーキテクチャ設計や、調達するハードウェア／ソフトウェアが決まらないからです。
サイジングの方法は、状況に応じていくつかやり方があります。大きく分類すると次のとおりです。
- 1) 実機検証で基礎数値を取得してサイジング
- 実際にハードウェア、ミドルウェアを用意して検証環境を構築し、システムに負荷をかけることで限界キャパシティやスケーラビリティを確認する。最も精度は高いが、実施するためのコストと時間も大きい。
- 2) 類似システムからのサイジング
- システムの更改や拡張であれば、「現行」システムが存在しているはずなので、そのスペック情報やリソース情報を取得して類推を行う。このときの類推に使うベンチマーク指標値としては、SPEC（https://www.spec.org/）などが公表している数値が一般的。あくまで机上計算のため、1)に比べれば精度が落ちる。
- 3) 机上サイジング
- 2)のように参考にできる先行事例すら存在しないケース。先述のSPECやTPCを使って見積もるしかないが、精度が最も悪いため、大きめの安全率を見込むとともに、スケールアウト／スケールアップが可能な構成としておくなどのリスクヘッジが欠かせない。
サイジングの精度は、1)が最も高く、3)が最も低くなります。実施コストという面では、逆に1)が最も大きく、3)が最も小さくなります。実際には、それほど特殊なシステム構成を採用したり、初物のハードウェアやソフトウェアを利用するのでなければ、少なくとも何らかの類似システムを参考にできる2)の方法で対応できます。
RDBMSのライセンス料金は高い
このケースでは、お客様の元に運用中の類似システムがあったため、それをベースに各サーバのサイジングを実施しました。そこで明らかになったのは、ハードウェアとソフトウェアの調達費用に、当初想定した2倍以上の予算が必要という事実でした。さらに、予算の75％を占めているのが、商用RDBMSのライセンス費用であることも分かりました。
「かなり極端な例だろう」と思われるかもしれませんが、ソフトウェアライセンス費用の中で最大の割合を占めるのがRDBMSであることは、珍しくありません。大量のデータを管理するため、RDBMSは非常に複雑な機能を持っておりソフトウェアとしても巨大です。また、パフォーマンス、セキュリティ、バックアップ、クラスタリングなどのオプション機能が必要になるケースも多く、それがライセンス料金を膨らませる一因となります。
ライセンス料金の安い他のRDBMSやオープンソース製品への乗り換えは、既存アプリケーション資産の単純な流用ができない、セキュリティなど必要な機能を充足できないといった理由から認められませんでした。だからといって、費用の増加が簡単に認められるわけではありません。かくしてまかせいのうでは、全力で次のミッションに取り組むことになりました。
ハードウェア／ソフトウェア費用を削減しろ。
ただし、機能・非機能要件を落としてはならない。
これは、無理なダウンサイズによってシステムの機能不全を招くリスクがある危険なミッションです。唯一幸いだったのは、本システムはプライベートクラウド上に構築されていたため、負荷試験によるPoC（Proof of Concept）を実施したのちにサーバスペックを確定することができた点です。環境構築とスケールアップ／スケールアウトが容易なクラウドの利点が活きました。
