Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
meetup_20210608_kintai.pdf
Search
Yusuke Konno(Rakus)
June 10, 2021
Programming
1.6k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
meetup_20210608_kintai.pdf
RAKUS Meetup発表資料
https://rakus.connpass.com/event/211947/
Yusuke Konno(Rakus)
June 10, 2021
More Decks by Yusuke Konno(Rakus)
See All by Yusuke Konno(Rakus)
jjug_ccc_fall_ykonno.pdf
yusukekonnorakus
0
1.2k
20210901_lt.pdf
yusukekonnorakus
0
29
Other Decks in Programming
See All in Programming
音楽のための関数型プログラミング言語mimiumにおける多段階計算の活用
tomoyanonymous
1
380
AI時代のPHPer生存戦略 ~「言語、もうなんでもよくない?」に本気で向き合う~
vivion
0
220
これって Effect でできたのでは? / TSKaigi Mashup Kansai #2
susisu
0
140
Terraform標準の組織で AWS CDKをどう使うか
mu7889yoon
1
450
コーディングルールの鮮度を保ちたい for SRE NEXT 2026 / keep-fresh-go-internal-conventions-sre-next-2026
handlename
0
160
OpenSpecのproposalにbrainstormingを持たせてみた
tigertora7571
1
180
SREの積み重ねがAI駆動開発のガードレールになった ― 7つの実践/SRE Guardrails The 7
tomoyakitaura
9
6k
Embedded SREと共に達成した会員管理システムのAWS移行 - SRE NEXT 2026 ランチスポンサーセッション
niftycorp
PRO
1
3.3k
Claude Opus 4.6以後の受託開発エンジニアの変化(Claude Code開発ノウハウ大公開スペシャルbyクラスメソッド)
iidatakuma
1
930
変わらないものが、変わるものを決める — 意図駆動開発 × イベントソーシング × イミュータブル | What Doesn't Change Decides What Can — IDD × Event Sourcing × Immutability
tomohisa
0
1k
TSX の <Hoge<Fuga>> という構文に驚いた話 / tsx-type-argument-syntax
kanaru0928
0
190
Japan Community Day at Kubecon + CloudNativeCon Japan 2026: Learning Container Privilege Control by Building My Own Low-Level Container Runtime
ternbusty
1
120
Featured
See All Featured
Optimizing for Happiness
mojombo
378
71k
Automating Front-end Workflow
addyosmani
1370
210k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
680
A Modern Web Designer's Workflow
chriscoyier
698
190k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
420
Ethics towards AI in product and experience design
skipperchong
2
330
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
500
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
1
380
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.9k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
230
GitHub's CSS Performance
jonrohan
1033
470k
Transcript
#RAKUSMeetup ©2021 RAKUS Co., Ltd. 新機能開発の アーキテクチャ選定 楽楽勤怠開発課 今野裕介
#RAKUSMeetup 今野裕介(こんのゆうすけ) • 開発本部・第三開発部・楽楽勤怠開発課所属 • バックエンドエンジニア • 2020/7/1入社 ◦ 前職ではレコメンドエンジンASPサービスの設計・開発・運用・
保守を担当 ◦ 現在は打刻機能をメインに新機能開発を担当 • 趣味 ◦ カメラ・城巡り
#RAKUSMeetup 楽楽勤怠の紹介 • クラウド型勤怠管理サービスです • 2020/10に初期リリース後、ほぼ毎月新機能リリース中!
#RAKUSMeetup ICカード打刻機能 • 2021/2/16(火)にリリース • 端末はPitTouchPro2を利用 ◦ PCがなくても打刻が可能 ◦ 工場や店舗など、PCが持ち込めない環境でも打刻が可能
• 端末はラクスから販売したもののみ利用可能
#RAKUSMeetup PitTouchPro2の概要 • 打刻(出退勤・休憩・外出)やカード登録削除が可能 • リクエストはXHR Level2で行われている ◦ 組み込みのSafariが内部で稼働している模様 •
NWに問題がある場合には打刻を再送する機能が存在する ◦ 端末内部に打刻データを保存しておき、NWが再開すると再送する • ICカードはFeliCa、Mifareに対応
#RAKUSMeetup PitTouchPro2外観
#RAKUSMeetup ICカード打刻の要件 • PitTouchPro2端末による出勤打刻および退勤打刻ができる • PitTouchPro2端末によるカード登録・削除ができる ◦ 登録削除用に従業員照会も実施できる • 楽楽勤怠がメンテナンス中の場合、打刻データが失われない
◦ メンテ以外でも不慮の事故でデータが失われない
#RAKUSMeetup 打刻データの性質 • エンドユーザーの行動ログの一つである • データは失われてはいけない ◦ 失われるとエンドユーザーは勤怠時刻申請が必要になる ◦ 頻繁に失われていると楽楽勤怠への信頼性が下がる
◦ データが失われないための機構が必要 • 重複しても(大きな)問題がない ◦ 同じ日時の打刻を何回繰り返しても、勤怠計算上は影響がない ◦ 影響を受けるのはパフォーマンス面だけ
#RAKUSMeetup アーキテクチャ図 PitTouchPro2 打刻アプリ ケーション 楽楽勤怠 同期バッチ ① ④ ②
③ A B
#RAKUSMeetup RabbitMQ • 打刻データの保存のために採用 ◦ 社内での導入実績がある ◦ 公式ドキュメントなど、情報量が豊富 • バージョンは3.8系
◦ ErlangはZero-dependency Erlang RPM for RabbitMQの23系を採用 • クラスター構成
#RAKUSMeetup Resilience4jの採用 • Javaのフォールトトレラント用のライブラリ • サーキットブレーカー、リトライ、流量制御、タイムアウトハンドリングなどができる • 今回は以下を採用 ◦ サーキットブレーカー
▪ 打刻アプリケーション => 楽楽勤怠のAPI通信のみ(図中②) ◦ リトライ ▪ 楽楽勤怠API通信箇所(図中②およびB) ▪ RabbitMQへのPublish(図中③)
#RAKUSMeetup Resilience4jの採用箇所 PitTouchPro2 打刻アプリ ケーション 楽楽勤怠 同期バッチ ① ④ ②
③ A B サーキットブレーカー+リトライ リトライのみ
#RAKUSMeetup やってみた感想 • 実現すべき事自体はシンプル • 事故った時の想定をどこまでやるかが大変 ◦ RabbitMQの採用、リトライ、サーキットブレーカーの適用 ◦ 異常系のテストが大変
• 情報量の偏り ◦ RabbitMQは公式ドキュメントや英語文献が豊富 ◦ Resilience4jは公式のサンプルコードすら動かなくて辛い