Tokuhiro Matsunoさん 「モダンな Perl5 開発環境について - Modern Perl5 Development Environment - 2010年代を生きのびる Perl5 活用術」

tokuhiromさんによる開発環境構築ノウハウの紹介トークです。

まずはperlの自体のインストールの話から。OSに標準ではいっているperlは一般的な設定となっているためthreadが有効になっているなどWebアプリケーションとして使うには不要な設定が入っていたりします。perlではthreadをoffにするだけでインタプリタの実行速度が10〜15％程度高速化されるそうで、WEBアプリケーション環境として使う場合には1からインストールしなおすことを進められていました。続いてどのバージョンを使うかという話ではperl-5.12.2が一番とのことでした。安定志向の場合はperl-5.8.9も良いとのことですが、5.10以降はgiven/whenや、smart match, defined or (//), naped captureなど便利な機能が使えるため、新しいバージョンを勧められていました。とくにdefined or (//)は0や空文字列に起因するバグ削減に効果的なので、これだけでも5.10以降を使う動機になるのではとのことでした。

perl環境を構築するうえでの便利なツールとして、様々なバージョンのperlを簡単に切り替えられるperlbrewや、標準のcpanコマンドの軽量版であるcpanm、インストールされているモジュールの更新をチェックするcpan-outdated、使わなくなったモジュールをアンインストールするpm-uninstallなどのツールの紹介がありました。そうやって構築したperl環境を本番環境に配置するときは、単純にrsyncするのがおすすめとのことです。

CPANモジュールの選び方についても紹介されました。CPANには現在8万以上のモジュールが登録されており、初心者がその中から必要なものを選ぶのはとても困難です。そんな中よいモジュールを選ぶにはやはり人に教えてもらうのが一番で、気楽にIRCチャンネルの#perl-casual@irc.freenode.orgやTwitterでperlについて質問してみるのがいいのではとのことでした。どうしても自分で選ばないといけないときの調べ方として、CPANソムリエになる方法というtokuhiromさんのエントリも紹介されました。

質疑応答では、リリース後更新されたCPANモジュールはどうアップデートするかという質問がありましたが、tokuhiromさんは開発中はどんどん最新化しているが、リリース後は気になったものだけをチェックして手動でアップデートされているそうです。

本トークは今回から導入されたセッション投票システムにおいて、Best talk賞を受賞されました。

Kensuke Kanekoさん「30days Albumの裏側 後日談」

昨日の前夜祭にも登場した，刺身さんによるトークです。paperboy&co.さんが開発している30days Albumという写真共有のサービスを運用するにあたり，発生した様々な問題について解説をして下さいました。30days AlbumではPerlbalとMogileFSを利用しており，主にこの二つのプロダクトにまつわる具体的な事例が紹介されました。

最初に紹介されたのは，MogileFSの稼働している実サーバの1つでディスク障害が起きたときの事例。このような障害が発生したときは，mogadmコマンドにてデバイスを一度「dead」の状態にし，その後データ復元後に「alive」へ戻すことで，サービス停止なしで障害対応が可能だったそうです。また，MogileFSのリバランスの動作も解説され，ネットワーク負荷やMySQLの負荷が上がるため，Muninなどの監視ツールで監視をしながら実行した方がよいと指摘されていました。MySQLの負荷については，MogileFSの最新版を使うことで緩和されるとのことです。

Perlbalに関しては，FLVの疑似ストリーミングへの対応とRangeヘッダへの対応について説明がありました。PerlbalはFLVの疑似ストリーミングを行うためのプラグインを持っていないため，paperboy&co.さんではこれを自作されているそうです。また，Rangeヘッダについてはバックエンドのストレージサーバの挙動に問題があったため，Rangeヘッダを含む場合に適切なContent-Lengthを表示できるように調整をしたとのことです。Rangeヘッダの仕様には複雑な機能も含まれていますが，その部分に関しては対応をしなくても実用上問題はないそうです。

Hiroki DaichiさんInside Mixi - ソーシャルネットワークを支える技術

Hiroki Daichiさんにより、mixiシステムの内部について「二つのスケーラビリティ(Performance, Development)」というテーマで発表されました。

Performance : アクセス数の増加や変動に耐える

mixiではmemcahcedをキャッシュ機構として利用しているそうです。memcachedは揮発性KVS、汎用キャッシュ機構、LRUといった特徴をもったプロダクトです。 キャッシュをする上で考慮する点として、キャッシュ方式とキャッシュ対象レイヤについて解説されました。キャッシュの方式は大きく分けてリードスルー方式とライトスルー方式があります。リードスルー方式では、データソースから読み込み時にキャッシュに書き込む方式で、実装が簡単という特徴があります。Perlで実装する場合は、Moose::RoleやClass::Method::Modifierを使えば、データ取得ロジックに手を加えずにキャッシュ機構が実現できるそうです。ライトスルー方式はデータソースへの書き込み時にキャッシュに保存する方法です。ただしデータソースへの保存粒度とキャッシュの粒度を合わせる必要があるなど実装上すこしハードルが上がりがちのようです。またmemcachedの場合はキャッシュが揮発するので、リードスルー方式と併用する必要があると述べられていました。続いてキャッシュ対象レイヤの話では、キャッシュの粒度についての説明がありました。データベースレコードの1カラムデータをキャッシュするレベルから、レコード単位、ドメイン単位、サービス単位など、様々な粒度でのキャッシュを使い分けているそうです。

Development : 機能追加や他人数開発に耐える

開発面でのスケーラビリティについては、MVCの重要性について述べられていました。特に様々なデバイスでサービスを展開する場合、コントローラが肥大化した作りだとうまくいかないケースが多く、MVCの真価が問われるとのことでした。また凝集度を高く結合度を低く保つことも重要です。ライブラリは 基礎ライブラリ、フレームワーク、サービス、アプリケーションというレイヤに分割し、レイヤごとの依存関係の制限や、品質基準などを設定されているということでした。またModelのCRUD操作にフックを定義されていて、それによりモデルの深い事情をしらなくても連携するサービスが作れるようになっているそうです。イイネ機能などはその仕組みにより実装されているとのことでした。

まとめ

最後にまとめとして、パフォーマンス面でも開発面でもスケーラビリティを保つためには負荷の分散構成と責務の分散構成が必要だが、それらは構成的には共通点が多いということをおっしゃっていました。

Tatsuro Hisamoriさん「ソーシャルアプリ向け　システム監視運用の勘所」

このセッションは、Social Applicationの開発者を対象としたレスポンス時間に関する不具合を調査する方法についてのトークでした。DeNAのHisamoriさんより、実際に問い合わせが発生した事例に基づいて現象の切り分けていくHow Toが紹介されました。

Social Applicationでは、コンテンツ提供サーバがレスポンスをする際に、タイムアウトが規定されています。今回の事例では、規定の時間内にコンテンツを返しているのにタイムアウトになってしまう、という問い合わせが発生したというものでした。結論としては、GadgetServerの計測する時間とプロバイダー側が計測していた時間にブレがあるのが原因でした。前者は問い合わせを行うPerlコード内でalert関数での割り込みが発生する時間であったのに対し、後者はリクエストラインを受け取ってからの応答時間であったというものです。この調査に利用した道具として、tcpdumpとwiresharkが紹介されていました。

HisamoriさんはSocial Application開発者に意識して欲しいものとして、「⁠コンテンツを返すのにかかる時間」「⁠DB周りの処理時間」「⁠ネットワークのレイテンシの把握」の3つを上げていました。DBに関してはDBIx::ProfileManagerを利用したりmaatkitを利用した調査方法が紹介されました。レイテンシに関しては、EC2やGAEでは100msから200msの時間がかかることもあり、ネットワークだけで大きく不利になることもありうると指摘されていました。

Lyo Katoさん「DataPortability and SocialWeb Protocols」

まずは最近のソーシャルウェブ界隈の様々なプロトコルが紹介された後、OpenIDとOAuthによってサービスはIDの提供者(IdP:Identity Provider)とサービスの提供者(SP:Service Provider)をわけて考えることができるようになってきたと述べられました。それまでは各サービスごとにIdPとしての機能とSPとしての機能を実装する必要あったが、それらを他のサービスから借りてくるというエコシステムが形成されてきています。OpenIDとOAuthの相違点については、一般的にOpenIDはIdPの部分を移譲するための仕組みであり、OAuthはSPの部分を移譲するための仕組みとなっていますが、実際にはOpenIDでも拡張機能でユーザのプロファイル機能が取得可能であったり、OAuthでも認証をIdPに移譲していると言えなくもないなど、似通っている部分も多いとのことでした。

続いてOAuth2.0の紹介がありました。sslが必須になり、Request Tokenも必要なくなるそうです。また署名も必要なくなるかもしれないということで、そうなればクライアント側はOAuth用のライブラリがなくても通常のWebサービスクライアントライブラリだけで十分になるかもしれないと仰っていました。OAuth2.0の実装としてlyokatoさんが作成されているモジュールのOAuth::Lite2も紹介されていました。現在はOAuth2.0(draft10)に対応しているそうです。Server側はPlackに対応していて、OAtuth::Lite2::Server::Handlerを継承して実装します。ただしこの実装にはOAuthプロトコルを熟知していないと難しいそうです。

iPhone, AndroidなどでOAuthを利用するためのtipsなどが紹介されました。例えばAndroidではAccount ManagerというOSがアカウント情報を統合管理する仕組みを持っているそうです。その他xAuthを使うときなどはパスワード情報の保存を平文でおこなってしまうと漏洩リスクが高いので、扱いに注意を促されていました。

最後にOAuthはそろそろ必須技術になってきているとして締めくくられました。