みなさん、おひさしぶりです、キュン(@kyuns)です。 記事を書く時間がすっかり空いてしまい猛省... 先日iQONがリニューアルしました。 今回から数回に渡ってリニューアルまわりの記事を書きたいと思います。 まずはじめはシステムの全体的な構成についてです。 今回のリニューアルでは主に以下の点に絞ってシステムの構成を見直しました。 1.EC2インスタンスの引越し 2.Ruby化 3.内部APIモデルの採用 4.検索システムの見直し 1.EC2インスタンスの引越し 今まではAmazon EC2のUS-WEST (西海岸)で運用していたのですが今回のリニューアルにあたり EC2(東京リージョン)に変更しました。 もともとEC2の西海岸へはstaticなページでもレイテンシーが 400ms-600ms ほどあり、 不満がたまっていたところでした。 結果的に東京インスタンスへの移行は "劇的な" パフォーマンスアップにつながりました。 HA目的以外でまだ西海岸インスタンスを使っている人は今すぐにでも引っ越しするべきです。 EBS、およびS3のデータのコピー サーバー自体を東京インスタンスに移したことによりデータの保存先であるS3やEBSも東京リージョンに移行する必要がありました。 S3については名前を変えて新しく東京のバケットにつくりなおしました。 残念なことにAWSはデータを簡単に移行できるツールなどは用意してくれていないので 自前で西海岸のバケットから東京のS3バケットにコピーするスクリプトを組んで移しました。 EBSについても同様で手動でrsyncしました。 このあたりの作業は非常にめんどくさいですね。 AWSももう少しデータ移行まわりを強化してほしいです。 Cloud Frontの廃止 もうひとつ、AmazonのCDNサービスであるCloudFrontの利用も廃止しました。 今までは画像の配信にCloudFrontを使っていたのですが、S3のみのシステムに変更しました。 CloudFrontはとても便利なのですが、一度キャッシュされたものを削除するのが非常に手間だったのです。 AmazonCDNにはキャッシュを削除するAPIが用意されてはいるのですが そのAPIを実装したクライアントがほとんどないといっても過言ではありません。 現状僕が知るかぎりではCloudberryぐらいでしょうか。（しかもWindowsのみ) S3のみに変更したことによりレイテンシーが気になることは思いますが、 実際に調べてみるとCloudFront経由でS3の画像を取得した場合、一度キャッシュされた画像は 平均50msでレスポンスが返ってくるのですが、S3(東京)でもほぼ同等の速度がでており サービス運用に問題はないと判断しました。 2.Ruby化 今まではシステムのフロントエンドもバックエンドもPHPで構成されていたのですが 独自のPHPフレームワークを用いており、開発人数が増えたことにより メンテナンスおよび学習コストがかかるようになっていたのでRuby on Rails化することによって 複雑になっていた処理の見える化を行いました。 ソースコードは全てgitで管理されており、capistranoを用いてdeploy作業を行なっています。 capistranoについては以前に こちらの記事 で紹介しています。 アプリケーションサーバーはRuby1.9.2 + Rails 3.0.X + Passenger で動いています。 3.内部APIモデルの採用 内部APIモデルの採用の目的としては"データの取りだしやすさ"と"スケールのしやすさ"です。 近年Webアプリケーションではデータの加工部分のロジックは1箇所にまとめておいて データのアウトプット先がiPhoneやスマホ向けサイト等複数になってもデータを取り扱いやすいようにWebAPI化しておく いわゆる「API化」が進んでいると思います。 今回のリニューアルでもいわゆる内部APIモデルを採用しました。 データの取得、書き込みはすべてRESTfulなAPI経由で行っています。 フロントのアプリケーションサーバーにはロジックはほとんどいれず アプリケーションサーバーからAPIサーバーに対して HTTP経由で並列にデータを取得する流れになっています。 アプリケーションサーバーとAPIサーバーを切り離しているため デプロイも別々にでき、また台数も別々に増やすことができるためスケールが容易になっています。 また、キャッシュサーバーとしてMemcachedとVarnishを利用しています。 リアルタイム性が必要でかつデータの粒度が小さいものはmemcachedに入れておき 検索や一覧など、リアルタイム性のやや低いものはVarnishでレスポンスをまるごとキャッシュしています。 アイテムのデータやコーディネートの個別データなどはmemcached、検索一覧などはVarnish、といった感じです。 4.検索システムの見直し 今まではDBから検索するようにしていましたが、データ量が増え、 検索したい軸も増えてきたことにより検索エンジンを用いることにしました。 色々検討した結果、今回はAmebaやcookpadでも使われているSolrを使うことにしました。 これについては次回以降、nakedエンジニアの@6ratsが別途解説する予定です。 次回は 次回はiQONの肝であるエディター機能、および大規模JavaScript開発におけるノウハウなどを書こうと思います!

