これで失敗しない ASTERIA WARPサイジングのポイント

これで失敗しない！
ASTERIA WARP
サイジングのポイント
インフォテリア株式会社
東京R&Dセンター
田村健

2
©1998-2017 Infoteria Corporation

サーバーサイジングとは
サーバサイジングとは、システムやサー
ビスを提供する際に、想定されるシステ
ムの負荷を見積もり、それを処理するの
に十分な性能・台数のサーバを用意する
こと。システムの運用を開始した後に、
負荷の増大に応じてサーバ性能を増強す
ることも含まれる。
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
3

4
運用に適した構成を見積もる

5
本日はASTERIA WARPを
利用したデータ連携システ
ムを前提とした話をします

サーバーサイジングの手順 6
構成の決定
最終的なシステム構成を決定
ボトルネックの調査
ボトルネックとなる部分の調査
ベンチマーキング
運用負荷を想定した処理をプロトタイプし測定
前提条件の設定
運用するシステムの負荷を見積もる

7
構成の決定

前提条件となるもの
• システム要件
• 利用する技術
• ソフトウェア
• クラウド or オンプレミス
• 運用負荷
• 変動要因
• データ量
• 同時アクセス数
• バッチなのかオンライン処理なのか
• 性能要件
• 現実的な数値
• コスト
• サイジングの結果として、これらの前提を変更する可能性も出て
くることもある、つまり、パラメータになる可能性もある
8

運用負荷を考えるときに考慮すべきポイント
• 安定状態とピーク状態
• 定期的な変動要因
• 季節、曜日、時間帯、月末月初
• キャンペーンなど突発的な変動要因
• システムのタイプ
• バッチ処理：一度に大きな処理
• APIサーバー：細かい
• データ
• 均一なのか？変動が大きいのか？
• データ量
• １レコードのサイズ
• レコード数
• 並列度
9

10
構成の決定

ベンチマーキングとは
• 実際にプロトタイプを作成して、運用に可能な限り近
い状態で性能を測定する
11

ベンチマーキングのポイント
• 想定した運用条件に可能な限り近づける
• 処理内容
• データの量と質
• 実行形態
• アウトプットとなるシステム構成をイメージし、シン
プルな構成から始める
• 処理内容の特性を理解する
12

ベンチマーキングの指標
• 単一リクエストのレスポンスタイム
• 処理を開始してから処理が終了するまでの時間
• 処理速度を上げれば速くなる
• 並列度を上げても変わらない
• 多重リクエストのレスポンスタイム
• 処理投入開始からすべての処理が終了するまでの時間
• 処理速度を上げれば速くなる
• 多重度＜並列度であれば、多重度を上げると速くなる
• 多重度＞並列度であれば、多重度を上げると遅くなる
• 各リクエストのレスポンスタイムは同じであるとは限らない
• 単一リクエスト時のレスポンスタイム×リクエスト数
≠ 多重リクエスト時の各レスポンスタイムの合計
13

• スループット
• 単位時間内に処理できる実行数やデータ量
• 処理速度を上げれば高くなる
• 並列度を上げれば高くなる
14

• プロセスのメモリ使用量
• プロセスが確保する最大のメモリ量
• 一度にメモリ中に展開されるデータ量に依存する
• 多重度が上がればメモリは多く使われる
• システムのメモリ使用量
• プロセスが確保する以外にOSが使用するメモリも考慮が必要
• ファイルキャッシュ、システムスワップはレスポンスタイム
やスループットにも影響する
15

パラメータとなるリソース 16

CPU
• 速度
• クロック数
• ECU (AWS)
• 仮想コア数×仮想コアあたりの
Unit数（処理スピード）
• 並列度
• 物理CPU数
• コア数
• 物理コア
• 論理コア（ハイパースレッディン
グ）
17

メモリ
• OS搭載メモリ
• プロセス割り当てメモリ（Java）
• 初期ヒープサイズ
• 最大ヒープサイズ
• その他各種メモリパラメータ
• スワップ領域
18

