<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d45c2be8-638e-4eed-a7a5-5713d61b0a1b/7984ab2d5c90fe4021010a8f381885f6.png" alt=""></p>
<p>こんにちは！<br>
プレイドで主にインフラを担当しているikemonnです。</p>
<p>1/19(木)に<a href="https://www.freee.co.jp/">freee</a>さんの会場をお借りして、「【freee×プレイド】Tech Meetup 〜インフラ監視編〜」を開催しました！</p>
<p>そこで、KARTEを支えるマルチプラットフォームインフラ監視について話してきましたので、本日はこの勉強会のレポートをお届けしたいと思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0ae92521-5b87-46f1-856a-9a618316c4ce/DSC05081.JPG.jpg" alt=""></p>
<p>卓球台！<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/23ebabde-a4c6-45ea-b847-0be2208a3981/DSC05069.JPG.jpg" alt=""></p>
<p>PLAIDの &quot;Nice Deploy&quot; カップ<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/09206030-401c-4bbc-9120-9fc66c287778/DSC05073.JPG.jpg" alt=""></p>
<h2>発表タイトル</h2>
<ul>
<li>freee を支えるインフラ監視</li>
<li>KARTEを支えるマルチプラットフォームインフラ監視</li>
<li>対談</li>
<li>プロセス生存確認サービス始めました</li>
<li>grafana-zabbix 活用術</li>
<li>prometheus 監視で変わるもの</li>
</ul>
<h2>freee を支えるインフラ監視</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/76d5caee-43e6-4355-8fd6-afdccab00340/DSC05127.JPG.jpg" alt=""><br>
まずfreee <a href="https://twitter.com/manabusakai">@manabusakai</a>さんから「freee を支えるインフラ監視」についてお話して頂きました！</p>
<script async class="speakerdeck-embed" data-id="351643d1ce91448f891b9a2b47ab8ace" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>freeeさんで使っている監視系サービスや少人数(インフラエンジニアが3人！)で運用するためのノウハウについてお話して頂きました！</p>
<p>freeeさんでは下記の5点を工夫することで少人数で運用しておられるとのことでした。</p>
<ol>
<li>情報はプルよりプッシュ</li>
<li>フルマネージドサービスの活用</li>
<li>障害が起きることを前提にインフラを設計する</li>
<li>本業にフォーカスする</li>
<li>トラッキングして見える化</li>
</ol>
<p>上記の内容はプレイドでも当てはまることが多く、特に「本業にフォーカスする」は強く意識しています。</p>

