今週はJAWS-UG 千葉支部 Vol.4 -AWS運用縛り-へ参加してきた
http://jaws-ug.jp/es/%E3%80%90%E5%8D%83%E8%91%89%E3%80%91jaws-ug-%E5%8D%83%E8%91%89%E6%94%AF%E9%83%A8-vol-4-%E9%81%8B%E7%94%A8%E7%B8%9B%E3%82%8A/
今回は-AWS運用縛り-というタイトルということもあり、
運用とは？という部分から、経験談と今後目指していく形というところまでお話を聞くことができ、
運用担当者として明日から活かせる内容が多かった。
またしてもmemoを晒してみる。
こんなこと言ってなかったぞ！ってとこがありましたらご指摘いただけると幸いですm(__)m
※ memo部分はあくまで話聞きながら個人でとったメモなのでワードだけな部分も多いです。
あくまで個人の感想です。
セッションメモ
『クラメソ保守運用担当からみたAWS使っててよかったこと』
登壇者
クラスメソッド株式会社：植木さん
スライド
memo
保守→システムが本来あるべき姿になる メンテナンス
運用→正常に稼働しているシステムを用いて実施する業務
→手順やルールに従って
→オペレーション障害復旧
EC2 stop → start
突発障害は仮想ホスト障害が原因
→仕組み上不可避なので受け入れる
→なので極力複数台構成
→再起動すればサービス再開する仕組みにしておく
→AutoScalingにしておけばなおよしAWSサポート素晴らしい
客観的に調査してくれる←別の視点素晴らしいバックアップ
簡単→スナップショット クラメソブログ：ソンナコトモアロウカト おすすめ
タグつけとくと自動で世代管理までするよCloudWatch
インスタンス作成後「すぐに」情報収集
結構足りない監視項目多い（ディスク使用率、メモリ使用率など）
→カスタムメトリクス
監視項目数多いのでZabbixとか使いなさいリソース収集
CloudWatch = 2週間 = 足りない
足りない項目多いのでZabbix等と併用コマンドラインによる定型業務 aws-cli
ドキュメント駆動運用
マウスオペレーション難易度高し→手順書造り辛い→作らない
コマンドラインならコピペできログも残り複数処理も可能
Zabbixから自動実行も予防保守
障害が起きてからではなく→起きる前にやろう→AWSサポート
Pre-warmingビジネス以上じゃないといけない？
Trusted Advisorいいよ
Operational Checklists for AWS
http://dev.classmethod.jp/cloud/aws/aws-operational-checklist/
『エンジニア3人で支える月間10億PV』
登壇者
株式会社DoBoken：磯部 有司さん
スライド
memo
LT：人間関係自動化
ZenClark
2年で月間10億PVを支えるまでに成長
一行コード入れるだけなので一気にトラフィック増える
リアルタイム分析
大量なデータ
月間10億PV 秒間平均400PV 平均同時接続5万 月間10TB
約70台(インスタンスタイプは用途ごとに)→AutoScalingしてる
サービス豊富
API豊富
スポットインスタンス安い
→一気に増やしたら相場上がって全死亡事件
運用
開発も運用
アーキテクチャ
MongoDB
キューがSPOFになってスケールしない可能性→使わなかった
git-flowモデルで開発
Pull Request駆動
Curcle CI
Slack（チャット）、Squigle（ビデオチャット）、trello（タスク管理）
errbit（）モニタリング
大切な情報を見極める
人に気づいてもらう
監視レベル
サーバーダウン：電話
高負荷、JSエラーとか：Slack（チャット）
怪しい：赤字で表示
Zapier → twillio
ELB UnhealtyHostCount(監視用ELB)で生存確認
オオカミ少年にならない
メールの飛びすぎは誰も見なくなる
『ドキュメントを書こう! 運用自動化時代のドキュメンテーション』
登壇者
運用設計ラボ合同会社：波田野 裕一さん @tcsh
スライド
memo
- 「運用でカバー」で検索
「運用」は人によって概念が異なる（重要）
ドキュメント駆動運用
運用って何やってるかよくわからない
→やっているほうもわからん…
→ドキュメント無いと客観的にもわからない、何やってたかは基本忘れるDevとOps目的と手段が違う
Dev：手段 > 目的
Ops：手段 < 目的
ドキュメントがないと
→属人化してしまうので、その人がいなくなると致命的
データに語らせるのが「エンジニアリング」
構造化メモ→AMI,Cloudformation,Chef(Opsworks)→ドキュメンテーション
詳細は「運用ドキュメント」で検索日本は場の空気を前提とした「聞き手の責任」になっている
→「一回話したら説明完了」みたいな感じ見返されないドキュメントになってない？
→作業内容だけ書いたようなドキュメント。誰も見なくなる。ドキュメントツール：Sphinx デモ
pipでOK
『AWSを含めたハイブリッド環境の監視の実現 ～Zabbixのクラウド対応モジュールHyClops～』
登壇者
TIS株式会社：池田 大輔さん @ike_dai
スライド
memo
CDP：Monitoring Integration Pattern
http://aws.clouddesignpattern.org/index.php/CDP:Monitoring_Integration%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3なぜZabbix?
・監視の基礎となる作りがよく出来ておる
・監視設定の手間をかけないような自働化の枠組みが充実
・監視機能は非常に充実
監視→視覚化→通知・アクション実行
※見た目は古いwHyClops for Zabbix
『LEGOマインドストームでシステム監視』
登壇者
株式会社Syun：高松さん @TadaKazegaFuite
memo
昔はサーバーを起動させたらサービスが終了するまでは絶対に落とさない、という気持ち
ホスト名つけて管理したり、丹精込めて設定していたそんなサーバーには魂があるんじゃないか・・・
ということでサーバーが削除されたら供養をするシステム←文字だとなんのことかわからないw
素敵なお土産ありがとうございました
『NO MONITORING NO LIFE – さぁ、監視を始めよう on AWS』
登壇者
クリエーションライン株式会社 前佛さん @zembutsu
memo
- AWS×Munin
- シェル芸炸裂させられる
- kubernetes
『リアルタイムログ解析システムの裏側』
登壇者
株式会社ナレッジコミュニケーション 奥沢さん
memo
fluentd → kinesiss
抜け漏れのチェックどうする？
監視サーバーへ件数送る→S3へチェック
一件も抜け漏れがない→きつい→ほぼほぼないぐらいで
ログ加工が容易
『AWSサミット東京1日目のパネル<<クラウド時代の運用>>振り返り』
登壇者
アマゾン データ サービス ジャパン株式会社 荒木さん @ar1
スライド
memo
45%が運用コスト
保守含めると70%以上運用の悩みは大きくても小さくても同じ
高負荷
属人化
見えない費用対効果API+インフラ=強力！
自動化と運用
自動化は「手段」
運用は「設計＋構成管理」
開発者とツール・スキルの共有化クラウド時代の運用
「こだわり」を"エンドユーザー視点”でアップデート
→新しいサービスが出たら見なおしてみれば？
ベストプラクティスから学ぶ、真似る
→ベストプラクティスをコードで書く→管理→運用ドキュメント
なぜ自分がそれをやったか？を書くVagrat
これを使ってから個人のEC2使用料が減ったRuby
構成管理ツールはRubyに通じる→いつの間にかコード書いてる
セッションまとめ
キーワードで
運用
今回の本題なのでたくさんのワードが出ていた。
個人的に
- 「運用」は人によって概念が異なる
- 開発も運用
- 運用でカバー = ただのマンパワー
- 暗黙のSLA100%
ここらへんのフレーズが刺さった。
ドキュメント駆動運用
そして一番刺さったのはこのフレーズ。
可読性の低い「自動化」だけが目的となってしまったスクリプトを置いてきてしまった。
前職の方には会うたびに謝ることしか出来ない、苦い経験。
今はできているか、といえばまた出来ていない。
だが設定・構築系のタスクはAnsibleでplaybook化、スクリプトを社内Gitで共有を徹底している。
Sphinx使ってみよう。
CloudWatch
- デフォルトで取れるメトリクスでは足りない項目多いのでカスタムメトリクスで対応。
2週間しか値を保存しておけないというのは致命的
→過去の値がわからない→改善を数値で見れない自分としては fluentd + Graphite + Grafana 構成をおすすめしたい
監視
- Zabbix推しが多かった
- しかし、「Zabbixを使おう！」というわけではなく、監視ツールをちゃんと使おうという内容
オオカミ少年にならない
通知メール飛ばしすぎて見ない状態…。監視あるあるだけど超重要。
適切な閾値調整大事。Nagios派の自分としても同じ運用ツールの話として興味深く聞けた。
基本的にやっていることは一緒。監視→視覚化→通知・アクション実行。どう自動化するか・
追加したサーバーの自動追加はZabbix便利そうだと思った。
Serf使って対抗中（近いうちにQiitaにかきたい）
個人的まとめ
運用縛りということで業務的にも近く、更に経験豊富な方たち揃いだった為、
個人的にお話をさせていただいた際にも面白い話がたくさん聞けてとても楽しかったです。
今回、懇親会初参加でしたが、参加出来て本当に良かったです。
いつもブログやスライドを拝見して参考にさせて頂いている@zembutsuさんにお会いできたことも個人的に嬉しかった。
勉強会に参加させていただくことが多くなってきており、仕事を早退して行く日もある。
そうした時は特に業務に生かせるようにしなくてはいかないと思い、メモを晒すようにしてみた。
（7月に飲みに連れて行ってくださった方からのアドバイスが大きいです。あとは何してきたとかの報告が面倒というのも…。）
とにかく継続することが大事。
早く技術系のも書かないと…
個人ブログにしてもいいのだけれど、Qiitaのほうが管理楽で見てもらえる率が高いのでしばらくはこちらで。