システムはできて終わりではなく，そこから始まる
前回は，安心のためのSAF機能とテストサポートをみてきました。SAFによりat-least-onceという実行時の堅牢さが保証され，メッセージが消失しない安心を得ることができました。また，非同期まで含めたテストの仕組みにより，TDD/BDDと同じように開発ができ，リリースに対する安心感も得られました。
前回までで，アプリケーションは一応の完成をみています。しかし，システムは作って終わりというわけにはいきません。利用状況の変化に合わせて円滑に処理が進むよう調整しなければなりませんし，また障害発生時にもすみやかに復旧する必要があります。
最終回となる今回は，負荷分散のための設定と，SAF Forwardエラーのリカバリ，および業務処理がエラーとなったメッセージのリカバリを説明します。
負荷分散のための設定
AP4Rにおける負荷分散はいくつかのポイントがあります。
- 非同期処理を複数プロセスへ分散
- ウェブサーバのプロキシ機能を使う
- AP4RのURL変換フィルタを使う
- AP4R プロセス自体の多重化
- メッセージ送信を分散する
- AP4R プロセス間でメッセージを転送する
既に説明した内容もありますが，負荷分散という観点でまとめて見ていきましょう。
ウェブサーバのプロキシ機能にて，非同期処理を複数プロセスへ分散
非同期の処理を複数プロセスで分散させることを考えた場合，通常のHTTPリクエストをリバースプロキシで分散させるのと同様に，ウェブサーバの機能を利用する方法があります。
最も簡単な構成は，同期処理と同じウェブサーバを利用して，処理を担当するRailsプロセス群も同期，非同期の区別無く動かすことです。この場合，Railsがリバースプロキシの後ろで動くようになっていれば，追加の設定は必要ありません。Railsアプリケーションを動かすときのよくある構成と同じです。
図1 リバースプロキシで複数プロセスに分散させる
では，非同期処理を担当するRailsプロセス群を，同期のプロセス群から分離する場合はどうなるでしょうか。リバースプロキシまで含めて分離する場合は，AP4RのURL変換フィルタにて対応することが出来ます。前回までの例では，ポート番号を変更していましたが，ホストの部分を変更すればOKです。
modify_rules:
url: proc {|url| url.host = "your.async.host"}
図2 リバースプロキシごと非同期処理を分離する
リバースプロキシを同期処理と共用にする場合は，AP4Rでの設定は不要です。プロキシの設定で非同期と同期を分離することになります。プロキシの設定を簡略化するためには，非同期に流したいURLやHTTPヘッダなどに，接頭辞やキーワードなど共通の構造を持たせる必要があるかもしれません。
図3 リバースプロキシにより，同期と非同期の処理を分離させる
