そういうこともある

エンジニア的な何かの、プログラミングとかイベントレポートとか読書感想文

2回以上やることは自動化したい | SRE-SET Automation Night | イベントレポート

f:id:sktktk1230:20171207110228p:plain

2017年12月12日(火) SRE-SET Automation Nightのイベントレポートです
普段から作業の効率化や自動化といったものには非常に興味を持っているので、ここで共有して頂く知見を社内でも展開できればなと思い参加しました

イベント概要

"2回以上やることはなんでも自動化されるべきだ" Adam Stone, CEO, D-Tools
SREとSETという役割は、インフラやQAなどソフトウェア開発において手動で操作されることが多い領域を自動化するためにGoogleで作られました。このMeetupは例えば下記のような、生産性とプロダクトの品質を向上するための自動化ハックを学習し、共有し、コラボレーションするためのものです。

  • CI/CDを用いたプロダクトリリースの自動化に関する経験
  • Ansibleなどを用いたDevOpsの自動化
  • AppiumやSeleniumなどのUIオートメーションツールを使った第一印象
  • テストの自動化ハックとアドバイス
  • CircleCI, Travis, BitriseなどのクラウドCIサービスの経験
  • SeleniumやSlackbotを用いた日次タスクの自動化
  • どなたでも発表やLTしていただけますのでぜひご参加ください。

引用:[さらに増枠!] SRE-SET Automation Night

「Data processing, workflow and us ~How to manage automated jobs~」

  • Time 19:40-19:55
  • Speaker @syu_cream 氏
  • Slide

概要

BigQueryにログをアップロードする部分の話と統計情報を解析するコンポーネントの話でした

メルカリさんでは以前はこのような構成でログをBigQueryに送っていたようです f:id:sktktk1230:20171213095718p:plain

※ fluentd

ただcronジョブが失敗しやすくなったので、digdagでジョブ管理をしているようです

※ digdag

統計情報解析の話

以前の構成は f:id:sktktk1230:20171213095959p:plain

そこから Cloud Dataflowを使っているそうです

※ Cloud Dataflow
※ scio

また apache airflowも試しているとこのことでした

apache airflow

apache airflowを使って以下のようなメリットがあったようです - ジョブとジョブの依存関係を管理出来る - データ・ソースの待機が出来る

「レビューのコストを削減するための施策」

  • Time 19:55-20:10
  • Speaker @tarappo 氏

概要

レビューのコストが課題としてあったそうです
非エンジニアのQAが作ったテスト観点のドキュメントのレビューコストを減らすという内容でした

レビューサポートツールとしてDangerを使い 文書チェックツールでtextlintを使っているそうです

※ Danger
※ textlint

「After Test Automation, 自動テスト後」

  • Time 20:10-20:25
  • Speaker @vbanthia 氏
  • Slide

概要

モバイルのE2Eテストがflaky(テストが失敗する場合が色々ありすぎる)、実行環境による失敗等でメンテされずゴミ箱行きが多い
そのため、すべてを記録しましょう

※ flaky

記録する対象は f:id:sktktk1230:20171213103856p:plain

rspec_html_reporterでレポートを出力しているそうです

rspec_html_reporter

LT

「Magic Podの活用を具体的に考えてみた」

  • Time 20:30-20:35
  • Speaker 戸田広 氏
  • Slide

「Prometheusを導入した話」

  • Time 20:35-20:40
  • Speaker 株式会社Nagisa 榎戸 氏

「セキュリティ強化のための自動化」

  • Time 20:40-20:45
  • Speaker @manabusakai (freee 株式会社) 氏
  • Slide

「1人インフラ運用チームで、自動化の作業時間を確保するためにやっていること」

  • Time 20:45-20:50
  • Speaker 北野勝久( @katsuhisa__ )氏
  • Slide

TBD」Automation基盤の提供の仕方

  • Time 20:50-20:55
  • Speaker @tnir 氏

所感

第2回もあるそうなので、是非またいきたいです

Twitterハッシュタグ

#automation_night

Togetter

togetter.com

Railsのソースコード読んでみる | ActiveSupport blank?編

f:id:sktktk1230:20171212153754p:plain

