AWSのALBがリリースされたので触ってnginxの機能の代わりになるか試してみた

## 概要

AWSでALB（Application Load Balancer）が
2016/8/11にリリースされたので試してみた

[AWS Application Load Balancer](https://aws.amazon.com/jp/blogs/aws/new-aws-application-load-balancer/)

---

## 設定方法・ELBとの違い

設定方法・ELB（Elastic Load Balancer）との違いは以下のblogなどで紹介されているので割愛します

[【新機能】新しいロードバランサー Application Load Balancer（ALB）が発表されました](http://dev.classmethod.jp/cloud/aws/alb-application-load-balancer/)

[AWS Application Load Balancer がきたので試しに作ってみた](http://blog.serverworks.co.jp/tech/2016/08/12/alb-testmaking/)

---

## 概要

出来るようになったこと

- パスベースルーティング：URLのパスに基いてルーティングが可能です。
- 複数ポートの登録：1つのインスタンスに複数ポートを登録することが可能です。
- コンテナアプリケーションのサポート：ECSはタスクスケジュールので未使用のポートを使用してターゲットグループに登録する事ができます。
- ターゲットグループでのヘルスチェック：CloudWatchで多くのメトリクスをサポートしています。
- アクセスログの情報追加：アクセスログに情報が追加され、圧縮形式で保存されます。
- パフォーマンス改善：パフォーマンスが向上しています。
- HTTP/2サポート：HTTP/2のリクエストを受けられるようになりました。
- WebSocketサポート：WebSocketのリクエストを受けられるようになりました。
- 削除保護：EC2と同様に削除保護ができるようになりました。

今回は、上3つに関してみてます

---

## 設定の概念

一般のLoadBalancerの設定であるように

- サーバ（EC2）作って
- サーバのグループ作って
- バーチャルサービスでLBに紐つける

って設定です

設定上グループを「ターゲットグループ」っていいます

---

## 目的

現サービスで用いているnginxの以下の機能が
代替できるか試してみる

- サブドメイン分ける
- パラメータによる振り分け
- ステージング
- メンテナンス

また、うまいこと運用できないか考えてみた

---

### ざっくり設定図

![001.png](https://qiita-image-store.s3.amazonaws.com/0/66113/70769e7c-902c-2c2d-0da5-0e41ac7ee5eb.png)


---

## ALBのいいとこ

- パスパターンで、ターゲットグループを変えられる
- 優先順位を付けれる
- defaultの設定は削除出来ない
- セキュリティグループの設定は、ALBではなく、EC2に紐づく

---

（あんま使わないかな・・・）

- ターゲットグループごとにポートを変えられる
- ターゲットグループ内のインスタンス毎にポートを変えれる

---

### パスパターンで、ターゲットグループを変えられる

【使えるであろう想定場面】

- 時間別の高負荷等には、高スペックなインスタンスのターゲットグループを配置し、終わったら削除
- パスでバージョン管理している場合（/ver200/ or /ver210/ etc）、バージョン毎にターゲットグループ作ってユーザーをアクセスさせる

---

こんな感じ（/event/ の場合）

![002_1.png](https://qiita-image-store.s3.amazonaws.com/0/66113/9f284769-efe9-98fa-204e-00def6a4c62d.png)



---

あと、こんな感じ（version管理の場合）

![003.png](https://qiita-image-store.s3.amazonaws.com/0/66113/7b773e40-c2ea-9609-e9b5-5c49dd5ee33d.png)


---

### 優先順位を付けられる

【使えるであろう想定場面】

- deployした最新のアプリは、優先順位高くすれば反映・削除すればロールバックできる

---

こんな感じから切替えすると
![011.png](https://qiita-image-store.s3.amazonaws.com/0/66113/5a0516c2-28b6-02e0-2f16-7e01301b0461.png)


---

入れ替え後！！

![012.png](https://qiita-image-store.s3.amazonaws.com/0/66113/9a5a42b8-d1c2-0d8e-6de6-78bd2ecf8857.png)



エラーになったロールバックだ！！！

---

ロールバックしたら

![013.png](https://qiita-image-store.s3.amazonaws.com/0/66113/aa6e0299-841d-886f-2c64-effba11edd3c.png)

---

### defaultの設定は削除出来ない

【使えるであろう想定場面】

- defaultにメンテナンス設定しておけば、ターゲットグループ削除すればメンテにいれられる

---

メンテ入れる前

![014.png](https://qiita-image-store.s3.amazonaws.com/0/66113/686a8e43-f8bb-80e3-c6eb-975322188783.png)


メンテ入れまーす！

---

メンテ中

![015.png](https://qiita-image-store.s3.amazonaws.com/0/66113/51de10ab-5b0e-2ba4-ffe5-52c0b5eafdee.png)



---

### セキュリティグループの設定は、ALBではなく、EC2に紐づく

【使えるであろう想定場面】

- 1つのALBの設定配下に、アプリ（全ユーザーアクセスOK）・管理ツール（社内のみアクセスOK）をおいてもEC2のセキュリティグループに紐づくので管理が楽

---

## ALBが（現時点で）いけてないところ

- ホスト名でのルール分けには対応していない
- ルールにパラメータが設定出来ない
- 優先順位の入替え・変更が出来ない
- 優先順位が「1～999」の間しか設定できない

---

### ホスト名でのルール分けには対応していない

【これが使えない】

- サブドメイン毎に、ターゲットグループを分けれない
    - FP・SP（fp.\*\*\*.jpとsp.\*\*\*.jp）や、
iOS・Android（app-ios.\*\*\*.jpとapp-ard.\*\*\*.jp）など

---

### ルールにパラメータが設定出来ない

【これが使えない】
uid=\*\*\*
などで、ルールの振り分けが出来ない

---

エラー画面＞＜

![004.png](https://qiita-image-store.s3.amazonaws.com/0/66113/78ee439f-f9ee-0662-f598-10495904ea7d.png)




---

### 優先順位の入替え・変更が出来ない

【これが使えない】
ステージングからプロダクションに上げるぞって時に
優先順位の操作ができない
（新規で作成する必要および、現設定の削除が必要になる）

---

変えられない画面

![006.png](https://qiita-image-store.s3.amazonaws.com/0/66113/642d1506-0d03-ce64-fb01-47a3582f2dd8.png)



---

### 優先順位が「1～999」の間しか設定できない

【これが使えない】
YYYYMMDD+番号
などで、優先順位の管理・バージョン管理ができない

---

![005.png](https://qiita-image-store.s3.amazonaws.com/0/66113/6aba54e0-d2eb-dc3b-5556-8cb7b61de4a7.png)




---

## ALBが（現時点で）いけてないところ

に関しては、現時点でと、
GUIでしか試していないので
CLI(awscli)では操作出来るかもです

別途検証します

---

## 考察

・サブドメイン分ける
→できない
・パラメータによる振り分け
→パラメータ・アクセス元IPでは出来ない
・ステージング
→パス操作だったらできるが現実的ではない
・メンテナンス
→出来る

今のgloopsのシステムにあてはめると、まだ、nginxが必要にはなりますね