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

こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a> です。
今回は、2023年4月からBigQueryがEditionsという料金体系の変更を行なったことによる、コスト最適化の挑戦について書いていこうと思います。前回は3年以上前になりますが、<a href="https://tech.plaid.co.jp/bigquery-slot-resource-optmization">6,000スロットを使うBigQueryのリソース配分最適化への挑戦</a> として同様にコストの最適化についてご説明してありますので、Slotとは何？という疑問をお持ちの方はこちらも是非ご参照下さい。
BigQueryは、Google Cloud Platformが提供する、大規模なデータセットを高速に分析できるデータウェアハウスです。BigQueryは、企業のデータ分析基盤として広く利用されており、その利用量は年々増加しています。
しかし、BigQueryのコストは、データの量やクエリの実行回数に応じて増加するため、コスト管理が重要となります。特に、BigQueryは2023年4月から、料金体系が<a href="https://cloud.google.com/bigquery/docs/editions-transition?hl=ja">Editionsに変更</a>され、従来の料金体系が変化しました。弊社におけるインパクトは主に2つあり
<ul>
<li>slot(定額)の単価の増加</li>
<li>storageコストの減少</li>
</ul>
による影響が発生しました。
storageコストに関する<a href="https://cloud.google.com/bigquery/pricing?hl=ja#storage">料金変更</a>としては、Physical StorageとLogical Storageといういずれかの課金体系が選択可能になったという点があります。どちらが最適かはユースケースによって大きく異なるため詳細は省きますが、Long-Term Physical Storage という圧縮効率が高く、長期保存されるデータに関しての費用が減少するため、弊社の場合はPhysical Storageへの課金とすることである程度のコスト減となりました。
一方で、slotの単価が $0.024/slothour から $0.048/slothour へ2倍の増加となるので、こちらのインパクトがより大きいという実情でした。従って、全体では大幅に増加という影響になり、弊社の分析基盤の要でもあるため、7月から9月にかけて集中的に主にSlotを中心としたコストを最適化する流れとなりました。その名も、Bigquery-Slot-Optimization Teamです！
本記事では、BigQueryのSlotの最適化について主に実行した ① Monitoringの整備によるJobごとのSlot監視と削減、②AutoScaleの導入によるSlotBaseLineの最適化 という2つの観点から解説します。
<h2>① Monitoringの整備によるJobごとのSlot監視と削減</h2>
Slotのコスト削減のためには、まず、BigQueryの利用状況を把握することが重要です。BigQueryの利用状況を把握する第一歩は、BigQueryのConsoleのMonitoringを利用することです。Monitoringでは、BigQueryのジョブの実行状況やリソースの使用状況を時系列で確認することができます。Organization全体ではこのような利用状況であることが確認できます。 
<img src="https://ik.imagekit.io/plaid/cba093e9-b2e1-4746-b24f-4f0f99077eb7/bq_console_top_v2.png" alt="bq_console_top_v2.png">
MonitoringでBigQueryの利用状況を把握したら、slotを大きく消費しているJobを特定します。しかし、Monitoringの画面だけでは、ReseravtionやProjectごとでのGroupByしかできないため、クエリレベルでの細かい単位で調査することはできません。また、そもそも画面が非常に重く現実的に使いやすいものとは言えないという背景がありました（こちらはGoogleさん...お願いします...!）。クエリにラベルを適切に付与していれば、そちらで管理することも可能ですが、全てのProductでクエリにラベルを振るのは現実的ではありませんでした。そこで、独自のMonitoringを構築する必要が生じるため、CloudFunction/CloudScheduler/Datadog を用いて実装します。
まず、slotの消費は主にslot_ms (slot millisecond)で調査することになります。100slotを60sec利用するJobであれば、100×60×1000 = 6,000,000 slot millisecond という単位になります。
時系列で把握したいので、<code>INFORMATION_SCHEMA.JOBS_TIMELINE</code> というテーブルを利用します。 
単純には
<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>
のようにすれば、簡単に取得できます。
period_slot_msとはperiod(=1sec)あたりのslot_msを意味するので、1secあたりのJobごとのスロット消費量が簡単に取得できます。
このテーブルをさらに、<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という形で集約できます。
集約することで、Productごとに消費したslotのtimelineが得られるので、これをDatadogに送信します。送信するには <a href="https://cloud.google.com/functions?hl=en">CloudFunction (2nd gen)</a> を用いることで簡単にDatadogに送信できます。
Query ResultをBigqueryClientとDatadogClientを用いて送信するだけです。 
TypeScriptで書くとこのようになります。（※一部抜粋）
<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>
この関数をDeployするには
<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>
というgcloudコマンドだけでdeployできます。
さらに、このFunction を Cloud Scheduler で定期的に実行します。 
ただし、あまりにも頻度が高いとslotに負荷をかけるため、10分おきに実行しています。
結果として、送信したMetricsを用いて以下のようなDashBoardを構築しました。 
<img src="https://ik.imagekit.io/plaid/61cdd26c-0f08-4fbd-b796-63bbce5c8612/datadog_top_v2.png" alt="datadog_top_v2.png">
これにより、どのJobがどの時間に大きなSlotを消費しているのかが、一目瞭然になります。 
消費Slotの多い上位のJobをターゲットにして、それぞれ個別に対策を行います。
<h2>② AutoScaleの導入によるSlotBaseLineの最適化</h2>
BigQueryのコスト削減のためには、<a href="https://cloud.google.com/bigquery/docs/slots-autoscaling-intro?hl=ja">AutoScale</a> を利用することも有効です。AutoScaleは、BigQueryの利用状況に応じて、自動的にリソースをスケールアップまたはスケールダウンする機能です。AutoScaleを利用することで、余剰していたBaseLineを最適化し、コストを削減することができます。
弊社はReservationという単位でProductごとに個別のSlotを持っているため、個別に利用状況を判断し調整します。 
例えば Datahub というProductではdatahub独自のSlotをReservationとして占有しており、サービス提供に支障がないように余裕をもったBaseLineを敷いていました。 
しかし、休日深夜帯などほとんど利用されていないような時間帯でも、BaseLine分の料金は課金されてしまうことになります。 
これを最適化するために導入されたのが、AutoScaleです。
そうなるとBaseLineを全部0にしてしまえばいい感じに最適化されるのでは？と疑問に思うかもしれませんが、一方でBaseLineにはCommitという概念があり、<a href="https://cloud.google.com/bigquery/pricing?hl=ja#flat-rate_pricing">年間契約</a>することにより割引価格が適用できます。
そのため、固定分を割引価格で、変動分を定価で、のような使い方をすることができるため、一概に0にするのが正解とはいえません。
これらを考慮した上で、弊社で最適化した結果が以下の通りです。 
<img src="https://ik.imagekit.io/plaid/daa0289b-1fe7-4024-9dca-440bebed292d/slot_autoscaling.png" alt="slot_autoscaling.png">
いかがでしょうか。利用量に応じて動的にSlotがAutoScaleしていることがわかると思います。 
ただし、BaseLineと違って変動分にどれくらいのコストがかかっているのか？がなかなかConsoleだけだとわかりにくいので、こちらもDatadogに送信すると以下のような画面になります。 
これによりBaseLine+AutoScaleの料金の見積もりと監視が容易になります。 
<img src="https://ik.imagekit.io/plaid/a741e551-2926-4af0-a77b-1edc77c04a38/datadog_autoscale.png" alt="datadog_autoscale.png">
ただし、AutoScaleも完璧ではなく、Scaleup/downでOverHeadの時間はかかります。 
弊社の要件であると、「軽いクエリで必ず1,2sec以内で結果を返して欲しい」という要件も一部存在します。その場合は、interactive用のReservationを別途確保して、BaseLineを100や200で設定することで、この問題を解決することが可能です。
最も大事なのは、Productごとに要件を把握し適切にReservationを配分することであり、前回同様変わらないです。Product Teamとしてはもちろん余剰にSlotを使えた方が楽なのですが、会社全体としての予算があり、あくまでその配分の中で最適化するというのを理解してもらうことが大事です。
<h2>最終的なコストは...?</h2>
全体で約20%のコスト削減を実現 することができました。 
年間にして***円(非公開)の効果で、弊社の基盤としてはかなりのインパクトがありました。
以上のように 
① Monitoringの整備によるJobごとのSlot監視と削減 
② AutoScaleの導入によるSlotBaseLineの最適化全体
でBigQuery全体として、約20%のコスト削減を実現しました。
BigQueryのUpdateは特に早く、コストの最適方法はその都度変化するため、継続的に検討を行う必要があります。今回の方法は主にEditionsへの移行に伴う最適化でしたが、今後のUpdateに伴ってより良い方法が出る可能性があります。ご自身の環境へ適用する場合は、最新のドキュメントを参照の上、ご検討下さい。
CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営する<a href="https://plaid.co.jp/">PLAID</a>では、データを活用しプロダクトを改善していくエンジニアを募集しています。 
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。

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

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

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

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

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

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

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

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

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

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

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