普段仕事で使っているRuby on Railsですが、ソースコードを読む機会もなかなかないので、試しにやってみることにしました

読めるようにするまで

1. Githubのrails/railsリポジトリから任意のフォルダにクローンする

  1. ブラウザで https://github.com/rails/rails を開く
  2. Clone or Downloadをクリック f:id:sktktk1230:20171212153907p:plain

  3. クリップボードアイコンをクリック f:id:sktktk1230:20171212153931p:plain

  4. 任意のディレクトリ配下で $ git clone https://github.com/rails/rails.git rails

2. 任意のエディタで閲覧

僕の場合はRubyMineを使ってます
※以下はRubyMineの場合の設定方法です

  1. Rubymineを開き、openを選択 f:id:sktktk1230:20171212154018p:plain

  2. 先程cloneした任意のフォルダを選択する

  3. 下記のように取り込めている f:id:sktktk1230:20171212154031p:plain

読んだ箇所

Rails書いているとよく使う blank? を今日は読んでみようと思います

どんな使い方だっけ?

読んで見る前に使い方を調べてみます Railsの日本語ドキュメントを見てみると

ruby 変数.blank?
nil? + empty? のようなメソッド。nilまたは空のオブジェクトをチェックできる。
nil, "", " "(半角スペースのみ), , {}(空のハッシュ) のときにfalseを返します。
Railsで拡張されたメソッドで、Rubyのみでは使えないのでご注意ください。
引用:Railsドキュメント

ざっくり値がないものを確認したいときとかに便利ですね。ruby標準でも欲しいなと思ったりします

ソースコードを読んでみる

1. railsプロジェクトのactivesupportにある機能なので、activesupportディレクトリのlib配下で def blank? を探してみます

f:id:sktktk1230:20171212154210p:plain

2. 該当箇所が10個ほどあったので、それぞれみてみます

1. activesupport > lib > active_support > core_ext > date > blank.rb
# frozen_string_literal: true

require "date"

class Date #:nodoc:
  # No Date is blank:
  #
  #   Date.today.blank? # => false
  #
  # @return [false]
  def blank?
    false
  end
end

Dateクラスに対してblank?をすると必ずfalseが返り値のようです
オープンクラスで実装しているようです

オープンクラスとは?

既存するクラスを好きな場所で再オープンし、メソッド修正・追加など任意の変更を加えられる機能のこと。
引用: [Ruby] メタプログラミングの入り口、オープンクラスを理解する

2. activesupport > lib > active_support > time_with_zone.rb
中略

# An instance of ActiveSupport::TimeWithZone is never blank
def blank?
  false
end

中略

ActiveSupport::TimeWithZoneの場合も同じように必ずfalseが返り値のようです

3. activesupport > lib > active_support > core_ext > date_time > blank.rb
# frozen_string_literal: true

require "date"

class DateTime #:nodoc:
  # No DateTime is ever blank:
  #
  #   DateTime.now.blank? # => false
  #
  # @return [false]
  def blank?
    false
  end
end

DateTimeクラスに対してblank?をすると必ずfalseが返り値のようです

4. activesupport > lib > active_support > core_ext > object > blank.rb
Object.blank?
# An object is blank if it's false, empty, or a whitespace string.
# For example, +false+, '', '   ', +nil+, [], and {} are all blank.
#
# This simplifies
#
#   !address || address.empty?
#
# to
#
#   address.blank?
#
# @return [true, false]
def blank?
  respond_to?(:empty?) ? !!empty? : !self
end

respond_to?の使い方を調べてみると

respond_to?メソッドは、レシーバのオブジェクトに対してメソッドを呼び出せるかどうかを調べます。引数nameにはメソッド名をシンボルか文字列で指定します。メソッドnameを持っていればtrue、なければfalseが返ります。
レシーバのクラスのメソッドだけでなく、親クラスやインクルードしているモジュールのメソッドも対象になります。デフォルトではpublicなメソッドとprotectedなメソッドを調べますが、第2引数にtrueを指定するとprivateなメソッドも含めて調べます。
引用:Rubyリファレンス:respond_to? (Object)

