URLごとのパフォーマンス監視ツールをつくりました

小林芳樹, 唐澤貴大他2人

エンジニア, 技術者

小林芳樹

株式会社ベーシック / エンジニア

フォロー

唐澤貴大

株式会社ベーシック / 技術者

フォロー

長谷川博貴

株式会社ベーシック / エンジニアリーダー

フォロー

佐々木亮祐

株式会社Basic / エンジニアリーダー

フォロー

株式会社ベーシック

on 2017/07/05

404 views

パフォーマンス監視ツールを作ろうと思ったきっかけ

ベーシックのgithubには雑リポジトリと呼ばれているリポジトリがあります。

雑リポジトリとは、とりあえず普段思いついたアイデアをぼんぼん放り込んでいくためのリポジトリで、cookpadさんがやっていたのをマネをして開始してみました。（参考：雑な発想を活かすチーム作り）

このリポジトリにはエンジニア以外のメンバーも登録できるようになっているのですが、そこであるマーケッターからこんな要望があがりました

「ページスピードもサイトを作る時のルールの1つにしたい」

ごもっともな意見

（雑リポジトリに投稿された内容）

パフォーマンスの監視自体は各サービスでやっていたり、やってなかったりな状態であったため、いい機会なので会社として統一の仕組みをつくっちゃおーっということで始めることにしました。

一応世の中的に利用されているパフォーマンス監視ツール（zabbixやnewrelic等）を使うことも考えられたのですが、今回の要件として

URL単位で計測したい
DOMの読み込み完了時間までを計測したい

という2点があり、特にURLごとに計測をするという点で既存のサービスだと不便を感じるところがありましたので、自分たちでつくることにしております。

今回は開発メンバーの話がメインになりますので、技術的な視点でのお話は少なめになっております。そちらをあまり期待しすぎると物足りない感がでてしまうかもしれなませんが、ご了承ください！！！

構成

紆余曲折あったのですが、最終的にはこうなりました！！

サービス名：sakimori

当初完全Server Lessを目指していたのですが、残念ながらLambdaの仕様上どうしようもない問題（※）がでてきてしまったため、ec2インスタンスを1つ用意することになりました。
（※どうしようもない問題については、話の中に出てきますので是非目を通していただきたく...！！）

使っている技術、サービスとして

Vue.js
HeadLess Chrome
Go
Lambda
ElasticSearch
ElastAlert
Kibana

今風の面白そうな仕組みで、オラなんだかワクワクすっぞ！！

大枠の処理の流れ

S3上にあるURL設定管理画面で管理したいURLを登録
ec2インスタンス上のcronに設定したプログラムが定期的に動いて、[1]で登録したURLを取得して1つずつSNSに投げる
SNSをトリガーにしてLamda functioinを実行
URLを受け取ったLambdaがHeadLess Chromeでサイトにアクセスして、ページ表示速度を計測
計測した結果をLambdaからElasticSearchに投げる
ElasticSearchに投げられた結果をkibanaでグラフ化
ElasticSearchに投げられたデータはElastAlertで監視をして、しきい値を超えた場合にslackへ通知

サービスを決める

今回作るサービス名を先に決めて置かないと、開発進めていく上で色々と不便というか迷うことが出てくるので、サービス名を決めることにしました。

まずはみんなで適当に名前を出して開発メンバーでの投票制です。

そして.......何やかんやあって、「sakimori」に決定。

どうやってすすめるか

さてつくろうと思ったものの、どうやって進めるか。

ベーシックでは開発部という部署はあるものの、メンバーはベーシックで運営をしている各サービスを担当することになっています。そのため事業部に属したサービス開発は、そのサービスを担当しているエンジニアがやれば問題ないものの、事業部をまたいだ開発となると、「誰がやるか」というところをはっきりと決めなければなりません。

１人でも進めていこうと思えばできるレベルのツールだったかもしれませんが、個人で進めるにはモチベーションの維持とか、スケジュール管理とかもろもろなかなか大変だろうな、と思ったためチームをつくることにしました。

