2007年10月29日月曜日

oAuth の調査

oAuth という認証・認可のプロトコルに興味があり、調査している。

以下で認証と認可という言葉を使うので、まずここで整理する。
認証 (Authentication) と認可 (Authorization) は違う。

認証(Authentication)
そのユーザーが自分の物であると主張するIDに対して、そのIDが確かにそのユーザーの物であるということを保証すること

認可(Authorization)
認証されたIDを受け入れ、サービスに対して適切な権限を与えること

である。

oAuth というプロトコルをマッシュアップサイト作成時に使ってみることを考える。
プレイヤーは以下の 4種類。

1. End User
リソース所有者。Consumer にリソースを提供
2. Protected Resource
End User が Consumer に公開するリソース
3. Consumer
リソース処理者 (マッシュアップサイト)
4. Service Provider
リソース管理者 (マッシュアップされるサイト)

マッシュアップ時に問題になるのは、以下のことである。

Service Provider のリソースを利用するため、API を叩くとき、End User のユーザ ID とパスワードによる認証が必要である。多くの場合、そのアイパスは Consumer が管理することになる。
⇒ Consumer の管理リスク + End User のセキュリティリスクが高い。

このため、目標としては、

1. End User は Service Provider のサイトで認証したい。
2. Consumer は End User が Service Provider により認証されたユーザであることのみ知りたい。
3. End User は Consumer に自身が許可したリソースのみ認可したい。

ということになる。
この目標を達成してくれそうなのが、oAuth なのである。
ここで、oAuth による認証・認可フローを追ってみる。

1. End User は Consumer に Service Provider の Protected Resource 取得を依頼
2. Service Provider は Consumer に 401 (Unauthorized) + Request token
3. Consumer は Request token を End user に渡す。
4. End User は request token を使い、Service Provider と認証
5. Service Provider は End User に Access token 返却
6. End User は Consumer に Access token を渡す
7. Consumer は Access token を使い Service Provider に Protected Resource の取得を依頼 (⇒ OK!)

