How to Work with Legacy Ruby on Rails Applications in Treasure Data Shimpei Makimoto, API Team Arm Treasure Data 16 October 2018 PLAZMA TD Tech Talk 2018 at Shibuya
こんにちは • Shimpei Makimoto • API Team, Arm Treasure Data since November 2017 • TD では特に認証認可に関することをやっている • https://github.com/makimoto • https://twitter.com/makimoto
Goals of this presentation • Treasure Data の内部においてウェブ API アプリケーションやそれを開発・運用す る API チームが果している役割について知ってもらう • 最近の API チームのチャレンジについて紹介する • あわよくば、採用サイトからわれわれのチームに応募してもらう
What is “API” in TD? • “Treasure Data についてのウェブ API を提供するサービス” • 具体的には、“td-api” レポジトリ (private) に含まれる Ruby on Rails プロジェクト のこと • (主にサービスの観点で) “api3” の名でも呼ばれる • 開発・運用しているのは API Team
Other kaizens in the last few months • Rails が生成する X-Request-Id ヘッダの値を Rails アプリ間で持ち回るようにし、 各種ログに記録されるようになり、エラー追跡などに使えるようになった • 伝統的に大量に使用されている RAILS_ENV の数が減った • 内部コンポーネントが公開 API と内部 API の両方を叩いていたのを内部 API だけ 使うようになった
Basic idea on separating services graduatelly “main service” (具体的には td-api) 内に “sub service” のコンポーネントを作る sub service のデータベースは main service のものとは分ける main service sub service main service DB sub service DB
Basic idea on separating services graduatelly “main service” が “sub service” を使う際 は必ず所定のインターフェースを使う インターフェースは create_permission み たいなメソッドを提供しているが、 CQRS と イベントソージングなどを採用することもでき る main service sub service interface
Separating services graduatelly “interface” と対応するウェブ API を用意し て “main service” からの使用をウェブ API 経由にする HTTP リクエストのオーバーヘッドなどが許 容できるか評価するのもこの段階 main service sub service interface Web API HTTP
Separating services graduatelly これまでの段階で十分な要件を果たしてい ることが確認できたら、満を持してサービス を分割する サービスを建てたら基本的にコンシューマ 側 (“main service”) のエンドポイントを切り 替えるだけで実現できる main service sub service Web API HTTP sub service interface Web API interface