none
Azureでのオートスケーリングについて RRS feed

  • 質問

  • Azure初心者です。

    質問させていただきます。

    現在クラウドサービス上に2つのインスタンス(A,B)がデプロイされ、起動しています。

    このうち一台のインスタンスへの負荷が集中した場合に、リソースを増減させて安定稼働を実現したいのです。

    しかし、Azureでのリソースの増減の概念が、公式サイトなどを読みましたがよく理解できません。

    1.外部からのアクセスが集中した際のAzureでのリソースの増減は、予めリソースを決めて同一クラウドサービス上に作成したインスタンス(リソースグループに登録済み)を使用して、ロードバランサーとしての機能を担わせることでリソースの増減(負荷分散)が図れる(事前に負荷分散用のインスタンスを作成しておく必要がある)という認識で合っていますでしょうか。

    2.例えばインスタンスA内での処理負荷が高くなり、常にCPU使用率が高くなってしまう場合などに、動的にCPUなどのリソースを増減(もしくは変更など)させることはできるのでしょうか。こちらはインスタンスの内部的なリソースの増減に関してですが、可能でしょうか。

    1,2に関してですが、どちらもAzurePowerShell(AzureResourceManagerに変更後)からコマンドレットによる操作を行うことは可能でしょうか。

    よろしくお願いいたします。



    • 編集済み ewewewm 2015年6月2日 2:23
    2015年6月2日 2:19

回答

  • > リソースグループに登録するインスタンスには、作成上なにか制約などはあるのでしょうか

    制約はありませんが、ロードバランシングする以上は同じ機能のものでなくては意味がありませんし、そうすると仮想マシンを複製して作るのが一番手っ取り早いでしょうね。

    > 青天井に課金がされてしまうのではないか。

    事前にリソースグループに登録しておいた仮想マシンのインスタンス数を超えてスケールする事は無いので、青天井って事にはならないかと。

    > Q.インスタンスAにリソースグループ(インスタンスB,C,D...K)を関連付けておくだけで、
    >自動的にロードバランサがされるのでしょうか。
    > Q.リソースグループに登録されているインスタンスのうち、「何台までロードバランサの対象として動作させるか」を、
    >管理ポータルのスライイドバー(インスタンス数)で設定できるのでしょうか。

    YES

    > 解決方法2:もっとスマートな方法はないものかと考えております。

    仮想マシンを使う限りは無いです。あくまでx64サーバーをエミュレーションしているに過ぎませんから、もととなるx64サーバーに存在しないような、動的CPUの追加とかメモリの追加には対応しようがありません。仮に作ったとしてもx64サーバーを前提としたOSでは機能しないでしょう。



    甕星

    • 回答の候補に設定 星 睦美 2015年6月2日 8:13
    • 回答としてマーク 星 睦美 2015年6月8日 2:30
    2015年6月2日 7:03

すべての返信

  • 仮想マシンのインスタンスの話ですよね?

    「1.」の理解であっています。逆にロードバランサなどを使った負荷分散を前提に設計していなかった場合、仮想マシンのインスタンスを増やすことで高負荷に対応することはできません。

    「2.」に関しては、仮想マシンのサイズを変更すればCPUの数を増やせます。CPU単体で増やすことは出来ません。また仮想マシンのサイズを変更する場合には再起動を伴います。


    甕星

    2015年6月2日 4:14
  • 甕星さん

    ご回答ありがとうございます。

    1.>逆にロードバランサなどを使った負荷分散を前提に設計していなかった場合

    リソースグループに登録するインスタンスには、作成上なにか制約などはあるのでしょうか(仮想マシンのオートスケールを設定する際、同一イメージの仮想マシンを用意する必要があるとの記事があったもので・・)

    2.>仮想マシンのサイズを変更する場合には再起動を伴います。

    再起動を行なわずに、動的にCPU等の内部リソースを増強することはできないものでしょうか(なるべくインスタンスは停止したくないもので・・・)


    行いたいこと:ある一定の時間になるとインスタンスAのCPUが高負荷状態になるため、その時間帯だけ内部リソース(CPUなど)を増強して安定稼働を実現したい

    解決方法1:高負荷状態になる時間帯はわかっているため、その時間帯に備えてインスタンスを停止→サイズ変更→再度起動を行い、高負荷処理が完了したらまたインスタンスを停止→サイズ変更→再度起動を行う

    解決方法2:もっとスマートな方法はないものかと考えております。

    危惧していること:オートスケール(Azureでは自動的に行なわれると聞いていますが・・・)を行なわれることで、青天井に課金がされてしまうのではないか。

    3.オートスケール、可用性セット、リソースグループ、ロードバランサの関係性がいまいち理解できていません。

    Q.インスタンスAにリソースグループ(インスタンスB,C,D...K)を関連付けておくだけで、自動的にロードバランサがされるのでしょうか。

    Q.リソースグループに登録されているインスタンスのうち、「何台までロードバランサの対象として動作させるか」を、管理ポータルのスライイドバー(インスタンス数)で設定できるのでしょうか。

    再度の質問になってしまいますが、よろしくお願いいたします。

    2015年6月2日 5:26
  • > リソースグループに登録するインスタンスには、作成上なにか制約などはあるのでしょうか

    制約はありませんが、ロードバランシングする以上は同じ機能のものでなくては意味がありませんし、そうすると仮想マシンを複製して作るのが一番手っ取り早いでしょうね。

    > 青天井に課金がされてしまうのではないか。

    事前にリソースグループに登録しておいた仮想マシンのインスタンス数を超えてスケールする事は無いので、青天井って事にはならないかと。

    > Q.インスタンスAにリソースグループ(インスタンスB,C,D...K)を関連付けておくだけで、
    >自動的にロードバランサがされるのでしょうか。
    > Q.リソースグループに登録されているインスタンスのうち、「何台までロードバランサの対象として動作させるか」を、
    >管理ポータルのスライイドバー(インスタンス数)で設定できるのでしょうか。

    YES

    > 解決方法2:もっとスマートな方法はないものかと考えております。

    仮想マシンを使う限りは無いです。あくまでx64サーバーをエミュレーションしているに過ぎませんから、もととなるx64サーバーに存在しないような、動的CPUの追加とかメモリの追加には対応しようがありません。仮に作ったとしてもx64サーバーを前提としたOSでは機能しないでしょう。



    甕星

    • 回答の候補に設定 星 睦美 2015年6月2日 8:13
    • 回答としてマーク 星 睦美 2015年6月8日 2:30
    2015年6月2日 7:03
  • 甕星さん

    何度もご回答いただきまして、ありがとうございます。

    仮想マシンを複製してリソースグループに登録、そのリソースグループをインスタンスAに関連付けることでロードバランシングができるということなのですね。

    仮想マシンを使う限りは出来ないとのこと、非常に納得致しました。仰るとおり、そもそものx64サーバに動的にリソースを変更できる機能が存在しないのだから、CPUやメモリの追加に対応のしようがないですよね。

    非常に勉強になりました。

    ありがとうございました。

    2015年6月2日 7:37