ウェブ接客プラットフォームKARTEの解析周りのアルゴリズムの利用検討の一環として、ストリーミングアルゴリズムについて検討したので、ストリー

大規模データを解析するストリーミングアルゴリズムをサクッと見てみる

機械学習 x PySparkでアルゴリズム開発をサクサクやる検証

みなさん、ごきげんよう。プレイドの@tik-sonと申します。
私たちは<a href="https://karte.io/">KARTE</a>というリアルタイムでウェブ接客ができるサービスを提供しており、 
KARTEの売りであるリアルタイム性を保てるように、日々インフラを磨きこんでいます。
このエントリーでは、そのインフラの仕組みについて一部を紹介していきます。 
今回は「1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン」です。 
現在KARTEは主に<a href="https://aws.amazon.com">AWS</a>上で稼働しているので、このエントリーはAWSでのAutoScalingの紹介になります。
改めて説明は不要と思いますが、AutoScalingとは特定の条件をトリガーにリソースを自動的に増減させる仕組みのことです。
KARTEは
<ul>
<li>リアルタイムなウェブ接客を売りにしているので、リソースの枯渇でリアルタイムに接客ができないということがあってはいけない</li>
<li>時間帯によって大きく負荷が変わるためリソースを負荷のピークにあわせて用意しておくと無駄にコストがかかってしまう</li>
</ul>
のでAutoScalingはとても重要な要素の１つになっています。
<h1>EC2でのAutoScaling</h1>
KARTEではサーバリソースとしてEC2を利用していて、その一部でAutoScalingを導入しています。 
AutoScalingの構成パターンはざっくり言うと3種類あり、それぞれ紹介していきます。
<h2>1. Autoscaling+CloudWatch+ELB</h2>
一番標準的なパターンです。 
AWSでは<a href="https://aws.amazon.com/autoscaling/">Autoscaling</a>という、サービス名の通りEC2の能力を自動的に縮小、拡張することができるサービスが存在するので、EC2でAutoscalingさせたい時はこのサービスを利用するのが標準です。 
また、AutoScalingではサーバをScaleOutさせるだけでなく、ScaleOutしたサーバに対して処理を割り振らないといけないので、ロードバランサーと共に利用するのが一般的です。 
このパターンではロードバランサーとしてAWSで提供されている<a href="https://aws.amazon.com/elasticloadbalancing/">Elastic Load Balancing(ELB)</a>を利用しています。ELBを使えばScaleOut時のロードバランサーへのインスタンスの紐付けも比較的に容易に実行できます。 
AutoScalingのトリガーとしては<a href="https://aws.amazon.com/cloudwatch/">CloudWatch</a>を利用しています。CloudWatchはAWSのモニタリングサービスでAWSの各サービスにおける基本的な監視ができ、AutoScalingのトリガーとして簡単に設定することが出来ます。 
ちなみに<a href="http://aws.clouddesignpattern.org/index.php/CDP:Scale_Out%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3">CDP:Scale Outパターン</a>が本パターンに該当すると思います。
<ul>
<li>CloudWatchでAutoscalingGroupのMetricを監視</li>
<li>Metricが設定した閾値を超えた時にAlarmを発行</li>
<li>AutoScalingがAlarmを受け取り、サーバを起動/停止</li>
</ul>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/84aeceee-8d1f-4285-b0b2-e05542e5cc4c/c1ee3e57-2afd-4bf2-b898-9f0b30790c18.png" alt="image.png (70.2 kB)">
<h2>2. Autoscaling+CloudWatch+CustomMetric+ELB</h2>
CloudWatchで用意されている標準のMetricだけだと、適切なタイミングでスケールアウト/インが実行されないことがあるので、独自のMetric(CustomMetric)を利用してスケールさせるパターンです。 
CustomMeticを利用する以外は基本的には「1. Autoscaling+CloudWatch+ELB」と同じです。KARTEではこのパターンを解析サーバのAutoScalingで利用していて、解析状況をCustomMetricとして送付して利用しています。 
AWSには<a href="https://aws.amazon.com/jp/tools/">色々な言語でのSDK</a>が用意されているのでCustomMetricの送付はこれを利用すると便利です。 
ちなみにNode.js(coffeescript)でMetricを送ろうとするとこんな感じになります。
<pre><code class="language-coffee">AWS = require('aws-sdk')
cloudwatch = new AWS.CloudWatch()
params =
 MetricData: [ {
 MetricName: 'YOUR_METRIC_NAME'
 Dimensions: [ {
 Name: 'YOUR_DIMENSIONS_NAME'
 Value: YOUR_DIMENSIONS_VALUES
 } ]
 Timestamp: new Date
 Unit: 'YOUR_UNIT'
 Value: YOUR_VALUE
 } ]
 Namespace: 'YOUR_NAMESPACE'
