Mackerelで予測する的な話を試したり発展させたりする

『年末年始のディスク容量アラートを回帰分析で回避しよう』という最高の記事が公開されたので試してみました。また、追加で自分が試してみたいことを試してみた話。

経緯

MackerelでAlertが出たらSlackの特定チャンネルにメンションするという運用にしているのですが、
DiskやMemoryのAlertはショボい理由*1で発生することも多く
サーバ数が増えるに従って頻度も増えるし手が回らなくなってきたのでどうにかしたい、
予測みたいなことで対処できないかと思っていました。

そこでid:stanakaさんの記事を試してみたり、
応用例について考えてみたという内容になります。

用意

自分のような人間にはだいたい準備が大変です。
仕事の環境(AWS/Amazon Linux)を意識してCentOS6で環境を作ったので、
Ubuntuならあるいはもっと楽に出来るかも知れませんん。
欲張って慣れないpyenv-virtualenv環境でやったのもハマリポイントでした。

とりあえず雑にVagrantfile作りました。
Vagrantだとグラフは見れないけど予測プログラム試すだけならコレで出来るはず。*2

実行

id:stanakaさんのプログラムをコピーして実行してみます

$ export MACKEREL_APIKEY="(your own mackerel key)"
$ python mackerel_estimate_filesystem_lifetime.py
INFO:__main__:fetching ip-xxx-xxx-xxx-xxx (1/xxx)
INFO:__main__:fetching ip-xxx-xxx-xxx-xxx (2/xxx)
...
...
ip-xxx-xxx-xxx-xxx:xvda1, size: 277.73 GB/422.62 GB, full in 12d21h21m35.429102s
ip-xxx-xxx-xxx-xxx:xvda1, size: 4.46 GB/8.32 GB, full in 17d22h39m20.554903s
...
...

こんな感じでDiskFullまでの時間が短いものから表示されます。
あくまで予測ですが候補が提示されるのは非常に助かります。
何日か連続でチェックすれば変動に幅があるものもケアできるでしょう。
毎日1回とか仕込もうかなとか画策中です。

metricsを収集する範囲は1週間で利用してます。

(APIの叩く頻度は数秒に1回程度にご配慮ください)

とのことなので、API実行後に time.sleep(2.0) とかして実行してます。

Memoryでも試してみました。
他のmetricもいい感じに確認できるようになるといいですね。

とりあえずこれで長期的な予測はしやすくなりました。
デプロイ前後の挙動変更とか元々使用量が高い場合とかいくつか難しい課題はあるのですが、
こういった手段の枠組みが提供されたことは喜ばしいことです。
更に
『もう少しすると、今までの傾向を分析して予測に基づいた監視が出来るようになりそうなので、ぜひご期待ください！』
(Mackerelが大切にしているエンジニアを”ワクワク”させることについて)
とあるので期待せざるをえません！

応用例

もう1つ出来たらいいなと思っていたことがあって、
それは閾値を超えたら緊急度を判定して通知してくれないか、というもの。
WARNING Alertをトリガーに分析した結果を通知する方向で考えてみました。

方法

流れとしては、

• Alert APIでAlertを定期的に取得する
• 未処理のDisk WARNING Alertを判定
• 短時間のmetrics値を元に前出の分析を実行
• 結果(DiskFullに到達するまでの時間)が一定の値よりも短い場合はSlackメンションする

分析には前出のプログラムを流用します。
プログラムは適当にcronで監視させます。

こんな感じでDisk使用量が増加すると、

Alert出現時に分析も行って結果を表示して、寿命が短い場合はメンションも実施します。

逆に寿命に猶予がある場合にはメンションしないようにします。
MAXまで1日以上かかるような場合は平日であればメンションせずとも対応可能なのではないでしょうか。

試したコードはサンプルとして貼っておきます。
https://gist.github.com/ki38sato/7f2b1a81423a55a0bbef
分析期間やAlert判定閾値は適当です。

チューニングはまだまだこれから*3、場合によって分析方法も、、ですが、
こういった仕組みを用意することで分析の得意な人に改善してもらえる土壌ができます。(他人任せ)

以上、Mackerelで予測したりする話でした。

補足

filesystemを分析するスクリプトをVagrant VMに対して試す場合は注意が必要です。 /dev/mapper/VolGroup-lv_root がMackerelサーバでは mapper_VolGroup-lv_root に変換されています。

