AWS ELB について
CMSサーバが AWS ELB サービスの ALB や CLB を使用している場合、espar による静的化とリバースプロキシの挙動で問題が発生する場合があります。本ページでは問題発生の原因にAWS ELBの仕様があることと、その対策について解説します。
espar 関連サーバからCMSへのアクセス
espar 関連サーバからのCMSサーバには3種類のアクセスがあります。
| No | アクセス元 | アクセス用途 |
|---|---|---|
| 1 | 静的化エンジン | サイトを静的化するため |
| 2 | 本番用公開サーバ | 動的要素を動作せるリバースプロキシのため |
| 3 | テスト用公開サーバ | 動的要素を動作せるリバースプロキシのため |
下図も併せてご覧下さい。
espar 関連サーバからは、CMSサーバにIP指定でアクセスします。例えば、www.example.com のCMSサーバにアクセスする場合、IPが仮に 1.2.3.4 なら、以下のような curl コマンドに相当するHTTPリクエストヘッダを送出します。
curl -H "Host: www.example.com" https://1.2.3.4/このように、esparインフラは原則 CMSサーバのIPに対して www.example.com のサイトとして表示を返すようにという要求を行います。CMSサーバのIPが変わることは想定しておらず、通常はCMSサーバには固定IPが割り振られているため一定です。
万が一IPが変化すると以下のような不具合が発生します
- CMSサーバにアクセスできずサイトを静的化できない
- リバースプロキシ適用パスへのアクセスが正しく処理されない
このような現象発生を避けるためにCMSサーバやそのIPが変わる場合は、事前に当社に連絡して頂く必要があります。
AWS ALB/CLB の仕様
AWSのロードバランサー AWS ELB には3種類のロードバランサーがあります。このうち ALB(Advanced Load Balancer) と CLB(Classic Load Balancer) を使用している場合、CMSを意味するドメインに割り当てられている IP がAWS側に変更されることがあります。
そのトリガは、
- AWSインフラ内でのELBリソースの切り替わり
- AWSインフラ内でのELBの Auto Scale
など、構築側の意図に関係なく突然変わることがあることが知られています。AWS側の変更計画等はなく、予測不能です。よって ALB や CLB のIPがAWSによって強制変更された場合に、静的化の失敗やリバースプロキシの処理不能などの問題が発生します。
espar 関連サーバ側ではCMS側のIP変更を検出できないため、IPが変わった場合には必ず当社にお知らせ下さい。静的化エンジンや公開サーバの設定変更となりますので有償となりますがご了承下さい。
対策
本現象の対策は幾つか考えられますが、CMS側のIPアドレスが固定となればどのような構成でも問題ありません。例えば以下のような方法が考えられます。
A. AWS NLBの使用
AWS ELB の3種類のロードバランサーのうち、NLB(Network Load Balancer)は、ALBやCLBのようにIPが変化することがありません。esparではNLBの使用を推奨しています。ALBやCLBの利用経験者であれば同様の理解で NLB を構成できます。
ただし、NLBはISO参照モデルのLayer4で動作するロードバランサーであるため、既存のALBでLayer7の機能を使っている場合はNLBで代用できないことに留意して下さい。詳しくはAWSのドキュメント Network Load Balancer とは? をご覧下さい。
B. AWS Global Accelerator を使用する
固定IPアドレスを持つグローバルなロードバランサーである AWS Global Accelerator を使用することで ALB 使用環境の IP を固定することができます。詳しくはAWSのドキュメント AWS Global Accelerator（アプリケーションの可用性とパフォーマンスを向上） をご覧下さい。
C. EC2単体で構成し直し EIP を割り当てる
esparでは冗長性と可用性を担保した別の公開サーバで全アクセスの一次受けを担うため、CMSサーバ側の冗長性が本当に必要かどうかを検討する価値はあります。なぜなら、esparの導入によりCMSサーバ側へのアクセスは以下に限定されるからです。
- 静的化エンジンによる静的化
- リバースプロキシによる一部パスのアクセス
CMSサーバに万が一障害が起こってもサイトの公開状態はespar公開サーバによって原則維持され、影響範囲は以下に限定されます。
- 静的化ができない
- リバースプロキシを必要とするページにアクセスできない
- 管理画面にアクセスができない
この影響範囲をどう捉えるかはサイトポリシーによりますが、クリティカルではないとしてALB/CLBを構成から廃しEC2単体構成とすることも可能です。それが可能な場合、CMS 側で AWS ELB の使用をやめて EC2 単体で構成することが考えられます。