会社概要名称 : 株式会社日本総研ソリューションズ JRI Solutions, Limited. 設立 : 2006 年 7 月資本金 : 50 億円従業員 : 1,300 名株主 : 株式会社日本総合研究所代表者 : 代表取締役社長兼最高執行役員小名木正也所在地 : 東京本社東京都

Size: px

Start display at page:

Download "会社概要名称 : 株式会社日本総研ソリューションズ JRI Solutions, Limited. 設立 : 2006 年 7 月資本金 : 50 億円従業員 : 1,300 名株主 : 株式会社日本総合研究所代表者 : 代表取締役社長兼最高執行役員小名木正也所在地 : 東京本社東京都"

みいかおおかわち
5 years ago
Views:

1 HITACHI Open Middleware World 2007 Autumn 開発の現場から学ぶ高信頼な Web システム基盤構築のポイント日本総研ソリューションズ技術本部インフラ技術部飯田博記

2 会社概要名称 : 株式会社日本総研ソリューションズ JRI Solutions, Limited. 設立 : 2006 年 7 月資本金 : 50 億円従業員 : 1,300 名株主 : 株式会社日本総合研究所代表者 : 代表取締役社長兼最高執行役員小名木正也所在地 : 東京本社東京都中央区晴海晴海センタービル大阪本社大阪市西区新町支社名古屋 U R L : 主要事業所システム開発東京 : 晴海大阪 : 四ツ橋心斎橋土佐堀データセンター東京大阪にそれぞれ設置 1

3 当社の強みお客様の本質的な問題解決と未来の価値創造を私たちは信頼されるプロフェッショナル集団です複雑化するお客様のニーズに応え IT 投資の効果を最大化する為社員一人ひとりが IT コンサルティングからシステム構築運用アウトソーシングまで各分野の高度な技術を背景に問題点を本質的に捉えスピーディに解決していく課題解決から価値創出へ繋ぐ架け橋としていつの時代も信頼されるプロフェッショナル集団である最適な IT 戦略を武器にお客様に信頼される長期の IT パートナーへお客様の CIO やそのスタッフの方々と IT 戦略の策定やシステム化計画立案プロジェクト品質の向上をご支援します Consulting コンサルティング経営資源の最適化を実現する高品質な IT リソースをご提供いたします高度のノウハウを持つエキスパートが価値ある新規事業を創出 Technology テクノロジー Outsourcing アウトソーシングシステム管理全般からサービスレベル管理特定機能の ASP 型利用等様々な外部委託のご要望にお応えします技術テーマ別にエキスパート集団を組成し先進的かつ効率的なシステム構築を実現できる体制を整えています 2

4 0. 高信頼な Web システム基盤構築のポイントセミナーのポイント信頼性の高いWebシステム基盤基盤を構築するには信頼性とは定められた期間中にシステムが期待通りに動作することすなわち要件に定められた機能サービスを提供すること信頼性の高い Web システムとはピーク時にも安定して稼動できる障害が発生したときも影響を少なくできるビジネス規模の拡大に対応できる障害時に迅速に状況を把握できる 3

5 アジェンダ 1. システム基盤のアーキテクチャを選定する 2. ピーク時にも安定して稼動する 3. 障害が発生したときも影響を少なくできる可用性 4. ビジネス規模の拡大に対応できる拡張性 5. 障害を予防し障害時も迅速に対応できる運用性 4

6 アジェンダ 1. システム基盤のアーキテクチャを選定する 2. ピーク時にも安定して稼動する 3. 障害が発生したときも影響を少なくできる可用性 4. ビジネス規模の拡大に対応できる拡張性 5. 障害を予防し障害時も迅速に対応できる運用性 5

7 システム基盤アーキテクチャの選定 Webシステムの目的ごとにアーキテクチャが異なる 1 情報発信型不特定多数のユーザー Web サーバーコンテンツ : 静的セキュリティ : ほぼなしレスポンス要件 : 低い DB 連携 : ほぼなしトランザクション要件 : 低い 2 対話型 Web サーバー AP サーバー DB サーバー特定のユーザーコンテンツ : 動的セキュリティ : 暗号化 / 認証 DB 連携 : 必須トランザクション要件 : 中程度レスポンス要件 : 中程度 DBMS 3 ミッションクリティカル型特定のユーザー Web サーバー AP サーバー OLTP サーバー DB サーバーコンテンツ : 動的セキュリティ : 暗号化 / 認証 DB 連携 : 必須トランザクション要件 : 高いレスポンス要件 : 高い DBMS 本セミナーでは J2EE の AP サーバーを対象にシステム基盤構築のポイントを紹介する 6

