第4回 システムは稼働してからがはじまり | gihyo.jp
システムはできて終わりではなく、そこから始まる 前回は、安心のためのSAF機能とテストサポートをみてきました。SAFによりat-least-onceという実行時の堅牢さが保証され、メッセージが消失しない安心を得ることができました。また、非同期まで含めたテストの仕組みにより、TDD/BDDと同じように開発ができ、リリースに対する安心感も得られました。 前回までで、アプリケーションは一応の完成をみています。しかし、システムは作って終わりというわけにはいきません。利用状況の変化に合わせて円滑に処理が進むよう調整しなければなりませんし、また障害発生時にもすみやかに復旧する必要があります。 最終回となる今回は、負荷分散のための設定と、SAF Forwardエラーのリカバリ、および業務処理がエラーとなったメッセージのリカバリを説明します。 負荷分散のための設定 AP4Rにおける負荷分散はいくつかのポイ
第3回 SAF機能とテストサポートによる安心非同期 | gihyo.jp
前回のおさらい 前回は、ウェブ上のお店のアプリケーションを作成しました。店を訪れたお客さんはウェブブラウザから品物の名前を入力して、注文を行います。その後、サーバ側では注文情報の保存と決済の2つの処理を順次行います。処理が完了すると、ブラウザに注文完了の情報が表示されます。この同期アプリケーションをAP4Rを利用して非同期拡張しました。 すなわち async_to メソッドを使って「重い」決済処理を注文処理から分離し、ユーザーの待ち時間を解消しました。リバースプロキシを利用した、バックエンドに複数の Railsプロセスが存在する構成では、「重い」非同期処理とユーザーにすぐ応答したい処理をうまく両立させながら実行できます。記事のサンプルではリバースプロキシ構成にはせず、URL変換フィルタの機能を利用して、非同期メッセージ処理のリクエスト先を別のRailsプロセスに変える例をご紹介しました。
第1回 軽量さと堅牢さを兼ね備えたメッセージング | gihyo.jp
はじめに みなさん、はじめまして。 今回からRubyによるオープンソースのメッセージングライブラリ、AP4Rの連載をさせていただくことになった加藤です。一緒にAP4Rの開発を進めている篠原とともに 4回にわたってご紹介させていただきます。 筆者らはフューチャーアーキテクト株式会社にて、自社製のJavaによるメッセージングミドルウェアの開発、メンテナンスを行なってきました。大小さまざまなプロジェクトで稼動してきたものであり、数十台規模での導入実績もあります。そこで培った実装や経験をもとにRubyで書きあげたものが、AP4Rです。Ruby 会議 2007でも取りあげてもらえたので、名前くらいは聞いたことあるよ、という方もいるかもしれません。以下、RubyForgeのプロジェクトサイトと日本語ホームページのURLです。 AP4R のホームページへようこそ! RubyForge: AP4R: Pr
第2回 AP4RとRailsでつくる非同期アプリケーション | gihyo.jp
ちょっとしたニュース 今年11月にアメリカ東海岸のシャーロットで開催されるRubyConf 2007の発表枠応募にAP4Rが通りました！ いい機会をもらえたので、がんばって発表してきます。 Agenda for RubyConf 2007 : Introduction to AP4R, Asynchronous Processing for Ruby 手を動かしてみましょう 第1回では、AP4Rの開発に至った背景、システムの構成例、信頼性を保証するSAF機能について見てきました。 そして、非同期処理を利用する場合の一般的な利点と注意点に触れた後、AP4Rの「堅牢」かつ「軽量」という特徴について解説しました。 今回は、Ruby on Railsで作られたウェブアプリケーションをAP4Rと連携させて、非同期処理を実装してみましょう。作成するアプリケーションの機能と、非同期化する箇所を選び出した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
