Engineer Blog

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

<p>こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a> です。</p>
<p>今回は、2023年4月からBigQueryが<strong>Editions</strong>という料金体系の変更を行なったことによる、コスト最適化の挑戦について書いていこうと思います。前回は3年以上前になりますが、<a href="https://tech.plaid.co.jp/bigquery-slot-resource-optmization">6,000スロットを使うBigQueryのリソース配分最適化への挑戦</a> として同様にコストの最適化についてご説明してありますので、Slotとは何？という疑問をお持ちの方はこちらも是非ご参照下さい。</p>
<p>BigQueryは、Google Cloud Platformが提供する、大規模なデータセットを高速に分析できるデータウェアハウスです。BigQueryは、企業のデータ分析基盤として広く利用されており、その利用量は年々増加しています。</p>
<p>しかし、BigQueryのコストは、データの量やクエリの実行回数に応じて増加するため、コスト管理が重要となります。特に、BigQueryは2023年4月から、料金体系が<a href="https://cloud.google.com/bigquery/docs/editions-transition?hl=ja">Editionsに変更</a>され、従来の料金体系が変化しました。弊社におけるインパクトは主に2つあり</p>
<ul>
<li>slot(定額)の単価の増加</li>
<li>storageコストの減少</li>
</ul>
<p>による影響が発生しました。</p>
<p>storageコストに関する<a href="https://cloud.google.com/bigquery/pricing?hl=ja#storage">料金変更</a>としては、Physical StorageとLogical Storageといういずれかの課金体系が選択可能になったという点があります。どちらが最適かはユースケースによって大きく異なるため詳細は省きますが、<strong>Long-Term Physical Storage</strong> という圧縮効率が高く、長期保存されるデータに関しての費用が減少するため、弊社の場合はPhysical Storageへの課金とすることである程度のコスト減となりました。</p>
<p>一方で、slotの単価が <strong>$0.024/slothour</strong> から <strong>$0.048/slothour</strong> へ2倍の増加となるので、こちらのインパクトがより大きいという実情でした。従って、全体では大幅に増加という影響になり、弊社の分析基盤の要でもあるため、7月から9月にかけて集中的に主にSlotを中心としたコストを最適化する流れとなりました。その名も、<strong>Bigquery-Slot-Optimization Team</strong>です！</p>
<p>本記事では、BigQueryのSlotの最適化について主に実行した ① Monitoringの整備によるJobごとのSlot監視と削減、②AutoScaleの導入によるSlotBaseLineの最適化 という2つの観点から解説します。</p>
<h2>① Monitoringの整備によるJobごとのSlot監視と削減</h2>
<p>Slotのコスト削減のためには、まず、BigQueryの利用状況を把握することが重要です。BigQueryの利用状況を把握する第一歩は、BigQueryのConsoleのMonitoringを利用することです。Monitoringでは、BigQueryのジョブの実行状況やリソースの使用状況を時系列で確認することができます。Organization全体ではこのような利用状況であることが確認できます。<br>
<img src="https://ik.imagekit.io/plaid/cba093e9-b2e1-4746-b24f-4f0f99077eb7/bq_console_top_v2.png" alt="bq_console_top_v2.png"></p>
<p>MonitoringでBigQueryの利用状況を把握したら、slotを大きく消費しているJobを特定します。しかし、Monitoringの画面だけでは、ReseravtionやProjectごとでのGroupByしかできないため、クエリレベルでの細かい単位で調査することはできません。また、そもそも画面が非常に重く現実的に使いやすいものとは言えないという背景がありました（こちらはGoogleさん...お願いします...!）。クエリにラベルを適切に付与していれば、そちらで管理することも可能ですが、全てのProductでクエリにラベルを振るのは現実的ではありませんでした。そこで、独自のMonitoringを構築する必要が生じるため、CloudFunction/CloudScheduler/Datadog を用いて実装します。</p>
<p>まず、slotの消費は主にslot_ms (slot millisecond)で調査することになります。100slotを60sec利用するJobであれば、100×60×1000 = 6,000,000 slot millisecond という単位になります。</p>
<p>時系列で把握したいので、<code>INFORMATION_SCHEMA.JOBS_TIMELINE</code> というテーブルを利用します。<br>
単純には</p>
<pre><code class="language-sql">  SELECT
    job_id,
    period_start,
    period_slot_ms
  FROM
    `{YOUR_PROJECT_NAME}.region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
  WHERE
    period_start BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 20 MINUTE)
    AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
    AND job_creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 20 MINUTE)
    AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
    AND job_type = 'QUERY'
    AND statement_type != 'SCRIPT'
</code></pre>
<p>のようにすれば、簡単に取得できます。</p>
<p><strong>period_slot_ms</strong>とはperiod(=1sec)あたりのslot_msを意味するので、1secあたりのJobごとのスロット消費量が簡単に取得できます。</p>
<p>このテーブルをさらに、<code>INFORMATION_SCHEMA.JOBS</code> というテーブルを用いて、job_idをkeyにjoinすることで、実行されたqueryを取得できます。取得したqueryをさらに、<code>REGEXP_CONTAINS</code> 関数を用いて、正規表現で任意のJobに集約します。例えば、<code>WHEN REGEXP_CONTAINS(query, r'/* JOURNEY') THEN 'journey'</code> という表記により、queryのコメントに<code>/* JOURNEY</code> が含まれているqueryを <a href="https://karte.io/product/journey/">Journey</a> というProductのために使っているQuery Jobという形で集約できます。</p>
<p>集約することで、Productごとに消費したslotのtimelineが得られるので、これをDatadogに送信します。送信するには <a href="https://cloud.google.com/functions?hl=en">CloudFunction (2nd gen)</a> を用いることで簡単にDatadogに送信できます。</p>
<p>Query ResultをBigqueryClientとDatadogClientを用いて送信するだけです。<br>
TypeScriptで書くとこのようになります。（※一部抜粋）</p>
<pre><code class="language-typescript">  const slots: v2.MetricSeries = {
    metric: '${metric_name}',
    type: 2,
    interval: 1,
    points: points,
    tags: [`project:${projectId}`, `task:${task}`],
  };

  const params: v2.MetricsApiSubmitMetricsRequest = {
    body: {
      series: [slots],
    },
  };

  apiInstance
    .submitMetrics(params)
    .then((data: v2.IntakePayloadAccepted) =&gt; {
      console.log('API called successfully. Returned data: ' + JSON.stringify(data));
    })
    .catch((error: any) =&gt; console.error(error));
</code></pre>
<p>この関数をDeployするには</p>
<pre><code class="language-bash">gcloud functions deploy $FUNCTION_NAME \
  --project=$GCP_PROJECT \
  --region=$REGION \
  --runtime nodejs14 \
  --entry-point=index \
  --gen2 \
  --source ./build \
  --trigger-topic=$TOPIC_NAME \
  --trigger-service-account=$TRIGGER_SERVICE_ACCOUNT_ADRESS \
  --service-account=$SERVICE_ACCOUNT_ADRESS \
  --retry \
  --timeout=180s \
  --set-env-vars=DATADOG_APP_KEY=$DATADOG_APP_KEY,DATADOG_API_KEY=$DATADOG_API_KEY
</code></pre>
<p>というgcloudコマンドだけでdeployできます。</p>
<p>さらに、このFunction を Cloud Scheduler で定期的に実行します。<br>
ただし、あまりにも頻度が高いとslotに負荷をかけるため、10分おきに実行しています。</p>
<p>結果として、送信したMetricsを用いて以下のようなDashBoardを構築しました。<br>
<img src="https://ik.imagekit.io/plaid/61cdd26c-0f08-4fbd-b796-63bbce5c8612/datadog_top_v2.png" alt="datadog_top_v2.png"></p>
<p>これにより、どのJobがどの時間に大きなSlotを消費しているのかが、一目瞭然になります。<br>
消費Slotの多い上位のJobをターゲットにして、それぞれ個別に対策を行います。</p>
<h2>② AutoScaleの導入によるSlotBaseLineの最適化</h2>
<p>BigQueryのコスト削減のためには、<a href="https://cloud.google.com/bigquery/docs/slots-autoscaling-intro?hl=ja">AutoScale</a> を利用することも有効です。AutoScaleは、BigQueryの利用状況に応じて、自動的にリソースをスケールアップまたはスケールダウンする機能です。AutoScaleを利用することで、余剰していたBaseLineを最適化し、コストを削減することができます。</p>
<p>弊社はReservationという単位でProductごとに個別のSlotを持っているため、個別に利用状況を判断し調整します。<br>
例えば Datahub というProductではdatahub独自のSlotをReservationとして占有しており、サービス提供に支障がないように余裕をもったBaseLineを敷いていました。<br>
しかし、休日深夜帯などほとんど利用されていないような時間帯でも、BaseLine分の料金は課金されてしまうことになります。<br>
これを最適化するために導入されたのが、AutoScaleです。</p>
<p>そうなるとBaseLineを全部0にしてしまえばいい感じに最適化されるのでは？と疑問に思うかもしれませんが、一方でBaseLineにはCommitという概念があり、<a href="https://cloud.google.com/bigquery/pricing?hl=ja#flat-rate_pricing">年間契約</a>することにより割引価格が適用できます。</p>
<p>そのため、固定分を割引価格で、変動分を定価で、のような使い方をすることができるため、一概に0にするのが正解とはいえません。</p>
<p>これらを考慮した上で、弊社で最適化した結果が以下の通りです。<br>
<img src="https://ik.imagekit.io/plaid/daa0289b-1fe7-4024-9dca-440bebed292d/slot_autoscaling.png" alt="slot_autoscaling.png"></p>
<p>いかがでしょうか。利用量に応じて動的にSlotがAutoScaleしていることがわかると思います。<br>
ただし、BaseLineと違って変動分にどれくらいのコストがかかっているのか？がなかなかConsoleだけだとわかりにくいので、こちらもDatadogに送信すると以下のような画面になります。<br>
これによりBaseLine+AutoScaleの料金の見積もりと監視が容易になります。<br>
<img src="https://ik.imagekit.io/plaid/a741e551-2926-4af0-a77b-1edc77c04a38/datadog_autoscale.png" alt="datadog_autoscale.png"></p>
<p>ただし、AutoScaleも完璧ではなく、Scaleup/downでOverHeadの時間はかかります。<br>
弊社の要件であると、「軽いクエリで必ず1,2sec以内で結果を返して欲しい」という要件も一部存在します。その場合は、interactive用のReservationを別途確保して、BaseLineを100や200で設定することで、この問題を解決することが可能です。</p>
<p>最も大事なのは、<strong>Productごとに要件を把握し適切にReservationを配分する</strong>ことであり、前回同様変わらないです。Product Teamとしてはもちろん余剰にSlotを使えた方が楽なのですが、会社全体としての予算があり、あくまでその配分の中で最適化するというのを理解してもらうことが大事です。</p>
<h2>最終的なコストは...?</h2>
<p><strong>全体で約20%のコスト削減を実現</strong> することができました。<br>
年間にして***円(非公開)の効果で、弊社の基盤としてはかなりのインパクトがありました。</p>
<p>以上のように<br>
① Monitoringの整備によるJobごとのSlot監視と削減<br>
② AutoScaleの導入によるSlotBaseLineの最適化全体</p>
<p>でBigQuery全体として、約20%のコスト削減を実現しました。</p>
<p>BigQueryのUpdateは特に早く、コストの最適方法はその都度変化するため、継続的に検討を行う必要があります。今回の方法は主にEditionsへの移行に伴う最適化でしたが、今後のUpdateに伴ってより良い方法が出る可能性があります。ご自身の環境へ適用する場合は、最新のドキュメントを参照の上、ご検討下さい。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営する<a href="https://plaid.co.jp/">PLAID</a>では、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


BigQuery Editionsにおけるコスト最適化

BigQueryのコストの最適化への再挑戦〜BigQuery Editionsへの料金体系の移行について〜

社内で脆弱性診断を行なっている理由や、どのように診断から修正までを行なっているか、また社内で脆弱性診断をやることでどのような変化が起きたかについて紹介します。

社内でのプロダクト脆弱性診断の方法、継続することで見つかる脆弱性の傾向の変化

今回のブログではプラットフォームチームにて取り組んだ、異なるデータベース間のリアルタイムレプリケーションについて解説いたします。

MongoDB AtlasからBigQueryへのリアルタイムレプリケーション

<p>初めまして！エンジニアのとさ (@tosa_now)です！</p>
<p>プレイドは、2023/10/28 (土) に開催された<a href="https://vuefes.jp/2023/">Vue Fes Japan 2023</a>にゴールドスポンサーとして協賛しました。</p>
<p>スポンサーブースの運営をする機会をいただき、参加者の皆さんに<a href="https://karte.io/">KARTE</a>のデモや現在作成中の機能についての説明やお話をすることができました。</p>
<p>今回のブログでは、参加したVue Fes Japanの様子をお伝えできればと思います。</p>
<p>今回スポンサーとして参加した理由は、PLAIDが開発しているKARTEというプロダクト内ではなんとVueが0系の時から利用しており、現状でも管理画面の大部分がVueで書かれておりコミュニティに助けられているので少しでも還元したいという思いから参加しました！</p>
<h2>Vue Fes 当日の様子</h2>
<p><img src="https://ik.imagekit.io/plaid/20f62fe9-7a00-4d55-b0bc-8e3702e7b810/1000002289.jpg" alt="1000002289.jpg"><em>スポンサーブースの準備完了後の写真</em></p>
<p>主にブースではKARTEのプロダクト説明をメインで行っていました。<br>
来訪してくださった方とVue2からVue3への移行をどのように進めているのかなどの技術雑談話でもりあがりました。</p>
<p><img src="https://ik.imagekit.io/plaid/bcbfc85c-7535-4087-a132-75fbb2c890cc/IMG_4361.jpg" alt="IMG_4361.jpg"><em>エンジニアのnichimuさんがスポンサーブースに立っている様子</em></p>
<p>プロダクト説明では、<a href="https://blocks.karte.io/">KARTE Blocks</a>と新機能であるエレメントビルダーを開発しているエンジニアのjunjun (@junish_js) さんによるデモで大いに盛り上がりました！！</p>
<p>エレメントビルダーの開発の裏側は<a href="https://cxclip.karte.io/products/developer/action-editor/">こちら</a>の記事で解説しています</p>
<p><img src="https://ik.imagekit.io/plaid/4a62f6c0-d15d-49ff-a81f-cb11fe87f2d6/IMG_4364.jpg" alt="IMG_4364.jpg"><em>エンジニアのjunjunさんがプロダクト説明をしている様子</em></p>
<p>とさの個人的な趣味でVue Fesの開催二日前に発売されたHHKB Professionalのお試し会も開催しました。興味を持ってくださる方が多くて嬉しかったです。<br>
<img src="https://ik.imagekit.io/plaid/00ea3072-8ce7-4ef7-ad70-6a0cfcf0e2a3/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-11-0510.53.04.png" alt="スクリーンショット2023-11-0510.53.04.png"></p>
<p>Vue Fesのスポンサーブース全体が賑やかでどの企業さんも回っていてとても楽しかったです。</p>
<h3>参加した開発メンバーの感想</h3>
<p>デザイナーの今西さん<br>
今回、ブース対応を初めて担当し、KARTEの魅力が少しでも伝わっていれば嬉しいなと思います。ひさしぶりのオフラインカンファレンスということで、当日は大いに盛り上がり、とても楽しい1日を過ごすことができました！</p>
<p>エンジニアのjunjunさん<br>
Vue Fesにスポンサーとして参加したのが新鮮でした。また、イベントは参加者と交流するという楽しみかたがあるんだと気づきました。私はVue Fesがきっかけでプレイドを知って入社したので、皆さんも知っていただけたら嬉しいです。またお会いましょう！</p>
<h3>おわりに</h3>
<p>Vue Fesのスタッフの皆さん、準備及びに当日の運営ありがとうございました！<br>
PLAIDはこれからもVue.jsのコミュニティグループの活動を応援しています。</p>
<p><img src="https://ik.imagekit.io/plaid/a0f082ec-3452-4958-a31d-50c506335c07/1000002292.jpg" alt="1000002292.jpg"><em>ブース撤収直後のサインボードの様子</em></p>


株式会社PLAIDはVue Fes Japan 2023にゴールドスポンサーとして参加して、スポンサーブースの運営を行いました！

Vue Fes Japan 2023にゴールドスポンサーとして参加しました！

KARTE 管理画面のパフォーマンスの監視をするにあたって考えたことや Datadog の活用のポイント、改善で取り組んだことについて紹介します。

Datadog を使った KARTE 管理画面パフォーマンス改善の取り組み

<p>みなさん、ごきげんよう。プレイドの@tik-sonと申します。</p>
<p><a href="http://tech.plaid.co.jp/aws_gcp_multicloud_1/">前回のエントリー</a>では、<br>
弊社の<a href="https://karte.io">KARTE</a>で、インフラには<a href="https://aws.amazon.com">AWS</a>と<a href="https://cloud.google.com/">GCP</a>の２つのクラウドプラットフォームを組み合わせ、マルチクラウドインフラとして利用しているというお話をいたしました。<br>
今回のエントリーではその中から、「AWSとGCPをVPNで接続した」内容についてフォーカスして</p>
<ul>
<li>各クラウドプラットフォームでのVPNの仕様</li>
<li>KARTEではどのようなVPN設計にしているのか</li>
</ul>
<p>等をお話したいと思います。</p>
<h1>目次</h1>
<ul>
<li>VPNを用いる理由</li>
<li>AWSとGCPのSubnetの違い</li>
<li>VPNを接続する</li>
<li>可用性を考える</li>
<li>パフォーマンスを考える</li>
<li>VPN周りの設計について</li>
<li>悩まされたこと</li>
<li>最後に</li>
</ul>
<h1>VPNを用いる理由</h1>
<p><a href="http://tech.plaid.co.jp/aws_gcp_multicloud_1/">前回のエントリー</a>で、マルチクラウドインフラの要件として <strong>「各クラウドプラットフォームのサーバが相互に通信できる」</strong> と記載しましたが、私達はその実現方法としてVPNを選択しました。<br>
VPNであればプライベートネットワークを拡張する形になるので<br>
既存のAWSのネットワーク構成変更を少なく、GCPのサーバとセキュアに通信ができるようにすることができるからです。</p>
<p>もちろんサーバにグローバルIPアドレスを持たせて直接通信させる案も考えましたが、</p>
<ul>
<li>外部に対して通信できるように新たにポートを空けなければならない</li>
<li>通信を暗号化しなければならない</li>
</ul>
<p>など考慮しなければいけないポイントが多くでてきてしまい、実装まで時間がかかりそうだったため、今回は選択しませんでした。</p>
<h1>AWSとGCPのSubnetの違い</h1>
<p>はじめにVPNにて利用するSubnetにおけるAWSとGCPの違いについて軽くお話をします。</p>
<h2>AWSのSubnet</h2>
<p>AWSでプライベートなネットワークを作る時は<a href="https://aws.amazon.com/vpc/">VPC</a>という機能を使います。1つのVPCの中に最大 <code>/16</code> のネットマスクのプライベートネットワークを定義でき、そのプライベートネットワークの中で更にSubnetを切っていくことができます。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/a72f0973-8348-4b17-b040-ae9458865846/1-1.png" /></div>
`https://cloud.google.com/compute/docs/networking#subnet_network`
<h2>GCPのSubnet</h2>
<p>GCPではAWSのVPCのようなサービスとして定義はされていないのですが、以下の図のように1つのGCP Networkという単位の中に様々なSubnetを作成することができます。<br>
例えば、<code>10.240.0.0/24</code> と <code>192.168.1.0/24</code> を１つのGCP Networkを共存させることができ、それぞれのSubnetは特に設定不要で相互通信が可能になります。<br>
GCPの方がAWSより柔軟にSubnetを作れるようです。<br>
ただし、Subnetは柔軟に作れますが、 GCP Network上で稼働させるインスタンスの<a href="https://cloud.google.com/compute/docs/networking#quotas_and_limits">台数制限はデフォルトだと7000台</a> だということ は注意しなければなりません。(なかなかその上限に引っかかることは無いと思いますが)</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/33ed5504-df40-4ef3-ab1f-a51109c43da4/2-1.png" /></div>
<p><code>https://cloud.google.com/compute/docs/networking#subnet_network</code></p>
<h1>VPNを接続する</h1>
<p>VPNには色々な種類がありますが、今回使用するVPNはAWS、GCPが共にサポートしているIPsecVPNになります。</p>
<p>AWSとGCPをVPN接続する際の詳細な手順については<br>
<a href="http://dev.classmethod.jp/cloud/vpn-interconnect-amazon-vpc-and-gce/">クラスメソッドさんの記事</a>に記載されているので参考にさせていだきました。少し古い記事になりますが、流れとしてはほとんど変わっていないので、こちらとあわせて<br>
<a href="http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_VPN.html">AWSのドキュメント</a>と<br>
<a href="https://cloud.google.com/compute/docs/vpn/creating-vpns">GCPのドキュメント</a><br>
を参考にしていただければ、特につまることなくVPN接続が出来るかと思います。<br>
記事内でも紹介されていますが、VPN接続の設定順番が重要になってきます。<br>
また、この記事の記載後にGCEのネットワークの機能が拡張されたことで、現在はVPN接続を定義したリージョン以外のインスタンスからもVPN接続を利用できるようになっています。</p>
<h1>可用性を考える</h1>
<p>本番環境で運用する上で可用性を考えないわけにはいきません。<br>
VPNトンネルが１つしかない状態でそのVPNトンネルが切断されてしまうとどうなるでしょうか？<br>
答えは簡単でAWS、GCP間で通信ができなくなるというクリティカルな問題が発生してしまいます。<br>
したがって<code>VPNを冗長化</code> することはとても大切です。</p>
<p>AWSでは1VPN設定に対して、2VPNトンネル、GCPでは1VPN設定に対して1VPNトンネルが提供されます。<br>
GCP、AWS共に2VPN設定ずつ用意し、以下の図のように構成を組むことで、冗長構成を取ることができます。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/14be069b-2a93-43b1-b569-f7c034014df7/3-2.png" /></div>
<p><code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_VPN.html#VPNConnections</code></p>
<p>尚、どちらのプラットフォームにおいても、それぞれのゲートウェイで同じルーティングを設定しておけば、片方のトンネルが落ちてしまった時に残りのトンネルを利用してくれるようになります。</p>
<p><strong>GCP</strong></p>
<blockquote>
<p>Cloud VPN ゲートウェイは、ピア VPN ゲートウェイが停止して一方の VPN トンネルが使用できなくなっても、もう一方の VPN トンネルを使用し続けます。停止した VPN トンネルが復帰すると、また自動的に両方のトンネルを使用します<code>https://cloud.google.com/compute/docs/vpn/advanced#redundancy_and_failover</code></p>
</blockquote>
<p><strong>AWS</strong></p>
<blockquote>
<p>AWS はときどき、仮想プライベートゲートウェイに対して定期的にメンテナンスを実行します。このメンテナンスによって VPN の 2 つのトンネルのうち 1 つが短時間無効になることがあります。このメンテナンスの実行中、VPN 接続は自動的に 2 番目のトンネルにフェイルオーバーします。サービスが中断されないようにするために、両方のトンネルを設定することが重要です。<br>
<code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/NetworkAdminGuide/Introduction.html#CustomerGateway</code></p>
</blockquote>
<blockquote>
<p>カスタマーゲートウェイが使用できなくなった場合に接続が失われるのを防ぐために、2 番目のカスタマーゲートウェイを使用して、VPC および仮想プライベートゲートウェイへの 2 番目の VPN 接続を設定できます。冗長な VPN 接続とカスタマーゲートウェイを使用すれば、1 つのカスタマーゲートウェイでメンテナンスを実行しながら、2 番目のカスタマーゲートウェイの VPN 接続を通してトラフィックの送信を継続することができます。<br>
<code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_VPN.html#VPNConnections</code></p>
</blockquote>
<p>ちなみに<a href="https://cloud.google.com/vpn/sla">GCPはVPNのSLA</a>が定義されていますが、AWSにはSLAの記述がないようです。<br>
また、GCPにもSLAはありますがGoogleのコントロール外の部分(インターネット等)による問題については保証されていない点については意識しておかなくてはいけません。</p>
<h1>パフォーマンスを考える</h1>
<p>もちろん本番環境で運用する上では可用性だけではなくパフォーマンスも考えないわけにはいきませんよね。ということで話をします。</p>
<h2>VPNのスループット</h2>
<p>各プラットフォームは以下の通りスループットについて説明があり、まとめると以下の通りです。</p>
<ul>
<li>AWSでは仕様上、スループットの制限は特にない</li>
<li>GCPは仕様上、VPN ゲートウェイごとに1.5 Gbpsまでのスループットのサポートはしている</li>
<li>スループットは利用環境によって変わるので実質、保証はされない</li>
</ul>
<p><strong>AWS</strong></p>
<blockquote>
<p>Q: VPN 接続のスループット制限はありますか?<br>
VPN のスループットについて、Amazon はいかなる制限も実施していません。ただし、その他の要因、例えばカスタマーゲートウェイの暗号化能力や、お客様側のインターネット接続速度、平均パケットサイズ、使用されているプロトコル（TCP か UDP か）、カスタマーゲートウェイと仮想プライベートゲートウェイの間のネットワークレイテンシーなどが、スループットに影響を与える可能性があります。<br>
<code>https://aws.amazon.com/jp/vpc/faqs/</code></p>
</blockquote>
<p><strong>GCP</strong></p>
<blockquote>
<p>各 Cloud VPN ゲートウェイでは、すべてのトンネルで最大 1.5 Gbps のスループットがサポートされています。スループットを最大にするには、トンネルごとに Cloud VPN ゲートウェイを作成します。 実際のパフォーマンスは次の要因によって変動します。</p>
</blockquote>
<ul>
<li>2 つの VPN ピア間のネットワーク容量。</li>
<li>ピアデバイスの機能。詳しくは、デバイスのドキュメントをご覧ください。</li>
<li>パケットサイズ。パケット単位で処理が発生するため、小さなパケットの割合が高いと全体的なスループットが低下します。</li>
<li>RTT やパケット損失率の値が高いと、TCP のスループットが大幅に低下します。<br>
<code>https://cloud.google.com/compute/docs/vpn/advanced#vpn_throughput</code></li>
</ul>
<h2>VPNトンネルへのトラフィックをコントロール</h2>
<p>スループットについてお話しましたが、仕様上においても1VPNトンネルだけだとスループットに限界があるため、複数のVPNトンネルを組み合わせることが大切だということが分かると思います。<br>
AWS、GCP共に、トラフィックを流すVPNトンネルをコントロールすることができるので、その仕様について紹介します。両クラウドプラットフォームともにトラフィックをコントロールすることはできるものの出来ることが少し異なっています。</p>
<p><strong>GCP</strong></p>
<ul>
<li>各VPNトンネルへのルーティング、Priorityを同じにすると、トラフィックをそれぞれのトンネルにバランシングしてくれます。</li>
<li>各VPNトンネルへのルーティングを同じにし、Priorityに差をつけると、Priorityが高いVPNトンネルがプライマリーのVPNトンネルとして利用されるようになります。<br>
<code>https://cloud.google.com/compute/docs/vpn/advanced#redundancy_and_failover</code></li>
</ul>
<p><strong>AWS</strong></p>
<ul>
<li>
<p>VPCのVPNでは Multi Path でのルーティングには未対応なので、バランシングはしてくれません。AWS側で定められたロジックによって、必ずVPNトンネルのどれかを利用することになります。<br>
<code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/NetworkAdminGuide/Introduction.html#MultipleVPNConnections</code></p>
</li>
<li>
<p>静的ルーティングの場合は最も具体的な IP プレフィックスが優先されます。<br>
例を示します。(参考: <a href="http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html#route-tables-priority">ルーティングの優先度について</a>)</p>
<p>IP プレフィックスについて少しややこしいと思うので以下の静的ルーティングが設定されたVPN1、VPN2という2つのVPN接続を例に説明してみます。</p>
  <table>
  <tr>
  <th> </th>
  <th>VPN1</th>
  <th>VPN2</th>
  </tr>
  <tr>
  <td>設定された静的ルーティング</td>
  <td>10.1.0.0/18,  10.1.64.0/18,  10.1.128.0/17</td>
  <td>10.1.0.0/17, 10.1.128.0/18, 10.1.192.0/18</td>
  </tr>
  </table>
  この場合
  - 全VPNが正常な場合はそれぞれ `/18` を設定したVPNが優先になります。
  - 片方のVPN切断時には `/18` で設定されたルーティングを包括する `/17` のルーティングが別のVPNに設定されているのでそちらの経路が使って迂回されることになります。
