はじめに

現在のWebシステム開発・運用では、特に大規模化するシステムの安定稼働、パフォーマンスの向上、システムのスケールアップやスケールアウトの実現が求められます。また開発フェーズではこれまで以上の効率化に加えて、新しい技術的な取り組みを踏まえたシステム開発も必要となります。

本連載では、これらシステム開発者を取り巻く要求事項をどのように解決していけばよいのか、解決のためのソリューションとしてはどのようなものがあるのかについて、日立のAP（アプリケーション）サーバであるCosminexusを題材として取り上げながら解説していきます。連載第1回の今回は、多重度・流量制御を中心に、DB（データベース、I/O）のチューニング（最適化）などにも触れて解説します。

チューニングとは

システム構築においては、CPUやメモリ容量など限りあるリソースを最大限に有効活用するとともに、機能要件を満たすレスポンスやスループットを得られるようにアプリケーションの構造や設定を調整する必要があります。そのために不可欠な作業が性能チューニングです。

性能チューニングでは性能測定とボトルネック要因の分析および対処を繰り返し実施し、個々のボトルネック要因を排除していきます。性能向上を突き詰めていくと際限なくチューニングを繰り返すことになりかねませんので、目的の性能を得られた時点でチューニングを終了することも重要です。

Webシステムの性能および安定性を確保するためには、①Webサーバの最大同時接続数、②Java EEサーバ接続用コネクションキャッシュサイズ、③実行待ちキューサイズ、④Java EE（Java Platform, EnterpriseEdition）サーバの同時実行スレッド数、⑤SessionBeanインスタンスプールサイズ、⑥DB（データベース）サーバ接続用コネクションプールサイズなどのパラメータを適切に設定していきます。そして、システムの要件を満たすための適切なパラメータを設定するためには、長年の経験によるノウハウやテスト環境での検証を通じて探っていくことになります（図1⁠）⁠。

Cosminexusでは、これまでのシステム構築を通じて蓄積してきた知見を体系化したドキュメントノウハウを「uCosminexus SI Navigation System」というツールにシステム化しました。このツールでは、条件に応じた適切な流量制御およびDB（I/O）周りを中心とした各種のパラメータ設定が可能です。なお、「⁠uCosminexus SI Navigation System」については本連載の次回以降で詳解します。

安定性確保のための流量制御

要件どおりのリクエストを処理できるようシステムを設計したとしても、リクエストがシステムの処理能力を超えてしまうと安定したサービスの動作が困難になります。実際の運用時には想定外のリクエストが発生する場合が多々あり、システムの安定性を確保するために運用時の負荷状態を考慮する必要があります。

こういった場合に備えて、流量制御で負荷を軽減する必要があります。流量制御とは、システムで受け付けるリクエスト数の上限を区切ることに加えて、重い処理と軽い処理がある場合にバランスよくキューを配分し、重い処理と軽い処理を並行して実行できるようにするものです。このためには、重い処理に割り当てられるスレッド数を固定するとよいでしょう。通常のシステムでは処理の軽重による流量制御はサーバを分けて対応するために、サーバを複数台導入するようなケースが多く見られますが、Cosminexusの場合は、メインフレームなどによる基幹情報システムの開発経験で培ってきた安定稼働のノウハウを活かし、業務ロジックレベル（URLグループ単位）でキューを分けて流量制御するため、APサーバを分ける必要がありません。

これによってシステム全体の安定稼働が可能になり、運用面でも煩雑さがなくなるというメリットがあります。

システムの安定性を確保するためには、リクエスト処理の負荷をうまく分散する流量制御が欠かせないものです。それでは次に、Webアプリケーション、EJB（Enterprise JavaBeans）アプリケーションの安定性能確保について見ていくことにします。

Webアプリケーションの安定性確保

たとえば朝の始業時のように、処理に時間を要するログイン処理が集中するケースを想定してみましょう。