empty?が実装されているかチェックしているようです
そしてtrueの場合は!!empty? で falseの場合は !selfが返ります

なぜempty?の前に!!が付いているのかわからなかったので、更に調べてみます

該当箇所のコミットログを見てみると f:id:sktktk1230:20171212160213p:plain

126dc47で変更しているようです
Githubで見てみると

github.com

コントリビューターから質問されているところを見つけました f:id:sktktk1230:20171212160539p:plain

rubyという言語仕様上empty?が書き換えられて必ず TrueClass / FalseClass のシングルトンが返り値となるわけではない為、こういう書き方をしているようです

!self はObjectクラスのインスタンスに対して行っているので、基本的にfalseが返り値となります
※ trueになるケースが思いつかなかったので、誰か知っている方いらっしゃいましたら教えてください

NilClass
class NilClass
  # +nil+ is blank:
  #
  #   nil.blank? # => true
  #
  # @return [true]
  def blank?
    true
  end
end

Dateクラスのときと同じようにオープンクラスしてblank?メソッドを追加しているようです
下記クラスも同様ですね

FalseClass
class FalseClass
  # +false+ is blank:
  #
  #   false.blank? # => true
  #
  # @return [true]
  def blank?
    true
  end
end
TrueClass
class TrueClass
  # +true+ is not blank:
  #
  #   true.blank? # => false
  #
  # @return [false]
  def blank?
    false
  end
end
String
BLANK_RE = /\A[[:space:]]*\z/

# A string is blank if it's empty or contains whitespaces only:
#
#   ''.blank?       # => true
#   '   '.blank?    # => true
#   "\t\n\r".blank? # => true
#   ' blah '.blank? # => false
#
# Unicode whitespace is supported:
#
#   "\u00a0".blank? # => true
#
# @return [true, false]
def blank?
  # The regexp that matches blank strings is expensive. For the case of empty
  # strings we can speed up this method (~3.5x) with an empty? call. The
  # penalty for the rest of strings is marginal.
  empty? || BLANK_RE.match?(self)
end

レシーバがempty?またはBLANK_REにマッチする場合はtrueのようです
BLANK_REをみてみると BLANK_RE = /\A[[:space:]]*\z/
[:space:]はPOSIX文字クラスというものです。スペースとタブと改ページにマッチします

※以前の記事でPOSIX文字クラスについて調べています

上記2パターンのどちらかにマッチした場合にtrueが返り値になるようです

Numeric
class Numeric #:nodoc:
  # No number is blank:
  #
  #   1.blank? # => false
  #   0.blank? # => false
  #
  # @return [false]
  def blank?
    false
  end
end

Numericの場合も必ずfalseが返り値のようです
0だともしかしたらtrueが返り値かもとか思ってしまいそうなので、確認するのは大事ですね

Time
class Time #:nodoc:
  # No Time is blank:
  #
  #   Time.now.blank? # => false
  #
  # @return [false]
  def blank?
    false
  end
end

読んでみて

ソースコードを読むのは結構億劫だったりしますが、よく使う処理などは意外な発見があったりして楽しめそうです

イベントレポート | SEOサーチニーズマーケティングとSNS潜在ニーズマーケティングでwebを制する 〜Webには探されている情報と探されていない情報がある〜

f:id:sktktk1230:20171207110228p:plain

最近はWebマーケティングにも興味が出てきていてサービスをもっとユーザーに使ってもらえるにはどうすればいいのだろうか?
ということを知りたくて参加しました!

概要

2017年12月6日(水)開催の SEOサーチニーズマーケティングとSNS潜在ニーズマーケティングでwebを制する 〜Webには探されている情報と探されていない情報がある〜のイベントレポートです

公演内容

  1. はじめに
  2. webには探される情報と探されない情報がある
  3. 探される情報のwebマーケティングとは?
  4. 探されていない情報のwebマーケティングとは?

はじめに 

  • Time 15:00-15:05
  • Speaker ティネクト株式会社 楢原一雅氏

テーマは

1.webには探される情報と探されない情報がある

  • Time 15:05
  • Speaker ティネクト株式会社 楢原一雅氏

Webでの情報の分類