通常のサービス開発をしながらになるため、細かくスケジュール管理をしていく必要あるので、とりあえず週1でミーティングをするようにして、その時に毎回次回のミーティングまでにやることを決めて進捗管理。

（議事録はDropbox Paperを使ってまとめました。マークダウン形式でかけるので簡単にメモを取れて共有できるので便利）

後はslackで専用のチャンネルを用意して、細かいコミニュケーションは、そのチャンネル上で進めていきました。

開発メンバーインタビュー

ここからは実際に開発に携わってもらってメンバーに話を聞いてみたいと思います。

私がいろいろ書いてますが、ほぼ何もしてませんので...

メンバーは

長谷川博貴（kibana周り）
後藤達彦（ElastAlert周り）
len（計測処理周り）
佐々木亮介（計測処理のLambdaとのつなぎこみ）
唐澤貴大（URL管理画面）

インタビュアーは私、小林芳樹です。
です。それでは順番に行きましょう！

長谷川博貴

（MVPを取った時の写真）

まずは山ラボに所属する、筋肉むきむきラガーマン系エンジニアの長谷川くんです。

遠隔にいながらも、遠隔感を全く感じさせないところや、円滑にすすめていくコミニュケーションスキルに定評があります。

そんな長谷川くんのブログはこちら↓
リモートで事業成長にコミットするエンジニアが山形で幸せに暮らせる理由

---

小林：ではよろしくお願いします。

長谷川：長谷川博貴、28歳です。7ヶ月の子供を溺愛中です。お仕事はFC比較ネットとか開発しております。愛読している新聞は日経MJ新聞です。

小林：新聞読んでいる人久々にみた。

長谷川：掃除機はマキタ派です

小林：マキタ...？まあ、マキタはいいや。入社してどのくらいでしたっけ？

長谷川：えーと2015年2月9日入社なので、2年と4ヶ月と6日です

小林：細かい...2年いればもういい感じですね。まずは...sakimoriではどの辺を担当しました？

長谷川：AES（Amazon ElasticSearch）、kibanaらへんですね。

小林：それぞれどんな設定周りを触ったんでしょ？

長谷川：AESは一通りセットアップした感じですが、ドメイン作成、インデックス作成、あと計測側で送ってもらうJSON形式をきめたりとかです。

kibanaは主に各サービスのパフォーマンスのチャート作成と各チャートをまとめてたダッシュボードの作成らへんでございますね。

（kibanaでみれるダッシュボード。なんかすごいカラフルで、まだちょっとみずらい...でもグラフを作るのは簡単）

小林：今回AES触るの初めてだったと思ったけど、どうでしたかね？思っていたより難しかったとか

長谷川：思ったより簡単に扱えた感あります。

小林：へー

長谷川：設定もそうですが使いやすかったです。今回はkibanaと連携して使いましたが、いろいろと使い所がありそうな雰囲気を感じました。
ただ、ちょっとindexのところで融通が効かない所とかがあったりしたましたね

小林：あの一度設定したインデックスが変更ができないやつ？

長谷川：そうです。indexの型変更で既にデータ入っていると型が変更できなそうな雰囲気で。（※）

普通なら簡単にできそうなところですが、ただ逆にindex用意してなくてもデータ取り込んでくれたりと柔軟なところもあり、全体的には慣れたらすごくいいものかと。

（※ElasticSearchのインデックスは一度設定すると変更が効かないのですが、reindexAPIを使うとできるようです。参考：http://dev.classmethod.jp/cloud/aws/amazon-es-elasticsearch5-release/）

小林：データを突っ込めば勝手にグラフだしてくれるし、データの形式も自由にできるので、いろいろ使えそうな感じはありますねー
なんか他のことにも使っていきたい感はあります、せっかくなんで。

長谷川：kibanaはかなり多機能で、実際まだぜんぜん使いこなせてない感あります。他のには使っていきたいですね。
CVデータとかうまく投げれば、自前の管理画面代わりにもなって分析にも向いているかと思います。

ferret One(※)ではユーザーのログを全て投げていて、該当のユーザーから問い合わせされたときに、そのユーザーが本当に操作したかとか見てるらしいです。
（ferret Oneとは弊社ベーシックで開発をしている、オールインワンマーケティングツールのこと）

