「止まらない」「増やせる」「素早く追従する」。可用性、スケーラビリティ、弾力性の3語は、どれも「クラウドは強い」という話の中で一緒に出てくるので、なんとなく同じものに見えます。AZ-900でも、問題文の条件からどれに当たるかを選ばせる形で問われやすいところです。
見分けるコツは、その言葉が何に備えているのかを先に考えることです。可用性は故障に、スケーラビリティは需要の量に、弾力性は需要が変わる速さに備えます。この記事では、3語の定義をそろえたうえで、実際の設計では3語が互いに影響し合うことまで整理します。
可用性：壊れないことではなく、止まる時間を短くすること
可用性が高いとは、停止時間を最小限に抑え、必要なときに使える状態を保つことです。「絶対に障害が起きない」という意味ではありません。物理的な機械である以上、サーバーも電源も回線もいつかは壊れます。壊れない1台は存在しないので、壊れる前提で、使えない時間をどれだけ短くできるかを考えます。
これを支えるのが二つの言葉です。
- 冗長性：同じ役割の資源を複数用意しておくこと。「備える」側の言葉です。
- フェイルオーバー：異常を検知したとき、別の資源へ処理を引き継ぐこと。「切り替える」動きの言葉です。
1台構成なら、その1台が止まった時点でサービスも止まり、直し終わるまで戻りません。2台を用意しておき（冗長性）、片方が止まったらもう片方へ切り替える（フェイルオーバー）。切り替えの瞬間に短い中断はあっても、使えない時間は大きく減ります。
自社で運用する場合、この「2台目」はサーバーだけでは済みません。電源も回線も二重にし、使わない予備にも費用と運用の手間がかかります。Azureでは、物理的な冗長化の多くをMicrosoftが用意した基盤の上で、必要な部分に必要な分だけ、構成として組むことができます。ただし、何も設定しなくても勝手に止まらなくなるわけではありません。どこまで冗長にするかを選ぶのは利用者側です。可用性は「買って備える」ものから「設計して使う」ものに変わった、と捉えると分かりやすいでしょう。
スケーラビリティ：増やせる方向は二つある
スケーラビリティは、需要の変化に応じてリソースを増やしたり減らしたりできる能力です。朝の始業時にアクセスが集中する、季節やキャンペーンで波がある——システムへの需要は一定でないのが普通なので、この能力が重要になります。
増やし方には二つの方向があります。
| 垂直スケーリング | 水平スケーリング | |
|---|---|---|
| 別名 | スケールアップ／スケールダウン | スケールアウト／スケールイン |
| やること | 1台の性能（CPU・メモリ）を上げ下げする | 同じ役割の台数を増やし減らしする |
| Azureでの例 | 仮想マシンのサイズ変更 | 仮想マシンスケールセットの台数変更 |
| 向く場面 | 構成を変えずに性能だけ調整したい、小〜中規模で段階的に増強したい | アクセスの急な変動を受け止めたい、大規模な拡張が必要 |
| 限界・前提 | 用意されている最大のサイズが天井になる | どの台で処理しても同じ結果になるよう、分散できる作りであること |
垂直スケーリングは構成がシンプルなままで済む反面、1台の上限に早く届きます。水平スケーリングは台数を大きく増やせる反面、入ってきた要求を複数台に振り分ける仕組み（ロードバランサーなど）が要り、アプリケーション側も「どの台が処理しても同じ結果になる」作りでなければ効果が出ません。人の仕事で言えば、誰がやっても同じ結果になる作業でなければ、人数を増やしても仕事を分けられないのと同じです。
実際のシステムでは、どちらか一方を選ぶのではなく、部分ごとに向いている方を当てはめて組み合わせます。
弾力性：どこまで増やせるかではなく、どれだけ速く追従できるか
弾力性（エラスティシティ）は、需要に応じて素早くリソースを増減できる性質です。スケーラビリティと混同しやすいのですが、見ている点が違います。
- スケーラビリティ：増減できるか、どこまでできるか（例：100台までスケールアウトできる）
- 弾力性：その範囲の中で、需要の変化にどれだけ速く追従し、需要が落ちたらどれだけ速く戻せるか
増やせても反映までに時間がかかりすぎれば、急なアクセス増には間に合いません。弾力性はスケーラビリティがあることを前提に、その速さに注目した言葉です。自動化と組み合わせることが多いものの、自動でなければ弾力性と呼べない、というわけではありません。
Azureの仮想マシンスケールセットでは、自動スケーリングの条件を決められます。たとえば「平均CPU使用率が80%を超えたら1台増やし、20%を下回ったら1台減らす。最小2台、最大20台」といったルールです。「最大20台」がスケーラビリティの範囲で、条件を満たしたら人手を介さずに台数が変わる仕組みが弾力性を支えています。
3語は、何に備えるかで見分ける
問題文でどの言葉が問われているか迷ったら、次の対応に戻ります。
| 状況 | 主に当たる言葉 | 手がかりになる語 |
|---|---|---|
| 障害が起きても使い続けたい | 可用性 | 冗長性、フェイルオーバー |
| アクセスの増加に備えて増強できるようにしたい | スケーラビリティ | 垂直・水平、スケールアップ・スケールアウト |
| 急な変動に素早く追従したい | 弾力性 | 迅速、自動 |
| 同じ役割の資源を複数持ちたい | 可用性（冗長性） | 冗長 |
「増強したい」の問題に弾力性が無関係とは言えませんし、「資源を複数持つ」はスケーラビリティにも関わります。それでも、問題文が何を心配しているか——故障か、量か、速さか——を読めば、主に問われている言葉は一つに絞れます。
設計では、3語が互いに足を引っ張ることがある
用語の区別ができたら、もう一歩だけ進めておきます。現実の構成では、この3つは独立していません。
垂直スケーリングは、1台構成のままだと可用性を下げる瞬間があります。 Azureの公式ドキュメントでは、稼働中の仮想マシンのサイズを変更すると再起動が発生し、中断を伴う操作として扱うよう説明されています。性能を上げるための操作そのものが、短い停止を生むわけです。1台で動かしているシステムを「サイズを上げれば大丈夫」で乗り切ろうとすると、スケーラビリティのために可用性を削ることになります。
水平スケーリングの最小台数は、可用性の設計でもあります。 スケールセットの最小台数を1にすれば、アクセスが少ない時間帯には1台構成、つまり冗長性がない状態になります。最小を2にしておけば、需要が小さいときでも1台の故障で止まらない構成を保てます。台数の下限は、コストだけで決めてよい値ではありません。
同じ場所に2台あっても、同時に止まる可能性は残ります。 2台が同じ設備の上にあれば、その設備の障害では両方とも止まります。どの単位で分散させるか（データセンター、可用性ゾーン、リージョン）という話が、この先のAZ-900の範囲につながっていきます。
3つの言葉を正しく区別し、その上で「この操作は別の性質を削っていないか」と問い直す。ここまでできると、試験の選択問題を解くだけでなく、実際の構成を見て弱点を言えるようになります。
なお、3語の定義と、1台構成から冗長構成へ移る図はAZ-900 第2回の動画（無料・約26分）で、手の動きも交えて順に説明しています。自分の言葉で説明できるか確かめる前に、一度通して聞いておくと定着が早くなります。また、自動スケーリングの条件（最小・最大台数、増減のしきい値）が実際のポータル画面でどう並ぶのかは、仮想マシンスケールセットの回（無料）で作成画面を操作しながら確認できます。
