そういうこともある

エンジニア的な何か

わからないこと調べてみた - rails commit log流し読み(2017/08/03)

概要

y_yagiさんのrails commit log流し読みを読んでいてわからなかったこと調べてみました

y-yagi.hatenablog.com

わからなかったこ

  1. POSIX文字クラス

POSIX文字クラス

github.com:word: という記述を初めてみました

Unicodeプロパティと 似た機能を持つ記法として、POSIX 文字クラスと呼ばれるものがあります。 これらは上の省略記法とは異なり、文字クラスの中でしか用いることが できません。これらは [:クラス名:] という記法を持ちます。 また、[:^クラス名:]という記法でその否定を意味します。 以下の括弧では実際にどの文字にマッチするかが Unicode プロパティや Unicode コードポイントで示されています。
引用:https://docs.ruby-lang.org/ja/latest/doc/spec=2fregexp.html

種類は以下のものがあります

文字 説明
[:alnum:] 英数字
[:alpha:] 英字
[:ascii:] ASCIIに含まれる文字 (0000 - 007F)
[:blank:] スペースとタブ
[:cntrl:] 制御文字
[:digit:] 数字 (Decimal_Number)
[:graph:] 空白以外の表示可能な文字(つまり空白文字、制御文字、以外)
[:lower:] 小文字
[:print:] 表示可能な文字(空白を含む)
[:punct:] 句読点
[:space:] 空白、改行、復帰
[:upper:] 大文字
[:xdigit:] 16進表記で使える文字
[:word:] 単語構成文字

Rubyのバージョンによって挙動が変わったりすることもあるみたいです qiita.com

Mackerel Dayでわからないこと調べてみた(freeeでMackerelを使って一年間サービスを運用してみた事例紹介)

概要

Mackerel Dayに行ってきたのですが、用語とかがわからなくてイマイチ理解が進まなかったものなど、 自分が分からなかったものを調べてみました第三弾です

分からなかったこ

  1. Bugsnag
  2. Deep Security as a Service for AWS
  3. PagerDuty

対象セッション

  • Title freeeでMackerelを使って一年間サービスを運用してみた事例紹介
  • Time Time 16:00〜16:20
  • Speaker freee 浅羽 様

1. Bugsnag

調べてみた結果

www.bugsnag.com

主にはモバイルアプリのクラッシュログなどのログ管理に関して、最近の流れを知りたいと思いいろいろ物色してみました。類似サービスとしてはCrashlyticsなんかがありますが、いろいろ使っていると機能的に柔軟性が足りなかったりして目的に沿った利用ができないことが増えてきて、他に手頃なサービスあるのかなと思ったことも要因です。
引用:https://kazucocoa.wordpress.com/2015/02/12/bugsnag%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F%E3%81%8C%E3%80%81%E8%89%AF%E3%81%95%E3%81%9D%E3%81%86%E3%81%A0/

エラーをGithubのissueで管理したりと多彩な機能があるログ収集サービスみたいです。

2. Deep Security as a Service for AWS

調べてみた結果

WS上の仮想マシンに、Deep Security エージェントをインストール。6つのセキュリティー機能で仮想マシンの多層的な防御を可能にします。 特に侵入防御(IPS/IDS)機能に関しては、WindowsだけでなくLinux, Solaris等などの幅広いサーバーOSに対応し、さらに100以上のアプリケーションの脆弱性も保護することができます。
引用:https://licensecounter.jp/trendmicro/aws/

AutoScalingにも対応していて、サーバの増減に合わせて自動的にセキュリティ対策できるのは便利そうだと思いました

3. PagerDuty

調べてみた結果

www.pagerduty.com

PagerDuty - https://www.pagerduty.com/ アプリ、サーバ等からの通知をきっかけに、予め定義していたエスカレーションポリシーとスケジューリングに基いて様々なアクションを実行することができるSaaSです。
SaaSなので利用者側でサーバを用意する必要がなく、すべての操作/設定はWeb上のインターフェースから行います。
様々な監視ツール(Datadog, Mackerel, Zabbix 等) からのアラート通知をPagerDutyで集約して、予め設定/登録した任意の通知ルールに従って様々なアクションを実行できます。
通知の例として 電話・SMS・メール・プッシュ型のアラート通知 (iOS or android 用のアプリが用意されています) 等があります。
引用:http://blog.serverworks.co.jp/tech/2015/10/13/start-pagerduty/

IFTTTみたいな感じですかね。サーバからの通知で何かアクションを実行するというのを自動化したりしたいときに便利そうです

