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

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

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

監視で重要なポイントは、次のアクションを明確にしておくこと

　続いては、こちらも日常的に継続しなければならない監視へと話題は移った。監視について植木さんはまず次のように述べた。

障害監視のポイント

　「何で監視するか、どうやって監視するか。エンジニアとしてはついそこに注目しがちだけど、それだけでは足りません。トラブルシューティングという観点から考えると、アラートが出たら誰が、どう対応するのかというところまで明確にしておかなければ意味がありません。ネットなどでも『どんなツールで監視するか』という話題を目にすることは多いのですが、その監視で障害を捉えてアラートが上がったときに何をすればいいか、というところまで議論されることはほとんどありません。実際にはその部分、『アラートが上がった次のアクションを明確にする』というのが一番重要です」（植木さん）。

　サービスを維持するためには、「障害があったことを知る」だけでは意味がない。発生した障害に対してどのように対応するか、つまりいかにしてサービスを復旧するかということの方が重要なのは、植木さんの言う通りだ。そのような訳で、監視について植木さんが指摘したポイントも自然と、次の話題である「障害対応」と密接な関係になっていた。

　「監視についてもうひとつ重要なことは、アラートを上げる際に重要な障害を見落とさないように工夫することです。オペレーションチームは色々なシステムから毎日数十通、数百通の障害通知を受け取っています。その中から、緊急に対応が必要な重要な障害のアラートを見つけられるようにしなければなりません」（植木さん）。

　重要なものについては通知メールの件名に「重要」と付加したり、重要度に応じて通知方法を変えるなどの工夫をしておけば、運用を担当するエンジニアはそれらを優先的に対応することができる。実際に植木さんが属するクラスメソッドのオペレーションチームがどのような体勢で監視を行なっているのか、その手法も紹介された。

　クラスメソッドで社用しているのはOTRSというOSSのチケットシステムで、アラートメールをすべて取り込んでチケット化している。先に紹介したような重要なアラートが届いた場合にはチケット化の際に【重要】と赤く表示され、さらに社内のチャットシステムに「未対応の重要なチケット化がある」と通知する。

クラスメソッドでは通知にも一工夫

　ちなみにクラスメソッド社内で使われているチャットシステムはチャットワーク、未対応チケットについて通知してくれるのは、クラスメソッドの非公式キャラクター「くらめそちゃん」だ。重要度の高いインシデントもカワイイくらめそちゃんからの通知なら「よし、がんばって対応しよう」という気になるに違いない。カワイイは正義だからだ。

クラスメソッドの非公式キャラクター「くらめそちゃん」が通知

　「この場合も通知するだけではなく、次のアクションを明示することが重要です。当社では重要なアラートを検知した場合には『緊急連絡事項あり、すぐに折り返し連絡をください。折り返しが難しい場合は人を呼び出してください』と、次のアクションまでチャットメッセージに含めています。その上でZabbixからTwilioを叩いて、くらめそちゃんから私の携帯電話に電話がかかってきます」（植木さん）。

開発段階から運用を意識したシステム作りをすることで保守の負担も軽減

　AWSに限らないが、クラウドインフラはプロ中のプロが常時目を光らせて運用しているIT基盤であり、社内のエンジニアだけで管理するオンプレミスのサーバに比べて信頼性は高いと言える。が、それが誤解を生んでいると植木さんは指摘する。

「お客様からはよく、『AWSで作ったシステムは信頼性が高いんでしょ』と言われますが、違います。『AWSなら信頼性が高いシステムを作りやすい』というのが正解です」

「AWSなら信頼性が高いシステムを作りやすい」というのが正解

　それを含めて、次の4つがよくあるAWSで多い障害だという。

1. EC2のリタイアメントとリブート
2. RDSのフェイルオーバー
3. Direct Connectの緊急メンテナンス
4. API呼び出しに失敗

　「Direct Connectの緊急メンテナンスは本当に緊急です。『10分後にDirect Connectのメンテナンスを実施します』なんて通知が急に来て、『どうすんのよこれ』ってなります（笑）。ですから、緊急なメンテナンスでも問題ないように、回線を冗長化しておきましょう」（植木さん）

　止まりはしないが処理速度が遅いという問い合わせも多く、中でもRDSがボトルネックになっていることが多い。ほとんどの場合開発時には問題なく動作していたものが、プロダクションとしてリリースされたとたんにアクセス数が増えてRDSの過負荷が健在するケースが多いそうだ。

「企業のサイトなどでは、TwitterやYahoo!で話題になりアクセスが集中して顕在化することもあります。なぜそれだけでRDSに負荷がかかるのかといえば、トップページを表示するたびにDBからデータを読み出す作りになっていたり、Webのセッション情報をDBに格納する作りになっているため。この問題を避けるために運用チームから開発チームには、負荷試験ではなく限界試験をしてもらうようお願いしています」（植木さん）

よくある障害原因

　限界試験を行なうことで、どこがボトルネックになるのかを確認することができる。ここで得られる情報開示は、運用に入ってから問題が発生した場合にも、チェックすべきポイントを絞り込むためにも役に立つ。

　「関東で開発に携わっている方でも、S3やCloud Front、Multi-AZ、Auto Scalingを使いこなせているエンジニアは少ないと感じています。このあたりの機能を使いこなせれば、AWSのパフォーマンスを最大限に引き出したり、どんな負荷にも耐えられるシステムづくりができるはずです」（植木さん）