cloudwatch.putMetricData params, (err, data) -&gt;
 if err
 console.log err, err.stack
 else
 console.log data
</code></pre>
まとめると以下の通りです。
<ul>
<li>AutoscalingのトリガーになるMetricを取得し、CustomMetricとしてCloudWatchに送信</li>
<li>CloudWatchでCustomMetricを監視</li>
<li>Metricが設定した閾値を超えた時にAlarmを発行</li>
<li>AutoScalingがAlarmを受け取り、サーバを起動/停止</li>
</ul>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/51774bd8-b6b0-41b2-8b27-551a073bad6a/1a31b8c7-5207-42b1-a634-1b588eeeadc3.png" alt="image.png (82.4 kB)">
<h2>3. Autoscaling+CloudWatch+ELB+Route53+NginxPlus</h2>
KARTEではSocket.IOを利用している部分があるのですが、Socket.IOはELBとは相性が悪く、 
(HTTPモードの場合だとHTTPヘッダが書き換えられて、HTTPUpgradeができない、TCPモードだと接続ごとに別のサーバが応答するのでハンドシェイクが失敗する等) 
nginxをSocket.IOを利用するサーバのロードバランサーとして利用しています。 
nginxはWebSocketProxyのサポートを1.3.13より開始しており、それによりSocket.IOもnginxで利用できるようになっているためです。 
詳細な設定方法は<a href="https://www.nginx.com/blog/nginx-nodejs-websockets-socketio/">nginxのブログ</a>に記載されているのでこちらをご覧いただければと思います。 
<a href="http://nginx.org/en/docs/http/ngx_http_upstream_module.html#ip_hash">ip___hash</a>という方法で分散することがポイントで、これにより同じクライアントからのアクセスは一意になります。 
ちなみにこのip_hash、IPv4の場合は初めの3オクテットがhashing keyとして利用されるので、注意が必要です。
<blockquote>
Specifies that a group should use a load balancing method where requests are distributed between servers based on client IP addresses. The first three octets of the client IPv4 address, or the entire IPv6 address, are used as a hashing key. The method ensures that requests from the same client will always be passed to the same server except when this server is unavailable. In the latter case client requests will be passed to another server. Most probably, it will always be the same server as well.
</blockquote>
nginxを利用することでSocket.IOの負荷分散ができるようになりましたが、最終的に実施したいことはAutoScalingです。 
ELB利用時にはAutoscalingで新しく起動してくるインスタンスはAWS側でELBに紐付けてもらえますが、nginxを利用する場合はもちろんAWS側は何もしてくれないので、この仕組みを作る必要があります。 
実現方法は色々とあると思いますが、この仕組みはRoute53とnginxPlusで実現可能です。
nginxのupstreamにはIPアドレスではなく名前であらかじめ利用予定のサーバ名を記載しておき、 
インスタンスの起動時にインスタンス自身がRoute53に自分のIPアドレスをAレコードに登録するという方法です。
この方法では既存のレコードに影響をおよぼさないように
<ul>
<li>既に利用されているAレコードで登録しないようにするために「ping/ncコマンドで存在を確認」</li>
<li>自分のIPアドレスがAレコードに登録されている場合は登録の処理をとりやめるために、「digコマンドと<a href="http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-metadata.html">EC2のインスタンスメタデータ</a>を利用して確認」</li>
</ul>
のような工夫が大切になります。
また、この仕組みには標準のnginxではなく、nginxPlusを利用します。 
nginxPlusとはnginxのエンタープライズ向けのプロダクトで、nginxの機能に加え様々な機能が利用できます。 
今回の仕組みの中でnginxPlusを利用するのは、サービスの再起動なしにupstream内のserverのAレコードの変更を追従してくれる機能があるためです。 
https://www.nginx.com/resources/admin-guide/load-balancer/
<blockquote>
NGINX Plus can monitor changes of IP addresses that correspond to a domain name of the server and automatically apply these changes to NGINX without its restart.
</blockquote>
nginxPlusはAWSだと<a href="https://aws.amazon.com/marketplace/search/results/ref=gtw_navgno_search_box?page=1&amp;searchTerms=nginx+plus">AmazonMarketPlace</a>でAMIとして購入できるので、EC2インスタンス同様に従量課金で利用することが可能です。
このパターンについてまとめます。
<ul>
<li>nginxPlusのupstreamに利用予定のサーバ名をあらかじめ登録(s3にupstreamファイルを置いておいて、起動時に取ってくるとか)</li>
<li>CloudWatchでAutoscalingGroupのMetricを監視</li>
<li>Metricが設定した閾値を超えた時にAlarmを発行</li>
<li>AutoScalingがAlarmを受け取り、サーバを起動/停止</li>
</ul>
[以下、サーバ起動時の処理]
<ul>
<li>サーバ起動時にサーバは自分のIPアドレスをRoute53のAレコード(nginxPlusに登録されていて、現在で利用されていないレコード)に登録する</li>
<li>nginxPlusから先程Aレコード登録された名前のサーバへのhealthcheckが成功する</li>
<li>nginxPlusが新しく上がってきたサーバへ処理を振り分ける</li>
</ul>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ce445bfc-9670-4e9d-aecf-a67853e6bcd6/a326770a-a7bc-40fc-9a7c-ac31fe1231c7.png" alt="image.png (92.5 kB)">
以下のようなことも諸々と考慮しないといけないのですが、今回のエントリーでは割愛させていただきます。
<ul>
<li>serverのhealthcheckの間隔</li>
<li>同じレコードに登録しにいかないようにする仕組み(ランダムな時間待つ、チケット発行するなど)</li>
<li>nginxの冗長化</li>
</ul>
<h2>最後に</h2>
ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、 
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。
詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）募集一覧をご覧ください。 
もしくはこちらのボタンよりお気軽に「話を聞きに行きたい」と押してください！
<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>