重い処理と軽い処理でキューを共有し流量制御をしない場合、リクエストは先着順に実行されます。重いログイン処理中はすべてのスレッドで実行するので、ほかの軽い業務へのリクエストは実行待ちになります。このため、クライアント多重度が一定の値を超えると全体的なスループットは低下してしまいます。

Cosminexusでは、重い処理と軽い処理とでキューを分けて流量制御する場合は、前述のように重い処理と軽い処理をバランスよく扱うため、並行して効率よく実行できます。異なる業務をバランスよく実行できるため、クライアント多重度が上昇しても全体的なスループットの低下は抑制できます（図2⁠）⁠。

EJBアプリケーションの安定性確保

EJBアプリケーションを安定稼働させつつシステムリソースを有効活用するには、流量制御に加えて、リクエスト単位での優先制御やEJB単位のサービス閉塞、動的な負荷分散が求められます。Cosminexusではこれらを標準で装備するとともに、さまざまな運用オプションに対応しています。

動的負荷分散では、負荷状況に応じたスケジューラ間のリクエスト転送ができます。流量制御では前述のURLによるキューの適切な割り当てに加え、業務の最大同時実行数の制限やキューの滞留監視、同時実行数の動的変更を備えています。これはリクエストキューの滞留状態を監視し、スローダウンが閾値（いきち）を超えると系を閉塞するとともに、スローダウンが解消された場合は自律的に回復動作を実行します。すなわち、自律的かつ動的な処理により、EJBアプリケーションの安定性を確保しシステムリソースの有効活用を実現しているのです（図3⁠）⁠。

安定性確保のためのDB（I/O）最適化

DB（I/O）アクセスはソフトウェアリソースにおいてボトルネックとなりやすいポイントであり、安定性を確保するためには最適化が不可欠です。その主なチューニング手法には、APサーバがDBとのコネクションを作成してメモリにプールし、DBへのリクエスト時に再利用する「DBコネクションプーリング」と、DBへのアクセス時に作成するステートメントの一部をプールし再利用する「ステートメントプーリング」の2種類があります。

Cosminexusでは前述のuCosminexus SI Navigation Systemに含まれるドキュメントに最適化の指針が載っていますので、これに基づいてDBの最適化を効率よく実現できます。

実効的なチューニングとテスト

要件を満たすシステム性能を確保するためには、性能向上させるためのチューニングとその実証を行うテストが必要となります。システムの実効的なチューニングやテストを実施するには、適切なポイントの把握と設定、作業の工数削減、システムやアプリケーションの修正・再構築時における負荷軽減、実稼働環境でテストする場合は影響の抑制などが重要です。チューニングやテストにおいて適切なポイントを把握していないと、システムの性能や信頼性を十分に確保できなかったり無駄な工数が生じたりといった事態を招いてしまいます。さらに、テスト環境でチューニングした結果を実稼働環境へスムーズに移行できれば、効率的なシステム構築が可能になります。

性能要件の検証

性能要件の検証には、単一のリクエストを要件どおり処理できるかを検証する「単体性能の検証」と、複数のリクエストを処理できるかの「多重性能の検証」があります（図4、図5⁠）⁠。これらの検証作業の負荷を軽減しつつ適切な検証を行えることが、効率的なシステム開発に直結します。

さらに実稼働環境では、設計段階や検証段階では予想しきれなかったさまざまなトラブルが発生することがままあります。その原因がクライアント／APサーバ（Webサーバ、Java EEサーバ⁠）⁠／DBサーバ／ネットワークなどシステムのどこにあるのかを速やかに把握し適切に対処することが、効果的なチューニングとシステムの安定稼働には不可欠なのです。

すなわち、設計・開発・検証・運用を効率的に実施できる環境が、理想的な環境と言えます。

アプリケーション修正時の負荷軽減

