大規模化・安定稼働・開発効率化…Webシステム開発・運用を乗り切るテクニック

第1回 チューニング① 多重度・流量制御の最適化

この記事を読むのに必要な時間:およそ 3.5 分

安定性確保のためのDB(I/O)最適化

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

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

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

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

性能要件の検証

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

図4 単体性能の検証フローチャート

図4 単体性能の検証フローチャート

図5 多重性能の検証フローチャート

図5 多重性能の検証フローチャート

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

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

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

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

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

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

統合属性も引き続きサポートしていますので,何らかの事情で従来の手法を用いたいケースでも問題ありません(図6)。

図6 業務を動かしたまま本番環境でテストが可能

図6 業務を動かしたまま本番環境でテストが可能

※:入替え時にはアプリケーションの一旦停止が必要です。テストモード利用時にはテスト用のクライアントやデータが必要です。