関西オープンソース 2008 30days Albumの裏側

関西オープンソース 2008 （株） paperboy&co. 宮下剛輔 2008/11/7

アジェンダ

自己紹介

30days Album 紹介

サーバソフトウェアまわりの話

運用まわりの話

自己紹介

宮下剛輔と申します

（株） paperboy&co. で技術責任者というのをやってます

ナウでヤングなレンタルサーバロリポップ！の会社です

個人的には

mizzy.org の中の人

Perl プログラマの人

Puppet の人

ドクターペッパーの人

30days Album

http://30d.jp/

オンラインアルバムサービス

30 日間限定

30 日経過すると閲覧できなくなる

その後 10 日間アーカイブダウンロードができる

40 日経過後、完全に削除

合い言葉制

合い言葉を知ってる人だけ閲覧できる

合い言葉を知ってる人なら誰でも投稿できる

シンプルなインターフェース

あまりコンピュータ詳しくない人がターゲット

30days Album 誕生の経緯

社内プレゼン大会で優勝したアイデア

プロジェクトキックオフ飲み会でホルモン喰いながらドメイン名（ 30d.jp ）を決定して即取得（もちろんムームードメインで）

開発合宿（お産合宿）で実装開始

30days Album の開発体制

デザイナ 1 人

開発 3 人

フロント Web アプリ

ストレージ API

ジョブサーバ API ＋ジョブワーカー

サーバ周り２人

30days Album 全体構成リバースプロキシ Web アプリ画像ストレージジョブサーバデータベース

リバースプロキシリバースプロキシ Web アプリ画像ストレージジョブサーバデータベース

リバースプロキシ

サービスの入り口

Perlbal

Perl 製のリバースプロキシ / ロードバランサー

Perl でプラグイン書いて機能拡張できる

2 台で DNS ラウンドロビン

ウェブアプリと画像ストレージへの振り分け / 負荷分散

3 つの独自プラグイン

SSL 接続か否かをウェブアプリへ通知

画像アクセスに対する認証

URL マッピング

リバースプロキシリバースプロキシ Web アプリ画像ストレージジョブサーバデータベース http://30d.jp/img へのアクセス http://30d.jp/img 以外へのアクセス

Web アプリリバースプロキシ Web アプリ画像ストレージジョブサーバデータベース

Web アプリ

サービスの中心部分

アルバム作成 / 閲覧 / 投稿

認証（メールアドレス / パスワード、合言葉）

Ruby on Rails + lighttpd + FastCGI

SWFUpload

BackgrounDRb

表示用サムネイル生成

ジョブサーバへの画像処理ディスパッチ

リサイズ

ローテート

アーカイブ

なぜ Ruby on Rails なのか？

うちは PHP がメイン

初の Ruby を使ったサービス

なぜ Ruby なのか？

それメインプログラマが Ruby 好きなので

それだけです

開発者が一番好きな言語で開発するのがモチベーション向上には一番

画像ストレージリバースプロキシ Web アプリ画像ストレージジョブサーバデータベース

画像ストレージ

MogileFS + 独自のストレージ API

MogileFS

Perl 製の分散ストレージシステム

複数ノードへの自動振り分け

自動レプリケーション

ストレージ API

MogileFS は専用クライアントライブラリが必要

HTTP GET/PUT で画像の出し入れ

Catalyst + lighttpd + FastCGI

Conten-Type や Content-Length の管理

ストレージ API ＋ MogileFS ストレージ API tracker (mogilefsd) トラッカー DB (MySQL) storage node (mogstored) storage node (mogstored) ストレージノード (mogstored) トラッカー (mogilefsd) ファイルの実体ファイルのメタデータ

Perlbal 経由の画像取得（通常）ストレージノードストレージノード Perlbal ストレージ API ストレージノードファイルリクエストファイル取得ファイルの内容を返す

X-REPROXY-URL ヘッダ

画像の取得をストレージ API 経由でやるのは効率が悪い

FastCGI プロセスを画像転送だけで占有してしまう

そこで画像取得時に、画像データではなく、 X-REPROXY-URL ヘッダを Perlbal に返す

ヘッダの値は MogileFS のストレージノード上にある、ファイルの実体を示す URL

X-REPROXY-URL ヘッダを使う場合ストレージノードストレージノード Perlbal ストレージ API ストレージノードファイルリクエスト X-REPROXY-URL: http://storage_node/dev1/0/000/... X-REPROXY-URL ヘッダをもとにファイル取得

画像ストレージのディスク構成

500GBx2 本

/boot は RAID1

swap, / は RAID1+LVM

/data は LVM で 1 パーティションに見せ、大きく使う

/boot swap / /data RAID1 /boot swap / /data RAID1+LVM LVM

画像ストレージのサーバ構成

リリース時はサーバ 2 台

API 、トラッカー（ mogilefsd ）、ストレージノード（ mostored ）が共存

MogileFS の機能により、 2 台のサーバは同じデータをストア

ストレージ API mogilefsd mogstored ストレージ API mogilefsd mogstored

画像ストレージのサーバ構成

現在は 4 台

追加した 2 台はストレージノードとしての役割のみ

アプリケーションの修正やサービスの再起動を全くせずに拡張できた

ストレージ API mogilefsd mogstored ストレージ API mogilefsd mogstored mogstored mogstored

画像のアクセスコントロール

Web アプリ

最初の認証は必ずここ

メールアドレス / パスワード

合い言葉

認証後、セッションキーとアクセス可能なアルバムの相対 URL を memcached にセット

リバースプロキシ

Web アプリが memcached にセットした情報を元に、画像へのアクセスコントロールを実施

画像のアクセスコントロール Perlbal Web アプリ画像ストレージ memcached 認証時に、セッションキーとアクセス可能なアルバム名をセットセッションキーを元に、アクセス可能なアルバム名を取得して、リクエストを許可 / 拒否認証画像取得