<p>スタートアップでインフラ監視をする際に考えるべき重要なポイントが上手くまとまっていてとても参考になりました！</p>
<p>登壇ブログも書いてくださっています！<br>
<a href="https://blog.manabusakai.com/2017/01/freee-plaid-tech-meetup/">【freee × プレイド】 Tech Meetup に登壇しました</a></p>
<h2>KARTEを支えるマルチプラットフォームインフラ監視</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dfe14c2b-9d8b-4ac3-87a2-63bb7beee4a4/DSC05161.JPG.jpg" alt=""></p>
<p>次に私、プレイド <a href="https://twitter.com/ikemonn">@ikemonn</a>から「KARTEを支えるマルチプラットフォームインフラ監視」の発表を行いました。</p>
<script async class="speakerdeck-embed" data-id="4fb2e580439e49aebad935111d848a58" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
<p>プレイドではもともとAWSのみでインフラを構築していました。</p>
<p>しかし、GCPのBigTableやBigQueryを積極的に利用するにあたり、latencyやnetworkコストの面からGCPにもインスタンスを立てており、現在AWSとGCPの両プラットフォームでインフラを構築しています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ea8c4d56-f532-40ea-bbd8-6cf8479a8b99/----------2017-01-20-18.12.38.png" alt=""></p>
<p>今回の発表では以下のことについて話しました。</p>
<ul>
<li>具体的にどのような値をどのように監視しているのか</li>
<li>ダッシュボードを作るときのコツ</li>
<li>マルチプラットフォームの監視でハマったこと</li>
</ul>
<p>プレイドのインフラエンジニアは2名でして、少数でマルチプラットフォームの監視を行っていくために以下のことを工夫しています。</p>
<ul>
<li>情報/アラートを一元管理する</li>
<li>問題をドリルダウンして追っていけるようにする</li>
</ul>
<p>マルチプラットフォーム監視にご興味のある方は是非スライドを御覧ください！</p>
<h2>対談</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d32537a3-8b77-423c-b38f-ba5814547d9b/DSC05196.JPG.jpg" alt=""></p>
<h6>Dashboardやアラートを作ったり、整理したりするタイミングは?</h6>
<ul>
<li>障害駆動でDashboardやアラートを作る</li>
<li>アラートの数は抑え気味で、監視しすぎないことを意識している</li>
</ul>
<h6>適切な負荷ってどうやって監視するの?</h6>
<ul>
<li>時系列のデータから低負荷を定義しやすい。ソーシャルゲーム等だと色々イベントあるから難しい</li>
<li>決めの問題で、余裕があるときに一気に落として見たり負荷テストしてみたりすると良い</li>
<li>自分のカードで支払うとしたら?と考えてコスト落とす。勇気のある方は自分のカードを登録してもいいかもｗ</li>
</ul>
<h6>使用中のモニタリングツールの辛いところ、改善して欲しいところは?</h6>
<ul>
<li>Datadog
<ul>
<li>セキュリティ, 99 percentile位まで見たい, 異常値検出でインスタンスの起動/終了時を省けない</li>
</ul>
</li>
<li>Mackerel
<ul>
<li>Zabbixに比べて画面が重い。画面を開き続けているとバッテリーの持ちが悪い。</li>
<li>障害が今起きてるのに画面が遅いのは困る！簡易版で良いから画像で出すoptionとか欲しい</li>
</ul>
</li>
</ul>
<h6>通知を受け取る範囲/対象はどのように設定していますか？ 通知が多すぎるとオオカミ少年になるので。</h6>
<ul>
<li>緊急の場合はPagerdutyで、その他は緊急度に応じてSlackのchannelを分ける</li>
<li>緊急性の高い問題が飛んでくるチャンネルと、少し気にしておけば良い優先度の低い問題を飛ばしているchannelをわけている</li>
<li>twilioを使ってインフラエンジニアにランダムで電話をかける</li>
</ul>
<h6>新しい監視ツール・サービスを導入する際、社内をどう説得しているか</h6>
<ul>
<li>PLAIDはCTOが新しいサービスが好きで、hackernewsなどで見つけたものをshareしてくれる
<ul>
<li>free trialですぐ試して、ある程度の金額までだったらすぐに導入できる</li>
</ul>
</li>
<li>freeeにいると苦労しないが、前職だと稟議を通したりしないといけなかった
<ul>
<li>ツールを導入することでどれくらい安くなるかを言えると話が早い</li>
</ul>
</li>
<li>社内稟議が大変な会社は
<ul>
<li>何をやっているかわからない人の言うことはなかなか理解されないので、社内で勉強会をやったりして何をやっているかアピールする</li>
<li>社内でPRすると色々実現しやすくなる</li>
</ul>
</li>
</ul>
<h2>プロセス生存確認サービス始めました</h2>
<script async class="speakerdeck-embed" data-id="2fb4c7a90f25461599d4a8e0bf62d5ab" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
<p><a href="https://github.com/narita-takeru">@narita-takeru</a>さんから「プロセス生存確認サービス始めました」というテーマで発表して頂きました。<br>
「サーバにsshせずとも、バッチ処理のプロセスの死活監視を簡単に行いたい」という想いから、プロセスの死活監視ツール<a href="https://nursecall.io/#/signin?redirect=%2F">NurseCall</a>を作られたそうです！</p>
<p>プロセスが生きている/生きていたかの監視を行いたい方はぜひ使ってみてはいかがでしょうか？</p>
<h2>grafana-zabbix 活用術</h2>
<script async class="speakerdeck-embed" data-id="df7ec85f5c7847e2a988fc9234892ecc" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p><a href="https://twitter.com/kakakakakku">@kakakakakku</a>さんから「grafana-zabbix活用術」についてお話していただきました。<br>
<a href="https://github.com/alexanderzobnin/grafana-zabbix">alexanderzobnin/grafana-zabbix</a> を使うことで、モダンな見た目のzabbixが使えるようになるそうです！<br>
grafana-zabbixの良いところが、zabbixサーバには影響を与えずに試せるため、手軽にTryできるところです。<br>
zabbixを使っておられる方も多いと思いますので、一度試してみてはいかがでしょうか！</p>
<p>発表の際にあげておられた、<a href="https://www.amazon.co.jp/Effective-Monitoring-Alerting-Web-Operations/dp/1449333524/ref=sr_1_1?s=english-books&amp;ie=UTF8&amp;qid=1484893216&amp;sr=1-1&amp;keywords=Effective+Monitoring+and+Alerting%3A+For+Web+Operations">Effective Monitoring and Alerting: For Web Operations(Oreilly)</a>をちょうど年末に読んでおり、監視に関するオススメ本なのでぜひ読んでみてください！</p>
<p>勉強会の参加ブログも書いていただきました！<br>
<a href="http://kakakakakku.hatenablog.com/entry/2017/01/20/003857">Tech Meetup に参加して「grafana-zabbix 活用術」を紹介してきた - kakakakakku blog</a></p>
<h2>prometheus 監視で変わるもの</h2>
<script async class="speakerdeck-embed" data-id="ae4d55d171af409a8f50e4b0d4948340" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p><a href="https://github.com/sugitak">@sugitak</a>さんから「prometheus 監視で変わるもの」についてお話していただきました。<br>
最近話題になっている<a href="https://prometheus.io/">Prometheus</a>を実際に使用されていて、Prometheusの思想や具体的にどのように使っているのかについてお聞きできました！<br>
「大量のホストのCPU使用率を１つのグラフに表示する」のではなく「CPU使用率の最小値と最大値だけを表示する」と言ったように、「本当に必要な情報だけを表示する」思想は良いなと思いました！</p>
<p>Qiitaの方にも記事を書かれていますので、ご興味のある方は是非！<br>
<a href="http://qiita.com/sugitak/items/ff8f5ad845283c5915d2">次世代監視の大本命！ Prometheus を実運用してみた</a></p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを支えるマルチプラットフォームインフラに興味がある！KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><br>
をご覧ください。</p>