*1:ちょっとしたエラーを放置してログが溢れるとかリークを放置するとか

*2:ただし初回起動に1時間くらいかかる気がする　Docker欲しい案件

*3:ddでファイル作って試しましたが傾きを調整できずなかなか、、、

Mackerel Meetup #5に参加した話

9/17に マークシティで開催されたMackerel Meetup #5 参加してきました。
進化の早いMackerelですが一周年記念だそうです。おめでとうございます！
当日の雑なメモと簡単な感想です。

1. はてな　stanakaさん　「Mackerelの最初の1年と今後」

• 1周年 一升餅作った
• 毎週リリース継続　(開発スピードはやい)
• 10,000+ agent
• おすすめ5選
  • オートスケールグラフ
  • アラーと通知グラフ
  • 外形監視
  • 監視ルールコード化
    • mkr monitors diff/pull/push CircleCI
  • docker plugin
    • docker-hub mackerel-agent
• 価格　移動平均で後払い決済=>セールスに連絡
• ビジョン
  • クラウド化
  • コード化　API化

開発が早いのは肌で感じてます。
はてなの皆さん、お会いする度に「何でも言ってください！」みたいにおっしゃられるのですが、 本当にリクエストしたものがすぐ入るので頭が下がります。
自社の導入状況は後の方で振り返ってみたいと思います。
後払い決済最高ですね。今月都合3回くらいポチった気がするので導入したい。
休み明けたらメールしようと思います！

2. GMOペパボ　山下さん　「僕が今日呼ばれた意味」

• private cloud : OpenStack利用　<- サービス全て移行予定
• 壊れたら作り直す
• Nagiosを使っていた　動的追加厳しい
  • Mackerel採用　サービスメトリックで自由に追加
• macklog plugin作った
• OpenStackの監視　ポート使用数監視　利用率監視
  • scriptにfog使用、重い => YAO 軽量 開発Udzuraさん
• hubotでMackerel＋OpenStackの情報をJOINして返す
• hubotでMackerelのURLを返す　一発で開ける　便利
• unreachableの切り分けは皆はどうしているのか？
• mkr最高！

Mackerel APIとOpenStakの連携が始まってて羨ましいです。
サーバ管理という意味での連携はうまく出来てないので見習いたい。
Mackerel用のURLをhubotで返すの便利そう。
unreachableは今はcloudwatchと合わせ技で判断してます。
Mackerelをメインに他もチェックして自動で判断、とかできると良さそう？
mkr最高、間違いない。

3. サイバーエージェント　松浦さん　「アメーバオウンドとMackerel」

• アメーバオウンドはAll AWS、Golang
• Sensu + influxdb + grafana
  • influxdb 0.8 クエリがフルスキャンで参照が重い
  • Mackerel採用
• ホスト名つけよう
• サービス/ロールの設計方法について
• sensu-plugin.io
  • pending queue監視とか

サラッと言われてたけどGolangも実践投入しているとはさすがサイバーさん。
松浦さんとは少し前に直接話す機会がありましたが、 influxdb 0.8使っててMackerelに乗り換える経緯が全く同じで共感したことが。 influxdbも0.9で改善されたとのことなので、grafanaも2.0出たし気にはなりますね。
ホスト名に関してはうちはむしろPrivateIP運用になっているので現状困ってないのですが、 display_name使いつつ、徐々にIP依存無くしたいとは思ったり。
sensu-plugin流用するのいいですね。
自分もMackerel-plugin書く時に出力参考にした気がしますが、 そのまま使うのも検証済みの場合は特に良さそう。

---

LTは飲んでたのでメモなし！
あと折角京都から来られていた人達に挨拶できなかったので課題です。

というわけで前回発表してから何が変わって何が変わってないのか少し振り返り。

追加されて導入済み

• スクリプトによるチェック監視が出来るようになった
  • バッチやバックエンドサーバのプロセス監視とか便利
• 通知先や通知条件が分けれるようになった
  • 更にチェック条件も調整できるようになった
  • stagingとproductionをSlackの別のchannelに出してproductionはメンション有りとか
• URL外形監視
  • たまに504みたいなので警報出てつらかったけど回数や時間も見れるようになった
  • response timeグラフ便利
• auto_retirement
  • BlueGreenDeploymentでグラフが無限増殖しない
• on_start/on_stop
  • マシン毎停止する場合には警報止めたりする必要がなくなった
