「JAWS-UG 千葉支部 Vol.4 – AWS運用縛り」に参加してきました

本日松戸で開催された「JAWS-UG 千葉支部 Vol.4 – AWS運用縛り」に参加してきましたので、参加メモをエントリにしておきます。
あくまで個人的な参加メモですので、内容については公開される(はずの)各プレゼンのスライドをご覧ください。

ちなみに、Togetterでまとめていただいたものはこちら
1713_normal_1387263538_logo_450x400


「クラメソ保守運用担当からみたAWS使っててよかったこと」クラスメソッド株式会社 植木 和樹さん@czkuk

保守と運用

保守=「システムをあるべき状態に保つ」
運用=「正常に稼働しているシステムを用い手順やルールに従って実施する業務」
⇒面倒は全部AWSに任せる

AWSの障害復旧:EC2 Stop⇒Start

  • 再起動すればサービス再開する作りにしておく・・・これはアプリケーション開発者の責任
  • AutoScalingでAutoHealingしとくと安全

AWSの障害原因調査:AWSサポート

AWSのバックアップ:自動スナップショット

AWSの監視:CloudWatch

  • 必要に応じてカスタムメトリクスを活用
  • CloudWatchは監視項目数が膨大なので全部個別にアラート設定するのは現実的ではない⇒Zabbix等を併用
  • CloudWatchの保存期間は2週間と非常に短い
  • Webサーバー1台でもELB入れとくとリクエスト数、レイテンシ、HTTPステータスコード等見れるので便利でよい

AWSの定型業務:awscli

  • 運用はドキュメントドリブンでやるもの
  • マネジメントコンソールは頻繁にアップデートされるので画面キャプチャベースの手順書はすぐ古くなる
  • awscliならコマンドコピペだけで済むし、操作ログも残って便利

おすすめ


「エンジニア3人で支える月間10億PV」株式会社DoBoken 磯部 有司さん

ライトニングトーク

Facebookの好感度をCloudWatchで監視する

ZenClerk(リアルタイムにクーポンを配信するサービス)

・昔話:スポットインスタンス100台->200台に一気に増やしたら、全体の相場が上がってもともと生きてたインスタンスも含めて200台が同時DOWN・・・!?

ZenClerkのアーキテクチャ

  • ビジターとアナライザを分けているのは、アナライザ側でNode.jsを使っていて、Node.jsがシングルスレッドであるため。ビジターから通知を受けたアナライザが解析完了した際にビジターに通知する仕組み。
  • ブラウザとビジターの間だけでなく、ビジターとアナライザの間でもELBを使うように(キューとは違うモデルで)デザインしている。
    • (Internal ELB使う例は結構ある)

    モニタリング四原則

    • 大切な情報を見極める
    • 人に気付いてもらう
    • サービスを組み合わせる
    • オオカミ少年にならない

    大切な情報

    • MongoDBの健康状態
    • クライアントサイトのJavaScriptエラー⇒errbit(Airbrakeのクローン)で監視

    監視レベル

    • メールだとだれも見ないので、電話、チャット、管理画面で通知

    CloudWatch Tips

    • INSUFFICIENT DATAにアラートをセットすることができる
    • でもINSUFFICIENT DATAに変化するにはタイムラグがある
      ⇒全然関係ないサーバーも全部ELBにつっこんで、UnhealthyHostCountで見るとタイムラグが少なくて便利

    「ドキュメントを書こう! 運用自動化時代のドキュメンテーション」
    運用設計ラボ合同会社 波田野 裕一さん @tcsh

    運用ドキュメントは大事

    アンドキュメンテッド設計&運用は致命的な「知識のロスト」を生む可能性がある

    手段と目的を間違えてはいけない

    Dev: 手段の比重が大きい
    Ops: 目的の比重が大きい

    「問題を根性で解決するのは馬鹿です。 問題をエンジニアリングで解決するのがエンジニアの仕事です」
    ⇒データ(QCD)に語らせるのがエンジニアリング⇒運用現場はエンジニアリング

    クラウド時代のドキュメントの作り方

    • Level1. 整理
    • Level2. 客観化
    • Level3. 脱属人化

    How(実装) + Why(設計) = KnowHow(運用現場の資産)

    それでもドキュメントを書けないなら、ガイドラインやベストプラクティスに極力準拠する
    運用ドキュメントのアウトソーシング

    AWS CLIのドキュメントはSphinxで作成されている

    CLIリファレンスのURLにあるlatest/の後ろに _sources/を追加して、末尾の.htmlを .txt にするとreSTソースが見えるとのこと。(Sphinxデフォルトの動作)
    具体例:
    HTML⇒http://docs.aws.amazon.com/cli/latest/reference/iam/create-group.html
    RST⇒http://docs.aws.amazon.com/cli/latest/_sources/reference/iam/create-group.txt


    「AWSを含めたハイブリッド環境の監視の実現 ~Zabbixのクラウド対応モジュールHyClops~」TIS 株式会社 池田 大輔さん@ike_dai

    CloudWatchで統合監視はしんどい

    AWSの監視と言えばCloudWatch

    • 2週間しかデータが残らないので、長期にわたった傾向を見づらい
    • 毎回APIをたたくのはめんどくさい

    ⇒CDP: Monitoring Integration Pattern

    なぜZabbix?

    • 監視の基礎となる作りの部分がよくできている
    • 監視設定も手間が少なく自動化の枠組みが充実している

    ⇒監視という活動についてトータルでカバーできる
    見た目は今風ではない。New Relicみたいにかっこよくはない。

    Monitoring Integration PatternをZabbixで実現する

    • スクリプトをたたいて監視結果を登録する機能がZabbixにあるので、それでAPIをたたけばよい。
    • Zabbix Agentをインスタンス側に入れれば、インスタンス内部の情報もとれる

    ⇒インスタンス内部の情報もCloudWatchの情報も全部統合監視できる

    HyClops for Zabbix: Monitoring Integration Patternをもっとやりやすくするためのプラグイン

    CloudWatch Logs

    ログのタイムスタンプはdatetime_formatで指定

    • 一致していた場合⇒ログに出力された時刻がログの作成時刻として使用される
    • 一致していなかった場合⇒CloudWatchに連携された時刻がログの作成時刻として使用される

    ライトニングトーク

    LTについてだらだらまとめるのも野暮だと思うので、タイトルだけ。。。

    「LEGOマインドストームでシステム監視」株式会社Syun 高松 基広さん @TadaKazegaFuite

    「NO MONITORING NO LIFE – さぁ、監視を始めよう on AWS」クリエーションライン株式会社 前佛 さん @zembutsu

    「リアルタイムログ解析システムの裏側」株式会社ナレッジコミュニケーション 奥沢 さん

    「AWSサミット東京1日目のパネル<>振り返り」アマゾン データ サービス ジャパン株式会社 荒木 さん @ar1


    おまけ

    株式会社Syunの高松さんに、AWSステンシルを頂きました!ありがとうございます!
    awsステンシル

    以上!

  1. トラックバックはまだありません。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。