Engineer Blog

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

プレイドでエンジニアをしている田宮です。今回は Cloud Logging と BigQuery 用いて開発した 監査ログ の紹介をします。

マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装 - 収集編

<h1>はじめに</h1>
<p>こんにちはプレイドの<a href="https://cxclip.karte.io/products/info/message-beta/">KARTE Message</a>チームでエンジニアをしている<a href="https://x.com/prooooograming">土谷</a>です。</p>
<p>今回は大量メール配信を実現するためにKARTE Messageで取っている仕組みを紹介していきます。</p>
<h1>KARTE Messageについて</h1>
<p>本題に入る前に、まずKARTE Messageについて説明します。</p>
<p>KARTE Messageはマルチチャネル(Mail/アプリPush/LINE *)での大量配信を行えるMAツールとなっており、主に以下の機能を備えています。</p>
<ul>
<li>配信の管理
<ul>
<li>配信対象抽出の設定</li>
<li>配信コンテンツの設定・コンテンツへの埋め込み</li>
<li>配信速度・頻度の管理</li>
</ul>
</li>
<li>配信対象の管理
<ul>
<li>誰に配信するのかを取り扱うための配信対象を管理するためのリスト機能</li>
<li>リストに対するフィルタリング機能</li>
<li>リスト同士を組み合わせて配信対象を絞り込む機能</li>
</ul>
</li>
<li>配信コンテンツの管理
<ul>
<li>配信コンテンツをテンプレートとして管理</li>
</ul>
</li>
</ul>
<p>これらの機能に加えてKARTEの特有の機能を利用した配信対象の抽出などもできるようになっています。</p>
<p>* LINEとの連携機能は現状β版として提供しています。</p>
<h1>このブログで出てくる用語</h1>
<p>まずメール配信においてよく使われる用語の説明をします。理解している人は読み飛ばしてください。</p>
<p><code>Eメール</code> : 一般的にEメールはマーケティングメールとトランザクションメールに大別できます。</p>
<p><code>マーケティングメール</code> : 受信者がアクションをしていなくても送信者側が能動的に送信するメールです。メルマガ配信やクーポンメールなど。</p>
<p><code>トランザクションメール</code> :  受信者が何かしらのアクションを起こした時に受等的に送信するメールです。ログインメールやパスワードリセットメールなど。</p>
<p><code>メールバウンス</code> : 送信したメールが何らかの理由で相手のメールサーバーに拒否されて、送信者に戻ることです。メールバウンスはハードバウンスとソフトバウンスに大別できます。</p>
<p><code>ハードバウンス</code> : メールの拒否理由が恒久的な問題の場合のメールバウンスのことです。メールアドレスが存在しないなど。</p>
<p><code>ソフトバウンス</code> : メールの拒否理由が一時的な問題の場合のメールバウンスのことです。受信者のメールボックスがいっぱいなど。</p>
<p><code>IP/ドメインレビュテーション</code> : メール送信時に利用するサーバーのIPアドレスやFromドメインに対して付けられる評価をレピュテーションと呼びます。スパムメールのようなメールをたくさん配信しているとレピュテーションが下がり、メールプロバイダー(GmailやYahoo!メールなど)から受信を拒否される場合があります。レピュテーションの管理はメールプロバイダーがやっていたり、第三者機関がやっていたり、さまざまなパターンがあります。</p>
<p><code>SPF</code> : SPFレコードというDNSレコードを利用して、送信されたメールの送信元IPを確認することで送信者がなりすましをしていないかを確認する仕組みです。</p>
<p><code>DKIM</code> : DKIMレコードというDNSレコードを利用して、送信されたメールの内容が第三者に改竄されていないことを確認する仕組みです。</p>
<p><code>DMARC</code> : SPF/DKIMの確認に引っかかった時に、どのように対応すべきかを送信元のサーバーが表明しておく仕組みです。</p>
<h1>大量メール配信の運用における課題</h1>
<p>マーケティングメールが大量に送信されている現在の環境では、同様に大量のスパムメールも送信されています。メールプロバイダーはメールの大量送信に対して、スパムメールかどうか・送信者がスパマーではないかという判定を厳しく行なっています。</p>
<p>そのためマーケティングメールをエンドユーザーに届けるためには、送信したメールがスパムメールでないことを証明する必要があります。</p>
<p>メールプロバイダーは送信されたメールがスパムメールでないことを確認するために、以下のような項目を確認しています。</p>
<ul>
<li>SPF/DKIM/DMARCの設定確認
<ul>
<li>これらのDNSレコードの設定がされていないとスパムメールと判断される場合があります。</li>
</ul>
</li>
<li>IPレピュテーション・ドメインレピュテーションの確認
<ul>
<li>送信元のIPレピュテーションやドメインレピュテーションが低いと、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メールコンテンツの正当性の確認
<ul>
<li>メール内のコンテンツにhttpのセキュアではないリンクがあったり、不審なスクリプトなどが含まれていたりすると、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メール配信量の急増の検知
<ul>
<li>特定IPからのメールの配信量が急増すると、スパムメールと判断される場合があります。</li>
</ul>
</li>
</ul>
<p>上記のようなスパムメールかどうかの大量のチェックが各メールプロバイダーごとで設定されているため、マーケティングメールをエンドユーザーに届けることが簡単ではないことが課題となっています。</p>
<h1>KARTE Messageにおける大量のメールをエンドユーザーに届けるための仕組み</h1>
<p>ここからは、KARTE Messageで行なっているマーケティングメールを正常にエンドユーザーに届けるための仕組みを紹介します。</p>
<h2>AWS SESを利用したマルチテナント構成</h2>
<p>大量メール配信においてIPレピュテーションを高く保つことは、上述した通り非常に重要です。これを実現するには、スパムメールと判定される可能性のある質の低いメールの送信を極力避け、メールプロバイダーに確実に受信される質の高いメールを送信する必要があります。</p>
<p>そのため、質の高いメールの配信量を最大限に増やすことが有効なアプローチの一つです。これにより、仮に少量の質の低いメールが送信されたとしても、全体におけるその割合を低く抑えることができ、結果としてIPレピュテーションを高く維持することにつながります。</p>
<p><img src="https://ik.imagekit.io/plaid/913abcd7-570a-481a-bc9b-b9cb0c8ff3e4/blog_image1.png" alt="blog_image1.png"></p>
<p>KARTE Messageでは、それを実現する仕組みとしてマルチテナントなメール配信を行なっており、KARTE Messageが所有しているIPアドレスをクライアントごとに固定せず、全てのIPに均等に振り分けて送信しています。</p>
<p><img src="https://ik.imagekit.io/plaid/c3e46daa-6c2d-4f66-b27e-b7a349813334/blog_image2.png" alt="blog_image2.png"></p>
<p>結果として冒頭で述べた通り、KARTE Messageを利用しているクライアント全配信量が母数となるので、特定のクライアントで質の低いメールが多少送信されても影響を小さくすることができます。</p>
<p>また、複数のクライアントの配信をKARTE MessageのIPで送信しているため、配信はほぼ24時間常に行われています。そのため、1クライアントが急な大量配信をしたとしてもKARTE Message全体では配信量の急増にはなりにくく、メール配信量の急増によるIPレピュテーションの低下を防ぐことができ、送信されたメールもスパムメールと判定されづらくなります。</p>
<p>こういったIPレピュテーションの運用は、1クライアントでやろうとすると配信量や配信時間の問題で運用が難しくなる場合があります。KARTE Messageではマルチテナント配信にすることで、その運用負荷をクライアントから取り除いています。</p>
<h2>まとめ</h2>
<p>マルチテナント配信以外にも、KARTE Messageではメール配信の細かなモニタリングを行ったり、SPF/DKIM/DMARCの設定の補助機能なども提供することで、なるべくマーケティングメールの運用負荷を下げるような機能提供を行なっています。</p>
<p>KARTE Messageでは、メールという長年コミュニケーションツールとして中心になっている技術であるからこそ難しくなっている部分を管理することで、価値を届けるプロダクトを作っています。</p>
<p>興味がある方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。お待ちしております！</p>