大きく2つに分けることができる

  1. 探されていない情報
    • まだサービス認知がなかったり、検索する利用習慣がないもの
      例:忖度 以前は全く検索されてないが国会での発言以降検索数が上がる
  2. 探されている情報
    • Googleで検索される情報と同義
      Googleでは年間2兆回検索されている

探されている情報 = 検索ニーズであり、検索ニーズはマーケティングに活かすことが出来る

探されていない情報がユーザに届くまでの経路

  1. ユーザがスマホを開く
  2. FacebookSNSをなんとなく見ていて他者が「いいね!」しているもので気になったものを見る

2.探される情報のwebマーケティングとは?

  • Time 15:12-15:40
  • Speaker 株式会社 電通 倉増京平氏

サーチニーズマーケティングとは?

ウェブサイトへアクセスされるワードとサーチエンジンで検索されるワードを最適化すること

特徴

サイトへのアクセスとは切り離し、市場でのニーズ把握・分析の手段として利用することも出来る

サーチニーズマーケティングの基本的な考え方

  • 横軸:ウェブサイトへのアクセスキーワード
  • 縦軸:サーチエンジンでの検索ワード
サーチワード少ない サーチワード多い
アクセスワード多い C A
アクセスワード少ない D B
  1. Aのエリア
    • 検索数→アクセス数ともに多く、サーチニーズマーケティングが上手くいっていると考えられる
  2. Bのエリア
    • 検索数は多いがアクセスが少ない。いわゆる「取りこぼしている」マーケットと言える
  3. Cのエリア
    • キーワードごとのコンバージョンを見て、高い場合はロングテールでの集客獲得に成功している。低い場合は無駄なアクセスを呼び込んている可能性がある
  4. Dのエリア
    • 優先順位は低いが、ロングテールの優良キーワードが漏れていたり、市場の先行指標となりうるキーワードが隠れていることもある。要注意エリア

サーチニーズマーケティングを実施する場合にまず取り組むこと

BのエリアのものをAに引き上げる
ニーズは多いがアクセスが少ない(B)をニーズもアクセスも多い(A)へSEOSEMで有効キーワードを押し上げる

調査手法

アドワーズのキーワードツールで自社の関連検索キーワードを抽出し、検索数が多いワードほどユーザが求めている(= ニーズがある)と言える

調査例
1. アクセスワード
  - 100ワード
  - サイトカタリストのデータを用いる
2. ニーズワード
  - 300ワード
  - Googleの月間平均検索回数
  - 無関係ワードの削除など調整・精査を行います

アクセスワードとニーズワードを同数でとる場合などもありますが、今回は
1. 集客力アップのためニーズキーワードをより広範に調べるため
2. アクセスキーワードの中にはニーズが弱いロングテールワードが多い

という点から、アクセスワードの3倍のニーズワードを調査しました

3.探されていない情報のwebマーケティングとは?

  • Time 15:41- 16:45
  • Speaker ティネクト株式会社 楢原一雅氏

情報を得る方法がスマホの登場によって変化した

  • 以前のニュースの見方
    • 読売新聞を見る→各記事を見る
  • 最近のニュースの見方
    • SNSスマホでの通知などで様々な媒体からニュースが直接送られてくる

そこで、SNSマーケティングの必要性が出てきた

SNSでバズるには?

バズるための要素とは?

  1. メディア力
  2. 配信力
    • 発行部数
    • アプリDL数
    • SNSフォロワーなど
  3. SEO
    • 検索される情報をもっている
  4. コンテンツ力(記事力) 

SNSはファンを作る

  • PVを伸ばすは意識しない
  • ファンとはあなたの隣に座っている人です(身近な人向けに響く記事を書こう)

自分の身近な人にバズらないとダメ なぜなら友人→友人の友人→同じ価値観の人 という連鎖でSNSでは伝搬していくから

コンテンツ力(記事力)とは?

  • 共感する
  • 役立つ
  • 笑える(泣ける)

上記3つを満たす記事であること それぞれの感情によってシェアされるSNSが変わる

という傾向がある

つまり
よく読まれる記事とはみんなが興味のあるテーマについて書かれていること = 内容がおもしろいこと!!

