firequeueの改修 ~非同期処理で45%のAPIレイテンシ削減を実現~

Natureエンジニアインターン生の後藤です。この記事では、インターン期間中に取り組んだfirequeueの改修についてお話します。

背景

NatureのバックエンドにはNature Remoからメッセージを受け取るエンドポイントがあるのですが、このエンドポイントはメッセージが来るたびに叩かれるので、NatureのAPIサービスの中で最も合計レイテンシとリクエスト数が大きいものとなっています。

詳しくこのAPIのレイテンシの内訳を見てみると、その中でもFirehoseが占有している時間が40%と最も長くなっていました。

また、Natureではfirehoseへの送信にfirequeueというGo言語のpackageを使用しています。firequeueは、Amazon Kinesis Data Firehoseへのアイテムの投入をインメモリキューで保証してくれるものとなっています。つまり、こちらからは再送の処理を書かずともいい感じにしてくれるわけです。

問題の分析

既存のfirequeueでは同期的にFirehoseに送信している事に着目しました。そこで私はfirequeueに非同期で送信を行う機能を追加することでAPIのレイテンシを大きく削減できると考えました。

firequeueの改修

firehoseに送信を非同期で行うためには、いろいろな方法があげられます。そのため、いくつかの設計を考え、pros/consをまとめチームで設計レビューの機会をいただきました。設計案の例をあげると、都度イベントを送るたびにそれを非同期実行することです。この方法は既存のコードを使い回すことができるので実装が比較的容易です。しかしながら、goroutine数を適切に管理しないと、goroutine数が多すぎる場合はメモリ消費が増大し、システムのパフォーマンスが低下する可能性があります。逆に、goroutine数が少なすぎると並列処理の機会を逃し、アプリケーションの応答性が損なわれることがあります。

このような問題を避けるために、私は非同期かつバッチで送信する機能をfirequeueに追加しました。APIのレイテンシの問題は非同期で送信することで解決し、複数のデータを一つのバッチとしてまとめて送信することで、送信回数を減らし、ネットワークやシステムの負荷を軽減することができます。下図に今回作成した機能の概略を示します。簡単に説明しますと、クライアントは送信したいデータをキューに追加するだけで良いので、送信によるオーバヘッドがなくなります。キューは一定時間ごとに自身の状態を確認し、キューにデータが存在する場合にFirehoseにデータをバッチで送信します。

改修結果

firequeue改修後の結果がこちらです。水色の線が改修前、グレーの線が改修後のAPIのレイテンシとなっています。Firehoseへの送信のオーバヘッドを無くしたので当然ですが、こちらのグラフからAPIのレイテンシが削減されていることが確認できます。実際に平均値を確認してみると、改修前の平均が42.8msに対し、改修後は23.4msと約45%ほど削減することが出来ました！

まとめ

今回はAPIのレイテンシを減らすために、firequeueに非同期かつバッチで送信を行える機能を追加しました。その結果、45%ほど削減することができました。また今回のfirequeueの改修を通して、非同期処理の面白さと難しさの両方を体感することができました。firequeueはNatureがOSSとして公開しているので興味があれば試してみてください。

github.com

インターンの感想&すゝめ

私がインターンに参加したのは6ヶ月ほどとインターン生としては短い間でしたが、大変良い経験を得ることが出来ました。特に、個人開発とは異なって実際に使用されているコードの改修・作成を行えるのはインターンならではの体験でした。さらに、Natureには多くの経験豊かなエンジニアが在籍されているので、遭遇する問題や疑問に対して迅速かつ的確なアドバイスを受けることができ、良質なコードを作成するための知見を深めることができました。私は修士２年生と比較的忙しい時期での参加となりましたが、学業との両立も行いやすかったです。

私の感想がこれからNatureでインターンを考えている方々の参考になれば幸いです。