非機能要件（拡張性）

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

拡張性には、インフラの拡張性とアプリケーションの拡張性の２つの観点があります。本番稼働後に、どれだけ容易に拡張できる作りにしておくかという要件です。

１．インフラの拡張性

インフラの拡張性では、サーバーごとにどのくらいの期間でスケールアウトやスケールアップをできるようにするかを合意します。

一般的には、WebAPサーバーはスケールアウト、DBサーバーはスケールアップでリソースを増強します。

いずれの場合でも、リソース増強の判断をしてからどのくらいの期間で増強が完了するのか、作業実施時のサービス提供時間はどれくらいかを合意します。

上記のような期間でベンダーと合意をした場合、基盤のテストの中でスケールアウトを行い、１日で作業が完了するかを確認します。もちろん事前に手順書やスクリプトも作成しておくので、本番でスケールアウトが発生した場合には、それらをブラッシュアップして使用することも想定します。

またスケールアップの場合、増設するCPUやメモリー、DISKの上限があるので、それらも明らかにしておきます。

DBサーバーは基本的にはスケールアップでリソース増強しますが、リソースには上限があるため、一定以上のリソース増強の場合にはスケールアウトにする必要があります。DBサーバーのスケールアウトは製品によっては対応できない場合もあるので、将来的にスケールアウトを想定するのであれば、それに対応した製品にする必要があります。

２．アプリケーションの拡張性

アプリケーションの拡張性は非機能要件の中で、保守性と１、２位を争うほど厄介な要件です。

ありがちなのは「将来、M&Aで同業他社を吸収した場合でも、速やかに同業他社の要件を追加できるようにする」とか「将来、テナントのPOSを利用しても買い上げ分析ができるようにしておく」といった将来のビジネスモデルの変更の可能性を拡張性要件に盛り込むケースです。

気持ちは分かりますが、システムは魔法の箱ではないので、このような漠然とした拡張性の要件は実現できません。

今までも、変化の激しいビジネス環境に、速やかにシステム対応できるようにするために、オブジェクト指向だとか、SOA、最近だとマイクロサービスといったような考えが出てきていますが、いずれもビジネスモデルの変化に対応できるような魔法の手法ではありません。

基本的には大部分のアプリケーションは、データベースが要となり、データベースの変更がシステムを変更するスピードの足かせになります。

端的に言えば、主要なテーブルのKeyが変わらなければ、比較的に速やかに対応しやすいですが、テーブルのKeyが変わるような変更は、かなりの費用と時間をかけることになります。

またスモールスタートをして、徐々に機能を増やして大きくしていくような考えも、はじめから拡張後のシステムをイメージして作っておかなければ、簡単には拡張は出来ません。

アプリケーションの拡張性は、拡張後の要件が明確で、すぐにでも拡張後のアプリケーションを構築できるくらいでなければ、実現は困難であることが多いので、その辺りを過剰に期待せずに要件定義を実施する必要があります。

【振り返り】

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

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

今週のお題「夏うた」

はてなブログの今週のお題「夏うた」

夏のうたといえば、「平和ってなあに」。

東京都大田区の平和都市宣言の歌です。毎年8月15日に大田区平和都市宣言記念事業「花火の祭典」で、多摩川河川敷での花火の打ち上げ前に、みんなで合唱をします。

2001年8月15日にはじめて行ってから、大田区民でもないのにほぼ毎年参加。いつの間にか「平和ってなあに」をそらで歌えるようになってしまいました。

残念ながら今年はコロナで「花火の祭典」は中止になってしまったけれど、来年はまたみんなで「平和ってなあに」を合唱できるといいなと思います。

初フェイスシールド

今日は店舗の応援でした。

店舗の入口にサーモグラフィーと消毒液を置いているのですが、気づかずに出口から入ろうとするお客さまを、入口に誘導する係り。

店でフェイスシールドを支給されたので、はじめて着けてみました。

他の人たちが着けているフェイスシールドと違って、透明度が悪く視界不良。応援用は経費削減で質の悪いフェイスシールドでした。

と勝手に思っていたら、見回りにきた人に、セロハン付けたままだよ、と言われ、セロハンを外すとくっきり視界良好に。

はじめてのフェイスシールドに、ご機嫌で出口に立っていたのですが、徐々に腰が・・・。同じ場所にずっと立っているのが、こんなに辛いとは。

２時間経って昼休憩になったときには、腰のあまりの痛さにロボット歩き。放心状態で１時間の昼休憩が終わった後は、再度、２時間立ちっぱなし。

誘導係の仕事そのものは楽でしたが、腰がぼろぼろになりました。

今週のお題「お気に入りのTシャツ」

はてなブログの今週のお題「お気に入りのTシャツ」

スイカが好きなので、スイカＴシャツを持ってます。

エスニック系の雑貨屋で出会って、一目惚れ。

物欲の無い私にしては珍しく、即決で買ってしまいました。そして当然、恥ずかしくて外では着られず、タンスの肥やしに。

唯一、毎年夏の沖縄旅行の時にだけ来ていたスイカＴシャツですが、コロナで在宅勤務がはじまった４月に、テレビ会議で思い切ってスイカＴシャツデビューをしてみました。

関西の会社で関西出身の人たちが多いので、きっとスイカＴシャツを見て、突っ込み入れてくれるだろうと期待していたら、誰にも触れられず、打合せ終了。

スイカＴシャツは関西ウケしないのか、それとも誰もテレワークで私の映像なんて見ようとしなかったのか、どちらにしてもスイカの悲しい思い出が一つ、増えてしまいました。 

打合せデー

今日は、11:00-12:00、14:00-15:00、15:00-16:00、16:00-17:00、17:00-18:00、18:00-18:30と笑ってしまうくらい、打合せがびっしり。

せっかくのテレワークなのに、のんびり過ごせません。

打合せしていると、「仕事をやっている感」がしますが、テレワークになってから成果物で成果が見られるようになりつつあります。

今日一日、打合せだけで終わってしまったので、無駄な打合せは減らしていかねばと痛感です。

非機能要件（性能：基盤設計（後編）・性能負荷テスト）

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

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

５．基盤設計（タイムアウト：上級編）

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

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

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

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

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

６．基盤設計（待機接続数）

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

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

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

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

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

７．基盤設計（その他）

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

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

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

８．性能負荷テスト

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

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

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

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

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

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

【振り返り】

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

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

通勤定期券の更新

７月も今日で終わり。そして通勤定期券も今日で期限切れ。

８月もテレワークが続きそうなので、定期券を更新するのはやめました。

定期代丸儲けです。

でも儲けばかりでなく、来月からは出費が増えそう。

今年は不幸中の幸いで梅雨明けが遅く、７月は冷房要らずでしたが、いよいよ梅雨明けが近づいてきて、冷房の電気代が気になります。

毎年、私は冷房を入れずに過ごしていたのですが、在宅勤務中でも冷房無しで過ごせるのか、未知の世界に突入です。