いまさら聞けないELBのお話し

はじめに

こんにちは、園田です。

前回に引き続き、「いまさら聞けない」シリーズを開催したいと思います。
いまさら聞けないシリーズの第6弾は「ELB」になります。

記事はそれなりに書いているつもりですが、意外なことにELBについては一度も触れてなかったですね。ELBっていまさら感がありますからね。

今回のELBについては基本から、こんな感じで使うとよいのでは、というアドバンス的なところまでお話しできればいいなと思います。

恒例のAWS資料を貼っておきます。

ELBってなに？

いまさらきけないシリーズはとりあえずこのフレーズから始めておけば良いでしょ。感がありますが、「ELBってなに？」というお話を最初にしておきましょう。

ELBはElastic Load Balancingの略で、要するにロードバランサーです。

昔話になりますが、AWSが誕生したのは2006年。最初のサービスはS3でした。
その後、同年にEC2、2008年にEBSがリリースされています。
（2006年、2007年は永続的にデータを保持するという事は出来なかったです。）

で、2009年にVPC、RDS、SQS、ELBがリリースされました。
この年から所謂3層構成Webサーバ、APサーバ、DBサーバ（RDS）の構成が出来るようになり、一般的なWebシステムがクラウドで構築可能となりました。

何が言いたいかというとELBは最初期のサービスであり、クラウドが普通に使えるようになったと思われるコアなサービスなんです、という事です。

で、当時はELBの1種類でしたが、時代と共に拡張され、今では3種類のELBが存在します。

ELBがあると何が嬉しいの？

こんな感じの嬉しいことがあります。

1．耐障害性の向上

ロードバランサーは負荷分散を実施する装置です。（英語を日本語にしただけですけど）
負荷を分散するためにリクエストを複数のサーバに割り振ることが出来ます。

そのため、一般的にロードバランサーを利用すると2台以上のサーバにリクエストを割り振るので、1台のサーバがダウンしてしまっても処理を継続させることが可能です。

なお、ALBでは、割り振りを以下の2つから選択可能です。

ぶっちゃけ割り振りはラウンドロビンでよいと思います。最⼩未処理は一般的にはLeast Connection（リーストコネクション）と言われると思いますが、わざわざ「考慮しているぜ感」が個人的に好きではありません。

シンプルが一番だと思います。

なお、ALBの場合、スティッキーセッション（stickiness）の利用も可能です。
こちらもデフォルトは無効です。
Cookieベースで同セッション内は同じサーバに割り振ってくれます。

セッション維持をLBにさせるのはオンプレミス環境では一般的でしたが、クラウド環境であればElastiCacheとかDynamoDBにセッションを持たせてほしいところです。

詳しいことは分からないけど、とりあえず使えるようにしてくれ。という場合は、スティッキーセッションを有効化しておくのが良いと思います。これまでのオンプレミス環境と同じ形にできますので。
（最終的には色々勉強して、セッション維持機能は外だしして欲しいところです。一般的に疎結合のシステムの方が、耐障害性が強く、柔軟性があります）

2．セキュリティ強化

ELBを利用することで、直接サーバ（EC2とかECSとか）にアクセスさせなくて済みます。

通信経路はこんな感じですね。

ELBが無い場合、サーバ（EC2とかECSとか）にグローバルIP（一般的にはEIP）を割り当て直接接続させる形式になります。

この場合、EC2に脆弱性があった場合、攻撃を受ける可能性があります。
この攻撃については、セキュリティグループでHTTP、HTTPSのみ許可していれば問題はありません。

とはいえ、セキュリティグループの設定ミスなので攻撃される可能性は（ELB配下の構成と比較して）高くなります。
また、DDoSなどサービスを利用させない攻撃については対策が取られていません。

ELB配下の場合、AWS Shieldが標準で導入されているため、DDoS攻撃が実施された際に、自動的に攻撃トラフィックは配下のサーバに割り振りしない仕様となっています。

なので、とりあえずELBを置くだけでセキュリティが強化されます。

なお、これはELBに限った話ではありません。CloudFrontでも同様です。
AWSではAWSが用意しているエンドポイントを経由する場合、AWSが定義しているセキュリティ機能が有効化されます。

EC2をそのまま公開することは絶対にしないでおきましょう。
というか、個人的にはEC2にグローバルを振らないで欲しいです。ホントに。

