電子の密林を開拓する

2012年12月

AWS のセキュリティキーって、リージョン(region)ごとに異なるものなんだ……。

AWSで(CloudWatchを試すために)実験してて、たまたま Tokyo ではない使ったことのないリージョンに設定されたまま EC2インスタンスを作成しようとしたら、以前作成したセキュリティキーが選択できなくて焦った。

よく考えたら、データセンターが違うのだから、セキュリティキーが共通になっていなくても当然だよな…。

だがしかし、AvailabilityZone が異なる場合でも セキュリティキーは共有なんですが…。AZ が違うということは、(所在国は同じでも)データセンターが違うというコトだよね??? データセンター間でセキュリティキーをコピーしているのかなぁ。

まぁ、クラウドだから あんまり気にしても仕方ないけど…。

EC2でWEBサーバを複数台用意して、そのWEBサーバ群のログを syslog か何かを利用して1台のEC2へ集約したい。仮に集約する先を「ログサーバ」と呼ぶとする。

ログサーバがダウンした場合に、EC2インスタンスを再起動すると IPアドレスもホスト名も変化してしまい、WEBサーバが syslog 経由で接続する先を見失ってしまう。WEBサーバからはどのようにログサーバを見つけ出せばよいのか???

...

AWS EC2インスタンスを START⇔STOP していると、(EIPではない)プライベートIPアドレスがコロコロ変化するのが問題な訳ですが……。どこかでチラッと聞いた話によると VPC というのを使えば、プライベートIPアドレスを固定的に占用できるらしい。


で、Simple Monthly Caluculator という Amazon 提供の見積もりツールで VPC の料金を計算してみると、4台のVPCを追加するだけで $8000 を超えてしまうんですけど……(゚∇゚ ;)

AWSに詳しい人(?)に質問してみたところ、どうやら プライベートIPアドレスを使うだけであれば特別な料金はかからないという話でした。見積もり機能で記載されているVPCとは「専用EC2インスタンス(=特別に専用のハードウェアを用意するサービス)」であって、ふつーのEC2インスタンスをプライベートIP空間に配備するだけなら 料金不要みたい。
見積額を見たときに、ちょっと焦ってしまった...。




ちなみに、1台(=1つのある役割を持った)のEC2インスタンスを固定的に識別する方法としては、VPCによるプライベートIPアドレス固定確保の方法以外に、EIPを使った解決方法もあるらしいです。例のログサーバに例えると…
  1. EIPを ログサーバに付与する
  2. EIPを正引きしてIPアドレスを得る
  3. 入手したIPアドレスを逆引きする
  4. 結果として「AWS内でのみ通用するローカルホスト名」が手に入る
  5. ローカルホスト名のマシンに対して通信する
これで、ログサーバを(EC2インスタンスが変化してローカルIPアドレスが変化しても)常に固定的に指定できるらしいです。でも、こんなメンドクサイ方法を、ふつーのミドルウェア(syslogとか)に処理させるには、どうしたら良いのだ?
⇒ そもそも syslog も設定したことないけどw
⇒ コレがメンドクサイから VPC のプライベートIPアドレスを利用するのかなぁ~



以下、参考URL。

Simple Monthly Caluculator
  http://calculator.s3.amazonaws.com/calc5.html?lng=ja_JP

Amazon Virtual Private Cloud FAQ
  http://aws.amazon.com/jp/vpc/faqs/



とりあえず、VPCを使ってプライベトIPアドレスを確保しても特別お高い料金がかかるわけではない……という点が分かったのでヨシとしよう。


次回からは、CloudWatch と AutoScaling を実験してみる。

前回の続き。

作成したロードバランサーと、EC2インスタンス、EBS Snapshot、AMI を削除します。



・ロードバランサーの後始末
elb35
実験が終わったのでロードバランサーを消去します。
「Load Balancer → test-lbをチェック → Delete」で消去。


elb36
ダイアログ画面が出ますが、特に気になる警告も出ないので Yes, Delete をクリック。


elb37
ロードバランサー設定前の画面に戻りました。



・EC2インスタンスの後始末
WEBサーバとして利用した web01/web02 のEC2インスタンスも消去します。

elb38
「Instances → web01/web02を両方チェック → Actionsボタン → Stop」とクリックしていきます。両方同時にチェックできるので、STOPさせるだけなら、マトメて処理できます。


