_posts/2018-02-01-functions-100k-events-per-second.html

--- title: "Azure Functions で秒間 10 万のイベントを処理する" author_name: "Japan Azure CIE Support Team" tags: - MigratedArticle - Function App ---  この記事は <a href="https://docs.microsoft.com/ja-jp/archive/blogs/jpcie/azure-functions-で秒間-10-万のイベントを処理する方法">旧 Japan Azure PaaS Support Blog</a> からのコピーとなります。 記載されている内容は 2018 年 2 月 1 日時点のものとなり、現時点におきましては変更されている可能性がありますので、ご注意下さい。 <hr /> <main class="content" data-bi-name="content" dir="ltr" id="main" lang="en-us" role="main">  このポストは、2017 年 9 月 19 日に投稿された <a data-linktype="external" href="https://blogs.msdn.microsoft.com/appserviceteam/2017/09/19/processing-100000-events-per-second-on-azure-functions/"> Processing 100,000 Events Per Second on Azure Functions </a> の翻訳です。 しばしば、 <a data-linktype="external" href="https://azure.microsoft.com/en-us/services/functions/"> Azure Functions </a> の従量課金プランのスケーラビリティ/スループットの限界についてお客様からご質問をいただきます。簡易な答えは常に「それは場合によって異なりますが、ワークロードはどの程度ですか？」です。本日は、 Event Hubs / IoT Hubs の高スケールなワークロードを Functions で実行し、プラットフォームから得られるパフォーマンスを最大限に引き出すために注意すべきいくつかの重要なポイントについて説明したいと思います。 私たちは <a data-linktype="external" href="https://blogs.msdn.microsoft.com/azurecat/2017/01/05/hello-world-welcome-to-azurecat-guidance/"> Azure CAT </a> チームと連携して、Function と <a data-linktype="external" href="https://azure.microsoft.com/en-us/services/event-hubs/"> Event Hubs </a> を使用したシンプルで代表的なイベント処理パイプラインを構築しました。テレメトリは <a data-linktype="external" href="https://azure.microsoft.com/en-us/services/application-insights/"> Application Insights </a> に送信されます。 <img alt="" data-linktype="external" src="/blog/media/2017/09/01-overview.png"/> 負荷生成器（Function で実行されています）は、バッチ処理されたメッセージを、Ingestion Event Hub に書き込みます。これらのメッセージは、与えられたセンサーからの一連の測定値を表します。Function は、Ingestion Event Hub からメッセージを収集し、そこから個々の測定値を抽出し、それらを追加のテレメトリとともに、それぞれ天気/地震データ用の Event Hub に書き込みます。加えて同じ Function App 内の 2 つの Function（従量課金プラン）は、それぞれ個別の測定値を処理し、集約されたテレメトリを Application Insights に送信します。 <h2 id="performance"> Performance </h2> 我々は、合計 9 日間、毎秒 100,000 イベントの負荷目標の下でシステムを実行しました。その間、システムは合計 760 億イベントを処理しました。パイプラインの e2e 待ち時間、すなわち、メッセージを Ingestion Event Hub に書き込んでから天気/地震の Function でメッセージを処理するまでに要した時間を測定しました。結果は次のとおりです。 <h4 id="e2e-latency-percentiles"> E2E Latency Percentiles </h4> <table> <tbody> <tr class="odd"> <td> P50 </td> <td> P90 </td> <td> P95 </td> <td> P99 </td> <td> P99.9 </td> <td> P99.99 </td> <td> Max </td> </tr> <tr class="even"> <td> 1,102.42ms </td> <td> 2,755.56ms </td> <td> 3,788.30ms </td> <td> 11,894.12ms </td> <td> 50,367.23ms </td> <td> 111,240.50ms </td> <td> 239,890.10ms </td> </tr> </tbody> </table> 簡単にお伝えすると： ・メッセージの半分が、処理ハブに書き込まれてから1.2秒以内に処理されました ・10 件中 9 件のメッセージが3秒以内に処理されました ・1 分未満で 1,000 件のメッセージのうち 999 件が処理されました ・すべてのメッセージが 5 分以内に処理されました <h2 id="monitoring"> Monitoring </h2> Azure Functions には、WebJobs ダッシュボードと Application Insights（Azure FunctionsとApplication Insightsの統合は現在プレビュー中）の 2 つの監視用ソリューションが組み込まれています。ダッシュボードは長時間実行されるジョブを考慮して設計されており、1 秒あたりに 10,000 回以上の Function が実行されるシナリオには最適化されていません。幸いなことに、Application Insights は驚異的に頑健なテレメトリシステムであり、大規模なシナリオでは Azure Functions との連携が優れていることを確認しました。 App Insightを有効にするのは簡単です。Function App にインストルメントキーを追加するだけで、Azure Functions は自動的にApp Insightsにデータを送信し始めます。詳細は <a data-linktype="external" href="https://blogs.msdn.microsoft.com/appserviceteam/2017/04/06/azure-functions-application-insights/"> こちら </a> をご覧ください。 Azureダッシュボードは高度にカスタマイズ可能で、App Insightsはその視覚的コンポーネントを固定するのに非常に効果的です。このシナリオでは、非常に便利な監視ダッシュボードをまとめるのに 1〜2 時間程度しかかかりませんでした。 <img alt="" data-linktype="external" src="/blog/media/2017/09/02-monitoring.png"/> <h2 id="configuration"> Configuration </h2> 今回の結果を達成するためにいくつか注目すべき設定を行いました。 <ul> <li> Function はバッチでメッセージを処理します </li> <li> WebJobs ダッシュボードを無効化し、監視とテレメトリーのためにApplication Insights を使用しています </li> <li> 各 Event Hubs は 100 個のパーティションで構成されています </li> <li> データはパーティションキーなしで Event Hubs に送信されます </li> <li> イベントはプロトコルバッファを使用してシリアル化されます </li> </ul> それぞれの詳細については、以下を参照してください。 <h3 id="batching"> Batching </h3> Event Hubs でトリガーされる Function を記述して、単一のメッセージまたは複数のメッセージのバッチ処理を行うことができます。後者に関しては、とても優れた性能特性を持っています。スプリットする関数を例に取ってみましょう： <pre><code> public static async Task Run( EventData[] sensorEvent, PartitionContext partitionContext, IAsyncCollector outputWeatherData, IAsyncCollector outputSeismicData, TraceWriter log) { foreach (var sensorData in sensorEvent) { SensorType sensorType = SensorType.Unknown; try { if (sensorData.Properties.ContainsKey("SensorType")) { System.Enum.TryParse(sensorData.Properties["SensorType"].ToString(), out sensorType); } await ProcessEvent(sensorData, sensorType, partitionContext, outputWeatherData, outputSeismicData); } catch(Exception ex) { telemetryHelper.PostException(ex, sensorData, partitionContext.Lease.PartitionId, sensorType.ToString()); } } } </code></pre> このコードに関する主な注意事項： <ul> <li> イベントの配列は1回の実行で関数に渡されます </li> <li> 例外処理ブロックは、各イベントの処理をラップします </li> </ul> 配列ベースのアプローチは、各関数の実行よりもオーバーヘッドの面で優れています。このシステムは、関数を呼び出すときに多数のアクションを実行します。これらのアクションは、イベントごとに1回ではなく、イベントの配列に対して 1 回だけ発生します。注：JavaScript の Function の場合、バッチ処理を有効にするために、function.jsonの "cardinality" プロパティを明示的に "many" に設定する必要があります。（ <a data-linktype="external" href="https://github.com/Azure/azure-webjobs-sdk-templates/blob/df94e19484fea88fc2c68d9f032c9d18d860d5b5/Functions.Templates/Templates/EventHubTrigger-JavaScript/function.json#L10"> こちら </a> の例を参照してください） 例外処理に対するこのアプローチは、メッセージの消失/スキップを防ぐ場合に重要です。一般的には、後の処理/分析に失敗したイベントを格納するように例外ハンドラを作成します。 Azure Functions には Event Hub のデッドレターが組み込まれていないため、これは重要です。 <h3 id="webjobs-dashboard"> WebJobs Dashboard </h3> 上記のとおり、私たちは監視のためにApp Insightを使用していたので、ダッシュボードを無効にしました。アプリケーション設定で、 AzureWebJobsDashboard の設定を削除します。 <h3 id="partition-configuration"> Partition Configuration </h3> Azure Functions は Event Hubs SDK で提供される EventProcessorHost（詳細は <a data-linktype="absolute-path" href="https://docs.microsoft.com/ja-jp/azure/event-hubs/event-hubs-programming-guide#event-processor-host"> こちら </a> を参照）を使用して、Event Hub メッセージを処理します。 EventProcessorHost は、アプリケーションを実行する各VMが複数のパーティションのリースを取得し、それらのパーティションでメッセージを処理できるようにする仕組みです。つまり、Event Hub に 2 つのパーティションしかない場合、任意の時間に 2 つの VM しかメッセージを処理できません。つまり、パーティション数が Function のスケーラビリティに上限を設定します。 Event Hub の Basic と Standard には、Event Hub ごとに 32 個までのパーティションの既定の制限がありますが、 <a data-linktype="external" href="https://portal.azure.com/#create/Microsoft.Support"> 課金サポート </a> に問い合わせることでこの制限を増やすことができます。Event Hub を100 個のパーティションに設定することにより、各 Function を 100 台の VM で同時に実行することができるようになりました。天気データ用の Function を 1分間に実行した一意の VM の数を数えると、下記のような結果になります。 <img alt="" data-linktype="external" src="/blog/media/2017/09/query3.png"/> 別の簡単なクエリを使用して、94 台の VM 上で作業が均等に分散されているか確認することができます。 <img alt="" data-linktype="external" src="/blog/media/2017/09/query2.png"/> <img alt="" data-linktype="external" src="/blog/media/2017/09/04-distribution.png"/> <h3 id="partition-keys"> Partition Keys </h3> Event Hub のプログラミングガイドには、パーティションキーの <a data-linktype="absolute-path" href="https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-programming-guide#partition-key"> 概要 </a> と、それをいつ使用したらよいかが記載されています。このシナリオでは順序付けやステートフルな要件がないため、パーティションキーなしでイベントを生成しました。これにより、実行のスループットと可用性が向上しました。 <h3 id="protocol-buffers"> Protocol Buffers </h3> 1秒間に10万回以上のイベントを読み書きする場合は、シリアライズ・ステップを実行するのに要する時間とデータサイズの観点から、これらのイベントのシリアライゼーションとデシリアライゼーションを可能な限り効率的にしたいと考えています。 <a data-linktype="external" href="https://developers.google.com/protocol-buffers/"> プロトコルバッファー </a> は、扱いやすい高性能シリアル化フォーマットです。イベントから気象測定値のバッチをデシリアライズして処理するコードの例を次に示します。 <pre><code> if (sensorType == SensorType.Weather) { var batch = WeatherReadingBatch.Parser.ParseFrom(sensorData.GetBytes()); var messages = batch.SensorReadings .Select(reading => EnrichData(enqueuedTime, reading)); await WriteOutput(messages, sensorData.PartitionKey, outputWeatherData); } </code></pre> このシナリオで使用する.protoファイルを知りたい場合は、 <a data-linktype="external" href="https://gist.github.com/paulbatum/c918e19cadb43fdfcce978d58d97d235"> ここ </a> を参照してください。 <h2 id="section"> </h2> <h2 id="cost"> Cost </h2> Function App とその依存リソースを 9 日間実行するための費用総額は、 約 1,200 ドル でした。各サービスの 1 時間あたりのコストは次のようになります。 <table> <tbody> <tr class="odd"> <td> Service </td> <td> Cost per Hour (USD) </td> </tr> <tr class="even"> <td> Functions </td> <td> $2.71 </td> </tr> <tr class="odd"> <td> Storage </td> <td> $1.80 </td> </tr> <tr class="even"> <td> Application Insights </td> <td> $1.03 </td> </tr> </tbody> </table> 注目すべき重要な点は次のとおりです。 <ul> <li> このデータには、負荷ジェネレータおよびイベントハブのコストは含まれていません。これらの最適化には労力が費やされなかったためです。 </li> <li> Azure Storage の費用は、1 時間あたり約 5,000 万件のトランザクションに基づいています。これらのトランザクションのほとんどは、Event Hub のチェックポイントに関連しています。 </li> <li> Application Insightsの費用は、時間当たり 450 メガバイトのデータ収集量に基づいています。 </li> </ul> Azure Monitor REST API を使用して実行可能な実行カウントと実行ユニットのデータを使用することで、Function Appのコストをより詳細に把握できます（詳細は <a data-linktype="external" href="https://stackoverflow.com/questions/41128329/how-can-i-programmatically-access-azure-functions-usage-metrics"> こちら </a> ）。 1 時間分のデータを照会すると、次のようになります。 <ul> <li> Function Execution Counts: 6,500,012 </li> <li> Function Execution Units：90,305,037,184 </li> </ul> ここでのFunction Execution Units は、mb-milliseconds 単位で測定されることに注意してください。これらをgb-secondsに変換するには、1,024,000で割ります。（Function の価格設定の詳細は <a data-linktype="external" href="https://azure.microsoft.com/en-us/pricing/details/functions/"> ここ </a> にあります。簡単な補助プログラムは <a data-linktype="external" href="https://gist.github.com/paulbatum/2b16c5f92351ed1c59e3a2b8a727ca97"> ここ </a> にあります）： 時間あたりのコスト=（6,500,012回の実行*（$ 0.20 / 1,000,000））+（（90,305,037,184単位/（1024 * 1000））* $ 0.000016）= 2.71ドル <h2 id="summary"> Summary </h2> Azure Functions の従量課金プランは、何百もの VM 上で実行するようにアプリケーションをスケーリングすることができ、膨大な計算容量の確保のために料金を支払うことなく、高パフォーマンスが要求されるシナリオを実現可能にします。 Azure Functions の詳細とサーバレス技術でのクラウドアプリケーションの構築については、 <a data-linktype="external" href="https://azure.microsoft.com/en-us/services/functions/"> ここ </a> から始めてください。  </main>

_posts/2018-02-01-functions-100k-events-per-second.html (492 lines of code) (raw):