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

2.
2
©1998-2017 Infoteria Corporation

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
運用に適した構成を見積もる
©1998-2017 Infoteria Corporation

5.
5
本日はASTERIA WARPを
利用したデータ連携システ
ムを前提とした話をします
©1998-2017 Infoteria Corporation

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

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

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

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

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

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

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

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

14.
ベンチマーキングの指標
• スループット
• 単位時間内に処理できる実行数やデータ量
• 処理速度を上げれば高くなる
• 並列度を上げれば高くなる
14
©1998-2017 Infoteria Corporation

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

16.
パラメータとなるリソース 16
©1998-2017 Infoteria Corporation

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

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

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

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

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

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

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

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

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

26.
よくあるボトルネック

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

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

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
構成の決定
最終的なシステム構成を決定
ボトルネックの調査
ボトルネックとなる部分の調査
ベンチマーキング
運用負荷を想定した処理をプロトタイプし測定
前提条件の設定
運用するシステムの負荷を見積もる
©1998-2017 Infoteria Corporation

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

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

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

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

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

36.
ASTERIA WARPのサイジングTips

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

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

39.
プロファイルモード 39
©1998-2017 Infoteria Corporation

40.
プロファイルモード 40
©1998-2017 Infoteria Corporation

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

43.
プロセス状況を調べる 43
• FSMCでスナップショットを見る。ツール＞サービス
©1998-2017 Infoteria Corporation

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

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

47.
本日のまとめ
47

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

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