tsalakh ain sus noam Huyah ol guf

勉強会のメモ。その他備忘録。参考にさせて頂いたサイトや資料はリンクさせて頂いていますが不都合があればご連絡ください。

【勉強会】July Tech Festa 2016

勉強会 noindex

2016−07−24 July Tech Festa 2016

これに行ってきた。

2016.techfesta.jp

Mackerelの技術の全て。これまでの道のりと更なる発展に向けて

はてな　松木さん

Mackerelの技術の全て。これまでの道のりと更なる発展に向けて

インフラを意識してコードを書くということ（ブログ）

developer.hatenastaff.com

Mackerel

  • 社内ツールはクラウド化の流れ、ビジネスの本質に集中するため
    • メールサーバはGmailとか、バージョン管理はGitHubとか
    • 社内監視サーバもクラウド→Mackerel
      • 小規模だと割に合わない
      • 大規模でも割にあわない
  • モニタリングの重要性の向上
  • 全てのサービスで健全性と一般的な監視関連のメトリックを同じように出力することをおすすめする
  • 開発体制
    • PM３名、エンジニア４名、デザイナー２名、インフラ１名、セールス３名
    • スクラム、２週間スプリント
    • IssueTrackerはGitHub、ゼンハブでカンバン的に見せる
    • リモートワーク、Slack、Hangoutを利用
  • アーキテクチャ
    • エージェントから定期的にメトリックを投稿HTTP REST API
    • Mackerel自体はオンプレで構築
    • LVS、nginx、Scala、Redis、Postgres、Graphite
  • Why Scala?
    • 表現力の高い静的型システム
    • 大きめのものをかっちり作るのに向いてる
    • はてブのリニューアルもScala
    • コンパイルは遅い
    • エージェントはGo-lang
  • Why Go?
    • ビルドするとバイナリが一個できてインストールすればすぐ動く
    • 常駐プロセス向き
    • フットプリントが小さい
    • 型がありつつコンパイルが早い
    • 実装をちょっと書いて、テストをちょっと書いて、テストを回すLL的なリズムでかける
    • コマンドラインツール向き
    • マイクロサービス的なアーキ向き
    • 機能の少ない方が向いている
  • URL外形監視ワーカー
    • 毎分、Webをたたくヘルスチェック
    • ここもGo-lang
    • MackerelからJob投入、redisにキューしてて、監視対象のWebをクローリング
  • 自動化機構の罠
    • 属人的になり、負債になりやすい
    • コードを書く＝即負債
  • Perl
    • だいたいどこでも動く
  • Ruby
    • fluent−plugin-mackerel
    • fluetndでメトリック取ってMackerelに投げるとか
    • Chef、CapistranoもRuby
  • Python
    • Graphite、Python製の時系列DB
    • RRDToolも時系列DB
    • ある時間帯にどうだったか、みたいに使う
    • TCPプロトコルで書いて、JSONで吐き出せる
    • 線形回帰分析
    • 読み込みパフォーマンス向上、何千メトリックでも動くように
    • 書き込み効率向上
  • ドッグフーディング
    • 自分が使うツールを自分で開発できる
    • 監視はつまらないものではない
    • 普通のWebアプリでは使わない技術を使う必要がある
    • アプリエンジニアとインフラエンジニアの差がなくなってきてる
    • ユーザごとに異なる技術スタック、言語、MW、OS、Cloud、を学べる
    • 自分のキャリアを活かして、ビジネスに結び付けられる
    • 自分より優秀なエンジニアと働ける、自分も研鑽できる

MOM (Message Oriented Middleware) に求めるモノ

DMM.comラボ　大山裕泰さん

www.slideshare.net

目的

  • MQ技術とMOMの特徴
  • MOMに求めるもの
  • 用途に応じたMOMの選択

What is MQ

  • プロセス同士のMessagePassingをサポートする仕組み
  • ProcessAとBの間にBrokerを介す
  • Pub/Subモデル、複数プロセス間の通信

Why MQ

  • もしMQがなかったら、
  • 連携の一部システムが停止した場合に、連携元は再送を考えたり
  • 連携先が一つ増えた場合、連携元は送信先を追加したり
  • アプリケーションが考えないといけない
  • MQがあれば、
  • AとBはお互いの状態を意識しなくて良くなる

  • Broker MQ
    • Pres:Scalability,Isolation
    • Cons:moreTraffic、moreLatency
  • Broker-less MQ
    • Pres:lessTraffic、lessLatency
    • Cons:Scalability,Isolation