3．いろんなサービスと組み合わせてパワーアップ

とりあえずELBを利用すれば色んなサービスとの組み合わせが出来ます。
セキュリティ強化でも記載したAWS Shieldが標準搭載されています。

それ以外にも証明書を発行、管理するACM（AWS Certificate Manager）はELBが無いと利用できません。
また、AWS WAFもELBに適用する形になります。

後、あまり使っている事例は聞きませんが、認証サービスのCognitoもELBに組み込む形となります。
Cognitoは便利だと思うんですけどねー。
なお、本サービスのCUVIC on AWSの内部管理ツールのWeb認証はCognito使っています。

実際の環境はアプリケーション側で認証を作りこむケースが多いですね。

ELBってただのロードバランサでしょ。と思っている方もいるかと思いますが、意外とメリットがあることが分かっていただけたかと思います。

なお、サードベンダーのロードバランサーを導入しても「いろんなサービスと組み合わせる」という事は出来ないので、AWSでロードバランサーを使いたい時はELB一択だと思っています。

ELB利用時の注意点①

オンプレミスでロードバランサーを利用する場合、大体こんな感じの構成にするかと思います。

構成図書いておいてアレですが、特にこの図に意味はありません。
ただ、この構成時、一般的にはサーバ側でログを取った時にサーバには「クライアントのIPアドレス」が記載されます。

AWSでELB（Classic、ALB）を利用した場合、サーバのログに記載されるのは、クライアントのIPアドレスではなく、ELB（Classic、ALB）のIPアドレスになります。（ALBがNATしているため）

そのため、デフォルトではクライアントのIPアドレスを知ることはできません。
クライアントのIPを知りたい場合は、X-Forwarded-Forヘッダを付加するようにしておきましょう。

こんな感じで設定

X-Forwarded-Forヘッダを付けるとログ上に以下のように記載されます。

これで利用者の分析ができますね。

ELBの拡張性

ELBは負荷（トラフィック量）に応じて⾃動でスケールする仕様となります。
そのため、利用者は基本、拡張性については認識する必要がありません。

ただし、ELBのスケールについては負荷分散サーバのスペックを上げる、負荷分散サーバを追加する形になるため、急激なトラフィック増加が発生時、トラフィックが捌けない状態となってしまう事があります。
（多分、ELBはコンテナで実行されていると思われます。トラフィックが増加するとコンテナがトラフィックを捌くために自動的にコンテナが追加されますが、きちんと立ち上がってトラフィックを捌けるようになるまでラグが発生します。）

そのため、事前に負荷が急激に上がることが分かっている場合、
例えば

みたいな感じですね。

その場合は、事前に暖機運転（Pre-Warming）申請を実施することで、トラフィックの断を防ぐことが可能です。

暖機運転（Pre-Warming）を依頼すると、時間前から事前にELBのサーバスペックを上げる、ELBを追加するなどの対応をAWSが実施してくれます。

なお、暖機運転（Pre-Warming）についてはあくまでAWSの善意に基づくものであるため、費用は発生しません。
申請時はきちんと想定されるアクセス数を申告しましょう。
※暖機運転（Pre-Warming）申請は、ALB、およびClassicのみ実施可能です。
※あくまで善意に基づく対応であるため、定期的に急激にトラフィックが増加することが想定される場合は、システム側で対策をしましょう。

NLBは瞬間的に増加するトラフィックも捌くことが可能であるため、暖機運転の申請は不要となります。

ELBの料金

ELBの料金は以下の通りです。

LBの種類で費用が変わってしまうので、今回はALBの費用を掲載します。（2025年）

①については基本費用です。
電気とか水道の基本料金と思ってください。

1つのAlBを作ると特に通信を流さない状態でも0.0243×24時間×30日分の費用が発生します。
大体18ドル弱（17.496ドル）です。なので、1つのALBを作るごとに、18ドルぐらいかかると思っておいてください。

これにプラスしてたくさんトラフィックを流すと②の料金がプラスされます。

②の詳細は以下を参照ください。
https://aws.amazon.com/jp/elasticloadbalancing/pricing/

だいぶややこしいのですが、

の時に「6.22ドル」となります。

細かいことは無視して、1分間に60回のアクセスがある程度のサイトだと、②の費用が5ドル強ぐらいと思っていただければと思います。

