ほとんどのアプリケーションプロバイダーにとって、アプリケーションのトラフィックや利用が増えれば、ビジネス機能を処理するために必要なインスタンスやサーバ数は増える。同様に、特定の時間帯や曜日にアプリケーションの利用が低下する場合は必要なインスタンスは減る。計画段階では、想定されるユースケースやコスト、性能に与える影響、インフラニーズに応じてどのようなスケーリングを使うかを決める必要がある。

　本稿ではAWSの「Auto Scaling」と「Amazon Elastic Load Balancing」（Amazon ELB）、組織が突き当たる溝や障壁、それに対処するためのアイデアについて解説する。

Auto Scaling

　AWSのWebサービスツール「Auto Scaling」では、必要な容量を事前にカスタマイズして、設定された値や需要に応じてインスタンスを自動的にスケーリングする状況を個々に設定できる。スケールアップ／スケールダウンを実行する値は組織が設定する。例えばCPUの平均利用時間が65％に達するとAuto Scalingが作動して、ニーズに応じたインスタンスが追加されるよう設定できる。Auto Scalingでインスタンスを10％減らすことも可能だ。インスタンスは設定に基づいて自動的に追加されたり削除されたりする。ただし行動を起こす前にAuto Scalingを特定時間待機させたり、インスタンスの追加や削除を行う前に再検討させたりする冷却期間の設定を検討することも重要だ。Auto Scalingは基本的に、ユーザーが定義した設定に基づきクラウドインスタンスをAWS内で起動したり終了したりできるWebサービスといえる。

　さらに、特定数のインスタンスを実行する設定にしている場合にもAuto Scalingは機能する。望ましいインスタンス数を設定したAuto Scalingグループを作成することにより、常時実行されるインスタンスの数を管理できる。グループ内のインスタンスは設定された容量の値に基づいてAuto Scalingで自動的に追加または削除される。Auto Scalingにはアプリケーションの利用状況に基づいて動的かつ予測的にサーバリソースをスケーリングできる機能がある。適切な値を設定するためには、負荷テストを行うか、時間の経過に伴う実際のアプリケーションの反応を継続調査して、時間の経過に伴うアプリケーションの反応を調べる必要がある。いずれのケースでも、最も効果的なユーザーの反応を引き出すためにはAuto Scalingの上の値と下の値を正確に判定する必要がある。

Amazon ELB

　Amazon ELBを有効にすると、アプリケーションのトラフィックが自動的に健全なサーバインスタンスに配分される。アプリケーションの耐障害性を高めるため、インスタンスは別々のアベイラビリティーゾーン（AZ）にグループ化され、また、アプリケーションのトラフィックは利用可能なサーバインスタンスに均等に分散される。

　Amazon ELBではインスタンスのヘルスチェックを行って、AZ全体の健全なインスタンスにのみトラフィックを流す。同ツール自体がAWS内で積極的にモニタリングされている。Amazon ELBのオプション使用の特筆すべきメリットは、手動で介入しなくても負荷分散とスケーリングが管理でき、組織のリソースを解放して別の場所に振り向けられる点にある。

　Amazon ELBを使うインスタンスに対して、同ツールが自動的に行うヘルスチェックの計画は重要だ。ヘルスチェック実行の値と、インスタンスがヘルスチェックに失敗した場合にトラフィックのルートを切り替えるまでの時間の値を設定する必要がある。例えば30秒ごとにヘルスチェックを実行するよう設定し、ヘルスチェック成功の回数を10に設定した場合、トラフィックがそのインスタンスに送られるまでに約300秒を要する。さらに、失敗の基準となる値も考慮しなければならない。失敗の基準を4回に設定し、ヘルスチェックを30秒ごとに行った場合、そのインスタンスが削除されてトラフィックのルートが変更されるまでに120秒かかる。

　Amazon ELBとAuto Scalingは相互運用が可能だ。アプリケーションの拡張性を高めるためにこの2つを組み合わせ、両方の機能を活用することは検討の余地がありそうだ。

追加的ニーズへの対応

　AWSのスケーリングツールは大部分のユースケースで効果が実証されているが、中には機能を追加するためカスタム版ツールを開発する必要に迫られる企業もある。その一例として、オンライン映画レンタルサービスの米Netflixは、Auto Scalingを補うために社内で開発した「Scryer」というツールを使っている。

　ScryerはNetflixが特定した以下の問題に対応することによって、Auto Scalingを強化する。

• 需要の急増
• 「再試行ストーム」による障害
• 時間ごとのトラフィックパターンの変化

　組織によっては、AWSのツールセットが現在対応していないさまざまなビジネスニーズを処理するために、AWSのスケーリングツールを補完するツールの開発が必要だと判断することもある。

　アプリケーションを開発している組織は全て、顧客を満足させられる性能やスケールを保証しなければならない。インターネットアプリケーションの顧客は高いレベルの性能とセキュリティ、機能の組み合わせを期待する。あらゆるオプションを組み合わせ、シームレスで高速かつセキュアな高い使用感を実現するためには、スケーリングの計画が必要だ。