cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平@inokara)です。

半蔵門の SAP ジャパンさんで開催された第 22 回 AWS User Group – Japan 東京勉強会に潜入して各種セッションは LT の内容をメモってきましたので、各種スライドのリンクと共に共有させて頂きます!

aws-jawsug-tokyo-22th-take-notes_01

内容等に誤り等ありましたらご指摘、または編リク(編集リクエスト)頂けると幸いです。


テーマ

  • 運用の自動化!


アジェンダ

19:00 〜 19:05 会場説明19:05 〜 19:10 開催の挨拶
19:10 〜 19:30 セッション1 「NulabとAWSと私(仮)」ヌーラボ 中村さん
19:30 〜 19:40 ショートセッション1「運用自動化時代のドキュメンテーション」運用設計ラボ 波田野さん
19:40 〜 20:00 セッション2 「タイトル未定」 KAIZEN platform 伊藤さん
20:00 〜 20:10 休憩
20:10 〜 20:20 ショートセッション2「AWSアカウント開設からインスタンスを立ち上げるまでの作業自動化について」gumi 本間さん
20:20 〜 20:40 セッション3「Sensu on AWS(仮)」 Amazon 吉羽さん
20:40 〜 20:45 LT1「Pandora FMSを使って監視もオートスケール対応」Rworks 北川さん、山田さん
20:45 〜 20:50 LT2「ちょっといいSensuの話(仮)」cloudpack 山口さん
20:50 〜 21:00 バッファ + 終了



NulabとAWSと私(仮)


資料


自己紹介

  • @ikikko
  • ヌーラボ
  • Backlog の開発者
  • 若干インフラも…
  • Jenkins とかも


ヌーラボの説明

  • Backlog
  • Cacoo
  • typetalk(チャットツール)


アジェンダ

  • 自動化はどこから始めるか?
  • 事例
  • デモ
  • 自動化の先にあるもの


自動化は一日してならず

  • PDCA や改善は必要
  • 回数を重ねることでプロセスが洗練される


運用環境

  • プロダクション(開発者オンリーベータ環境含)
  • ステージング
  • ベータ環境はリスク小
  • 自分たちがよく使う環境を自動化するのが良い
  • がっつり Jenkins をメインとした自動化をやっている(印象)


ワークフロー

  • サーバー構成リポジトリ、アプリリポジトリ
  • Packer + Ansible を利用している
  • Serverspec でテスト
  • Junit でテスト
  • 固めた war を S3 に(好き勝手(言語)にアップロードしている)
  • Static なファイルも別の S3 にアップロード
  • Packer ファイルがプッシュされると EC2 が起動してサーバーのプロビジョニングして AMI 化


最新の AMI(常に)

  • AMI の作成タイミング
    • 構成管理ファイル変更時
    • 定期実行(最新の実行環境とミドルウェアを最新版に追随)
    • OpenSSL 問題等に役立った
    • 定期実行は良いプラクティス


リポジトリとしての S3

  • S3上に成果物や認証情報を確認
  • IAM ロールで EC2 インスタンスから S3 へのアクセスが容易に


テスト用インスタンス

  • CI テスト時にリソースが足りない場合にはインスタンス起動
  • Jenkins プラグインをカスタマイズしてスポットインスタンスを起動出来るようにしている
    • Jenkins のプラグインで EC2 プラグインがあるけどスポットインスタンスが起動出来ないので改造している
    • EBS が SSD のインスタンスでやれるように修正中


いみゅーたぼー

  • 環境の入れ替えはミドルウェアのバージョンアップ時のみ
  • 普段は設定ファイルやアプリのみ入れ替え
    • Java アプリは環境依存が少ない
    • EC2 インスタンス起動が遅いので…
  • Docker も検証中


Demo

  • テスト用のインスタンスが立ち上がるところ(負荷が高い状態で….スポットインスタンスを…)
  • hubot をトリガーとして


実績

  • ベータ環境へのデプロイ 272 回


自動化先にあるもの

  • Backlog(通知を登録)
  • typetalk(通知を収集)


ショートセッション1「運用自動化時代のドキュメンテーション」


資料