小林：あー、ユーザーの操作ログとかをElasticSearchに投げれば、そういうのできますね

長谷川：操作してなかったときに「あなたそんなこと言ってるけど操作してないですよね？」と言われたら感じ悪いような気がしますけどねww

小林：www

長谷川：ElasticSearchで、kibana上で検索もしやすいのでホントいろいろ使える雰囲気です。ElasticSearchなので、名前の通りですね

小林：elasticって柔軟な、みたいな意味だったかな、たしか

長谷川：融通きくぜ的な感じかと

小林：このsakimoriプロジェクトをやってみてどうでした？

長谷川：とても良い機会だったかなと思います。普段の通常業務だけでは触れられない技術もそうですが、東京-山形間で複数人で一つのもの作っていくことで、なんか連携感があったかなと。

小林：まるでお願いをしたかのように、すばらしい感想ありがとうございます。普段はリモートで働いているので、よりチームでやった時の連帯感を感じることができたのかもしれませんね。

長谷川：ただ全体的に時間とれなかったので（他のところがっつり時間とってやっていただいた方々ありがとうございます）Google20%ルールのように、決めて時間とっていけるとよいのではと。

小林：そーっすねー、そのへんはもう少しいい感じで制度かしていきたいですね。今はまだ無理やり組み込んでいる感はいなめないので

長谷川：定例山形開発合宿するしかないですね

小林：結構ありだと思う（5割ぐらい本気）
あと今後のsakimoriでやりたいことありますか？

長谷川：kibana拡張ですね。見やすくってのはもちろんですが、いろいろ知らない機能がまだたくさんありそうなので

小林：そうね、正直なんかまだ見やすい状態とはいいがたいので、もっと改善していきたい！
というわけで、ありがとうございました！

長谷川：ありがとうございました！インタビュー形式なんかよいですね

小林：インタビュー形式のブログを書くのが僕の夢でした

===============================================================================

後藤達彦

続きまして、先程の長谷川くんと同じく山ラボに所属する、アニメとゲームが好きで、ハンターハンターが再開してモチベーションバリ上がりの後藤くんです。

---

小林：それではよろしくー

後藤：山形ラボ在勤の後藤です。SIerから転職して約1年半程です。普段は自社で運営する比較サイトの開発を担当しています。

小林：まだ1年半か...

後藤：まだ1年半ですねぇ…

小林：（しみじみ）では今回のプロジェクト[sakimori]をやるにあたって、どんなところを担当しましたか？

後藤：今回のプロジェクトでは、サイト読み込み速度が一定時間以上かかっているサイトについて、監視側に通知を行う機能を担当しました。

小林：具体的にどんな仕組みでしょ？

後藤：今回はAmazon Elasticsearch Serviceを利用する環境でしたので、無料でElasticsearch Serviceに対応していたElastAlertというOSSがあったので導入してみました。

ESに対してクエリを発行し、検索結果に対して、任意に設定したイベント回数や値を監視できるツールとなります。この任意に設定した監視ルールに基いて、slackの専用チャンネルへと通知を行うようにしました。

（閾値を超えると上記の様な感じでslackに通知が飛んでくるように設定してます。）

小林：ElasticAlertってあんまり情報なさそうな雰囲気
実際いれてみてどうでした？導入のしやすさとか、わかりやすさとか

後藤：実際いれてみて、結構大変でした。まず、導入のしやすさで言うと、まずインストール時の対話コマンドがドキュメントと異なる。
AESを考慮したドキュメントが揃っていない（機能はあるっぽい）ため難儀しました...

小林：ドキュメントって
http://elastalert.readthedocs.io/en/latest/elastalert.html
これだよね

後藤：それです
http://elastalert.readthedocs.io/en/latest/running_elastalert.html?highlight=install#setting-up-elasticsearch

この辺のsetupの項目を見ながら作業をしました。

小林：ここがバージョンが違って微妙にコマンドが違ったっていうことです？？