以上の過程で、上記の目標は達成可能である。
ここで、
  • Consumer は End User のログイン情報に介入していないこと
  • 4、 7 より oAuth の過程には認証も認可も含まれること

  • に注意して欲しい。

    後者より、oAuth は認証、認可どちらかに分類されるというより、リソースへのアクセス制御プロトコル、という位置付けが適当だろう。
    oAuth の標準化と実装が進むと、ネットの世界でますます面白いことができるようになると思っており、とても期待している。

    ※本記事では以下を参考にしました。
    OAuth Core 1.0 Draft 4
    OAuth - リソースへのアクセスを代行するプロトコル
    WebAPI のアクセス制御に使える OAuth という仕様
    OAuthは熱いかも?な件に関して
    OAuth の Auth は認証?認可?

    2007年10月28日日曜日

    パーティショニングによるデータベースのパフォーマンスチューニング

    パーティショニンングによるデータベースのパフォーマンスチューニングを勉強した。

    パーティショニングが必要な理由


    MySQL では DB 上のデータ量が増加するとパフォーマンスが低下する。
    以下が原因。

    1. MySQL では 1度アクセスされたデータやインデックスは効率化のためにバッファにキャッシュされる。
    2. データ量が増大すると、メモリ上のキャッシュサイズでは不足。
    3. ディスク I/O が増大し、パフォーマンス低下へ。

    テーブルや DB を分割(パーティショニング)し、アクセスされるデータがメモリ上に収まる状態をキープすることで対策する。
    パーティショニングは 2 アプローチが考えられる。

    1. アプリケーション側で実装
    2. MySQL のサポート機能を用いて実装


    アプリケーション側でのパーティショニング実装


    レプリケーションは参照系の負荷分散にはなるが更新系の負荷分散の解決にはならない。
    ⇒ DB のパーティショニングで解決。パーティショニングアプローチには以下の 3種類が考えられる。

    1. データの鮮度でパーティショニング
    直近のものは参照頻度が高い。直近のものを保持するテーブルを用意する。
    (バッチで順に古い DB へデータを移行)

    2. データの種類でパーティショニング
    ブログ記事はサーバ A, コメント記事はサーバ B みたいな感じ

    3. 論理的なデータ構造でパーティショニング
    アルゴリズムを決めてユーザごとにユーザテーブルを決定するなど (テーブルサイズが小さくなる)。

    MySQL のパーティショニング機能での実装


    MySQL 5.1 では β 版だがパーティショニングがサポートされている。

  • コンパイル時に -with-partition オプションをつける

  • ルールを設定して分割させる。
    • データの値の範囲で分割 (100 以上は A みたいな感じ)
    • データの値別に分割 (2,4,6 は A, 3,5,7 は B みたいな感じ)

    パーティショニングを実装したときの問題点


  • Join ができない。
  • ⇒ 複数回 SQL を発行して解決。O/R マッパを使用してプログラムの見通しを良くすること。

  • 全体での新着表示ができない。
  • ⇒ 全体テーブルを用意。Gearman などの非同期処理で全体テーブルを随時更新。

    2007年10月6日土曜日

    Twitter via QuickSilver

    以下、対象は Mac ユーザです。

    今年の主役の twitter ですが、
    twitter へ Quick Silver から post できます。
    結構便利なのと、参考 URI が英語サイトなので簡単にやり方を残しておきます。

    参考 URI は以下です。
    tweet -update twitter via quicksilver

    1.上記サイトから、 Tweet.scpt をダウンロード
    2. ダウンロードしたスクリプトを以下に移動( Actions ディレクトリがない人は、Actions ディレクトリを作成します。)
    ~/Library/Application Support/Quicksilver/Actions/Tweet.scpt
    3. Cmd+Ctrl+Q で QuickSilver を再起動。
    4. 必要に応じて、Tweet.scpt へトリガーキーを設定してください。 ( 参考 URI の中の人は Cmd+Opt+Ctrl+T としているみたいです。)
    5. ~/.twitter を編集し、パスワードを入力
    6. QuickSilver で Tweet.scpt を実行し、update したい内容を入力して、実行
    7. Tweet Sent と出たら成功。

    これでトリガーを使えば、 twitter へ簡単にポストできます。

    ちなみに僕の twitter は planets です。

    追記
    QuickSilver は日本語が使えないので、日本語を post したい場合は、post 内容を QuickSilver にコピペしないと駄目なようです。

    注意 以下がインストールされていることが前提です。
    Growl
    Ruby
    Rubygems
    Twitter Rubygem

    ruby をインストールしていない人は
    port install ruby
    で ruby をインストールしてから、
    sudo gem install twitter
    でインストールできます。

    また、port で ruby をインストールしている人は、Tweet Script 中の ruby のパスを ( 3 箇所 ) 変更します。
    /usr/local ⇒ /opt/local

    Rest スタイルと web 設計を考える

    web サービス設計や API 設計にあたって、今後は 「Rest」 という設計スタイルが自然とキーワードになってくると思います。
    僕はなかなか Rest が理解できなかったのですが、ここ 2 ヶ月くらい、Rest スタイルを意識するようになってから、色々と見えてきたこともあり、一旦自分なりに Rest を整理してみました。

    以下はある勉強会で使った資料です。

    Restful Web Services

    特に苦労したのは、Rest とは何かを理解してもらうのに何から説明したら良いか、ということです。
    個人的には URI の理解が第一歩だと思い、資料の順番となりました。

    Rest は仕様でなくスタイルであるが故、これは自分なりに理解した Rest であり、異論もあると思います。そんな方のフィードバック大歓迎です。

    Rest を理解するポイントは以下だと思います。

    • Rest とは、設計「仕様」ではなく設計「スタイル」である、ということを理解する。

    • リソースの概念を理解する。

    • URI の認識と URI 設計のポイントを理解する。

    • HTTP メソッドとレスポンスコードを理解する。

    • リソース間のつながりを理解し意識する。

    • 自分で API を設計してみる。

    • フレームワークと Rest 設計について考察する。

    上を見て興味が沸いてきた人は、Rest 入門 を読むと良いと思います。このブログは僕が Rest に興味を持ったきっかけでもあり、今改めて読んでみても思うところが多いです。
    特に、 Rest が「仕様」ではなく「スタイル」である、ということを認識できたのはこのブログのおかげだと思います。

    また、邦訳は出版されていないけれども、以下の本が Rest スタイルを理解するのに最適だと思います。