Mackerel Dayでわからないこと調べてみた(Mackerel インフラ基盤 AWS 移行の舞台裏)

概要

Mackerel Dayに行ってきたのですが、用語とかがわからなくてイマイチ理解が進まなかったものなど、 自分が分からなかったものを調べてみましたの第二弾です

分からなかったこ

  1. 時系列データベース
  2. Redis Cluster
  3. シャード
  4. Unbound
  5. コンテンツサーバとキャッシュサーバ
  6. vpcのリゾル
  7. TTL60
  8. iptablesのチェイン

対象セッション

  • Title Mackerel インフラ基盤 AWS 移行の舞台裏
  • Time 15:00〜15:20
  • Speaker はてな 大野 様

1. 時系列データベース

調べてみた結果

そもそも時系列データ・時系列データベースとは?
時系列データというのは、特定の時間ごとに何らかの値を取得した際の、取得した一連の値を指します。 例えば、以下のようなフォーマットをしたデータなどは時系列データにあたるでしょう。

timestamp1,key,value1  
timestamp2,key,value2  
timestamp3,key,value3  
:  

時系列データベースとは、上記のような時系列データの保存・処理に特化したデータベースです。 Web インフラストラクチャーの文脈では、サーバのメトリクス等が時系列データにあたります。
Web サービスの文脈では、Web サーバの増加や複雑化により、高い解像度の様々なメトリクスを長期間保持したいという要望や、 サーバのメトリクスをより統計的に解析し、アラーティングの精度を向上させたいという要望などがあり、 様々な会社や組織で独自の時系列データベースが開発されているという事情があります。
引用:http://techlife.cookpad.com/entry/timeseries-database-001

2. Redis Cluster

調べてみた結果

Redis Cluster 機能を使うと、Redis インスタンスクラスタリングすることができる。
通常のレプリケーション構成ではなく、複数の master ノードを束ねて協調動作させ、クラスタ全体で保持するデータ量をスケールアウトさせることができる。
引用:https://qiita.com/key-amb/items/c3c947578b043a6b4096

3. シャード

調べてみた結果

シャード (API/CLI: ノードグループ) は、1 〜 6 個の Redis ノードで構成されるコレクションです。Redis (クラスターモードが無効) クラスターを構成するシャードは 1 つに限られます。Redis (クラスターモードが有効) クラスターは 1 から 15 個のシャードで構成できます。クラスターのデータは、クラスターのシャード間で分割されます。シャードに複数のノードがある場合、1 つを読み書きのプライマリノード、その他を読み取り専用のレプリカノードとするレプリケーションが実装されます。
引用:http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/UserGuide/Shards.html

4. Unbound

調べてみた結果

UnboundはBINDの代替を目指したDNSキャッシュサーバです。 2008年5月20日に正式版1.0がリリースされました。 オープンソースのソフトウェアとして公開されており,ライセンスはBSDライセンスです。 UnboundはNLnet Labsにより開発と保守が行われています。
UnboundはDNSキャッシュサーバとしてはフルスペックであるため,BINDを置き換えることができます。しかし,DNSコンテンツサーバとしては機能しないので,BINDを完全に置き換えることはできません。しかし,後述するようにDNSキャッシュサーバとDNSコンテンツサーバの役割は異なるため,この割り切りは良いでしょう。
引用:http://gihyo.jp/admin/feature/01/unbound/0001

スライド調べてみたから若干脱線しますが、DNSコンテンツサーバとDNSキャッシュサーバがそれぞれどんな役割なのかよくわからなかったので、さらに調べてみました

5. コンテンツサーバとキャッシュサーバ

さて、このDNSサーバさんですが、大きく分けて二種類あります。
一つは、自分の管理している情報を教えてあげるのがお仕事のDNSサーバさんです。
自分の中にIPアドレスドメイン名の対応表を持っていて、問い合わせに対して「あー、そのIPアドレスはこのドメイン名だね~」「そのIPアドレスはこのドメイン名だよ~」と答えてあげます。対応表に載っていなければ「知らないな~」と答えます。
もう一つは、どんな手を使おうともお問い合わせに答えてあげるのがお仕事のDNSサーバさんです。
問い合わせがあると、答えを知っていそうなDNSサーバさんに「ねーねー。こんな問い合わせが来たんだけど、答え教えてよ」と訊きに行きます。言わばカンニング野郎ですね。
DNSコンテンツサーバ 自分の管理している情報を教えてあげるのがお仕事のDNSサーバ
DNSキャッシュサーバ 他のDNSサーバさんに答えを教えてもらいに行くDNSサーバ
引用:http://wa3.i-3-i.info/diff10dns.html