What the best MOM is？

  • 完璧なMOMはない
  • 目的と、各特性を知って、選択が必要

特徴

AMQP（Advanced MQP）

  • 柔軟なメッセージルーティング
  • EXCHANGEがBrokerの役割
  • SubごとにQueueを用意
  • メッセージに情報をもたせてルーティングができる
  • （通常は全Queueにばらまいちゃうところ、条件で絞り込みができるという意味）

STOMP

  • Text-baseによる簡素なプロトコル
  • BinaryBased、テキストをバイナリにEncodeして送って、受信側でDecode
  • TextBased、テキストのまま連携
    • CPU負荷は下がる、NW負荷は高い

MQTT

  • 軽量なメッセージプロトコル
  • HTTPに比べて軽量、例えばヘッダサイズ
  • データ本体が大きければ誤差、IoTとか小さいデータの時に有効
  • 高品質な到達保証
  • At-most-once、最大で１つ
  • メッセージ投げっぱなしで、投げたら捨てる
  • At-least-once、最小で一つ
  • ACKが返ってきてから削除
  • Exactly-once
  • PUBLISH、PUBREC、PUBREL、PUBCOMP

KAFKA

  • Scalable
  • forAvailability
  • クラスタ構成を前提としたアーキテクチャ
  • forPerformance/Capacity
  • 順序保証をしつつメッセージを並列取得できる仕組み
  • 通常はSubを一つにすることで順序保証、ただスケールできない
  • KafkaはQueueをPartitionに分けて、SubをConsumerでわける
  • 順序保証が必要な単位でPartitionを分けておく（＝スケール）
  • キューの内容をストレージで永続化できる、他の製品はメモリ上に持つ

What purpose to use?

  • 非同期通信
  • システムの孤立化/Isolation
  • 負荷平準
  • スケーラビリティ
  • データストア

How MOM use？

SENSU

OpenStack

IBM

Conclusion

  • 用途に応じて最適なMOMを選択する

  • AMQP（RabbitMQ）

  • MQTT（ActiveMQ）
  • STOMP（NewtMQ）
  • Kafka
  • ZeroMQ

運用自動化のための、ゼロから始める監視設計

クリエーションライン　前佛雅人さん

www.slideshare.net

目的

  • ゼロから監視設計
  • ヒューマンエラーの考慮
  • 知識x経験を自動化でさらに活かす

現場あるある

  • なぜこの監視項目があるかわからない
  • いざ監視しようと思ってもできない
  • ツール選定の話をすると職場が荒れる

運用監視

  • 監視＝運用を評価する手段
  • キャパプラ、トラシューのため
  • あくまで、運用を回すために必要なものが監視

  • 0０年代から10年代にかけて、システム管理はサイト運用技術に拡張してきた

  • Architectures for open and scalable clouds

  • ペットから家畜へ

ゼロからの監視設定

サービスレベルの監視

非機能要件としてのシステム監視

  • プロセス
  • システムリソース
  • ログ
  • ネットワーク
  • ハードウェア

必要な知識

必要な経験

  • インターネット上に自分のサーバを運用する

なぜ自動化なのか

なぜ人は失敗するのか

  • 運用における失敗とは
  • システム稼動前→適切な設計で回避する
    • 不適切な運用フロー
    • 監視、通知設定ミス
  • システム稼動後→人が介在すると必ず失敗が起こる、精神論では回避できない
    • 作業ミス
    • 異常時のリカバリ失敗
    • 運用フローが機能しない
  • ラスムッセンのSRKモデル
  • 知識、規則、熟練
  • 知識がなく余裕がない
  • 規則に従ってマニュアル通りに事故を起こす
  • 熟練することによって手順省略、思い込み
  • 障害に強い設計
  • 手作業の排除と完全な運用や監視の自動化はちょっと違う
  • 人によるダブルチェックを信用しない
  • 手作業が入る場合は、自動テストツールを一緒に組み入れる
  • 局所最適化は意味がない
  • 自動化システムの維持が目的化してしまう
  • 何のための運用なのかを忘れずに
  • ツールに縛られると、ツールの制限に縛られる
  • 目的：誰が使うのか、開発は自社か他社か、運用は？
  • 個人は経験を蓄積すべき
    • 自分で手を動かす
  • 組織は知識を蓄積すべき
    • ドキュメント化を進めるべき、なぜこのような運用設計、監視設計をしているのか
    • 運用でもテストをする文化を根付かせる