</li>
</ul>
<h1>VPN周りの設計について</h1>
<p>可用性やパフォーマンスについて記載してきましたが、それらを踏まえてVPN周りは以下のように設計にしています。</p>
<ul>
<li>VPNトンネルは複数作成する。</li>
<li>特定のVPNトンネルにトラフィックが偏らないように、
<ul>
<li>GCP側のサーバは複数のSubnetにサーバを分散させて配置する。</li>
<li>AWS側のルーティングは特定のSubnetへの通信が特定のVPNトンネルを利用するよう設定する。</li>
<li>GCP側のルーティングは全VPNトンネルでバランシングされるように同じプライオリティで同じ内容を設定する。</li>
</ul>
</li>
<li>VPNトンネルが切断された時に別トンネルで迂回できるよう、
<ul>
<li>AWS側のルーティングでは全VPNトンネルに対して別VPNトンネルのルーティングを包括するルーティングを記載しておく。</li>
<li>GCP側のルーティングでは全VPNトンネルに対して、同じルーティングを設定しておく。</li>
</ul>
</li>
</ul>
<p>イメージとしては以下の図のようになります</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/976999df-225b-4dbb-9f5c-d01a2270601c/4-1.png" /></div>
<p>ちなみにKARTEではシンプルなネットワーク構成にしているので、静的ルーティングを利用し<br>
ています。</p>
<h1>悩まされたこと</h1>
<h2>VPNのDropパケットの増加問題</h2>
<p>AWSとGCPをVPNで接続して運用していたある日、GCPのサーバのパフォーマンスが悪化することがありました。<br>
GCPは<a href="https://www.stackdriver.com/">StackDriver</a>でVPNの様々なメトリックををモニタリングできるので確認してみたところ、特定のVPNトンネルでDropパケットの増加が見受けられました。<br>
VPNトンネルが切断されてしまえば別のVPNトンネルを利用するようにしていたのですが、そのVPNトンネルは劣化した状態で生き続けていました。<br>
対応としては、特定のVPNトンネルの問題として判断し、劣化したVPNトンネルを切断し正常なVPNトンネルのみを利用するようにしたところ現象が改善しました。</p>
<p>後々、GCP、AWS両方のサポートなどに問い合わせて原因を突き詰めていったところ、AWSにおけるネットワークの劣化が原因で、VPNトンネルは落ちないがパケットがDropされているという状況でした。<br>
ネットワーク周りの問題は切り分けが難しいですが、モニタリングツールが存在することで切り分け、対応が迅速に行うことが出来ました。<br>
この件以降、VPNトンネルに対し、DropパケットなどのMetricでアラートを仕掛けるようにしています。</p>
<h2>VPNのスループット問題</h2>
<p>元々単一クラウドプラットフォーム内のプライベートネットワーク内で通信していたものをVPN越しで通信させようとすると、想定した以上にアプリケーションの性能が出ませんでした。<br>
その主な理由としては、DBとの通信の多くがVPN経由になっていたことでした。</p>
<p>VPNトンネルを増やしていけば暫定的には解決できる話になりますが、そもそも元々のアーキテクチャがマルチクラウドインフラに最適なアーキテクチャになっているとは言えなかったので、その部分について考え直しました。このあたりの話はまた別エントリーでお話しようと思うので乞うご期待を。</p>
<h1>今後について</h1>
<p>AWSとGCPの周りにはまだまだ改善の余地はあるので、今後以下を考えていきたいと思っています。</p>
<ul>
<li>特定の条件でVPNトンネル切断→接続する等のVPN運用周りでの自動化の仕組み</li>
<li>VPNトンネルのAutoscalingの仕組み</li>
<li>VPN経由ではないサーバ間通信の仕組み</li>
</ul>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、マルチクラウドインフラを成長させたい、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>、または<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>


AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイントを説明します。
マルチクラウドインフラ連載の第二回。

AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント| PLAID engineer blog

AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント

<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の内部構造について徹底解剖してみました！