• statusをRoleの一覧画面から変更できる
  • 某アーキテクト大喜び
• display_name付けれるようになった
• グラフ上で範囲選択できるようになった
  • kibanaっぽい感じで範囲ドラッグできる

未導入

• カスタムダッシュボード
  • slackへのグラフ通知が便利すぎて皆そこから飛んでるっぽい
• 監視設定API　mkr monitors
  • これからやる！絶対！

これ以外にもいくつか想定した挙動と異なる部分を質問して改良してもらったりしてます。
4ヶ月でえらい便利に。特にAPI化は大きいです。
同僚にmonitoringの設定100＋手で設定した話して苦笑されるしかなかったので、 パパッとコード管理化してドヤ顔するしかない。
またpluginも書きたい。

AWSなんかもそうですが毎週何かしらリリースされるの進化が目に見えてありがたいですね。
年末までに何がリリースされるか楽しみです。
はてなさん、サイバーエージェントさん、発表者の皆さん、ありがとうございました。

(ネタ)Slack＋Hubotでファイルアップロードする話

深遠な理由*1によりファイルアップロードをSlack経由で行いたい。
アップロード先はAWS S3なのですが、ここではAWSの世界にファイルを持ち込むまでを書きます。
普通、ファイルアップロードしたいとなれば入り口としてWebサーバ的なものが必要ですが、
ちょっとした要件にはセキュリティコストが高くついて面倒。
SlackやGithubといった既に利用している外部サービスに乗っかればその辺のコストを省略できる、
というのが後付の狙い。

どうしたかというと、Slackのファイルアップロード機能でアップロードします。
その際にコメントに特定のキーワードを付与すると、
Hubotが裏でファイルダウンロードしてS3にアップロードします。
HubotはAWSの中にいる前提です。簡単・強引な仕様。

hubot-slackにはそういう機能はないので、生のAdapterで書きます。
要点抜粋のソースは以下。

request = require 'request'
fs = require 'fs'

module.exports = (robot) ->
  robot.adapter.client?.on? 'raw_message', (msg) ->
    if msg.type is 'message' and msg.subtype is 'file_share' and msg.text.match(/uploaded a file: \<\S+\> and commented: !fileupload/)

      filename = msg.file.url_download.split('/').pop()
      filepath = "work/#{filename}"
      file = fs.createWriteStream(filepath)
      channel = robot.adapter.client.getChannelByID msg.channel
      request
        .get(msg.file.url_download)
        .on 'error', (err) ->
          console.log "#{err}"
        .pipe(file)
        .on 'close', (resp) ->
          # post process
          robot.send {room: channel.name},  "<@#{msg.user}>: Complete file download: #{filename}"

アップロードの際のコメントは、
「uploaded a file: <filename> and commented: (comment)」
という形になるので注意が必要。
上記の例ではコメントに「!fileupload」と付ければ実行されます。
工夫すれば複数のアップロード先も制御できそう。

mgs.file.url_download でSlackにアップロードされたURLが取れるので、ダウンロードします。
この例ではrequest使ってます。後は似るなり焼くなり。
adapter.clientを使うのでchannelとかuserは自分で取得する必要があります。

欠点として、ファイルアップロードを別の場所(S3とか)にしたいのにSlackにも残ってしまう。
終わったら削除したかったのだがBotだと削除できないらしい。
ファイルサイズとかも危険なので上限をチェックするようにはしてます。
後はファイルが重複しないようにtmpdir作ったり終わったら消したり、
細かい所は割愛してますがケア必要です。

*1:「Slackからサクッとファイルアップロードできたりしないの？」と言われたとか

Kibana4 + dstat の話

あらまし

以前に、『dstatをkibanaで可視化＋3.0.0milestone5新機能』という エントリでKibana3+dstatを使った可視化について書いたのですが、この中で構築の肝としてfluent-plugin-mapがありました。 Kibana3だと同一グラフ内に同一レコードの複数のfieldを含めることが出来なかったので、 fluent-plugin-mapを使って同一@timestamp＋各fieldという別々のレコードとして分割登録しました。 このやり方は@kazeburoさんも記事にされたことにより 同様の方法を利用する人が意外といるようなのですが、 Kibana4では同一グラフ内に同一レコードの複数fieldを含めることが出来るのでレコード分割する必要がありません。 性能はわかりませんがdocument数や容量は分割する場合と比べると減ると思います。 ただしfluent-plugin-dstatはネストしたjsonを返すので平らにしてあげる必要があってfluent-plugin-flatten-hashを使います。

