Home • About • me

Rails Developers Meetup 2018: Day 1 大阪会場に参加しました

Tags: ,
Created at: 2018-03-24 02:00:00
Last modified at:

Rails Developers Meetup 2018: Day 1 大阪会場 に参加しました。

以下、メモです。

会場

トラック A の中継は、前にきたことがある場所より広い部屋でした。

安全かつ高速に進めるマイクロサービス化

  • トラックA
  • これからマイクロサービスに切り出す人向けの知見の共有
  • 動機: モデル定義が YAML で、それが DB に入っていて安定性にも速度にも問題があった
  • 問題を許容できるか?
    • 境界をまたいで JOIN できないとかトランザクションとか
    • 障害発生源の増加
    • 管理運用コストの増大
  • エンドポイント丸ごと分離する? 内部APIにしていろんな場所から叩く?
    • 今回は内部API寄りかつ途中から分割する話
  • テスト
    • いろんな選択肢
    • 何を達成したいか
    • 今回は結合テストがある程度あったのでそれを流用
    • 切り出したアプリを起動してユニットテスト
      • DB を切り離した時に FactoryBot から API での作成に切り替え
    • この手法の良い点、悪い点
    • 銀の弾丸はないので要件などにあわせて柔軟に
  • Rails におけるリトライの実装パターン
    • エラーハンドリングの観点
    • Circuit Breaker パターン
      • circuit_breaker.gem : mix-in なので使いたくなかった
      • expeditor.gem : 非同期化が不要だったが詳しかったので採用
    • すぐにエラーがかえってくる場合など外側のタイムアウト時間いっぱいまでリトライしてほしいことがあるので、1回のリクエストのタイムアウトと全体のタイムアウトは別にしている
    • GET や POST などの状況別のリトライ
    • リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
  • Rails アプリの切り出しで困難な点
    • belongs_to :user とか : PubSub とか user_id だけとか
    • JOIN の必要なソート
    • 気軽に解決できなくなる N+1 問題
    • 認証認可どうするの問題
  • 危険なデプロイ環境を改善した話
    • CI が通っていなくても30分に一回デプロイ
    • おまけなのでほぼ省略
  • 質疑応答
    • 内部APIにした理由?
    • モデルのバリデーションから API を呼ぶ必要があったりした
  • 安全かつ高速に進めるマイクロサービス化 / railsdm2018 by Takashi Kokubun

Microservices on Rails

  • トラックA
  • マイクロサービスにもレールを敷きたい
  • サービス紹介
    • Wantedly Visit: モノシリック
    • Wantedly People: マイクロサービス
  • Wantedly People の事例
    • リリース時の機能
      • 名刺がスキャンできる
    • (他のことをしながらきいていたのでメモとれず)
  • Wantedly Visit からの分割
    • profile service の分割
    • モンキーパッチして JOIN を事前にログを取るようにして書き換え
    • connections service の分割
    • すでに局所化されていたので楽だった
  • 質疑応答
    • ネイティブアプリの分割?
    • (よくわからず)
    • ふりがなサービスが gem ではなくマイクロサービスなのはなぜ?
    • python で書きたかったからとか
    • (よくわからず)
    • People のサービスをさらに細かいサービスに分ける?
    • 使われ方の変化次第

MySQL/InnoDB の裏側

MySQL は使ってないけど EXPLAIN を読めるようになった方が良いと感じました。

スポンサーセッション

昼食のため外出していたため最後の方しか聞けず

それPostgreSQLでできるよ

  • それPostgreSQLでできるよ @ Rails Developer Meetup 2018 Day 1 by Fujimura Daisuke
  • トラックB
  • AWS RDS, Google Cloud SQL for PostgreSQL で使える機能のみ
  • PostgreSQL 10.1, PostGIS 2.4.3
  • コード: https://github.com/fujimura/railsdm_2018_postgresql
  • マチマチの紹介
  • Window関数
    • データ分析ではよく使うがアプリケーション開発では使わない?
    • 例1: position 振り直し
    • 例2: アクセスログからセッションを抜き出す
    • Rails では? execute とかで直接対応するものはなさそう
  • Trigger
    • 行への操作があったときに特定の関数を実行できる
    • 例: 変更のログを取る
    • Rails では? マイグレーション内で execute
  • Materialized view
  • PostGIS
    • この話がしたかった
    • 例: 東京都の近くに公園が多い駅ランキングを出したい
    • 地理空間情報
    • Rails では? ジオメトリ型がマイグレーションで定義できます
  • 質疑応答
    • 保守性を考えるとロジックを Rails とどっちに書く?
    • trigger はあまり複雑なことを書かない
    • Materialized view はご利用は計画的に
    • Materialized view の話? (よくわからず)
    • 生 SQL を使った時のページング?
    • カーソルを使っている

メドピアの開発を支えるgem

時間が来たら容赦無くまとめの話に切り替わっていました。

