銀座Rails#35を開催しました
去る2021/7/30(金)、銀座Rails#35を開催しました。
当日の様子は、togetterのまとめを御覧ください。
スポンサーセッション リンクアンドモチベーションさま
今日は河野さんにご登壇いただきました。
7/14に実施された「CTOが語る、テックカンパニーに向けた未来の話」。
テクノロジーで実現できる未来について語り合うこのイベントでは、2030-2040年代にかけて、テクノロジーでどんな時代が訪れるのかについて語られたとの事。
その中で、2020年代にヘルスケア領域で大きく進化することとして、バイタルデータによるリアルタイム診断や、AIによる診断などが挙げられました。
リンクアンドモチベーション社は、組織のヘルスケアを一つの解決課題としており、人間のヘルスケア領域と同様にデータ活用の深化やテクノロジーによって、コンサルレス・アンケートレスを目指していきたいとのことでした。
現在積極採用中とのことで、カジュアル面談をご希望の方は気軽に entry@lmi.ne.jp までメールを！とのことです。
森雅智(@morimorihoge)さん(BPS株式会社) 「出張Railsウォッチ in 銀座Rails 〜何かと便利なActiveSupport::Instrumentation〜」
毎度おなじみ出張Railsウォッチ。今回は「ActiveSupport::Instrumentation」がお題でした。
まずActiveSupport::Instrumentationとはなにか。PubSub機能を提供するものであると述べ、PubSubの例としてRedisやAWS SNSなどを挙げながら図解。 またその利用例を挙げ、どのようなオブジェクトのやり取りがされるかを説明し、RailsのあちこちにInstrumentsが仕込まれていることを説明されました。
さらにRailsGuideを見ると色々と解説があること、そこからRailsのLogに出ている情報が該当することを例示。
最後に自分で定義する場合のやり方や、使用上の注意点を述べられていました。
菊池修平さん 「認証基盤開発で遭遇したシングルログアウトの問題と対応について」
リンクアンドモチベーションさま所属の菊池さん。最近は「相手を地獄の底まで追い詰めるゲーム」ポケモンユナイトにハマっているとのこと。
本日の主題は、認証基盤を開発して導入した話、シングルログアウトを導入した話でした。
複数あるプロダクト毎に、ユーザ・認証情報を管理していましたが、似たような画面を毎回作成することになっていた。 そこで共通した認証基盤を作りたい。クラウド系IDaaSはありはするが、今回は認証だけでなく、独自機能や処理の挟み込みを行いたかったとのこと。
そこで中心部分をRailsで構築し、Auth0と組み合わせることにしたそうです。 特に困ったことは生じずに構築できたそうですが、一つだけ困ったのがシングルログアウト問題。
シングルログアウトとは「一つのアプリからログアウトすると、全てから自動的にログアウトする」ことですが、一つのアプリのログアウト状態を他のアプリにどう伝えるかが悩みどころだったそうで、最終的には横断的なCookieによってログアウトを判別するようにした、とのことでした。
@joker1007 さん 「Rails on AWS Lambda」
CTOから念願の離脱、チーフアーキテクトとなったjokerさん。 ワクチン接種後に禁酒していたものの、今日こそはビール飲むぞと気合を入れてのご登壇でした。
テーマはRails on AWS Lamda。コンテナイメージの利用がLambdaでできるようになって以降の、Lambda上でのRails動作のノウハウを共有していただきました。
まずはどのように動作するのかについて、RubyによるLambdaのAPIの利用例や挙動を説明。 コンテナイメージがキャッシュされ、コンテナイメージの大きさに左右されないこと、Lambdaの場合はFargateなどと比べコールドスタートでも高速であることなどの特徴を述べられました。
またRubyのLambda Runtime Interface Clientの動作の流れについて、注意点とともに説明。
更にRailsで動作について、方法や注意点、ユースケースなどを列挙。
最後にjokerさんの社内での活用方法について、EmbulkやStepFunctionを利用したワークフロー構築について述べられ、「AWSを使う限りでは、ActiveJob/sidekiqはもう要らないんじゃないか」という印象的な言葉を残されました。
なお、Repro社では引き続き人材募集中とのことです。
スポンサーセッション DeNAさま
スポンサーであるDeNAさまよりご登壇されたのは、学生の頃から趣味でRailsを使ってらっしゃるという三軒家さん。
DeNA社内でRailsを使っているのはpocochaだけじゃない！大規模モバイルゲームでもだ！とのこと。
大規模のモバイルゲームのサーバはRailsで作られ、大量のアクセスや多くの関係者のニーズに答えているそうです。
一般的なモバイルゲームに必要な機能から、ゲーム固有の遊びを実現する機能まで提供。
バグ極小化、高いRead/Write性能、高い可用性の実現などを備えた「高品質なゲームサーバの開発」をミッションとし、、綿密な調査、設計、レビュー、QA試験、シャーディング、レプリケーション、スキーマファースト開発、エコシステムえのcontributionなどがそれを支えているとのことでした。
島田浩二さん 「Railsと継続的アーキテクティング」
近年マイクロサービスに関する話題が増える中、Railsを使う我々に考えるヒントを頂きたいと思い、 書籍「モノリスからマイクロサービスへ」の翻訳を手掛けながら、日本Rubyの会の理事をされており、Railsを長く使われている島田浩二さんをお招きしました。
まず、「モノリスは駄目で、マイクロサービスなの？」「RailsはモノリスだがもうWebにはだめ？」という、Rails開発者が不安を抱きそうな点を挙げ、それについて「どっちが良い悪いではない」という事から始まりましたが、それよりも大切なことは「アーキテクチャに無関心な設計をしない」事であるとのこと。
そして、そもそもアーキテクチャという言葉については、ISOなどを参照しながら紐解いてゆき、「アーキテクチャ決定要因に基づいてなされた、システムの構造や品質特性、依存関係、インターフェイス、構造手法などに対する決定」と定義。
ここでアーキテクチャに関心を持つためのに、具体的に三つのアクティビティを例示いただきました。
そしてアーキテクティングについて、現代の「終わらないプロダクト開発」を前提とした場合、未知が多く、一方でアーキテクチャ決定は重い事を指摘。コツとしては、決定は責任を持てる限り遅らせることである、と説明。
どうアーキテクティングしていくかについては、必要十分なアーキテクチャからはじめ、システムのアーキテクチャが劣化しないように保護していくことが必要とのことで、これを「継続的アーキテクティング」という言葉で総括。
Railsについては、開発初期に最小限のアーキテクチャ決定を与えてくれ、継続的なアーキテクティングに対して開かれているが、Railsはよく出来ているが、Railsが与えてくれるのはあくまで最小限であり、そこに自分たちのアーキテクチャ決定要因は考慮されていないことに注意が必要、と述べられていました。
次回、銀座Rails#36について
次回銀座Rails#36は2021/08/27(金)、オンラインでの開催となります。
ゲストスピーカーには松田 明(@a_matsuda)さんをお招きし、「RubyKaigi Takeout 2021 タイムテーブル徹底解説」と題して、RubyKaigi Takeout2021のそれぞれのセッションの魅力を語って頂きます。
参加者募集中です。
