あの鷲尾です。
最近は年金のセキュリティ問題で騒がしくなっていますね。
メールを開いて、明らかにあやしいURLを信頼してしまって開いてしまったとのことですが、
これはどこの会社でも起きうることですね。
特に、社員のITリテラシに偏りがある企業や昔からのやり方を変えていない企業、もしくは同じ作業を同じ人が同じ技術で行っている場合などは、特にITリテラシー（情報セキュリティリテラシー）が偏ってしまうのではないかと思います。
この事件の余波はマイナンバー制度にももちろん大きく影響し、マイナンバー制度の採択にもいろいろと問題が発生していますね。この問題については近々追って触れたいなと思います。
さて、先日は、Azureのインスタンス起動と停止をA-AUTO 50で最適化して、コストを削減しましょう！という記事を書きました。
その際、Azureのことを調べていく上で、「可用性セット」、「ロードバランサ」、「リソースグループ」に「負荷分散エンドポイント」といったキーワードがたくさん出てきまして、初心者の私にはこんがらがってしまい、概念を理解するのが非常に大変でした...
そこで今回は、以上４つのAzureの機能について、なるべくわかりやすく紹介していきたいと思います。
※私も勉強中なので、記事に間違いなどがあればご指摘願います。
１．可用性と可用性セット
■そもそも可用性とは
可用性とは、一言でいうと「システムの壊れにくさ」です。
例えば、あるWebサービスがあるとします。このWebサービスは、サーバA上で動作しています。この状態でサーバAが壊れてしまった場合、当然ですがWebサービスは提供できません。サーバ１台で動かしていて、その１台が壊れた時の対策も特にしていない場合、これは可用性が低いと言えます。
では、サーバAの他に待機用サーバBを用意しておき、なにかあったらサーバBに切り替えよう！という体制をとっていた場合はどうでしょう。サーバAになにか障害などが発生したとしても、待機用のサーバBがWebサービスを提供できるため、Webサービスの提供は止まりません。これは先ほどの例に比べて可用性が高いと言えます。
まとめると、可用性とは、「どれだけいつでも使える状態にあるか」を意味しているということになります。
Azureでは、システムの可用性を高めるために「可用性セット」というものが用意されています。セットとありますが、深く意識しすぎてしまうとまたこんがらがってしまうので、はじめは「そういう名前なんだ」と思っておけばよいかと思います。
■可用性セットとは
Azureは、インスタンスのアップデートやメンテナンスのために私たちが利用しているインスタンスを停止することがあります。これはAzure側で行うことなので私たちにはどうしようも出来ないのですが、この可用性セットを指定することで、少なくともインスタンス1台は停止されません。
※必ず１台は動作しているということです。
そうすることで、例えばメンテナンス時などにわざわざインスタンスを停止することを周知したりしなくて済むわけです。
ただし、この可用性セットは、あくまでも「Azure側」による操作（インスタンスのアップデートやメンテナンス、もしくはハード的な物理障害など）によってインスタンスを停止されてしまう場合にのみ有効な手段です。したがって、たとえ可用性セットを作成していたとしても、インスタンスが停止してしまうような操作（後述：インスタンスサイズの変更など）をユーザ自身で行なってしまうと、その間にAzure側のメンテナンスがあった場合にもう1台のほうが停止してしまう可能性があります。その点、注意しなければいけません。
ここまでで、可用性と可用性セットの説明になります。
可用性セットを設定しておくことで、急な障害などが発生したとしても、それに対応することができるというわけですね。
続いては、Azureの機能の代表格、オートスケールによるロードバランスです。
２．ロードバランサ？オートスケール？
■ロードバランサとは
ロードバランサとは、Webサイトなど、１か所にアクセスが集中した時にその負荷を分散させる装置のことです。高負荷処理を１台で処理してしまおうとすると、CPU使用率などが上がり続け、不安定な動作をするかもしれません。しかし他のマシンにその負荷を分散させることができれば、負荷は軽減されますよねっということです。
その、実際に振り分け役を担うのがロードバランサです。
■そもそもスケーリングとは
スケーリングとは、「サーバの台数を物理的に増やしたり、CPUのやメモリなどの処理能力を高くすること」です。一般的に、サーバの台数を増やすことをスケールアウト、サーバのスペックをあげることをスケールアップといいます。
Azureでは、このうちスケールアウトを自動で行ってくれます。
この自動でスケールアウトしてロードバランシングしてくれる機能を、「オートスケール」と呼びます。
※ オートスケールすることをオートスケーリングと言います。
オートスケーリングを行う際には、事前にポータル画面から"リソースグループ（※ 後述）"と"可用性セット"を作成し、"トリガー"を設定します。トリガーでは、「なにをもってしてスケールアウト用のインスタンスを動作させるか」を定義することが出来ます。
例えば、「CPUの使用率が60％以上になったら、待機用のインスタンスを起動する」というようなトリガーを設定することが出来ます。これを設定しておくことで、トリガーの起動条件に合致した時に待機用のインスタンスが自動で起動します。
また、「CPUの使用率が20％以下になったら、自動起動したインスタンスを自動停止させる」というように、CPUの使用率に下限を設定することも出来ます。これは、メインのインスタンスのCPUの使用率が低い時は処理能力にまだ余裕があるので、無駄なインスタンスは停止させて最小限のインスタンスで動作するように構成（節約）しましょう！というもので、非常にお財布にもやさしい"自動縮退"運転機能なのです。
※待機用インスタンスとあるところは、同じクラウドサービス、もしくはローカルネットワーク上にデプロイされたインスタンスを指しています。
※料金は使った分だけ、サイズに応じて分単位で課金されます。
３．リソースグループ
ここまで可用性セットやオートスケーリングに関して説明をしてきましたが、前提として、実はリソースグループというものを作成しておき、そこに関連づいている必要があるんです。
リソースグループとは、DBなどの各リソースを一つの大きなグループとして管理されたものの事です。普通、Webサイトなどを構築する際は、様々なDBやその設定などが必要で、ひとつひとつ管理する必要があります。しかし、リソースグループという概念でそのWebサイトなどを管理すると、ポータル画面からはひとつの大きなリソースグループ（さまざまなコンポーネントの集まり）として管理することが出来るのです。
可用性セットを作成するためには、このリソースグループを予め作成しておき、そのリソースグループに可用性セットを作成します。
４．負荷分散エンドポイント
名前だけ見ると非常に難しそうな感じがしますが、エンドポイントとは、ポート番号のことを指しています。ひとまず"負荷分散"という言葉は置いておいて、エンドポイントという言葉を整理します。
先程も書いたように、エンドポイントとは、ポート番号のことを指しています。例えばインスタンスを新規にポータル画面から作成するときのことを思い出してみてください。PowerShellからの通信と、リモートデスクトップの通信を許可していた（デフォルト）と思います。あそこで設定したのが、PowerShellなどが通信するためのエンドポイント（ポート番号）なのです。
さて、負荷分散エンドポイントですが、これは、「特定のポートで受信したトラフィック（負荷）を他のインスタンスに分散させる」目的で使用します。例えば、インスタンスAは80番ポートを使用したトラフィック（httpなど）を受信するとします。この時、負荷分散エンドポイントに「インスタンスAで受信した80番ポートを使用したトラフィックを、他のインスタンス（B,C,D...）に分散させる」と設定することができます。
こうすることで、インスタンスAが処理するトラフィックを他のインスタンスに分散することができ、結果的にインスタンスAの負荷分散が実現出来るのです。
５．まとめ
ここまでで、ざっと可用性セット、ロードバランサ、オートスケーリング、リソースグループ、そして負荷分散エンドポイントについて説明してきました。
では、ここまでの内容を図とともにまとめます。
■可用性セット
→ Azure側で行われる不定期なメンテナンスや障害時に、同時に2台が停止されないよう、事前に設定しておくもの。イメージ的には、Azure側に「同時には停止しないでね」と、事前にお願いしておくような感覚に近い。
■オートスケーリング
→ ロードバランサ用のインスタンスを予め用意しておき、ポータル画面から設定しておいたトリガー（ＣＰU使用率の上限、下限など）をもとに自動的にロードバランシングをしてくれる機能のこと。
■リソースグループ
→ ひとつのWebサイトを構成している各リソースを束ねた一つの単位のこと。リソースごとに管理するのではなく、リソースグループに設定されているリソースをひとつのまとまりとして管理することが出来る。
■負荷分散エンドポイント
→ 指定したポート番号のトラフィックを、別のインスタンスに分散させることが出来る機能です。予め負荷分散させたいトラフィックのポート番号を設定しておくことで、そのポート番号で受信したトラフィックを別のインスタンスに分散させることができる
以上のような設定をしておくことで、インスタンスの可用性を高めることができるようになり、安心してAzureを使用することができます。
ここまで、「現状のインスタンスには変更を加えずに」ロードバランシングや可用性の向上をさせる設定などを行いました。
しかしAzureには、こういったスケールアウトな方法による対処のほか、高負荷処理に対応するために直接インスタンスのサイズを変更させる方法（スケールアップな方法）もあります。
それが、インスタンスサイズの変更です。
【インスタンスサイズの変更について】
インスタンスには、「どれくらいのスペック」で、「どれくらいの処理能力があって」、という、"インスタンスサイズ"というものが存在します。
インスタンスサイズは、インスタンスを作成する際にはじめに設定するものですが、途中からサイズを変更することができます。
※ インスタンスサイズの変更はPowerShellからでもポータルからでも行えますが、どちらにせよ、インスタンスの再起動を伴います。
Azureでは、インスタンスサイズの大小に関わらず分単位で課金がされます。また、インスタンスサイズが大きくなればなるほど、分単位での課金額も高くなっていきます。
したがって、「普段はなるべく小さいインスタンスサイズで処理を行い、パワーが必要なときだけインスタンスサイズを大きくして高負荷処理を行う」 というのが理想的な課金体制になるわけです。
では、例えば予めパワーが必要な時間帯や日がわかっていた場合、それに合わせてインスタンスサイズを変更することで、課金額を少しでも減らすことが出来ますよね！
そこで次回は、インスタンスサイズを変更するスクリプトを実際に作成して、インスタンスサイズを変更するタイミングをA-AUTO 50で制御したいと思います。
それでは次回お楽しみに。
0 件のコメント:
コメントを投稿