設定とか

fluentdの設定は以下。

<source>
  @type dstat
  tag dstat
  option  -ams
  delay 5
</source>

<match dstat>
  @type flatten_hash
  add_tag_prefix flattened.
  separator _
</match>

<match flattened.dstat>
  @type elasticsearch
  type_name       dstat
  host            localhost
  port            9200
  logstash_format true
  logstash_prefix dstat
  flush_interval  3s
</match

それからMapping template

$ vi template_dstat.json
{
  "template": "dstat-*",
  "mappings": {
    "dstat": {
      "properties": {
        "@timestamp" : {
          "type" : "date",
          "format" : "dateOptionalTime"
        },
        "dstat_dsk/total_read" : { "type" : "double" },
        "dstat_dsk/total_writ" : { "type" : "double" },
        "dstat_memory_usage_buff" : { "type" : "double" },
        "dstat_memory_usage_cach" : { "type" : "double" },
        "dstat_memory_usage_free" : { "type" : "double" },
        "dstat_memory_usage_used" : { "type" : "double" },
        "dstat_net/total_recv" : { "type" : "double" },
        "dstat_net/total_send" : { "type" : "double" },
        "dstat_paging_in" : { "type" : "double" },
        "dstat_paging_out" : { "type" : "double" },
        "dstat_swap_free" : { "type" : "double" },
        "dstat_swap_used" : { "type" : "double" },
        "dstat_system_csw" : { "type" : "double" },
        "dstat_system_int" : { "type" : "double" },
        "dstat_total_cpu_usage_hiq" : { "type" : "double" },
        "dstat_total_cpu_usage_idl" : { "type" : "double" },
        "dstat_total_cpu_usage_siq" : { "type" : "double" },
        "dstat_total_cpu_usage_sys" : { "type" : "double" },
        "dstat_total_cpu_usage_usr" : { "type" : "double" },
        "dstat_total_cpu_usage_wai" : { "type" : "double" },
        "hostname" : { "type" : "string", "index" : "not_analyzed" }
      }
    }
  }
}

$ curl -XPUT 'localhost:9200/_template/tmptelate_dstat' -d @template_dstat.json

templateは特定のパスに置いておくと自動的に読まれるのですが、 再起動が必要になるので最近はtemplate APIを呼ぶようにしてます。 変更結果を確認もできますし。
(既存のindex mappingが即時変更されるわけではありません)

mappingでなくfluent-plugin-typecastを使って先に型を定義してしまう方法もあります。
私はmappingでdoc_valuesやStringにnot_analyzedを設定することが多いのでElasticsearchでは共通的にmapping作成するようにしてます。 mappingを作るにはまず一旦設定なしでデータを入れてみてできたmappingを見て変更するとわりと簡単にできます。

curl localhost:9200/<index>?pretty

Kibana4の設定

Visualize Line chartの設定画面です。

add metricsでY軸を複数設定できます。

複数表示できましたね。

cpuやmemory, swapはArea chartの方がいいかもしれませんね。
設定方法は一緒です。

Vertical bar chartなんてのも。

レコード分割せずに複数のfieldを同一グラフに表示できました。

結論

dstat + fluentd + kibana4(Elasticsearh)ではレコード分割する必要がない。
(ただし構成上の話で性能はわかりません)

sample

github.com ansible-hands-onを再利用して構築検証用Vagrantfile作りました。

番外

grafana + influxdbの場合はレコード分割が必要(?自力では調べてない)なので その場合はwinebarrelさんの記事を参考にするといいと思います。

YAPC::Asia Tokyo 2015に参加した話

YAPC::Asia Tokyo 2015に参加した話

2015/08/20-22に東京ビックサイトで開催されたYAPC::Asia Tokyo 2015に参加してきました。

参加メモ:
YAPC参加メモ 8/20 前夜祭
YAPC参加メモ 8/21 1日目
YAPC参加メモ 8/22 2日目

