最近の IT 系のノウハウ系ブログ(企業持ち)は、いちいち冒頭に筆者の名前を書いて
自己アピールしてるのがすごくウザいしイラッとくる。さらにつまらん個人的な話
しを数行最初に書いたりしててかなりいらつく。AWS 系に強い某社のやつとか。
# AWS じゃないけどうちの会社のブログもそうかも知れんが私は関与しない。
誰もあんたのことなんか知らんし知りたくもないて。
ちょっと外れるけどネットはいつまでも「嘘を嘘であると見抜ける人でないと使う
のは難しい。(ひろゆき)」な存在で無責任であって欲しいわ。
2016年12月15日木曜日
2016年12月9日金曜日
AWS Auto Scaling における AZ 異常時等の挙動
AWS の Auto Scaling Group で Multiple な AZ を指定すると、自動でインスタン
スを均等に分散してくれる。例えば、スケールアウトしたときなんかは少ない
AZ の方にインスタンスを作ってくれる。まぁ今更言うことでもないが。
スを均等に分散してくれる。例えば、スケールアウトしたときなんかは少ない
AZ の方にインスタンスを作ってくれる。まぁ今更言うことでもないが。
じゃぁ、とある一つの AZ が世の中的に大障害に見舞われた時はどんな動きにな
るのか気になった。ただ、こんな状況は検証しようがないし、ドキュメントに頼
るしかないと思い、いろいろ Web をあさったところ結局 Amazon の公式ドキュ
メントにその記述があった。忘れそうなのでメモ。
るのか気になった。ただ、こんな状況は検証しようがないし、ドキュメントに頼
るしかないと思い、いろいろ Web をあさったところ結局 Amazon の公式ドキュ
メントにその記述があった。忘れそうなのでメモ。
Auto Scaling プロセスの中断と再開 (日本語)
AZRebalance
リージョンのアベイラビリティーゾーンでグループの
EC2 インスタンスの数のバランスをとります。Auto Scaling
グループからアベイラビリティーゾーンを削除する場合や、その他の理由でアベイラビリティーゾーンが異常ありまたは使用不可になった場合、Auto
Scaling
は、異常ありまたは使用不可のインスタンスを終了する前に、影響を受けていないアベイラビリティーゾーンで新しいインスタンスを起動します。異常のあるアベイラビリティーゾーンが正常な状態に戻ると、Auto
Scaling はグループのアベイラビリティーゾーンにわたって均等にインスタンスを自動的に再分散します。
ということで、異常じゃない AZ で新しいインスタンスを起動してくれるというこ
と。これはまぁ想定どおりだったが、ちゃんと正常に戻った時に AZRebalance と
いうプロセスが元に戻してくれるんだって(この Auto Scaling におけるプロセスっ
て概念は「過程」ということじゃなくておそらく OS のプロセスと同義なんだろ
う。停止とか再開とか出来るらしいし)。
と。これはまぁ想定どおりだったが、ちゃんと正常に戻った時に AZRebalance と
いうプロセスが元に戻してくれるんだって(この Auto Scaling におけるプロセスっ
て概念は「過程」ということじゃなくておそらく OS のプロセスと同義なんだろ
う。停止とか再開とか出来るらしいし)。
こりゃすごいね。こんな親切なの AWS だけじゃないの? Azure とか GCP とかこ
んなことやってくれるんかね? 知らんけど。
んなことやってくれるんかね? 知らんけど。
で、なんでこんなこと調べてたかっていうと、私が担当している環境で Reserved
Instance (RI)を契約してるところがあるんだけど、RI って AZ に紐付いてるよね。
例えば、とある AZ に障害があって Auto Scaling Group のインスタンスが別の AZ
に偏ってしまった状況で、その偏った AZ における実際のインスタンス数が RI の
契約インスタンス数より多くなったら、そりゃ余計な課金の対象になるでしょう。
偏った状態に気づかず、何日も運用が続いたら予期せぬ課金が... という状況が恐ろ
しくて。でも自動で戻るということなので、まぁ予期せぬ課金はおそらくわずかな
もので済みそうで安心。
あともうひとつ、AZ の障害とはあまり関係ないけど心配なことがあった。
Auto Scaling Group (もしくは ELB)のヘルスチェックで異常と判断されたインスタ
ンスって、自動的に削除/作成をしてくれるよね。でも新しく作成されたインスタン
スでも異常な状態が続いちゃってると、おそらく削除/作成はループする。
これが土日とかみんな遊びに行ってるときに起こったら、すごい課金になるんじゃ
ないかと(つーかちゃんと運用体制組めよってのは置いておいて)。
ないかと(つーかちゃんと運用体制組めよってのは置いておいて)。
ヘルスチェック猶予期間をデフォルト(300秒)のままにしておいたとして、最短で
5 分に一回インスタンスの削除/作成が行われる。つまり 1 時間で最大
60分 / 5 分 = 12 回の削除/作成が繰り返されると。一回のインスタンスの作成で
は最低でも 1 時間の料金が取られるから、1 時間で 12 時間分の料金発生。
は最低でも 1 時間の料金が取られるから、1 時間で 12 時間分の料金発生。
これが延々続くとヤバイと思ったら、どうやら上記の URL にこれについても記述
があって、おそらく 24 時間以上のループがある場合はプロセスが停止するという
ことらしい。これを「administrative suspension (管理上の停止)」と言うらしい。
があって、おそらく 24 時間以上のループがある場合はプロセスが停止するという
ことらしい。これを「administrative suspension (管理上の停止)」と言うらしい。
24 時間ということは、最大で 24時間 x 12回 ということは 12 日分の料金が取ら
れるということになる。うーん微妙な感じ。まぁ制限があるだけマシか。
れるということになる。うーん微妙な感じ。まぁ制限があるだけマシか。
Reserved Instance 範囲内でこの現象が起こってれば特に気にすることも無いのか
もしれないけど、心配症なもんで...
もしれないけど、心配症なもんで...
ということで最近 AWS をいじりまくってるが、AWS は細かい気配りがすごいね。
この前なんて、Auto Scaling で必須だった EC2 の詳細モニタリング(有料)を、仕組
みを変えて無料にしてくれたもんね(Group Metrics Collection)。
みを変えて無料にしてくれたもんね(Group Metrics Collection)。
いや、AWS 好きになるつつあるかもw
2016年12月7日水曜日
NGINX とか Apache で ipv6 Link Local アドレスで Listen できないっす
Link Local アドレスはインタフェースが特定できないので、
<ipv6アドレス>%<インタフェース名> で指定すると固有になる
らしいが、この記法が Apache や NGINX で通用しない。
そもそも Link Local で Listen しちゃいかんのかな?
登録:
投稿 (Atom)