ではWeb上での面白いとは?

ブログが面白さを表現している最たる例 - 個人の思い込みや主張思想が、むき出しになっていることが面白さではないか?

みんなが興味あるテーマと主張したいことが一致していることがバズる記事!

探されていない情報のwebマーケティングとは

メディア力と記事力を磨くこと

監視って何?という初心者にオススメ | ソフトウェアエンジニアのための ITインフラ監視[実践]入門 | 書評

f:id:sktktk1230:20171207134848p:plain

f:id:sktktk1230:20171201155424j:plain:h300

オススメ理由と概要

監視って何?どんなことするの?という知識ゼロの状態から

  • 監視する対象がどういうものがあるのか
  • どうやってアラートの対象にするのか
  • 実際に運用する場合はどうすればいいのか

といった内容が網羅的に書かれており、監視の入門書として最適だったなと思いました

私と同じようにITインフラ監視に関して知識があまりない。これから学んでいきたいというエンジニアの方にはオススメだと思います

章立て

  • 第1章 監視の目的
  • 第2章 設計の流れ
  • 第3章 現状分析
  • 第4章 判断基準の設計
  • 第5章 監視サーバの選択と経路の設計
  • 第6章 監視業務運営の設計
  • 第7章 構築
  • 第8章 運用に入ったあとの問題への対処
  • 第9章 自動化を見据えて

ポイントを抜粋

1. どんなレイヤーがあるの?

まず、監視を行う項目を棚卸ししやすいよう、5つのレイヤーに分けて分類します。
続いて、監視項目を洗い出す際に必要となる作業項目、および監視の目的についてレイヤーごとに確認します。
引用:第2章 設計の流れより