後藤：おそらくそうだと思います。
ドキュメントよりも対話コマンドの種類が増えてました。。。

小林：ほー、まあ、あるあるですかねw

後藤：setup時に聞かれる項目がドキュメントの2倍くらいになっていた。とか
http://elastalert.readthedocs.io/en/latest/running_elastalert.html#setting-up-elasticsearch

クエリーの例文通り書いても動かない…とかhttp://elastalert.readthedocs.io/en/latest/recipes/writing_filters.html#query-string

小林：つらい

後藤：そうですねw

小林：後は、ElasticSearchとの接続部分でも若干苦戦しましたね。設定ファイルが意外とややこい

--------------------------------------------------------------------------------------------------------------------------------
config.yaml（全体設定）

rules_folder: sakimori_rules #アラート詳細設定ファイルの配置ディレクトリ
run_every: 
  hours: 1                   #アラート通知間隔、これは1時間に1回通知
buffer_time:
  hours: 1

es_host: <elastic searchのホスト>

es_port: 443
aws_region: ap-northeast-1
use_ssl: True

writeback_index: <AESのindex名>

※デフォルトで用意されているconfig.yamlがuse_sslの項目がコメントアウトになっていて、AESとうまく通信できずはまる...

※事前準備としてAWSACCESS KEYIDとAWS SECRETACCESS KEYを環境変数に登録しておきます。

sakimori_rules/sakimori.yaml（詳細設定）

use_ssl: True
aws_region: ap-northeast-1
name: sakimori_response_rule # sakimoriのルール名（なんでも良かったはず...）

type: frequency              # 指定条件が指定回数以上きたら発火
index: sakimori*
num_events: 1                # n回発生したら発火 
timeframe:                   # データのチェック間隔
 hours: 1
query_key: url               # 主キーを設定
filter:
- bool:                      # boolクエリ（AND,OR,NOT検索指定時に必要）
    should:                  # shouldクエリ(ORを表す)
        - bool:
            must:            # mustクエリ(ANDを表す)
                - term:
                     service: "fc-hikaku.net" # serviceがfc-hikaku.netに合致
                - range:
                     total:
                        gte: 15               # totalが15以上のデータ
        - bool:
            must:
                - term:
                     service: "www.canvath.jp"
                - range:
                     total:
                        gte: 10
alert:
- slack

slack_webhook_url: "<slackのwebhookURL>"
slack_username_override: "<slackへの投稿ユーザーの名前>"
alert_subject: "{0}のパフォーマンスが低下しているようです"
alert_subject_args: ["service"]
alert_text: "timestamp: {0}\n url: {1}\n total: {2}\n total_threshold: {3}"
alert_text_type: alert_text_only
alert_text_args: ["@timestamp", "url", "total", "total_threshold"]

※登録されているURLごとに、service指定文字列と合致かつtotal数値以上のデータが直近1時間で1件以上検索にヒットしたら発火する、という条件

小林：えーと、ではこのsakimoriプロジェクトやってみてどうでした？

後藤：ツールはともかく、はじめてESを触る機会でしたので、クエリ様式等が知れて良かったと思います。

小林：普段の業務だけだとなかなか触れる機会なかったりしますからね

後藤：はい。AWS関連も業務で使わないサービスを弄れたので、とても良い機会になったと思います。

小林：ではあとsakimoriでやりたいことってあります？？

後藤：今回ツールで作った通知機能ですが、もっと使い勝手のよいアプリ開発できれば...と思います。

小林：具体的にいうと...？

後藤：sakimoriでは監視対象のURLを登録時点で速度のしきい値も設定できるのですが、現状その値をそのまま判定値として利用できていないので不完全燃焼している感があります。

小林：まあ、今設定ファイルにべた書きしているような状態ですからね。せっかくなんでできるようにしたい気持ちはありますねー

後藤：そうですね。

小林：第二フェーズですね。

後藤：乞うご期待ですね

小林：ありがとうございました！

後藤：こちらこそ、ありがとうございました！

===============================================================================

Len

続きまして、ベトナムからの刺客として送り込まれたlen。
日本語はまだカタコトですが、なにげに冗談もかましてきます。