こんにちは。 VASILYのエンジニアの福本です。 前回は、 Redmineのbacklogsプラグインの概要とインストール方法 を紹介しました。 今回はインストール後の改善点について、メール設定とストーリ入力画面の改善についてご紹介します。 メール設定 SMTPにGoogleAppsを使用する VASILYではGoogleAppsを利用しているので、Redmineからのメール送信もGmailのSMTPを利用する事にします。 メール関連の設定は下記のファイルを参考に記述するのですが、親切にもGmail用の設定も雛形になっています。 redmine/config/configuration.yml.example GmailにはTLSを使用するので、いくつか作業してねと書いてあり RedmineBlog へのリンクが貼ってあります。 こちらの手順通りにやってみたいと思います。 1. TLS用プラグインのインストール Redmineのインストールディレクトリに行き、下記のコマンドを打つとインストールしてくれます。 ruby script/plugin install git://github.com/collectiveidea/action_mailer_optional_tls.git 2.設定ファイルの編集 先ほどの雛形ファイルを参考に、redmine/config/configuration.yml を作成します。 下記のようになります。 production : email_delivery : delivery_method : :smtp smtp_settings : tls : true address : "smtp.gmail.com" port : 587 domain: "smtp.gmail.com" # 'your.domain.com' for GoogleApps authentication : :plain user_name : "your_email@gmail.com" password : "your_password" 3.テストメール送信 管理者権限でログインし、管理>設定>メール通知の一番下に「テストメールを送信」というリンクがあります。 クリックすると自分のアカウントの登録メールアドレスにテストメールが送信されます。 何か問題があれば、エラーメッセージが表示されるようになっています。 これでGmailのSMTPを利用してメール送信をする事ができると思います。 非同期設定 メール送信はできるようになったのですが、バックログ管理画面やタスクボード上でのAjax操作が異様に遅くなりました。 先ほどの設定ではメール送信が同期設定になってしまっていたからです。 これだとメールが実際に送信されるまで処理が進まず、完了までに数秒待たされる事もあります。 非同期にできないかと調べていたら、やはりRedmine.JPにありました。 小技(0.9): 非同期メール送信を設定してチケット登録を高速化 (あとから雛形に書いてあるのを発見しました^^;;;ちゃんと見なきゃダメですね) 先ほどの設定のdelivery_methodのところをsmtpからasync_smtpに変更するだけです。 これで以前のパフォーマンスを取り戻しました！ production : email_delivery : delivery_method : :async_smtp # ここを変更 smtp_settings : tls : true address : "smtp.gmail.com" port : 587 domain : "smtp.gmail.com" # 'your.domain.com' for GoogleApps authentication : :plain user_name : "your_email@gmail.com" password : "your_password" メール送信制御 ただ、バックログ画面やタスクボードの操作でいちいちメールが送信されるのもうざいですよね。 少し調べた限り、設定での制御はできないようです。 こちらはコードを見てみて、変更できそうであれば改修してしまおうと思います。 うまくいったら、また紹介させていただきます。 バックログ管理画面のプチ日本語対応 バックログ管理画面のストーリー入力は日本語にやさしくありません。 漢字変換を確定させるEnterで入力が確定してしまいます。 ひとまず下記のJSを修正する事で、入力確定をEnterでは無くCtrl+Enterにすることで対処しました。 redmine/vendor/plugins/redmine_backlogs/assets/javascripts/editable_inplace.js $ diff editable_inplace.js editable_inplace.js.org 23 ,26c23, 28 < if ( event.ctrlKey === true && event.which === 13 ) { // Ctrl + Enter < that.saveEdits () ; & lt ; } else if ( event.which === 27 ) { // ESC < that.cancelEdit () ; --- > switch ( event.which ) { > case 13 : that.saveEdits () ; // Enter > break ; > case 27 : that.cancelEdit () ; // ESC > break ; > default : return true ; ストーリーを入力する部分について全般的にちょっと使いかってが悪いので、時間を取って調整をしようと思っています。 またアウトプットが出てきましたらご報告します。 VASILYではエンジニアを募集しています。 一緒に変化を楽しみませんか？ 詳しくは こちら をご覧ください！