自己紹介

  • 波田野裕一さん(@tcsh)
  • 運用でカバー(レガシー運用が得意)


運用はいつも忙しそうだが…

  • 忙しいんだけど
  • 説明が難しい
  • 業務の客観化(未来の自分も含む)


ドキュメントが実現するもの

  • 記録
  • 整理「書く」ことで整理
  • 客観化「有形の成果物」(手順書)
  • 脱属人化「自動化」


注意点

  • 目的ではない
  • 自動化が目的…弊害
  • 運用ドキュメントで解決


ドキュメントを作る時間が…(無い)

  • 安く、手間をかけず(インターネット運用)
  • 後から金型を作るようなもの…orz
  • 働き方の多様化により知識のロストが発生する可能性が…


クラウド時代の運用ドキュメンテーション

  • How
  • Why
  • know how


Sphinx

  • ドキュメントを作りなくなるツール
  • 続きは JAWS-UG 千葉と AWS Summit


セッション2 「KAIZEN platform Inc. における運用自動化」KAIZEN platform 伊藤さん


資料


planBCD と AWS

  • よくある構成


自動化への指針

  • 行動哲学:三度同じことを繰り返す時は自動化
  • 少ない人数で
  • Chef と Serverspec
  • インフラも GitHub
  • CircleCIでインフラも CI


インフラ CI の流れ

  • レシピを GitHub へ push
  • CircleCI が自動で検知


Chef の適用

  • Paraknife(knife solo を並列実行)
  • xargs だとログが混ざる


デプロイの自動化

  • CircleCI を使っている
  • プロダクションブランチの変更を検知
  • capistrano でデプロイ


ブランチ戦略

  • master ブランチ
  • pull リクエストベース
  • github 上でマージすると自動で edge 環境へ


Pull Request デプロイ

  • デプロイタスクを pull request で実行
  • デプロイの見える化…
  • チャットで(hubot)


リリース時のチェックリストを hubot が自動作成

  • QA 環境


デプロイ後の確認テスト

  • Circle CI で…
  • CasperJS(ブラウザの動きを…)
  • BrowserStack(ブラウザ毎のテスト)モバイル端末のテストも
  • テストの実行命令も bot


bot が bot を操作

  • QA
  • テスト実行
  • リリースデプロイフローを実行する
  • 人間いらない


監視とモニタリング

  • sensu
  • Mackerel
  • sensu プラグインで CloudWatch の値をとってきて Mackerel に登録
  • PagerDuty


コードレビュー

  • レビューワーの自動アサイン


クロスブラウザのスクリーンショット撮影

  • hubot で


リモート会議 URL を案内

  • hubot で


EC2 のリストを取得するのも自動化

  • percol
  • リストを取得してそのまま SSH でログイン


kaizenzo

  • スクリーンショット
  • 撮影して S3 に…


自動化ミッションチーム


まとめ

  • 三度繰り返したら自動化
  • 自動化は一日にしてならず
  • 誰でも実行できるようにする「自動化より形式知化が重要」


AWSアカウント開設からインスタンスを立ち上げるまでの作業自動化について


資料

  • 見つけたら…


自己紹介

  • gumi
  • ほんまさん


アカウント開設

  • 新しいアプリケーション毎に


Cosolidated Billing

  • 請求をまとめることが出来る


アカウント作成フロー

  • Consolidated Billing アカウントをひもづけるまで費用のかかることはしない
  • さすがに自動化出来ない


インスタンス立ち上げまでにしておくこと

  • aws-cli 設定ファイルの共有
  • git で管理
  • profile で管理


アカウントの初期設定

  • key-pair の設定
  • import-key-pair
  • Security Group 設定
  • VPC Peering を意識した設計が重要
  • RDS Paramater Group 設定
  • などなど…基本的には aws-cli


Chef の利用例

  • environment
  • role / recipe
  • definition
  • attributes
  • cookbook の構成
    • Game
    • app
    • common


まとめ

  • aws-cli で運用準備
  • Chef の Cookbook の設計は早めに見なおしたほうが良い


Sensu on AWS(仮)


資料


自己紹介


Chef 実践入門

  • 寿司