dnscache

うまく調べられなくてわかってないです。

dnsmasq

うまく調べられなくてわかってないです。

6. vpcのリゾル

調べてみた結果

VPC

Amazon Virtual Private Cloud (Amazon VPC) により、アマゾン ウェブ サービス (AWS) クラウドの論理的に分離したセクションをプロビジョニングできます。これにより、AWS リソースをユーザー定義の仮想ネットワークで起動できます
引用: https://aws.amazon.com/jp/vpc/

ゾル

ドメイン名を元にIPアドレス情報を検索したり(正引き)、IPアドレスからドメイン名の情報を検索したり(逆引き)するのが目的である。名前解決を行うことから「解決するもの」(resolver)という意味でリゾルバと呼ばれている
引用:http://www.weblio.jp/content/%E3%83%AA%E3%82%BE%E3%83%AB%E3%83%90

これまでWebブラウザがDNSサーバーにIPアドレスを問い合わせると説明してきたが,正確に言うと,IPアドレスを問い合わせるのはWebブラウザなどのアプリケーションに含まれる「リゾルバ」と呼ばれるプログラムである。
引用:http://itpro.nikkeibp.co.jp/article/COLUMN/20071022/285173/

ブラウザ等アプリケーションにリゾルバが含まれていて、リゾルバがDNSサーバーに問い合わせにいくという流れみたいです

7. TTL60

調べてみた結果

DNSでは、Authoritative name server が特定のリソースレコードに対してTTLを設定する。(再帰的な)キャッシングネームサーバが Authoritative name server にリソースレコードについて問い合わせたとき、(再帰的な)キャッシングネームサーバはTTLによって指定される時間(秒単位で)の間その記録をキャッシュする
引用:https://ja.wikipedia.org/wiki/Time_to_live

TTL60はキャッシュの保持期間が60秒って意味っぽいです

8. iptablesのチェイン

調べてみた結果

iptablesは複数のチェックポイント(チェインと呼ぶ)ごとにパケットの通過を許可、拒否、破棄する条件を設定できます。
各チェインはfilter、nat、mangleという3つのカテゴリ(テーブルと呼ぶ)に分類されますが、ここではLinuxサーバにおけるファイアウォールを扱うことが目的なのでfilterテーブルにのみ言及します。
引用:https://qiita.com/fusagiko/items/bc2e9ae9392a28b73734

Mackerel Dayでわからないこと調べてみた(Mackerelリリース3周年の振り返りとこれからの成長について)

概要

Mackerel Dayに行ってきたのですが、用語とかがわからなくてイマイチ理解が進まなかったものなど、 自分が分からなかったものを調べてみました

分からなかったこ

  1. Twilio
  2. グラフアノテーション
  3. ディザスタリカバリ

対象セッション

  • Title Mackerelリリース3周年の振り返りとこれからの成長について
  • Time 14:10〜14:30
  • Speaker はてな 杉山 様

1. Twilio

調べてみた結果

Twilio

Twilioとは、様々な通信チャネルを連携するためのコミュニケーションAPIです。 電話、SMSのほか、ビデオ、チャットなどの通信手段を アプリケーションに簡単に埋め込むことができます。
引用:https://twilio.kddi-web.com/function/

API経由で固定電話やブラウザなどと繋いで、通話やSMS送受信、ビデオやチャットによる通信ができるようです

2. グラフアノテーション

調べてみた結果

サービスやロールに関係する様々な事象をグラフにアノテーション(注釈)として残すことができます。 アプリケーションのデプロイやバッチ処理実行、テレビCMなどのビジネスキャンペーンとの相関を考慮しながらリソース状況を把握できるので、より直感的な分析ができるようになります。 とても役に立つ機能ですので皆様もぜひ使ってみてください!
引用:https://mackerel.io/ja/blog/entry/weekly/20170127

3. ディザスタリカバリ

調べてみた結果

日本語に訳すと「災害復旧」となります。 地震津波などの天災や、テロ、不正侵入などによりシステムが壊滅的な状況になった際に復旧・修復すること、また、その災害に備えたシステムや体制を指します。 引用:https://www.idcf.jp/words/dr.html

イベントレポート:Mackerel Day 2017/10/5

2017年10月5日開催のMackerel Dayに行ってきたので、イベントのレポートです

イベント概要