レイヤーは5つに分けていて、以下の分類だそうです

  • 外形
  • アプリケーション
  • デーモン(ミドルウェア
  • リソース
  • サーバ

2. 監視閾値の決め方

すべての監視項目の決定時に求められるのが、 測定方法と監視閾値です。 これらはどのような基準で決めていけばよいのでしょうか? また、閾値に達した、すなわち障害発生と認識する際に必要となる情報とは何でしょうか?
引用: 第4章 判断基準の設計より

監視する対象が決まっても、何を監視して通知するための基準はどうすればいいのかも気になるところだと思います
設定の仕方によっては誤報が多くなってしまったりするので、

3回の測定で連続して監視閾値に達した際に通知すること
引用: 第4章 判断基準の設計より

のように設定するとのことです

3. アプリケーションの基準

監視項目名 内容 対象 注意値 警告値
監視専用APIの参照 サービスの動作確認 Webアプリケーション 3秒 7秒
監視専用ページの参照 サービスの動作確認 Webアプリケーション 3秒 7秒
アプリケーションログの監視 サービスの異常検知 Webアプリケーションログ - ある

引用:4.4 アプリケーションの基準

4. ミドルウェアの基準

監視項目名 内容 対象 注意値 警告値
プロセス数 プロセスの死活確認 ミドルウェアのプロセス - 0
応答 応答時間の確認 ミドルウェアのポート 通常時の2倍 通常時の3倍

引用:4.5 ミドルウェアの基準

感想

上記の他にも重要度をどうやって決めていけばいいのか。実際の監視業務の運用はどうすればいいのかなどが書かれていて、監視について何も知らない人が全体像をつかむのには最適な本ではないかと思います
オンプレミスの場合は?Saasの場合は?なども書かれていていろんなサービスで監視する場合が考慮されていたので、色々な人が自分の業務を当てはめながら読み進められると思います

OSS開発参加の為に一歩踏み出してみた | OSSGate イベントレポート

f:id:sktktk1230:20171207110228p:plain

経緯

以前からOSS開発に参加したいな〜とは思っていたけれど、バグ踏むことあんまりないな〜とかちゃんとした英文書いたりとかしなきゃいけないよな〜とか参加することに非常に高いハードルを感じていました
そんな時にDoorkeeperOSS Gateを見つけました

OSSGateとは?

oss-gate.github.io これからOSS開発に参加したいなと思っている人が始める心理的ハードルを低くする為のコミュニティのようだったので、 まさしく自分が求めているものだ!と思い今回参加してみました。

コミュニティについて 「OSS Gate」とはOSS開発に参加していない人が参加する人に変わる「入り口」を提供する取り組みです。
OSS開発に未参加の人向けに参加方法を伝える場を継続的に提供することにより、OSS開発に参加する人を増やすことができるのではないか。
それを実現することが「OSS Gate」という取り組みの目的です。
参照:OSS Gate

OSSGateでは - ワークショップ - ミートアップ

があって、ワークショップは初心者向け、ミートアップは一度参加した人が継続的にOSS活動していくためのもののようです

ワークショップの概要

ワークショップではOSSの開発に参加する人を - ビギナー - サポーター - レポーター

と分類するそうです

「ビギナー」とは次のような人です OSSの開発に参加したいけどまだ参加したことがない人 OSSの開発に参加したことはあるけどまだ自信がない人 参加したい!という人は「ビギナー」として申し込んでください  

「サポーター」とは次のような人です OSSの開発に参加している人(OSSの開発に参加していれば「OSS Gateワークショップ」未経験でも大丈夫です。) 「ビギナー」をサポートしたい!という人は「サポーター」として申し込んでください (サポーターは、従来のOSS Gateワークショップで「メンター」と呼んでいた人たちです)

「レポーター」とは次のような人です。 http://oss-gate.github.io/ にイベントレポートを書く人 サポーターではない形でのOSS Gateへの参加方法を考えていた人 イベントレポート例:OSS Gateワークショップ2016-06-11開催レポート このレポートはワークショップの内容を時系列で並べたものになっていますが、内容も分量も違うまとめ方も試行錯誤の段階です。内容や分量などを相談しながらまとめていきましょう。 当日は、ワークショップの内容は実施せず、ビギナー・サポーターを観察したりインタビューしたりしながら随時レポートをまとめたり、レポートに入れる材料を収集します。

ということで今回はビギナー(初参加)として申し込みしました

OSSGateワークショップ当日

今回参加したのはOSS Gate東京ワークショップ2017-11-25です

当日は10時30からワークショップがスタートしOSSGateの説明や準備、OSS開発手順など説明を受けました そして今回取り組んでみたいOSSを選択してという感じです その後はworkshop内にissueを立てて、どんなことをやったのか作業ログを記述していくという感じでした
自分のissue例: github.com

作業ログはOSSを使用するユーザとして、ドキュメントに沿ってインストールすることで、わかりにくいところ、はまったところなどを主に書いていく感じです   そのつまづきはドキュメントにどう書いてあったら解消されただろうかを今回はプルリクとして作成しました わからないところなどは隣にサポータの方がいたので相談したりして進めていくことで特に躓くところもなく順調に進めました

感想

OSS開発に参加するということははかっこよくバグフィックス出したりするものだと思い込んでたけど、 ユーザー目線で見た時にこういうドキュメントの方がいいんじゃないってフィードバックするということも参加方法のひとつとして学べたことが非常に大きかったです
実際にプルリク出すところまでやってみることで、やってみようとするハードルはかなり下がったし、これからやっていこうというモチベーションにもなったので、参加できてよかったです

イベントレポート | Rails Developers Meetup #7

f:id:sktktk1230:20171207110228p:plain

2017年11月16日(木) Rails Developers Meetup #7のイベントレポートです。当日はリモートから参加させて頂きました!

イベント概要

第一線で活躍する開発者・導入企業から、RubyRailsに関する 発想・アプローチ・成功体験・失敗体験を学ぶ、非営利勉強会です。

RailsでECサービスをゼロから作ってみて

  • Time 19:35〜20:05
  • Speaker 株式会社spice life 赤松 祐希 氏
  • Slide

概要

オリジナルTシャツ販売サービス「STEERS」の内部の設計や開発で得た知見・経験について話します。
この発表を通じて普段のRailsの開発のちょっとした指針になるような話をできたらと思っています。
また、プロダクトマネージメントを行いながらの開発だったので、プロダクトマネージメントと開発の関係性などについても言及できたらと思っています。

発表ではチーム開発においてプロダクトマネージャーとエンジニアの意思疎通の大事さとそこをspice lifeさんはどうやって取り組んだのか。 Rails開発において原則を守っていくことの大事さと開発時にどういったことを考え開発していたのかを学ぶことができました

spice lifeさんでは以下のようなチーム構成と特色をもっているようです

チーム構成

  • プロダクトマネージャー兼アプリケーションエンジニア
  • インフラ兼アプリケーションエンジニア
  • デザイナ
チームの特色
  • プロダクトマネージャーと開発者が同一人物

メリットとして、意思疎通のコストがかからない
また負債を積むとしてもどれくらい苦労しそうかビジネス的に今後どうしたいのか自分がわかっているので判断が楽とのことでした

多くのプロジェクトではプロダクトマネージャとエンジニアが別れているケースが多いと思いますが、プロダクトマネージャーと開発者が別の場合は認識違いが発生するというのは非常に共感しました f:id:sktktk1230:20171128143838p:plain

ただ仕様変更も発生するし、すべてがスムーズにいくわけではないとのことです f:id:sktktk1230:20171128144019p:plain

Railsの話では開発時に考えておきたい必要なことを発表されていました - データベース設計をどうするべきか - マイグレーションをどうするべきか - サービスレイヤをどうするべきか - フォームクラスを利用する場合の、バリデーションをどこに書くのかetc

QA

  1. Rails原則はどうやって学びましたか?

スタートアップでのRails開発/運用でやってよかったこと

  • Time 20:05〜20:20
  • Speaker 株式会社トレタ 沢田 洋平 氏
  • Slide

概要

トレタ社では飲食店向けの予約/顧客管理サービスをつくっています。
サービス起ち上げ前から今までの4年を振り返って、スタートアップのエンジニアの視点から、ログや定期処理の扱いなどの開発/運用面でやってよかったことをいくつか紹介したいと思います。

開発に集中していく為にいかに運用を整備して、回していくかというのが勉強になりました。そのためにどういう部分を整備するのが あまり手間をかけずに運用が楽になっていくのかを発表されていました

スタートアップの特徴

プロダクト開発に集中するため、運用がまわらなくなってしまう。そのため、合間に地道に運用面を整備する必要がある

あまり手間をかけずに運用を楽にする方法

  1. リクエストのログが構造化されておらず検索性が低い為、アプリケーション固有のリクエストログの作成
  2. リクエストのログを集めて貯める為に、BigQueryを使用
  3. ジョブキューのログもリクエストログを同じくらい大事なためしっかりと収集
    • リクエストに比べて処理時間がユーザ体験に直結しないので見過ごしがち

グローバルサービスを作る時に考えておくこと

  • Time 20:20〜20:35
  • Speaker 株式会社トレタ 中村 真人 氏
  • Slide

概要

トレタは日本以外でも、シンガポールや台湾など15ヶ国以上の飲食店で使われています。
グローバルで使われるサービスでは時刻や電話番号ような、国による違いを考慮しておかないといけません。Railsでグローバルサービスを作る時に考えておくべきポイントを共有します。

タイムゾーンを考慮したRailsアプリケーション開発と海外対応の事例について発表されておりました。
タイムゾーンを考慮したときのハマりどころなど非常に勉強になりました

DBにタイムゾーン文字列を保存する際の注意点や f:id:sktktk1230:20171128144304p:plain

Railsアプリで日時を扱う場合のおすすめ f:id:sktktk1230:20171128144500p:plain

ケース別使用例 f:id:sktktk1230:20171128144818p:plain

トレタさんでの祝日対応もサービスならではの特徴があり非常に学びがありました f:id:sktktk1230:20171128144947p:plain f:id:sktktk1230:20171128145129p:plain

SMSの利用用途では以下のものがあるため、なるべく国番号(例:+81(日本))を入れるようにしていたのも グローバルサービスならではと感じました f:id:sktktk1230:20171128145449p:plain

クックパッドでの Webアプリケーション開発 2017

概要

クックパッドではこれまで Microservices 化を推し進め、1つの巨大な Rails アプリを大勢で開発するのではなく、いくつもの小さいアプリを小さいチームで開発しようとしてきました。
その結果として2017年現在ではどのような開発が標準となっているのか、そしてそれを支える技術としてどのようなものを開発してきたかについて共有できればと思います。

クックパッドさんでのwebアプリケーション開発における自動化Hakoでの学びです

デプロイフロー

f:id:sktktk1230:20171128145726p:plain

Hakoが作れれた経緯

f:id:sktktk1230:20171128145835p:plain

Hakoが出来たことによって新規webアプリケーションの開発フローが以下のように f:id:sktktk1230:20171128150024p:plain f:id:sktktk1230:20171128150038p:plain

しかし課題感はまだのこっていたため統合コンソールの開発(hako-console)したそうです。 それによって開発フローが変化したとのことでした f:id:sktktk1230:20171128150147p:plain

また今後やっていきたいこととして以下に取り組んでいるそうです

  1. サービスメッシュ
  2. RPC

コンテナは友だち! in Rails Developers Meetup

概要

いわゆるコンテナ仮想化と呼ばれるものは、正体はホストOSからリソース、権限等を隔離・制限したプロセスです。皆さんは隔離されていますか?
今回は、今流行中のDockerを例に、コンテナ仮想化がどのように実現されているかをデモしつつ覗いてみます。
時間があれば、拙作コンテナランタイム「Haconiwa」に同梱されたコンテナ作成専用のRuby(mruby)でコンテナ自作に挑戦してみます。
GMOペパボの新卒研修 コンテナは友だち!のRailsdm版です。

途中で離席してしまったため、メモを残せず。。

まとめ

定期開催は今回が最後とのことで残念ではありますが、また参加させて頂きたいと思います。初のリモートの参加でしたが、不自由なく非常に便利だったため、また開催するときには利用してみたいです

togetter.com

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

f:id:sktktk1230:20171207123225p:plain

概要

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を使って一年間サービスを運用してみた事例紹介)

