楽楽勤怠開発1課のy_konnoです。
先日開催されたJJUG CCC 2022 Fallに登壇しましたので、今回はそのレポートになります。
プロポーザル
マイクロサービスにおいては一部のサービスが障害を起こして応答が不能になったり、ネットワーク的にリクエストが到達不能になることがあります。その際に無対策だと連鎖的に各サービスがダウンし、アーキテクチャー全体が機能不全に陥ってしまいます。
対策としてはサーキットブレーカーの適用が挙げられます。サーキットブレーカーは局所的な障害がアーキテクチャー全体に波及しないように障害を分離する機構です。しかし、自力で実装するのはコストが高いのが難点です。
Resilience4jはJavaでフォールトトレランスを実現するためのライブラリです。数多くの機能を備えますが、その中の一つにサーキットブレーカーがあります。本セッションでは以下内容について解説したいと思います。
- Resilience4jの概要
- Resilience4jを利用したサーキットブレーカーの実現方法の解説
- Resilience4jを利用したリトライの実現方法の解説
- 弊社サービスである「楽楽勤怠」での適用例
登壇資料
登壇を振り返って
今回はセッション本体が動画配信で、質疑応答がリアルタイムという形式でした。動画は15分という制限時間があったので、なるべくシンプルかつ利点がストレートに伝わるように、Resilience4jの適用方法を3ステップに分けて解説してみました。
Resilience4j自体あまりメジャーではないので、テーマ被りの心配はしていませんでしたが、やっぱり被らずに済みましたw
表題としてはサーキットブレーカーをメインに据えていますが、個人的にResilience4jを使っていて最もありがたいポイントはリトライをものすごく簡単に実装できるところですね。質疑応答前に運営の方とも話をしたんですが、リトライのコードを自前で書いてつらいという話は各所で出ているのでこういったライブラリはありがたいとおっしゃってましたね。
以下は頂いた質問に対する回答をいくつか
Q：競合ライブラリは検討したか？
A：正直なところ、Resilience4jが真っ先に出る上にメンテされてるので、一択なところがありました。かつてはNetflixがサーキットブレーカー用のライブラリを出していたんですが、それがディスコンになっているのも影響はでかいと思います
Q：楽楽勤怠の事例においてミドルウェアではなくあえてJava側でやった理由は？
A：リトライを併せて使いたかったことと、インフラ構成を増やしたくなかったのが理由になりますね。あとは打刻アプリケーションは様々な顧客向けにリクエストを飛ばす関係上、振り分けのロジックを管理するのがJavaでやるほうが都合が良かったというのもあります
Q：タイムアウトなどの値はどう設定しているか？
A：正直、手探り感があるところです。リトライでウェイトする秒数などはサービスで応答目標としている秒数があるのでそちらを下回るように計算しています。他方、サーキットブレーカーにおけるリングバッファのサイズなどは暫定で決めています。
まとめ
マイナーなネタなので質問が全く来ないことを危惧しましたが、なんとか関心を集めることはできたようで安心しました。
リトライ目的からスタートしてResilience4jを導入する人が増えてくれると嬉しいですね。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/
カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.com
ラクスDevelopers登録フォーム
https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/
イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！
◆TECH PLAY
techplay.jp
◆connpass
rakus.connpass.com
