Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
【後半】API 編
GMO Pepabo, Inc.
伊藤洋也
2015/08/29 ペパボテックカンファレンス 第3回 @渋谷セルリアンタワー
MogileFS
をバックエンドとした
Private S3の作り方
伊藤洋也 @hiboma
> GMOペパボ 技術基盤チーム
> 低いレイヤの問題解決が好きです
スライドの用語
> オブジェクト
> 本スライドでは「 mogilefs ストレージに
格納されたデータ」を指します
> メタデータ
> オブジェクトの名前, サイズ, MIME, 作成日
時, ETag … 等 を保持する MySQLのレ
コ...
アジェンダ
> S3 互換 API を実装したお話し
> 設計に S3 互換を採用するまで
> 言語・フレームワークの選定
> 実装
> チューニング小話
> New Relic チラ見
> 所感
(前半のおさらいも含めて)
何が必要なのか?
必要なAPI
必要なAPI
必要なAPI
> オブジェクトのGET/PUT/DELETE/HEAD
> オブジェクトのリスト取得
> オブジェクトのアクセス権コントロール
> 認証 (HMAC認証)
> … etc
「Rails で S3 互換 API
を実装するぞ!!!!1」
を決めるまで
API 設計
API
> どう設計しましょう?
> 何で実装しよう?
> そもそも作る必要あんの?
設計の選択肢
> 新しく API を設計する?
> 既存の API を借用する?
新しくAPIを設計する?
> 設計するの…やだナー… (本音)
> 会社の基盤となるストレージ の API
> 時間に耐えうる設計の重さ
> サーバサイド + クライアントの実装
> PHP, Ruby, ... の実装を全部用意するのは大変だ...
_人人人人人人_
>   <
 ̄Y^Y^Y^Y^Y ̄