エンジニアをワクワクさせる「直感的サーバー監視サービス」 Mackerel(マカレル)の正式リリースから3周年を祝して Mackerel Day を開催します。
今回はAWS様の大きな会場をお借りしました、たくさんの方にお越しいただけますので、ぜひふるってご参加ください。
当日はMackerelを古くから使っているユーザ様から今年新たにご利用を始めたユーザ様まで幅広いユーザ様がご登壇していただきます。

Mackerelリリース3周年の振り返りとこれからの成長について

選ばれる理由

  • 導入が簡単でわかりやすい
  • 開発スピード(毎週リリース)
  • マルチクラウド
  • 日本語サポート

おすすめ機能

  1. 多彩なアラート通知
    • チャットへのグラフ月通知
    • SMSや電話加電で通知(Twilio)
  2. URL外形監視
    • SSL証明書の有効期限
    • カスタムヘッダ・メソッド
  3. AWSインテグレーション
  4. 大規模環境との親和性
    • 任意の権限でユーザーをオーガニゼーションへマッピング
  5. グラフアノテーション

直近の主要なリリース

  1. Azureインテグレーション
  2. グラフボード機能
    • サービス内に任意のグラフを集めたページを作成可能(便利!!)
  3. システムプラットフォームの堅牢化
  4. DevOps Competency初認定

リリース予定

  • メトリックデータの粒度を維持しながら保持 一分粒度を400日保持
    ※その他にも色々…

どういう方向で成長させていくのか

世の中の流れ

  • 動的でかつ複雑化するインフラ環境
  • クラウドサービス
  • コンテナを始めとする仮想化技術

Mackerelとしての使命

  • エンジニアにとってエッジなサービス
  • ビジネスを加速化させるための仕組みであること
  • 監視するだけでなく動的で複雑なインフラをより簡単にわかりやすくする仕組み
  • DevOpsライフサイクルの中核として効率化を促進

shitake4.hatenablog.com

アプリケーションエンジニアがMackerelで楽しく監視構成している事例

観点

  • アプリケーションエンジニアから見た事例

導入ストーリー

  • DMM.makeでの事例
  • オンプレミスからクラウドへ移行
  • クラウド移行することに伴いエンジニアの責務が変化

移行プロジェクトについて

  • 使用するサービスAWS
  • アプリケーションは大きく分けて3つが移行対象
  • 担当は2人(専任ではない)

監視どうするか?

今まで
  • Zabbixで監視し、アラートが着たら対応
  • 監視サービスを独自にホスティングは厳しい
これから(構想)
  • AWSで一括管理を想定
  • CloudWatchとLambda
採用するための観点
比較するに当たっての観点
  • 利便性

Mackerelは簡単かつ柔軟に設定できた。メトリクス取るのが楽

監視構成

監視対象
  1. EC2,ALB,RDS アプリケーションのホスティング以外はマネージドサービスにお任せ
  2. EC2
  3. その他 AWSインテグレーションにお任せ
Ansibleでのエージェント設定
  • 狙った構成がサクッと入った
  • 気持ちいい
監視設定の管理
  1. Jenkinsからmkr monitors push
    • 設定のJSONはGit管理
    • 各種メトリクス監視、URL外形監視
  2. WEB上で設定をお試しすること多し
  3. チャンネル設定は手設定
サービス・通知レベル毎にチャンネル設定

得られた価値

  • 楽な監視構成
  • つまづくことがほぼなし
    1. エージェントの設定
    2. プラグインの利用
  • 日本語ドキュメント

気づき

  • リソースが余ってる
  • 通知時のグラフでパッと見てヤバさを把握できる
  • アプリケーションエンジニアでも異常がわかる
  • Monitors設定はオンプレベースで確認中

まとめ

  • 必要充分な監視を行えている
  • アプリケーションエンジニアでも扱える
  • 導入が楽で、運用が楽しい

Mackerel インフラ基盤 AWS 移行の舞台裏

AWS移行の流れ

  • Mackerelのサービス名を分けて移行
  • DB、アプリケーション、DNSと切り分けて移行完了

※お客様から遠いところから移行

なぜAWSへ移行?

  1. 時系列データベース
  2. データセンター運用コストの削減

クラウドに移行して問題を解決したい!!

時系列データベースの移行

  • mackerel-agent, APIが送るメトリックを保存
  • 時系列データベースは自分たちで作り直した
  • 移行時にはデータをコピーしながら2拠点(aws,データセンター)に書き込んでいた

時系列データベースの運用(Redis Cluster)

想定していた状態

  • Elasticacheで運用