ストレージ
• 物理タイプ
• HDD
• SSD
• RAID
• 0/1/5/6/0+1
• 接続
• USB
• Ethernet
• iSCSI
• FC
• ネットワークプロトコル
• NFS
• iSCSI
• SMB(Windows共有ファイル)
19

ネットワーク
• RTT（ラウンドタイムトリップ）
• ネットワーク往復の応答時間
• レイテンシとも
• 物理的配置
• AWSやAzureのリージョン
• スイッチングハブなどの機器による影響
• ファイアウォールなどの機器・設定による影響
• Web APIなど、ネットワーク呼び出しの大きいシステ
ムへの影響大
• データベース・アクセスにも影響
20

ベンチマーキングのコツ
• 基本パターンで小さく始める
• いきなりピーク時の負荷をかけた場合、結果が出るまでに時間がかかる
• 小さなデータ、少ない多重度から徐々に運用パターンに近づける
• 可変パラメータは一つに、その他のパラメータは固定
• CPU速度だけを変更して測定
• 多重度だけを変更して測定
• ネットワークだけを変更して測定
• 当たりをつける
• すべての可変パラメータについてベンチマーキングを行うのは効率が悪い
• 論理的にどこがボトルネックになるのかを考えながらパラメータを変えてい
く
• 他の要因を極力排除
• セキュリティソフトのディスクI/OやCPUに与える影響
21

22
構成の決定

• 多重度や速度がリソースの追加に伴って比例して向上
することが望ましい
• 性能要件に満たない場合はボトルネックを調査する
23ベンチマークの結果を精査

ボトルネックとは？
• 処理速度を阻害する最も大きな要因
• ボトルネックを検出するためのベンチマーキング
• ボトルネックは、解消すれば新たなボトルネックが発
生する
24

ボトルネックを全て解消する必要はない
• 運用に耐えられれば良い
• 運用開始後に対策が立てられるように原因を探ってお
くことが大切
• 簡単に解消できるボトルネックは解消する
25

よくあるボトルネック

多重度を上げた場合にレスポンスタイムが遅くなる
• 並列度が足りてない
• CPU数、コア数、スレッド数
• 処理の何処かで待ちが入っている
• 排他制御
• IOブロック
27

マルチスレッドは万能か？
• 単独で１０秒の処理を８コアのサーバーで同時に８個
の処理を実行開始した場合、すべての処理が終わるま
でにかかる時間は？
• ＞１０秒
• 完全に並列になることはない
• OSレベル、物理レベルでのさまざまなコスト
• プロセススイッチ
• ストレージアクセス
• ネットワークアクセス
• 多くのコアの１サーバーより１コアの複数サーバーの
方が効率良いこともある
28

Web APIの呼び出し
• ネットワークが絡むと小さな要因が増幅されることが多い
• 例えばWeb APIで1000件のデータを取得する場合
• ローカルでテストしていたときは2秒しかかからなかった
• リモートからテストすると11秒かかってしまう
• 実は1000件のデータを1000回APIを呼んで取得していた
• 通信コストがローカルでは1ms、リモートでは10ms。データ取得のコ
ストはどちらも1ms
• API呼び出しでの通信コストが10倍になったので、全体も約10倍になる
• どちらも1回の呼び出しでは10ms以下なので単体テストでは気づきにく
い
• 同様のケース
• 毎回ログイン
• ネットワーク経由でのDBアクセス
29

30
構成の決定

システムの構成を考える
• ベンチマークの結果からシステムをどのような構成に
すべきかを考える
• ポイント
• キャパシティ設計
• オーバーフロー時の対策
31

キャパシティ設計
• 安定運用にはリソースに余裕をもたせることが重要
• 決定要因
• システムの重要度
• キャパシティを超えた場合の深刻度
• コスト
32

オーバーフロー対策
• オーバーフローは起こるものという前提で考える
• そのときに慌てないようにシステムに柔軟性を持たせ
ておくことが大切
• クラウドの活用
• スケールアップとスケールアウト
33
スケールアップ
スケールアウト