システム不良の修正やチューニングのためにアプリケーションを修正する場合、たとえクラスファイルを1つ更新しただけであってもWAR（WebArchive Format）やEJB-JAR（Java ARchiver⁠）⁠、EAR（Enterprise ARchive）を再アーカイブしなければならず、アプリケーションの入れ替え手順が煩雑になってしまいます。

Cosminexusは任意のディレクトリに置かれたファイルからデプロイする方式のサポートにより、アプリケーション入れ替え作業をシンプル化し効率を大きく向上しました。アプリケーションの修正時に再アーカイブが不要であり、クラスを更新すると自動的またはコマンドでリロード可能なのです。

また、通常の環境ではアプリケーションの入れ替え時にはインポート後にアプリケーション属性を毎回設定しなければならず、作業の負荷が増大するという問題がありました。Cosminexusでは環境定義ファイル「cosminexus.xml」のサポートにより、インポート後の作業を大きく軽減できます。これは独自設定をあらかじめEARに含めることで実現しており、インポート後すぐにアプリケーションを開始できます。従来のAP

テスト環境と実稼働環境での検証

アプリケーションの修正も完了し、テスト環境でチューニングとテストを終えて実稼働環境に移行するには、実稼働環境でもテスト環境と同じ手順で環境を構築しなければならないのが通例です。また、実稼働環境でテストする際、通常はシステム全体を停止しなければならないため、オンライン業務が稼働していない時間帯に実施するか、テストの実施中は業務を停止せざるをえません。

Cosminexusでは各種パラメータを「環境定義ファイル」としてエクスポート／インポート可能であり、テスト環境からエクスポートした定義ファイルを用いて実運用環境にインポートして構築できます。環境定義ファイルを用いた環境の構築はコマンド1つで実施できるため、手作業での再構築とは異なり、確実かつスムーズな移行が少ない工数で済みます。

さらに、業務の稼働中でもテストが可能な「テストモード」という機能を備えており、実稼働環境でのテストを通じてアプリケーション入れ替え時のトラブルリスクを低減できます。APサーバのテストモードでデプロイすると自動的にオンラインアプリケーションとは別名で登録するため、実稼働環境に影響を及ぼすことなくテストできるのです。

また、アプリケーションの入れ替え作業は動的に可能でシステムを停止する必要がないため、実稼働環境の稼働中でも実施できます。

障害原因の特定における負荷の軽減

設計・開発・検証・運用の、どこの段階においてもシステムで障害が生じた場合、その原因を特定して適切に対処することが肝要です。ごく当たり前のこととは言え、現実的にはさまざまな困難がつきまといます。原因特定や対策の検証にはテストが欠かせませんが、その作業は大きな負担になりがちです。しかし、障害原因を特定するための再現テストが不要なら、負担をかなり軽減できます。

Cosminexusの場合は「PRFトレース」というログによって状況を把握し原因を特定できるため、再現テストは不要です。このトレースログではセッションごとにユニークなIDを付加しており、これを追うことでトラブルの原因がAPサーバなのかDBサーバなのか、あるいはクライアント－サーバ間の通信網にあるのかを容易に特定できます。PRFトレースログの出力、およびユニークID付加はデフォルトで備えている機能であり、システムに対するオーバヘッドは極小です（図7⁠）⁠。

また、Cosminexusは性能に影響をほとんど与えずに詳細な各種稼動情報ログを出力できるのが特長です。そのため、他のAPサーバからCosminexusに乗り換えたユーザは、そのログの量に驚くことが多いようです。しかしこれは、ミッションクリティカルなメインフレームのシステムで培ってきたノウハウをCosminexusに継承しているためで、これらログによって再現テストを行うことなく障害原因の特定が可能となり、システムの高い信頼性と可用性の実現につながっています。

次回予告

本連載の次回では、Java VM（Virtual Machine）のメモリ管理機能であるガベージコレクション（GC⁠）⁠、日本語処理における課題を中心に、JavaVMにおけるメモリ管理技術について解説します。