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

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 へのレプリケーション

機械学習 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でオフィスの温度と湿度を可視化する

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

Popular Articles

Popular Tags

Archives

Writers