f:id:sktktk1230:20171207123225p:plain

概要

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

イベントレポートはこちら

shitake4.hatenablog.com

分からなかったこと

  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

f:id:sktktk1230:20171128142957p:plain

調べてみた結果

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

f:id:sktktk1230:20171128142957p:plain

調べてみた結果

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

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

3. PagerDuty

f:id:sktktk1230:20171128143236p:plain

調べてみた結果

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 移行の舞台裏)

f:id:sktktk1230:20171207123225p:plain

概要

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

イベントレポートはこちら

shitake4.hatenablog.com

分からなかったこと

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

対象セッション

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

1. 時系列データベース

f:id:sktktk1230:20171128141545p:plain

調べてみた結果

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

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

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

2. Redis Cluster

f:id:sktktk1230:20171128141750p:plain

調べてみた結果

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

3. シャード

f:id:sktktk1230:20171128142106p:plain

調べてみた結果

シャード (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

f:id:sktktk1230:20171128142247p:plain

調べてみた結果

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のリゾル

f:id:sktktk1230:20171128142443p:plain

調べてみた結果

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

f:id:sktktk1230:20171128142443p:plain

調べてみた結果

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

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

8. iptablesのチェイン

f:id:sktktk1230:20171128142651p:plain

調べてみた結果

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

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

f:id:sktktk1230:20171207123225p:plain

概要

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

イベントレポートはこちら

shitake4.hatenablog.com

分からなかったこと

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

対象セッション

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

1. Twilio

f:id:sktktk1230:20171128140202p:plain

調べてみた結果

Twilio

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

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

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

f:id:sktktk1230:20171128140619p:plain

調べてみた結果

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

3. ディザスタリカバリ

f:id:sktktk1230:20171128140944p:plain

調べてみた結果

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

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

f:id:sktktk1230:20171207110228p:plain

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. シャードが偏るとどんなことが起きるのか
    • CPU使用率がボトルネックになっている
    • maxmemoryにあたって書き込めなくなる
  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って何?

f:id:sktktk1230:20171207123225p:plain

概要

ソースコード中のコメントの # 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を使ってハマった

f:id:sktktk1230:20171207123225p:plain

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: '太郎'} }