これは、クラウド・アプリケーションのスケーリングに関する2部構成のシリーズの最初の投稿です。この投稿では、コンポーネントごとに異なるスケーリング戦略がどのように適切であるかという基本的な概念について説明します。第2部では、リニア・スケーリングのゴールと、スケーリング・ニーズを満たすために使用できる具体的なツールやパターンについて掘り下げていきます！
最新のソフトウェア・アプリケーションでは、スケールを考慮した設計がますます必要になってきています。アプリケーションの使用量が増えるにつれて、ほんの数年前にはほとんど考えられなかったようなトラフィック量を処理する必要が出てくるかもしれません。
では、あなたが設計している新しいアプリケーションが、その利用とともに成長できることを保証するために、どのような手段を講じることができるでしょうか？
スケーリングとは何か？
スケーリングとは、アプリケーションで利用可能なリソースの量を増やしたり減らしたりして、さまざまな負荷に対応できるようにすることです。これは、どのようなタイプのコンピュート・リソースにも関係します： CPU、メモリ、ディスク、ネットワークI/Oなどです。
スケーリングの技術は、コストと利用率の微妙なバランスです。先にリソースを積極的にスケールアップすれば、コストは高くなります。支払っているリソースを十分に活用できていない場合（これを「オーバープロビジョニング」と呼ぶ）、アプリケーションは利益を生まないかもしれません。しかし、入ってくるトラフィックを処理するのに十分なスケールアップを行わなければ、ユーザーはパフォーマンスの低下や停止を経験するかもしれません。
ほとんどすべてのアプリケーションにおいて、スケーリングを成功させるには、次のような一連の手順を踏む必要があります：
・次にボトルネックになるシステムの部分を特定する。
・どのようなリソースやアーキテクチャの変更によって、そのボトルネックを超えてスケーリングできるようになるかを理解する。
・スケーリングが必要な時期をどのように把握し、時期が来たらどのようにスケーリングを実行するか、計画を立てる。
・次のボトルネックについても同じことを繰り返す！(プロからのアドバイス：次のボトルネックは必ずあります！）。
水平スケーリングと垂直スケーリング
システムのさまざまな部分を管理する中で、ボトルネックに対処する方法に影響する独自の制約に遭遇します。このプロセスにおける重要な決定は、水平スケーリングと垂直スケーリングのどちらを選択するかです。水平スケーリングはシステムにノードを追加することであり、垂直スケーリングは既存のノードの能力をアップグレードすることです。この決定は、システムのパフォーマンスを向上させる最も効果的な方法を決定する上で非常に重要です。
垂直スケーリング
垂直スケーリングは、理解するのが最も簡単なタイプのスケーリングである場合もありますが、依存するのは危険となりうる制限があります。垂直スケーリングとは、アプリケーションの実行に使用している「より小さな」リソースを、より大きなバージョンに置き換えるという考え方です。
垂直スケーリングについて話すとき、ほとんどの場合、アプリケーションの実行に使用するサーバーのサイズについて話しています。これはデータセンターにある物理サーバーかもしれないし、AWS EC2や他のクラウドプロバイダーの仮想マシンかもしれません。どちらの場合でも、これらのマシンには、（v）CPUコア、メモリ、ローカルディスクストレージ、ネットワークインターフェース（したがって、ネットワークI/Oの最大帯域幅）の固定割り当てがあります。アプリケーションがマシンを使い切った場合、これらのリソースの1つまたはすべてをより多く持つ、より大きなマシンにアップグレードするのは簡単なアイデアです。
これは特にリレーショナル・データベースでよく見られます。リレーショナル・データベースのトランザクションがアトミックであることを保証するのは複雑であるため、データベースは1台のマシンで実行されることが非常に多いのです。データベースを拡張する必要がある場合は、より大きなマシンに移す必要があるかもしれません。
しかし、これは想像以上に難しいのです。この戦略の問題点をいくつか挙げてみましょう：
・移行のダウンタイム：高度な移行戦略を持っていない限り、アプリケーションのメンテナンスウィンドウを指定し、新しいマシンに移行する間、ある程度の期間オフラインにする必要があるかもしれません。
・単一障害点：垂直スケーリングを追求する場合、通常、アーキテクチャの中で多くの責任を負うマシンが1台あることを意味します。このマシンに障害が発生すると、アプリケーション全体がダウンする可能性があります。
・上限： いつでも、1台のマシンに搭載できるCPUやRAMなどの数には上限があるります。アプリケーションの要件がこれを超えて大きくなると、それ以上拡張できなくなります。これは避けるべき重要な状況です。
水平スケーリング
一方、水平スケーリングとは、アプリケーションの実行に使用するリソースの量を増やすことです。つまり、アプリケーションがEC2 VM上で動作している場合、（同じサイズの）VMを追加することになります。アプリケーションがドッカー・コンテナで稼働しているなら、コンテナを追加することになります。これは、Kubernetesのようなプラットフォームの中核となる考え方です。
水平スケーリングにも課題がないわけではない。最も顕著なのは、VMやコンテナを追加すれば負荷処理能力が実際に向上するように、アプリケーションを記述しなければならないことです。これは通常、ロードバランサーの背後で実行される「ステートレス」アプリケーションを設計することを意味します。ロードバランサーにさらにノード（VMまたはコンテナー）を追加すると、ロードバランサーは負荷を均等に分散できるようになり、より多くのトラフィックを処理できるようになります。
これは、アプリケーションのノードのどれかが、いつでもどんなリクエストでも処理できる場合にのみ機能します（言い換えると、リクエストの処理は、前のリクエストのローカル状態に依存してはいけません）。もしアプリケーションがこの方法で動作するように設計されていれば、ロードバランサーに100や1000のノードを追加することは、現在のものより100倍や1000倍強力なサーバーに垂直方向にスケールしようとするよりも、通常はずっと簡単で現実的です！
リニア・スケーリング
リニアスケーリングは、アプリケーションをスケールするために設計する際に、私たち全員が理想とするものです。一言で言えば、アプリケーションにリソースを追加するたびに、容量とスループットを同じだけ増加させ、無限に拡張できるようにすることです。次回の記事では、これが実現可能かどうか、そしてその方法について掘り下げて説明します。
Momentoでアプリケーションのスケーリングを始めましょう。
Share
EN 
JP