TECH PLAY

プログラミング

むベント

マガゞン

技術ブログ

ミむダステックチヌムです 2026幎6月にt_wadaさんをお招きし、「2026幎の゜フトりェア開発を考える」ず題した瀟内勉匷䌚を開催したした。前回ご登壇いただいた2024幎の講挔から2幎、゜フトりェア開発の珟堎はすっかり様倉わりしたした。瀟内からも再講挔のリク゚ストが倚かったt_wadaさんのご講挔をレポヌトしたす。
はじめに ITD2-2-3のI.Hです。今回、RubyKaigi 2026 in 凜通に参加する機䌚をいただきたした。 RubyKaigiは、Ruby本䜓や゚コシステムに関する最新の知芋が集たる技術カンファレンスです。 今回の参加を通しお、Rubyそのものに぀いお孊べたのはもちろん、他瀟゚ンゞニアずの亀流やスポンサヌむベントでのLT登壇など、普段の業務だけでは埗られない倚くの経隓をするこずができたした。 この蚘事では、Rubyに関する知芋の共有だけでなく、技術むベントに参加するこず自䜓の意味や䟡倀に぀いおもあわせおたずめたした。 Day0(むベント前日) 凜通に前日入り 堎所が北海道の凜通ず蚀うこずで、圓日出発では間に合わないため前日の倜に出発したした。 空枯に到着するず、空枯の至る所にRubyKaigiの看板や垂れ幕がありたした。 たた、路面電車の車内倖にもRubyKaigiの看板が。町おこしさながらの盛り䞊がりでした。 空枯で明らかにrubyistの方第䞀rubyistを芋かけたので、タクシヌに盞乗りしたした。 有名なラヌメン屋さんで降りるずのこずだったので、䞀緒に食べながら技術の話やお互いの䌚瀟の制床・AIツヌルの導入状況などに花を咲かせたした。 Day1 䌚堎ぞ 䌚堎は、JR凜通駅から垂電で30分ほどの堎所にある「 凜通サヌモン・たるなたアリヌナ/ホヌル 」でした。呜名暩を地元の氎産䌚瀟が取埗されたらしく、凜通感党開の良い䌚堎名ずロゎになっおたした。 チェックむンするず、銖から掛けるストラップず名札をいただきたした。 䌚堎で「どこの䌚瀟の方ですか」ず床々聞かれるので匊瀟のロゎを手曞き。 なんずか䌝わりたした。 基調講挔 The Journey of Box Building 発衚資料はこちら 初日の講挔は、rubyコミッタヌでもある田籠 聡さんの基調講挔から始たりたした。 内容は、2025幎12月25日にリリヌスされた  Ruby4.0.0  ã®æ–°æ©Ÿèƒœã®äž€ã€ã§ã‚る、 Ruby::Box  ã«ã€ã„おでした。 Ruby Boxはクラス等の定矩の分離隔離のための機胜を提䟛する、実隓的機胜です。 実隓的な機胜ずしお䜍眮付けられおいるずのこずでしたが、安党にコヌドの分離ができるようになる点は業務にも掻かせそうでした。 Exploring RuboCop with MCP 発衚資料はこちら Keynote以倖の公挔は基本的に倧ホヌル・小ホヌル・サブアリヌナで行われ、同時刻に開催される講挔に同時に参加するこずはできないため、タむムスケゞュヌルず発衚内容を芋お遞ぶ圢匏でした。 英語での講挔も倚く、同時翻蚳アプリで聎くこずにも挑戊したしたが、やはり日本語の講挔の方が理解しやすく、自然ず日本語の講挔を遞ぶこずが倚かったです。 そんな䞭で、初日の午埌に参加した䌊藀浩䞀さんの RuboCop  x MCPの話が印象に残りたした。 RuboCopは人間や他のプログラムによっおトリガヌされおいたした。AI時代においおは、AI゚ヌゞェントが新たなトリガヌずしお登堎したした。本講挔では、生成型AIずリンタヌおよびフォヌマッタヌを組み合わせる実践的な方法に぀いお議論したす。 決定性がLinterずしおの䟡倀だった䞭で、非決定性を持぀LLMを組み合わせるこずでどんな䟡倀が創出できるのか又は倱われるのかずいう詊行錯誀の話が面癜く、こういったむベントに参加しお盎接コミッタヌの方のお話を聞く醍醐味だず感じたした。 Day2 基調講挔 Twenty Years of JRuby 2日目は20幎以䞊 JRuby Java仮想マシン䞊で動䜜するRubyの凊理系を開発しおいる、Charles Nutterさんの基調講挔から始たりたした。 内容はJRuby が誕生しおからの20呚幎の振り返りず、JRuby 10.1 のリリヌスに぀いおでした。 業務を含めこれたでCRubyC蚀語で実装されたRubyの凊理系しか觊ったこずがなかったのですが、JRubyやMRubyのような別の凊理系にも興味が湧きたした。 Practical TypeProf: Lessons from Analyzing Optcarrot 発衚資料はこちら 2日目は TypeProf 開発者の 遠藀䟑介さん の講挔が印象に残りたした。 メむンの話は、TypeProfを実際に適甚しおみた事䟋です。題材に遞ばれたのは、発衚者自身が開発したRubyで曞かれたNESファミコンの゚ミュレヌタで、玄6000 行の耇雑なコヌドに TypeProf を適甚したずころ600個以䞊の゚ラヌが出たずのこずです。 察応ずしおは、型掚論結果に匷く圱響する箇所にRBSを曞くこずず、TypeProf 偎の誀認識の根本原因を盎すこずの2方向から進められ、最終的には Ruby 55行RBS 67行、合蚈122行の倉曎でれロ゚ラヌに到達したずのこずでした。SteepやSorbetず比べおも、既存コヌドぞの倉曎量がかなり少ないずいう結果でした。 終盀では、AI コヌディング゚ヌゞェントが普及する䞭でTypeProfをどう䜍眮づけるのか、ずいう問いも提瀺されおいたした。゚ディタ支揎を䞻目的ずしおきたツヌルが、AI 時代にどんな䟡倀を持おるのかずいう点に぀いおも蚀及されおいたした。 Day2の亀流䌚 2日目の倜は、Drink Upに参加し、LT枠が空いおいたので発衚したした。 3日目のRubyKaigiがより面癜く聞けるようにず思い、Rubyが実行されるプロセスをParserの話からGCの話たで、䞀通りたずめおみたした。 資料は marp  + Opus4.6で䜜成 Day3 Lightning-Fast Method Calls with Ruby 4.1 ZJIT 発衚資料はこちら RubyKaigi最終日は、 囜分厇志 さんのZJITの講挔が印象に残りたした。 泚目床の高い ZJIT ですが、今回の発衚では特にメ゜ッド呌び出しの高速化に焊点が圓おられおいたした。 Rubyでは䟝然ずしおメ゜ッド呌び出しのオヌバヌヘッドが倧きく動的型付けだから仕方ないが、YJIT によっお改善が進んできた珟圚でも、なお倧きなボトルネックずしお残っおいるそうです。ZJIT ではこの凊理の最適化が倧きなテヌマになっおおり、バックトレヌスや䟋倖凊理、ロヌカル倉数アクセスに必芁なメタデヌタをどう保持し぀぀、無駄なメモリラむトを枛らすかが論点になっおいたした。 そこで玹介されおいたのがLightweight Framesでした。これは、メ゜ッド呌び出し時に必芁なフレヌム情報を最初からすべおメモリに曞き蟌むのではなく、必芁になるたで遅延させ、たずは最小限の情報だけを持぀こずでコストを䞋げるアプロヌチです。 Rubyの柔軟な曞き心地は維持し぀぀、高速に動くようにしおいく取り組みをしおいただいおる事に感謝です Matz Keynote もちろん最埌は、Rubyを䜜った「 た぀もず ゆきひろ 」さんMatzの基調講挔でした。 ここ半幎くらいは自分でコヌドを曞かずに、ほが党おAIに曞かせるずいう瞛りを自らに課しおいるずのこずでした。コヌドレビュヌやプロンプトを现かく制埡できるからこそできる事だず思いたすが、実務の珟堎でもAI゚ヌゞェントは欠かせない存圚になっおきおいるのではないでしょうか。 そんな䞭で倧きなトピックは、新しいRubyのAOTコンパむラ「 Spinel 」の発衚です。RubyコヌドをC蚀語に倉換しおからコンパむルするこずで、ネむティブバむナリを生成するずいう詊みで、すぐに業務レベルで圹立おられるものではなさそうですが、むンタプリタ蚀語×AOTコンパむルずいう発想ず開発過皋が興味深かったです。Rubyは動的機胜が倚いので、機械語にできる=高速化ではないこずに泚意しおください たずめ RubyKaigiに行っお良かったず思う1番のポむントは、Rubyやプログラミングが倧奜きな人達の「熱」を感じられたこずでした。普段「仕事」ずしおプログラミングをしおいるず商業的な芳点で䟡倀を枬り枬かられる癖が぀いおしたっお、楜しいずか知的探求ずいう偎面を忘れおいたなぁず思いたした。 たた、珟地での他瀟の゚ンゞニアずの亀流も刺激的でした。今たで自分がマむナビ色に染たっおいる自芚はありたせんでしたが、他瀟の゚ンゞニアず亀流するず明らかに各瀟個性ずいうか雰囲気があっお、たたには芖野を広げるためにも亀流しお新しい知芋を持ち垰っおくる必芁があるず感じたした。
はじめに こんにちは、バック゚ンド゚ンゞニアの小笠原 @yukineko_819 です。 Checkout Reliabilityチヌムに所属し、負荷詊隓環境の構築や賌入ロゞックの最適化など、賌入䜓隓の信頌性向䞊に向けた取り組みをしおいたす。 今回は、「どのショップでも、い぀でも安定しお賌入できる」ずいう賌入䜓隓を守るために、賌入時のクレゞットカヌド決枈ぞ流量制埡以降、レヌトリミッタを導入した話をご玹介したいず思いたす。ずくに、 特定のショップに賌入が集䞭しおも、ほかのショップでは決枈ができる状態にする ために、アクセス集䞭の圱響をできる限り抑え、党䜓の賌入可甚性を平準化する蚭蚈をどう考えたか、ずいうずころが䞭心になりたす。 あるショップにアクセスが集䞭しおいる時、ほかのショップで賌入ができない たずは、私たちが解きたかった問題からお話しさせおください。 䞀般的に、決枈凊理には安定皌働のために単䜍時間あたりに捌ける流量の䞊限が蚭定されおおり、これを決枈流量制限以降、決枈レヌトリミットず蚀いたす。平垞時であればこの決枈レヌトリミットを意識するこずはほずんどありたせん。しかし、倧型の販売むベントや限定商品の販売ずいったケヌスで、特定のショップに察しおごく短期間に賌入が䞀気に集䞭しおいる時、この決枈レヌトリミットが問題になりたす。 このずき、賌入が集䞭しおいるショップの決枈で決枈レヌトリミットに達するず、たったく無関係なほかのショップにも圱響が及んで制限がかかり、賌入できなくなっおしたう可胜性がありたす。 これは賌入者から芋れば、自分にもショップにも䜕の萜ち床もないにもかかわらず賌入できない、ずいうマむナスの䜓隓ずなっおしたいたす。ネットショップの買い物䜓隓ずしお、これほど避けたいものはないでしょう。 い぀でも買えるカヌトを目指しお そこで私たちが目指したのは、特定のショップに賌入リク゚ストが集䞭しおいる状況でも、ほかのショップではい぀もどおり賌入できる状態を保぀こずでした。これを実珟するために、次の2぀を満たすレヌトリミッタの蚭蚈を考えたした。 1. 流量を自分たちで把握しお制埡する ひず぀めは、流量を自分たちでカりントしお胜動的に制限をかけるこずです。決枈レヌトリミットに到達しおいるか吊かわからないたた決枈を実行するのではなく、安定しお捌ける範囲の䞊限を自瀟偎で定矩し、あえお胜動的に流量を絞る方針を取りたした。 2. その他のショップの取り分を「匕き算」で残す ふた぀めは、アクセス集䞭ショップずその他のショップを分けお管理するこずです。これたではアクセス集䞭ショップが流量を独り占めしおしたい、その他のショップの決枈が通らなくなっおしたう危険がありたした。そこで、あえおアクセス集䞭ショップに本来の䞊限倀よりも少しだけ䜎い䞊限を蚭定し、残った流量をその他のショップが䜿えるようにする、ずいう方針を取りたした。 この蚭蚈のポむントは、その他のショップ甚の流量を予め確保しおおくのではなく、アクセス集䞭ショップの䞊限倀にキャップをかける圢にしたこずです。アクセス集䞭ショップずいっおも垞に䞊限に匵り付いおいるわけではありたせんし、その他のショップでの賌入がたたたた同時刻に重なっおリク゚スト数がはね䞊がる可胜性もありたす。この方針は、その他のショップ偎の流量に䞍芁な制限をかけおしたわないようにするずいう意図がありたす。 図1: アクセス集䞭の圱響を抑え、その他のショップの取り分を「匕き算」で残す どう䜜ったか ここからは、より具䜓的な凊理フロヌの話に移りたいず思いたす。 決枈を実行する盎前に、1トヌクンを芁求する レヌトリミッタをどこに挟むべきか怜蚎した時、私たちは決枈凊理を実行する盎前に挟むこずにしたした。 決枈凊理は、その実行前にレヌトリミッタぞ「1トヌクンください」ず芁求したす。このレヌトリミッタの実䜓は、専甚のRedis䞊でアトミックに実行される Luaスクリプトで、叀兞的なトヌクンバケットずしお振る舞いたす。 なぜLuaなのかずいうず、「トヌクンの回埩 → トヌクン残量を確認する → トヌクンを消費する」ずいう䞀連の刀定をひず぀のアトミックな操䜜にたずめたかったからです。こうしおおけば、同時に倧量のリク゚ストが来おも、競合するこずなく正しくカりントできたす。 このレヌトリミッタは、トヌクンが残っおいればトヌクンを消費しおOKを返し、制限ず刀定されればNGを返したす。レヌトリミッタを呌び出したアプリケヌション偎は、刀定がOKであればそのたた倖郚APIを実行しお決枈に進みたす。NGであれば倖郚APIを実行するこずなく、決枈を諊めお凊理を゚ラヌで終了させたす。 グロヌバルバケットずアクセス集䞭ショップ甚バケットの2段構成にする ただ、総量を制埡するだけでは足りたせん。先着順でトヌクンを奪い合うず、アクセス集䞭ショップが党おのトヌクンを独占しおしたい、その他のショップが締め出されおしたうからです。これでは今たでず䜕も倉わりたせん。 そこで䞭栞になるのがアクセス集䞭ショップ甚に別途専甚のトヌクンバケットを甚意するずいう方法です。 党ショップが共通のグロヌバルバケットからトヌクンを消費する アクセス集䞭ショップだけアクセス集䞭ショップ甚バケットからも远加で消費する アクセス集䞭ショップ甚バケットの䞊限をグロヌバルバケットより小さく蚭定する ポむントは、アクセス集䞭ショップではないショップ向けのバケットを明瀺的に確保しおいるわけではない、ずいうずころです。あえおアクセス集䞭ショップ偎を絞るこずで、その差分がその他のショップの取り分ずしお匕き算で自動的に残るようにしおいたす。 この蚭蚈には、 work-conserving 䜙力を遊ばせないずいう嬉しい性質がありたす。アクセス集䞭ショップがなければグロヌバルバケットは誰でも䜿えるので、トヌクンが䜙るこずはありたせん。アクセス集䞭ショップが珟れお初めお、その分だけアクセス集䞭ショップ甚バケットの制玄が効き始める、ずいうわけです。 刀定のルヌルを敎理するず、次のようになりたす。 アクセス集䞭ショップ  グロヌバルバケットずアクセス集䞭ショップ甚バケットの䞡方に空きがあっおはじめお蚱可。 その他のショップ グロヌバルバケットに空きがあれば蚱可。 図2: その他のショップはグロヌバルバケットだけ、アクセス集䞭ショップは䞡方の空きが必芁 なお、レヌトリミッタが制限ず刀定したずきはトヌクンを消費しないようにしおいたす。これは、匟いたリク゚ストでトヌクンを消費しおしたうず本来なら通せたはずの埌続のリク゚ストにたで圱響が及んでしたうからです。 アクセス集䞭ショップをどう芋分けるか アクセス集䞭ショップをどう刀定するか、ずいう点にも少し工倫が芁りたした。 玠朎に閟倀だけで刀定するず、ショップの状態が閟倀の前埌で行ったり来たりしおしたい、挙動が安定したせん。 そこで、ショップごずに単䜍時間あたりの決枈リク゚スト回数をカりントし、䞀定以䞊に達したらアクセス集䞭ショップず刀定するようにしたした。さらに、䞀床アクセス集䞭ショップず刀定されたらしばらくはそのフラグを匕き継ぐクヌルダりン期間を蚭けおいたす。このクヌルダりン時間は、実際の過去のリク゚ストの状況を分析しお決定したした。 Off → Observe → Enforce、3぀のモヌドで段階的に出す 決枈ずいう事故が蚱されない経路に新しい制埡、それも決枈を胜動的に遮断する機胜を入れるわけですから、リリヌスの手順は慎重に怜蚎したした。いきなり遮断するようなこずはせず、フィヌチャヌフラグで3぀のモヌドを切り替えられるようにしお段階的にリリヌスできるように蚭蚈したした。具䜓的には、以䞋の3぀のモヌドを管理画面から瞬時に切り替えられるような䜜りにしたした。 Off 完党な機胜OFF状態。Redisにも通信しない、完党に無害な状態で本番に導入する。 Observe 制限の刀定はするが、制限はせずに党お蚱可する状態。「もし遮断しおいたら、い぀・どれだけ匟いおいたか」を蚘録するだけにずどめる。このモヌドで誀っお制限しおしたうケヌスがないかを本番のデヌタで実枬する。 Enforce 制限の刀定を行い、遮断も実行する状態。この状態で初めお本栌的なレヌトリミッタの挙動がリリヌスされる。 䞇が䞀 Enforce で誀った遮断が起きおも管理画面からフラグを即座にObserveぞ戻すだけで、デプロむなしに誀遮断を解陀するこずができたす。さらに、この状態の蚈枬自䜓は継続するこずで、䜕が起こったか埌から分析できるように情報を残すこずもできたす。この「デプロむなしで止められる」「埌から分析できるデヌタも残せる」ずいう安心感は、本番に投入しおいくうえで倧きく効いたず感じおいたす。 レヌトリミッタで決枈を止めないようにする 圓然ですが、流量制埡のために導入したレヌトリミッタ自身が新たな障害点になっおしたっおは本末転倒です。レヌトリミッタの䞍調で決枈党䜓が止たっおしたうのは、避けたい事態の䞭でも最悪の郚類だずいえたす。 そこでRedisに異垞があったずきは刀定をスキップしお決枈を通すfail-open方針にしたした。「厳密に䞊限を守るこず」よりも「決枈を止めないこず」を優先する、ずいう䟡倀刀断です。あわせお、刀定にかけるタむムアりトはごく短期間に蚭定し、Redisが重くなったずきも玠早く安党偎に倒れお、決枈の本流の足を匕っ匵らないようにしおいたす。 すべおの刀定を芳枬する 最埌は芳枬の話です。すべおの刀定経路で、レヌトリミッタの呌び出し毎に1぀のむベントを蚘録するようにしたした。 蚘録しおいるのは、どのモヌドで動いおいたかOff / Observe / Enforce、蚱可したのか制限したのか、制限刀定の理由グロヌバルバケットで匟いたのか、アクセス集䞭ショップ甚バケットで匟いたのか、凊理にかかった所芁時間、そしおfail-openが発生したかどうか、ずいった情報です。 特に Observe モヌドで蚘録した「もし遮断しおいたら匟いおいたはずの量」は、Enforce ぞ昇栌しおよいかを刀断するための䞀次デヌタになりたす。たた、レヌトリミッタが事前に遮断したものず、決枈凊理そのものが倱敗したものずでは意味がたったく異なるので、ログには専甚のタグを付けお、䞡者をはっきり区別できるようにしおいたす。 おわりに 今回は、賌入時のクレゞットカヌド決枈に流量制埡を導入した話をご玹介したした。 やったこずを䞀蚀でたずめるず、 特定のアクセス集䞭ショップに賌入が集䞭しおも、その他のショップに圱響が及ばないように、限られた決枈の流量を胜動的に制埡するこずで受け止められるようにした 、ずいうこずになりたす。決枈の流量を1぀のグロヌバルカりンタで枬っお制埡し぀぀、アクセス集䞭ショップ甚バケットによっおアクセス集䞭ショップの流量に少しだけき぀めの制限を蚭け、その他のショップの決枈分を匕き算で残す。そしお3぀のモヌドで安党に段階リリヌスし、䞇が䞀レヌトリミッタ自身が䞍調になっおもfail-openで決枈を止めない。 ひず぀補足しおおきたいのは、これは「決枈の凊理胜力がこれ以䞊䌞ばせないから絞っおいる」ずいう話ではない、ずいうこずです。実は、既存の実装を敎理するこずで、レヌトリミッタを導入しおもなお、単䜍時間あたりに捌ける決枈の流量そのものはむしろ増えおいたす。だからこそ今回、思い切っおアクセス集䞭ショップに制限を蚭けるずいう刀断ができたした。レヌトリミッタ導入前ず比べおも、アクセス集䞭ショップが単䜍時間あたりに賌入できる流量はむしろ増えおいるのです。 そのうえで、限られたリ゜ヌスのバランスを短期的に取るための手段ずしお、レヌトリミッタによる制埡を䜵甚しおいる、ずいう䜍眮づけです。䞀郚のショップぞのアクセス集䞭でシステム党䜓が䞍安定になれば、圱響を受けるのはほかのショップだけでなく、アクセスが集䞭しおいるショップ自身も同じです。党䜓を安定しお動かし続けるこずこそが、結果的にすべおのショップの賌入機䌚を守るこずに぀ながるず考えおいたす。 もちろん、ここで満足しおいるわけではありたせん。凊理胜力そのものの匕き䞊げや、ほかの遞択肢の怜蚎も含めお、「どのショップでも、い぀でも買いやすいカヌト」を目指しお改善を続けおいきたす。 掟手な機胜ではありたせんが、「どのショップでも、い぀でも賌入できる」ずいう圓たり前を裏偎で支える仕組みずしお、地味に効いおくれるものになったのではないかず思っおいたす。今回のような改善はナヌザヌの目に盎接芋えるものではありたせんが、快適な賌入䜓隓のために、Checkout Reliabilityチヌムではこういった现やかな改善を匕き続き積み重ねおいきたす。 BASE では、「どのショップでも、い぀でも賌入できる」ずいう圓たり前を、こうした地道な蚭蚈ず運甚で支えおいく仲間を募集しおいたす。カヌトや決枈たわりの信頌性に興味がある方は、ぜひお気軜に採甚情報をご確認ください。 binc.jp

動画

曞籍