Clusterはちょっと試してみる分には問題はありませんが、実際にシステムを運用するうえでは、「ログが各Tomcatインスタンス上に分散される」「セッション情報が利用できない」などの問題があります。Clusterをさらに使いこなす3つのテクニックを紹介します。Syslogによるログの集約プロキシサーバの設定のカスタマイズTomcatのJDBCStoreによるフェイルオーバ【1】Syslogによるログの集約Tomcatクラスタ上で動作するWebアプリケーションのログは、ファイルに書き出すと各インスタンス上に保存され、Webアプリケーションのログ解析をする際に各インスタンスのログを確認する必要があります。haproxyのデフォルトの設定ではstickyセッションが無効のため、リクエストごとに別のインスタンスにログが書き出される可能性があり、解析が大変です。ここで、Syslogとlog4jのSyslogAppenderを利用すると、ログサーバにログを集約できデバッグが楽になります(図10)。syslogによるログの集約ここで、ロードバランサをログサーバとして設定して、ログを集約する例を紹介します。EC2のロードバランサでは、「rsyslog」があらかじめインストールされているので、ここではrsyslogを利用した設定例を紹介します。syslogやSyslogAppenderの詳細については、下記のサイトをご覧ください。連載「新世代syslogデーモン徹底活用」SyslogAppender(Log4jのAPIドキュメント)最初に、アプリケーションのログを出力するファシリティ(ログの種別)を定義します。ここでは、ファシリティ「local0」にアプリケーションのログを出力するように設定します。設定するには、「/etc/rsyslog.conf」に下記の1行を追加します。「/etc/rsyslog.conf」への追加log4jでは、デフォルトでUDPのsyslogへのログ出力をサポートしているため、UDPによるログの受付を有効にします。rsyslogでUDPのログの受付を有効にするには、「/etc/sysconfig/rsyslog」ファイルの「SYSLOGD_OPTIONS」に「-r514」(514番のUDPポートでログの受付を許可する設定)を追加します。設定した後、下記のコマンドによりrsyslogdを再起動すると、ログの受付の準備は完了です。restartWebアプリケーション側では、log4jの設定でSyslogAppenderを利用する設定を行います。SyslogAppenderを利用したログ出力の設定例をリスト3に示します。log4jによるSyslogAppenderの設定例これで、すべてのWebアプリケーションで出力したログがログサーバ上の「/var/log/application.log」に集約されます。【2】プロキシサーバの設定のカスタマイズデフォルトでは、haproxyの設定は8080番ポートとなっており、同一のWebブラウザからアクセスするアプリケーションサーバを固定するstickyセッションもサポートされません。ロードバランサのインスタンスのhaproxyの設定を変更することにより、HTTPのポートを一般的な80番に変更したり、stickyセッションを有効にすることによりアプリケーション内でセッションを利用できるようになります。haproxyの設定を変更するには、ロードバランサのインスタンスにログインして、「/etc/haproxy.cfg」を下記のように書き換えます。「/etc/haproxy.cfg」ファイル(変更後)haproxy.cfgの値を書き換えたら、起動しているhaproxyを停止し、下記の要領でhaproxyを再起動します。-sfhaproxyの詳細は、haproxyの公式サイトを参照してください。【3】TomcatのJDBCStoreによるフェイルオーバstickyセッションを有効にしても、アプリケーションサーバが何らかの障害によりダウンすると、セッションの内容はクリアされてしまいます。Tomcatの「JDBCStore」機能を利用すると、セッションの内容をデータベースで永続化でき、障害によりアプリケーションサーバがダウンしたときでも、ほかのサーバで処理を引き継げるようになります。JDBCStoreを利用して、信頼性を向上しましょう。JDBCStoreは、Tomcatのセッション情報をデータベースを利用して共有します。そのため、データベースが利用できるインスタンスを起動しておき、セッション情報を格納するテーブルを作成する必要があります。PostgreSQLを利用した場合は、次のようなSQLを実行して「TOMCAT$SESSIONS」テーブルを作成します。Cluster-config/context.xml」に、データベースを利用してセッションを管理するJDBCStoreの設定を、下記のように追加します。JDBCドライバやconnectionURLは、実際のデータベースの設定に応じて変更してください。Clusterを起動後、Tomcatが起動している各インスタンスのTomcatの「lib」ディレクトリ(/env/tomcat/lib)にJDBCドライバをインストールしTomcatを再起動すれば、データベースによるセッションの共有が有効になります。Reference(JDBCStore)」を参照してください。Tomcatのセッションの同期を取る方法として「SimpleTcpCluster」を利用する方法がありますが、EC2では、SimpleTcpClusterを利用するために必要なマルチキャストを利用できないため、SimpleTcpClusterは利用できません。Toolkitを利用すると、EC2のサーバの起動・停止ができるだけでなく、WTPを利用した通常のアプリケーションサーバ上でのWebアプリケーションの実行・デプロイと同じようにTomcatクラスタ上でWebアプリケーションをデプロイできます。Toolkitを利用することにより、PaaSレイヤでのアプリケーション開発ができるようになります。Engineに匹敵するほど簡単にアプリケーションを起動できます。Engineに比べると、手間が掛かります。Engineのようにファイルアクセスやネットワークアクセスに制限はないので、自由度の高いアプリケーション開発が可能であり、いままでのノウハウを生かしたクラウドアプリケーションを開発できます。Toolkitの利用を検討してみる価値はあると思います。Beanstalk」とはAnt使いでもMavenのライブラリ管理ができるIvyとは「Hudson」改め「Jenkins」で始めるCI(継続的インテグレーション)入門Bazaarでござ〜る。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。