マジで何も知らないけどAWSの勉強をする 7日目
※この記事含む「マジで何も知らないけど～」で始まる記事は
マジで何も知らないIT関連職種に就いている男が学習の履歴を残しているだけのものになります。※
こんばんは！今日もやってきました。
今回はDay6でした。
１．Day6でやったこと
★ELBを使ってみよう★
ELBとはAWS上で使えるロードバランサーのことです。
ロードバランサーって何？という感じなんですが…
ロードバランサーとは
例えばWebサーバーがあったとして、たくさんのアクセスが殺到したとする。
アクセス過多でサーバーが壊れたり、停止したりすることが考えられる。
こういうとき、同様の処理ができるWebサーバーをもう一台立てておいて、それをロードバランサーに登録しておく。すると、ものすごい量のアクセスがあった際ロードバランサーがアクセス（情報のリクエスト）を二台にいい具合に分散してくれる。
ロード（読み込み先）のバランサー（調整役）ということ。
ELB（AWSで用意されたロードバランサー）の機能
・負荷分散
EC2インスタンスにかかる負荷を分散する。
・ヘルスチェック
ELBに登録されたインスタンス群から、正常に動作しているものにだけリクエストを振ってくれる。異常があるインスタンスは割り振り先から除外してくれる
・オートスケーリング
一定の閾値を設定しておくと、そこを超えたとき、割ったときでEC2インスタンスを増やしたり減らしたりしてくれる。ものすっごい便利。
★AWSにおける設計★
AWSでは「可用性」「冗長性」といった観点が非常に重要視されています。
そのために重要なのがSPOF（単一障害点）を無くすこと。難しい言い方をしていますが、要は「ここが壊れるともうその機能使えませ～～～ん」というポイントをできる限り無くしましょうという話です。
それを体現したようなサービスとしてELB（ElasticLoadBalancer）が存在しています。
前回はRDSを使ってDBの単一障害点を無くしましたので、今回はELBでWebサーバの方のSPOFを無くしましょうという感じです。
※ちなみに、SPOFを減らすためのサービスは他にもたくさんの種類があるそうです。
２．Day6で困ったこと
今回は意外と困ったことは起こりませんでした！
流石にLinuxの操作やサーバの接続、相関関係は飲み込めてきたように感じます。
強いて言えばロードバランサーの性能が上がっている（？）事で、
講座内での処理の負荷と実際の処理の負荷との間の差分が大きくなって
オートスケーリングの検証がすんなりとはいかなかった、という点くらいでしょうか。
あと、ステートレス・ステートフルなど、まだまだ用語の理解が足りていません…
３．Day6で学んだこと
AWSではとにもかくにも冗長性の確保が重要！
また、それを実現するためにも「各サービスの守備範囲」をしっかり理解しておく必要があると感じました。
ELBは複数のAZをまたぐ形で利用できるので、その特性を活かす設計が必要そうです。
今日は短いですがここまでです。
