Skip to content
espar vault espar DOCS

AWS ELB について

名称変更について

2025年3月に espar から espar vault (エスパーボルト)へ名称が変更されました。サービスの機能・仕様・価格に変更はありません。詳しくはこちらをご覧下さい。

CMSサーバが AWS ELB サービスの ALB や CLB を使用している場合、espar vault による静的化とリバースプロキシの挙動で問題が発生する場合があります。本ページでは問題発生の原因にAWS ELBの仕様があることと、その対策について解説します。

espar vault 関連サーバからCMSへのアクセス

espar vault 関連サーバからのCMSサーバには3種類のアクセスがあります。

Noアクセス元アクセス用途
1静的化エンジンサイトを静的化するため
2本番用公開サーバ動的要素を動作せるリバースプロキシのため
3テスト用公開サーバ動的要素を動作せるリバースプロキシのため

下図も併せてご覧下さい。

architecture_summary

espar vault 関連サーバからは、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 vault インフラは原則 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 vault 関連サーバ側ではCMS側のIP変更を検出できないため、IPが変わった場合には必ず当社にお知らせ下さい。静的化エンジンや公開サーバの設定変更となりますので有償となりますがご了承下さい。

対策

本現象の対策は幾つか考えられますが、CMS側のIPアドレスが固定となればどのような構成でも問題ありません。例えば以下のような方法が考えられます。

A. AWS NLBの使用

AWS ELB の3種類のロードバランサーのうち、NLB(Network Load Balancer)は、ALBやCLBのようにIPが変化することがありません。espar vault では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 vault では冗長性と可用性を担保した別の公開サーバで全アクセスの一次受けを担うため、CMSサーバ側の冗長性が本当に必要かどうかを検討する価値はあります。なぜなら、espar vault の導入によりCMSサーバ側へのアクセスは以下に限定されるからです。

  • 静的化エンジンによる静的化
  • リバースプロキシによる一部パスのアクセス

CMSサーバに万が一障害が起こってもサイトの公開状態は公開サーバによって原則維持され、影響範囲は以下に限定されます。

  • 静的化ができない
  • リバースプロキシを必要とするページにアクセスできない
  • 管理画面にアクセスができない

この影響範囲をどう捉えるかはサイトポリシーによりますが、クリティカルではないとしてALB/CLBを構成から廃しEC2単体構成とすることも可能です。それが可能な場合、CMS 側で AWS ELB の使用をやめて EC2 単体で構成することが考えられます。