これで失敗しない 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

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

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

4

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


5

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


サーバーサイジングの手順 6

構成の決定

最終的なシステム構成を決定

ボトルネックの調査ボトルネックとなる部分の調査

ベンチマーキング運用負荷を想定した処理をプロトタイプし測定

前提条件の設定運用するシステムの負荷を見積もる


7

構成の決定






前提条件となるもの

• システム要件• 利用する技術• ソフトウェア• クラウド or オンプレミス

• 運用負荷• 変動要因• データ量• 同時アクセス数• バッチなのかオンライン処理なのか

• 性能要件• 現実的な数値

• コスト

• サイジングの結果として、これらの前提を変更する可能性も出てくることもある、つまり、パラメータになる可能性もある


8

運用負荷を考えるときに考慮すべきポイント

• 安定状態とピーク状態• 定期的な変動要因

• 季節、曜日、時間帯、月末月初• キャンペーンなど突発的な変動要因

• システムのタイプ• バッチ処理：一度に大きな処理• API サーバー：細かい

• データ• 均一なのか？変動が大きいのか？• データ量

• １レコードのサイズ• レコード数

• 並列度

9


10

構成の決定






ベンチマーキングとは

• 実際にプロトタイプを作成して、運用に可能な限り近い状態で性能を測定する


11

ベンチマーキングのポイント

• 想定した運用条件に可能な限り近づける• 処理内容• データの量と質• 実行形態

• アウトプットとなるシステム構成をイメージし、シンプルな構成から始める

• 処理内容の特性を理解する

12


ベンチマーキングの指標

• 単一リクエストのレスポンスタイム• 処理を開始してから処理が終了するまでの時間• 処理速度を上げれば速くなる• 並列度を上げても変わらない

• 多重リクエストのレスポンスタイム• 処理投入開始からすべての処理が終了するまでの時間• 処理速度を上げれば速くなる• 多重度＜並列度であれば、多重度を上げると速くなる• 多重度＞並列度であれば、多重度を上げると遅くなる• 各リクエストのレスポンスタイムは同じであるとは限らない• 単一リクエスト時のレスポンスタイム × リクエスト数

　≠ 多重リクエスト時の各レスポンスタイムの合計

13



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

14



• プロセスのメモリ使用量• プロセスが確保する最大のメモリ量• 一度にメモリ中に展開されるデータ量に依存する• 多重度が上がればメモリは多く使われる

• システムのメモリ使用量• プロセスが確保する以外に OS が使用するメモリも考慮が必

要• ファイルキャッシュ、システムスワップはレスポンスタイ

ムやスループットにも影響する

15


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

CPU メモリー

ネットワークストレージ


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#exec_direct_profile.html


https://asteria.jp/documentation/warp/1610/flow/designer/index_guide.html%23exec_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


デモ

45

OutOfMemory ？

• 不要なストリームを使っていないか確認しましょう• サブフローでストリームを返さないのに EndResponse になっていな

いか？• パラレルで大きなストリームを処理していないか？

• CSV や XML はメモリをたくさん使います• 場合によっては Record やテキストに変換して流すことも検討

• FileGet じゃなくて RecordGet を使いましょう• メモリの心配がなくてスピード優先なら FileGet もあり

• RDBGet のフェッチサイズを調整しましょう• JDBC ドライバーの特性によって最適なサイズは変わります

46


本日のまとめ

47

まとめ

• 業務やシステム特性についてを深く理解し、運用パターンを網羅的に想定する

• 効率よく、限りなく運用に近いパターンでベンチマーキングを行う

• 技術アンテナを高く持ち、十分な基礎知識を蓄えることでさまざまなボトルネックに対して速やかに対処できる

• フットワーク軽く、いつでも最適な環境に切り替えられるようにシステムに柔軟性を持たせる

• ASTERIA WARP のさまざまなツールも活用してくださいね！

48


49

ありがとうございました

Software

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