b.l0g.jp     About     Archive     Feed

AWS, GCP, Azureの障害情報の提供方法とTwitterボット

Twitterボットを作るのが趣味という記事を以前書いたが、そのからみでAWS(Amazon Web Service)、GCP(Google Cloud Platform)、Microsoft Azureの主要3クラウドの障害情報Twitterボットを作った。面白いもので3サービスとも障害情報の提供方法やポリシーが違っていて、ボットのような障害情報を取ってきて通知する仕組みをつくるのはちょっと面倒。せっかくなのでボットの宣伝も兼ねて障害報告に関するサービス間の違いを挙げておく。自分で通知の仕組みを作ったり、サービスを選ぶときの参考に。

ちなみに、これらのサービスを既に使っている人は、単純にこれらのボットをフォローするか、Slack(英語の公式ドキュメント日本語記事)やHipchat(Zapierを使った方法の日本語記事)などにボットのツイートを通知するようにしておくと、障害検知の一環としても使えますのでぜひどうぞ。どのボットも障害発生時間などを日本時間に置き換えてツイートする仕組みです。

AWS

Twitterボット

  • 全リージョン対象 @awsstatusjp_all
    • 下のボットのツイートも包含されるので片方フォローすればOK
  • 東京リージョン関連のみ @awsstatusjp
    • 東京リージョンのサービスと、S3やManagement consoleなどリージョンなしのサービスの障害が対象

障害情報サイト

  • http://status.aws.amazon.com/
  • 大まかな地域ごとにタブが並んでおり、その中に地域内の全リージョン、全サービスが一列に並ぶ
  • 障害があると左端の緑の丸がオレンジになり、障害の詳細がDetails列に簡潔に書かれる
  • 他のサービスと比べると障害内容の記述はシンプルであまり詳細は書かれない
  • 過去の障害履歴は下半分に1週間分(それ以前にもさかのぼれる)表示されるが、サービス数が多すぎてやや見にくい
  • 比較的定型的な表現が多い
  • タイムゾーンはPST/PDT

機械的に障害情報を取る方法

  • 全リージョンの全サービスの情報がそれぞれ1つずつRSSフィードで提供される
  • その他に全障害情報が含まれるRSSフィードもある
  • 基本的には上記サイトに表示される内容がフィードにも書かれる

所感

  • いいところ
    • リージョン及びサービスごとにフィードがあるので特定サービスごとに監視したい時は楽
    • 定型的な表現が多いので訳したり表現を拾って処理を分岐したりしやすい
  • 悪いところ
    • 過去の障害情報が見にくいので他サービスのように時系列の一覧などが欲しい
    • フィードの数が多すぎる(all.rssをうまく使えばいいが)
    • 他サービスと比べて障害情報の詳細さが足りない

GCP

Twitterボット

  • 全リージョン対象 @gcpstatusjp
    • 日本リージョンはまだない(開設予定)
    • 現状、障害がリージョンごとにうまく分けて通知されないので日本リージョンができても別ボットにしづらそう

障害情報サイト

  • https://status.cloud.google.com/
  • 地域ごとやリージョンごとの区分けはなく、横軸が日時、縦軸がサービスのグリッドのみ
  • 障害があるとグリッド状に赤(致命的障害)やオレンジ(一部障害)の丸が表示され、障害の詳細へのリンクが貼られる
  • 障害内容の記述は詳細で、次の報告をいつまでにするかが必ず併記される
    • ただし次の報告時刻は守られない時もある様子
  • 過去の障害は時系列に並んで表示される
  • タイムゾーンはPST/PDT

機械的に障害情報を取る方法

  • サイトに掲載されている詳細情報や障害のレベル(Severity)、開始・収束時刻なども載ったJSONと、少し情報が少ないRSSの2つ

所感

  • いいところ
    • フィードの他に詳しい情報を含むJSONフィードが提供されている。しかもちゃんとスキーマ情報も別にある
    • Severityと障害の開始・収束時間があるのが非常にいい
  • 悪いところ
    • リージョンが障害情報の詳細にしか書かれないので、特定リージョンの障害のみを検出したりするのが困難

Azure