最近は日本語わからないフリをして、ちょっとおもしろいことを言うキャラを作ろうとしているんじゃないかと思ってます。

---

小林：というわけで、まずは自己紹介をお願いします。

len： ferret One部署のlenデス。developerとしてハタライてマス
コレだけでヨイですか？

小林：笑

len：w

小林：ベトナムからきたっていうのは、いれてもいいんじゃないかな。
まあ、とりあえず大丈夫っす。普通な感じで。

len：ソウデスネw

小林：じゃ、次に...今回sakimoriをつくるにあたって、どの辺を担当しました？

len：ボクの方でタントウしたブブンはPageヒョウジソクドケイソクとケイソクしたケッカをElasitcSearchに送りマス

小林：AWS Lambdaで実装をしてもらった、今回の速度計測のメインとなるところだよね。
何か苦労したところとか、ある？

len：ソウデスネ。
ジッソウにはserverless-chrome（https://github.com/adieuadieu/serverless-chrome）をツカイマシタ。
Lambdaでchrome-headlessをツカウのサンコウシリョウがおおくないので、モンダイがハッセイするトキ、時間がカカリマス。
Lambdaのdebuggerもつかいにくくて...

小林：Lambdaのdebugは大変だよね...

len：これ以外モンダイがありませんかな

小林：（ありませんかな...？）問題の内容をもう少し具体的に言えるかな？

len：ジッソウしたとき、コケるバグあります。

たくさんURLをケイソクするとき、いくつかURLがケイソクできなかったというゲンショウがオコリマシタ。200ぐらい。

Googleでチョウサしたとき、同じモンダイをミツケなかった...

Lambdaのドウサをしらべると、多分ゲンインはLambda functionデータをサイリヨウ（※）です。
※https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/

小林：Lambda functionデータの再利用...？

len：コードをもっとヨムと、LambdaでURLケイソクロジックは、
chrome server up => chrome tab open => url navigate => chrome tab close

立ち上がっているchromeサーバはlambda functionをジッコウカンリョウするトキ、chromeサーバをカイホウしないので、ツギのlambda functionをジッコウすると、コケるバグがハッセイします。

小林：へー、Lambdaを連続して実行するとこけちゃんだね。これはどう解決したんだっけ？？

len：ケイソクカンリョウしてから、chromeをkillします。以下のworkflowになりマス。
chrome server up => chrome tab open => url navigate => chrome tab close　=> chrome server kill

killのメソッドがありますので、カンリョウジにchrome.kill()をジッコウしマス。

const chrome = childProcess.spawn(
    path.resolve('./headless-chrome/headless_shell'),
    [
      '--disable-gpu',
      '--no-sandbox',
      '--homedir=/tmp',
      '--single-process',
      '--data-path=/tmp/data-path',
      '--disk-cache-dir=/tmp/cache-dir',
      '--remote-debugging-port=9222',
    ],
    {
      cwd: os.tmpdir(),
      shell: true,
    }
  )

waitUntilChromeIsReady()
    .then(() =>
      cdp()
        .then((client) => {

　　　　　　/* いろんな処理 */

          // chromeのページロードイベントを発火
          Page.loadEventFired(() => {
            doneLoading = true
            console.timeEnd('loadtimer');
            let end = Date.now();
            page_load_time = ((end - begin) / 1000).toFixed(2);
            let response_time = 0;

            //ElasticSearchにPostするようにJSONつくる
            let log = '{"service":"' + service +
              '","url":"' + url + '","response":"' + response_time +
              '","total":"' + page_load_time +
              '","response_threshold":"' + response_threshold +
              '","total_threshold":"' + total_threshold +
              '","@timestamp":"' + new Date().toJSON() + '"}'

            //ElasticSearchにPostするメソッド
            postDocumentToES(log);
          })

          Promise.all([Network.enable(), Page.enable()])
            .then(() => {
              console.time('loadtimer');
              begin = Date.now();
              Page.navigate({ url })}
              )
            .then(() => waitUntilPageIsLoaded())
            .then(() => {
              client.close()

              chrome.kill() // ←これが重要

              callback(null, {
                url,
                requestsMade,
              })
            })
        })
        .catch((error) => {
          throw new Error(error)
        }))
    .catch((error) => {
      chrome.kill()

      callback(null, {
        message: 'There was an issue connecting to Chrome',
        error,
      })
    })