懸念点
  1. 動的にスケールできない
  2. クラスター作成後のノードが追加削除できない

実際の状態

Redis ClusterをEC2上で動かしている

Redis Cluster

複数のレディスをシャードとして分割している

  1. キーでシャードを分けている
    • シャードが偏ることがある、つまり負荷が偏る
  2. シャードが偏るとどんなことが起きるのか
  3. メトリックはredisプラグインで収集している
DNSキャッシュサーバ

社内の権威サーバーがデータセンタにある

  • データセンタのサーバに問い合わせる構成
  • 拠点ごとに権威サーバはない
  • 社内ツールを使う為に依存している
Unbound
メリット
  1. キャッシュを効率的にフラッシュできる
  2. 他のキャッシュサーバの選択肢
    • dnscache
      • フラッシュさせるには停止が必要
    • dnsmasq
      • すべてのレコードをフラッシュしてしまう
unbound 運用
  1. VPC内のリゾルバはTTL60で固定されている
  2. .ioドメイン不調時にはすぐに気づいた
    • Mackerelもmackerel.ioにメトリックを投稿している
アクティブスタンバイ構成の実現
  1. DBはアクティブ、スタンバイ
    • keeepaliveでmaster,backup構成
  2. keepalivedによるフェイルオーバ
AWSでのネットワークモニタリング

DCではスイッチからメトリックを収集していた

ネットワーク安定性モニタリング
AZ間の通信料モニタリング
  • iptablesのチェインでみる
    • vpcフローログでなくても見れる

まとめ

  1. AWS移行の見えない部分についてのお話
  2. AWS移行は様々な技術に支えられている
  3. AWSに移行したことでMackerel自体の監視、モニタリングも進化している
  4. まだまだエージェントプラグイン便利にできる

shitake4.hatenablog.com

大丈夫! Mackerel には CRE がいます

CREとは?

顧客信頼性エンジニア

CREが在籍していることの意味

Mackerelによって提供されているもの

  • サーバ監視が効率化されるという価値
  • 動的なインフラ管理を実現することでDevOpsが加速されるという価値

→これらの価値はサービスが利用されることで生まれる価値

価値を支えるものは?

  1. プロダクトそのもの
  2. ユーザーからの信頼
    1. 技術力によって支えられている
    2. 向上させる他の要因

向上させる他の要因とは?

  1. 投げかけた質問に対し的確な回答
  2. プラグインの導入法などに対してドキュメントがあること
  3. 知らない人が短期間で把握できること

上記3点を解決するのがCRE

CREは具体的に何をやっているのか?

投げかけた質問に対し的確な回答

  • 寄せられた問い合わせにたして、出来る限り力になる
  • 技術的な課題には立ち向かいたくなる
    • インフラエンジニア、SREという肩書は少数精鋭
    • インフラ基盤の安定運用というミッションに対しても、その少人数のメンバーに大きな責任がのしかかっているという現状

具体的な努力

  • Mackerelとセットで使われることの多い技術・プロダクトについても日々理解を深める
  • ミドルウエアの最新バージョンのコミットを追いかける
  • 社内勉強会
  • 輪読会

価値を向上させるもの1 投げかけた質問に対し的確な回答

成果(前期実績)
  1. 同営業日中の返答率:90%
  2. 〜翌営業日の返答率 99%
  3. やりとり(往復)の平均回数 2.0未満

価値を向上させるもの2 プラグインの導入法などに対してドキュメントがあること

  • 公式Webヘルプがいつでも閲覧可能
    • ヘルプドキュメント
    • APIドキュメント
  • 公式ブログ
ドキュメントの管理方法

価値を向上させるもの3 知らない人が短期間で把握できること

  • ハンズオンを開催
  • 直接説明に伺う
  • 魅力を伝える為にイベントに登壇

freeeでMackerelを使って一年間サービスを運用してみた事例紹介

  • Time 16:00〜16:20
  • Speaker freee 浅羽 様
  • slide

導入前の話

  1. Zabbixを使用

    • VPC毎にzabbix serverを運用
    • 機能が豊富なので作り込めば色々なことが出来る
      • しかし作り込みや運用に時間を取れない状況
  2. いくつかのプロダクトを評価した観点

    • 移行のしやすさ
    • プロダクトの進化スピード
    • 使いやすさ
    • コスト
      • AutoScalingとの親和性

ZabbixからMackerelへ

現在の監視構成

  • Mackerel
  • NewRelic
  • CloudWatch
  • Bugsnag
  • Deep Security as a Service

