スケーラビリティは、エンタープライズ ソフトウェアに不可欠な要素です。

ソフトウェア設計は、開発者がクライアントの時間と予算の制約の中で最高の製品を作成するために働く、バランスをとる行為です。 プロジェクトの要件を満たすために、それが技術的か金銭的かにかかわらず、トレードオフを行わなければなりません。

しかし、あまりにも頻繁に、企業は拡張性よりもコストを優先し、あるいはその重要性を完全に否定します。 これは残念ながらビッグ データ イニシアチブでよくあることで、スケーラビリティの問題が有望なプロジェクトを沈没させる可能性があります」

スケーラビリティは「ボーナス機能」ではありません。 スケーラビリティを念頭に置いて構築することで、長い目で見て時間とお金の両方を節約することができます。

「作業負荷」とは、同時ユーザー、ストレージ容量、処理される最大トランザクション数、またはシステムを元の容量を超えて押し上げるその他のものを指す場合があります。

スケーラビリティは、スケーラブルでないソフトウェアが限られた容量でうまく実行できるという点で、プログラムの基本要件ではありませんが、ユーザーの要求に応じて成長または変化するソフトウェアの能力を反映しています。

基本機能を超えて拡張する可能性のあるソフトウェア、特に、ビジネス モデルがその成長に依存している場合は、スケーラビリティを考慮して構成する必要があります。

たとえば、データ インテリジェンスのパイロット プログラムを開始する企業は、大規模なエンタープライズ アナリティクス バンドルを選択できますが、最初に必要な機能だけを処理するソリューションから始めることも可能です。

規模が大きくなり、より多くの分析プログラムを使用するようになった場合、複数の視覚化プログラムを操作したり、まったく新しいシステムを構築したりする代わりに、それらのデータ ストリームをダッシュボードに追加することが可能です。

この方法で構築することにより、将来の成長に備えるとともに、余分な複雑さを排除して現在のニーズに合ったより無駄のない製品を作成できます。

また、初期の資金支出を少なくする必要があるので、ビッグ データ投資の規模について心配している経営者にとって大きな考慮事項となります。 既製の分析パッケージは、企業が進化する市場の需要に対応するためにシフトすると、関連性を失う可能性があります。

拡張可能なソリューションを選択すると、初期のテクノロジー投資が保護されます。

変更するとき、堅牢でスケーラブルなソフトウェア上に構築することは、敏捷性の低いプログラムを適応させようとするよりもかなり低コストです。

また、まったく新しいソフトウェアを実装するよりも、新しい機能をオンラインで提供する方が「立ち上げ」時間が短くなります。

The Fallout from Scaling Failures

So, what happens when software isn’t scalable? アプリの初期段階では、ワークロードは軽いものです。 比較的少数の同時ユーザーでは、アーキテクチャに対する要求はそれほど多くありません。

作業負荷が増加すると、問題が発生します。ソフトウェアが保存するデータまたは同時ユーザーの数が増えるほど、ソフトウェアのアーキテクチャにかかる負担は大きくなります。 パッチは初期の問題のいくつかを軽減するかもしれませんが、パッチは複雑さを増します。

複雑さは、継続的に問題を診断することをより面倒にします（翻訳：価格が高く、効果的でない）。 その他の潜在的な問題としては、可用性の低下やデータの損失があります。

従業員は、自分の仕事を終わらせるために、信頼性の低いソフトウェアの回避策を見つけるでしょう。

その結果、企業はデータ漏洩やそれ以上のリスクにさらされます。 40%は、代わりに競合製品に直行します。

スケーラビリティの問題は、小さな会社が犯す新手のミスだけではありません。 ディズニーでさえ、Applause アプリを最初に立ち上げたとき、視聴者にお気に入りのディズニー番組と対話する追加の方法を提供することを意図していたため、問題に直面しました。 このアプリは、同時ストリーミング ビデオ ユーザーの殺到に対応できませんでした。

不満を感じたファンは、Google Play ストアでアプリの星が 1 つになるまで、否定的なレビューを残しました。

Setting Priorities

ビジネスによっては、スケーラビリティがすぐに役立つとは思えないために、スケーラビリティを優先できない場合があります。

プロトタイプや少量の概念実証を目的としたソフトウェアは、問題を起こすほど大きくはなりません。

同様に、潜在的なユーザーの固定数が少ない小さな会社の内部ソフトウェアでは、別の優先順位を設定できます。

最後に、ACID コンプライアンスが絶対に必要な場合、スケーラビリティは信頼性よりも後回しになります。

しかし一般的に、スケーラビリティは最初から考慮すれば、より簡単で資源消費も少なくなります。 新しいデータベースへの移行は、費用と時間がかかります。

Principles of Scalability

Several factors affect the overall scalability of software:

Usage

Usage measures the number of simultaneous users or connections possible.

