Kyash DirectにおけるMicroservicesのリトライ処理
この記事は Kyash Advent Calendar 2019 の9日目の記事です。
Kyash DirectではMicroservices Architectureを採用しています。
この記事ではMicroservicesでのリトライ処理をどのように行なっているかを紹介させていただきます。
イベントドリブンに行われるMicroserviceの処理
Kyash Directはサービス間の通信を非同期に行なっています。Microservices群の1サービス内で何かしらの処理が発生した後、イベントと呼ばれるデータをpublishします。
publishされたイベントをsubscribeしているサービスは、イベントを受信すると処理を開始し、完了後同じようにイベントをpublishします。このように、イベントをトリガーにして各サービスが自律的に動作する仕組みになっています。
イベント受信後の処理に失敗したらリトライを開始する
イベント受信後、様々な理由で処理が失敗する場合もあります。
publishされたEventを送信側が再送してくれることはないため、処理が成功するまでイベントをsubscribeしている側がリトライする必要があります。
Kyash Directではリトライ処理のアルゴリズムにExponential backoff と jitterを採用しています。
リトライ回数とタイミングの衝突を抑制するExponential backoffとjitter
Exponential backoffはインターバルをおいてからリトライを実行しますが、回数を重ねる毎にインターバルが指数関数的に増加してくのが特徴です。
初回リトライまでのインターバルは1秒、2回目は2秒、3回目は4秒と回数を重ねる毎にインターバルを長くします。
Exponential backoffのメリットは障害発生時にシステムへの不必要な負担を軽減できることです。
仮に「3秒ごと」などの固定値でリトライ処理を行うと、全処理が同じタイミングでリトライを実行することになるため、システムに不要な負荷をかける可能性があります。
リトライする度インターバルを指数関数的に増加させることで、全体のリトライ回数とシステムへの不要な負荷を抑えることが可能になります。
Exponential backoffでリトライ回数を抑制することが出来ましたが、複数処理でリトライが発生した場合、リトライのタイミングが競合してしまう可能性が考えられます。
それを解決するのがjitterです。jitterは乱数を用いてインターバルにゆらぎを導入します。jitterを用いることで複数処理で発生したリトライタイミングの衝突を抑制する効果があります。
リトライの最大試行回数はイベントを処理するHandler毎に設定出来るようにしています。
まとめ
Kyash DirectにおけるMicroservicesのリトライ処理の雰囲気を感じ取って頂けたら幸いです。