Twitterボット

  • 全リージョン対象 @azurestatusjp_a
    • アカウント名の文字数制限の影響で末尾がallじゃなくて悲しかった
    • 下のボットのツイートも包含されるので片方フォローすればOK
  • 日本リージョン関連のみ @azurestatusjp
    • 日本のリージョンとグローバルサービスのみ

障害情報サイト

  • https://azure.microsoft.com/ja-jp/status/ (https://status.azure.com/でもアクセス可)
  • 大まかな地域ごとにタブが並んでおり、その中に横軸リージョン、縦軸サービスのグリッドがある
  • 障害があるとグリッドに赤丸や黄色三角が表示され、障害の詳細がページ上部に書かれる
  • 障害内容の記述はGCPに近い詳細さで、今後の対応予定なども書かれる
  • 過去の障害は時系列に並んで表示される
  • URLからすると障害内容は日本語で表示されそうに見えるが、リージョン名などのみ日本語であとは英語のまま
  • タイムゾーンはUTC

機械的に障害情報を取る方法

  • 全リージョンの全サービスの情報が含まれるRSSフィードが1つのみ
  • 障害内容の記述はサイトに表示されるものと同じだが、Severityなどの情報は含まれない

所感

  • いいところ
    • かなり詳しい障害状況が報告される
  • 悪いところ
    • RSSフィードのスキーマが微妙(リージョンとサービスが同じCategoryに列挙されている)
    • 障害がない時はRSSフィードの内容が空になる
      • どんな情報がどのように配信されるか分からない
      • 障害が終わった時の情報がフィードから得られない
      • 他サービスだと、障害収束後に「こんなのありました」という報告パターンがあるがそういうのをどう出すのか謎
    • サイト上には表示されるがRSSフィードに載らない情報が多い

全体的に

  • 利用者から見てもっとも丁寧な感じなのはAzureだが、フィードがいけてないので情報の加工は一番やりにくい
  • AWSは情報の詳細さが他サービスと比べて全然足りない
  • 障害情報を加工して通知などに使いたい時には圧倒的にGCP。Severityや障害開始・収束時間など詳しい情報をパースしやすい形式で提供しているのはGCPのみ

英語をしゃべる機会を探して勉強会に行った話

いわゆる外資系企業に転職して半年、英語力の不足をひしひしと感じるのでさらにレベルアップすべく色々と試行錯誤中。お金をかけずに英会話の練習する機会は、探してみれば色々あるもの。最近行った英語に関する勉強会。

1000 speakers conference in English

金曜は1000 speakers conference in Englishという、参加者全員が英語で3分のLTをするというイベントに参加、マイペースで続けている個人的な翻訳プロジェクトYakstについて英語で話してきた。3分というのは非常に短いので、英語どころか日本語でもプレゼンしたことないという人でも、意外と話せてしまう時間。思ったよりゆるい雰囲気かつ参加者はエンジニアばかりではないというところが面白く、ネタがあるときには今後も積極的に参加してみたい。参加費無料。

Vital Japan / Vital English

土曜はVital Japanという老舗かつ大規模な英語勉強会のイベントで、シリコンバレー企業のワークスタイルについての英語セッションを聞いた。たった1000円で第一線で活躍するコンサルタントの英語のトークが聞け、さらに参加者同士で英語ディスカッションする機会もあるなんて、なんてお得な!

現職がシリコンバレー企業みたいなもの(本社はサンフランシスコ。SFもシリコンバレーに入る?)だし、How Google Worksとか読んだ身としては特に目新しいトピックはなかったけれど、逆にディスカッションの時に他の参加者の話から日本企業の闇みたいなのを感じられて、その意味では興味深かった。

最後の質問時間に参加者から出た「シリコンバレー企業のやり方が非常にいいのはわかるが、既にルールでがんじがらめの日本企業を一般社員の力で変えていくにはどうしたらいいか?」という鋭い質問に対して、「日本企業でも、経営者と現場の社員は何が問題か既に気づいていて、中間管理職の存在がシステムを変えにくい原因になっているケースが多いように感じる。経営者が言っていることをよく聞いて、彼らと協力する方法を探せば道は開けるんじゃないか」とスピーカーのロッシェルさんが回答していたのが印象的だった。

