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

【後半】API 編
GMO Pepabo, Inc.
伊藤洋也
2015/08/29 ペパボテックカンファレンス第3回 @渋谷セルリアンタワー
MogileFS
をバックエンドとした
Private S3の作り方

伊藤洋也 @hiboma
> GMOペパボ技術基盤チーム
> 低いレイヤの問題解決が好きです

スライドの用語
> オブジェクト
> 本スライドでは「 mogilefs ストレージに
格納されたデータ」を指します
> メタデータ
> オブジェクトの名前, サイズ, MIME, 作成日
時, ETag … 等を保持する MySQLのレ
コードを指します

アジェンダ
> S3 互換 API を実装したお話し
> 設計に S3 互換を採用するまで
> 言語・フレームワークの選定
> 実装
> チューニング小話
> New Relic チラ見
> 所感

(前半のおさらいも含めて)
何が必要なのか?

必要なAPI
> オブジェクトのGET/PUT/DELETE/HEAD
> オブジェクトのリスト取得
> オブジェクトのアクセス権コントロール
> 認証 (HMAC認証)
> … etc

「Rails で S3 互換 API
を実装するぞ!!!!1」
を決めるまで

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 実装もいろいろ
> とはいえ mogilefs をバックエンドとして流用できるものはさすがに
無かった
> 細かい仕様や実装の参考になるものはたくさんある
> リクエストパラメータの扱いや、SQLの組み方、エラーで返す XML
の組み方等々

S3 互換の制約
> S3 API ができる事だけ提供
> 利用サービスに制約が課されることになる
> S3 を使うんだ!!! という設計にしてもらえれば
> 利用クライアントの特殊なドメインに閉じた API が増えな
いという利点はあるかも
> API の拡張はむずかしそ
> SDK の実装をいじっての拡張や改造あれこれは大変そう
> SDK v1 -> v2 からのアップデートでごっそり実装が書き
換えられたこともある

S3 互換 API の仕様
> REST API のドキュメントが公開されています !
> ここに載ってない挙動は S3 を叩いて確認するか SDK
を見るか OSS実装を読んで埋めていく
http://docs.aws.amazon.com/AmazonS3/latest/API/APIRest.html

さくらさんのオブジェクトストレージのリファレンス
> さくらさんの「オブジェクトストレージ API リファレンス」
を先に読むと S3 互換として最低限必要そうなものが把握し
やすい (＾＾；
http://cloud-news.sakura.ad.jp/wp-content/uploads/2015/01/ObjectStorage_API.pdf

API の実装を考える
> 何で実装しよう?
> 言語何にする?
> フレームワーク何にする?
> 条件
> 期限はきびしめプロジェクト
> 今後の継続的メンテナンスもちろん必須
> どうやって決めようね?

必須
> MogileFS クライアント ★★★
> MySQL クライアント
> HTTP のハンドリング
> その他
> XML のパース/生成
> HMAC認証の実装で SHA256 であれこれ

既存API perl-Catalyst
> perl-Catalyst API の稼働実績がある
> 専用のインターナルな API
> ところが、俺俺 API な仕様
> API・DBテーブル設計も S3 仕様とは違う
> Perl で作る?
> ペパボで Perl の継続的開発できるだろうか
> 黒田と伊藤は Perl 得意だけど
> 会社全体で見ると … うーん
> 別の言語で作りなおしも視野にいれよう

MogileFS クライアント
> Perl
> MogileFS::Client
> 本家本元。枯れている
> Ruby
> mogilefs-client
> Unicorn の作者製
> Go
> GitHub にいくつか実装落ちてるけどテストが無いとか
> …

mogilefs-client
> Unicorn を実装している方が作っている
> mogilefsd を冗長化した場合のラウンドロビン
機能、高速に動くような工夫アリ
> MogileFSにコミットもしている
> 信頼感高い
> おまけ
> Perl のクライアントより遥かに読みやすい (＾＾;
> 黒田 & 伊藤「perl の MogileFS クライアントはむずかし
い」

フレームワーク
> Rails on ペパボ
> 社内で Rails を採用しているサービス(リポ
ジトリ) 10∼件
> Ruby も含め社内に識者多数
> Rails についての pros / cons は語り尽くされていると
思うので割愛
> 運用も枯れている

Rails とパフォーマンス
> 30days 用 perl-Catalyst API の
実績から Rails で代替可能と判断
> ネットワーク I/O バウンド
> mogilefsd がボトルネック
> Rails でも十分に捌けると見込み
> スタート時点で扱うオブジェクトのサイズも 1MB未満の
ものがほとんど

実装の指針
> S3をリファレンス実装とする
> S3 へのリクエスト/レスポンスをテスト(request
spec) に起こしてからテストドリブンで作ってく
> バグレポートのやり取りが楽
Aさん「S3 に foo bar した結果と Bayt に foo
bar した結果が違うんですが？」
私「Bayt が間違っています! 直します！」

認証
> HMAC認証
> AWS4-HMAC-SHA256
> 公式ドキュメントでアルゴリズムが公開されているので
実装します
• http://docs.aws.amazon.com/ja_jp/general/
latest/gr/sigv4-create-string-to-sign.html

HTTPルーティング
> ドキュメントのを一個一個追って作る
> 機能を実装しない API でも 501 Not Implemented を返すように
ルーティングだけ作るの大事。漏れがあると別のAPI にルーティング
されて意図しない挙動をするケースを生む

スキーマ例
> メタデータの CRUD は1テーブルで実装できる
> 一部正規化されていないのは過去の実装を引きずっている
> bucket も DBで扱う複数テーブル実装になるはず

オブジェクトのCRUD
> DBのレコードを CRUD + mogilefs で
CRUD を1コントーロラ、1トランザクショ
ンとして作っていく
> 合わせて S3仕様のレスポンスボディ(XML) や 30X系ス
テータスを返す実装を埋めていく
> +αで mogilefsd の過負荷に備えてのリトライ実装等
> aws-sdk でリトライが実装されているけど、API でもリトライ

list objects API
> オブジェクトの一覧(XML)を返す

list objects API
> S3に「ディレクトリ」は無い
> ディレクトリは擬似的に作られているだけ
> CommonPreﬁxes と呼びます

CommonPreﬁxes
> 前方一致の LIKE検索で取り、Rails で文字列加工する

list objects API
> 「ディレクトリ」に大量のオブジェクトがある
場合の CommonPreﬁxes をどう作るか?

list objects API
> 「ディレクトリ」に大量のオブジェクトがある
場合の CommonPreﬁxes をどう作るか?
> クエリを複数回投げる + Railsで文字列加工
> LIKE と NOT LIKE と > を組み合わせて
途中のレコードをスキップして探索
> 前方一致でインデックス使える
> Covering Index の活用

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-Catalyst API の実績や MogileFS
の知見/経験があることで暗黙知で楽ができた部分
多数

所感 (2)
> もっと高速化したいね
> Rails の恩恵を受けている箇所は控えめ
> もっと素朴なフレームワークで小さく・速くなるか?
> mogilefs バウンドをどうするか?
> mogilefs をバイバスして DB を直で触る実装
> 他の言語、アーキテクチャ …
> golang, …

所感 (3)
> このような方向性もありますね
https://speakerdeck.com/naoya/web-api-sabatositefalse-elixir-falseke-neng-xing

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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

Recently uploaded

Recently uploaded (15)