例1) 月次バッチのシステムの場合
• システム特性
• メモリが足りなければ増設しか解消方法がない
• 処理時間が想定時間内に終わらなくても、最悪待っていれば
少しの遅延で済む
• 構成案
• メモリは想定最大データよりもより多くのデータを処理でき
るだけを確保しておく
• CPU速度はコスト見合いで
34

例２) ECサイト
• システム特性
• 処理時間がユーザーエクスペリエンスに直結する
• １度の処理に使うメモリは少ない
• 多重度のブレが大きい
• 構成案
• CPUはできるだけ速いものを選択し、コア数も確保する
• メモリはそこそこ。ただし、多重度に耐えうる構成
• キャンペーンなど、多重度の上がるケースに備えて、スケー
ルアウトできる構成
35

ASTERIA WARPのサイジングTips

デザイナーで実行して処理時間を見る
• デザイナーから見た実行時間なのでサーバーとの間の
通信コストなども含まれる
• 時間がかかる場合、フローのタイムアウトにも気をつ
けなければならない
37

ログファイルから実行時間を読む
• ログファイルにはフローの実行時間が出力されている
• FlowService.log
• アプリケーションログ
• フローに純粋にかかった時間
• 開始時刻と終了時刻から計算しなくてOK
.... フローの実行を開始します: /user.Project1.Flow1
.... フローの実行が終了しました: /user.Project1.Flow1 [1345ms]
38

プロファイルモード 39

• FlowProfile.logにCSV形式で出力
• CSV形式のデータ
• 詳細は「フローデザイナー操作ガイド」＞「フローの
実行」＞「直接起動」＞「プロファイルを参照する」
https://asteria.jp/documentation/warp/1610/flow/designer/index_guide.html#exe
c_direct_profile.html

多重度性能を測定する
• Timerコンポーネントを利用する
• Loop->Timerで複数のリクエストを実行
する
• Timerコンポーネントの「実行する時間」
を「0」にすることで呼び出しコストを最
小化
（0以上だとスケジューラが使用される）
• 「実行モード」を指定できるのでプロ
ファルが取得できる
42

プロセス状況を調べる 43
• FSMCでスナップショットを見る。ツール＞サービス

fsmon.exe
• フローの各プロセスの状況を見るためのコマンド
• 1610: <INSTALL_DIR>/server/bin/fsmon.exe
• 4.x: <INSTALL_DIR>/flow/bin/fsmon.exe
• ダブルクリックするとGUI版が開く
• -consoleをつけてコマンドを実行するとコンソール
モードで実行される
44

OutOfMemory？
• 不要なストリームを使っていないか確認しましょう
• サブフローでストリームを返さないのにEndResponseに
なっていないか？
• パラレルで大きなストリームを処理していないか？
• CSVやXMLはメモリをたくさん使います
• 場合によってはRecordやテキストに変換して流すことも検討
• FileGetじゃなくてRecordGetを使いましょう
• メモリの心配がなくてスピード優先ならFileGetもあり
• RDBGetのフェッチサイズを調整しましょう
• JDBCドライバーの特性によって最適なサイズは変わります
46

まとめ
• 業務やシステム特性についてを深く理解し、運用パ
ターンを網羅的に想定する
• 効率よく、限りなく運用に近いパターンでベンチマー
キングを行う
• 技術アンテナを高く持ち、十分な基礎知識を蓄えるこ
とでさまざまなボトルネックに対して速やかに対処で
きる
• フットワーク軽く、いつでも最適な環境に切り替えら
れるようにシステムに柔軟性を持たせる
• ASTERIA WARPのさまざまなツールも活用してくだ
さいね！
48

49
ありがとうございました

これで失敗しない ASTERIA WARPサイジングのポイント

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to これで失敗しない ASTERIA WARPサイジングのポイント

Similar to これで失敗しない ASTERIA WARPサイジングのポイント (20)

More from ASTERIA User Group

More from ASTERIA User Group (7)

Recently uploaded

Recently uploaded (6)

これで失敗しない ASTERIA WARPサイジングのポイント