また、Netflixに勤めているという日本人が、発音は日本人的だけれど的確な言葉を選んで非常に流暢に発言していて、まさに自分が目指すのはああいうレベルだよなと再確認。勉強会みたいなイベントは、何かの知識を得るために行くのだけでなく、自分よりできる人を目の前にしてその人に感化されてもっと頑張るモチベーションをもらいに行くところでもあるなと改めて思った。

ちなみに、いきなり全部英語は無理という人は、Vital English 英語勉強会というのもあり、こちらは説明が英語に加えて日本語でもされて、資料に従って会話の練習をするというような流れになっている。こちらも参加費1000円とは思えない非常に濃い内容。

他にもオススメの英語勉強会あったら @dblmkt まで教えてください!

AWSのEBSボリュームのスナップショットを定期的に取る

小ネタだけど、久しぶりに技術的な内容の記事を書いてみる。最近はこういうのはQiitaに書くのが流行り?

EBSボリュームのスナップショット

インスタンスストレージ(インスタンスに無料で付いてくるローカルストレージ)と比べてEBSを使うことの利点の一つに、スナップショットを取れるというのがある。これはもちろんAWSのコンソールからの操作でも、awscliのようなツールを使ってもできるんだけど、いちいちこれらの操作をやるのは面倒になってくる。そうすると、

  • 自動で定期的にスナップショットを取りたい
  • 古いスナップショットは自動的に消したい
  • 複数のEBSボリュームのスナップショットをまとめて取りたい
  • 全ボリュームのスナップショットを取る必要はなく、一部だけ取っておきたい

みたいな話が出てくる。

そういう時にはもちろんawscliや各言語のSDKを使って自分でこれを実装してもいいのだが、AWS Missing Toolsと言う、AWSに関するちょっと痒いところに手が届くツール集があって、これに含まれるEBSスナップショット取得用のスクリプト ec2-automate-backup.sh を使うと便利。

ec2-automate-backup.shの使い方

拡張子でわかる通り単なるシェルスクリプトで、中ではawscliを駆使して処理を行っている。なので、前提としてawscliがインストールされていて、credentialの設定が終わっている必要がある。awscliのインストール方法については割愛。

awscliの用意が済んだら、リポジトリをクローンしてきてコマンドを叩けばよい。

  
git clone https://github.com/colinbjohnson/aws-missing-tools.git
  
cd aws-missing-tools/ec2-automate-backup
  

コマンドのオプションはREADMEに書いてあるが、イマイチわかりにくい。最低限以下がわかればとりあえずのバックアップは取れる。

  • -s [volumeid|tag] : バックアップ対象のボリュームをボリュームID指定するか、特定のタグが付いているもので指定するかを選択する。tagを選んでおくと、例えば「Backup=true」と付いているボリュームを一括でバックアップする、ということが可能。
  • -v ボリュームID : -s volumeidを指定した場合にボリュームIDを指定する。
  • -t 'タグ名,Values=値' : -s tagを指定した場合にタグ名を指定する。上の例のように「Backup=true」のタグが付いているボリュームをバックアップする場合、-t 'Backup,Values=true'と指定する。ここちょっとわかりにくい。なお、タグはEC2インスタンスではなくEBSボリュームに付ける
  • -r リージョン : リージョン指定。ap-northeast-1とか。
  • -n : タグ指定でスナップショットを取った時、スナップショットのNameタグに、元のボリュームIDを入れる
  • -k 日数 : 指定した日数以上経過したスナップショットは削除可能タグが付けられる
  • -p : -kで指定した日数以上経過したスナップショットを実際に削除する

具体的には、以下のようにコマンドを実行する。これは「Backup=trueタグが付いたボリュームのスナップショットを作成し、7日以上経過したスナップショットを削除する」例。

  
bash ec2-automate-backup.sh -s tag -t 'Backup,Values=true' -r ap-northeast-1 -n -k 7 -p
  

実際の挙動的には、-k 7オプションがあるので7日経つとスナップショットにPurgeAllow=trueタグが付けられ、次の実行で-pオプションが効いてPurgeAllow=trueがついているスナップショットが消される、という流れになる。

これをcrontabに書いておくなりJenkinsで定期実行するなりしておけば、うっかりファイルを消してしまったとか、データベースがぶっ壊れたみたいな時にもサクッと戻せて幸せになれる。