elb39
確認ダイアログが出ますが、そのまま Yes, Stop をクリックします。


elb40
しばらく待てば、web01/web02 の両方とも「stopped」の状態になります(その状態になるまで待ってください)。

次は、EC2インスタンスを TERMINATEしたいのですが……Termination Protection が設定されているので直接 TERMINATEできません。さらに、設定変更するのは1台ずつしか出来ないという……まぁ、 Protection の存在意義を考えると当然なのですが、メンドクサイです(x_x;

elb41
Instances 画面で web01 か web02 にチェックを付け、Actions ボタンから Change Terminate Protection を選択します。


elb42
「Terminate Protection を無効にするけど、ホントに良い?」と聞かれるので「Yes, Disable」をクリックします。

上記の Change Terminate Protection の手順を web02 にも同じように適用します。


両方とも Terminate Protection を解除したら、後は、前回の記事でやったように、web01/web02 の両方のインスタンスを Terminate します。
「Instances → web01/web02をチェック → Actionsボタン → Terminate」で操作できます。


elb43
結果としては、web01、web02 ともに「terminated」になって上記のような画面になるはずです。


・AMIの削除
elb44
AMI(Amazon Machine Image)は…今回の作成してあるものは たぶん実体のない名前だけだと思うのですが……残していても困るので消去しておきます。
AWS Management Console で「AMIs → 作成済みのAMIをチェック → De-register」と操作すれば消去できます。


elb45
確認画面。特に問題は無いので Yes, De-register をクリック。



elb46
消去完了画面。


elb47
消去が完了すると、上記のような画面になります。

De-register という名前の通り、AMI 単なるラベルであって、S3 とか EBS とかに保存されているものが実体なのでしょう。たぶん...。



・EBS Snapshot の削除
elb48
EBS Snapshot を削除するので、AWS Management Console で「Snapstops → 作成済みSnapshotをチェック → Delete」と操作します。



elb49
確認画面。Yes,Deleteをクリックします。



elb50
削除が完了すると、上記のような画面になります。



・削除完了の確認
elb51

ロードバランサー、EC2インスタンス、EBS snapshot、AMI とすべて削除したハズなので、EC2 Dashboard に戻って My Resources を確認します。念のため リロードボタンも押下しておいた方が良いでしょう。
「0 Running machines」「0 EBS Volumes」「0 EBS Snapshots」「0 Load Balancers」となっていれば正解。

お金がかかることなので、毎回確認しておきましょう。


これで、ELBを使ったロードバランサーの実験は終了。
次は何をしましょうか...。

前回の続き。

ロードバランサーの「ヘルスチェック」の仕組みについて調べます。

WEBサーバ(EC2インスタンス)が2台、ロードバランサーが1台…が設定済みであることが前提です。



・WEBサーバの1台を停止させてみる
elb20
ロードバランサーの動作確認の一環として、web01 を強制的に停止(STOP)させてみます。
AWS Management Console から「Instances→web01→Actions→Stop」とクリックして、web01 の EC2 インスタンスを停止状態(STOP)にします。



・ロードバランサーはweb01の停止を認識する?
elb21
「Load Balancers → test-lb → Instances」をクリックして、ロードバランサーが web01 をどのように認識しているかを確認します。
↑の画面では、Out of Service となっており、理由はともかく web01 が無応答であることを認識しています。
これは期待通りですね。



・web01がSTOPした状態でhttp疎通試験してみる

ローカルPCからコマンドラインでロードバランサーに対してhttpリクエストを発行してみます。

$ for R in $(seq 1 20) ; do curl 'http://dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/public-hostname'; echo -en "\n" ; done
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com

※ホスト名は、自分のロードバランサーのものと置き換えてください。

web01が停止しているので、web02 にだけリクエストが届いているのが分かります。



・全WEBサーバを停止(STOP)させる
elb22
「Instances→web02→Actions→Stop」とクリックして、web02 もSTOPさせてしまいます。



・ロードバランサーはweb02の停止を認識する?
elb23
「Load Balancers → test-lb → Instances」をクリックして、ロードバランサーが web02 の停止(STOP)を認識しているかどうか確認します。
↑の画面では、期待通り Out of Service になっていますね。

ちなみに、WEBサーバが2台しか存在しないのに、その2台両方ともが Out of Service になってしまったので、Availability Zones で ap-northeast-1a の Healty? 項目が No となっています。これは期待通りの反応です。




・WEBサーバが存在しない状態でhttpリクエストを投げてみる
ローカルPCからコマンドラインからロードバランサーに対して http リクエストを投げてみます。

$ curl -v 'http://dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/public-hostname'
* Connected to ec2-54-248-79-114.ap-northeast-1.compute.amazonaws.com (54.248.79.114) port 80
> GET /ec2meta.php/latest/meta-data/public-hostname HTTP/1.1
User-Agent: curl/7.9.5 (i386-redhat-linux-gnu) libcurl 7.9.5 (OpenSSL 0.9.6b) (ipv6 enabled)
Host: dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

* Connection #0 left intact
* Closing connection #0

※ホスト名は、自分のロードバランサーのものと置き換えてください。

ロードバランサーらしきものには接続しますが、そこから先は 応答がありませんね...。

こういう状態になったときのための定型文「ただいま込み合っております」とかの表示をさせたいけど、方法が分からないので今回は無視しておきます。




・WEBサーバを両方とも再起動する
elb24
STOP状態にしてあるWEBサーバを、両方とも START 状態に戻します。
「INstances→webb01/web02を両方チェック→Actionsボタン→Start」で、両方のEC2サーバを同時に START 状態にできます。



elb25
確認画面が出ますが、特に気になることもないので Yes, Start で。



・ロードバランサーは両WEB サーバを正常動作中として認識する?
elb26
「Load Balancers → test-lb → Instances」をクリックして、ロードバランサーが 両方webサーバ再起動を認識しているか確認しますが……認識してませんね。なぜ???



・ロードバランサーのヘルスチェック設定確認
elb27
「Load Balancers → test-lb → Health Check」とクリックして、ヘルスチェックの設定を確認します。
Healthy Threshold の値が 10 になってますね。Interval が 30sec になっているので、30sec × 10 = 300sec、つまりサーバーが再起動してから5分間はロードバランサーの割当配下に戻らないということですね。
これでは(動作確認が)ツライので設定を見直します。Health Check ページの下部にある「Edit Health Check」をクリックします。



・ヘルスチェックの設定変更
elb28
ダイアログが開くので、Healthy Threshold をデフォルトの10から4に変更しておきます。
これで、復活したサーバーが再度ロードバランサー割当配下に戻るまでの時間が  4 × 30sec = 2分 に短縮されます。これぐらいなら待てるかなーという数値になりました(気に入らなければ interval も含めてもっと小さい数字にしてください)。


elb29
確認のダイアログが出ますが、特に気になることもないので Close (OK)で。


・ヘルスチェック設定値の再確認
elb30
Healthy Threshold が 4 になっています。それだけ…。



・ロードバランサーは両WEB サーバを正常動作中として認識する?(再)
elb31
二分と設定したので、二分ほど待ちます(実際には 忘れて30分ほど放置しましたが…)。

「Load Balancers → test-lb → Instances」をクリックして、ロードバランサーが 両方webサーバ再起動を認識しているか確認しますが……今回は正常に認識していますね。
どちらも「In Service」となっています。



・両WEBサーバが再認識された状態でロードハランサーにhttpリクエストを投げてみる
まずは小手調べに一回だけローカルPCからリクエストを投げてみます。

$ curl -v 'http://dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/public-hostname'
* Connected to ec2-54-248-79-114.ap-northeast-1.compute.amazonaws.com (54.248.79.114) port 80
> GET /ec2meta.php/latest/meta-data/public-hostname HTTP/1.1
User-Agent: curl/7.9.5 (i386-redhat-linux-gnu) libcurl 7.9.5 (OpenSSL 0.9.6b) (ipv6 enabled)
Host: dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

* Connection #0 left intact
* Closing connection #0
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com

ちゃんと応答がありますね。
次は、連続でリクエストしてみます。

$ for R in $(seq 1 20) ; do curl 'http://dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/public-hostname'; echo -en "\n" ; done
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com

連続でリクエストすると、交互にサーバが負荷分散されています。
どちらも期待通りです。

※ホスト名は、自分のロードバランサーのものと置き換えてください。




・ヘルスチェック用のindex.htmlを消してみる
ヘルスチェック用として設定されている /ndex.html のファイルを消去(リネーム)して、ヘルスチェックを失敗させてみましょう。
ここでは web02 側の Ubuntu を操作します。

  cd /var/www
  sudo mv  index.html  index.html_

ロードバランサーの状態を確認してみます。
elb32
index.html を消去してから数分待てば、Out of Service として認識されています。期待通りの挙動です。



・ヘルスチェック用のindex.htmlを復活させる
先ほど消去(リネーム)した /index.html を復元します。web02側の Ubuntu を操作します。

  cd /var/www
  sudo mv  index.html_  index.html

その後、ロードバランサーの画面を見ると、以下のようになっているはずです。
elb33
web02 が In Service 状態に戻っていますね。

EC2インスタンス自体を停止(STOP)させたときは、Out of Service から In Service に復帰するまで 相当待たされましたが、Apache のファイルを消去→復元 しただけだと、2分かからずに In Serviceに復元しているように見えます。気のせいですかね...[謎]



・Apache を停止させてみる
次は、web02 の Apache サービス自体を停止させてみます。

ubuntu@ip-10-150-191-57:/var/www$ sudo service apache2 stop
 * Stopping web server apache2
 ... waiting    ...done.
ubuntu@ip-10-150-191-57:/var/www$

この状態でロードバランサーの Instances 画面を見ると…
elb34
…期待通り(しばらくすれば) Out of Service に変化しています。

次は、web02 の apache を再開させます。

ubuntu@ip-10-150-191-57:/var/www$ sudo service apache2 start
 * Starting web server apache2
   ...done.
ubuntu@ip-10-150-191-57:/var/www$

で、もう一度 AWS Management Console で LoadBalancer を確認してみると…。
Apache を再開させるて(2分経過することなく) すぐに In Service に復帰します。
どういう理由で2分待たずに復帰するのか分からないので、ヘルスチェックのログが見たいなぁ...(どこにあるのか知らないので見られないけど ^^;)



ロードバランサー用ヘルスチェックの動作確認もできたので、今回はここまで。



次回は後始末です。

前回の続き。今回は、ロードバランサーを設定します。
以前設定した WEBサーバ(EC2インスタンス)は動作状態である…という前提です。


・ロードバランサーの設定
elb11
WEBサーバが2台用意できたので、次はロードバランサーを設定します。
AWS Management Console の EC2 Dashboard から「LoadBalancer→Create Load Balancer」で作成を開始できます。




elb12
ロードバランサーの設定画面ですが……ここでは名前(Load Balancer Name)ぐらいしか設定するものはありません。ここでは test-lb という名前にしておきます。
ポート設定は……port:80 以外使わないので、追加は不要です。



elb13
ヘルスチェック(EC2の死活確認)の設定画面。
↑はデフォルトのままですが、これでOKということにしておきましょう。



elb14
ロードバランサーの配下に従える EC2 (WEBサーバ)の割り当て画面。
ここでは web01 と web02 の両方をチェックし、割り当てておきます。




elb15
確認画面。特に気になることもないので次へ。




elb16
完了画面。特に言うことは無いです。



・ロードバランサーの状態確認
elb17
出来上がったロードバランサーの動作を確認してみます。
まず、先ほど割り当てた二台の web01 と web02 が、正しく割り当てに入っているかどうかの確認をします。

「Load Balancers → test-lb(今回作成したロードバランサー) → Instances」をクリックすると、ロードバランサー配下のEC2インスタンスの状態を確認できます。精確には、ロードバランサーから見えている EC2 インスタンスの状態……ということになりますが。

ここでは、web01、web02 ともに In Service となっているので 正常 ということですね。


・ロードバランサーのURL(FQDN)確認
elb18
ロードバランサーのURL (FQDN) は、Description のタブで確認できます。
「Load Balancers → test-lb(今回作成したロードバランサー) → Description」にあります。

URL(FQDN)は、3種類提供されていますが……。Aレコード(IPv4用…一番最初のFQDN)を使えばOKなような気もするのですが、InternetExplorer で試したところアクセスできませんでした。
仕方がないので、dualstack. ~ で始まる「A or AAAA record」というのをコピーして使用します。curl で確認するのであれば、こんな感じ。

$ for R in $(seq 1 20) ; do curl 'http://dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/public-hostname'; echo -en "\n" ; done
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com

※ホスト名は、自分のロードバランサーのものと置き換えてください。

2つのEC2インスタンスに対して、交互にアクセスが振り分けられているのが分かります。

ここまでで、基本的なロードバランサーの設定は完了しました。



記事が長いと livedoor blog に怒られるので、今回はここまで。

このページのトップヘ