最近ドラム式を購入し、ソフトウェアの発展で実装が楽になっているのと同じくらい、文明の進化に対する感謝の念を感じた @ourly_nobuo です！
9/26(金)と9/27(金)に行われたKaigi on Railsにourlyチームとして参加させていただいたので、その感想と学びをレポートさせていただきます！
弊社CTOの @tigers_loveng の2人で現地参戦し、残りのメンバーはオンラインで参加しました！
下の画像2つをもとに集合写真をGPTでいい感じに作ってもらいました！ほぼ別人ですが笑
個人の学びまとめ！
kaigi on Railsに参加したメンバーがそれぞれセッションを選び、そこでの学びや感じたことを下記でまとめていきます！
相澤がピックアップしたセッション
講演の概要
- 権限管理の重要性
- 誤った権限設計は情報漏洩や信頼失墜につながるため、慎重な設計が必須。
- ありがちな失敗例
-
admin?などの単純なロール判定ロジックが乱立し、事業拡大時に技術負債化する。
-
- 権限を4要素で整理
- 「対象（リソース）」「操作」「役割」「条件」に分けて考えることで、柔軟で拡張しやすい設計に。
- Punditを用いた実装例
- 権限チェックをモジュール化し、CRUD以外の操作にも対応。バックエンドとフロントの整合性を取る仕組みを紹介。
- 成果と効果
- 運用後も不具合が減少し、権限関連の問い合わせが激減。保守性・生産性ともに向上。
学び/感想
- 権限 ≠ 役割は雰囲気で分かっていたものの言語化できずにもやもやしていたところ、4要素への分解の説明を聞き、とても納得感がありました。
- ちょうど最近でも特権管理者(管理者よりさらに上の権限)を作って、特定のデータを特権管理者のみにしたいという話も上がっていたのでタイムリーな話題で、とても参考になりました。
- ourlyではPuditではなくCanCanCanを使って権限管理しており、思想の違いなどをコードから見ることができて面白かったです。
ourlyで活かせそうなところ
- ourlyでは固定の役割を定義し、エンドポイントベースで役割ごとの権限を振り分けているので、4要素が一部密結合な状態になっています。
- ただ、一応ABACの方式にも対応できるようにテーブル設計上はRole(役割)にPermission(条件)を付与できるような構成にしています。
- 今まで、役割を軸に権限の切り分けを考えていたが、4要素それぞれに分解して設計できるような構造／仕組みを考えたいと思いました。
玉田がピックアップしたセッション
講演の概要
- よくあるリクエスト送信後に送信ボタンを無効化するといった対策だけでは画面リロードやAPI経由の重複リクエストには対応できない。クライアント、インフラ、アプリケーションそれぞれのレイヤで複数の対策を組み合わせて実施することが重要
- 9つの対策
- サブミットボタンの制御: 送信後にボタンを非活性化
- PRG(Post-Redirect-Get)パターン: POST完了時に直接HTMLを返却するのではなく結果表示ページへリダイレクト。リロードでの再POSTを防ぐが、ブラウザで戻る->再POSTには別対策が必要。
- 排他制御: 悲観ロック/FIFOで順序化/アドバイザリロック等で同時実行を制限する。ただしロック範囲やエラー処理など考慮しなければならないことも多い。
- テーブル設計: 状態遷移ルールやユニーク制約などでデータ整合性を保つ
- レートリミット: 短時間での複数回操作を無効化できる仕様の場合、上位レイヤで防御が可能。API Gatewayのスロットリングや、Rails 8の標準機能もあり。
- APIキャッシュ: 同一リクエストにはキャッシュしたレスポンスを返すことで冪等性を担保。キャッシュキー、TTL、キャッシュサイズなどの論点あり。
- Idempotency-Keyヘッダ: クライアントが採番した一意なキーでリクエストを判別する。同一クライアントに対する制御であれば強力。
- ETag + If-Match: リソースのバージョン(ETag)が一致している場合のみ更新し、競合時は412 Precondition Failedを返却する。Idempotency-Keyは冪等性、ETag + If-Matchは同時更新への制御。
- ワンタイムトークン: 一度だけ使用可能なトークンを発行・検証する。実装・UXコストがあるため特に重要な部分に適している。
学び/感想
- 一口に2重リクエスト防御といっても様々な対策を組み合わせて実施しなければいけない点に関して身が引き締まる思いだった。
- 単に技術的な内容だけでなくスマートバンクさんでの事例も共有していただき、感謝でいっぱい
ourlyで活かせそうなところ
- ETagによる制御も含めてAPIにおけるキャッシュは負荷軽減の目的で導入していたが、2重リクエスト防止の文脈でも使用できるのはよい学びだった。
- Idempotency-Keyヘッダは、意図的な再送信と事故/悪意での再送信を区別できるのが魅力。外部サービス連携の際に威力を発揮しそう。
- 最終的な防衛線としてDB設計はやはり重要。ロックは有用だが取り方によって障害につながる可能性もあるため、これも設計のうえ実装しなければならない。
神本がピックアップしたセッション
講演の概要
- システム全体の設計思想
- 規制産業ならではのアーキテクチャ設計時の工夫
- 認知負荷の低いモジュール化されたコアAPIの設計
- アラートを検知するための仕組み
- 検算/集計で例外ではないが、不整合なデータを検知できるように集計を別途作りクライテリアを設定
- パフォーマンスが著しく悪くなる前に想定集計終了時間を設けてアラートする仕組み作り (SLO設定)
- アラートトリアージを旗振り役の活躍で可能にしたこと
- 障害対応フローの属人生の排除
- Runbookと呼ばれるドキュメント整備によって、インシデント対応を暗黙知から形式知に昇華
- アラートに対して、過去の類似対応のRunbookが自動的にサジェストされるslackBotを作成
学び/感想/ourlyで活かせそうなところ
- 「検算/集計で例外ではないが、不整合なデータを検知できるように集計を別途作る」話
- ourlyでも集計基盤上の自明な不整合データはアラートを飛ばすフックを導入しているが、非自明な不整合をあらかじめ想定して、別途検知できるようにしておくという発想や事前の推測と設計はしていかないといけないと感じたこと
- Runbookの件
- ourlyではインシデント対応については、属人的な部分が多く、一部、ojt的に第三者へ暗黙知の伝達が行われてるのが現状
- この判断自体、限られたリソースをどこに張るか?という判断として誤ってはいないものの、メンバーが増えたりサービスが拡大していくと、この対応方法だとどこかで頭打ちしてしまうので、暗黙知が蓄えられたきた自分自身がこの活動を行い、暗黙知として昇華させてれば全員へのojtを毎度行う必要がなくなりレバレッジが効く可能性があるのでやらねばと感じた
- 全体を通して
- 「運用とはビジネスを可能にすること」という上位起点から、「我々のビジネスにおける死守するべきポイント」を決め、そのために「システム設計と運用フローを構築していく」という全体のプロセスが一気通貫しており、ソフトウェア開発もトップダウンで考えるべきだなと改めて感じました。
- また、スマートバンクさんは、メンバー全員が各所で登壇やテックブログでそれぞれの活動をアウトプットしており、これらのプロセスをメンバー全員が積み上げて築いてきているのが素晴らしいことだなと感じました。
- 我々も全体の戦略に対してすべての活動が紐づくように設計を行う姿勢や、それらをメンバー全員の活動によって築き上げていくという力強い組織を目指したいと思いました。
土橋がピックアップしたセッション
講演の概要
- 設計におけるベテランエンジニアとジュニアエンジニアの思考プロセスの違いを解説
- ジュニアはコードレベルで設計してしまうが、ベテランはシステムレベルの抽象的な構造で思考する
- ジュニアエンジニアでも自然と抽象的な思考で設計をするための手法は「逆算」である
- ゴール（ex. CSVインポート機能など）を実現するために「何が必要か？」を逆算的に考え、システムレベルでの全体像を考える
学び/感想/ourlyで活かせそうなところ
- 純粋に設計時の思考プロセスをここまで言語化できていることがすごいなと感じました。
- 大葉さんがこれまでのご経験の中で、設計の育成に対して真摯に向き合ってきたからなのだと感じ、尊敬の念を抱きました。
- ourly内でRailsを用いてAPIを実装する際に、自分で設計をしてから実装をすることが増えていたが、この際に逆算的な思考プロセスを行っていることを実感しました。
- ゴールとなるJSONレスポンスを部分に分け、各構造を実現するために「どのテーブルの値が必要か」、「どういう変換が必要か」を逆算的に考えていく
- 講演の中で登場した「デザインパーツ」が設計時の選択肢に直結するが、現状自分自身はここを意図的に伸ばしていくことがあまりできていません。そのため日々キャッチアップしていく必要があると強く感じました。
- ↑に関しては生成AIによる壁打ちの恩恵がかなりありそうだと感じたので、より早く自分が持ちうるデザインパーツを増やしていきたいです。
ourlyメンバーとの写真で振り返るKaigi on Rails
ここからは会場で楽しんでいる我々の写真をもとにKaigi on Railsを振り返っていきます！
スマートバンクさんのブース!借金で生計を立てるプロンプトを入力中の弊社CTO
クラシルさんのブース！Xのポストを通じて寄付できる素敵な取り組み！
アイキューブドシステムズさんのブース!タイピングのランキングに挑戦！
最後に
ここまでお読みいただきありがとうございました。
チームとして本イベントに参加するのは今年で2回目となりますが、前回に引き続き、実践に基づいた泥臭い話や最先端のRails周りの話など、ここでしか得られない学びを得ることができ、非常に素晴らしいイベントでした。
Leaner TechnologiesさんのスポンサーLTでも述べられていたように、多くの会社はこういったRubyやRailsなどのコミュニティによって日々の開発を支えられている部分が多いかと思います。ourlyも例外なくお世話になっており、エンジニアコミュニティへ恩返しができるよう、チーム全体としてより一層事業に向き合い、そこで得られた学びや知見を積極的に外部に発信していきます！
運営の皆様、そしてスポンサーの企業様、ありがとうございました！！
Discussion