1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン

ArduinoとDatadogでオフィスの温度と湿度を可視化する

株式会社プレイドのCTOシバヤマです。
この度、エンジニアブログを開設することにしました。 
背景には、<code>社外の人にプレイドの中のエンジニアのユニークなパーソナリティを知ってもらいたい</code>、というのがあります。
弊社のエンジニアには多様なメンバーがいて、言語解析や動画解析をやっていたメンバー、制御・ロボティクスをやっていたメンバー、並列言語コンパイラをやっていたメンバー、大手ゲーム会社出身、検索エンジンの会社出身、長くDSP畑のメンバーなどなど、ここでは書ききれないほど経験値が多種多様です。
年齢も23歳~38歳（平均31歳？）というレンジで、研究畑の人もいれば、文系の人もいるし、大手からベンチャーを渡ってきた人も、新卒もいます。
社内でミーティングをしていると、他のメンバーの意見に気づかされることが多いので（若干の悔しさは覚えますが）、このユニークなメンバーの知識や経験を社外にも還元していけるといいなぁと思っています。
出来る限り、<code>他では得られないユニークな経験もしくは深い洞察・知識</code>が書いている場所になるといいなぁと思っています。 
が、若干ハードルを上げすぎないでくれぃとメンバーには言われそうなので、このくらいにしておきますw
他にも開発合宿の様子とか新メンバーの紹介とか、ライトなコンテンツも用意していくかもしれません。
それではよろしくお願いいたします。

プレイドのエンジニアブログを開設することになりました。CTOのシバヤマから、エンジニアブログを始めるにあたってのメッセージです。

プレイドのエンジニアブログを始めました！

Engineer Blog

Recent Article

大規模データを解析するストリーミングアルゴリズムをサクッと見てみる

機械学習 x PySparkでアルゴリズム開発をサクサクやる検証

1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン

ArduinoとDatadogでオフィスの温度と湿度を可視化する

プレイドのエンジニアブログを始めました！

Archives

Writers