ジョブサーバリバースプロキシ Web アプリ画像ストレージジョブサーバデータベース

ジョブサーバ

Gearman ＋ TheSchwartz ＋独自のジョブ API

Gearman

Perl でできたジョブキュー

リアルタイム性が高い

ステータス管理しない

TheSchwartz

Perl でできたジョブキュー

MySQL でキューを管理

リアルタイム性が低い

ステータス管理、リトライ

ジョブ API

Catalyst + lighttpd +FastCGI

XMLRPC でジョブ処理を受け付け

後ろの Gearman, TheSchwartz へジョブ依頼

ジョブサーバの構成ジョブ API gearmand gearman worker TheSchwartz worker MySQL

ジョブの種類

Gearman

リアルタイム性の高い処理

アルバムを表すサムネイル

画像の回転

TheSchwartz

リアルタイム性の低い処理

画像リサイズ

アーカイブ作成

Ruby + memcached

Ruby Memcache Client が、 memcached にデータをセットする際に、デフォルトで marshal する

Perlbal で memcached からデータを取得すると、なんかゴミが入ってる

オプションで marshal しないように設定して回避

mogstored + lighttpd

mogstored は WebDAV サーバ

デフォルトは Perlbal がバックエンド

設定で Apache や lighttpd をバックエンドにすることができる

Perlbal だと不安定で lighttpd に変更

mogstored で保存されるファイルは、ディレクトリが階層化されている

/data/dev1/0/005/090/0000000012.fid

mogstored + lighttpd （つづき）

Perlbal がバックエンドの時は、存在しないディレクトリにファイルを PUT しても、勝手につくってくれる

Apache や lighttpd の場合はエラーになる

MogileFS::Client に手を入れて修正

PUT しようとするディレクトリの存在を確認し、存在しなければ MKCOL

Perlbal の Out of memory

リバースプロキシの Perlbal が頻繁に落ちる

ログには Out of memory! のみ

DEBUGGING オプションつけて Perl をコンパイル

Danga::Socket の以下の行で発生してると判明

my $res = sysread($sock, $buf, $req_bytes, 0);

$req_bytes を小さくして対応

Puppet

Ruby 製のシステム管理ツール

クライアント / サーバ型

サーバの状態を独自言語で定義

マニフェストと呼ばれる

マニフェストは Puppet サーバで一元管理

各サーバで Puppet クライアントを動かし、マニフェストを適用してサーバ構築や設定変更を行う

Puppet マニフェスト

package {

‘ MogileFS-Server’:

ensure => present ;

‘ MogileFS-Server-mogilefsd’:

ensure => present ;

‘ MogileFS-Server-mogstored’:

ensure => present ;

}

Puppet の構成 Puppet サーバ (puppetmasterd) Puppet クライアント (puppetd) Puppet クライアント (puppetd) Puppet クライアント (puppetd) マニフェストの取得と適用実行結果のレポートプロトコルは XMLRPC over HTTPS

Puppet によるサーバ構築

OS インストール

ネットワーク設定

Puppet インストール

Puppet 実行

完了

Puppet マニフェスト

独自の宣言型言語でサーバの状態を記述

プログラミング言語ほどの自由度はない

自由度がないぶん、人による差異が出にくい

サーバの状態をテキスト形式で記述

Subversion 等で管理できる

誰がどういう変更を行ったのか、追跡しやすい

Archer

Perl 製のデプロイツール

Capistrano みたいなやつ

モバイルファクトリの松野徳大さん (id:tokuhirom) が開発

プラグインで拡張が簡単

YAML で動作を定義

Archer 設定ファイル

tasks :

init:

- module: SVN::Update

process:

- module: Rsync

- module: Exec::Remote

config:

command: /etc/init.d/lighttpd restart

projects :

days:

storage_api:

- storage1.30d.jp

- storage2.30d.jp

Archer の動作イメージ対象サーバ対象サーバ Subversion デプロイサーバ対象サーバ ① archer.pl –c days.conf ② svn up ③ 前処理 ④ rsync ⑤ 対象サーバ上で後処理（ SSH でコマンド実行）

Days での Archer の使い方

プログラムのアップデート

プログラム修正して svn co

archer.pl –c program.conf

Puppet マニフェストのアップデート

マニフェストを修正して svn co

archer.pl –c manifest.conf

puppetmasterd の再起動も archer コマンド一発

独自 yum サーバ上の RPM パッケージアップデート

パッケージをアップデートして svn co

archer.pl –c yum.conf

createrepo の実行も archer コマンド一発

OpenLDAP

社内で利用

SSH ログイン

Subversion 認証

Trac 認証

30days Album でも利用

SSH ログイン

Puppet ノード管理

社内の LDAP データと同期

独自の同期スクリプト

OpenSSH + LPK patch

LDAP Public Key patch

$HOME/.ssh/authorized_keys の代わりに、 LDAP 内の sshPublicKey 属性を参照

各サーバに authorized_keys を配布しなくても、 SSH の公開鍵認証ができる

LPK patch 用 LDIF

dn: uid=mizzy, ou=people, o=paperboy

objectclass : ldapPublicKey

sshPublicKey : ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIB3dsrwq

XqD7E4zYYrxwdDKBUQxKMioXy9pxFVai64k

APxjU9KSqIo7QfkjslfsjflksjfldfkjsldfjLX/5zkzR

mT28I5piGzunPv17S89z8XwSsuAoR1t86t+5

dlI7eZE/gVbn2UQkQq7+kdDTS2yXV6VnC52

N/kKLG3ciBkBAw==

関西オープンソース 2008 30days Albumの裏側

0 comments

Notes on slide 1

7 Favorites