8 アジェンダ 1. システム基盤のアーキテクチャを選定する 2. ピーク時にも安定して稼動する (1) 十分な能力を持ったハードウエアを選定する (2) ガーベージコレクションを制御する (3) リクエストの流量を制御しスループットを確保する 3. 障害が発生したときも影響を少なくできる可用性 4. ビジネス規模の拡大に対応できる拡張性 5. 障害を予防し障害時も迅速に対応できる運用性 7

9 2-1. ハードウエア選定 (1) 十分な能力を持ったハードウエアを選定する Webシステム基盤に期待される性能要件レスポンス時間ピーク時のリクエスト量性能要件を満たすよう CPU 性能個数をサイジングする十分でなければレスポンス時間の要件を満たすことができない CPU サイジング手順 1リクエストを処理するのにかかるCPU 資源はいくらかピーク時のリクエスト量を処理するのにかかるCPU 資源の総量は必要となるCPUの性能個数はいくらか 8

10 2-1. ハードウエア選定 1リクエストを処理するのにかかるCPU 資源はいくらかレスポンス時間の内訳を確認しておくネットワーク伝送時間リソース待ち時間は状況により変化する 1 リクエストの処理に必要となる CPU 資源の量はサーバー状態に因らず一定クライアント AP サーバー 1 リクエストにかかる時間レスポンス時間レスポンス時間の内訳ネットワーク伝送時間内部保留時間内部保留時間の内訳ネットワーク帯域が太く遅延時間が短ければゼロに近づくリソース待ち時間サーバー状態により増減する CPU 資源サーバー状態に因らず一定 CPU 資源の量は CPU 性能 ( モデルクロック ) とアプリケーションアーキテクチャ (EJB 利用有無など ) により決まる 9

11 2-1. ハードウエア選定ピーク時のリクエスト量を処理するのにかかるCPU 資源の総量はピーク時のリクエスト量を 1 秒あたり (TPS) で捉えるピーク時のTPSは性能要件で定められる TPS:1 秒あたりのリクエスト量クライアント AP サーバーリクエスト CPU 資源 CPU 資源 CPU 資源ピーク時の TPS CPU 資源ピーク時に必要な CPU 資源 AP サーバーで必要となる CPU 資源の総量はピーク時の TPS 1 リクエストあたりの CPU 資源 10

12 2-1. ハードウエア選定必要となる CPU の性能個数はいくらか必要となる CPU 資源の総量に CPU 使用率を考慮して CPU 性能と個数を求める算出した CPU 個数にもとづいてサーバー構成を決定するサイジングの結果必要 CPU 数が 4 個場合の構成例 CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU 4CPU 構成 x 1 サーバー 2CPU 構成 x 2 サーバー 1CPU 構成 x 4 サーバー低低負荷分散冗長性運用管理コスト高高 11

13 ガーベージコレクション制御 (2) ガーベージコレクションを制御する Java の自動メモリー管理メモリー確保解放のプログラム不要使用済みメモリーの解放と未使用領域の確保はGCが行う JavaVM ヒープメモリ使用中のインスタンス使用済みのインスタンス GC には検討しておくべき課題がある GC 中に一時的に処理が停止する GC が頻発する 12

14 ガーベージコレクション制御ガーベージコレクション (GC) の課題 GC 中は一時的に処理が停止する GC を実行してもメモリーが解放されない場合頻繁に GC が発生し性能が劣化する使用中のインスタンスは GC を実行してもメモリーが解放されない長期間使用されるインスタンスが多いと問題になるメモリー量 GC 頻発割当メモリー使用メモリー時間 13

