読者です 読者をやめる 読者になる 読者になる

sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

S3 で発生した障害の影響はデカかった [cloudpack OSAKA blog]

ナスです。

米国時間 2/28 に発生した S3 の障害のニュースは、皆さん見られてるかと思います。日本時間で夜中だったので、実際に障害の影響に直面した方は偶然にも少なかったかもしれません。

jp.techcrunch.com

今回の件で初めて知りましたが、S3 っていろんな web サービスが使っているんですね。Business Insider や Slack も S3 を使っていたようで、サービス影響があったみたいです。私は寝てたので全く気がつきませんでした…

 

SLA とその考慮

S3 には SLA があって、月あたり 99.9% の使用可能時間が定義されています。
サービスレベルアグリーメント - Amazon S3 | AWS

SLA はあくまで SLA なので、当然障害などでこれを下回る可能性はあります。AWS の場合は、下回ったら返金かサービスクレジットがもらえるだけです。そんなバカな!って思った方は、もう一度 SLA と言う言葉の定義を再確認しましょう。

で、今回の障害では 4 時間くらい S3 が自由に使えなかったわけですが、これを AWS のせいにするのは簡単です。ですが、これを機に、本当に落ちたら困るサービスを設計する時は、何かのサービスやリソースに依存する設計はやめるように改めましょう。本当に数時間落ちたら困るシステムやサービスで実際に同時間落ちたら、それは設計が悪いってことです。

基本的には、使った分だけ支払うモデルなので、うまく使えば安く済みます。が、特定のものに依存して安く済ます=障害でサービスが多少落ちても許容する、ということを関係者全員で共有しておく必要があると思います。

 

オンプレミスでも同じです

今回の件で「やっぱりクラウドは〜〜」的な論調で話してたり SNS 等でコメントされている方もいらっしゃいますが、別にクラウドは関係なくて、オンプレミス環境でも起こりうることです。今回は 4 時間程度で済みましたが、これオンプレミスだと業者手配とかでもっとかかる可能性だってありますよね。

全てはシステムやサービスの設計、運用設計にかかっているわけです。

 

というわけで、全てを AWS のせいにせず、そのサービスの要件にあった設計を心がけましょう、というのを私も含め皆さんも再認識してもらえたらと思います。

 

って、うちの社内の人が言ってました。私は、へー、って思いながら話を聞いてました。

パブリック IP が外せない… [cloudpack OSAKA blog]

ナスです。

とある検証で、EC2 インスタンスにパブリック IP をつけたら外せなくなったお話です。知ってる人にしてみたら当たり前の話ですが、意外と知らなかったって人もいるんじゃないでしょうか。

 

流れ

EIP は諸事情で使えない状態で、EC2 インスタンスからインターネットに出る必要があったので、VPC のサブネットで自動割り当てパブリック IP を有効化しました。
f:id:nasrinjp1:20170221234024p:plain

この状態で EC2 インスタンスを起動しました。この時点では、パブリック IP が付いています。
f:id:nasrinjp1:20170221234116p:plain

で、VPC のサブネットで自動割り当てパブリック IP を無効化しました。
f:id:nasrinjp1:20170221234235p:plain

 

結果

EC2 インスタンスのパブリック IP はついたままでした… EC2 インスタンスを再起動しても停止/起動しても、どうやっても外れません。

 

プライベートサブネットだけど一時的にインターネットに出る必要があってこうした場合、一度ついたパブリック IP は外れませんので、AMI 作成して EC2 インスタンスを再作成してください。これ意外と忘れがちなので、思い出せるように書いておきます。

Windows Update を RDP せずに実行する [cloudpack OSAKA blog]

ナスです。

皆さんは Windows Server で何か作業される時、リモートデスクトップ(RDP)でログインして作業してますか? その時、オペミス等でヒヤリとしたことや、実際に何かやっちゃった!ってことないですか? 私は何回もあります…

オペミスでなくても、Windows なら作業中にサーバの負荷が高くて画面が遷移しない!とか、何か実行したけど画面に何も出なくてちゃんと操作できたかどうかわからない!なんて経験をされた方も多いと思います。

もし、RDP せずに Windows Server の操作ができたら楽だし、オペミスも少なくなるので安心だと思いませんか? 思いますよね??

そこで今回は、EC2 Systems Manager というサービスを使って、Windows Server に対して RDP で入らずに操作する方法をご紹介します。EC2 Systems Manager って何?って方は、↓をみてください。
aws.amazon.com

 

とりあえず KB 検索からやってみよう!

まずは AWS のコンソールにアクセスしましょう。EC2 の左のメニューに↓のようなのがあると思います。
f:id:nasrinjp1:20170217095646p:plain

コマンド履歴から、「コマンド実行」を押します。とりあえず、現時点で Windows Update で適用できるパッチ一覧を確認してみましょう。コマンドのドキュメントで、AWS-FindWindowsUpdates を選びます。 f:id:nasrinjp1:20170217100144p:plain

対象のインスタンス ID と、Update Level を選びます。 f:id:nasrinjp1:20170217100751p:plain

AWS のコンソールから確認できる結果は2500文字までなので、長くなることを想定して、S3 に結果を保存するためにバケット名を指定します。実行結果によってメール等で通知させたい場合は、SNS の ARN 等も指定します。 f:id:nasrinjp1:20170217100806p:plain

これで「実行」を押すと、数分後には実際にパッチ一覧を出してくれます。 f:id:nasrinjp1:20170218213501p:plain

「結果の表示」リンクをクリックすると、こんな感じでKBがリストアップされます。日本語は文字化けしましたが、S3 に保存されている結果テキストは日本語表示されていました。 f:id:nasrinjp1:20170218213641p:plain

 

実際に KB を適用してみよう!

今度はドキュメントで「AWS-InstallMissingWindowsUpdates」を選んで、先ほどと同じ感じで内容を入れて実行します。 f:id:nasrinjp1:20170218214254p:plain

実行した結果(S3 のもの)です。先ほど Find で出力された KB だけがインストールされました。 f:id:nasrinjp1:20170218214402p:plain

実際に RDP でログインして Windows Update の画面を見ると、同じ KB がインストールされていることがわかります。 f:id:nasrinjp1:20170218214943p:plain

 

ものすごい雑な感じで流れを見てきましたが、RDP でわざわざ Windows Server にログインしなくても作業ができることがお分かりいただけたと思います。定型作業や不定期実行だけど決まった動作の作業等は、この Systems Manager を使うことでオペミスすることなく、しかもログが保存されるので画面ショットを撮るといった煩わしい行為もする必要がなくなります。

ちなみに、Systems Manager は、オンプレミスのサーバにも使えますので、AWS 使ってないから関係ないや、ではなく、ぜひ一度使ってみてください。この便利さがお分かりいただけると思います。