Service, Role, Hostの考え方

プロビジョニングやデプロイはEC2タグで処理を分けているので、タグの情報をそのままMackerelへ移植

サービス開発エンジニアとのコミュニケーション

  • ダッシュボードかサービス一覧のグラフを眺める
    • 定期的にパフォーマンス振り返り会を実施
    • ぽちぽち作るのは面倒なのでmkrコマンドで作る
    • さらに深掘りしたい場合は、NewRelicで確認する
  • 何かあったときやグラフをシェアしたいとき

デプロイの記録を行う

  • いつデプロイしたかわかるように記録

サービスメトリックの使い所

  1. サービスに紐づくメトリック
    1. レスポンスタイム
    2. 非同期ワーカーの未処理のキュー
    3. サーバ台数
  2. サービスメトリックの放り込み方

アラート通知

  1. 基本的にはslackに通知
    1. WarningはSREが見る
    2. Criticalは広めに通知
  2. 夜中のアラート
    1. PagerDutyなどは使わずに雑にbotが電話をかけていく
    2. slackに誰か反応したら電話を切る

Mackerelの設定

  1. Host Statusの初期状態はstandby

    • AutoScalingのUserDataが動いている間はアラート出したくない
    • UserDataの中でmkrを叩いてworkingに戻す
      • 構築でコケた場合も
  2. 実験的機能

    1. とりあえずonにしておく

Mackerelに欲しい機能

  1. 毎月の支払い(レシート)をPDFで欲しい
  2. AWSインテグレーションも自動退役機能が欲しい
    1. EC2でないリソースを主にstaging環境で作ったり消したりするので、消すスクリプトを作った
    2. タグ・除外タグをサービスごとに設定出来ると嬉しい

まとめ

全く問題なく運用できてます

質問

  1. Zabbixの頃のほうがよかったことはあるか?
    • 特にない。Mackerelで出来ないものもあったが、そもそも監視する必要のないものだったりしたので、監視すべきことが整理出来たのが、よかった

shitake4.hatenablog.com

Mackerelを導入して変わったN個のこと

使用状況

  • サービス:20
  • メンバー:100
  • ロール:300
  • ホスト:1000
  • サービスメトリック:300
  • 外形監視:70

Mackerelが使われるキッカケ

  1. nagiosの管理が大変
    • サーバーの追加、削除時に設定ファイルの更新が必要
    • SERF&イベントハンドラでいちおう自動化は可能
    • 監視サーバーが複数ある
      • どこをみればいいのかわからない
  2. クラウドらしい仕組みへの移行
  3. サーバーの管理を手で行っていた
  4. サーバーがボコボコ生まれ変わる時代だと厳しい
  5. 監視設定の追加
  6. 情報の一元管理
    • サーバ自体とパッケージ情報も管理したい
      • パッケージ更新したっけ?をなくしたい
    • 監視サーバーが複数あるのも同様の問題

Mackerelに移行した結果どうなったか?

  1. nagiosの管理が大変
  2. クラウドらしい仕組みへの移行
    • サーバーの管理が楽
  3. 情報の一元管理
    • Mackerelのページを見ればすべて載っている

どのような使い方?

  1. サービスディスカバリとして使う
    • 何かをデプロイするときに、デプロイ先を知りたい
  2. 退役忘れ、ロール設定忘れをチェックする
  3. 退役忘れで無駄にライセンス消費
  4. ロール設定忘れて、運用に支障
  5. ロール毎のサーバー数を数える
  6. consul未所属サーバーの検知
  7. リリースタイムを計測したい
    • 改善したときにどの程度改善出来るのか知りたい
  8. ステータスコード毎のリクエスト数を取得
  9. sideKiqのジョブ数監視
    • ジョブが詰まって障害になっている時に気づきたい
    • 過去の特定時点でどの程度ジョブが溜まっているかみたい
  10. TreasureDataのジョブ数監視
    • ジョブが詰まると他のジョブに影響することがある
    • エラーには気づけるが、その後リカバリ作業が必要
    • ジョブ数を関しして、閾値を超えたらアラートしたい
  11. GHE(GitHub Enterprise)のディスク使用量監視
    • ディスク利用量が突如異常な増加
    • いまいち原因が分からないので監視したい
  12. お問い合わせ数を監視
    • お問い合わせが急増していないか知りたい
    • リリース後の思いがけないバグ

まとめ

  • やりたいことに集中できる
  • 1つのダッシュボードを見ればすべてわかる
  • インフラ周りだけでなくいろんなものを気軽にモニタリング

