やっと、やっとです。 cookpadなど名だたる会社のように、自社tech meetupを開催することができました 🎉 全体では40名近い方にも参加いただき、内容的にも盛り上がり、個人的にはとても楽しかったです :sparks Whats Repro Tech Meetup Repro Tech Meetupは、スタートアップにおける技術領域での失敗を少しでも防ぐようノウハウを共有することを目的とするミートアップです。 Reproで過去選択した技術の失敗談や、それをどうやって盛り返してきたのか共有 Reproの今を支える技術や知見を共有 ゲストを呼びReproで利用する・している技術について学ぶ Repro は、5,000以上の世界中にあるアプリに利用されるマーケティングオートメーションツールを提供する会社です。 数千万DAUのアクセスや行動ログを基にした柔軟な分析ワークロードを実現し、毎日億を超えるpush配信などのマーケティング施策の実施を支援しています。 Prepare 受付にはReproグッツも！四角いのはメモ帳です 👀 お酒を飲みながら聞ける！ 人もいっぱい！ 今回のテーマはDocker あの docker によるアプリケーション開発環境構築ガイドを著者の櫻井さんにも登壇いただきました! 当日のTwitterの様子は以下を御覧ください togetter - Repro Tech Meetup #1 Docker まとめ RettyにおけるDocker活用のこれまでとこれから by 櫻井洋一郎 お酒飲んでるところを映してしまってすいません 😅 Rettyさんは2014年から機械学習基盤にdockerを使っているのすごい。 ReproとECSの今と昔 by kei_q ECSとの戦い。ECS進化してきたなーとしみじみ感じます。 個人サービスをFargateに移行したよ by hatappi 昔の自分に伝えたい容量回復のためのDockerの仕組み by ksk1030 ECS運用ノウハウ by naomichi => https://github.com/metaps/genova systemd-nspawnは便利らしい by threetreeslight 時間が余ったので私もLT打ち込んだっ！当日にっ！！！ 次回も がんばっていきますので、よければぜひご参加ください 🎉 ... Read more

2年ぶりに開催したshinjuku.aar が前回。 思ったより良い雰囲気だったこともあり、今月もshinjuku.aarを開催 🎉 shinjuku.aarとは？ 発表ごとにディスカッションタイムを設けているのが特徴的な勉強会です :) 以下が発表。 Background Execution LimitsのAndroid Pの変更点？ by konyavic めっちゃ面白かったです。 観測されない変更。ログを目diffして見つけていくとかヤバイ。超やばい。 もう胆力の塊。 Visual Studio App Centerで始めるCI/CD by nakasho Visual Studio App Centerで始めるCI/CD from Shinya Nakajima microsoftの本気を見た！ ここまで使い勝手良いのであれば、SDK用の社内のCIを移管するのも有りなのかもしれない 🤔 1つのアプリに複数のプッシュ通知サービスを入れた by takehiroxy 資料がアップされていないのが残念。 foregroundとbackgroundでreceiverの挙動が異なるというのに、まじか、、、という衝撃でした。 RxIdlerを使ってみた話 by youmeee https://github.com/square/RxIdler Reactive Programmingしているときの待ち合わせをちゃんとやってくれる子 これはテストが捗る International Obfuscated Kotlin Contest by lee 少し時間が余ったのでredditなりから面白いネタを leeさんが発表! https://www.reddit.com/r/androiddev/comments/91h2vi/international_obfuscated_kotlin_contest/ Hallo worldを出力するプログラムを以下にkotlinで汚く書くかというアレですねｗ https://github.com/fractalwrench/iokk やっぱ最後は文字コード使って頑張っていくんですね。趣深い。

