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

<html><head></head><body>みなさん、ごきげんよう。プレイドの@tik-sonと申します。
私たちは<a href="https://karte.io/" target="_blank" rel="noreferrer">KARTE</a>というリアルタイムでウェブ接客ができるサービスを提供しており、 
KARTEの売りであるリアルタイム性を保てるように、日々インフラを磨きこんでいます。
このエントリーでは、そのインフラの仕組みについて一部を紹介していきます。 
今回は「1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン」です。 
現在KARTEは主に<a href="https://aws.amazon.com" target="_blank" rel="noreferrer">AWS</a>上で稼働しているので、このエントリーはAWSでのAutoScalingの紹介になります。
改めて説明は不要と思いますが、AutoScalingとは特定の条件をトリガーにリソースを自動的に増減させる仕組みのことです。
KARTEは
<ul>
<li>リアルタイムなウェブ接客を売りにしているので、リソースの枯渇でリアルタイムに接客ができないということがあってはいけない</li>
<li>時間帯によって大きく負荷が変わるためリソースを負荷のピークにあわせて用意しておくと無駄にコストがかかってしまう</li>
</ul>
のでAutoScalingはとても重要な要素の１つになっています。
<h1 id="EC2でのAutoScaling">EC2でのAutoScaling</h1>
KARTEではサーバリソースとしてEC2を利用していて、その一部でAutoScalingを導入しています。 
AutoScalingの構成パターンはざっくり言うと3種類あり、それぞれ紹介していきます。
<h2 id="1. Autoscaling+CloudWatch+ELB">1. Autoscaling+CloudWatch+ELB</h2>
一番標準的なパターンです。 
AWSでは<a href="https://aws.amazon.com/autoscaling/" target="_blank" rel="noreferrer">Autoscaling</a>という、サービス名の通りEC2の能力を自動的に縮小、拡張することができるサービスが存在するので、EC2でAutoscalingさせたい時はこのサービスを利用するのが標準です。 
また、AutoScalingではサーバをScaleOutさせるだけでなく、ScaleOutしたサーバに対して処理を割り振らないといけないので、ロードバランサーと共に利用するのが一般的です。 
このパターンではロードバランサーとしてAWSで提供されている<a href="https://aws.amazon.com/elasticloadbalancing/" target="_blank" rel="noreferrer">Elastic Load Balancing(ELB)</a>を利用しています。ELBを使えばScaleOut時のロードバランサーへのインスタンスの紐付けも比較的に容易に実行できます。 
AutoScalingのトリガーとしては<a href="https://aws.amazon.com/cloudwatch/" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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 id="2. Autoscaling+CloudWatch+CustomMetric+ELB">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/" target="_blank" rel="noreferrer">色々な言語でのSDK</a>が用意されているのでCustomMetricの送付はこれを利用すると便利です。 
ちなみにNode.js(coffeescript)でMetricを送ろうとするとこんな感じになります。
<pre><code class="language-coffee hljs">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 id="3. Autoscaling+CloudWatch+ELB+Route53+NginxPlus">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/" target="_blank" rel="noreferrer">nginxのブログ</a>に記載されているのでこちらをご覧いただければと思います。 
<a href="http://nginx.org/en/docs/http/ngx_http_upstream_module.html#ip_hash" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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 id="最後に">最後に</h2>
ウェブ接客プラットフォーム「<a href="https://karte.io/" target="_blank" rel="noreferrer">KARTE</a>」を運営するプレイドでは、 
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。
詳しくは<a href="https://www.wantedly.com/companies/plaid/projects" target="_blank" rel="noreferrer">こちら</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> 

</body></html>