RubyKaigi Takeout 2021 をスポンサーとして応援しました

技術顧問の五十嵐(igaiga)です。RubyKaigi Takeout 2021 が9月9日〜11日の3日間で開催されました。

 

rubykaigi.org

 

弊社クルーバーもスポンサーとしてRubyKaigiを応援するとともに、何人かのメンバーが業務の一環として参加して講演を聞きました。オンラインでの開催で、世界中から多くの開発者さんが興味深い話をしてくださいました。

JITに関連する話はRuby本体に入っているMJITがついにRailsを数%高速化した話をk0kubunさんが行ったほか、Maximeさんが話すYJITは実戦投入されていて、Railsも10%程高速化し、開発者も10人程の大人数でやっていることが驚きでした。加えて、2日目の基調講演でChrisさんがShapeというインスタンス変数のデータの持たせ方についての提案を行ったり、ブラッドさんがつくっているMIRについてk0kubunさんが言及されたりと、JITに関連した多くの話題が提供されました。話された話題の中でRuby3.1や今後のRubyに入る機能があるかもしれないのは楽しみです。

開発環境改善の話題では型定義ファイルrbsがRuby3.0で入ったあとに進化を遂げていて、mameさんの基調講演ではVSCodeで型を表示するコメントやメソッド補完、ko1さんの講演ではデバッガであるdebug gemが動いていたりと一気に進化していました。WindowsでもMacでも動くVSCodeでいろいろな機能が使えることは教育現場の観点からもありがたいです。

参加メンバーの一言感想

hotoolong

Railsをメインに活動しているフリーランスのhotoolongです。

今回のRubyKaigi2021 takeout ではIDE連携、JITなどの高速化、Ractor、型定義などの話題がメインでした。

静的型付け言語が最近の主流ですが、LSPによる入力補完が強化されることにより速くコードが書けそうですし、JITやRactorとの連携でいままで遅いと言われているRubyがより速く動ごき更にはメモリ消費が少なく動く未来が近づいているのではないかと希望が持てました。

Ruby3.0よりも更に三倍はやくするという話も出ていたので遅いと言われるRubyの進化が今後も楽しみです。

しゅう

講演「TypeProf for IDE: Enrich Dev-Experience without Annotations」

静的型付けが好きな一番の理由は、まさにRubyKaigiで紹介された様にIDEからのサポートがとにかく強力で書きやすく、型チェックの安心感もあることです。Rubyの様な柔軟な言語に強力なIDEサポートが加わるのがとても楽しみで、待ち遠しいですね。

igaiga

ko1さんのdebug gemはVSCodeで変数の中身が見えたりブレークポイントを作成したりとIDEとの統合が進んでいて便利に感じました。Ruby3.1に標準添付されると、Gemをインストールする必要もないので、初学者向けの書籍でも説明しやすいのが助かります。

どの講演も興味深かったですが、「Parsing Ruby」はRubyの文法とパースの歴史が調査解説されていてすごくおもしろかったです。

そのほかにも

ほかにも、はすみさんのキーボード上でRubyを動かす話や、mrknさんのグラフをRubyから簡単に描けるChartyをJupyter Notebookと組み合わせて便利に使えるデモは興味深かったです。

しおいさんのプロトコル自作にima1zumiさんのエンコーディング自作、udzuraさんのバイナリ組み立てにosyoさんのAST黒魔術、tagomorisさんとunasukeさんのRactorの話など、作ってみた系の話も本当にすごいなと楽しみながら観させていただきました。

たのしさにあふれた3日間でした!

スポンサー

また、弊社クルーバーはRubyKaigi Takeout 2021をスポンサーとして応援しました。素晴らしいイベントを運営してくれたスタッフのみなさんに感謝します。

 
f:id:iga_k:20210921145050p:plain

 

クルーバーでは一緒に開発するメンバーを大募集しています!

 https://www.zerotoone.co.jp/recruit/ 

www.zerotoone.co.jp

レガシーなシステムをピカピカに磨くための新アーキテクチャ

