Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

これで失敗しない ASTERIA WARPサイジングのポイント

1,513 views

Published on

2016年12月20日AUG忘年会、2017年3月9日AUG関西支部第3回WGの際にASTERIAユーザー様向けに実施されたセミナーのプレゼンテーション資料

Published in: Software
  • Be the first to comment

  • Be the first to like this

これで失敗しない ASTERIA WARPサイジングのポイント

  1. 1. これで失敗しない! ASTERIA WARP サイジングのポイント インフォテリア株式会社 東京R&Dセンター 田村健
  2. 2. 2 ©1998-2017 Infoteria Corporation
  3. 3. サーバーサイジングとは サーバサイジングとは、システムやサー ビスを提供する際に、想定されるシステ ムの負荷を見積もり、それを処理するの に十分な性能・台数のサーバを用意する こと。システムの運用を開始した後に、 負荷の増大に応じてサーバ性能を増強す ることも含まれる。 IT用語辞典「サーバーサイジング」 http://e-words.jp/w/%E3%82%B5%E3%83%BC%E3%83%90%E3%82%B5%E3%82%A4%E3%82%B8%E3%83%B3%E3%82%B0.html ©1998-2017 Infoteria Corporation 3
  4. 4. 4 運用に適した構成を見積もる ©1998-2017 Infoteria Corporation
  5. 5. 5 本日はASTERIA WARPを 利用したデータ連携システ ムを前提とした話をします ©1998-2017 Infoteria Corporation
  6. 6. サーバーサイジングの手順 6 構成の決定 最終的なシステム構成を決定 ボトルネックの調査 ボトルネックとなる部分の調査 ベンチマーキング 運用負荷を想定した処理をプロトタイプし測定 前提条件の設定 運用するシステムの負荷を見積もる ©1998-2017 Infoteria Corporation
  7. 7. 7 構成の決定 最終的なシステム構成を決定 ボトルネックの調査 ボトルネックとなる部分の調査 ベンチマーキング 運用負荷を想定した処理をプロトタイプし測定 前提条件の設定 運用するシステムの負荷を見積もる ©1998-2017 Infoteria Corporation
  8. 8. 前提条件となるもの • システム要件 • 利用する技術 • ソフトウェア • クラウド or オンプレミス • 運用負荷 • 変動要因 • データ量 • 同時アクセス数 • バッチなのかオンライン処理なのか • 性能要件 • 現実的な数値 • コスト • サイジングの結果として、これらの前提を変更する可能性も出て くることもある、つまり、パラメータになる可能性もある ©1998-2017 Infoteria Corporation 8
  9. 9. 運用負荷を考えるときに考慮すべきポイント • 安定状態とピーク状態 • 定期的な変動要因 • 季節、曜日、時間帯、月末月初 • キャンペーンなど突発的な変動要因 • システムのタイプ • バッチ処理:一度に大きな処理 • APIサーバー:細かい • データ • 均一なのか?変動が大きいのか? • データ量 • 1レコードのサイズ • レコード数 • 並列度 9 ©1998-2017 Infoteria Corporation
  10. 10. 10 構成の決定 最終的なシステム構成を決定 ボトルネックの調査 ボトルネックとなる部分の調査 ベンチマーキング 運用負荷を想定した処理をプロトタイプし測定 前提条件の設定 運用するシステムの負荷を見積もる ©1998-2017 Infoteria Corporation
  11. 11. ベンチマーキングとは • 実際にプロトタイプを作成して、運用に可能な限り近 い状態で性能を測定する ©1998-2017 Infoteria Corporation 11
  12. 12. ベンチマーキングのポイント • 想定した運用条件に可能な限り近づける • 処理内容 • データの量と質 • 実行形態 • アウトプットとなるシステム構成をイメージし、シン プルな構成から始める • 処理内容の特性を理解する 12 ©1998-2017 Infoteria Corporation
  13. 13. ベンチマーキングの指標 • 単一リクエストのレスポンスタイム • 処理を開始してから処理が終了するまでの時間 • 処理速度を上げれば速くなる • 並列度を上げても変わらない • 多重リクエストのレスポンスタイム • 処理投入開始からすべての処理が終了するまでの時間 • 処理速度を上げれば速くなる • 多重度<並列度であれば、多重度を上げると速くなる • 多重度>並列度であれば、多重度を上げると遅くなる • 各リクエストのレスポンスタイムは同じであるとは限らない • 単一リクエスト時のレスポンスタイム×リクエスト数 ≠ 多重リクエスト時の各レスポンスタイムの合計 13 ©1998-2017 Infoteria Corporation
  14. 14. ベンチマーキングの指標 • スループット • 単位時間内に処理できる実行数やデータ量 • 処理速度を上げれば高くなる • 並列度を上げれば高くなる 14 ©1998-2017 Infoteria Corporation
  15. 15. ベンチマーキングの指標 • プロセスのメモリ使用量 • プロセスが確保する最大のメモリ量 • 一度にメモリ中に展開されるデータ量に依存する • 多重度が上がればメモリは多く使われる • システムのメモリ使用量 • プロセスが確保する以外にOSが使用するメモリも考慮が必要 • ファイルキャッシュ、システムスワップはレスポンスタイム やスループットにも影響する 15 ©1998-2017 Infoteria Corporation
  16. 16. パラメータとなるリソース 16 ©1998-2017 Infoteria Corporation
  17. 17. CPU • 速度 • クロック数 • ECU (AWS) • 仮想コア数×仮想コアあたりの Unit数(処理スピード) • 並列度 • 物理CPU数 • コア数 • 物理コア • 論理コア(ハイパースレッディン グ) 17 ©1998-2017 Infoteria Corporation
  18. 18. メモリ • OS搭載メモリ • プロセス割り当てメモリ(Java) • 初期ヒープサイズ • 最大ヒープサイズ • その他各種メモリパラメータ • スワップ領域 18 ©1998-2017 Infoteria Corporation
  19. 19. ストレージ • 物理タイプ • HDD • SSD • RAID • 0/1/5/6/0+1 • 接続 • USB • Ethernet • iSCSI • FC • ネットワークプロトコル • NFS • iSCSI • SMB(Windows共有ファイル) 19 ©1998-2017 Infoteria Corporation
  20. 20. ネットワーク • RTT(ラウンドタイムトリップ) • ネットワーク往復の応答時間 • レイテンシとも • 物理的配置 • AWSやAzureのリージョン • スイッチングハブなどの機器による影響 • ファイアウォールなどの機器・設定による影響 • Web APIなど、ネットワーク呼び出しの大きいシステ ムへの影響大 • データベース・アクセスにも影響 20 ©1998-2017 Infoteria Corporation
  21. 21. ベンチマーキングのコツ • 基本パターンで小さく始める • いきなりピーク時の負荷をかけた場合、結果が出るまでに時間がかかる • 小さなデータ、少ない多重度から徐々に運用パターンに近づける • 可変パラメータは一つに、その他のパラメータは固定 • CPU速度だけを変更して測定 • 多重度だけを変更して測定 • ネットワークだけを変更して測定 • 当たりをつける • すべての可変パラメータについてベンチマーキングを行うのは効率が悪い • 論理的にどこがボトルネックになるのかを考えながらパラメータを変えてい く • 他の要因を極力排除 • セキュリティソフトのディスクI/OやCPUに与える影響 21 ©1998-2017 Infoteria Corporation
  22. 22. 22 構成の決定 最終的なシステム構成を決定 ボトルネックの調査 ボトルネックとなる部分の調査 ベンチマーキング 運用負荷を想定した処理をプロトタイプし測定 前提条件の設定 運用するシステムの負荷を見積もる ©1998-2017 Infoteria Corporation
  23. 23. • 多重度や速度がリソースの追加に伴って比例して向上 することが望ましい • 性能要件に満たない場合はボトルネックを調査する 23ベンチマークの結果を精査 ©1998-2017 Infoteria Corporation
  24. 24. ボトルネックとは? • 処理速度を阻害する最も大きな要因 • ボトルネックを検出するためのベンチマーキング • ボトルネックは、解消すれば新たなボトルネックが発 生する 24 ©1998-2017 Infoteria Corporation
  25. 25. ボトルネックを全て解消する必要はない • 運用に耐えられれば良い • 運用開始後に対策が立てられるように原因を探ってお くことが大切 • 簡単に解消できるボトルネックは解消する 25 ©1998-2017 Infoteria Corporation
  26. 26. よくあるボトルネック
  27. 27. 多重度を上げた場合にレスポンスタイムが遅くなる • 並列度が足りてない • CPU数、コア数、スレッド数 • 処理の何処かで待ちが入っている • 排他制御 • IOブロック 27 ©1998-2017 Infoteria Corporation
  28. 28. マルチスレッドは万能か? • 単独で10秒の処理を8コアのサーバーで同時に8個 の処理を実行開始した場合、すべての処理が終わるま でにかかる時間は? • >10秒 • 完全に並列になることはない • OSレベル、物理レベルでのさまざまなコスト • プロセススイッチ • ストレージアクセス • ネットワークアクセス • 多くのコアの1サーバーより1コアの複数サーバーの 方が効率良いこともある 28 ©1998-2017 Infoteria Corporation
  29. 29. Web APIの呼び出し • ネットワークが絡むと小さな要因が増幅されることが多い • 例えばWeb APIで1000件のデータを取得する場合 • ローカルでテストしていたときは2秒しかかからなかった • リモートからテストすると11秒かかってしまう • 実は1000件のデータを1000回APIを呼んで取得していた • 通信コストがローカルでは1ms、リモートでは10ms。データ取得のコ ストはどちらも1ms • API呼び出しでの通信コストが10倍になったので、全体も約10倍になる • どちらも1回の呼び出しでは10ms以下なので単体テストでは気づきにく い • 同様のケース • 毎回ログイン • ネットワーク経由でのDBアクセス 29 ©1998-2017 Infoteria Corporation
  30. 30. 30 構成の決定 最終的なシステム構成を決定 ボトルネックの調査 ボトルネックとなる部分の調査 ベンチマーキング 運用負荷を想定した処理をプロトタイプし測定 前提条件の設定 運用するシステムの負荷を見積もる ©1998-2017 Infoteria Corporation
  31. 31. システムの構成を考える • ベンチマークの結果からシステムをどのような構成に すべきかを考える • ポイント • キャパシティ設計 • オーバーフロー時の対策 ©1998-2017 Infoteria Corporation 31
  32. 32. キャパシティ設計 • 安定運用にはリソースに余裕をもたせることが重要 • 決定要因 • システムの重要度 • キャパシティを超えた場合の深刻度 • コスト 32 ©1998-2017 Infoteria Corporation
  33. 33. オーバーフロー対策 • オーバーフローは起こるものという前提で考える • そのときに慌てないようにシステムに柔軟性を持たせ ておくことが大切 • クラウドの活用 • スケールアップとスケールアウト 33 スケールアップ スケールアウト ©1998-2017 Infoteria Corporation
  34. 34. 例1) 月次バッチのシステムの場合 • システム特性 • メモリが足りなければ増設しか解消方法がない • 処理時間が想定時間内に終わらなくても、最悪待っていれば 少しの遅延で済む • 構成案 • メモリは想定最大データよりもより多くのデータを処理でき るだけを確保しておく • CPU速度はコスト見合いで 34 ©1998-2017 Infoteria Corporation
  35. 35. 例2) ECサイト • システム特性 • 処理時間がユーザーエクスペリエンスに直結する • 1度の処理に使うメモリは少ない • 多重度のブレが大きい • 構成案 • CPUはできるだけ速いものを選択し、コア数も確保する • メモリはそこそこ。ただし、多重度に耐えうる構成 • キャンペーンなど、多重度の上がるケースに備えて、スケー ルアウトできる構成 35 ©1998-2017 Infoteria Corporation
  36. 36. ASTERIA WARPのサイジングTips
  37. 37. デザイナーで実行して処理時間を見る • デザイナーから見た実行時間なのでサーバーとの間の 通信コストなども含まれる • 時間がかかる場合、フローのタイムアウトにも気をつ けなければならない 37 ©1998-2017 Infoteria Corporation
  38. 38. ログファイルから実行時間を読む • ログファイルにはフローの実行時間が出力されている • FlowService.log • アプリケーションログ • フローに純粋にかかった時間 • 開始時刻と終了時刻から計算しなくてOK .... フローの実行を開始します: /user.Project1.Flow1 .... フローの実行が終了しました: /user.Project1.Flow1 [1345ms] ©1998-2017 Infoteria Corporation 38
  39. 39. プロファイルモード 39 ©1998-2017 Infoteria Corporation
  40. 40. プロファイルモード 40 ©1998-2017 Infoteria Corporation
  41. 41. プロファイルモード 41 • FlowProfile.logにCSV形式で出力 • CSV形式のデータ • 詳細は「フローデザイナー操作ガイド」>「フローの 実行」>「直接起動」>「プロファイルを参照する」 https://asteria.jp/documentation/warp/1610/flow/designer/index_guide.html#exe c_direct_profile.html ©1998-2017 Infoteria Corporation
  42. 42. 多重度性能を測定する • Timerコンポーネントを利用する • Loop->Timerで複数のリクエストを実行 する • Timerコンポーネントの「実行する時間」 を「0」にすることで呼び出しコストを最 小化 (0以上だとスケジューラが使用される) • 「実行モード」を指定できるのでプロ ファルが取得できる 42 ©1998-2017 Infoteria Corporation
  43. 43. プロセス状況を調べる 43 • FSMCでスナップショットを見る。ツール>サービス ©1998-2017 Infoteria Corporation
  44. 44. fsmon.exe • フローの各プロセスの状況を見るためのコマンド • 1610: <INSTALL_DIR>/server/bin/fsmon.exe • 4.x: <INSTALL_DIR>/flow/bin/fsmon.exe • ダブルクリックするとGUI版が開く • -consoleをつけてコマンドを実行するとコンソール モードで実行される 44 ©1998-2017 Infoteria Corporation
  45. 45. デモ 45
  46. 46. OutOfMemory? • 不要なストリームを使っていないか確認しましょう • サブフローでストリームを返さないのにEndResponseに なっていないか? • パラレルで大きなストリームを処理していないか? • CSVやXMLはメモリをたくさん使います • 場合によってはRecordやテキストに変換して流すことも検討 • FileGetじゃなくてRecordGetを使いましょう • メモリの心配がなくてスピード優先ならFileGetもあり • RDBGetのフェッチサイズを調整しましょう • JDBCドライバーの特性によって最適なサイズは変わります 46 ©1998-2017 Infoteria Corporation
  47. 47. 本日のまとめ 47
  48. 48. まとめ • 業務やシステム特性についてを深く理解し、運用パ ターンを網羅的に想定する • 効率よく、限りなく運用に近いパターンでベンチマー キングを行う • 技術アンテナを高く持ち、十分な基礎知識を蓄えるこ とでさまざまなボトルネックに対して速やかに対処で きる • フットワーク軽く、いつでも最適な環境に切り替えら れるようにシステムに柔軟性を持たせる • ASTERIA WARPのさまざまなツールも活用してくだ さいね! 48 ©1998-2017 Infoteria Corporation
  49. 49. 49 ありがとうございました

×