既存のAPIを借用する?
http://aws.amazon.com/jp/s3/
S3 互換 API ???
> 「S3 を作る」じゃ無いよ
> 同じものつくれんわー (棒
> 「mogilefs に S3 と同じインタ
フェース をかぶせる」
> クライアントから見て S3 と同等に動く事
> 必要な API だけ実装
S3 互換 API
> aws-sdk 等, OSSクライアントを利用可能
> ( … な様に作る )
> S3 と合わせてリファレンス実装となる
> HMAC認証等、再実装が煩雑なものが ってる
> API 実装もいろいろ
> とはいえ mo...
S3 互換の制約
> S3 API ができる事だけ提供
> 利用サービスに制約が課されることになる
> S3 を使うんだ!!! という設計にしてもらえれば
> 利用クライアントの特殊なドメインに閉じた API が増えな
いという利点はあるかも
...
S3 互換 API の仕様
> REST API のドキュメントが公開されています !
> ここに載ってない挙動は S3 を叩いて確認するか SDK
を見るか OSS実装を読んで埋めていく
http://docs.aws.amazon.com/...
さくらさんのオブジェクトストレージ のリファレンス
> さくらさんの「オブジェクトストレージ API リファレンス」
を先に読むと S3 互換として最低限必要そうなものが把握し
やすい (^^;
http://cloud-news.sakura...
API 実装
API の実装を考える
> 何で実装しよう?
> 言語 何にする?
> フレームワーク 何にする?
> 条件
> 期限はきびしめプロジェクト
> 今後の継続的メンテナンス もちろん必須
> どうやって決めようね?
必須
> MogileFS クライアント ★★★
> MySQL クライアント
> HTTP のハンドリング
> その他
> XML のパース/生成
> HMAC認証の実装で SHA256 であれこれ
既存APIを見直す
既存API perl-Catalyst
> perl-Catalyst API の稼働実績がある
> 専用のインターナルな API
> ところが、俺俺 API な仕様
> API・DBテーブル設計も S3 仕様とは違う
> Perl で作る?
...
MogileFS クライアント
> Perl
> MogileFS::Client
> 本家本元。枯れている
> Ruby
> mogilefs-client
> Unicorn の作者製
> Go
> GitHub にいくつか実装落ちてるけど...
mogilefs-client
> Unicorn を実装している方が作っている
> mogilefsd を冗長化した場合のラウンドロビン
機能、高速に動くような工夫アリ
> MogileFSにコミットもしている
> 信頼感高い
> おまけ
>...
フレームワーク
> Rails on ペパボ
> 社内で Rails を採用しているサービス(リポ
ジトリ) 10∼件
> Ruby も含め社内に識者多数
> Rails についての pros / cons は語り尽くされていると
思うので割愛...
Rails とパフォーマンス
> 30days 用 perl-Catalyst API の
実績から Rails で代替可能と判断
> ネットワーク I/O バウンド
> mogilefsd がボトルネック
> Rails でも十分に捌けると見...
細かい実装
実装の指針
> S3をリファレンス実装とする
> S3 へのリクエスト/レスポンスをテスト(request
spec) に起こしてから テストドリブンで作ってく
> バグレポートのやり取りが楽
Aさん「S3 に foo bar した結果と Ba...
認証
> HMAC認証
> AWS4-HMAC-SHA256
> 公式ドキュメントでアルゴリズムが公開されているので
実装します
• http://docs.aws.amazon.com/ja_jp/general/
latest/gr/sig...
HTTPルーティング
> ドキュメントのを一個一個追って作る
> 機能を実装しない API でも 501 Not Implemented を返すように
ルーティングだけ作るの大事。漏れがあると別のAPI にルーティング
されて意図しない挙動をす...
スキーマ例
> メタデータの CRUD は1テーブルで実装できる
> 一部正規化されていないのは過去の実装を引きずっている
> bucket も DBで扱う複数テーブル実装になるはず
オブジェクトのCRUD
> DBのレコードを CRUD + mogilefs で
CRUD を1コントーロラ、1トランザクショ
ンとして作っていく
> 合わせて S3仕様のレスポンスボディ(XML) や 30X系ス
テータスを返す実装を埋めてい...
list objects API
> オブジェクトの一覧(XML)を返す
list objects API
> S3に「ディレクトリ」は無い
> ディレクトリは擬似的に作られているだけ
> CommonPrefixes と呼びます
CommonPrefixes の例
CommonPrefixes
> 前方一致の LIKE検索で取り、Rails で文字列加工する
list objects API
> 「ディレクトリ」に大量のオブジェクトがある
場合の CommonPrefixes をどう作るか?
list objects API
> 「ディレクトリ」に大量のオブジェクトがある
場合の CommonPrefixes をどう作るか?
> クエリを複数回投げる + Railsで文字列加工
> LIKE と NOT LIKE と > を組み合わせ...
API チューニング
rails-api
> rails/all から rails-api でダイエット
> 必要な Rails コンポーネントだけ require する
> メモリ(RSS) を小さく
API チューニング
> XML の生成がちと遅い
> builder, nokogiri, ox で比較
> builder はインデントの有無で速度が結構変わる
> 結果、ox がちょっぱやだった
API チューニング
> XML のパースがちと遅い
> デフォルトは REXML
> REXML, ox で比較
> ox がちょっぱやだった
> ( sorry, no benchmark data )
New Relic
のメトリクスチラ見
オブジェクトのHEAD
> 1
> メタデータを1件SELECT
> シンプル
> それなりに速い
オブジェクトのGET
> メタデータを1件SELECT + mogilefs 参照
> +100ms ∼
> mogilefsd ちょっと遅いですね …
所感
所感 (1)
> S3 互換 = 大きな山に見えていたが
> コアな API は 素朴に CRUD + XML をごそご
そするだけで作っていける
> バックエンドのストレージによって実装
の難易度が変わりそう
> 過去の perl-Catal...
所感 (2)
> もっと高速化したいね
> Rails の恩恵を受けている箇所は控えめ
> もっと素朴なフレームワークで小さく・速くなるか?
> mogilefs バウンドをどうするか?
> mogilefs をバイバスして DB を直で触る実...
所感 (3)
> このような方向性もありますね
https://speakerdeck.com/naoya/web-api-sabatositefalse-elixir-falseke-neng-xing
Upcoming SlideShare
Loading in …5
×

MogileFS をバックエンドとしたPrivate S3の作り方 【後半】API 編

4,867 views

Published on

http://www.slideshare.net/lamanotrama/mogilefsprivate-s3 とワンセットの発表となります

Published in: Technology
  • 前半はこちら http://www.slideshare.net/lamanotrama/mogilefsprivate-s3
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

MogileFS をバックエンドとしたPrivate S3の作り方 【後半】API 編

  1. 1. 【後半】API 編 GMO Pepabo, Inc. 伊藤洋也 2015/08/29 ペパボテックカンファレンス 第3回 @渋谷セルリアンタワー MogileFS をバックエンドとした Private S3の作り方
  2. 2. 伊藤洋也 @hiboma > GMOペパボ 技術基盤チーム > 低いレイヤの問題解決が好きです
  3. 3. スライドの用語 > オブジェクト > 本スライドでは「 mogilefs ストレージに 格納されたデータ」を指します > メタデータ > オブジェクトの名前, サイズ, MIME, 作成日 時, ETag … 等 を保持する MySQLのレ コードを指します
  4. 4. アジェンダ > S3 互換 API を実装したお話し > 設計に S3 互換を採用するまで > 言語・フレームワークの選定 > 実装 > チューニング小話 > New Relic チラ見 > 所感
  5. 5. (前半のおさらいも含めて) 何が必要なのか?
  6. 6. 必要なAPI
  7. 7. 必要なAPI
  8. 8. 必要なAPI > オブジェクトのGET/PUT/DELETE/HEAD > オブジェクトのリスト取得 > オブジェクトのアクセス権コントロール > 認証 (HMAC認証) > … etc
  9. 9. 「Rails で S3 互換 API を実装するぞ!!!!1」 を決めるまで
  10. 10. API 設計
  11. 11. API > どう設計しましょう? > 何で実装しよう? > そもそも作る必要あんの?
  12. 12. 設計の選択肢 > 新しく API を設計する? > 既存の API を借用する?
  13. 13. 新しくAPIを設計する? > 設計するの…やだナー… (本音) > 会社の基盤となるストレージ の API > 時間に耐えうる設計の重さ > サーバサイド + クライアントの実装 > PHP, Ruby, ... の実装を全部用意するのは大変だナー > 仕様を社内で流布するのも大変だナー
  14. 14. _人人人人人人_ >   <  ̄Y^Y^Y^Y^Y ̄ 既存のAPIを借用する? http://aws.amazon.com/jp/s3/
  15. 15. S3 互換 API ??? > 「S3 を作る」じゃ無いよ > 同じものつくれんわー (棒 > 「mogilefs に S3 と同じインタ フェース をかぶせる」 > クライアントから見て S3 と同等に動く事 > 必要な API だけ実装
  16. 16. S3 互換 API > aws-sdk 等, OSSクライアントを利用可能 > ( … な様に作る ) > S3 と合わせてリファレンス実装となる > HMAC認証等、再実装が煩雑なものが ってる > API 実装もいろいろ > とはいえ mogilefs をバックエンドとして流用できるものはさすがに 無かった > 細かい仕様や実装の参考になるものはたくさんある > リクエストパラメータの扱いや、SQLの組み方、エラーで返す XML の組み方等々
  17. 17. S3 互換の制約 > S3 API ができる事だけ提供 > 利用サービスに制約が課されることになる > S3 を使うんだ!!! という設計にしてもらえれば > 利用クライアントの特殊なドメインに閉じた API が増えな いという利点はあるかも > API の 拡張はむずかしそ > SDK の実装をいじっての拡張や改造あれこれは大変そう > SDK v1 -> v2 からのアップデートでごっそり実装が書き 換えられたこともある
  18. 18. S3 互換 API の仕様 > REST API のドキュメントが公開されています ! > ここに載ってない挙動は S3 を叩いて確認するか SDK を見るか OSS実装を読んで埋めていく http://docs.aws.amazon.com/AmazonS3/latest/API/APIRest.html
  19. 19. さくらさんのオブジェクトストレージ のリファレンス > さくらさんの「オブジェクトストレージ API リファレンス」 を先に読むと S3 互換として最低限必要そうなものが把握し やすい (^^; http://cloud-news.sakura.ad.jp/wp-content/uploads/2015/01/ObjectStorage_API.pdf
  20. 20. API 実装
  21. 21. API の実装を考える > 何で実装しよう? > 言語 何にする? > フレームワーク 何にする? > 条件 > 期限はきびしめプロジェクト > 今後の継続的メンテナンス もちろん必須 > どうやって決めようね?
  22. 22. 必須 > MogileFS クライアント ★★★ > MySQL クライアント > HTTP のハンドリング > その他 > XML のパース/生成 > HMAC認証の実装で SHA256 であれこれ
  23. 23. 既存APIを見直す
  24. 24. 既存API perl-Catalyst > perl-Catalyst API の稼働実績がある > 専用のインターナルな API > ところが、俺俺 API な仕様 > API・DBテーブル設計も S3 仕様とは違う > Perl で作る? > ペパボで Perl の継続的開発 できるだろうか > 黒田と伊藤は Perl 得意だけど > 会社全体で見ると … うーん > 別の言語で作りなおしも視野にいれよう
  25. 25. MogileFS クライアント > Perl > MogileFS::Client > 本家本元。枯れている > Ruby > mogilefs-client > Unicorn の作者製 > Go > GitHub にいくつか実装落ちてるけどテストが無いとか > …
  26. 26. mogilefs-client > Unicorn を実装している方が作っている > mogilefsd を冗長化した場合のラウンドロビン 機能、高速に動くような工夫アリ > MogileFSにコミットもしている > 信頼感高い > おまけ > Perl のクライアントより遥かに読みやすい (^^; > 黒田 & 伊藤 「perl の MogileFS クライアントはむずかし い 」
  27. 27. フレームワーク > Rails on ペパボ > 社内で Rails を採用しているサービス(リポ ジトリ) 10∼件 > Ruby も含め社内に識者多数 > Rails についての pros / cons は語り尽くされていると 思うので割愛 > 運用も枯れている
  28. 28. Rails とパフォーマンス > 30days 用 perl-Catalyst API の 実績から Rails で代替可能と判断 > ネットワーク I/O バウンド > mogilefsd がボトルネック > Rails でも十分に捌けると見込み > スタート時点で扱うオブジェクトのサイズも 1MB未満の ものがほとんど
  29. 29. 細かい実装
  30. 30. 実装の指針 > S3をリファレンス実装とする > S3 へのリクエスト/レスポンスをテスト(request spec) に起こしてから テストドリブンで作ってく > バグレポートのやり取りが楽 Aさん「S3 に foo bar した結果と Bayt に foo bar した結果が違うんですが?」 私「Bayt が間違っています! 直します!」
  31. 31. 認証 > HMAC認証 > AWS4-HMAC-SHA256 > 公式ドキュメントでアルゴリズムが公開されているので 実装します • http://docs.aws.amazon.com/ja_jp/general/ latest/gr/sigv4-create-string-to-sign.html
  32. 32. HTTPルーティング > ドキュメントのを一個一個追って作る > 機能を実装しない API でも 501 Not Implemented を返すように ルーティングだけ作るの大事。漏れがあると別のAPI にルーティング されて意図しない挙動をするケースを生む
  33. 33. スキーマ例 > メタデータの CRUD は1テーブルで実装できる > 一部正規化されていないのは過去の実装を引きずっている > bucket も DBで扱う複数テーブル実装になるはず
  34. 34. オブジェクトのCRUD > DBのレコードを CRUD + mogilefs で CRUD を1コントーロラ、1トランザクショ ンとして作っていく > 合わせて S3仕様のレスポンスボディ(XML) や 30X系ス テータスを返す実装を埋めていく > +αで mogilefsd の過負荷に備えてのリトライ実装等 > aws-sdk でリトライが実装されているけど、API でもリトライ
  35. 35. list objects API > オブジェクトの一覧(XML)を返す
  36. 36. list objects API > S3に「ディレクトリ」は無い > ディレクトリは擬似的に作られているだけ > CommonPrefixes と呼びます
  37. 37. CommonPrefixes の例
  38. 38. CommonPrefixes > 前方一致の LIKE検索で取り、Rails で文字列加工する
  39. 39. list objects API > 「ディレクトリ」に大量のオブジェクトがある 場合の CommonPrefixes をどう作るか?
  40. 40. list objects API > 「ディレクトリ」に大量のオブジェクトがある 場合の CommonPrefixes をどう作るか? > クエリを複数回投げる + Railsで文字列加工 > LIKE と NOT LIKE と > を組み合わせて 途中のレコードをスキップして探索 > 前方一致でインデックス使える > Covering Index の活用
  41. 41. API チューニング
  42. 42. rails-api > rails/all から rails-api でダイエット > 必要な Rails コンポーネントだけ require する > メモリ(RSS) を小さく
  43. 43. API チューニング > XML の生成がちと遅い > builder, nokogiri, ox で比較 > builder はインデントの有無で速度が結構変わる > 結果、ox がちょっぱやだった
  44. 44. API チューニング > XML のパースがちと遅い > デフォルトは REXML > REXML, ox で比較 > ox がちょっぱやだった > ( sorry, no benchmark data )
  45. 45. New Relic のメトリクスチラ見
  46. 46. オブジェクトのHEAD > 1 > メタデータを1件SELECT > シンプル > それなりに速い
  47. 47. オブジェクトのGET > メタデータを1件SELECT + mogilefs 参照 > +100ms ∼ > mogilefsd ちょっと遅いですね …
  48. 48. 所感
  49. 49. 所感 (1) > S3 互換 = 大きな山に見えていたが > コアな API は 素朴に CRUD + XML をごそご そするだけで作っていける > バックエンドのストレージによって実装 の難易度が変わりそう > 過去の perl-Catalyst API の実績や MogileFS の知見/経験があることで暗黙知で楽ができた部分 多数
  50. 50. 所感 (2) > もっと高速化したいね > Rails の恩恵を受けている箇所は控えめ > もっと素朴なフレームワークで小さく・速くなるか? > mogilefs バウンドをどうするか? > mogilefs をバイバスして DB を直で触る実装 > 他の言語、アーキテクチャ … > golang, …
  51. 51. 所感 (3) > このような方向性もありますね https://speakerdeck.com/naoya/web-api-sabatositefalse-elixir-falseke-neng-xing

×