私はReproで VP of Engineeringというお仕事をしているわけですが、エンジニアだったことも含めて人に関わる領域はわからないことが多いんです。 もう試行錯誤しかありません。答え、教えてくれませんか？ そんな思い満々なので、startupのHR業界盛り上げるためにもイベント作ってみました 👀 開催の雰囲気 https://www.wantedly.com/companies/dip/post_articles/127060 https://www.wantedly.com/companies/peraichi6/post_articles/127106 写真は小林さんの記事から拝借させていただきました。感謝 🙏 What’s Hacking HR! スタートアップにおける人事担当者のロールは多岐にわたります。 採用から労務・総務、果ては経理、営業事務に渡るまで幅広いものです。 しかし、私たち人事担当者のリソースも才能も有限です。 そのため、業務が多岐にわたる人事担当者は、会社の置かれる状況を正しく把握し、今会社の成長のドライバーは何であるか見極め、フォーカスし行動することが求められます。 そんなの正しく判断するのは無理ゲーです。 会社を経営でもしたことがない限りできそうもありません。 そのため、Hacking HR! ではスタートアップにおける人事担当者の活動をハックし、tipsを共有・ディスカッションするとともに、明日も元気に一歩前進できるようにすることを目的としています。 Theme : Hack Recruiting Media! 採用のためのダイレクト・リクルーティングやリファラルを頑張っていく空気づくり、採用のためのイベント開催はとても大変です。MP（多大な精神力）と時間を消費します。 我々HRに時間はない。そんなときに思いつくのは転職したい人が自ら進んで応募してくれるメディアです。 この銀の弾丸っぽいやつを、本当に銀の弾丸にすべく知見を貯めるミートアップを開催しました。 メディアをたくさん使ってみた by Repro株式会社 畑中 五月 GitPitch Presents: github/h-satsukiy/slides コンパクトに話がまとまっていてめっちゃいい。 Wantedly月間300エントリーを獲得し、1年で部署のインターンを4人から40人に増やした話 by ディップ株式会社 小林 宥太 wantedlyを活かすには圧倒的に画像とfeed投稿大事！ エンジニア採用担当者が考える負けないためのメディア戦略 by 株式会社Gunosy 猪飼 直史 負けない戦略。失敗しなければあとは量を増やせばいいだけといういい話。 元agentのikaiさんの面談プロセス話のほうに意識持っていかれそうでした。 狙った相手を逃さない、ダイレクトリクルーティングの極意 by 株式会社アトラエ Customer Success 平井 雅史 様 以下にヒットするDMを打つかという 採用広報ツールとしてWantedlyを使い倒す方法 by ウォンテッドリー株式会社 Customer Success 佐藤 太亮 様 ソーシングどうするのか、部門採用しているのどうなるのか？めっちゃためになる話 ... Read more

stackdriver -> gcs, bqすればよいのでは？ nginx prometheus grafana | | | ------------------- ||| node logging agent(fluentd) ||| stack driver | cloud pubsub | ------------------- | | | bigquery gcs papertrail/stackdriver concern data lost on fluentd node logging agentであるfluentdを終了するときにはいくつか気をつけなければいけないことがある buffer lost fluentd containerを単純にSTOPすると以下のような問題があります。 SIGTERMがcontainerに送られる container内で稼働するfluentdにSIGTERMが伝搬する fluentdがmemory bufferのflushを試みる 失敗してもretryしない この問題を解決するためには以下のような処理をする必要がある。 データの受付を停止 bufferのflushが完了していることを確認 終了 😇 see also: Fluentd’s Signal Handling forwarder data lost 直接データを送信している場合は、接続先のfluentdがdownしても問題ない状態を作らなければいけない service discoveryを行い、生存しているlogging agentに自動で再接続されなければいけない retryが適切になされなければいけない その間、可能であれば処理が継続できなければい tips: how to resolve fluentdのHA構成にておくことで、送信元の問題の解決も比較的容易である。 ... Read more

kubernatesのcluster上でlog集約をどうするべきか考えてみます。 nginx prometheus grafana | | | ------------------- | ココらへんどうしよう？ | ------------------- | | | bigquery gcs papertrail/stackdriver | spark(data proc) default logging architecutre on kubernates まず、kubernates標準ではどのようなログ集約を行っているのか調べます。 The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams. … By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs. ... Read more