今週はhatenaの人と話す機会があったり前日がrebuild meetupだったりと、 個人的にあったまってたしすごく期待感のある滑り出しでした。 前夜祭はこれで前夜祭かーという内容で、自分の参加した中ではベストトークはJxckさんなんだけど、 次くらいにtagmorisさんが来てもおかしくないと思ったりもする。 自分の場合、perl書かないしインフラ方面に現在の趣向が偏ってるので、 参加したトークは半分くらいインフラ関連だったりということはあったんだけど、 逆にそういったトークが多いのもクラウドの時代を反映してるのかもしれないし、 perlのもつ特性やコミュニティがそういう状況にマッチしてるのかもと思ったりもした。

2130人が関わるTech系カンファレンスってなかなか無いですよね。 名前をよく聞くような人達もたくさん歩いていて、YAPCって色んな意味で愛されているんだなと思う。

2日目のsongmuさんのトークは朝一にも関わらず30分前に自分がついた時には既に席の6割が埋まっていて 最終的に立ち見状態だった。休みの日の朝一から参加するのはdevops tokyo以来な気がする。

YAPCの歴史を紡いだ人達の昔話にみんな興味津々で大盛況。

無限コーヒーとか無限弁当とか、2k規模の開催も含めて運営の人達はすごいと思う。 トークで聴いた中にSpaceApps運営話があって本当に色々な知見が詰まっていたんだけど YAPCの規模は更にもっと色々あるんだろうなぁとか。
湯村さんも941さん makiさんブログ参考にしたって言ってましたね。

LTのレベルが高すぎて、自分が思っていたLTはなんだったんだっていう。 YAPCあるあるでもハードル上げすぎって話題になってましたね。 LT芸人という単語が頭をよぎったとか無かったとか、、、

10回目にして一区切り。次回の奇跡はおきるのか。
人はbuilderscon.ioに新たな夢を見るのか。
また機会があれば参加したいですね。皆様おつかれさまでした。

YAPC参加メモ 8/22 2日目

YAPC参加メモ 8/22 2日目

• YAPC参加メモ 8/20 前夜祭
• YAPC参加メモ 8/21 1日目

Mackerel開発におけるScalaとGo、そしてPerl　songmuさん

• 趣味CPANIZE
• Mackerelの開発
• 新機能　外形監視 外部からクローリング監視
• オンプレ構築　AWS障害とは無関係
• LVS nginx scala redis postgreSQL Graphite
• Angular typescript
• Scala Go JavaScript Perl Ruby
• Play Framework
• Scala 静的型システム使いたい
• 関数型楽しい
• Option便利　Nullのない世界
• コンパイルの遅さストレス<=>バグ混入率は低い
• 大き目のものをカッチリ作るのにむいてる　Scala
• Mackerel-agent Golang
• Golang 常駐プロセスに向いてる
• URL外形監視
  • job queue: redis
  • 外形監視ワーカーサブシステム　切り出すと単体の状況が見れる
• Graceful restart
  • github.com/braintree/manners
  • githubb.com/lestrrat/go-server-starter HTTP server(daemon)を簡単に作れる -> ?
• Mackerelのサイトは　はてなブログで運用している
• paranoidhttp 内部DNSへの解決を禁止する
• Golang
  • クロスコンパイル　ちゃんとやると意外と大変
  • 書き捨てしづらい
  • 実用言語としての割り切り perlも
  • 継承よりコンポジショん
• MackerelにおけるHaskell
  • プロファイラ　劇的に毅然
• リリースの自動化
  • Travisがgit pushする　止めれるようにしておく
  • 自動化機構は負債になりやすい？　肥大化　テスト困難
  • ツールをテストする　ツールの責務をわける　手元で実行できるように
  • Github Deploy keys-
• perl 全部Scalaだと大変　前段にやわらかいWebServerあったほうがいい
• ruby: fluentd-plugin-mckerel / mackerel-client
• はてな東京のエンジニア　1年で6倍！(6人)
• QA
  • 言語の適材適所すると属人化しない？　なりがちだが、レビューさせたり書いてもらう
  • Golang vendoring? 外部ライブラリは今の所慎重に使ってるので困ってない
  • buildスクリプトperlがGolangのレポジトリに入っているのは？
    • perl好きだし、軽いし違和感ない
  • deploy時間　最短20分だがテストもするので1時間とか

Mackerelはお世話になってるのでメモはけっこう飛び飛び、、、だったのだが 開発環境周りの話はそんなに聴いたことなかったのですごいためになった。 ServerはAWSじゃないんすね (それもそうか)

NASA主催の世界最大級ハッカソンSpaceAppsを運営した話　湯村さん

