Web API をデバックするときに必要なたったひとつのこと

Preview:

Citation preview

Web API をデバッグするときに必要なたったひとつのこと

2015/05/16 - Kanazawa.rb meetup 33

かしこいロギング

こたえ

かしこいロギング

こたえ

Web API の特徴• 多数の構成要素

• ロードバランサ, リバースプロクシ, アプケーションサーバー, DB ...

• プロセス, スレッド …

• 多数の並列処理

• 複数クライアント, 多重 API コール …

client A

client B

RP

RP

App Server

App Server

DB

DB

Process α

・ ・ ・

・ ・ ・

・ ・ ・

・ ・ ・

Process β

・ ・ ・

・ ・ ・

!

!

! !

!

!LB!

client A からの API コール x の 処理パスを特定して それぞれの log を 目 grep して…

そんな装備で大丈夫か?

–T.K, 2013

“開発環境はそんな複雑じゃない。複数 Terminal

開いて log を tail しておけば十分。”

–T.K, 2014

“開発環境は複雑だった”

–T.K, 2015

“本当のバグは運用環境にこそ潜む”

かしこさの種• ロギング全般

• いろいろある。おおい。

• おググりください。

• Web API に絞ると

• 集約と識別

集約と識別

集約と識別

ログの集約

• すでに様々なアプローチがある

• 古くは syslog

• イマドキは fluentd

集約と識別

ログの識別• API Call を識別する

• 構成要素横断で識別

• サーバやプロセスをまたいでも識別できることが大事

• API Call 毎に識別

• クライアント毎ではなく Call 毎であることが大事

どうやって?

• 識別子を発行して構成要素間で伝搬

• だれが発行?

• どうやって伝搬?

だれが発行?

client A

client B

RP

RP

App Server

App Server

DB

DB

・ ・ ・

・ ・ ・

・ ・ ・

・ ・ ・

! !

LB!

APIクライアントに もっとも近い構成要素

入れやすいのはこの辺

!

どうやって伝搬?

・ ・ ・

・ ・ ・

・ ・ ・

client A

client B

RP

RP

App Server

App Server

DB

DB

・ ・ ・

・ ・ ・

・ ・ ・

・ ・ ・

! !

LB!

!

① API Call

② 識別子発行

③ 識別子付きで logging

④ 識別子付きでIPC(call)

⑤ 識別子付きで logging

⑥ 識別子付きでIPC(call)

⑦ 識別子付きで logging

⑧ 識別子付きでIPC(call)

⑨ 識別子付きで logging

⑩ 識別子付きでIPC(res)

⑫ 識別子付きでIPC(res)

⑪ 識別子付きで logging

⑬ 識別子付きで logging

⑭ 識別子付きでIPC(res)

⑮ 識別子付きで logging

⑯ API

Response

シンプルな話

押さえるべきポイントが もうひとつ

どうやって?

• 識別子を発行して構成要素間で伝搬

• だれが発行?

• どうやって伝搬?

どうやって?

• 識別子を発行して構成要素間で伝搬

• だれが発行?

• どうやって発行?

• どうやって伝搬?

New!

client A

client B

RP

RP

App Server

App Server

DB

DB

・ ・ ・

! !

LB!

!

① API Call

② 識別子発行

LB!

①' API Call ②'

識別子発行

・ ・ ・

・ ・ ・

・ ・ ・

client A

client B

RP

RP

App Server

App Server

DB

DB

・ ・ ・

! !

LB!

!

① API Call

② 識別子発行

LB!

①' API Call ②'

識別子発行

・ ・ ・

・ ・ ・

・ ・ ・

ログの識別• API Call を識別する

• 構成要素横断で識別

• サーバやプロセスをまたいでも識別できることが大事

• API Call 毎に識別

• クライアント毎ではなく Call 毎であることが大事

ログの識別• API Call を識別する

• 構成要素横断で識別

• サーバやプロセスをまたいでも識別できることが大事

• API Call 毎に識別

• クライアント毎ではなく Call 毎であることが大事

一意性 (Uniqueness)

client A

client B

RP

RP

App Server

App Server

DB

DB

・ ・ ・

! !

LB!

!

① API Call

② 識別子発行

LB!

①' API Call ②'

識別子発行

・ ・ ・

・ ・ ・

・ ・ ・

client A

client B

RP

RP

App Server

App Server

DB

DB

・ ・ ・

! !

LB!

!

① API Call

② 識別子発行

LB!

①' API Call ②'

識別子発行

・ ・ ・

・ ・ ・

・ ・ ・

識別子発行サーバー×The ボトルネック

分散型ユニークID生成問題

分散型採番手法

• 分散した採番環境それぞれで自立的に採番可能であること

• 採番結果が絶対に衝突しないこと

分散型採番手法

• 分散した採番環境それぞれで自立的に採番可能であること

• 採番結果が絶対に衝突しないこと

分散型採番手法

• 分散した採番環境それぞれで自立的に採番可能であること

• 採番結果の衝突確率が運用されるシステムにおいて十分に低確率であること

分散型採番手法

• 大きな桁数のランダム文字列

• UUID

分散型採番手法

• 演算コスト問題

• Snowflake

• Twitter の Tweet ID 生成手法

• 衝突確率は上がる

• Twitter にとっては十分低確率

まとめ

• Web API におけるかしこいロギング

• 収集と識別を実現する

• 識別子には分散型ユニークID生成手法をもちいる

Thank you

Tomokazu Kiyoharahttp://github.com/kiyohara

http://facebook.com/tomokazu.kiyohara

Recommended