思い出の地 JAWS-UG金沢に参加してAWSの運用について話してきました

2016.05.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは植木和樹@上越妙高です。5月12日に石川県金沢市でJAWS-UG金沢が開催されたので参加してきました。

地方としては珍しい平日夜開催ですが、上越から金沢へは昨年春に開通した北陸新幹線のおかげで仕事を終えてからも楽々行けるようになりました。

JAWS-UG金沢について

元々JAWS-UG北陸として活動していましたが、参加者の地域が広くなってきたためいくつかの支部が新たに立ち上がりました。

  • JAWS-UG金沢
  • JAWS-UG白山
  • JAWS-UG富山
  • JAWS-UG上越妙高

3年前(2013年)2月に私が初めてAWSを触ったのも、JAWS-UG北陸での勉強会がきっかけでした。当時は前職を辞めることは決まっていたけど次の仕事は決まっておらず悩んでいた時期でした。勉強会後の懇親会でコアメンバーのみなさんや当時のエバンジェリスト堀内さんに色々と相談にのってもらい、結果クラスメソッドに転職したきっかけとなった大変恩ある支部でもあります。

ということで今回は感謝を込めて、3年間の成長をみてもらおうと「オレのAWS運用ネタが火を噴くぜ!」という意気込みで臨ませてもらいました。

発表内容

AWSトラブルシューティング!早期復旧のための心掛け(JAWS-UG上越妙高 植木)

今回は「運用」がテーマということで、私からはDevelopers.IO 2016で発表した内容をお話させてもらいました。

意気込みの割に資料使いまわしじゃん!というツッコミはご勘弁を。ちゃんと3ヶ月分のアップデートも含めてお話しましたよ!

「メモが追いつかないくらい参考になった」という声をいただけて、なんとか恩返しができたのかなとホッとしました。

俺と「AWS外部から観測」 (JAWS-UG金沢 ふぁらお加藤さん)

加藤さんからはAWS上のシステムを監視する上で、システム「内部」からの監視だけでなく、外部、つまり「利用者からみた視点」での監視の必要性についての話でした。

  • 観測
    • 早く通常に戻したいから
  • 通常とは?
  • 提供者からみた通常
    • 内容が正しく
    • 使える速度で
    • 構成要素が想定通りの動き
    • 望んでいないものは提供していない
  • お客さまからみた通常
    • 内容が正しく
    • 使える速度で
  • 通常に戻したい1
    • OpenSocial(Proxy)経由でアクセス
    • レスポンスが滞ると強制メンテに
    • 原因レポートを出さないとアプリを再開できない
    • 機会損失
  • 通常に戻したい2
    • お客さまがあらゆる手段で連絡してくる(対応に2〜3時間コース)
    • 信頼を取り戻すのが大変
  • 発生したら高コスト
  • 原因
    • 設定ミス
    • 高アクセス
    • セキュリティアタック
    • ハードウェア障害(オンプレ)
    • XaaS障害
  • 内部から観測
    • よくやる
    • 最終的に提供するものと違う
  • 外部から観測
    • お客さまみたサービス移譲
    • お客さまにできるだけ近いかたち
  • 外部・内部あるある
    • 内部DNSを使ってる → 社内から異常を目視できない
    • 外からなのに管理者ツールメニューがみえちゃう
    • 時限式イベントがでちゃってる
    • 隠しページが隠れてない
  • 手間がかかる
    • ツールを使う
  • さくらのシンプル監視
    • 月額21円!
    • nagios
    • シンプルにメール/Slackが届く
  • 外部CI
    • トップページダウンロード速度、ハッシュ、サイズ
    • リンク4xx
    • IMGタグがあってるか
    • sshやMySQLに接続して「失敗すること」を確認する
    • ツールを使うことでグラフも作ってくれる(開発コスト抑止)
  • 開発しながらする
    • 通常状態を策定しながら作る
    • スロークエリーはすぐ修正する

内と外で「あるべき姿」が違うというのは、当たり前のようでなるほどと思った内容でした。

センターSEがインスタンスので止め忘れを監視してみた(JAWS-UG富山 石崎さん)

石崎さんからはインスタンスの止め忘れに気付けるように工夫された際のお話でした。

  • センターSEとは
    • データセンターに所属
    • ルールに従い運用
    • 安定稼働がミッション
    • 新しいものに飢えている
  • AWSに感動
    • 化物みたいなインスタンス - c4.8xlarge(とても高い)
    • 使ったら止めればいいんでしょ → 忘れてました!!
  • 稼働しているインスタンスがあるかLambdaでチェック
    • SNS, IAM Role, Lambda, CloudWatch Events
  • 自動でチェックする
    • 気付けるようにしておく
    • Billing Alarm重要

ちなみにCloudWatch Logsもログをガンガン吐いていくと、予想外の請求されますので「次の期間経過後にイベントを失効」を適切に設定しておきましょう。

Zabbix 運用の実例 (JAWS-UG金沢/富山 松本さん)

松本さんからはZabbixを利用した各種機器やシステム監視のお話でした。

  • Zabbix活用のねらい
    • 障害対応が後手にまわらないように
      • お客さまが気付く前に気付く
      • でないと主導権を握られてしまう
    • 監視台数増に耐えられる
    • 統一的なインターフェース
  • 構成
    • オンプレに1台
    • ラックマウントはNICポートが少ないのが難
    • アイテム数 32,500、トリガー数 4,200
  • 対象
    • ネットワーク機器(ルーター、スイッチ)
    • SNMP対応機器
      • 無線LANアクセスポイント
      • プリンタ・スキャナー
    • サーバー
    • AWS
    • アプリケーション
      • ウイルスバスター
      • データベース
      • 独自スクリプトの実行結果
    • フォルダ監視
      • WordPressの脆弱性をつかれてファイルをアップロードされてしまった
      • 怪しいファイルを検知して通知
    • RSS(NTT西日本工事障害情報)
  • トリガーの通知方法
    • Googleハングアウト(後から全検索できる)
    • Slack(アーカイブを工夫)
  • 工夫
    • オンプレ Agent
    • AWS awscli
    • サーバーに自動登録
    • 通知内容を多く載せる
      • 障害通知連絡先情報
      • 関連情報チェックのURL(ドキュメント)
      • 次のアクション
    • トリガーの調整
    • 日本語による通知を心がける
  • 困ってること
    • ハングアウトの通知スクリプトが大変
    • 通知慣れ
    • 通知のプライオリティ付

SNMP対応機器は統一的な方法で監視ができていいですよね。そういう意味ではCloudWatchも各種メトリクスが統一的な方法でアクセスできるのが良い所だよなと思いながら聞いていました。

まとめ

運用にテーマを絞ったことで内容が掘り下げられていて、いろいろ気付きの多い勉強会でした。

勉強会後の懇親会では、AWSの話だけでなく地方エンジニアとしての働き方や、新幹線開通に伴う地域への経済効果みたいな話まで話を聞かせてもらい、大変有意義な時間を過ごさせてもらいました。

当日は金沢だけでなく富山からも参加者がいて、私(上越妙高)も含めると、さながらJAWS-UG北陸新幹線って感じでした。長野や大宮にもお世話になってるので、いつか新幹線駅の支部を繋げて勉強会をしてみたいですね。