HITACHI Open Middleware World 2007 Autumn −開発の現場から学ぶ− −開発の現場から学ぶ−
高信頼な
高信頼な
Web
Web
システム基盤構築のポイント
システム基盤構築のポイント
㈱日本総研ソリューションズ ㈱日本総研ソリューションズ 技術本部 技術本部 インフラ技術部インフラ技術部 飯田 飯田 博記博記■名 称 ： 株式会社日本総研ソリューションズ JRI Solutions , Limited.
■設 立 ： 2006年7月 ■資 本 金 ： 50億円 ■従 業 員 ： 1,300名 ■株 主 ： 株式会社日本総合研究所 ■代 表 者 ： 代表取締役社長兼最高執行役員 小名木 正也 ■所 在 地 ： 【東京本社】 東京都中央区晴海2-5-24 晴海センタービル 【大阪本社】 大阪市西区新町1-6-3 【支 社】 名古屋 ■Ｕ Ｒ Ｌ ： http://www.jri-sol.co.jp/ ■主要事業所 ○システム開発 東京：晴海 大阪：四ツ橋、心斎橋、土佐堀 ○データセンター 東京、大阪にそれぞれ設置
会社概要
会社概要
お客様の本質的な問題解決と未来の価値創造を。 お客様の本質的な問題解決と未来の価値創造を。 私たちは信頼されるプロフェッショナル集団です。 私たちは信頼されるプロフェッショナル集団です。 Consulting コンサルティング Outsourcing アウトソーシング Technology テクノロジー 最適なIT戦略を武器に、 お客様に信頼される長期のITパートナーへ。 高度のノウハウを持つ エキスパートが、 価値ある新規事業を創出。 経営資源の最適化を実現する、 高品質なITリソースをご提供いたします。 複雑化するお客様のニーズに応えIT投資の効果を最大化する為、社員一人ひとりが、ITコンサルティングから システム構築・運用アウトソーシングまで、各分野の高度な技術を背景に問題点を本質的に捉えスピーディに 解決していく。 課題解決から価値創出へ繋ぐ架け橋として、いつの時代も信頼されるプロフェッショナル集団である。 お客様のCIOやそのスタッフの方々と、IT戦略の策定や システム化計画立案、プロジェクト品質の向上をご支援 します。 技術テーマ別にエキスパート集団を組成し、 先進的かつ効率的なシステム構築を実現 できる体制を整えています。 システム管理全般から、サービスレベル管理、 特定機能のASP型利用等、様々な外部委託 のご要望にお応えします。
当社の強み
当社の強み
•
信頼性とは
• 定められた期間中に、システムが期待通りに動作 すること。すなわち、要件に定められた機能、サー ビスを提供すること。•
信頼性の高いWebシステムとは、
• ピーク時にも安定して稼動できる • 障害が発生したときも影響を少なくできる • ビジネス規模の拡大に対応できる • 障害時に迅速に状況を把握できる セミナーのポイント信頼性の高いWebシステム
基盤を構築するには
基盤
0.
0.
高信頼な
高信頼な
Web
Web
システム基盤構築のポイント
システム基盤構築のポイント
アジェンダ
アジェンダ
２．ピーク時にも安定して稼動する。 ３．障害が発生したときも影響を少なくできる。 ４．ビジネス規模の拡大に対応できる。 ５．障害を予防し障害時も迅速に対応できる。 高性能 可用性 拡張性 運用性 １．システム基盤のアーキテクチャを選定する。２．ピーク時にも安定して稼動する。 ３．障害が発生したときも影響を少なくできる。 ４．ビジネス規模の拡大に対応できる。 ５．障害を予防し障害時も迅速に対応できる。 高性能 可用性 拡張性 運用性 １．システム基盤のアーキテクチャを選定する。
アジェンダ
アジェンダ
1
1
-
-
1.
1.
システム
システム
基盤アーキテクチャの選定
基盤アーキテクチャの選定
①情報発信型 ②対話型 ③ミッション クリティカル型 DBMS 不特定多数の ユーザー 特定のユーザーWebサーバー APサーバー OLTPサーバー DBサーバー DBMS Webサーバー APサーバー DBサーバー Webサーバー 特定のユーザー コンテンツ：静的 セキュリティ：ほぼなし レスポンス要件：低い DB連携：ほぼなし トランザクション要件：低い コンテンツ：動的 セキュリティ：暗号化/認証 DB連携：必須 トランザクション要件：中程度 レスポンス要件：中程度 コンテンツ：動的 セキュリティ：暗号化/認証 DB連携：必須 トランザクション要件：高い レスポンス要件：高い
•
Webシステムの目的ごとにアーキテクチャが異なる。
• 本セミナーでは、J2EEのAPサーバーを対象に、システム基盤構 築のポイントを紹介する１．システム基盤のアーキテクチャを選定する。 ４．ビジネス規模の拡大に対応できる。
アジェンダ
アジェンダ
２．ピーク時にも安定して稼動する。 ３．障害が発生したときも影響を少なくできる。 ５．障害を予防し障害時も迅速に対応できる。 高性能 可用性 拡張性 運用性 （１）十分な能力を持ったハードウエアを選定する （２）ガーベージコレクションを制御する （３）リクエストの流量を制御し、スループットを確保する2
2
-
-
1.
1.
ハードウエア選定
ハードウエア選定
高性能（１）十分な能力を持ったハードウエアを選定する
• Webシステム基盤に期待される性能要件 • レスポンス時間 • ピーク時のリクエスト量 • 性能要件を満たすよう CPU性能・個数をサイジング する • 十分でなければ、レスポンス時間の要件を満たすことができない • CPUサイジング手順 • １リクエストを処理するのにかかるCPU資源はいくらか • ピーク時のリクエスト量を処理するのにかかるCPU資源の総量は • 必要となるCPUの性能・個数はいくらか高性能 １リクエストを処理するのにかかるCPU資源はいくらか
2
2
-
-
1.
1.
ハードウエア選定
ハードウエア選定
• レスポンス時間の内訳を確認しておく • ネットワーク伝送時間、リソース待ち時間は状況により変化する。 • １リクエストの処理に必要となるCPU資源の量は、 サーバー状態に因らず一定 レスポンス時間 ネットワーク 伝送時間 内部保留時間 CPU資源 リソース待ち時間 APサーバー クライアント ネットワーク帯域が太く、 遅延時間が短ければ ゼロに近づく ネットワーク帯域が太く、 遅延時間が短ければ ゼロに近づく １リクエストに かかる時間 レスポンス時間 の内訳 内部保留時間 の内訳 サーバー状態により 増減する サーバー状態により 増減する サーバー状態に因らず一定 サーバー状態に 因らず一定 • CPU資源の量はCPU性能（モデル・クロック）とアプリケーショ ンアーキテクチャ（EJB利用有無など）により決まる。高性能
2
2
-
-
1.
1.
ハードウエア選定
ハードウエア選定
ピーク時のリクエスト量を処理するのにかかるCPU資源の総量は • ピーク時のリクエスト量を、１秒あたり（TPS）で捉える • ピーク時のTPSは性能要件で定められる • TPS：１秒あたりのリクエスト量 APサーバー ピーク時の ＴＰＳ ピーク時に必要なCPU資源 CPU資源 CPU資源 CPU資源 CPU資源 クライアント リクエスト • APサーバーで必要となるCPU資源の総量は ピーク時のTPS×１リクエストあたりのCPU資源CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU
4CPU 構成x 1サーバー 2CPU構成 x 2サーバー 1CPU構成 x 4サーバー サイジングの結果、必要CPU数が4個場合の構成例 運用管理コスト 負荷分散・冗長性 低 高 高 低 高性能 • 必要となるCPU資源の総量に、CPU使用率を考慮して CPU性能と個数を求める • 算出したCPU個数にもとづいて、サーバー構成を決定する 必要となるCPUの性能・個数はいくらか
2
2
-
-
1.
1.
ハードウエア選定
ハードウエア選定
高性能
（２）ガーベージコレクションを制御する
• Javaの自動メモリー管理 • メモリー確保・解放のプログラム不要 • 使用済みメモリーの解放と未使用領域の確保はGCが行う2
2
-
-
2.
2.
ガーベージコレクション制御
ガーベージコレクション制御
JavaVM ヒープメモリ 使用済みの インスタンス 使用中の インスタンス • GCには、検討しておくべき課題がある。 • GC中に一時的に処理が停止する、GCが頻発する、高性能
2
2
-
-
2.
2.
ガーベージコレクション制御
ガーベージコレクション制御
• GC中は 一時的に処理が停止する • GCを実行してもメモリーが解放されない場合、 頻繁にGCが発生 し、性能が劣化する • 使用中のインスタンスは、GCを実行してもメモリーが解放されない。 長期間使用されるインスタンスが多いと問題になる。 ガーベージコレクション（GC）の課題割当メモリー
使用メモリー
時間
メモリー量
GC頻発高性能 GCの処理速度を改善する－世代別GC • Javaのインスタンスの多くは一時的なものが占める
2
2
-
-
2.
2.
ガーベージコレクション制御
ガーベージコレクション制御
例 割合 生存期間 GC 短命 インスタンス リクエストーレスポンス間の 処理に使用されるもの 多い 短い。 数秒程度 Copy GC （高速） 長命 インスタンス セッション情報に保存され るもの。ユーザーID、権限 情報など 少ない 長い。 数分程度 Full GC （全領域） • 世代別GCでは、インスタンスを生存期間で分け、短命インス タンスを対象として高速なGC（Copy GC）を行う • Full GC の発生頻度を制御する ことが重要高性能
Young領域
Eden領域 Survivor領域#1 Survivor領域#2 Old領域
2
2
-
-
2.
2.
ガーベージコレクション制御
ガーベージコレクション制御
Full GCの発生頻度を制御する • JavaVMのヒープ領域をYoung領域とOld領域に分ける • インスタンスは、Young領域に生成される。Copy GCを繰り返した結 果、長命インスタンスがOld領域に配置される。 • Full GCは、Old領域が一杯になったときに行われる。発生頻度は、長 命インスタンス＝セッション情報が生成されるスピードによって決まる。 • これは１秒あたりの想定ログイン数、セッション情報サイズから求まる。 • ログイン数が多い 場合、セッション情報サイズが大きい 場合は、Old領域 が一杯になるスピードが速い。Full GCの発生頻度が多くなる • セッションタイムアウトが長い 場合は、セッション情報が解放されない。 Full GC多発の原因となる2
2
-
-
3.
3.
リクエストの流量を制御する
リクエストの流量を制御する
高性能（３）リクエストの流量を制御し、スループットを確保する
• 同時実行数は、レスポンス時間、スループットと関係がある • 同時実行数が少なすぎれば、スループットが低くなる • 多すぎれば、レスポンス時間が悪化し、スループットも低下する • スループットが高くなるように、リクエストの流量＝同時実行 数を設定する 同時実行数 スループット レスポンス時間 レスポンス 時間要件APサーバー 同時実行 スレッド数 DB接続 プール 実行待ち リクエスト数 同時実行数 Web Webサーバー 高性能 Web AP
2
2
-
-
3.
3.
リクエストの流量を制御する
リクエストの流量を制御する
流量制御の設定ポイント DB DBサーバー 同時実行スレッド数 APサーバーの同時実行数。少ないとスループットが低くなる。多いと レスポンス時間悪化、スループット低下。 DB接続プール DB高速化のため、接続をプールしておく。同時実行スレッド数より大 きく設定する。少ないとDB接続プール待ちが発生する 実行待ちリクエスト数 APサーバーの実行キュー。少ないとキューあふれエラーの発生頻 度が高くなる。多いとレスポンス時間が長くなった場合にもエラーと できない 同時実行数Web Webサーバーの同時実行数。同時実行スレッド数＋実行待ちリクエ スト数より多くする高性能
2
2
-
-
3.
3.
リクエストの流量を制御する
リクエストの流量を制御する
アプリケーション特性にあわせた流量制御 • Webコンテナに複数のWebアプリを配置して運用する場合 • 一方のWebアプリにリクエストが集中すると、他方に影響がある • Webアプリケーションごとに流量制御を行う • 処理時間の長いプログラムが含まれる場合 • 特定のプログラムが実行スレッドを占有してしまう • プログラムごと（URLごと）に流量制御を行う APサーバー 同時実行 スレッド数 DB接続 プール Web AP Web AP 実行待ち リクエスト数 APサーバー 同時実行 スレッド数 DB接続 プール Web AP 実行待ち リクエスト数 http://XServlet/ http://YServlet/ http://XServlet/login http://XServlet/action WebAPごとの流量制御アジェンダ
アジェンダ
２．ピーク時にも安定して稼動する。 ３．障害が発生したときも影響を少なくできる。 ４．ビジネス規模の拡大に対応できる。 ５．障害を予防し障害時も迅速に対応できる。 高性能 可用性 拡張性 運用性 １．システム基盤のアーキテクチャを選定する （１）機器を多重化し、冗長化構成とする （２）グローバルトランザクション方式の考慮点3
3
-
-
1.
1.
機器を多重化し、冗長化構成とする
機器を多重化し、冗長化構成とする
可用性 拡張性（１）機器を多重化し、冗長化構成とする
負荷分散装置 クライアント サーバー サーバー 負荷分散装置を利用した水平負荷分散 サーバー サーバー 障害 サーバー 障害 • 平常時は複数のサーバーで分散して処理 • サーバー障害時は稼動サーバーで処理継続 • サーバーを追加でき、スケーラビリティを確保 サーバー サーバー 追加 サーバー 追加ラウンドロビン
ラウンドロビン 最小接続数最小接続数 最小応答時間最小応答時間 IPアドレスIPアドレス
Cookie
Cookie URLリライトURLリライト IPアドレスIPアドレス
Ping Ping HTTPHTTP アプリケーションアプリケーション 可用性 拡張性
3
3
-
-
1.
1.
機器を多重化し、冗長化構成とする
機器を多重化し、冗長化構成とする
負荷分散装置を用いた水平負荷分散の考慮点 • サーバーへの振り分け方法 • サーバーごとの処理量を平準化する方式を選択する • セッションを維持する方法 • 既存のセッションは同じサーバーに振り分ける • サーバーの死活監視 • 確実性と負荷、運用性とのバランス可用性
（２）グローバルトランザクション方式の考慮点
APサーバー DBサーバー 業務AP トランザクション DBMS3
3
-
-
2.
2.
グローバルトランザクション方式の考慮点
グローバルトランザクション方式の考慮点
• ローカルトランザクション • トランザクションはDBサーバー管理 • APサーバー障害時はDBサーバーがリカバリー • グローバルトランザクション • トランザクションはAPサーバー管理 • APサーバー障害時はトランザクションが未解決となる APサーバー DBサーバー DBMS DBMS トランザ クション 業務AP グローバルトランザクション グローバルトランザクション ローカルトランザクション ローカルトランザクション 障害時 未解決 障害時 未解決可用性
3
3
-
-
2.
2.
グローバルトランザクション方式の考慮点
グローバルトランザクション方式の考慮点
APサーバー障害時にリカバリーするには APサーバー DBサーバー DBMS DBMS トランザ クション 業務AP クラスタ構成 クラスタ構成 • クラスタ構成 • ディスクを共有し、稼動系障害時は待機系がリカバリー • 稼動サーバーごとに待機・リカバリー用のサーバーが必要となり、リ ソースの無駄が多い • ミドルウエアによっては、一台で複数のサーバーのリカバリーが可能 な専用サーバが利用できる（N+1クラスタ、 ） 業務AP APサーバー待機系 リカバリー 可能 リカバリー 可能 トランザ クションアジェンダ
アジェンダ
２．ピーク時にも安定して稼動する。 ３．障害が発生したときも影響を少なくできる。 ４．ビジネス規模の拡大に対応できる。 ５．障害を予防し障害時も迅速に対応できる。 高性能 可用性 拡張性 運用性 １．システム基盤のアーキテクチャを選定する （１）ログ・トレースの収集 （２）ログ・トレースの解析4.
4.
運用性確保のポイント
運用性確保のポイント
運用性運用性確保のポイントとは
• 平常時の運用
• システムの起動、計画停止 • 稼動状況の監視、稼動統計の確認 • モジュール入替、パッチ適用、定義変更• 障害時の運用
• 情報取得、ログ・トレース収集 • ログ・トレース解析 • フェールオーバー、フェールバック4
4
-
-
1.
1.
ログ・トレースの収集
ログ・トレースの収集
運用性（１）ログ・トレースの収集
• タイムリーに、必要なログを収集する • 出力場所は多岐に渡る • 迅速に収集しなければ情報が失われる １．顧客からの問い合わせ、または障害検知 ２．現象確認（再現性） ３．エラーログ、メッセージの確認 ４．サーバーの稼動状況の確認（CPU、メモリ） ５．問題点の一次切り分け（サーバー、業務アプリ） ７．ベンダーへの問い合わせ（指示待ち） ８．調査用の各種ログの送付 ６．業務復旧（システム暫定復旧） ９．対策（業務アプリ修正、製品パッチなど） １０．障害対応完了 • 必要なログを 一括で効率よく収集 できるよう工夫する • ミドルウエアの機能を利用する（ ）運用性