（コードを一部抜粋、コピペしても動きません...雰囲気だけ掴んでいただけると....）

小林：あ、なるほどー。要はkillすることっていうのを知らないとハマるところですね。

len：今ノコリのモンダイは、もっとクワしくケイソクケッカをシリタイなら、タイオウはちょっとムズカシイ。
ハンドルできるイベントはdomContentEventFiredとloadEventFiredしかないので。

小林：そうねー、当面はその2つの計測結果でとりあえずいいかな...
こういった今までと違うチームと一緒に仕事をしたのはどうだった？？

len：ウレシイです。
アタラしいチームとイッショにシゴトをして、いろんなことベンキョウになり。
シゴトがススメナイとき、ミンナさんはテイアンをオシエテくれて、カンシャしています。

小林：thanks!

lenはferretOneチームでずっと開発をしているので、なかなか他のチームとの関わり合いがないから、こういったほかメンバーと一緒に仕事ができる機会っていいよね。うちらも一緒に仕事をすることで新しい刺激をもらえることもできるし。

len：ソウデスネ

小林：最後にこの先sakimoriでやりたいことはある？

len：まずはもっとクワしくケイソクケッカをケイソクしたいですが、まだタイオウできませんでした。
ツギは今ec2のコストがかかっていますので、ec2をツカワずホウホウをシラベてみたい。

小林：ok、ありがとう！

len：アリガトウゴザイマス！

========================================================================

佐々木亮祐

続きまして、ベーシックに空前のラップブームを引き起こした「SASAKI」
今も夜な夜なクラブでリリックを変幻自在のフロウにのせてアンサーにライムをきかせて、やばいパンチラインをカマせているらしい。（適当）

そんなSASAKIの紹介文はこちらにあります。
マーチ文系がWebエンジニアになり数字にもコミットするようになった理由

※今回の記事でラップは全く関係ありません

---

小林：では、軽く自己紹介をお願いします！

佐々木：佐々木亮祐と言います。ベーシックには2015年10月頃に入社して、EC->メディアサイトの開発担当してきました。

小林：基本的に歴史が長いサイトを担当することが多いですねー

佐々木：そうですねｗフレームワークが使われていないサイトもたまにいじったりしています

小林：ああああ、負債が....
この辺の話をし始めると、話が進まなくなってしまいそうなので...本題の方に
※負債のお話はこちら（技術的負債に立ち向かうための心構え）

sakimoriではどの辺を担当しましたか？

佐々木：sakimoriでは速度計測対象のURLをyamlファイルでS3上で管理しています。そのURLを1時間に1度のバッチで拾って、実際に計測するためのLambda関数にデータを渡すハンドリング部分を担当しました。

（このec2インスタンス上のプログラムの話）

小林：Lambdaへのアダプターとかブリッジみたいな感じ？ですか。
ここは本来であれば最初は作る予定ではなかったところでしたね。

佐々木：そうですね。当初はLambdaだけで完結する想定だったんですが、URLが増えてくるとLambdaの実行時間の制限にひっかかってしまうことが判明しました。

なので、1URL毎Lambdaに渡して、実行時間の制限にひっかからないよう、ハンドリングする部分として作成しました

小林：lambdaの実行時間の制限、3分くらいだっけ？

佐々木：確か300秒（※）ですね。なので5分くらい。
（※AWS Lambda の制限）

小林：5分か、いずれにしても意外と短い。で、このLambdaに値を渡す部分を作成したと。
今回GO言語つかったと思うけど、GOにした理由ってあります？？

佐々木：GOにした理由は、単純に使ってみたかったからという好奇心が大きいです。

個人的に少し勉強していたんですが、社内の実務で採用しているチームもまだ少ないんですよね。他社は使用しているところも増えてきているので、この機会に知見を得ておきたいという目的もありました。