KARTE MessageというMAツールでメールの大量配信を安定的に行うためのシステム設計やIP運用の考え方などを説明

KARTE Messageで採用している大量配信を実現するためのアーキテクチャ

KARTE Messageの大量メール配信を支える技術

こんにちは！10月初旬から4月末までの7ヶ月間、ソフトウェア開発のインターンとしてプレイドで働いていた[上野海吏](https://x.com/kairi_noel)(@kairi_noel)です。

プレイドで7ヶ月間の開発インターンで体験したことと得られた学び

AIエージェントによるセキュリティレビューの試みを紹介します。

AIエージェントによるセキュリティレビューことはじめ

この記事では、MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーションシステムについて解説します。

MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーション

<p>ごきげんよう。プレイドの@tik-sonと申します。<br>
みなさんはクラウドプラットフォームを利用していますか？</p>
<p>弊社の<a href="https://karte.io">KARTE</a>は</p>
<ul>
<li>秒間3000イベントをリアルタイムで解析</li>
<li>累計解析ユーザがリリースから2年で12.5億<br>
https://karte.io/infographic/2017.html</li>
</ul>
<p>という規模のサービスになっています。<br>
そこで動いているインフラもそれなりに大規模になっており、インフラをいかに改善していくかが事業進捗に大きく関わってきます。</p>
<p>そのインフラを改善する試みとして半年ぐらい前から、<a href="https://aws.amazon.com">AWS</a>と<a href="https://cloud.google.com/">GCP</a>の２つのクラウドプラットフォームを組み合わせ、マルチクラウドインフラとして利用しています。<br>
<a href="http://tech.plaid.co.jp/">PLAID Enginner Blog</a>では複数回に渡ってマルチクラウドインフラを作る上で試行錯誤したポイントなどを紹介していこうと思います。<br>
今回は初回ということで概要部分について記載し、次回以降のエントリーで深掘りをしていきます。<br>
興味を持たれた方は本ブログをブックマーク等をしていただけば幸いです。</p>
<h1>目次</h1>
<ul>
<li>マルチクラウドインフラとは？</li>
<li>なぜマルチクラウドインフラを作るのか？</li>
<li>マルチクラウドインフラの構成</li>
<li>マルチクラウドインフラへの移行手順</li>
<li>まとめ</li>
<li>最後に</li>
</ul>
<h1>マルチクラウドインフラとは？</h1>
<p>私達がお話するマルチクラウドインフラとは、<br>
複数のクラウドプラットフォームを組み合わせ、それぞれのサーバが相互通信でき、あたかも１つのプラットフォームのように稼働させることができるインフラのことです。<br>
イメージにすると以下の図のようになります。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/77d17f92-74f7-4789-8e80-a0fd89074a1b/1.png" /></div>
<h1>なぜマルチクラウドインフラを作るのか？</h1>
<h2>可用性の向上</h2>
<p>各クラウドプラットフォームではそれぞれのサービスごとにSLAが定義されていますが、100%の稼働を保証するものではありません。<br>
<a href="https://cloudharmony.com/">CloudHarmony</a>というサービスで過去の稼働率を確認することが出来るのですが、例えば、<a href="https://aws.amazon.com/ec2">EC2</a>、<a href="https://cloud.google.com/compute/">GCE</a>においてもDowntimeはそこそこ発生しているようです。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/9361312a-04fd-445e-9c56-3a01eb3aa8e3/2.png" /></div>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/b3efb0ce-00bb-4ac6-afd9-a4ea45e23788/2.5.png" /></div>
<p>また、各クラウドプラットフォーム内にてMultiAZやMultiRegionの構成を取ることで可用性を高めることは可能ですが、クラウドプラットフォームの共通部分で問題が起きてしまうと、MultiAZやMultiRegion構成を取っていてもサービスダウンを避けることは出来ません。<br>
実際、GCPで<a href="https://status.cloud.google.com/incident/compute/16020#5177473553661952">LoadBalancerがリクエストをサーバにフォワード出来ず、502のreponseを返すという障害</a>が発生したこともあります。<br>
複数の異なるクラウドプラットフォームで稼働させることは、単一クラウドプラットフォームの障害の影響を抑えることができ、可用性を高めることができます。</p>
<h2>パフォーマンスの向上</h2>
<p><a href="https://aws.amazon.com/products/">AWS</a>、<a href="https://cloud.google.com/products/">GCP</a>共に様々な特色のサービスを提供しています。<br>
それぞれのサービスには得意、不得意な部分があり、適材適所で使うことでアプリケーションのパフォーマンスを向上させることができます。<br>
KARTEにおいても処理の一部をGCPの<a href="https://cloud.google.com/bigtable/">Cloud Bigtable</a>に置き換えたことにより、パフォーマンスが大きく改善しました。</p>
<p>ただ、「AWSのEC2からGCPのCloud Bigtableを利用する」といったようなクラウドプラットフォームをまたいでサービスを利用する際は、以下の要素がパフォーマンスを悪化させることがあり、無視することはできません。</p>
<ul>
<li>同じクラウドプラットフォーム内からの通信に比べて Latencyが大きくなる</li>
<li>各クラウドプラットフォーム管理外のネットワークが間に挟まってしまうので、問題が起きやすくなる</li>
</ul>
<p>当然ですが、Cloud BigtableのSLAにも <code>(c) errors: (i) caused by factors outside of Google's reasonable control; </code> というようにGoogleのコントロール外の部分でのエラーはSLA適用外と明記されています。<br>
https://cloud.google.com/bigtable/sla</p>
<p>サーバを手軽にそれぞれのプラットフォームに配置できる状態を作り、利用サービスの近くにサーバを配置させることで、各サービスの恩恵をより多く受け、アプリケーションのパフォーマンスを向上させることができます。</p>
<h2>コストの低減</h2>
<p>各クラウドプラットフォームのサービスを適材適所に利用するだけでコストの低減が期待できるように思えますが、何も考えずに他クラウドプラットフォームのサービスを使用してしまうと、パフォーマンスは向上はする一方で、膨大なコストがかかってしまうことがあります。<br>
Cloud Bigtableを例に考えてみます。<br>
Cloud BigtableはGCPのサービスですが、もちろんAWSからも利用することができます。しかしAWS側から利用するとなると、インターネット経由でCloud Bigtableと通信することになるので、以下の図のように <strong>データ転送コストが有料</strong>になってしまいます。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/2a5a6ab0-6f8d-4e7a-8864-0ad5c52b6392/3.png" /></div>
<ul>
<li>EC2でのCloud Bigtableからのread(①)はCloud BigtableのInternet EgressとしてGCP側で課金</li>
<li>EC2からCloud Bigtableへのwrite(②)はEC2のInternet EgressとしてAWS側で課金</li>
<li>Cloud Bigtableと同RegionのGCEであればread(③)、write(④)共に無料</li>
</ul>
<p>少量のデータを扱う際には対して気にならないかもしれませんが、大量のデータを扱うサービスは注意が必要です。請求を見て寿命が縮むことになります。<br>
実際に私達もCloud Bigtableの請求を見て寿命が縮んだ経験があります。<br>
私達がCloud Bigtableを導入しようと検証していた際にはインターネット経由のデータ転送コストが <strong>無料</strong> だったのですが、あるタイミングから有料に変更になり、気がついた時には <strong>サービス使用量全体の約30%</strong> をCloud Bigtableデータ転送コストが占めていたこともありました。。コストのアラートは適切に設定しておくことをおすすめします。<br>
パフォーマンスの話と同様にコストにおいても、サーバを手軽にそれぞれのプラットフォームに配置できる状態を作り、利用サービスの近くにサーバを配置させることは重要です。</p>
<h2>そこに新しくて良い技術があったから</h2>
<p>新しいサービス/技術はどんどん触りたいし、良いものはどんどん導入したいというモチベーションが煮えたぎっていました。**「そこに新しくて良い技術があったから」**というのはプレイドのエンジニア文化として根付いています。</p>
<h1>マルチクラウドインフラの構成</h1>
<p>上記のモチベーションを元に作ってみたマルチクラウドインフラの構成概要図を掲載します。<br>
詳細は別のエントリーでお話することになると思いますが、ポイントとしては以下の通りです。</p>
<ul>
<li>AWS、GCPのPrivateNetworkをVPNで接続する。</li>
<li>Cloud Bigtableや<a href="https://cloud.google.com/bigquery/">Bigquery</a>などGCPのサービスを多く使うサーバは主にGCPで、<a href="https://aws.amazon.com/jp/dynamodb/">DynamoDB</a>などAWSのサービスを多く使うサーバは主にAWSで稼働させる。</li>
<li>特定のクラウドプラットフォームで何か問題があっても片方のクラウドプラットフォームで動くようにする。</li>
</ul>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/11449304-378e-4495-b7d0-9e0a5a173e88/4.png" /></div>
<p>また、運用周りのツール/サービスは基本的マルチクラウド対応しているものを利用しています。以下に一部を記載します。</p>
<table>
<tr>
<th>用途</th>
<th>ツール名</th>
</tr>
<tr>
<td>インフラの構成管理</td>
<td><a href="https://www.terraform.io/">Terraform</a></td>
</tr>
<tr>
<td>マシンイメージの作成</td>
<td><a href="https://www.packer.io/">Packer</a></td>
</tr>
<tr>
<td>マシンイメージのテスト</td>
<td><a href="http://serverspec.org/">Serverspec</a></td>
</tr>
<tr>
<td>メトリックの監視/アラート</td>
<td><a href="https://www.datadoghq.com/">Datadog</a></td>
</tr>
</table>
<h1>マルチクラウドインフラへの移行手順</h1>
<p>KARTEは元々はAWS上でのみで稼働していたので、既存のAWSで作っていた仕組みをベースに以下のステップでマルチクラウドインフラへと移行していきました。<br>
ちなみに移行作業はKARTE利用ユーザに影響が出ないよう、サービス停止を伴うメンテナンス作業は実施せずに進めていきました。<br>
本エントリーでは概要を説明するにとどまりますが、各ステップで試行錯誤したポイントについては次回以降のエントリーで記載していこうと考えています。</p>
<ol>
<li>AWSとGCPをVPNで接続する</li>
<li>GCPでAWSと同じようにリソースを立てれるようにする</li>
<li>GCPでリソースを一部稼働させパフォーマンスを計測する</li>
<li>計測したパフォーマンスを元にマルチクラウドを意識した構成/コードに修正する</li>
<li>修正完了後、GCPの割合を徐々に増やしていく</li>
<li>運用を整える</li>
</ol>
<p>*3,4,5のステップは一度ではなく何度も繰り返し、構成/コードを洗練させていきました。</p>
<h1>まとめ</h1>
<h2>良かった点</h2>
<h3>可用性の向上</h3>
<p>前述したようにGCPで<a href="https://status.cloud.google.com/incident/compute/16020#5177473553661952">LoadBalancerがリクエストをサーバにフォワード出来ず、502のreponseを返すという障害</a>が発生したのですが、AWS/GCPのマルチクラウドインフラを作った後だったため、AWSに寄せて稼働させることができ、その影響を抑えることができました。</p>
<h3>パフォーマンスの向上</h3>
<p>Cloud Bigtableなど適材適所にサービスを導入し、GCPとAWSで双方で問題なく動かせるよう構成/コードを見直した結果、マルチクラウドインフラ構築前に比べ、パフォーマンスが格段に向上しました。<br>
またAWS/GCPそれぞれのサービスを導入しやすくなり、マルチクラウドインフラ構築後においても、日々パフォーマンスは改善しています。</p>
<h3>コストが 約40%低減</h3>
<p>データ転送コストを抑えつつ、パフォーマンスを向上させた結果、コストが約40%低減しました。</p>
<h3>エンジニアとしてのレベルアップ</h3>
<p>まとまった情報があまりない取り組みだったので、自分で考え抜く力、もがいて結果を出すという力が向上しました。</p>
<h2>意識しておかなければいけない点</h2>
<h3>利用サービスが増えることによって、学習コストも増える</h3>
<p>プレイドでは「新しいサービス/技術はどんどん触って、いいものはどんどん導入しようという」絶対的な文化があるので本項目は基本的には歓迎なのですが、企業文化やステージによっては考える必要があると思います。</p>
<h3>移行コストについて</h3>
<p>やってみないと分からない部分はありますが、移行に伴う以下のコストをある程度見積もっておくことは重要です。</p>
<ul>
<li>インフラのコスト：検証時、移行作業時にリソースを追加で立てる必要があるので</li>
<li>人のコスト：インフラの改修だけではなく、サービスのアーキテクチャを把握した上でコードの改修等の作業も必要になってくると思うので、それなりに覚悟は必要になります。折れない心が大切でした。プレイドではインフラ、アプリケーション、opsまで一通り修正をエンジニア2.5人×3ヶ月で実施しました</li>
</ul>
<h1>最後に</h1>
<p>私達のマルチクラウドインフラはまだ始まったばかりで、随時、拡張/改善していきたいと思っています。<br>
プレイドでは、マルチクラウドインフラをもっと成長させたい、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>
<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>


AWSとGCPでマルチクラウドインフラを始めた話。複数回連載予定の第一回です！

AWSとGCPでマルチクラウドインフラを構築した話とそのポイント| PLAID engineer blog

AWSとGCPでマルチクラウドインフラを構築した話とそのポイント

<p>こんにちは、プレイドの@wikrshです。</p>
<p>弊社の<a href="https://karte.io/">KARTE</a> では属性データやサイト上での行動情報など様々なデータを元に来訪したユーザーの状況をリアルタイムに可視化しており、どのような情報の見せ方をすればよりユーザーへの理解を深められるのか、社内では日々議論・改良を重ねています。</p>
<p>今回は現在KARTEで行っているものとは異なる表現を実験してみたい + アニメーションを作るのが面白そうという動機で、「各ユーザーがサイト内の各ページを遷移している様子」の可視化に取り組んでみましたので紹介いたします。</p>
<h1>作成するアニメーションのイメージ</h1>
<p>各ページをノードとして表し、ユーザーを表すノードが各ページのノードを移っていく形で表現することを考えました。</p>
<p><code>/page1</code>を見ていたあるユーザーが<code>/page2</code>にアクセスした場合は、<code>/page1</code>を表すノードから<code>/page2</code>を表すノードへユーザーを表すノードが移動するイメージです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/890d6805-9a38-4b41-b9b8-4fd9fc66baeb/blog.001.jpeg" alt=""></p>
<p>このノードを各ページ・各ユーザーについて表示して、時刻を変化させる（再生する）ことで、各時刻でユーザーがどのように移動しているかを可視化することが今回の目標です。<br>
実装にはチュートリアルや例が豊富でありアニメーションも容易な <a href="https://d3js.org/">D3.js</a> を使用し、ブラウザ上にSVGで表示を行うことにしました。</p>
<h1>ページの表現</h1>
<p>サイト内の各ページの配置方法は様々考えられますが、今回はサイト間のページ構造に依らずに適用でき、かつ実装も容易であるため環状に配置することを考えました。</p>
<p>各ページ間の遷移についてはこれらのノード間を移動させることで表現できますが、セッションの初回アクセスは表現できません。<br>
そのため、中心にノードを一つ配置し初回アクセス時は中心のノードからアクセスページへ移動するものとします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/faccdde3-0d1f-4e0e-8ede-6d39c2355504/blog.002.jpeg" alt=""></p>
<p>また、各ページを閲覧しているユーザー数はページのノードの大きさで表現することにしました。<br>
SVGの<code>circle</code>の大きさは半径で指定しますが、面積をユーザー数に比例させたいので半径はユーザー数の平方根に比例させるようにします。</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/a4owsx0d/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<h1>閲覧中のユーザーの取得</h1>
<p>今回は一般的なアクセスログを想定し、一つのレコードが、</p>
<ul>
<li>アクセス日時</li>
<li>ユーザーID</li>
<li>アクセスしたページ</li>
</ul>
<p>の情報からなるデータを使用します。</p>
<p>このデータに従ってある時刻<code>t</code>で発生したページアクセスを表示すれば良いのですが、このデータからはユーザーがいつページの閲覧を止めたか（離脱したか）は分かりません。<br>
ページアクセス以外のデータを組み合わせればより正確な離脱の計測も可能ですが、今回は簡単のためページアクセスから一定時間<code>T</code>経ったら閲覧を止めたとみなすことにします。</p>
<p>この条件の元である時刻<code>t</code>でサイトを閲覧中のユーザーを考えると、ページアクセスの時系列データの内、時刻<code>t-T</code>〜<code>t</code>でページアクセスをしたユーザーになります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a19b9522-01e0-464c-8e71-9d1dd7378a1b/blog.003.jpeg" alt=""></p>
<p>アニメーションの再生時は、この時刻<code>t</code>を進める→閲覧中のユーザーを更新という流れを繰り返して表示を行います。</p>
<h1>ユーザーのページ遷移アニメーション</h1>
<p>ユーザーがページ間を遷移するアニメーションはD3.jsの <a href="https://github.com/d3/d3-transition">transition</a>で実装します。<br>
詳細については多くのチュートリアルや例があるので割愛しますが、D3.jsを使用するとシンプルにアニメーションを実装できます。</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/hbgb5v3v/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>注意点としては、ユーザーとノードを対応させるためにユーザーIDをキーとして渡す必要があります。<br>
これを行わないと、異なるユーザーのノードが使われてしまう可能性があります。</p>
<p>キー指定無し：</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/bjzkmnfe/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>キー指定有り：</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/sdcuzkxp/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>上の例ではデータ上は2人のユーザーがページを遷移していますが、キー指定無しの場合はノードとユーザーの紐付けが行われないため、遷移が起こっていないように見えてしまいます。</p>
<h1>作成したアニメーション</h1>
<p>弊社の運営する<a href="http://shopping-tribe.com/">Shopping Tribe</a>へのある日のアクセスデータをサンプリングした上で抽出してアニメーションを作成してみました。<br>
ノード数を抑えるためにアクセス数の上位49ページをそれぞれ一つのノードで表し、残りのページへのアクセスは一つのノード（<code>others</code>）にまとめて表現しました。</p>
<iframe src="https://player.vimeo.com/video/207268708" width="640" height="668" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
<p>作成したアニメーションを眺めていると、</p>
<ul>
<li>各ページへのアクセスのほとんどはサイト外からの流入で行われており、トップページ等サイト内での遷移からのアクセスの割合は多くない</li>
<li>アクセスの集中しているページとその他のページ間の遷移が多いわけではなく、決まった遷移の流れにはなっていない</li>
<li>アクセス数が上位49ページに入っていないページへのアクセス割合が比較的大きく、幅広くアクセスが発生している</li>
</ul>
<p>といった大まかな傾向は見てとれますが、新しい知見を得るためにはまだまだ改良が必要そうです。</p>
<h1>最後に</h1>
<p>今回行ってみたユーザー行動の可視化では、大まかなユーザーの動きの傾向や時間帯ごとの動きの違い程度の傾向はつかめるように思いますが、データから新しい知見を得るという点までは達しておらず、サイトに来訪したユーザーについての理解を深めるためには改良が必要そうです。</p>
<p>ここから意義のある知見を得られるレベルまで改良するには、</p>
<ul>
<li>個々のユーザーをどのように表現するか</li>
<li>各ページのノードをどのように配置するのが良いか</li>
</ul>
<p>が主なポイントになるかと思います。</p>
<p>特に、個々のユーザーの表現方法については、KARTEに取り込まれたユーザー情報やセグメント情報と合わせればより多くの知見を得られるのではなかと思いますので、より良い表現を考えたいところです。<br>
また、今回は閲覧データのみを使用しましたが、KARTE上には購入や会員登録を含む様々な行動データが存在するため、閲覧よりもより細かい行動の遷移を見るのも面白そうです。</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、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>
<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>


D3.jsを使ってユーザーがサイト内の各ページを遷移している様子をアクセスログから可視化してみました。

データの可視化に使えるD3.jsでユーザーのページ遷移を表現してみた | PLAID engineer blog

データの可視化に使えるD3.jsでユーザーのページ遷移を表現してみた

<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ab738df8-3e11-4248-b37b-c8b4f16dfd83/16196179_1291472420896304_1281133783_o--1-.png" alt=""></p>
<p>こんにちは！<br>
プレイド エンジニアの@ikemonnです。</p>
<p>2/22(水)に開催しました「<a href="https://plaidtech.connpass.com/event/49170/">【KUFU×プレイド】Tech Meetup ~Docker編~</a>」のレポートをお届けしたいと思います。</p>
<h2>発表タイトル</h2>
<ul>
<li>ECS を使って PR ごとに検証環境を用意した話</li>
<li>CIにWerckerを使うべき5つの理由</li>
<li>Building Minimal Docker Containers</li>
<li>Docker社が買った会社</li>
<li>効率的なdocker build用directory構造について</li>
</ul>
<h2>ECS を使って PR ごとに検証環境を用意した話</h2>
<p>まず<a href="http://kufuinc.com/">KUFU</a> <a href="http://twitter.com/elbowroomer">@elbowroomer</a>さんから「ECS を使って PR ごとに検証環境を用意した話」というテーマで発表がありました。</p>
<p>もともと検証環境が1台だったところを、ECS &amp; Dockerを使ってPRごとに検証できるようにされたとのことでした！</p>
<p>修正内容を、文字やスクリーンショットベースではなく、実際に触って試せるのは良いですね！</p>
<iframe src="//www.slideshare.net/slideshow/embed_code/key/gZ4hajTEanBRb" width="100%" height="533" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/AtsushiYoshinari1/ecs-pr-72456169" title="ECS を使って PR ごとに検証環境を用意した話" target="_blank">ECS を使って PR ごとに検証環境を用意した話</a> </strong> from <strong><a target="_blank" href="//www.slideshare.net/AtsushiYoshinari1">Atsushi Yoshinari</a></strong> </div>
</div>
<p>詳細はブログに書いてくださっているので、併せてお読みください！</p>
<p><a href="http://tech.smarthr.jp/tech/466">「ECS を使って PR ごとに検証環境を用意した話」というテーマで登壇しました！ | SmartHR Tech Blog</a></p>
<h2>CIにWerckerを使うべき5つの理由</h2>
<p>次に<a href="https://plaid.co.jp/">PLAID</a> <a href="https://twitter.com/algas">@algas</a>から<a href="https://algas.github.io/plaid-meetup-20170222/#1">CIにWerckerを使うべき5つの理由</a>というテーマで発表がありました。</p>
<p>CIをしていると</p>
<ul>
<li>CIが何をしているのか把握できない</li>
<li>CIと同じ環境を構築できない</li>
<li>CIで起こった問題が再現できない</li>
</ul>
<p>という部分でハマりがちです。</p>
<p>「ローカルでは動くのにCIでコケた」のような状況を、<a href="http://www.wercker.com/">Wercker</a> というDockerネイティブなCIサービスを使えば解決できるという話でした！</p>
<p>弊社ではお客様に配布するJSファイルをbuildする部分からWerckerを取り入れ始めています！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/01a66a0e-7bfc-4347-a54e-762f53ce81d1/----------2017-03-01-14.47.46-1.png" alt=""></p>
<p><a href="https://algas.github.io/plaid-meetup-20170222/#1">スライドはこちら！</a></p>
<h2>Building Minimal Docker Containers</h2>
<p>続いて<a href="https://twitter.com/yepn">@gavinzhm</a> さんから「Building Minimal Docker Containers」というテーマで発表がありました。</p>
<p>軽量なLinuxディストリビューションである<a href="https://www.alpinelinux.org/">alpine Linux</a>を用いてイメージを作ったり、必要なレイヤーだけを注意深く選ぶことでビルド時間を短縮したりと実践的な内容でした！</p>
<script async class="speakerdeck-embed" data-id="bd98fa070456443096f8ebffc688b9c5" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h2>Docker社が買った会社</h2>
<p>次にPLAID <a href="https://twitter.com/otoan52">@otolab</a>から「Docker社が買った会社」というテーマで発表がありました。</p>
<p>Docker社が今まで買収した会社と、その買収によってどのような機能が実装されてきたか &amp; 今後どのような機能が実装されそうかということを発表してもらいました！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bbc96057-b5ad-48cc-a922-cf38fa68f556/----------2017-03-02-11.09.23.png" alt=""></p>
<p><a href="https://otolab.github.io/plaid-meetup-20170222/#1">スライドはこちら！</a></p>
<h2>効率的なdocker build用directory構造について</h2>
<p>最後に<a href="https://twitter.com/negabaro">@kimsehwa</a>さんから「効率的なdocker build用directory構造について<br>
」というテーマで発表がありました。</p>
<p><code>Git push -&gt; CI -&gt; Docker build, run, push</code> といったフローを行いたい時に、どのようなディレクトリ構成にするのが効率的かという内容でした！</p>
<script async class="speakerdeck-embed" data-id="f12a99e526614ad58a2cf5dadf610191" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<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>


2/22(水)に開催しました【KUFU×プレイド】Tech Meetup ~Docker編~のレポートです。
「ECS を使って PR ごとに検証環境を用意した話」「CIにWerckerを使うべき5

【KUFU×プレイド】Tech Meetup ~Docker編~を開催しました！

エディタ、ターミナル、UNIXシェルについて、PLAIDのエンジニアが何を使っているのか、アンケート形式で訊いてみた。果たして、1位のエディタは？

最強のエディタ、ターミナル環境はこれだ！〜PLAIDエンジニアの開発ツール調べてみた〜 | PLAID engineer blog

最強のエディタ、ターミナル環境はこれだ！〜PLAIDエンジニアの使っている開発ツール調べてみた〜

<p>こんにちは。プレイドの＠etoです。<br>
プレイドではバックエンド全般から外部API連携までを担当しています。</p>
<p>うちの妻がBot作りたいとか言ってたので、自分で作れるようにサポートしてみました。<br>
妻はエンジニアではありませんのでコード書いたりとか一切なしです。</p>
<p>設定して動作確認するところまでで、簡単につくれるLINE BOTの話になります。</p>
<h2>目次</h2>
<ol>
<li>BOT作りたい</li>
<li>事前準備編</li>
<li>動作確認編</li>
<li>その他できそうなこと</li>
<li>まとめ</li>
</ol>
<h2>BOT作りたい</h2>
<p>妻「チャットボット作りたい。作って。」</p>
<p>わし「えっ、自分（の会社）でやればいいじゃん。」</p>
<p>妻「無理。何とかして。」</p>
<p>わし（なんとかしてって言われても・・・）</p>
<p>(注)実話を元にしたフィクションです。</p>
<p>という感じで、<s>妻の機嫌が悪くならないように</s>簡単にBOT作れないか考えていたところ、<br>
登録したけど全く使ってなかった<code>docomo Developer support</code>からちょうどいい感じのメールが届きました。</p>
<p><code>Repl-AIに「LINE連携用シナリオ」のテンプレートが追加されました。（中略）Repl-AIであればLINEを簡単に自動応答させることができます。（後略）</code>とあるではないですか。<br>
折しもプレイドで LINE Messenger API をやったばかりということもあり、LINEとこれで妻<s>をちょろまかす</s>に LINE BOT 作らせてみればよくないかと思ったわけで、実際にやってもらってみました。</p>
<p>本稿とは一切関係ありませんが、プレイドには有能なBOTがいっぱいあります。<br>
こちらで紹介してありますのでどうぞ。<br>
/making-slack-bot-with-lambda/</p>
<h2>事前準備編</h2>
<p>まずは Repl-AI に登録します。<br>
アカウント自体はdocomo Developer support(dDs)なのでこっちに登録すればログインできるようになります。<br>
Repl-AI にログインしてクレジットカード情報を登録すれば使えるようになります。</p>
<p>LINEと連携する方法ですが、ドキュメントがあるのでこちらを参考にすれば簡単にできます。<br>
https://repl-ai.jp/#docs/tutorial/line<br>
基本的にはLINEとRepl-AIのアカウントがあればできる感じです。</p>
<ol>
<li>LINE BUSINESS CENTER に LINE のアカウントでログインしビジネスアカウントを作成</li>
<li>LINE@MANAGER のアカウント設定からBot設定に行きAPIを利用する</li>
<li>同じようにWebhook送信を利用する</li>
<li>LINE Developers で必要な情報の確認する</li>
</ol>
<p>わかりにくいのは LINE  側の設定が LINE@MANAGER と LINE Developers にわかれているあたりでしょうか。</p>
<p>前準備はこれで完了です。</p>
<h2>動作確認編</h2>
<p>次は Repl-AI でBOTを作ってLINEと連携させます。</p>
<h3>1.新規プロジェクト作成</h3>
<p>プロジェクト名を入れでプランを選択して保存します。<br>
とりあえずなので Light で問題ありません。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/26707329-b553-401c-a410-f2807c3e1795/----------2017-01-30-13.07.10.png" alt=""></p>
<p>無料期間を過ぎると自動で課金されてしまいますので注意が必要です。<br>
退会しなくてもプロジェクトを削除してしまえば問題ないかと思います。</p>
<h3>2. 新規ボット作成</h3>
<p>ボットIDとボット名を入れるだけです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cd472223-bec9-45ea-aa7a-5fd27f25b976/----------2017-01-30-13.10.05.png" alt=""></p>
<h3>3. 新規シナリオ作成</h3>
<p>シナリオIDとシナリオ名を入れて、連携ボットシナリオを選択しましょう。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/32947865-2e29-41f7-b631-f712dc50235e/----------2017-01-30-12.23.06.png" alt=""></p>
<h3>4. LINE連携</h3>
<p>LINE Developers から各種情報を入力<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5e2fde64-9dca-4c85-b94f-74e9a397168a/----------2017-01-30-13.12.53.png" alt=""></p>
<p>LINE Developers に Repl-AI から発行されるWebhook URL をコピペしましょう。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/eb56e28d-aae7-490c-80b1-f7e528767bed/----------2017-01-30-10.23.30.png" alt=""></p>
<h3>5. LINE Developers のQRコードからLINEで友達になる</h3>
<p>これで動作確認できます。<br>
Repl-AI 単体でもシミュレータから動作確認できたりするので便利です。</p>
<p>連携ボットシナリオ中身は以下のようになってます。</p>
<ul>
<li>「教えて」が含まれる発言に対して「知識Q&amp;Aボット」</li>
<li>「ニュース」が含まれている発言に対して「トレンド記事ボット」</li>
<li>その他は「雑談対話ボット」</li>
</ul>
<p>LINE上で話しかけて反応を楽しみましょう。</p>
<p>妻「なんかできてる。でも会話成立してなくない？」</p>
<p>わし「何もしてないしそんなもんよ。」</p>
<p>妻「思ってたのと違うんだけど、どうやったらちゃんと作れるの？」</p>
<p>わし（ネタにしかならんかったか・・・）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/52f0a22f-451f-41c6-8cb3-9b0ac86f0b86/----------2017-01-30-18.44.35.png" alt=""></p>
<h2>その他できそうなこと</h2>
<p>ここまでは簡単に誰にでもできると思います。<br>
次はシナリオに対応したBOTを作るためにはどうすればいいかですが、ある程度まではRepl-AIで簡単にできそうです。</p>
<p>上の手順の新規シナリオ作成の部分で「LINE連携シナリオ」を選択します。<br>
LINE Messenger API の内 Imagemap を除くAPI の雛形が用意されています。<br>
以下の文字を入力すると対応する応答が用意されていますので、好きにカスタマイズしてみてください。<br>
()内はLINE Message API での呼称です。</p>
<ul>
<li>テキスト (Text)</li>
<li>画像 (Image)</li>
<li>動画 (Video)</li>
<li>音楽 (Audio)</li>
<li>位置 (Location)</li>
<li>スタンプ (Sticker)</li>
<li>ボタン (Template Button)</li>
<li>確認 (Template Confirm)</li>
<li>カルーセル (Template Carousel)</li>
</ul>
<p>LINE BOT の中身として使用するのであれば結構有力な候補になると思います。<br>
お値段はそれなりですが、サーバーが不要なのとエンジニアでなくても作れそうなのでいいと思います。</p>
<p>こんな感じのが欲しいらしい。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/675eefaf-eebe-40cd-bd3a-188acafc9699/----------2017-01-30-18.35.19.png" alt=""></p>
<p>青い東京タワーの写真を表示するの図</p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a></p>
<p>または<a href="https://www.wantedly.com/companies/plaid/projects">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>


ある日突然チャットボット欲しいと言われ、楽にLINEでBOTを作る方法を模索し、実際に5分で作れるか試してみました

誰でも5分で作れるLINE BOTを試してみた | PLAID engineer blog

誰でも5分で作れるLINE BOTを試してみた

<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 〜インフラ監視編〜を開催しました！

<p>PLAID エンジニア/HUNTER<br>
山内 雅浩<br>
@algas</p>
<h2>概要</h2>
<p>node.js (npm) での依存性解決とパッケージマネージャを <a href="https://docs.npmjs.com/cli/shrinkwrap">shrinkwrap</a> から <a href="https://yarnpkg.com/">yarn</a> へ移行した話。<br>
<a href="https://algas.github.io/npm-to-yarn-slide">プレイド勉強会での発表資料</a> も合わせてご覧ください。</p>
<h3>対象読者</h3>
<ul>
<li>node.js で継続的に開発を行っているエンジニア</li>
<li>npm 依存関係地獄に苦しんでいる同志</li>
</ul>
<h3>結論</h3>
<p>shrinkwrap を捨てて yarn を使いましょう。<br>
ただし production に使うのはちょっと早い。<br>
執筆時点での yarn のバージョンは 0.17.10 です。</p>
<h2>shrinkwrap vs yarn</h2>
<p>(npm) shrinkwrap と yarn を比較してみましょう。</p>
<table>
<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>
</table>
<p>yarn を使う利点と欠点は以下のとおりです。</p>
<h3>PROS</h3>
<ul>
<li>インストール処理が高速かつ安定<br>
ネットワークパフォーマンス改善やオフラインモード、リトライの実装がされていてパッケージのインストールが標準の <code>npm install</code> に比べて高速かつ安定に動作します。</li>
<li>依存性解決の向上<br>
複数のパッケージで使われている同じパッケージを1つのインデックスにまとめることでインストールするパッケージ数を減らし、ディスク容量の軽減・インストール速度の向上を実現しています。</li>
</ul>
<h3>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>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>依存関係地獄 (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>依存性解決できない問題</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>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>自作ツールの紹介</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>ハマったこと</h2>
<ul>
<li>npm でのインストールの挙動(サブコマンドの動作など)が把握できなくて、理解するまでにすごく時間がかかりました。</li>
<li>自社の node.js プロジェクトの依存性解決に手間取りました。</li>
<li>うちの package.json はいろんな処理を書きすぎじゃね？</li>
</ul>
<h2>参考文献</h2>
<ul>
<li><a href="https://shift.infinite.red/npm-vs-yarn-cheat-sheet-8755b092e5cc">NPM vs Yarn Cheat Sheet</a></li>
<li><a href="https://yarnpkg.com/en/docs/migrating-from-npm">Migrating from npm</a></li>
</ul>
<h2>まとめ</h2>
<p>今すぐ <code>shrinkwrap</code> を捨てて <code>yarn</code> と旅に(ry</p>
<h2>エンジニア募集中</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、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>
<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>


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を使って作成しました！

SlackbotをAWS Lambdaでサクッと作ってみた | PLAID engineer blog

ランチメンバーを自動でグループ分けしてくれるSlackbotをAWS Lambdaでサクッと作ってみた

<p>プレイドの @nashibao です。</p>
<p>弊社では結構<code>BigQuery</code>を使い倒させていただいていて、社内向けのバッチ解析や<code>ChartIO</code>/<code>ModeAnalytics</code>等を介した社外向けのレポーティングとしての利用だけでなく、ABテストなどの集計系では（Query数のコントロールのためにキャッシュは介していますが）ほぼ直接アプリケーションのバックエンドとして利用しています。</p>
<p>またStreaming Insertが思ったより安定しているので、ニアリアルタイムにイベントを反映することができ、<strong>適当なQueryを投げ込んでPBの集計を気軽にやって、数百万使って唖然としてとりあえず寝て忘れる</strong>、みたいなことをしています。</p>
<p>先日も&quot;GCP NEXT World Tour in Tokyo&quot;において、弊社 @makinoy がジョブズばりのプレゼンをさせてもらいました。</p>
<p><a href="http://blog-plaid.com/event/2642/"><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/df784d2b-d07b-4eac-b2d1-afb1e918b464/DSC00529.jpg" alt="gcp"></a><br>
<a href="http://blog-plaid.com/event/2642/">Google Cloud Platform 国内最大のイベント「GCP NEXT World Tour in Tokyo」にプレイドが登壇しました</a></p>
<p>さて、これだけBigQueryを使い込んでいる弊社ですが、仕組みについてはあまり外に出てないため、ほとんど知りません。</p>
<p><a href="http://research.google.com/pubs/pub36632.html">DremelのPaper（2010/VLDB)</a> が6年前に出ていますが、その内容としては非常に単純なQuery Processingのケースのみを扱っていて、<code>シンプルな分割統治型のツリー処理</code> と、<code>独自の省スペースかつ効率的なNested Dataのカラムナ表現</code> の二点を中心に議論されています。論文の最後でも次のように締められています。</p>
<blockquote>
<p>In the future, we plan to cover in more depth such areas as<br>
formal algebraic specification, joins, extensibility mechanisms, etc.</p>
</blockquote>
<p>後半に乗っている<code>Dremel</code>と既存の<code>Google MapReduce/Sawzall</code>（Google 社内のMapReduce実装）とのパフォーマンス比較、キレイに線形にスケールする実験結果は一見の価値があります。ただ、カラムナについて独自のエンコーディング/FBMを使ったアセンブリ手法は、これがポッと作れてしまうGoogleはさすがだなぁ、と思う反面、カラムナにしたらそりゃパフォーマンスは上がるだろうという感じだし、割となんでもござれのHDDベースのMapReduceと比較して分割統治に特化した構造がパフォーマンスが出るのも当然だろ、という気がします。</p>
<p>それよりもむしろ、<code>テラ/ペタサイズのJOINやGroup Byが入り組んだクエリが数秒~数十秒で返ってくる</code>という理解不能な事象について深掘りして欲しい気がします。つまりちょうど<code>Dremel</code>のペーパーの範囲外ですw</p>
<p><a href="https://www.amazon.co.jp/Google-BigQuery-Analytics-Jordan-Tigani-ebook/dp/B00JUUZIZI">Amazon.co.jp: Google BigQuery Analytics 電子書籍: Jordan Tigani …</a></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5438d3eb-fff3-4106-bd6e-4db25c4b588e/583ec39bdd099caa2040f48c::image.png" alt="img"></p>
<p>そしてようやく本題ですが、JOINを含めたQuery Processingについては2014年に出ているこちらの本の方が詳しいので、少し紹介したいと思います。<br>
ちなみにタイトルは（かなり）盛り気味です。</p>
<h1>先に感想</h1>
<p>いくつかポイントがあると思いますが、僕が個人的に思うBigQueryのキモは次の3点です。（ちょっと想像で物を言っているので間違ってたら、、すみませんw）</p>
<ol>
<li>まずまずDisk IOの並列化（並みの並列化じゃない）</li>
<li>スピード重視でメモリとネットワークを酷使する設計（並みの酷使っぷりじゃない）</li>
<li>Slowなところを避ける代わりに出来なきゃ死ぬ設計。やり直せばいいという割り切り（その点逆にMapReduceはすごい）</li>
</ol>
<p>Disk IOを並列化して、読込をボトルネックから解放するのはこれ系では前提感あります。それに加えてネットワークを酷使したり、Hash PartitionによるShufflingなどで、メモリオーバーでabortするリスクをとるポリシーあたりがHadoopを含めたMap Reduce界隈と違うのかな、と感じます。</p>
<h1>基本構造とベーシックなクエリ処理</h1>
<p>基本的な構造としては次のようになっているようです。</p>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/55a1103a-d5c9-4f85-a446-1a0f8faa8ea2/583ec39bdd099caa2040f48b.png" alt="583ec39bdd099caa2040f48b.png"></p>
<p>クエリは<code>Root/Mixer/Slot</code>の順で伝播します。その時Slotのみで解決できないQuery要素に関しては排除されて伝播されます。<code>Slot</code>は実際にStorageレイヤと通信し最初の処理をする<code>Leaf Server</code>のスレッドのことのようです。そして、処理結果がSlot/Mixer/Rootの順で伝播し、それぞれ統治処理が行われます。</p>
<p>例えばJOINやGroup Byが絡まず、単純な分割統治処理のようなケースの場合</p>
<pre><code>SELECT corpus, word, word_count FROM tbl 
  WHERE LENGTH(word) &gt; 4 
  ORDER BY word_count 
  DESC LIMIT 5
</code></pre>
<p>（word_countが最初からaggregationされているという現実にはなさそうなケースですが）単純に同じQueryがSlotに伝播され、それぞれのSlotが返す結果に対してMixerが同じQueryをかければ終了です。</p>
<h1>Small Group By</h1>
<p>次のようにGroup Byがある場合も分割統治型で処理されます。</p>
<pre><code>SELECT corpus, word, SUM(word_count) AS total FROM tbl 
  WHERE ... 
  Group By corpus 
  ORDER BY total 
  DESC LIMIT 5
</code></pre>
<p>まず <code>Order</code>句と<code>LIMIT</code>句を排除してSlotに渡しクエリし、その結果をMixerに渡し、Mixerでは元のクエリをかけて終了です。ただしDistinctなKeyが多い場合メモリに乗り切らずabortします。</p>
<h1>BroadCast Join</h1>
<p>さてJoinですが、単純な場合としてJoinする片方がSlotにバラまけれるサイズであれば分割統治型の繰り返しで対応できます。（BigQueryでは <code>8mb</code>が閾値のようです）。こちらは</p>
<pre><code>SELECT hoge FROM a 
  JOIN 
    (SELECT fuga FROM b) AS c 
  ON a.hoge = c.fuga
</code></pre>
<ol>
<li>サブクエリ<code>SELECT fugue FROM b</code>のみをSlotに配布</li>
<li>Mixerに結果が返される</li>
<li>返された結果をインライン展開して、全体のクエリを配布</li>
<li>Mixerに結果が集められ、Aggregationして終了</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0f92e382-bd5f-4629-b49c-fa7a9c372f90/583ec39bdd099caa2040f48a.png" alt="583ec39bdd099caa2040f48a.png"></p>
<p>一つ面白いのは、例えば5000 Leafあれば 5000 x 8MB = 40GBのネットワークコストをかけている、というところです。</p>
<h1>Shuffled Query（Big Join/Big Group By）</h1>
<p>最後に複雑なケースとして、大規模なJOINと大規模なGroup Byのケースです。MapReduceと同じようにShuffleフェーズを組み合わせて処理をしますが、Merge Sortではなく、単純なHash Partitioningで分散します。つまり100台のLeafで処理していれば、keyに対して100でmodを取り対応する各Leafに配布します。</p>
<p>（元々は <code>JOIN EACH</code>や<code>GROUP EACH BY</code>といった特殊な句が用意されていましたが、自動で判断するようになったようなので、省きます。( <a href="https://cloud.google.com/bigquery/docs/reference/legacy-sql">Query Reference </a> )）</p>
<pre><code>SELECT hoge FROM a 
  JOIN 
    (SELECT fuga FROM b GROUP BY fuga) AS c 
  ON a.hoge = c.fuga
</code></pre>
<ol>
<li><code>b</code>に関するサブクエリをLeafに配布する。（例えば100Leaf）</li>
<li><code>fuga</code>を100個にHash Partitioning（<code>shuffle</code>）し、Leaf間でデータを交換する</li>
<li>Leafでサブクエリを実行しMixerに終了したかどうかだけを返す（データは返さない）</li>
<li>次に<code>a</code>に関するクエリをLeafに配布する（例えば500Leaf）</li>
<li><code>hoge</code>を500個にPartitionしLeaf間でデータを交換する</li>
<li>さらに3のデータも500個にPartitionし、Leaf間でデータを交換する（この処理がどこに挟まるかちょっと書いてなくて想像で書いてます）</li>
<li>Shard上でJOINのクエリを実行し、Mixerに結果を返す</li>
<li>Mixerで統合し終了</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6e7a1ef9-4119-4d18-8b8c-dba18a848b52/583ec39bdd099caa2040f489.png" alt="583ec39bdd099caa2040f489.png"></p>
<p>大きな注意としては、どでかいデータでHashが偏ると乗り切らずAbortする、という点です。</p>
<h1>最後に</h1>
<p>先に書いた感想と同じですが、割と古典的というか泥臭いやり方でShuffleを実装したりしているところ、ネットワーク/メモリを酷使し、合わないものはAbortするところなど、失敗を許容する代わりにパフォーマンスを出す設計が重要なように思います。</p>
<p>もう少しMapReduce界隈との設計思想の違いについても想いを馳せてみたかったんですが、図を作っていたら力尽きた感じがあるので、議論したい方は是非ともPlaidの社内勉強会等に来てください！</p>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit.html">プレイドの採用ページ</a>か、<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。</p>


プレイドで使い倒しているBigqueryの内部構造について徹底解剖してみました！

BigQueryの内部処理について徹底解剖してみた| PLAID engineer blog

Bigqueryの内部処理について徹底解剖してみた

<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/81e6ad0d-7393-4edb-9ddf-8d6a74776c40/b169e8b6-b251-40e6-82a2-dfea82be77ff.png" alt=""></p>
<p>こんにちは！<br>
プレイドでインフラエンジニアをしている@ikemonnです。</p>
<p>本日は10/27(木)に開催しました「【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜」のレポートをお届けしたいと思います。</p>
<h2>発表タイトル</h2>
<ul>
<li>ペパボを支える大統一CI基盤と人々</li>
<li>KARTEを支えるCI環境</li>
<li>自動マルチブラウザテストを導入・運用した話</li>
<li>グーペのE2Eテスト運用事情</li>
<li>並行処理のテストは難しい</li>
</ul>
<h2>ペパボを支える大統一CI基盤と人々</h2>
<p>まずペパボ @ravelllさんから「ペパボを支える大統一CI基盤と人々」についてお話頂きました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="0c5f4b9d8bc74e09ae75265cc73e9a8b" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>ペパボさんのCI環境の変遷や現在の姿、現場の声、課題などについて発表して頂きました。<br>
各チームがそれぞれ <code>いいかんじに</code> CI環境を立てていた時代からdrone.ioを用いた社内統一CIができるまでのお話です。</p>
<p>CI環境を社内で統一することによって、「CI環境自体のトラブルが減ったり」「困ったときに誰にでも質問できて楽」といったメリットがあったそうです。<br>
とは言え、Dockerfileをメンテする人が有識者に限られたり、drone.io/Docker側の問題があったりと課題もあるので改善しつつ運用されているようです。</p>
<p>弊社も現在絶賛Dockerize中ですので、大変勉強になりました。</p>
<h2>KARTEを支えるCI環境</h2>
<p>次にプレイド @positiveflatから「KARTEを支えるCI環境」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="61d9c5aa1a3340e2b3a8510fd90ef810" data-ratio="1.29456384323641" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>プレイドでは、Web接客サービスKARTEのサービス開発当初から、CIの仕組みを強化し続けています。今回は、弊社のCIの全体像と、CI環境強化の途中で発生したいくつかの問題とその解決策について簡単に紹介しました。会場にいた方は、CIに取り組みたいけどまだ取り組んでいないという方が多かったので、今回の内容がCI導入のきっかけになれば幸いです。詳しくは<a href="/2016_08_24_uitest_automation/">こちらのブログの記事</a>でも説明していますので、是非ご覧ください。</p>
<h2>自動マルチブラウザテストを導入・運用した話</h2>
<p>次にプレイド @sdaikichiから「自動マルチブラウザテストを導入・運用した話」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="537b41d4a4434a58b6c69ebb1b701d07" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p><a href="/multi-browesr-test/">40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する</a> を元に、PLAIDでマルチブラウザ（クロスブラウザ）テストを導入・運用をした経験から、設定方法やハマりどころを紹介しました。<br>
（sdaikichiが挙手制アンケートをとったところ）会場にはほぼマルチブラウザテストを行っている人はおらず、CIのマルチブラウザテストはかなりハードルが高いことが伺えました。<br>
twitterでは「(BrowserStackに関して)テストを全て動画にしてくれるのはありがたい」などの感想がつぶやかれていました。</p>
<p>ポケモンやりすぎ！</p>
<h2>グーペのE2Eテスト運用事情</h2>
<p>続いてペパボ @hypermktさんから「グーペのE2Eテスト運用事情」の発表がありました。</p>
<div style="width: 100%">
 <script async class="speakerdeck-embed" data-id="d8b089ddbf864a848a0a88035eb4d176" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>自己紹介をPHPUnit(テストはちゃんとパスする)で書かれていて、掴みからバッチリでした！<br>
テストが全くなかったサービスにテストを導入されたお話で、チームメンバーにテストコードの必要性から実装方法までを説明し、今ではUTもE2Eテストも都度追加しておられるそうです。<br>
まずは正常閲覧テストから始めてみると簡単に実装できて良いとのことでした！</p>
<h2>並行処理のテストは難しい</h2>
<p>最後にペパボ @nakano_akihitoさんから「並行処理のテストは難しい」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="0da601e2e2f1483b9cb21791d7bb0e0c" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>並列・並行処理が注目されている中、どのように並列・並行処理のテストをすればよいかを具体的にコードを見つつ説明して頂きました。<br>
<code>sleep 1</code> のように不安定な処理をいれるのではなく、<code>Humble Object pattern</code>で処理を切り出したり、<code>メッセージパッシング</code> を使うことでテストを上手く書くことが出来ます。</p>
<p>ご自身でもPHPの並列処理をするライブラリ<a href="https://github.com/ackintosh/snidel">ackintosh/snidel</a>を書かれておられるので、ご興味のある方はご覧ください！</p>
<h2>最後に</h2>
<p>今後も引き続き勉強会を開催したいと思っておりますので、一緒に勉強会を開いてくださる方を募集中です。</p>
<p>また、ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</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>


drone.io, CircleCI Enterprise, BrowserStack等を使用したテスト環境について、ペパボとプレイドで勉強会を開催しました！

【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜を開催しました！

Engineer Blog

Recent Article