sensu

  • モニタリングフレームワーク
  • 枠組み、土台、自分で色々と実装していく
  • オールインワンではない


sensu のアーキテクチャ

  • simple
  • rabbitmq がキモ
  • API だいじ


sensu のコンポーネント

  • Server
  • Client
  • API
  • Dashboard


Client と Server

  • 疎結合
  • Client 起動時に Server に登録される
    • Auto Scaling で監視対象に!


Check スクリプト

  • クライアント側での実行
    • 単純なチェック(0 / 1 / 2 / 3)
    • メトリクスの送信
  • 開発言語は問わない
  • 便利な gem があるのでそれを利用
  • 多数のチェックスクリプトを github で公開
  • 色々とたくさんある!!(AWS 系もある!)


ポイント

  • オンプレとクラウドで監視項目が同じとは限らない
  • サービスが意図した状態かどうかが重要
  • 個々のコンポーネント全てを監視する必要がない


Subscription

  • どのチェックを Client で実行するかを定義


Subscriber

  • どんなチェックをどんな頻度で
  • 結果をどうするか?(handler)


Sensu Admin

  • Sensu Admin で…


Handler

  • Client から受け取ったデータをどう処理するかを定義する
  • HipChat / fluentd 等…
  • Graphite とか…
  • mutator で送信前にデータ整形
  • 単純にデータを送るだけ


CloudWatch と組み合わせて…

  • データ保存期間
  • まとめてみたい
  • カッコイイグラフ
  • SDK + Sensu + Graphite で。。。


SNS と組み合わせて…

  • メールあちこちから
  • smtp とかたてたくない
  • Handler + Amazon SNS で解決!


Auto Scaling

  • サーバーが起動したら自動で監視対象にしたい
  • サーバーが破棄されたら自動で監視対象から外したい
  • OS の停止スクリプト + API


自動離脱

  • Sensu API をコール
  • 自動離脱しないと本当の障害と区別がつかない


まとめ

  • sensu は自由度の高いモニタリングフレームワーク
  • 可変インフラに対応しやすい
  • AWS の機能と組み合わせ可能


Pandora FMSを使って監視もオートスケール対応


資料

  • 見つけたら…


自己紹介

  • 北川さん


スケールされたインスタンスの監視について

  • 死活監視
  • リソース監視
  • ミドルウェア監視
  • ログ監視
  • Job / Backup 監視
  • アプリケーション監視

統合したい。


PandraFMS

  • 監視エージェント
  • リモート設定
  • ポリシーテンプレート


ちょといい sensu の話


資料


自己紹介

  • cloudpack 山口さん


check-rds.rb

  • RDS インスタンスの状態をチェックする
  • AZ を監視
  • 値の取得方法を指定可能
  • 取得する値の期間を指定可能


check-elb-latency.rb

  • ELB のレイテンシーをチェックする


check-elb-sum-request.rb

  • ELB の総リクエスト数をチェックする


check-dynamodb-capacity.rb

  • スループットの使用状況をチェックする


雑感

  • CloudWatch の API が強い
  • メモリが Bytes 単位でしか取得出来ない


感想


初体験

  • 自分自身、実は今回が初めての JAWS-UG 東京ということでした


大盛況

  • ほぼ満席、立ち見も出てしまう程の大盛況で AWS を使っている方、興味がある方の多さを感じました


自動化は一日にして成らず、三度同じことをしたら自動化を検討する

自動化がテーマだった今回、頻繁に出てきた言葉やセンテンスは以下のようのものでした。

  • 自動化は一日にして成らずの言葉の通りすぐに自動化を導入してすぐに身を結ぶものではない
  • 出来る部分、よく使う部分、サービスに影響が無い部分から自動化を導入していく
  • 自動化は目的では無い
  • 三度同じことをしたら自動化を検討する
  • hubot
  • bot が bot をコントロールする時代
  • sensu はカ・ワ・イ・イ

個人的には KAIZEN platform Inc. さんの行動哲学とされている「三度同じことをしたら自動化を検討する」という言葉がかなり刺さりました…。

ということで、勉強会の議事録をさくっと自動でまとめてくれるツールは無いものか…と思ったかっぱでした!

元記事は、こちら