• SpaceApps (International SpaceApps Challenge)
  • NASA JAXA
• 衛星コレクション
• 事務局はSpaceAppsのために結成　ボランティア
• キャパ　ハッカソンなので多ければいいわけでもない
• スポンサー　参加費は不可のルール
• 無断キャンセル対策　以降お断り文言掲載
• 運営の情報共有　Timezoneが違うので1日3回MTG開催、どれかに参加
• コミュニケーション重要　MTG後に食事したりとか。
• ドキュメンテーション大事　やったことを全部書き出す 941ブログ　Makiさん
• イベントの運営側に参加してみよう
• QA
  • 事務局長の仕事とは やる人がいないもの全部

世界で2番目くらいの規模のイベントだけど今まで知らなかったので参考になった。 イベント弱者だけど機会があれば・・・

Docker3兄弟について　アルパカ大明神さん

• Docker Machine / Docker Compose / Docker Swarm
• Docker Toolbox
• causion!!! all beta vesrion
• Docker Machine: VagrantのDockerバージョンみたいなもの？
  • cloud上も同じIFで操作できる
• Docker Compose: YAML定義から管理
  • extends 他のYAMLをincludeできる
• Docker Swarm: filters strategies
• Usecase
  • 開発環境配布 docker-compose.ymlもレポジトリに配布しておく
  • volumeでローカルと同期して、、、
  • Multi cloud cluster ?
• zenbutsuさん
• 開発環境としては十分利用可能

Docker早く使えるようになりたい。開発環境として十分というのは心強い。

3分でサービスのOSを入れ替える技術　hsbtさん

• YAPC通らなかったペパボ社員->ペパボテックカンファレンス
• 3ヵ月後にCM時にサービスを落とさないようにして？
  • Web+DB
  • 謎サーバ　単純平行ではない　数台ごにょごにょ
  • scale automatic 高速
  • 特命チーム
• Scale out
  • old: golden image 秘伝のタレ
  • host情報を起動後に書き換える　手で。手順書　半日
  • できたらつなぎかえる　5-6台　tanpopo work
  • Scietific linux 6.x <- 火を噴く
  • new: puppet
  • 書きかけだった　<- 書き換えた
  • ローカルモデルからagentモデルへ
  • コード化できた
• Automation
  • sshを使わない　何でもできるものに制限を課すとイノベーションが起こる
  • cloud-init: YAML(userdata?)で起動時実行できる　run_cmdは使わずpuppetに寄せた
  • Applicationはhostname/ipに依存しない　処理はIaaSからAPI取得
  • hostname情報みたいなのを消してImage登録自動でする
• 稼動するとなかなかUpgradeできなくなるので、先にRails4にした。
• いきなりHerokuみたいなことをすると爆発するので目も前のものを着実に自動化
• 高速スケールアウト
  • 上記まででも1時間
  • capistrano3導入
  • Rails Bundle (内製)　pull型　S3
  • Consul+consul-alert: nagios弱者、、、
  • mackerel: 1Roleに50+host, retire API -> shutdown init
    • 「公式がサポートして技術者の努力が全部無駄になりましたｗ」
  • fluentd
  • thor: sub commandを作れる
  • 人間が予測しなくてもよいアーキテクチャを使いましょう
  • 手作業にしない
  • ここまでで20-30分
• 番外:Antipopさん　Youtuberになりたい
• 手順を分類　Slow Operation, Fast Operation
  • Minimal image (phase1)
  • 起動しただけでRailsが走るImage (phase2)
  • 重い処理の区切りごとにImageを作る->Packerで
  • Packer
    • Image creation の手前でServerspec実行
• Infra CI: Drone CI->puppet
  • refactoring puppet manifests
• BlueGreenDeploy
  • AWSはELB、OpenStackはnginx+consul-template,nginx-mruby
• 今後
  • image作成の自動化
  • docker
• QA:
  • ScaleするとDB等にかかる負荷はどうみてるのか？ 1->10ということはないのでまだ大丈夫
  • Scaleout trigger: TV parameterから

ここでもConsul。Consulの話3回も聴いたし何か当たり前になってきてそう。 ちょうどこの前お試しで組み込んだばかりなので聴けてすごい捗るし、 どうやってこの仕組みを考えたかの背景まで聴けて参考になった。

【特別企画】YAPCあるある（仮）