クルーバー技術顧問の五十嵐(igaiga)です。今年の3月から技術顧問として勤務しています。クルーバーではカー用品・バイク用品に関する複数のECサービスを開発して運用しています。

 

今日はクルーバーが行っているレガシーとの闘い、大規模な設計変更についてお話しします。

旧設計とそのつらいところ

f:id:iga_k:20210813115321p:plain

旧システム概要
旧システムをざっと表現するとこのような構成になっていました。ほとんどぼかしをいれてしまっているので、よくわからないかもですが、ごちゃごちゃしていることは伝わるのではないでしょうか。保守コストが高いところがたくさんあり、また使われている技術領域もバラバラで人の移動にも大きなコストがかかっていました。

 

移行前に困っていた点としては次のようなものが挙げられます。

データが点在していた

たとえば在庫データなどが各サービスなどに散らばって保管されていたため、各サービス間でやりとりが多く発生していました。また、そのやりとりもCSVファイルでエクスポートしてファイルを転送してインポートするなど、レガシーな方法で行われていました。

レガシーなミドルウェアに依存していた

廃れてしまった旧世代の技術をつかったミドルウェアで書かれたサービスがあり、継続が困難な上に、技術の習得も難しく、人の交替もままならない状況でした。

ほかにもいろいろと挙げられますが、レガシーな領域が多く、それらを使い続けたまま存続させることはとても困難な状況となっていました。

新しい設計

これに対応すべく、新システムとして新しいアークテクチャを設計して対応することにしました。具体的には、次のようなマイクロサービス構成で設計しています。

 

f:id:iga_k:20210813115412p:plain

アーキテクチャ

Rails + GraphQL API を基本構成とする複数の基盤サービスで構築しています。ユーザーが利用するWebサービス部分はNuxt.js + Railsで構築し、必要に応じて基盤サービスを利用します。利用技術を揃えて、1人のエンジニアが複数のサービスに渡って新機能を実装しやすくしています。

 

前述した「データが散らばっていた」は既に「在庫基盤」として改善がなされた新設計で稼働をはじめています。図の右下に書かれている旧DBから左上に書かれた新DBへデータを同期する仕組みが稼働し、新DB側へデータが集まるようになりました。旧DBの古いしがらみは捨てて新DBはスキーマも新たな設計を採用し、しかも旧DBから新DBへサービス群を止めずになめらかに移行する仕組みを実装して稼働している状況です。ただし、規模も大きく全ての移行を一発で終わらせるには難しいため、まだ旧DBを見ていたり、旧DB時代のしがらみを解消する途上の箇所もまだまだあります。

 

共通で利用される「基盤サービス」としては前述の「在庫基盤」のほか「ユーザ基盤」「検索基盤」「帳票基盤」などが実装されて、部分的に、または機能全体が稼働しています。

現在と今後の課題

レガシーな旧システムを新設計によって改善を進めています。まだ基盤部分も実装途上の部分、足りない部分の方が多いですし、旧システムの上で動くサービス群は大半がこれから移行となります。

 

また、マイクロサービスやGraphQLなどのアーキテクチャを導入したため、新たな課題も生まれました。サービスを横断してトランザクション処理が必要な場合にどのように解決するのか。リポジトリを横断して開発をするためにDockerプロセスを多数起動しているが、開発環境をシンプルにつくるのにはどうすれば良いのか。運用コストを下げるために監視などをどのように改良していけば良いのか。GraphQLをつかって良いAPIを設計するためにどうすれば良いのか。

 

ここまでの新設計とその改善は私が入った3月時点で既にできていました。現在、私は同僚と一緒にこの新設計への移行を進めています。また、この機会からRailsをつかって開発するようになったメンバーもいるので、「パーフェクトRails」をつかった読書会を実施するなどして学習の仕組みも整えています。

 

まだまだやることも課題も山積みですが、より良いシステムへ進化させていくため、私たちと一緒に設計してコードを書いてくれるメンバーを大募集しています。マイクロサービスで運用される基盤群やサービス群を設計実装したり、GraphQLをつかってAPIを設計実装したりと、考え甲斐のある技術課題を解決したい方の応募をお待ちしています!

 

www.zerotoone.co.jp