30days Album™ Information Blog.

写真共有・保存サービス「30days Album」の最新情報をお届けします。

30days Album を支える技術 #0 〜 サーバ構成概要

こんにちは、mizzy です。30days Album では、全体的なシステムデザイン、ストレージ API の開発、サーバ構築などを担当しています。このブログでは、「30days Album を支える技術」と題して、裏側でどういった技術が使われているのか、ご紹介していきたいと思います。もちろん、技術スタッフは私だけではないので、他のスタッフにも各自担当した技術について紹介してもらう予定です。

第0回目は、サーバ構成の概要についてです。30days Album の論理的なサーバ構成は、以下の図のようになっています。(実際には、1台のサーバが複数のコンポーネントを兼ねていますので、物理的な構成はこの通りではありません。)



各コンポーネントと、コンポーネント間の関係について、もう少し詳細に解説します。

リバースプロキシが、直接ユーザさんから見えている唯一のサーバで、ウェブブラウザからのリクエストを処理します。リクエスト URI に応じて、画像へのリクエストの場合にはストレージ API へ、それ以外のリクエストは Web アプリへ振り分けられます。

リバースプロキシには Perl 製のソフトウェアである Perlbal を利用しており、振り分け処理や画像リクエストに対する認証を、独自開発したプラグインで処理しています。

Web アプリは Ruby On Rails で開発されており、lighttpd + fastcgi の組み合わせで動作しています。30days Album の中心となる部分ですね。ここで画像への参照リクエスト以外の、すべてのリクエストを処理しています。

画像のアップロードも Web アプリでリクエストを受け取りますが、リサイズ処理はここでは行わず、裏側の非同期ジョブ API にリサイズ処理を依頼します。

非同期ジョブ API は、その裏側にあるジョブサーバに実際の仕事を割り振ります。この API は lighttpd + Catalyst で動作しています。

ジョブサーバには、
Gearman や TheSchwartz といった Perl 製のソフトウェアを利用しています。

ジョブサーバは画像のリサイズだけではなく、ダウンロード用のアーカイブ作成も担っています。

画像ストレージとしては、これもまた Perl 製である MogileFS を採用しています。MogileFS へのアクセスには専用のクライアントライブラリが必要なのですが、他のコンポーネントからストレージにアクセスしやすいように、前面に Amazon S3 ライクな API を配置しています。これにより、単純な GET や PUT などの HTTP リクエストのみでストレージにアクセスできるようになっています。この API も lighttpd + Catalyst で動作しています。

MySQL はすべてのコンポーネントに共通の永続的なデータストレージとして利用しています。

今回はサーバ構成の概要についてざっと駆け足でご紹介させていただきましたが、次回以降では、各コンポーネントについて、もっと掘り下げて解説していきたいと思います。
author: mizzy, date: 10:30, -, trackbacks(1)

Trackback

Trackback URL: http://30d.jugem.jp/trackback/13
-
管理者の承認待ちトラックバックです。
-, 2012/01/13 7:06 PM