【freee×プレイド】Tech Meetup 〜インフラ監視編〜を開催しました！
KARTEを支えるマルチプラットフォーム(AWS/GCP)インフラ監視について話してきました

【freee×プレイド】Tech Meetup 〜インフラ監視編〜を開催しました！

<html><head></head><body><p>PLAID エンジニア/HUNTER<br>
山内 雅浩<br>
@algas</p>
<h2 id="概要">概要</h2>
<p>node.js (npm) での依存性解決とパッケージマネージャを <a href="https://docs.npmjs.com/cli/shrinkwrap" target="_blank" rel="noreferrer">shrinkwrap</a> から <a href="https://yarnpkg.com/" target="_blank" rel="noreferrer">yarn</a> へ移行した話。<br>
<a href="https://algas.github.io/npm-to-yarn-slide" target="_blank" rel="noreferrer">プレイド勉強会での発表資料</a> も合わせてご覧ください。</p>
<h3 id="対象読者">対象読者</h3>
<ul>
<li>node.js で継続的に開発を行っているエンジニア</li>
<li>npm 依存関係地獄に苦しんでいる同志</li>
</ul>
<h3 id="結論">結論</h3>
<p>shrinkwrap を捨てて yarn を使いましょう。<br>
ただし production に使うのはちょっと早い。<br>
執筆時点での yarn のバージョンは 0.17.10 です。</p>
<h2 id="shrinkwrap vs yarn">shrinkwrap vs yarn</h2>
<p>(npm) shrinkwrap と yarn を比較してみましょう。</p>
<div class="TableScroll"><table>
<tbody><tr>
<th>項目名</th>
<th>Node.js</th>
<th>Yarn</th>
</tr>
<tr>
<td>パッケージマネージャ名</td>
<td>npm</td>
<td>yarn</td>
</tr>
<tr>
<td>パッケージファイル</td>
<td>package.json</td>
<td>package.json</td>
</tr>
<tr>
<td>パッケージ指定ファイル</td>
<td>npm-shrinkwrap.json</td>
<td>yarn.lock</td>
</tr>
</tbody></table></div>
<p>yarn を使う利点と欠点は以下のとおりです。</p>
<h3 id="PROS">PROS</h3>
<ul>
<li>インストール処理が高速かつ安定<br>
ネットワークパフォーマンス改善やオフラインモード、リトライの実装がされていてパッケージのインストールが標準の <code>npm install</code> に比べて高速かつ安定に動作します。</li>
<li>依存性解決の向上<br>
複数のパッケージで使われている同じパッケージを1つのインデックスにまとめることでインストールするパッケージ数を減らし、ディスク容量の軽減・インストール速度の向上を実現しています。</li>
</ul>
<h3 id="CONS">CONS</h3>
<ul>
<li>yarn 自体のインストールが必要<br>
他のパッケージよりも先に yarn をインストールしなければなりません。shrinkwrap は npm に標準装備されているのでインストールは必要ありません。</li>
<li><code>npm ls</code> と <code>yarn ls</code> の互換性がない<br>
<code>npm install</code> 済みのパッケージを確認するコマンドである <code>npm ls</code> と <code>yarn install</code> 済みのパッケージを確認する <code>yarn ls</code> に互換性がありません。<code>yarn install</code> が正常にできた環境で <code>npm ls</code> を実施しても OK と返らない場合があります。</li>
<li>yarn 自体の不具合<br>
yarn のバージョンは執筆時点で 0.x であり、正式バージョンである 1.0 以上になっていません。公開されて間もないこともあり、issue が大量に上げられていて yarn 自体の不具合に悩まされることもあります。</li>
</ul>
<h2 id="node パッケージの追加と削除">node パッケージの追加と削除</h2>
<p>パッケージを追加・削除する方法にはコマンドからインストールするのと、package.json に書いてからインストールする2通りの方法があります。<br>
CIなどのリモート環境では後者の方法で運用する場合もあります。</p>
<ul>
<li>
<p>npm + shrinkwrap の場合</p>
<ol>
<li>コマンドからインストール
<ol>
<li><code>npm install --save new_package</code> or <code>npm uninstall --save new_package</code></li>
<li><code>npm ls</code></li>
</ol>
</li>
<li>package.json からインストール
<ol>
<li>dependencies に new_package を追加/削除する</li>
<li><code>npm update --save</code> (危険)</li>
<li><code>npm ls</code> (失敗しがち)</li>
</ol>
</li>
</ol>
</li>
<li>
<p>yarn の場合</p>
<ol>
<li>コマンドからインストール
<ol>
<li><code>yarn add new_package</code> or <code>yarn remove new_package</code></li>
<li><code>yarn check</code></li>
</ol>
</li>
<li>package.json からインストール
<ol>
<li>dependencies に new_package を追加/削除する</li>
<li><code>yarn upgrade</code></li>
<li><code>yarn check</code></li>
</ol>
</li>
</ol>
</li>
</ul>
<p>shrinkwrap を使った場合には package.json に手動でパッケージを追加すると、それを削除した際に追従できずにエラーが発生することがありますが、yarn を使った場合に同じ作業を行っても問題が発生しません。</p>
<h2 id="依存関係地獄 (dependency hell)">依存関係地獄 (dependency hell)</h2>
<p><code>npm-shrinkwrap.json</code> を使うことで確かに <code>npm install</code> で同じパッケージ群をインストールすることはできるようになります。<br>
この環境に package.json への追加によって新しいパッケージを追加しようとした場合には shrinkwrap は正しく依存関係を更新できません。</p>
<p>以下の手順で依存性解決をすることになります。</p>
<ol>
<li>本体またはサブモジュールの <code>package.json</code> を更新する</li>
<li><code>npm install</code> or <code>npm update --save</code> を実行する</li>
<li>パッケージの更新に失敗する</li>
<li>1.に戻る(依存性解決できるまで繰り返す)</li>
</ol>
<p>結局、問題が解決できずに <code>npm-shrinkwrap.json</code> を削除するしかない状況に陥ることも多くあります。<br>
これが継続的に依存性問題を解決できない理由です。</p>
<h2 id="依存性解決できない問題">依存性解決できない問題</h2>
<p>node.js でデファクトスタンダードになっているパッケージ管理ツールである npm (node package manager) で依存性を解決するのが難しいという問題があります。<br>
現状では shrinkwrap という npm に標準装備されている方法を使ってインストールされるパッケージを固定(バージョン指定のスナップショット)できます。<br>
<code>npm shrinkwrap</code> コマンドでパッケージ指定ファイル <code>npm-shrinkwrap.json</code> を生成することで、他の環境で <code>npm install</code> を実行した際に(依存関係も含めて)同じパッケージがインストールされるようにします。<br>
上記で書いたとおりに shrinkwrap を使えばインストールされるパッケージを固定することはできます。しかし上述の通り、実際に運用してみると shrinkwrap ではパッケージの固定はできても、継続的な依存性解決ができるわけではないことがわかります。</p>
<h2 id="Yarn の不具合">Yarn の不具合</h2>
<ul>
<li>production install できない<br>
<code>yarn install --production</code> が効かない。つまり devDependencies もインストールされる。<br>
https://github.com/yarnpkg/yarn/issues/761</li>
<li>postinstall を実行してない問題<br>
deep dependencies で preinstall, install, postinstall を実行できてない。<br>
https://github.com/yarnpkg/yarn/issues/2142</li>
</ul>
<h2 id="自作ツールの紹介">自作ツールの紹介</h2>
<p>緩やかに移行したい方へ <code>npm-shrinkwrap.json</code> から <code>yarn.lock</code> を生成するツールを作りました。<br>
https://github.com/algas/shrinkwrap2yarn<br>
使い方は上記リポジトリの README をご参照ください。<br>
動かなかったり不具合を見つけたりした場合には issue, PR をお待ちしております。<br>
自社の製品では~~<code>shrinkwrap.json</code> の作成フローが雑だったので~~結局使いませんでした。</p>
<h2 id="ハマったこと">ハマったこと</h2>
<ul>
<li>npm でのインストールの挙動(サブコマンドの動作など)が把握できなくて、理解するまでにすごく時間がかかりました。</li>
<li>自社の node.js プロジェクトの依存性解決に手間取りました。</li>
<li>うちの package.json はいろんな処理を書きすぎじゃね？</li>
</ul>
<h2 id="参考文献">参考文献</h2>
<ul>
<li><a href="https://shift.infinite.red/npm-vs-yarn-cheat-sheet-8755b092e5cc" target="_blank" rel="noreferrer">NPM vs Yarn Cheat Sheet</a></li>
<li><a href="https://yarnpkg.com/en/docs/migrating-from-npm" target="_blank" rel="noreferrer">Migrating from npm</a></li>
</ul>
<h2 id="まとめ">まとめ</h2>
<p>今すぐ <code>shrinkwrap</code> を捨てて <code>yarn</code> と旅に(ry</p>
<h2 id="エンジニア募集中">エンジニア募集中</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/" target="_blank" rel="noreferrer">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html" target="_blank" rel="noreferrer">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects" target="_blank" rel="noreferrer">Wantedly</a><br>
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
</body></html>

PLAIDエンジニア 山内雅浩 @algas yarn を使って node.js の依存性解決 npm shrinkwrap と yarn との比較

まだ node.js の依存性解決で消耗してるの？ | PLAID engineer blog

まだ node.js の依存性解決で消耗してるの？

<p>こんにちは。プレイドの@monoiです。<br>
プレイドでは主に管理画面周りの開発を担当しています。</p>
<p>さて、突然ですがプレイドには最近ある課題が浮上しています。<br>
それはメンバーが増えるに伴って、コミュニケーションの機会がなかなかない人ができてしまうこと。</p>
<p>この課題には多くの会社が頭を悩ませていると思いますが、コミュニケーションと言えば何と言っても<strong>ランチ</strong>ですよね。<br>
普段の業務であまり関わりのない人でも、一緒にランチに行けばそこには<strong>深い友情</strong>が芽生えるかもしれません。</p>
<p>そんなわけで今回は、ランチメンバーをシャッフルしてグループ分けしてくれるSlackbotを、AWS Lambdaを使って作成しました。</p>
<h1>目次</h1>
<ul>
<li>プレイドのbot紹介</li>
<li>AWS Lambdaとは？</li>
<li>作る</li>
<li>完成</li>
<li>最後に</li>
</ul>
<h1>プレイドのbot紹介</h1>
<p>botを作る方法は様々あります。</p>
<p>プレイドにはすでに多くのおもしろいbotがいるので、これらを紹介しつつ、処理方式を検討していきます。</p>
<h2>はる子さん</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bf5fcce8-3d22-467e-b818-f7ebe5f594da/hal.png" alt=""></p>
<p>はる子さんは優秀な人事・労務管理botです。<br>
勤務時間を管理してくれたり、社員のプロフィールを教えてくれたりします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/695cb0dc-1c30-41c7-979f-d558d15b6966/----------2016-12-14-16.09.02.png" alt=""></p>
<p>はる子さんは、社内に置いてあるMacBookAirにnode.jsサーバーを立てて動かしています。<br>
以前はiBeaconを使って社員がオフィスにいた時間を把握し、自動で勤務時間を記録してくれる仕組みもありました。（リモート勤務や外出が多い社員の勤務時間をうまく取得できないため、一時休止中。）</p>
<h2>KARTEくま</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dd9c67da-d00d-41c8-ba1a-ba8a53b73e02/cap4.png" alt=""></p>
<p>KARTEくまはCX(Customer Experience)チームをサポートするためのbotです。プレイドが提供しているサービスで、異常な数値が検出されていないか等のチェックを行っています。</p>
<p>Google App Scriptで定期実行し、SlackのIncoming Webhookを叩いています。</p>
<h2>karte-hubot &amp; DeployBot</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6dfe76a1-b314-4ad3-8bd4-fba5e6ab7004/deploy_bot.png" alt=""></p>
<p>日々のデプロイを補助してくれるbotです。<br>
デプロイをするのにいちいちコマンドを叩くのは面倒だ、ということで、Slack上で特定のキーワードを打つとデプロイできるような仕掛けが作られました。</p>
<p>こちらはEC2インスタンス上で動作させています。<br>
karte-hubotは名前の通りgithub社の<a href="https://hubot.github.com/">hubot</a>フレームワークを使っています。</p>
<h2>さてどうするか。</h2>
<p><strong>完全に余計な手間ですが</strong>、まだ社内で使われていない方法で作ってみたい・・・！</p>
<p>というわけで今回は<strong>AWS Lambda</strong>で作ってみました。</p>
<h1>AWS Lambdaとは？</h1>
<p>FaaS（Function-as-a-Service）の一種で、AWS上に関数を置いておき、インスタンスを立ち上げることなくクラウド上でアプリケーションを実行できるサービスです。<br>
CloudWatch（定期実行）や、S3（データがアップロードされたら実行）など様々なAWSのサービスをトリガーにして実行させることができます。<br>
2016年12月現在、Node.js、Python、Java、 C#に対応しています。</p>
<p>実際に処理が行なわれている時間のみしか課金されないため、常時動かす必要のないアプリケーションとは相性がいいです。<br>
お昼の時間しか動かさない今回のbotにはうってつけですね。</p>
<h1>作る</h1>
<h2>作成するbot</h2>
<p>ランチメンバーを募集してグループ分けしてくれる<strong>ランチくまbot</strong>。</p>
<ul>
<li>12:00に「一緒にランチに行く人募集ー！」と誘いがくる。</li>
<li>13:00に上のメッセージに対してリアクションした人を適度な人数でグループ分けする。</li>
</ul>
<h2>slackでBot Userを作る</h2>
<p>まず https://slack.com/apps/build からBot Userを作成します。</p>
<p>作成が完了したら、登場させたいchannelにinviteしてあげましょう。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3b37bc27-bb31-4c86-8027-28ca66844a22/----------2016-12-14-18.51.08.png" alt=""></p>
<h2>Lambdaのsetup</h2>
<p>続いて<a href="https://aws.amazon.com/jp/">AWSコンソール</a>からLambda Functionを作成します。</p>
<p>今回は定期実行なので、トリガーはCloudWatch Eventを使います。<br>
「平日12時」に実行の場合、CloudWatchのスケジュールは<code>cron(0 3 ? * MON-FRI *)</code>としてあげればOKです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9e584509-f549-4993-a992-083e09fd7ea7/----------2016-12-14-16.47.42.png" alt=""></p>
<p>「平日12時」のCloudWatch Eventでは<code>{&quot;event_name&quot;: &quot;send&quot;}</code>を投げるようにしています。<br>
「平日13時」のEventでは<code>{&quot;event_name&quot;: &quot;aggregate&quot;}</code>を投げます。<br>
event_nameによって処理内容をハンドルします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f78cd9a1-3b7b-42a7-b198-ee7ff5133f1a/----------2016-12-14-16.53.12.png" alt=""></p>
<p>また、タイムアウトまでの時間がデフォルトでは3秒になっているのですが、slackのAPIを何度か叩くので念のため10秒にしておきます。</p>
<h2>コードを書く</h2>
<p>通常通りローカルでコードを書き、その後zip化してAWSのコンソール画面からアップロードします。<br>
ブラウザ上でもちょっとしたコードを書くことはできますが、モジュールのインストールなどはローカルで行う必要があります。</p>
<p>ボタンひとつでテスト実行することもでき、デバッグも容易です。<br>
もちろんただの関数なので、ローカルでも簡単にテストできます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f963c72b-8523-4763-aef1-004a7f388a37/----------2016-12-15-2.47.08.png" alt=""></p>
<p>Lambda Function内からのみアクセス可能な環境変数をコンソール画面から設定することができます。<br>
例えばCHANNEL名をここで設定できるようにすると、再アップロードせずに投稿先のチャンネルを切り替えられるようになり、テストが非常に楽になります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c4cfced0-5cbc-4561-b729-3488edd2994f/env.png" alt=""></p>
<p>その後は<a href="https://api.slack.com/">SlackAPI</a>を見ながらコードを書き進めていきます。<br>
SlackのAPIは非常に豊富でわかりやすいです。</p>
<h1>完成</h1>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18ed12f5-d0df-4398-842c-bd5afb093da5/cap.png" alt=""></p>
<p>まずは自己紹介から入ります。<br>
先ほど紹介したKARTEくまbotの作成者である@akobaさんからも受け入れられたようです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18f9c763-e4d4-4759-9807-54dfb60e1cc3/cap5.png" alt=""></p>
<p>12:00になるとlunchチャンネルにメッセージを投稿し、募集を開始します。<br>
よく分からないリアクションもいっぱい付いてますが、lunch_kumaは余裕で全て受け入れます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c03c1d8e-7a5e-4589-b478-7fe83421136d/cap3.png" alt=""></p>
<p>13:00になるとリアクションをしたメンバーをシャッフル、グループ分けします。<br>
いい感じにグループ分けできました！</p>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくはこちら（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


社内のコミュニケーションを活性化させるため、ランチメンバーをシャッフルしてグループ分けしてくれるSlackbotをAWS Lambdaを使って作成しました！