JAWS-UG中部・北陸勉強会レポート 第2回

第10回JAWS-UG金沢メインセッションレポート

JAWS-UG上越妙高の植木さん、実体験に基づくAWS運用を披露

事前の準備で障害対応を機械的な作業にすれば復旧もスムーズ

　開発段階でどれだけ運用を意識したシステム作りを心掛けても、人が作って人が運用をする限り障害がゼロになることはない。その前提で運用を考える際に注目すべきポイントとして植木さんは「検知」「復旧作業」「確認」「報告」の4つを挙げる。

　検知段階において次のアクションが明確にされていれば、その手順に従って機械的に作業をしていくだけで復旧作業は終わるはずだが、そのような体制を構築するのは簡単ではない。おそらくエンジニアは、「何かあれば自分が対応すればいい」と考えがちなのではないだろうか。しかし緊急時にそのシステムに詳しい担当者が作業できるとは限らないものだ。

「あなたが南の島でバカンス中でも、機械的に復旧できる、仕組みと体制になっているかどうか、考えてみてください。それができていれば、障害発生時に現場にいるエンジニアだけで障害復旧は可能です」（植木さん）

「機械的」な復旧作業

　ここでいう「機械的に」というのは、システムで自動的に処理するという意味ではなく、資料に従ってエンジニアが機械的に作業するだけで復旧できるようになっていることを言っている。開発したエンジニアや、そのシステムのクセを知っているエンジニアがいないと復旧できないような体制では困るということだ。

　作業が終わり、復旧したことを確認できたら、最後にそれらの内容を報告してチームで共有しよう。この辺りのポイントについては植木さんが「【社内資料公開】構築担当者向け 運用チームに引き継ぐ時に気にしてほしい3つのポイント」というブログにもまとめているので、気になる読者はそちらもチェックするといいだろう。

AWSのサポートに頼る際に効くひと工夫も公開

　復旧作業の際、社内のエンジニアだけではどうにもならなくなりAWSのサポートに頼ることもあるだろう。しかし向こうも人間、問い合わせ方が悪ければ、正しく状況が伝わらず、十分なサポートを受けられない。

「どのくらい重要なのか、どのような事象なのか、それらをはっきり明記して『これは本当に重要で早く対応しないとまずい』と思ってもらうことが重要です」（植木さん）

　いつ発生したのか、現在も障害は継続中なのか。どのリージョンのどのサービスのどのインスタンスIDで障害が起きているのか、実際に障害を確認しているのはどのIAMユーザなのか。ログにはどのような情報が書き出されているのか。問い合わせのメールには、入手できる限りの情報を添えて送るようにしよう。

AWSのサポートに頼る場合に必要なのは？

「一番重要なのは、やはりログです。aws-cliでのdebugログや、SSHで事象を確認したのなら、-vvvvオプションを付けて操作ログを取得します。ネットワーク系であればpingやtracerouteの結果を、Webサービスでのエラーなら画面キャプチャを。とにかくその時点で得られるありとあらゆる情報を具体的に伝えること。そうでなければ、『このログがなければわかりません』と返信が来るだけで、復旧までの時間が長引くことになります」（植木さん）

早期に復旧するための対策は障害が起きてからでは遅い

　障害が起きたら、まずは復旧。顧客の先にいるエンドユーザーに迷惑をかけないためにもこれは鉄則だ。復旧したら、再発防止のためにも必要な原因の調査が待っている。調査に必要なものはいくつかあるが、いずれも事前に準備しておくことが必要だ。障害が発生してからログ機能をオンにしても手遅れでしかない。植木さんの示すポイントを参考に、これを読んでいる読者の方も自分が運用しているインスタンスの設定を見直してもらいたい。

「まず必要なのは、システムの構成図。開発チームから運用チームに引き継ぐときに、必ずシステム構成図をつけてもらうようにしましょう。ログ関連ではELB、CloudFront、CloudTrailのログ機能を必ずオンにしておくこと。DBを使っている場合にはMySQL show full processlistも定期的に取得するようにしておくとよいでしょう」（植木さん）

調査に必要なモノは？

　ログ関連で特に注意すべきと植木さんが指摘したのは、CloudTrailについて。東京リージョンしか使っていなくても、必ず全リージョンでCloudTrailをオンにしておくようにと強調した。

「うっかりしたミスからログイン情報が漏れてしまう事故は起こりえます。実際に私たちのお客様でも、GitHubにアクセスキーを付けたままのスクリプトをアップロードしてしまい、慌てて消すまでのわずか10分間に他リージョンで8xlargeのサーバを立てられるだけ立てられていたという事件がありました。そのリージョンでCloudTrailをオンにしておかないと、被害の全容把握さえ困難です」（植木さん）

　MySQL show full processlistも、障害原因の調査には役立つ情報だ。膨大な量になる恐れがあるので、数分に1回 show full processlistを取得して保存し、1週間に1回古い順に削除していくシェルスクリプトを組んでおくのがお勧めだ。