Tokuhiro Matsunoさん 「モダンな Perl5 開発環境について - Modern Perl5 Development Environment - 2010年代を生きのびる Perl5 活用術」
tokuhiromさんによる開発環境構築ノウハウの紹介トークです。
まずはperlの自体のインストールの話から。OSに標準ではいっているperlは一般的な設定となっているためthreadが有効になっているなどWebアプリケーションとして使うには不要な設定が入っていたりします。perlではthreadをoffにするだけでインタプリタの実行速度が10〜15%程度高速化されるそうで、WEBアプリケーション環境として使う場合には1からインストールしなおすことを進められていました。続いてどのバージョンを使うかという話ではperl-5.
perl環境を構築するうえでの便利なツールとして、様々なバージョンのperlを簡単に切り替えられるperlbrewや、標準のcpanコマンドの軽量版であるcpanm、インストールされているモジュールの更新をチェックするcpan-outdated、使わなくなったモジュールをアンインストールするpm-uninstallなどのツールの紹介がありました。そうやって構築したperl環境を本番環境に配置するときは、単純にrsyncするのがおすすめとのことです。
CPANモジュールの選び方についても紹介されました。CPANには現在8万以上のモジュールが登録されており、初心者がその中から必要なものを選ぶのはとても困難です。そんな中よいモジュールを選ぶにはやはり人に教えてもらうのが一番で、気楽にIRCチャンネルの#perl-casual@irc.
質疑応答では、リリース後更新されたCPANモジュールはどうアップデートするかという質問がありましたが、tokuhiromさんは開発中はどんどん最新化しているが、リリース後は気になったものだけをチェックして手動でアップデートされているそうです。
本トークは今回から導入されたセッション投票システムにおいて、Best talk賞を受賞されました。
Kensuke Kanekoさん「30days Albumの裏側 後日談」
昨日の前夜祭にも登場した,
最初に紹介されたのは,
Perlbalに関しては,
Hiroki DaichiさんInside Mixi - ソーシャルネットワークを支える技術
Hiroki Daichiさんにより、mixiシステムの内部について
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開発者に意識して欲しいものとして、
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.
iPhone, AndroidなどでOAuthを利用するためのtipsなどが紹介されました。例えばAndroidではAccount ManagerというOSがアカウント情報を統合管理する仕組みを持っているそうです。その他xAuthを使うときなどはパスワード情報の保存を平文でおこなってしまうと漏洩リスクが高いので、扱いに注意を促されていました。
最後にOAuthはそろそろ必須技術になってきているとして締めくくられました。