GKE上でのblog運用や監視が大分形になってきました。 次に目指すところ ここから以下のようなデータパイプラインとログの分析基盤を作って行きたいと思います。 nginx prometheus grafana | | | ------------------- | fluentd cluster | ------------------- | | | bigquery gcs papertrail | spark(data proc) TODOは以下のようなイメージです。 nginx logをLTSVに変える 自前のfluentd clusterを準備する fluentd clusterからbigquery, gcs, papertrailにfunoutするようにする nginx, prometheus, grafanaなどの稼働するcontainerのlog driverを上記で準備したものに変える google analyticsのデータをembulkを利用した定期バッチで GCSやbigqueryにpertitioningされた形で格納する 上記のログを元に、spark(data proc)を回していい感じに分析できるようにする mllibを使って遊ぶ 今回はその中での一つ目に着手します。 What ltsv 改めてltsvについてまとめます。 http://ltsv.org/ Labeled Tab-separated Values (LTSV) format is a variant of Tab-separated Values (TSV). you can parse each line by spliting with TAB (like original TSV format) easily, and extend any fields with unique labels in no particular order. ... Read more

現在のblogでは以下のようなredirect処理を追加しています。 # redirect http to https if ($http_x_forwarded_proto = "http") { rewrite ^/(.*)$ https://$host/$1 redirect; } これは以下を目的としています。 鍵をnginxで管理せず、GCPのloadbalancerで管理する。 また、https通信の複合処理はGCPで行い、そこから後ろはhttpでアクセスしたい。 このとき、blogはhttps通信しか許可しない。 そのため、ユーザーのrequest時のprotocolがhttpであるかどうかnginxで判断し、httpの場合はhttpsにredirectする localでわざわざ証明書を準備して作業するのもとても面倒。つまり ＿人人人人人人人＿ ＞　localで邪魔　＜ ￣Y^Y^Y^Y^Y^Y^Y^￣ bypass redirect ideas bypassするには以下のような方法がわかりやすいのですが、それぞれに問題があります。 local用のconf + dockerfileを分ける 管理が手間ですし、本番設定ファイルとの乖離が発生するリスクが十二分にあります 環境変数を使ってredirectしないよう処理を分岐する nginxのperl moduleもしくはlua moduleを利用しなければnginxで環境変数を利用することができない そういえば自社でやっている方法やれば良いですね、環境変数とentrykitを利用してconfを制御するようにします。 templating by entrykit entrykit は以下のようなツールです。 Entrypoint tools for elegant containers. Entrykit takes common tasks you might put in an entrypoint start script and lets you quickly set them up in your Dockerfile. ... Read more

とりあえず通知は飛ぶようになったが、２つ問題がある。 現在の通知 通知情報が不足している recover状態が通知されない これを解決します。 Notify recover alert 復旧通知をするには send_resolved optionをtrueにするだけで済みます。 receivers:-name:slackslack_configs:-send_resolved:true これはdefaultでtrueにしてよいきもするので、少しだけ掘ってみます。 https://github.com/prometheus/alertmanager/blob/master/config/notifiers.go#L27 // DefaultSlackConfig defines default values for Slack configurations. DefaultSlackConfig = SlackConfig{ NotifierConfig: NotifierConfig{ VSendResolved: false, }, commit messageを読むと、以下のように一般的に使うチャットシステムだし、通知が多いとスパムっぽくなるからとのこと。 brian-brazil committed on Jan 6, 2016 Don’t send resolved to Slack by default. Slack is a general chat system, it has no notion of resolved messages. Default it to false to avoid spamming people as we do with all other such systems. ... Read more

downtimeの観測ができるようになったので、downtimeがslackに通知されるようにしたいと思います。 そのためにもprometheusのalertingを理解します。 Alerting https://prometheus.io/docs/alerting/overview/ Prometheusのalartは２つのパートに分かれている。 prometheus alert ruleは alert managerに alertを送信する alertmanagerは silencing, inhibition, aggregation をしたり その通知を行う Alert manager behavior https://github.com/prometheus/alertmanager The Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integrations such as email, PagerDuty, or OpsGenie. It also takes care of silencing and inhibition of alerts. ... Read more

いままでgkeの監視に利用するprometheusやgrafanaをimage buildをしていた。 やっていることは設定ファイルの更新でしかないので、これをconfigmapに移行して管理を容易にします。 configmap ConfigMap とは onfigMaps bind configuration files, command-line arguments, environment variables, port numbers, and other configuration artifacts to your Pods’ containers and system components at runtime. ConfigMaps allow you to separate your configurations from your Pods and components, which helps keep your workloads portable, makes their configurations easier to change and manage, and prevents hardcoding configuration data to Pod specifications. ConfigMaps are useful for storing and sharing non-sensitive, unencrypted configuration information. ... Read more