ActiveResourceモデルによるAPIの隠蔽の怖い話~レスポンスタイムへの致命的影響~...

[Confidential] © 2013 Actcat, Inc. 1

モデルによるAPIの隠蔽の怖い話 ~レスポンスタイムへの致命的影響~

[Confidential] © 2013 Actcat, Inc.

SideCIとは

n 継続的コードレビューサービス

n コードを自動的に解析、問題を発見、改善を促します

n Ruby, PHPなどで開発されているプロジェクトで利用できます

2


SideCIのご利用イメージ 1/2

3

GitHub PullRequest 上の問題のあるコードに自動で問題点をコメントします


SideCIのご利用イメージ 2/2

4

コードに含まれる全ての問題点は SideCIの画面上で閲覧出来ます


SideCIのアーキテクチャ(2015/06) 8種類以上のサーバが…

n Frontend(API+Frontend+Job) n ツール毎サーバ

l RaislBestPractices(API+Job) l Brakeman(API+Job) l Bundler(API+Job)

n + 新しいアーキテクチャのサーバ l Job 処理サーバ(using docker) l Job 管理サーバ

5


SideCIのアーキテクチャの歴史(の一部) サーバ構成を4回以上変えた

n  2014/04/30 l ベータ版リリース l Heroku でサービス提供 l 解析処理は解析ツール毎のサーバで

n  2014/夏 l AWSにjob処理部分を移行

n  2015/03 l アーキテクチャ全面見直し l 解析処理をどの解析ツールでも同じサーバ内でdockerを用いて実施するタイプを追加

n  2015/07 l 解析ツール毎のサーバを全台廃止

6


ベータ版リリース当初アーキテクチャ


マイクロサービスアーキテクチャ

8

www Frontend + API + Job

Brakeman API + Job

Rails Best Practices API + Job

Bundler API + Job


ログイン後トップページの表示時APIコール

9

レポジトリの数だけ GitHubにAPIリクエスト

ブランチのリストAPI呼出

僕は誰？User api呼出ここらへんはDBに保存・表示してた


解析結果表示ページのAPIコール

10

このページはbrakeman専用サーバにAPIリクエスト、結果を表示

3サーバに同時にAPIリクエスト。結果が3つ揃うと表示する。

(Brakeman, bundler, rails_best_practicesの3サーバ)


問題が発生したぽよ

11


ログイン後トップページ

12

表示にかかる時間が15秒を超えてしまうユーザ多数

Herokuのtimeoutが頻発


実は各ツールが頻繁にwwwを呼び出す仕様。 wwwがボトルネックに。一回金パワーした

13


Brakeman API + Job


Bundler API + Job

PX Dyno


解析結果ページ表示も timeoutしたのでこっちも金パワーした

14


Brakeman API + Job


Bundler API + Job

2x Dyno

2x Dyno

2x Dyno


(お金ないけど)

15


GitHubのAPI呼び出し回数がボトルネックで、timeout頻発

16


Brakeman API + Job


Bundler API + Job


金パワーの限界

17


実装変更


ログイン後トップページの表示時APIコール

19

ここはRedisキャッシュでなんとか

DBにデータ突っ込み


各サーバがRedisでキャッシュ

20


Brakeman API + Job


Bundler API + Job

Redis Cache Redis Cache SideCI API Result Redis Cache

一部 Redis Cache


なんとか動くようになったけど…

21


つぎはぎの対応ばかり。全体的に無駄・無理が多い

22


結論: マイクロサービス

アーキテクチャは辞めて新しいアーキテクチャで再実装

23


原因分析


なぜこんなことが起こったか？

25



Brakeman API + Job


Bundler API + Job

APIのリクエストが多すぎた


なぜこんなに APIリクエストが多かったのか？

27



Brakeman API + Job


Bundler API + Job

各サーバにとって必要な情報が、他のサーバの管轄だった。各サーバは管轄サーバに

APIで問い合わせるしかなかった


なんでこんな面倒な設計で実装が出来たのか？

29


なんでこんな面倒な設計で実装が出来たのか？

30


ActiveResource 超便利！

31


さもDBに入っているデータであるかのように、 APIのデータを使ってた。

32


惜しげも無く APIリクエスト

33


APIリクエストである認識がそもそもなかった

34


ここまでのまとめ


ActiveResouceはAPIだ！

n APIは隠蔽してもAPIだ(当たり前だ!

n Cache Resourceで多少問題回避出来たが、Cacheの管理のほうが大変になる。

n 隠蔽していても、APIだという認識で設計、実装が不可欠

36


ちなみに現在


各ツール毎のサーバを廃止。APIの集約廃止。必要なデータはJob Enqueue時に付与

38

www Frontend + (API) + Job

Job管理サーバ

Job実施サーバ

必要なデータが入ったリクエストで

Enqueue


SIDECIの宣伝


開発メンバー募集中です

n アーキテクチャ綺麗になりました

n スケーラブルなアーキテクチャです

n 開発メンバー募集中です！

40


もしまだ使ったことない方ぜひ。設定は30秒で終わります。

Just nowでSign Upして貰えると嬉しいです https://www.sideci.com/

ActiveResourceモデルによるAPIの隠蔽の怖い話~レスポンスタイムへの致命的影響~...

Software

Transcript of ActiveResourceモデルによるAPIの隠蔽の怖い話~レスポンスタイムへの致命的影響~...