はじめまして。 梅雨で頭がモジャモジャしはじめてきた天パエンジニアの福本です。 さて、VASILYではアジャイル開発の導入を進めています。 前回は、 デプロイ自動化の話 でしたが、今回はタスク管理についてです。 アジャイル開発ではストーリーカードやタスクボードなどを使用する事が多いですが、それらをWEB上で管理できるツールを導入しました。 Backlogsプラグイン アジャイル開発用のタスク管理ツールを探してみると、BacklogsというRedmineのプラグインが評判もよくシンプルで使いやすそうでした。 タスク管理にRedmineを使用していていた事もあり試してみた所、使い勝手が良かったので紹介します。 全体的な操作感としてはAjaxを多用していて直感的でサクサク動くのが気に入ってます。 プラグインを導入すると通常のプロジェクト画面にBacklogsとReleasesというタブがあらわれます。 バックログ画面 主に利用するのはバックログ画面とタスクボードで、Backlogsタブを選択するとバックログ画面に遷移します。 バックログ画面ではプロダクトバックログとスプリントバックログの管理ができます。 右側のプロダクトバックログにストーリーカードを書き出していき、上下にドラッグアンドドロップで移動させる事により優先順位の管理を行えます。 そして、スプリント計画時に左側のスプリントへドラッグアンドドロップで移動させ、スプリントの対象ストーリを決定します。 タスクボード スプリントの対象ストーリーが決まったら、タスクボード上でストーリーに対するタスクを管理していきます。 タスクカードの管理もAjaxを多用した作りになっていて、直感的にタスクの生成、割り当て、進捗の更新などができるようになっています。 その他にもバーンダウンチャートを表示したりと色々な機能があります。 まだ小さなプロジェクトで試験運用している段階ですが、また使用感など出てきましたらレポートしたいと思います。 インストール方法 使ってみたい！と思われた方のためにCentOSへのインストール手順を公開しておきます。 ストーリーカード、タスクボードの登録がうまくいかなくハマってしまうポイントがあるので是非参考にしていただければと思います。 Redmineのインストール Redmine.JPで1.2のわかりやすいインストール方法が公開されましたので、こちらを参照ください。 Redmine 1.2をCentOS5.6にインストールする手順 Redmine自体のインストールについては、Redmine.JPの 「Redmine 1.1をCentOS5.5にインストールする手順」 がとてもわかりやすいので、こちらを参照ください。 ただ最新バージョンが1.2.0に上がっているので、下記２点にご注意ください。 ・rackのバージョンが1.0.1から1.1.0に上がっている gem install rack -v=1.1.0 ・1.2.0のソース wget http://rubyforge.org/frs/download.php/74944/redmine-1.2.0.tar.gz Redmineの基本設定 Redmine上で基本的な設定を行います。 こちらもRedmin.JPの Redmineを使い始めるための初期設定 がわかりやすいので、こちらを参考に必要な設定を行ってください。 Backlogsプラグインインストール トラッカーの登録 管理者アカウントで、管理>トラッカー画面の「新しいトラッカーを作成」ボタンから、ストーリーとタスクというトラッカーを追加しておきます。 この時、「ワークフローをここからコピー」で既存にある「バグ」や「機能」を選択しておいてください。 トラッカーにワークフローが設定されていないと、ストーリーやタスクへの操作が何も許可されない状態になってしまいます。 この状態になるとストーリーカード、タスクボードの登録時にJavaScriptが正常に動かなくハマります。 必要パッケージのインストール gem install icalendar gem install prawn gem install holidays gem install open-uri-cached gem install ruby-units yum install -y libxml2 libxml2-devel libxslt libxslt-devel gem install nokogiri rmagickのインストール rmagickはちょっとややこしいですが、手順通りやっていけば大丈夫です。 ・ImageMagickのインストール yum install ImageMagick ImageMagick-devel -y ・TrueTypeFontのインストール wget http://www.mjmwired.net/resources/files/msttcorefonts-2.0-1.noarch.rpm rpm -ivh msttcorefonts-2.0-1.noarch.rpm /etc/init.d/xfs restart ln -s /usr/share/fonts/msttcorefonts /usr/share/fonts/default/TrueType ・rmagickのインストール # yumで入れられるImageMagickに対応しているバージョンまで下げる gem install rmagick -v 1.15.17 プラグインのインストール プラグインのインストールはGit経由で行います。(GitHubからDLする場合は こちらの手順 を参照してください) cd /var/lib/redmine/vendor/plugins/ git clone git://github.com/relaxdiego/redmine_backlogs.git cd redmine_backlogs git tag # バージョンのリストが表示される git checkout v0.5.2 # 最新バージョンを指定 RAILS_ENV =production export RAILS_ENV cd ../../../ rake generate_session_store rake config/initializers/session_store.rb rake db:migrate rake db:migrate:upgrade_plugin_migrations # Cannot find old migration table - assuming nothing needs to be done # と出るけど新規インストールなのでOK。 rake tmp:cache:clear rake tmp:sessions: clear rake redmine:backlogs:install # ストーリーとタスクをどのトラッカーにするか聞かれるので、先ほど作成したストーリーとタスクのトラッカーを指定します。 # ちゃんと設定されていないとストーリーカード、タスクボードの登録時にJavaScriptが正常に動かなくハマります。 チャート描画のための設定 rake redmine:backlogs:generate_chart_data /etc/init.d/httpd restart プロジェクトの作成 ここまでできれば準備完了です。 プロジェクトの設定で、モジュールのBacklogsのチェックボックスをチェックしましょう。 先ほどのようにBacklogsとReleasesというタブが表示されるはずです。 以上になります。 アジャイルさを大切にする環境で一緒に働きませんか？ 詳しくは こちら をご覧ください。 参考サイト Redmine Backlogs公式ページ Redmine 1.1をCentOS5.5にインストールする手順 / Redmine.JP Blog BacklogsプラグインをMac上のRedmineにインストール / RedmineのBacklogsプラグインを入れてみた / プログラマの思索

