AWS運用専門の勉強会「Ops JAWS#5」に参加してきました #jawsug #opsjaws

2016.04.21

森永です。
AWS運用管理コミュニティが主催するAWS運用に関する勉強会Ops JAWS#5に参加したのでレポートします。

登壇された方は #opsjaws をつけてスライドをつぶやいていただくと拾いに行きます。

開会

OpsJAWS恒例のビアバッシュ形式です。
開会前からビールなどドリンク、ピザが振る舞われます。

DSC_0604

食べるのに夢中でピザの写真撮り忘れました。。。。

挨拶

野村総合研究所 宮越さん

DSC_0605

OpsJAWSについてのお話
AWSの運用についてノウハウを発信する場
運営メンバーが増員 3人→10人
いつも司会は宮越さん

今回から山中さんが司会を!

信興テクノミスト 山中さん

DSC_0606

写真がすき
Amazon Prime PhotoがでたのでDropBoxから乗り換えた

OpsJAWSの参加経験はなし

目的 - 運用ノウハウを習得したい - 色々な人の話を聞きたい

DevOps 運用アンチパターン3連発

ヴィジョンアーツ株式会社 岡田さん

DSC_0607

DevOps運用アンチパターン

運用を無視したログ

タイムスタンプなし フォーマットバラバラ 調査や再現に必要な情報がない トレース垂れ流し

障害時の切り分けが困難

機会的に処理できるようログを整理
「フォーマット」と「メッセージコード体系」を規定
運用観点から重要度に応じて分類(プログラムでの重要度と運用での重要度は違う)

  • INFO
  • WARN
  • ERROR

TransactionIDでシステム全体にまたがるリンクを確保
Redshiftなどに入れて分析に備える

ログを味方につける!

いろんなツール管理する

管理し続けるのが大変 新しいプラグイン入れたいんだけど、と言われても難しい

SaaSにしよう!

  • 構成管理 GitHub
  • チケット管理 GitHub
  • 認証 GitHub
  • CI Circle CI
  • プロビジョニング Cloud Formation Elastic Beanstalk
  • 監視・メトリクス Cloud Watch Datadog
  • コミュニケーション Slack

当番制なのに一斉通知メール

監視対応できるのが一人しかいない
メール通知する人を増やそう!
増やしても結局一人しかやらない
不幸な人を増やしただけ

CloudWatch → SNS → OpsGenie → slack
OpsGenieは緊急だったら、当番に連絡。
いなかったらサブに、いなかったら次。。。と設定可能

初報はメール、再通知はメール+電話、次は次の連絡先にという風設定できる
電話が英語なので混乱する

Now Hiring!

QA

Q. PagerDutyではなくOpsGenieにしたのはなんで A. 導入した当時はAWSとの親和性が高かった

Q. つきいくら? A. 月額ひとり15ドル。プランによって違う

Q. 日本語の電話はある?
A. ないとおもう

CloudWatch Eventsを使って楽をする 〜AMI削除編〜

クラスメソッド株式会社 千葉

DSC_0608

こちらの記事について話しました。

CloudWatch Eventsとは

素敵なサービス
いろいろな運用を楽にできる
ブループリントがいろいろあるのでそちらを使ってもいいし、自分でLambda書いてもいい

AMI削除をトリガにスナップショット削除

AWSで何か起きたら自動で処理を行う、ができるので運用が楽になる

cloudpack流AWSサポートのベスト・プラクティス! 

アイレット株式会社 新谷さん

DSC_0610

スライドは上がり次第追加します。

AWSサポート入ってますか?
AWSサポートは素晴らしい!という話

CloudPackはAWSサポート特別賞受賞!

1日のサポート問い合わせ件数は3~5件
多くても10件

上限緩和、暖気申請が一番多い
障害調査、仕様確認が次ぐ
仕様確認は社内でノウハウをためて、なるべく問い合わせない

英語の表示で問い合わせると、日本のサポートに届かないので注意!

気をつけていること

  • 対象の明確化
    • EC2インスタンスID
    • RDS、ElastiCacheのDNS名
    • どれを調査して欲しいか!
  • 直近の変更内容がないか
    • インスタンスタイプ変更
    • プログラムの変更
    • パラメータ変更など
  • 現在のサービス影響など焦りアピール
    • 現時点でサービス影響が出ているのか、収まっているのか
    • リリース前の追い込みで性能が出ないので困っているなど

他に、発生時間、似たような環境があればそちらの情報を伝えると良し

サポートのレベルの違い

  • ベーシック
  • 開発者
  • ビジネス
  • エンタープライズ