Railsエンジニアのための技術ブログ TechRachoの舞台裏

  • 中級者以上向け
  • 社内で書いた人以外も内容をチェックしている
  • 良い記事、悪い記事
  • 歴史
  • 開発会社の技術ブログは更新されなくなる法則
  • 事業化
  • 裏側の話
  • 知見
  • 書いてもらうエンジニアの負担軽減
  • 執筆以外は編集部が代行
  • アイキャッチ画像 : 絵文字が便利
  • Slack でレビュー
  • GitLab の MR は非エンジニアがやりにくかった
  • 「週刊 Rails ウォッチ」の例
  • 翻訳許可: 記事コメント, Twitter, メール, GitHub issue など
  • 「ダメ」と言われたことはない
  • 打率は「5割」
  • 残りは音沙汰なし
  • 引用、埋め込み (Twitter はスクリーンショットはダメらしい)
  • 記事作成上のハック
    • fresh eye 法 : 数日後に見直す
    • https://enno.jp/ でチェック (自作のチェッカー)
    • Dash アプリで定型文をキーマクロ化 (キーワードは ; ではじめる)
  • Google 翻訳?
    • たまに使っている
    • 機械翻訳の修正の手間は新規翻訳の手間とほとんど変わらない
    • たまにセカンドオピニオン的に1文だけかけてみるとか
  • 技術ブログはフィードバックが糧
  • 今後
  • 質疑応答
    • 記事を集めるサイト?
    • Ruby Weekly とか
    • 古いものが多いが翻訳記事はどうやってみつけている?
    • 良い内容のものは古くても翻訳している
  • 「TechRachoの舞台裏」をRails Developers Meetup 2018で発表してきました

なぜからいちょうと勘違いしていたけど、「てっくらちょ」だった。 悪い記事の例で出ていた言いたいことがまとまっていないみたいなのが当てはまる記事が公開できていないことがあったり、いろいろ分かる感が強かった。

365日24時間稼働必須サービスの完全無停止DB移行 〜MongoDB to Amazon Aurora〜

  • 自己紹介
  • 移行対象のコレクション
    • node_values 約12億ドキュメント
    • page_node_values 約26億ドキュメント
  • ビジネスサイドとの話し合いの結果、ダウンタイム数分はOKだったが、ダウンタイムなしの方が良いのでチャレンジした。
  • Abstractor を経由してフラグで動作をかえる
    • nil : mongoDB のみ
    • aurora_write : mongodb, aurora に write, mongodb から read
    • aurora_read :aurora, mongodb に write, aurora から read
    • aurora : aurora のみ
  • rake タスクで徐々に移行
  • チェックタスクでチェックして修正
  • フラグ実装のポイント
    • Thread#[] を使うなら around_action でちゃんと nil に戻す
    • request_store gem
    • AcitveSupport::CurrentAttributes
  • 移行ツールの内部実装
    • producer consumer パターンを SizedQueue で
    • JRuby で高速化
    • マルチサーバー x マルチスレッド
    • sshkit
  • 質疑応答
    • Abstractor を消す予定は?
    • ある
    • Ruby 以外の言語は使わない?
    • できるだけ Ruby の資産をいかしたい
    • mongo から移行した理由?
    • ちなみに 2 系を使っていた
    • 厳密な整合性が必要なケースが増えてきたなど
  • 365日24時間稼働必須サービスの 完全無停止DB移行 by Kyuden Masahiro

Railsのタイムゾーン

Elasticsearchによる全文検索の実装

  • Kibela では Amazon Elasticsearch Service を利用
  • elasticsearch-rails は使わない方が良い?
  • https://github.com/github/elastomer-client
  • 適合率 vs 再現率
  • LIKE 検索との違い
  • 用語 (type は削除予定)
RDBMS Elasticsearch
Table Index
Record Document
Column Field
  • 形態素解析
  • N-gram
  • 「京都」で「東京都」を含む文書を…
    • 形態素解析ベースだと検索できない→適合率が優れている
    • N-gram ベースだと検索できる→再現率が優れている
  • 形態素解析と正規化
    • kuromoji plugin
  • スコアリング
    • 「京都」で「東京都」という文書はヒットしてほしいが「京都」の文書が上位に来てほしい
    • 実装例
    • フレーズマッチ : ダブルクォートで囲んだ時に「フレーズそのもの」が検索対象になる
      • Kibela の場合はスコアリングをブーストしている
    • Field Value Factor : 特定のフィールドの値でスコアをブーストさせる機能
      • Kibela の場合、ライク数とトラックバック数
    • Cecay : Field Value Factor の逆で、特定のフィールドの値でスコアを減衰させる機能
      • Kibela では古い文書
      • 他には例えば距離
  • 発表資料: Elasticsearchによる 全文検索の実装 in Rails - Islands in the byte stream

Realworld Domain Model on Rails

  • 自己紹介
  • DDD っぽい話
  • 責任の範囲を明確に
  • データの流れは一方向に
  • Form オブジェクトが重要なのでは
  • 状態管理の悪い例 : devise の invitation 関連が NULLABLE カラムの嵐になる
  • イベント駆動アーキテクチャ
  • Realworld Domain Model on Rails by Tomohiro Hashidate

話が早口の予定だと最初にいっていたのと、資料が公開されるはずなので、あまりメモは取らずに聞いていました。

見てないセッションの資料

Disqus Comments
Written by

Kazuhiro NISHIYAMA

Ruby のコミッターとかやってます。 フルスタックエンジニア(って何?)かもしれません。 About znzに主なアカウントをまとめました。

znz znz

Published

Supported by