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

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

2016年06月13日 07時00分更新

文● 重森大

運用チームに引き渡す前の段階で障害対応を視野に入れた徹底試験を

　多くの場合、システム開発の現場では「まず動くものを作る」ことが優先されていると思う。もちろんその後に負荷試験などで動作速度や耐障害性もチェックされることと思うが、その手法に関して開発チームと運用チームが連携する必要があるようだ。植木さんが働くクラスメソッド社では、運用チームで蓄積した知見を開発チームにフィードバックし、引き渡し前の試験方法について見直しを行なったとのこと。

　まず負荷試験についてだが、仕様で見込まれている負荷だけではなく、その10倍程度の負荷をかけた試験を行なうよう開発チームに依頼。多くの場合、負荷を高めていく段階でRDSが着いてこなくなるので、チューニングを煮詰めてもらう。さらに、負荷試験だけではなく限界試験も実施する。システムがどの程度の負荷に耐えられるのか、ボトルネックとなるコンポーネントはどれなのかを事前に把握しておくことで、障害発生時に障害ポイントの目安をつけやすくなる。Webサービス系の負荷試験で注目すべきは、トップページとランディングページ。一番アクセスが多いので、アクセス集中で障害の引き金になることが多いためだ。

負荷試験（性能試験と限界試験）

「クラスメソッドではJMeterを使って負荷試験を行なうフルボッコ（fullbok）というCloudFormationテンプレートを公開しています。こういったものも活用して、どの程度の負荷に耐えられるか、ボトルネックはどこなのかをリリース前に確認してください」（植木さん）

　障害試験については、サーバーが止まってもサービスが止まらないことをまずは確認する。同様にDBのフェイルオーバー時の動作についても試験が必要だ。DBに障害が発生してフェイルオーバーする際、DBのIPアドレスが変わることがある。それでもアプリケーションがきちんとDBに再接続できるかどうか、これも実際にチェックしておくことが重要だ。

障害試験でのチェック項目

「あとは障害発生時の検知と、その通知が機能するかどうかの確認ですね。サーバ停止やDBフェイルオーバーの試験の際に、それらを障害としてきちんと検知できているか。適切な通知が行なわれるかどうか。通知については、通知内容の文面までチェックするのを忘れないようにしてください」（植木さん）

　実際に過去にあった例として、障害通知メール内にサーバの内部IPアドレスしか書かれておらず、どこのサーバで障害が発生しているのか特定できないものがあったという。ネームタグを使うなど、どこのサーバでどのような障害が起きているのかがわかる文面になっていることを確認しておこう。検知の項で述べたように、重要度がわかるかどうかもここでチェックしておくこと。

　引き渡し前にはオペレーショントレーニングを兼ねて、担当者が手順書通りに実際に障害を想定した対応を行なうことも勧められた。手順書を書いているのはシステムを熟知した開発者であり、彼らにとってわかりきった前提が書かれていなかったりすることも少なくない。こうした抜けや漏れをなくすために、実際に作業をして確かめるのだ。他にも、必要なログ機能がオンになっているかどうか、構成図が所定の場所に置かれているかどうかなど、受け入れチェックリストを作成しておくことを植木さんは勧めている。

　「それから、Trusted Advisorをリリース前に必ずチェックしてください。REDのない状態で引き継いで、運用開始後も定期的に見てREDをなくしてください」（植木さん）

　植木さんはTrusted Advisorを使っている人がいるかどうか会場に尋ねてみたが、ほとんど手が挙がらなかった。これに対して植木さんは「セキュリティ面から耐障害性までチェックしてくれるので、これでチェックしてREDがないことを、受け入れの最低条件にしてほしい」と語った。その上で最後に、次のように締めくくった。

まとめ

　「システムはリリースして利用が開始されてからが本当のスタートですが、そのためにはリリース前から入念な準備が必要です。リリース前のチェックをしっかりやっているサービスは、実際に運用に入ってからもほとんど障害なく安定して運用できています。備えあれば憂いなし、障害が起きて慌てる前に打てる手を打っておきましょう」（植木さん）

■関連サイト