はじめまして。 最近結婚しましたVASILYのエンジニア庄司です。 VASILY では最近、アジャイル開発を取り入れ始めました。 アジャイル開発では開発工程の早い段階でのデプロイ自動化が推奨されています。 ・開発の終盤でデプロイスクリプトを書くより安全・安心 ・自動化されていることで細かく頻繁なアップデートが可能 そこで、Rails定番で利用実績の多いCapistranoを選択しました。 今回はRailsアプリケーションの自動デプロイツールCapistranoを紹介します。 Capistranoとは Railsアプリケーションに特化したデプロイ自動化ツールです。 以下のような特徴があります。 ・Rubyで書かれたRails定番のデプロイツール ・デプロイ/リストアがコマンド一発 ・デプロイのバージョン管理 ・複数サーバにインストール可能。 ・配信先サーバには何もインストールしない。 ・配信中コケてもデプロイ実行前の状態にロールバックしてくれる。 ・git,subversion,Mercurialなどのリポジトリのデータをデプロイできる。 ・Rails以外のデプロイなどにも利用可能 (その分設定は複雑になる) 今回テストした環境 ・CentOS release 5.5 (Final) ・ruby 1.9.2p180 ・Rails 3.0.5 ・git 1.7.4 インストール方法 Gemfileに以下を追記し、bundle install を実行 #development環境にのみインストール group :development do gem ' capistrano ' end Capistranoを採用の前提条件 ・git,subversion等のSCMでソースコード管理されていること ・デプロイ先サーバにsshでログインができること デプロイの流れ 以下の流れで、gitから最新のソースコードを取得し、Railsアプリケーションを起動します。 初回の準備 $ cd /home/vasily/test_app #Rails Application Root $ capify . #capistranoのconfigファイル作成 $ vim config/deploy.rb #下記参照 $ cap deploy:setup #デプロイ先サーバに必要なフォルダを作る(初回デプロイ時のみ) デプロイ $ cap deploy #gitから取得 + Railsアプリケーション再起動 $ cap deploy:migrate #DBスキーマに変更があった場合のみ、本番DBへのmigrationを実行 deploy.rb require " bundler/capistrano " #(1) set :application , " test_app " #(2) set :scm , :git #(3) set :repository , " ssh://... " #(4) set :scm_user , “vasily” #(5) set :deploy_to , " /home/vasily/test_app " #(6) set :deploy_via , :copy #(7) set :user , " vasily " #(8) set :use_sudo , true #(9) default_run_options[ :pty ] = true #(10) role :web , " www.exampl.com " #(11) role :app , " www.exampl.com " #(12) role :db , " www.exampl.com " , :primary => true #(13) namespace :deploy do #(14) task :start do ; end task :stop do ; end task :restart , :roles => :app , :except => { :no_release => true } do run "#{ try_sudo } touch #{ File .join(current_path, ' tmp ' , ' restart.txt ' ) }" end end (1) Rails3用の設定 デプロイ後、bundle installを実行してくれます。 (2) Railsアプリケーション名 (3) リポジトリ管理ツール VASILYではgitを使用しています。 (4) リポジトリのURI (5) リポジトリユーザ名 (6) デプロイ先ディレクトリ (7) プッシュ式デプロイ デフォルトでは、デプロイ先サーバでgit cloneを行いますが、VASILYのgitリポジトリは社内ネットワーク内のサーバにあるため、本番環境からgit pullすることができません。 set :deploy_via, :copy と設定することで、git cloneしたソースコードをtarで固めてscpで配布します。 また、プッシュ式デプロイにすることで、デプロイ先サーバにgitをインストールする必要がなくなります。 (8) デプロイ先サーバにsshするユーザ (9) sudoの使用を許可するか (10) pseudo-ttyを利用するかどうか デフォルトはfalse。 リモートでsudoコマンドを実行する際に、「sudo: no tty present and no askpass program specified」というエラーが出る場合、これを設定するといいです。 (11) webサーバ 複数指定する場合は、以下のように設定します。(11), (12)も同様です。 role :web, "web01.exampl.com", “web02.exampl.com”, ... (12) デプロイ先Railsアプリケーションサーバ ほとんどの場合webサーバと同じ (13) migrateを実行するサーバ DBサーバそのものではなく、rake db:migrate を実行するサーバ (14) Railsアプリケーション再起動の設定 デフォルトではコメントアウトされていますが、Passengerを使っている場合はこのコメントを外せばいいです。 その他のcapistranoタスク cap -T でタスクを確認できます。 以下に代表的なタスクをまとめます cap deploy :cold #ソースコード配布 + migration + Railsアプリケーション起動 cap deploy :start #Railsアプリケーション起動 cap deploy :stop #Railsアプリケーション停止 cap deploy :restart #Railsアプリケーション再起動 cap deploy :rollaback #前回のdeploy前の状態にロールバック + Railsアプリケーション再起動 cap deploy :cleanup #デプロイ先の古いソースコードを最新版から5世代分(デフォルト)残して削除 デプロイ先のディレクトリ Capistranoでデプロイした先のサーバでは、バージョン管理の都合上、通常のRailsアプリケーションのディレクトリ構成とは違います。 ・releases バージョンごとのRailsアプリケーションのコードです。 ・current releases以下のいずれかのディレクトリのシンボリックリンク。通常は最新版を指します。 ・shared Railsアプリケーション内の一部のうち、ログファイルやbundlerで管理するgemパッケージなどデプロイの度に更新してほしくないファイルが置かれます。 実際のディレクトリ構成 /home/vasily/test_app/ |-- current -> /home/vasily/test_app/releases/20110603132533 |-- releases | |-- 20110530110205 .... | |-- 20110530121423 .... | |-- 20110530122100 | | |-- app | | |-- config | | |-- db | | |-- doc | | |-- lib | | |-- log -> /home/vasily/test_app/shared/log | | |-- public | | | --- system -> /home/vasily/test_app/shared/system | | |-- script | | |-- spec | | |-- tmp | | | --- pids -> /home/vasily/test_app/shared/pids | | --- vendor | --- 20110603132533 | |-- app | |-- config | |-- db | |-- doc | |-- lib | |-- log -> /home/vasily/test_app/shared/log | |-- public | | --- system -> /home/vasily/test_app/shared/system | |-- script | |-- spec | |-- tmp | | --- pids -> /home/vasily/test_app/shared/pids | --- vendor --- shared |-- bundle | --- ruby |-- log |-- pids --- system その他の機能 ・メンテナンスページへの切り替え ・独自タスクの設定 ・Railsアプリケーション以外での利用 など、便利な機能がありますが、これらはまた今後のエントリーで。 それでは！

  はじめまして、 iQON を運営しているVASILYのCTOの今村と申します。 この度サイトのリニューアルにあたり、心機一転、個性豊かなVASILYのエンジニア達による 技術ブログをはじめたいと思います。 一発目の記事ということなので簡単に弊社の環境紹介を。 弊社ではエンジニアをはじめとする全社員がMacを使っています。 Windows環境はVmwareFusion内にしかありません。 エンジニアには全員27インチのiMacが支給され、それを用いて開発を行っています。 また、自分が使いたいマウスやキーボードなども支給されます。 ちなみにVASILYのエンジニアのキーボードはRealForce派:HHKB派が4:1となっています。 僕は静音タイプのRealForceを使っています、一度慣れるともう戻れませんね。 マウスは全員トラックボールを使っています。 これも慣れるまでは大変ですが 慣れると普通のマウスにはもどれないぐらい快適です。 Realforce   トラックボールマウス     BOSEのノイズキャンセリングヘッドフォンのQC3       この3つを合わせて社内では エンジニア三種の神器 と呼んでいたりします。 労働環境については、設立当初からこだわりをもっているところですので 今後ともよりよい労働環境の追求をしていきたいと思っています。 さて、そんなVASILYでは、只今僕達と一緒に働ける仲間を募集しています。 詳しくは こちら 僕達と一緒にインターネットを使ってファッションの未来を変えていきませんか？