Driving Mercari with 50+ custom Plugins

  • Time 17:00〜17:40
  • Speaker メルカリ長野 様
  • slide

メルカリ&インフラストラクチャの紹介

Mackerel導入理由

  1. 異なるインフラストラクチャの監視項目・内容を共通化する
    • 以前はregion毎にzabbixを利用。バージョンがずれたり監視内容の差が発生
    • Service/Roleを利用することで管理
  2. サービスメトリクスの柔軟な使い勝手
  3. nagios互換のplugin

Mackerel以外の監視

  1. Kurado
    • 基本的なメトリクスはこちらで管理
  2. NewRelic
    • アプリケーションのチューニングの参考

Service/Role設計&デプロイ

  1. サービスを行うregion毎にServiceを分ける
  2. 外形監視は別Service
    • 通知チャンネルを分けるため
  3. QA環境・マイクロサービス

Role設計

Role名のPrefixに意味を持たせる

  • role- サーバーの基本的な役割
    • role-mysql, role-applicationなど
  • z- 共通の役割
    • 多くのサーバーはz-commonに属する
  • x- 監視上のフラグ

ROLEの自動付与

サーバに付与するRoleをどこかで自動で設定したい
conf.d以下のファイルに #role-def:ロール名 を追加すると起動時に読み込み、agentの起動オプションとして利用

  1. Roleのprefixに意味を持たせる。conf内にRole名を書いて自動で設定
  2. confはansibleで配布

監視にまつわる数字

  1. 監視ルール数: 265
  2. Host毎の監視ルール数
    • Mysql 34
    • Application 39
    • Search 36
  3. カスタムプラグイン +50

カスタムプラグイン

z-commons

  1. check_resolver
    • resolv.confを独自に読み込んで名前解決する
  2. diff-detector
    • コマンド結果の変化があるとアラート
    • 'cat /etc/passwd', 'uname -a', 'hostname' を見ている
  3. check-iptables
    • さくらの専用サーバはすべてglobal ipを持つ。不要なサーバはdisableにして運用
    • 不用意な iptables --list でiptables_filterが読み込まれ、パフォーマンスに影響するのを発見
  4. check-uptime
    • 不意な再起動を検知
    • 閾値は2分-10秒。1回アラートが来てすぐに復旧する
    • Mysqlmemcachedでも行っている
  5. check-inode
    • inode 枯渇防止
  6. check-machine-exceptions
    • メモリ異常を検知した際のログを監視
  7. check-raid-disk(MegaRAID)
    • MegaCLIを使い各物理Diskの状態を監視
  8. mackerel-plugin-ntpq
    • OffsetとリモートとのSync状況の可視化
  9. mackerel-plugin-linux-lite
    • 2Coreから56Coreまでサーバがある
    • 一貫した監視閾値を設けやすいように可視化

z-commons以外のplugin

  1. periodic-checker
    • 特定の時間のみ監視を行う
  2. check-dns-rr
  3. check-spf-and-reserve-lookup
    • メール配信にて利用
    • サーバが持っているGlobalIPすべて確認
  4. chech-mysql-slave-sql-error
    • レプリケーションが止まった時に、その理由も通知してくれると便利で作ったPlugins便利で作ったPlugins
  5. check-mysql-msr
    • MySQLのMulti Source Replicationの監視
  6. mackerel-plugin-msr
    • check-msyql-msrの可視化

その他の取り組み

  1. 問い合わせ数の監視
    • 多くの人が参加するChannelへ通知
    • 障害の検知、影響範囲の把握
  2. 監視されていないサーバの自動抽出
  3. slackへの通知
    • 1日2回slackへ通知
      • 監視されていないサーバ
      • standby,poweroffのサーバ

まとめ

  1. コードを書いて問題を解決する
  2. Mackerelは使い勝手のいい監視ツール

AWS Ecosystem with Mackerel

  • Time 17:45〜18:15
  • Speaker 酒徳 様

DevOps関連サービス

  • ソースコードのバージョン管理
    • CodeCommit
  • ビルド自動化
    • CodeBuild
  • デプロイ自動化
    • CodeDeploy
    • CloudFormation
    • ElasticBeanstalk
  • ワークフロー管理
    • CodePipeline

CloundFormation

  • Infrastructure as a code
    • AWSリソースの環境構築を自動化
  • ChangeSet Support
  • StackSet Support

Security

  1. ユーザ/クレデンシャル管理
  2. アクセス権限管理
  3. 権限の委任と監査