なので、1分間に60回のアクセスがある程度のサイトの場合のALBの料金は17.496ドル + 6.22ドル = 23.716ドルになります。（大体25ドル弱と思ってください。）

オンプレミスでロードバランサーのアプライアンスを購入して使う事を考えるだいぶリーズナブルですね。

こんな感じで使うといいよ

本サービスのCUVIC on AWSでも業務改善のため、色々コードを書いているわけですが、管理性をよくするために1つの機能（ツール）に対して、1つのコンテナを立ち上げています。

管理面ではこのやり方が良いのですが、そうすると10個ツールを作ると10個ELB（ALB）が必要となってしまいます。
そうするとELBの料金でも触れましたが、最低でも18ドル弱×10個 = 180ドルかかってしまいます。

このやり方だとお金が無駄にかかってしまうので（実際には開発、ステージング、本番の3環境あるので、費用は3倍です）、ALBに複数のターゲットグループをアタッチして管理することで、ALBの基本費用が1つで運用することが可能です。

以前はこのやり方をすると、どのALBにどのターゲットグループが紐ついているのか良く分からない。
という状況が発生し、管理が難しかったのですが、新規でALB、NLB内に「リソースマップ」という機能がリリースされました。
（Classicにはリソースマップ機能はありません。リソースマップはターゲットグループを管理するものなので、
1対1で紐付きが実施され、ターゲットグループを利用しないClassicではリソースマップは不要な為です。）

リソースマップを使う事で、ALBにどのターゲットグループが紐ついているのか、ルールが閲覧できるため1つのALB、NLBに複数のターゲットグループを紐付けることが現実的になりました。

リソースマップはこんな感じです。

「リスナー」→「ルール」の所で、線が交わっているように見えますが、GUI上リスナーをクリックすると色が付くようになりますので、どこに負荷分散しているのかはすぐ分かるようになっています。

ELBの管理

リソースマップで表示した画面では、1つのALBを利用して複数のサーバに負荷分散を実施する際にポート番号で振り先を変更しています。

このやり方はあまり良くないやり方になります。ダメな例と認識ください。

上記のやり方ではなく、基本はHTTPS（443）で受けるけど、利用者が指定したドメイン名にて割り振りを変更するようにしましょう。
この設定はリスナーの中のルールで対応が可能です。

以下の画像の通り、「ルールを追加する」をクリックすると振り分けルールの条件を追加することが可能です。
で、「ホストヘッダー」にドメイン名を設定することで、このURLで来たリクエストに対しては、サーバAに転送するという設定が可能になります。

この辺の作業については、ぶっちゃけ、手で作業をしていたら良く分からなくなってルール外の設定をしてしまうかもしれません。
そもそも1つのALBに複数のターゲットグループを紐付けるのは、結構管理が面倒な作業となります。
（リソースマップ機能があれば可能ですが、正直正しいルールを守らせるのは難しいです。）

そのため、こんな感じでELB（ALB）を利用するのであれば、CICDパイプラインの中に、IaCのコードも組み込み自動的にルール通りALBとターゲットグループの紐付けが実施できるようしておくのが良いですね。

IaCのコード書くのが面倒と思われる方もいるかと思いますが、確実にルールを順守できるのが最大のメリットだと思います。

CICDのパイプラインに組み込んで、開発担当はインフラの構成とかルールを意識することなくきちんと管理できている状態を確保しましょう。
それが出来ないのであれば、1つのALBには1つのターゲットグループとしておいた方が無難かもしれません。

終わりに

という訳で、「いまさら聞けないELBの話」でした。

ELBについてはもうちょっと細かい話も出来ますが、細かい話ばっかりされても困ると思うので概要レベルで納めてみました。

ELBについては費用も高くないですし、気軽に使える良いサービスだと思います。
システムを作る際にロードバランサーは必須ですからね。

当初は複雑なルールを定義することはできませんでしたが、現状ではPathがtest1だったらXXXX1に転送、Pathがtest2だったらXXXX2に転送みたいなことも定義可能です。
サードベンダーのアプライアンス製品ではもっと柔軟に設定が可能なものもありますが、現状のELB（ALB）でも必要な機能はそろっていると思います。

ELBはほぼすべてのシステムで利用する基本機能の1つなので是非抑えておきましょう。

ではまた、別の記事でお会いしましょう。