小林：非常に前向きな姿勢。すばらしいですね。見習いたいです。最高です。

佐々木：ありがとうございます！

小林：普段のうちのサービスだとphpとかrubyのスクリプト言語なので、GO言語となるとまただいぶ様子が変わるので、最初はだいぶとっつきずらそうなイメージあるんですが、どうでした？

佐々木：最初はやっぱりとっつきづらかったです。静的型付け言語をちゃんと勉強するのは初めてだったので構造体など理解するのに時間がかかりました

ただ慣れてくると、シンプルに記述できるなという利点を感じました。

func getJSONData(objKey string) interface{} {
        sess := session.Must(session.NewSession())
        svc := s3.New(sess, &aws.Config{
                Credentials: credentials.NewStaticCredentials(os.Getenv("ACCESS_KEY"), os.Getenv("SECRET_KEY"), ""),
                Region:      aws.String(os.Getenv("AWS_REGION")),
        })

        params := &s3.GetObjectInput{
                Bucket: aws.String(os.Getenv("S3_BUCKET")),
                Key:    aws.String(objKey),
        }
        resp, err := svc.GetObject(params)

        if err != nil {
                panic(err)
        }

        buf := bytes.NewBuffer(nil)
        defer resp.Body.Close()
        if _, err := io.Copy(buf, resp.Body); err != nil {
                panic(err)
        }

        var jsonData interface{}
        err = json.Unmarshal(buf.Bytes(), &jsonData)
        if err != nil {
                panic(err)
        }

        return jsonData
}

（S3に置かれているyamlファイルを取ってきてゴニョゴニョするところ）

佐々木：コンパイルするときに不要なライブラリ等が含まれないよう、エディタがよしなにライブラリのインポートの記述を追記/削除してくれたり、エラーを吐き出してくれたり、最終的にはスクリプト言語にはない楽さを感じましたね。

小林：エディタで不要なライブラリの削除とかいいですね。GOはもっといろんなプロジェクトで今後取り入れていきたい気持ちがあります。
あと、実際sakimoriプロジェクトをやってみてどうでした？

佐々木：単純におもしろかったです。ただ、技術選定で普段使ってないような技術を選んだことで、それなりに学習コストはかかったなぁと...
各担当との繋ぎこみも、全体をある程度理解できてないと、コミュニケーションを取る回数も増えて難しかったなと感じました

小林：新しい技術を使えるところは、こういう独立したプロジェクトならではですね。
普段はどうしてもサービスの運用・保守なので、つくられた技術基盤の上で仕事をすることになるので。

佐々木：そうですね。なので、今回は非常にいい経験になったと思います！

小林：いやー、そう言ってもらえるとやってよかったって思います。
では最後に今後のsakimoriプロジェクトの予定なんかを聞いてもよろしいですか？

佐々木：ハンドリング部分に関する話になるんですが、エラー処理が作り込めていないので、そこをしっかりしておきたいです。
それとせっかくGOを採用したのにgoroutine使ってないので、goroutine使って並行処理させてみたいなと

小林：エラー処理ってURLにアクセスできなくて計測ができなかった場合とか、そういうやつ？

佐々木：いや、yamlファイルに不備があった場合とかですね。URLが空だった場合など

小林：あー、なるほど

佐々木：エラーがあったらpanicっていうGOのメソッドで処理が止まるような状態になっています。。。

小林：せっかくなんで運用回り始めたらその辺は手をつけていきたいですねー
というわけでありがとうございました！

佐々木：ありがとうございました！

===============================================================================

唐澤貴大

最後に、二年目エンジニアの唐澤。
入社時の挨拶で「俺はCTOになる！」と宣言をするだけのことはあり、その圧倒的なパフォーマンスで見事昨年のルーキー賞をとった期待のエンジニア。
誰に言われるまでもなく勝手に（主体的に）いろんなものを試しては、導入をしていってます。

---

小林：それでは、よろしくー。

唐澤：ライフメディア事業部担当の唐澤です。
16卒の新卒として入社して、エンジニア2年目です。

