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

sorta kinda...

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

Linux の history コマンド結果に日時を入れたい [cloudpack OSAKA blog]

Linux

ナスです。

タイトルの通りです。
これやっとけばよかった!って体験をこの3月に何回かしたので…

あのコマンド叩いたのいつだっけ?とか、なんかディレクトリが削除されてるんですけど知りませんか?って聞かれたりした時、とりあえず history コマンド叩きますよね?

で、出てくる結果がこんなんです。

70  df -h
71  sudo cat /etc/nagios/nrpe.cfg
72  cd /etc/

うん、確かにxxユーザでこのコマンド実行してるけど、いつ実行したのかわからん、ってなります。

そこで HISTTIMEFORMAT と言う環境変数を設定します。これでいつどのコマンドが実行されたかがわかります。
細かい設定の話はしたの Qiita とかが参考になります。これが一番参考になりました。

qiita.com

 

この環境変数を設定している時に実行したコマンドだけに、実際の実行日時が出ます。環境変数を設定した以前の日時に実行したコマンドの行には、環境変数を設定した日時で統一されるので、最初に設定しておくことが大切です。

この環境変数を初期構築時に Ansible とかで設定するように仕込んでおけばいいですね。

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

AWS S3 Cloud Think

ナスです。

米国時間 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]

AWS EC2 VPC

ナスです。

とある検証で、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 インスタンスを再作成してください。これ意外と忘れがちなので、思い出せるように書いておきます。