イベント行ってみての所感

これからMackerel使いこなしていきたいなと考えてのイベント参加だったので、使うのが楽という発表を聞いて色々と触ってみたりしたいという欲求が更に高まりました

辛くなってきたら始めてみたい個人タスクの管理

毎日大量にメールが送られてきて、自分がやらなくてはいけないタスクが書かれたメールを見落としたり、タスク管理ツールをうまく使いこなせなかったりしている人に是非試してもらいたいTips

やりかた

やり方は非常にシンプル タスク管理ツールやメールを以下のカテゴリに分けるだけ!

  1. 今日やること
  2. やること
  3. やったほうがいいこと
  4. 人にお願いしたこ
  5. 人にお願いすること

※該当しないものなどは特にカテゴリ分けしない

運用方法

  1. 出社して一番先にタスク管理ツールのやること、やったほうがいいことの順番で確認
  2. 今日やることに上げられそうなものを確認し、タスク管理ツールの今日やることにカテゴリを変更する
  3. メーラーのやること、やったほうがいいことの順番で確認
  4. 今日やることに上げられそうなものを確認し、タスク管理ツールの今日やることにタスクを追記する
  5. 今日やることのリストにあるタスクをひたすらやる
  6. 帰社するタイミングで今日やることが残っていたら、またカテゴリを振り直す

運用してみて

半年くらいやってみてますが、今のところタスクのヌケ、モレは出ていないという感じです。もっとタスクの数が増えてきたりして破綻しそうだったらまた考えてみようかなと思ってます タスクツールで期限とか設定しておけば、リマインドもしてくれるので、つい忘れたとかも今のところはなさそうです

僕が使っているツール

  • Wunderlist
    • シンプルな機能と使い方によって柔軟に運用できそうだったので、好んで使ってます
  • Gamil
    • ラベルにカテゴリを作成して分類してます

ソースコードのコメントで見るTODOって何?

概要

ソースコード中のコメントの # TODO: 仕様に問題ないか確認する のような記述の種類を調べてみた

なんだったか

# TODO のことをアノテーションコメントという

他にもあるの?

TODO以外にも色々あった。種類は以下の通り

キーワード 内容
TODO あとで追加すべき内容を表す
FIXME 修正すべき箇所を表す
OPTIMEZE パフォーマンスの最適化をすべき箇所を表す
HACK リファクタリングすべき箇所を表す
REVIEW レビューすべき箇所を記す

アノテーションコメントの便利な使い方

Ruby on Railsの場合、アノテーションコメントが書かれた箇所を一覧で出力することができる

やり方(Ruby)

  1. TODO,FIXME 等を一覧で出力する

  2. 特定のアノテーションのみ表示する $ rake notes:custom ANNOTATION=FIXME

    ※独自のアノテーションも可能 file # DANGER: 注意 $ rake notes:custom ANNOTATION=DANGER

  3. アノテーションの書き方

# + 半角スペース + アノテーション + 半角スペース + 本文

ex)

 # TODO: ここを修正

参考サイト

ruby-style-guide Rails | コード内のコメントを見つける方法 (TODO、FIXME、OPTIMIZE、HACK、REVIEW)

RspecでStrongParamtersを使ってハマった

rspecでStrongParamtersを利用したテストを書いた時にはまったので、備忘録として書いてみる

StrongParamtersとは?

4.5 Strong Parameters strong parametersを使用することで、Action ControllerのパラメータがActive Modelのマスアサインメントに利用されることを禁止できます。ホワイトリストに追記したもののみ使用できます。これは、多くの属性を一度に更新したいときに、どの属性の更新を許可し、どの属性の更新を禁止するかを明示的に決定しなければならないことを意味します。大雑把にすべての属性の更新をまとめて許可してしまうと、外部に公開する必要のない属性まで誤って公開されてしまう可能性が生じますので、そのような事態を防ぐために行います。 (Railsガイド)https://railsguides.jp/action_controller_overview.html

渡ってきたパラメータのホワイトリストを用意し、ホワイトリストの項目が存在しない場合にエラーとして処理することができるもの

今回ダメだった書き方

Rspec 3.1.0 使用 Rails 4.1.8 使用

let(:params) { { first_name: '佐藤', last_name: '太郎'} }

正しい書き方

単純でHashに対してStrongParametersを書くのではなく、ActionController::ParametersでNewする必要があった

    let(:input) { ActionController::Parameters.new(user: params) }
    let(:params) { { first_name: '佐藤', last_name: '太郎'} }