小林：2年目にしては、まあ結構いろいろやっているよねー

唐澤：そうなんですよねー、いろんな経験をさせてもらってます

小林：webpackとかスタイルガイドとか、今までやってなかったところに手をいれつつあって、大変助かります。
※唐沢のwebpackの記事：http://qiita.com/tkhr/items/4b877961b5cee4e2b269

唐澤：いえ、とんでもないです笑

小林：で、sakimoriの方ですが、今回はどの辺を担当しました？

唐澤：sakimoriの方では、管理画面の部分を担当しました。
監視対象にするURLを受け付けるUIの部分です

小林：結構面白い構成でつくってたよね

（最初の構成図でいうところの右上の部分）

唐澤：フロント部分を、Vue.jsとvue-routerを使ったSPAで作りました。
バックエンドはAWSのlambdaを使ってAPIを立てました、いわゆるサーバレスな構成になってます。

小林：SPAでサーバレスなアプリケーション...憧れますね。たぶんVue.jsをつかって本格的にアプリケーションつくるの初めてかなって思ったけど、実際触ってみてどうだった？

唐澤：Vue.jsがデータとUIの関連付けをよしなにしてくれるので、コード量が少なくてとても楽でしたjQueryだったらゴリゴリDOMをいじらなきゃで、ただただ疲れてた気がします笑

小林：たしかにあの機能でjQueryをつかってDOMゴリゴリいじるだと、結構つらそう。
規模感といい、実装する機能といい、導入するにはちょうどいい感じでしたね。既存プロジェクトに導入するとなると、いろいろ面倒なことがあるので。

（UIはちょっとあっさりだけど、SPAで実現してます、URLの登録はyaml形式）

唐澤：そうですね。まっさらな状態で触れたのはよかったです。
ただやっぱりVue.jsの使い方で詰まることが時々あったのでその時は大変でしたね。
社内で浸透している技術じゃないし、webでもまだ情報は少なかったので。

小林：なんか社内に浸透してないこと、やるの多いよねw

唐澤：確かにそうですね笑
むしろそんなことしかやってないんじゃないかと笑

小林：そうだね

唐澤：じょじょに浸透させていけたらいいなと思っております

小林：なんとなく回答でてきちゃっているけど、このsakimoriプロジェクトをやってみてどうでした？？

唐澤：sakimoriは仕様の縛りが多くなかったので、普段ではその点から手を出しにくい技術を扱うことができて楽しかったです。
技術の記事を読んでもなんとなく知ってる、で終わりがちですが、実際に触ってみるとわかることがやっぱり違いました。こういう実感を持っていると事業の方にフィードバックしやすく、した時にはよりよく活かせる気がしました。

小林：素晴らしい回答！ありがとうございます。ブログにしがいがあるコメントです。

唐澤：ありがとうございます。
また新しいものに手を出しやすくなりました。

小林：こういうサブプロジェクトみたいのを定期的に用意して、各々が気になっている技術やツールを導入してやっていく、みたいなのをもっとやっていきたいなーって思ってます

唐澤：とてもLGTM（※）です。
ただ今回やってみて、事業部のタスクとの調整をうまくやっておかないとヤバそう感だけ感じました
（※Look Good To Meの略、要はいいね！みたいな感じ）

小林：いわゆる通常業務との兼ね合いっていうやつですね

唐澤：そこもうまくできるようになれば、そっちの成長もできて一石二鳥なのかなと思いました

小林：みんなハッピーで最高！！

唐澤：いいことしかないですね

小林：最後にこの先sakimoriでやりたいことありますか？

唐澤：計測するURLをsakimoriが探して欲しいですね。
URLを手動で登録するというだるい仕様なので、そこを改善できるとより簡単に計測できていいのかなと思いました

小林：おー、それはいいですね。sitemap.xmlとか使えばいけそうか、いうのは簡単だけど

唐澤：そうですね。それを想像してました、最悪クロールしてもいいですが笑
sitemap.xmlのスクレイピングはやったことないのでやってみたい気持ちもありますので。
普通にsitemapを作る時の参考にならないかなと思ったりしました。