Maximum stored data

これは、ユーザーがアップロードしたコンテンツ、サイト レポート、ある種のマーケティング データなど、多くの非構造化データを扱うサイトに特に関連します。 これらの種類のコンテンツによって保存されるデータ量は、予期せず劇的に増加する可能性があります。

最大保存データ量を迅速に拡張できるかどうかは、データベース スタイル (SQL vs NoSQL サーバー) に大きく依存しますが、適切なインデックス作成に注意を払うことも非常に重要です。

コード

経験の浅い開発者は、スケーラビリティを計画する際に、コードの考慮事項を見落としがちです。 優れた開発者は努力の重複を避け、コードベースの全体的なサイズと複雑さを軽減することを目指します。

アプリケーションは進化するにつれてサイズが大きくなりますが、コードをきれいに保つことでその影響を最小限に抑え、「スパゲッティ コード」の形成を防止します。 ディスク容量やより高速な中央処理装置 (CPU) を使用して、増加した作業負荷を処理します。

スケールアップはスケールアウトよりも優れたパフォーマンスを提供します。 すべてが 1 つの場所に含まれているため、リターンが速く、脆弱性が少なくなります。

スケールアップの問題は、成長する余地が限られていることです。 ハードウェアは、高度化すればするほど高価になります。

これらの制限により、垂直スケーリングは、ほとんど予告なく迅速に成長する必要のあるソフトウェアには最適なソリューションではありません。

スケールアウトする場合、ソフトウェアは、より高度なハードウェアではなく、より多くのハードウェアを使用し、新しいインフラストラクチャに増加したワークロードを分散させることによって成長します。 水平方向にスケールされたソフトウェアは、サーバーが通信できる速度によって制限されます。

しかし、その差はほとんどのユーザーが気づくほど大きくはなく、開発者がその影響を最小限に抑えるためのツールもあります。 その結果、スケーラブルなアプリケーションを構築する場合、スケールアウトがより良いソリューションと見なされます。

Guidelines for Building Highly Scalable Systems

計画段階でスケーラビリティを考慮することは、安価で簡単です。

負荷分散ソフトウェアを使用する

負荷分散ソフトウェアは、分散インフラストラクチャを持つシステム (水平方向にスケールされたアプリケーションなど) に不可欠です。 これは、パフォーマンスの問題を避けるために絶対に必要です。

ロケーションの問題

拡張可能なソフトウェアは、できるだけクライアントの近く（アプリケーション レイヤー）で行います。 コア リソースの近くでアプリがより重いトラフィックをナビゲートしなければならない回数を減らすことは、より速いスピードとサーバーへのストレスの軽減に繋がります。 リソースを大量に必要とするアプリケーションが増える中、できるだけ多くの作業をデバイス上で行うことで、信号の少ないエリアやネットワークの遅延の影響を低く抑えることができます。

可能な限りキャッシュする

セキュリティの懸念を意識して、キャッシュは同じタスクを何度も実行する必要がないようにする良い方法です。

Lead with API

ユーザーはさまざまなクライアントを通じて接続するので、特定のクライアント タイプを想定しない API でリードすればすべてのクライアントにサービスを提供できます。

非同期処理

前の処理が完了するのを待つ必要のない、個別のステップに分けられた処理を指します。「非同期処理により、大規模なソフトウェアのパフォーマンスに影響を与えるボトルネックのいくつかが取り除かれます。 複数の要求が同じリソースから同じ計算を要求する場合、最初の要求を終了させ、その結果だけを使用するようにします。

スケーラブルなデータベースを使用する

NoSQL データベースは、SQL よりもスケーラブルである傾向があります。 SQL は読み取り操作を十分にスケーリングしますが、書き込み操作になると、ACID 原則を強制するための制限に抵触します。

NoSQL をスケーリングするには、これらの原則にあまり厳密に準拠する必要がないので、ACID コンプライアンスが問題でなければ、NoSQL データベースは正しい選択かもしれません。 スケーリングは、サブスクリプション レベルをアップグレードするのと同じくらい簡単です。

FaaS

Function-as-a-Service は PaaS から発展したもので、非常に密接に関連しています。 サーバーレス コンピューティングは、任意の時点で必要な機能のみを使用する方法を提供し、バックエンド インフラストラクチャへの不要な要求を削減します。

FaaS はまだ成熟していませんが、拡張性を改善しながら運用コストを削減する方法として検討する価値があるかもしれません。

保守を忘れない

自動テストと保守のためにソフトウェアをセットアップし、成長したときに保守作業が手に負えなくならないようにする

Build with An Eye to the Future

拡張性を優先することは、ビジネスの成功の準備になります。 早期に検討することで、最も必要とされるときに、俊敏性のメリットを享受することができます。 このような場合は、当社の開発担当者にご相談ください。