社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

非機能要件(性能:基盤設計(後編)・性能負荷テスト)

非機能要件の中の性能の説明です。

基盤設計の後編と性能負荷テストです。

5.基盤設計(タイムアウト:上級編)

前章で説明したセッションタイムアウト以外に、さまざまなタイムアウトの設定があります。

それらは性能要件が非常に厳しいシステムでは考慮する必要がありますが、通常にシステムでは気にする必要はありません。また製品が異なると設定値も変わってしまうことが難しいところです。

f:id:SystemEngineers:20200725073302p:plain

⑩と⑪の設定が4章で説明をしたセッションタイムアウト(APサーバー)とセッション維持タイムアウトロードバランサー)です。⑪がTomcatとアプリの2箇所を指しているのは、Tomcatでもアプリケーションでも設定できるためです。通常はTomcatの単位(システム単位)で設定しますが、あるサブシステムだけ時間を長くしたいというような場合に、アプリケーション側で設定をします。

⑩⑪が画面操作をして、次の画面操作をするまでの時間に対して、②③⑦は画面操作をしてレスポンスが返るまでの時間です。デフォルトは10分のケースが多く、画面操作をして10分間レスポンスが返らないと、受信タイムアウトとなります。

残りはTCPコネクションのタイムアウトなので、タイムアウトが発生しても画面操作が継続できないような事象にはなりませんが、次のアクセス時にTCPコネクションを確立し直すので、若干、性能に影響します。

6.基盤設計(待機接続数)

5章の①④⑤⑥⑧⑨のTCPコネクションタイムアウトとセットで、待機接続数の設定というものがあります。

TCPコネクションの確立は、3ウェイハンドシェイクという手法を用いるため時間がかかります。

そのためTCPコネクションを使い終わっても、一定時間の時間はコネクションを確立したままにしておき、次のアクセス時に使い回すことで、3ウェイハンドシェイクの時間を省略することができます。このTCPコネクションを確立したままにしておく時間が5章の①④⑤⑥⑧⑨ですが、それとは別に何本のTCPコネクションを残しておくかという設定が待機接続数の設定です。

例えばTCPコネクションのタイムアウトが30秒、待機接続数が50本であれば、20秒間アクセスの無い状態で一気にアクセスが増えても、最大50のアクセスは3ウェイハンドシェイクの時間を省略することができることになります。

待機接続数の考え方は、TCPコネクションだけでなく子プロセスやスレッドでも同様の設定があります。

f:id:SystemEngineers:20200725080123p:plain

7.基盤設計(その他)

その他にデータベースにも性能に関係する設定があります。

例えばOralceであれば、プロセス管理に共有サーバーと専用サーバーの2種類があります。

共有サーバーは大規模システムやOLTPに適していて、専用サーバーはバッチ処理に適していると言われていますが、リソースに余裕がある場合にはOLTP中心のシステムであっても専用サーバーにするの方がメリットが大きいです。

f:id:SystemEngineers:20200726104840p:plain

f:id:SystemEngineers:20200726104853p:plain

8.性能負荷テスト

性能負荷テストの目的は「性能目標の達成確認」と「性能限界とその対応策の把握」です。性能負荷テストは、性能テストと負荷テストで分かれ、性能テストはレスポンス、負荷テストはスループットを計測します。

例えば性能目標が「スループット50件/秒」、「レスポンス3秒以内」だった場合、テストで、スループットが50件/秒の場合のレスポインスが2秒、60件/秒の場合のレスポンスが2.8秒、70件/秒の場合のレスポンスが8秒という結果が出た場合、性能目標は達成していると評価できます。またこの場合の限界性能は60件/秒となり、70件/秒の際のリソース使用量と比較をして、どのリソースがボトルネックになっているかを確認します。

性能負荷テストでの測定対象は、CPUやメモリーのように物理的な上限があるリソース以外に、基盤設計で上限を設定した箇所も対象になります。

f:id:SystemEngineers:20200726095001p:plain

同時接続数の確認は重要なのですが、なかなか要件通りの同時接続数まで到達させられないことが多いのが実情です。

負荷ツールの制約であったり、そもそもCPUが不足して、そこまで同時に処理できないといったことが良くあります。

それでも頑張って性能負荷テストで、どこに負荷がかかりやすいのかを測定すると、本来のテストとは別に、本番稼働後のリソース監視やリソース拡張時の基礎情報として役立てることもできます。

【振り返り】

性能の説明は以上で終了となります。次回は拡張性の説明をしていきたいと思います。

①可用性
②性能
③拡張性
④運用保守
⑤移行
⑥セキュリティ
⑦ユーザービリティ/アクセシビリティ
⑧システム環境