15 ガーベージコレクション制御 GC の処理速度を改善する - 世代別 GC Java のインスタンスの多くは一時的なものが占める例割合生存期間 GC 短命インスタンスリクエストーレスポンス間の処理に使用されるもの多い短い数秒程度 Copy GC ( 高速 ) 長命インスタンスセッション情報に保存されるものユーザー ID 権限情報など少ない長い数分程度 Full GC ( 全領域 ) 世代別 GCではインスタンスを生存期間で分け短命インスタンスを対象として高速なGC(Copy GC) を行う Full GC の発生頻度を制御することが重要 14

16 ガーベージコレクション制御 Full GC の発生頻度を制御する JavaVM のヒープ領域を Young 領域と Old 領域に分ける Young 領域 Eden 領域 Survivor 領域 #1 Survivor 領域 #2 Old 領域インスタンスは Young 領域に生成される Copy GC を繰り返した結果長命インスタンスが Old 領域に配置される Full GC は Old 領域が一杯になったときに行われる発生頻度は長命インスタンス = セッション情報が生成されるスピードによって決まるこれは 1 秒あたりの想定ログイン数セッション情報サイズから求まるログイン数が多い場合セッション情報サイズが大きい場合は Old 領域が一杯になるスピードが速い Full GC の発生頻度が多くなるセッションタイムアウトが長い場合はセッション情報が解放されない Full GC 多発の原因となる 15

17 2-3. リクエストの流量を制御する (3) リクエストの流量を制御しスループットを確保する同時実行数はレスポンス時間スループットと関係がある同時実行数が少なすぎればスループットが低くなる多すぎればレスポンス時間が悪化しスループットも低下するスループットが高くなるようにリクエストの流量 = 同時実行数を設定するスループットレスポンス時間要件レスポンス時間同時実行数 16

18 2-3. リクエストの流量を制御する流量制御の設定ポイント Web サーバー AP サーバー DB サーバー同時実行数 Web 実行待ちリクエスト数同時実行スレッド数 Web AP DB 接続プール DB 同時実行スレッド数 DB 接続プール実行待ちリクエスト数同時実行数 Web AP サーバーの同時実行数少ないとスループットが低くなる多いとレスポンス時間悪化スループット低下 DB 高速化のため接続をプールしておく同時実行スレッド数より大きく設定する少ないと DB 接続プール待ちが発生する AP サーバーの実行キュー少ないとキューあふれエラーの発生頻度が高くなる多いとレスポンス時間が長くなった場合にもエラーとできない Web サーバーの同時実行数同時実行スレッド数 + 実行待ちリクエスト数より多くする 17

19 2-3. リクエストの流量を制御するアプリケーション特性にあわせた流量制御 Webコンテナに複数のWebアプリを配置して運用する場合一方のWebアプリにリクエストが集中すると他方に影響がある Webアプリケーションごとに流量制御を行う処理時間の長いプログラムが含まれる場合特定のプログラムが実行スレッドを占有してしまうプログラムごと (URLごと) に流量制御を行う WebAP ごとの流量制御 AP サーバー URL ごとの流量制御 AP サーバー Web AP Web AP Web AP 実行待ちリクエスト数同時実行スレッド数 DB 接続プール実行待ちリクエスト数同時実行スレッド数 DB 接続プール 18

20 アジェンダ 1. システム基盤のアーキテクチャを選定する 2. ピーク時にも安定して稼動する 3. 障害が発生したときも影響を少なくできる可用性 4. ビジネス規模の拡大に対応できる拡張性 (1) 機器を多重化し冗長化構成とする (2) グローバルトランザクション方式の考慮点 5. 障害を予防し障害時も迅速に対応できる運用性 19

21 3-1. 機器を多重化し冗長化構成とする可用性拡張性 (1) 機器を多重化し冗長化構成とする負荷分散装置を利用した水平負荷分散サーバークライアント負荷分散装置サーバーサーバーサーバーサーバー障害サーバー追加平常時は複数のサーバーで分散して処理サーバー障害時は稼動サーバーで処理継続サーバーを追加できスケーラビリティを確保 20

22 3-1. 機器を多重化し冗長化構成とする可用性拡張性負荷分散装置を用いた水平負荷分散の考慮点サーバーへの振り分け方法サーバーごとの処理量を平準化する方式を選択するラウンドロビン最小接続数最小応答時間 IP アドレスセッションを維持する方法既存のセッションは同じサーバーに振り分ける Cookie URL リライト IP アドレスサーバーの死活監視確実性と負荷運用性とのバランス Ping HTTP アプリケーション 21