立ち見なのでメモなし。 面子見てアッと思って直前に飛び込んだけど期待を裏切らなかった。 サラッと色々名言が飛び出してた気がする。動画ないのかな？ yusukebeさんが緊張してた気がしてこの面子だとそりゃそうかっていう。 YAPC初参加組だけど楽しめました。

HTTP2 時代の Web　jxckさん

これも立ち見。入れ替え時に前の席行こうとして失敗するという。 日本だしまたチャンスあるかもしれないしBrad Fitzpatrick見るべきかもとも思ったが、 Jxckさんのトークは本当にうまいしわかりやすいしワクワクするので聴きに来てしまった。 そしてめっちゃ満足している。社内勉強会に来てくれないかなとか思ってしまう。

Lightning Talks Day 2

めちゃくちゃ面白かったし、思った以上にレベルも高かった。 というか色々突き抜けてた。 完全にエンターテイメントだったので酒ありで再演を要求したい。 (すいません、調子にのりました)

クロージング

おつかれさまでした！

感想

すごい充実していた気もするし、しかし自分の参加の仕方は普通の勉強会の延長でしかなくて、 もっとスピーカの人達と交流したりした方がいいんだろうなぁと思う。 それでも今回のお祭りの一端に関わる事ができて良かった。 勉強会で発表できるようになるのは目標だけどおっさんになり過ぎたので 若い人が発表するのを酒飲みながら野次飛ばして聴くくらいがいいのかも。 (というgdgdな感想も酒飲みながら書いてます)

ともかく今回YAPCに関わった皆様、歴代のYAPCに関わった皆様もありがとうございました。お疲れ様でした。

YAPC参加メモ 8/21 1日目

YAPC参加メモ 8/21 1日目

メリークリスマス　Larry Wall

• ホビット物語　指輪物語　スタートレック
• 2015/12/24 perl6 1.0出るかも？(バスに轢かれなければ)

いきなりホビット物語と指輪物語から入っていてオーディエンスが付いてきてなさげではあった。
バスには注意して欲しい。
よくわかってないけど正規表現の話？で$1が$0になるよって言ってて、
それって大丈夫なんだっけって少し思った。

世界展開する大規模ウェブサービスのデプロイを支える技術　aerealさん

• Miiは全てhtml game内からもブラウザを起動して表示している
• ゲーム内からも投稿できる
• JP/US/EU
• DB multi-master + region replication
• PCからは全世界USにつながる
• タイムライン、共感、通知はマルチサービスREST API
• Miiverse deploy
  • capstrano2 + Git
  • region超える+台数が多くて同時git pull耐えられない
  • slave+random accessで分散
  • git slaveを各regionに配置 lsyncdの監視上限に到達してしまった Capstrano
    • Mackerel利用し、同じRoleを設定
    • AutoScaleは事前にpoolしたマシンを利用している
    • deployは一時的に全台あげて実施して不要分は落としている
• 開発フロー
  • 初期　redmine -> 最近　GithubEに移行中　コードレビュー
  • Gitが2台になり同期ツール必要
    • hesokuri, ghm検討し新規開発することに
• 新git同期システム
  • JSON over HTTP API
  • git pull & git push
• 今後のデプロイ
  • 一般課題
    • deployに必要なものを全てcommit必要 repo肥大化
    • ビルドする場合、時間かかる
  • Miiverse課題
    • 台数 git負荷
    • region
  • consul + stretcher
  • jenkins build->s3->consul+stretcher
  • perf git: 1149 s consul+stretcher: 29 s
    • 40倍
• QA
  • git同期システムおよび周辺->perl5 デプロイ周期　2週間＋bugfix
  • pull型で一台だけ失敗した場合の検出?->失敗時の処理も書ける
  • pull req mergeは同期システムを導入した箇所では使えるようになった
  • codedeploy: 時期的に検討してない
  • consulのつらいところ: 各イベントの集約が難しそう。完了をそろえるのが？
  • どのくらいの規模からconsul? 30くらいからGit pullきつくなる

数年前からよくregion間運用の例としてウォッチしてたので聴けて良かった。
多チーム連携してるせいか課題や性能値がハッキリしててわかりやすい。

Consulと自作OSSを活用した100台規模のWebサービス運用 fujiwaraさん

• Lobi スマホ向けコミュニティ　プレイ実況とかも
  • 2010- AWS US 4台, 2011- 自社 4-20台, 2013- AWS max 100 AutoScale