エンタープライズは緊急事態(15分以内の一次回答)、TAMとの連携がつく

Now Hiring!

背伸びをしないAWS構成管理

日本ユニシス株式会社 会澤さん

DSC_0611

やってみた系負債 - やってはみたもののしばらく経つと、本当にこのパラメーターで動いてる?
- ルールを決めたけど、いつの間にか誰かが設定変更してる
- いざ何かやろうとしたらリスクを積んじゃう→高コスト体質
- 体制文化の問題 - インフラの設定変えるのは、リリース後はキツイ

理想論語っても現実的に聞こえない
ツールとか色々あるけど定着しない

ひとまず、手元の作業を改善していこうよ!

AWS Configを使っていきましょう!!
定期的にsnapshotを取得しておく
jsonのままだとお客さんや運用は見ないので、Excel化する
定期的にS3にあるsnapshotをLambdaでExcelにする
snapshotからCloudFormationやAnsibleで複製できるようにというのをチャレンジ中

差分を取れるようにするには最初が大事
ソースコード化はやっておく!バージョン管理も
Excelのフォーマットにパラメータを埋めてプロビジョニング
rspecやserverspec、awsspecでテスト

何が嬉しい?
今の状態が見える
当初構築した環境との違いが見える
AWSのサービスが使えるので社内に通しやすい

いきなりDevOpsはきついので、安全性を高めるところから始める
DevOpsへの道はインフラコード化&バージョン管理から
AWS Configでsnapshot使いましょう!

Kibanaと私

株式会社リンクバル 正現さん

DSC_0613

街コンジャパンを運営

実際起きた事例に対して、Kibanaでどう対処したか

JOIN後始めてKibanaに触れる
約1億行がたった2〜30秒で処理できる
SQLライクに検索ができる

OSS
解析や集計に全文検索エンジンのElasticsearchを採用
数クリックで色々なグラフを作成できる

  • 検索
  • フィルタリング
  • 表示範囲の絞込
  • 表示条件の保存・読み込み
  • csvエクスポート

などできる

  • プロフィール自爆テロ事件
    アクセスが少ない時間にCPU負荷が長時間続いている
    負荷が高いのにリクエストがない… プロフィール画面に不具合があることが判明

  • Bingbot事件
    EC2CPUの負荷が高いので調査
    直近30日あたりの総リクエスト数をUserAgentやIPで多い順に絞り込む
    絞り込むと、Bingは総リクエストの1/23を占めるが、refererはすくない

  • 超集中スクレイピング事件
    Kibanaで分析!
    突如EC2のCPU負荷が高く
    特定のIP群から短期間で超大量アクセスあり

  • アプリ用API激重事件
    特定の時間にレスポンスが重い
    該当時間にPUSH配信を行っている
    一部APIの処理が重いことが判明

今後の展望
ダッシュボードと使いこなしたい
自動アラート通知をしたい
Elasticsearchをドリルしたい

ITサービスマネジメントとSREの話

株式会社セクションナイン吉田さん

DSC_0614

  • キーワード
    • ITサービスマネジメント
    • 冗長化、キャパプラ、レジリエンス
    • 自動化
    • DevOps
    • コードが書けるインフラエンジニア
    • Site Reliability Engineering

ITサービスマネジメントとは
顧客のニーズに合致した適切なITサービスを提供するマネジメント活動全般

規格

  • ITIL
  • BS 15000
  • ISO/IEC 20000
  • JIS Q 20000

ITサービスマネジメントの中でやることがプロセスとして用意されている
計画、定義、運用、メトリクスをとる、などしてPDCAサイクルを回しましょう

Site Reliability Engineering

英語だけど以下の書籍が参考になるよ! http://www.amazon.co.jp/dp/B01DCPXKZ6

ソフトウェアシステムの一生の圧倒的大部分は設計でも構築でもなく、それを使っている期間ですよね? なんでそこに焦点を当てないんでしょうか?

システム管理者のアプローチからサービスマネジメントへ
ソフトウェア・エンジニアリングで問題解決を行える人間を採用し始めた

苦行を排除する
苦行の定義…マニュアル作業、反復作業で本番環境に縛られ、グロースにより直線的に増える作業
日々の50%以上を将来の苦行を取り除く作業に充てることでサービスをスケールアップする

自分の仕事をなくすために自動化しよう

SREはITサービスマネジメントとソフトウェアデベロップメントが合わさったもの

内容詰まってますのでスライドでご確認下さい。。。

クロージング

次回は5月末予定!
それとは別に、AWSクラウド運用ディスカッション会をやる予定

お疲れ様でした!!