23 3-2. グローバルトランザクション方式の考慮点可用性 (2) グローバルトランザクション方式の考慮点ローカルトランザクショントランザクションはDBサーバー管理 APサーバー障害時はDBサーバーがリカバリーグローバルトランザクショントランザクションはAPサーバー管理 APサーバー障害時はトランザクションが未解決となるローカルトランザクショングローバルトランザクション DB サーバー AP サーバー DB サーバー AP サーバー DBMS 業務 AP トランザクション DBMS 業務 AP トランザクション障害時未解決 DBMS 22

24 3-2. グローバルトランザクション方式の考慮点可用性 APサーバー障害時にリカバリーするにはクラスタ構成ディスクを共有し稼動系障害時は待機系がリカバリー稼動サーバーごとに待機リカバリー用のサーバーが必要となりリソースの無駄が多いクラスタ構成 AP サーバー DB サーバー業務 AP トランザクション DBMS AP サーバー待機系業務 AP トランザクションリカバリー可能 DBMS ミドルウエアによっては一台で複数のサーバーのリカバリーが可能な専用サーバが利用できる (N+1 クラスタ ) 23

25 アジェンダ 1. システム基盤のアーキテクチャを選定する 2. ピーク時にも安定して稼動する 3. 障害が発生したときも影響を少なくできる可用性 4. ビジネス規模の拡大に対応できる拡張性 5. 障害を予防し障害時も迅速に対応できる運用性 (1) ログトレースの収集 (2) ログトレースの解析 24

26 4. 運用性確保のポイント運用性運用性確保のポイントとは平常時の運用システムの起動計画停止稼動状況の監視稼動統計の確認モジュール入替パッチ適用定義変更障害時の運用情報取得ログトレース収集ログトレース解析フェールオーバーフェールバック 25

27 4-1. ログトレースの収集運用性 (1) ログトレースの収集タイムリーに必要なログを収集する出力場所は多岐に渡る迅速に収集しなければ情報が失われる 1. 顧客からの問い合わせまたは障害検知 6. 業務復旧 ( システム暫定復旧 ) 2. 現象確認 ( 再現性 ) 7. ベンダーへの問い合わせ ( 指示待ち ) 3. エラーログメッセージの確認 8. 調査用の各種ログの送付 4. サーバーの稼動状況の確認 (CPU メモリ ) 9. 対策 ( 業務アプリ修正製品パッチなど ) 5. 問題点の一次切り分け ( サーバー業務アプリ ) 10. 障害対応完了必要なログを一括で効率よく収集できるよう工夫するミドルウエアの機能を利用する ( ) 26

28 4-2. ログトレースの解析運用性 (2) ログトレースの解析状況を確認するにはログトレースからリクエストの処理シーケンスを解析する複数のログにまたがるため解析が困難ミドルウエアの機能を利用する (PRF トレース ) WEB サーバリクエスト毎にユニークな ID を付与 Web コンテナ J2EE サーバ EJB コンテナ DB サーバ JSP/ サーブレット EJB DB ボトルネックの特定が容易にボトルネック 27

29 まとめ高信頼なシステム基盤を構築するには性能確保 CPU サイジングガーベージコレクションの制御流量制御可用性拡張性冗長化構成水平負荷分散クラスタ構成 N+1 クラスタ運用性ログ収集トレース解析 28

30 終わりに本日のご説明内容他の詳細については日経 BP 社 : システム基盤の統合ノウハウもご参照ください (2008 年 1 月刊行予定 ) 本文中に記載されている会社名商標名は各社の商標または登録商標です 29

F5-NECセミナ資料(可用性向上)

F5-NECセミナ資料(可用性向上) NEC と F5 が実現するアプリケーションの可用性を高める方法 ~ WebOTX と BIG-IP Local Traffic Manager で実現する自律型負荷分散制御 ~ 2008 年 1 月 23 日日本電気株式会社アジェンダ WebOTXのご紹介 WebOTXの可用性への取り組み BIG-IP LTMとWebOTXの連携について制御の概要まとめ 2 WebOTX とは 1999