• hostの種類多い
• perl, node.js, Go
• AWS移行時の悩み　DNSがない　Chefで/etc/hosts
• AutoScaleしたい
• 内部DNSの代わりとしてConsul検討
• failedだとDNS引ける　left(自分から離脱したとき)は無理
• rawってつけるとBodyだけ帰ってくる　Base64decodeいらない
• 全ての問い合わせをLeaderが処理する => stale modeにすると他も応答する
• Consule server 2CPU 20MBMEM 2GBDisk
• root command投げれないようにユーザプロセスにして、、、
• 1年以上運用しているがAgentが落ちたりしたことはない
• オペミスでLeader選出できない台数まで減らすと崩壊する・・・・
• モンストにLobi SDKが入った=>大量の動画が、、、
  • Spot Instance + 自前AutoScale
• クラスタ内でuniqueな名前が必要
• Stretcher
  • AutoScaleするにはpullでないと、、、
• Rolebackしやすい　eventで前のMANIFEST指定しなおすだけ
• Deploy完了を待つには->kv dashboard
  • 100台が失敗で100個ログ流れないようにkvsに入れて管理
  • trigger
• Consul lock を使うと部分実行できる => BlueGreen
  • あるいはRole分ける
• server内

完全に前のMiiverseの発表の課題解決みたいになっててお得感ある。 自分の場合は台数はそこまでじゃないけど、種類が多くてpushは指定がつらい感じ出てきて pull(remote trigger)が気になっていてconsulの説明が詳しくてありがたかった。
kv dashboardの意図も自分の懸念と合致していて色々タイムリー。Stretcherも検討したいなー。

Conway's Law of Distributed Work caseywestさん

• remote で作業を行う様々なツール等
• remoteしていてもためにOfficeに来るの重要
  • 他に人がいることを意識する　機会
  • 意図的にremoteの人もchatやvideo chatの議論に巻き込む
• 分散チームにもCAP定理
• 分散化されたシステムを作るには分散化されたチームが必要(?)
• なぜJIRAが嫌いか？
  • Administratorが全ての設定やWorkflowを変えれてしまう
  • 今まで自分が見ていたものが変わってしまう。
  • confluenceのhosted jiraだと、制限があるので安心
• remote workだと働きすぎたりしないか？
  • 自分のスケジュールを厳しく管理
  • 帰宅を促す
  • 責任分担
• Google docsのGoogle等は信用できるのか？
  • 信じている
  • hipchatは履歴を暗号化してない過去があった
  • S3に関しては状況に応じて適用を変えるルールを決めた
• code review とペアプロを同時にするか？自分はどちらかにすることが多い
  • 選択的にやる
  • ペアプロしてれば十分だが、第3の目が必要であればリクエストをかける
• Timezoneに差がある場合はどうするのか？
  • 難しい　いくつか方法があるう
  • いくつかの場所に人をまとめる　特定の機能をまとめて担当させる
  • 個人がばらばらの場合は非常に難しい
• meetup頻度？
  • min:4半期に1回　
  • remoteで難しいこと　2つ
    • 人間関係の構築
    • 長期的なプランニング
• languageが異なる場合の効果的なコミュニケーション
  • あまり体験がないが、英語ベースでやっていた
• smartphoneでのChat　特にVacations
  • もちろん便利
  • 休みの時には気をつける　置いておく

英語＋通訳だけど非常にわかりやすい内容だった。(翻訳も鬼)
すごい特殊なことをしてるわけではなく、でも色々と気を配ってるようなイメージ。
remoteやってみたいけど集中力がなー。悩ましい。

うっかりをなくす技術　karupaneruraさん

立ち見だったのでメモなし 自分の趣向的に運用期待だったのでプラグラマーかーという(当たり前)
「リーダブルコード読んどけ」はアグリー

感想

LT...は部屋に入れずに帰った。
前の時間の最後、部屋を出る人が多くて感じ悪かったがこういう事かと。
中に着てたYAPC TシャツにLT時になろうと思ってたのだが。。ちょっと残念だった。

いくつか見たいけど満室で無理なものもあって、明日はもっと激戦なのでYAPC半端ねーなー、すげーわーって感想(小並感)
以前にチケット買ったのに来なかった時もあってすごい損した気になってきた。
今回は個人スポンサーに何故かしたけどそれだけの価値はあると思った。