技術者ブログ

クラウド型WAF「Scutum(スキュータム)」の開発者/エンジニアによるブログです。
金床“Kanatoko”をはじめとする株式会社ビットフォレストの技術チームが、“WAFを支える技術”をテーマに幅広く、不定期に更新中!

2017年10月

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
  • お問い合わせはこちら
Scutum開発者/エンジニアによる技術ブログ WAF Tech Blog

Amazon EC2のAvailability Zoneの名前はアカウント毎に違う

はじめに

先のエントリにて、EC2のデータ転送と課金の関係についてまとめました。EC2では、同一のAZ内に存在しているインスタンス間でのデータ転送は、プライベートIPを使ったものについては課金されません。

Scutum(スキュータム)はSaaS型のWAFなので、お客様のウェブサーバとScutumのWAFインスタンスの間にそれなりの量のトラフィックが発生します。そのため、この課金されないトラフィックをうまく使いたいと考えていますが、ここに落とし穴が潜んでいました。実は、EC2でのAZは、アカウント毎に指している実体が異なることがあるのです。


(クリックで拡大します)

発見に至ったきっかけ

先のエントリの内容を調査する段階で、私たちは2つの異なるAWSアカウントを用意しました。これは(ScutumがEC2でサービスを提供する場合には)、お客様のウェブサーバのインスタンスの管理アカウントと、ScutumのWAFインスタンスの管理アカウントが異なるためです。前者はもちろんお客様のAWSアカウント、後者は私たちScutum管理者が利用するAWSアカウントとなります。

異なるアカウントに所属するインスタンス間のデータ転送に対する課金を調べてみたところ、なぜかRegional Data Transferが課金されないという現象に遭遇しました。ap-northeast-1aのインスタンスとap-northeast-1bのインスタンスの間で5GBや10GBといった量のデータを転送したにもかかわらず、数日待っても課金が行われないのです。そこで、AWSのサポートフォーラムで質問してみました。該当のスレッドはこちらになります。

AZの名前は単なるマッピングである

AWS側からはすぐに返答を頂くことができました(それも日本語で。感謝)。それによると、AZの名前はアカウント毎に異なる場合があるとのこと。理由は書かれていませんが、おそらくユーザが無意識に最初のAZを選択してしまうことなどによって、AZ間のサーバの数が偏ってしまうのを避けるための仕組みではないかと思います。

私たちが立ち上げた2つのインスタンスは、それぞれ「ap-northeast-1a」と「ap-northeast-1b」で起動していたのですが、実際には同一のAZだったのです。そのため、データ転送はAvailability Zone Data Transferとして扱われ、課金が行われなかったのです。

このようなアカウント毎のマッピングの違いは東京リージョンに限らずEC2の仕様のようです(オフィシャルのドキュメントは見つけられていませんが、AWSのスタッフの回答にあるため、間違いないでしょう)。また、調べてみたところ、2つの関連エントリを見つけることができました(こちらこちら)。

障害が発生した際に「ap-northeast-1aで障害が発生しているようだ」などとtwitterでつぶやいても、実は混乱をまねいてしまう可能性があるようです。

2つのアカウント間でのズレを調べる方法(IPアドレスを使う)

このようにややこしい背景があるため、2つのアカウント間でAZの認識がずれているかどうか調べたいケースがあるかと思います。おそらく最も簡単なのは、2つのインスタンス間で、プライベートIPを使ったtracerouteをしてみることです。

[root@ec2-1 ~]# traceroute -n -T 10.150.105.214
traceroute to 10.150.105.214 (10.150.105.214), 30 hops max, 60 byte packets
 1  10.146.8.3  12.042 ms  12.022 ms  12.010 ms
 2  175.41.192.174  1.172 ms  1.176 ms  1.165 ms
 3  175.41.192.11  3.238 ms  3.408 ms  3.444 ms
 4  175.41.192.221  9.537 ms 175.41.192.225  3.325 ms 175.41.192.221  9.511 ms
 5  10.150.105.214  3.318 ms  3.307 ms  3.301 ms

このように5hopほどある場合には、異なるAZ間に所属している可能性が高いです。同一のAZにある場合には、2hopくらいになるようです(ただし、東京リージョンでしかテストしていません)。

また、実はIPアドレスの先頭の、10.146と10.150という部分だけに注目してしまってもよいのかもしれません。

これらは手軽ですが、100%確実な方法ではありません。

2つのアカウント間でのズレを調べる方法(Spot Instanceの相場を使う)

ブラウザでAWSのEC2コンソールにアクセスし、「Spot Requests」から「Pricing History」を表示します。すると過去のSpot Instances価格のグラフが表示されます。このグラフはAZ別に色分けされた線によって描かれるため、もし2つのアカウント間で色が逆転していれば、その2つのアカウントではAZの名前のマッピングが逆になっていることがすぐにわかります。私たちが利用した2つのアカウントでは以下のようになっていました。



グラフに目立ったピークがなくわかりにくい場合には、Date Rangeを長めにするのがよいのではと思います。この方法を使えば、確実にマッピングのズレを把握することができます。また、インスタンスを起動することなく実施することができる方法になります。

まとめ

今回はEC2のAZにおいて、アカウントによってマッピングが異なっている場合とその判別方法についてまとめました。文中からリンクしているエントリ内では、ec2コマンドを使って調べる方法も紹介されていますので、興味がある方は調べてみてください。

また、本エントリについてのフィードバックはお気軽に@kinyukaまでいただければ幸いです。