Help us understand the problem. What is going on with this article?

Webパフォーマンス管理の基本 1

はじめに

Webパフォーマンスはパフォーマンスエンジニアリングの1つの分野

Webパフォーマンス管理は、Webサイトの非機能要求の性能や可用性を扱います。
専門用語では、コンピュータの登場と時期を同じくして登場したパフォーマンスエンジニアリングという分野に属します。

パフォーマンスエンジニアリング

パフォーマンスエンジニアリングとは、Wikipediaでは以下のように記載されています。

Performance engineering encompasses the techniques applied during a systems development life cycle to ensure the non-functional requirements for performance (such as throughput, latency, or memory usage) will be met. It may be alternatively referred to as systems performance engineering within systems engineering, and software performance engineering or application performance engineering within software engineering.

パフォーマンスエンジニアリングは、システム開発のライフサイクルの中で、パフォーマンスに対する非機能的な要件(スループット、レイテンシ、メモリ使用量など)を確実に満たすために適用される技術を網羅しています。システム・エンジニアリングの中のシステム・パフォーマンス・エンジニアリング、ソフトウェア・エンジニアリングの中のソフトウェア・パフォーマンス・エンジニアリングまたはアプリケーション・パフォーマンス・エンジニアリングとも呼ばれることがあります。

As the connection between application success and business success continues to gain recognition, particularly in the mobile space, application performance engineering has taken on a preventive and perfective role within the software development life cycle. As such, the term is typically used to describe the processes, people and technologies required to effectively test non-functional requirements, ensure adherence to service levels and optimize application performance prior to deployment.

アプリケーションの成功とビジネスの成功との関連性が、特にモバイル分野で認識されるようになるにつれ、アプリケーション・パフォーマンス・エンジニ アリングは、ソフトウェア開発のライフサイクルの中で、予防的かつ完全性について役割を担うようになりました。そのため、この用語は一般的に、非機能的な要件を効果的にテストし、サービスレベルを確実に遵守し、デプロイ前にアプリケーションのパフォーマンスを最適化するために必要なプロセス、人材、および技術を説明するために使用されています。

The term performance engineering encompasses more than just the software and supporting infrastructure, and as such the term performance engineering is preferable from a macro view. Adherence to the non-functional requirements is also validated post-deployment by monitoring the production systems. This is part of IT service management (see also ITIL).

パフォーマンスエンジニアリングという用語は、ソフトウェアとそれをサポートするインフラストラクチャだけでなく、それ以上のものを含んでいるため、パフォーマンスエンジニアリングという用語は、マクロな視点から見ることが望ましいです。非機能要件への準拠は、本番システムを監視することで、デプロイ後にも検証されます。これはITサービス管理の一部です(ITILも参照すること)。

Performance engineering has become a separate discipline at a number of large corporations, with tasking separate but parallel to systems engineering. It is pervasive, involving people from multiple organizational units; but predominantly within the information technology organization.

パフォーマンス・エンジニアリングは、多くの大企業において、システム・エンジニアリングとは別個の、しかし並行して行われているタスクを持つ別個の規律となっている。これは、複数の組織単位からの人々が関与し、普及していますが、主に情報技術の組織内で行われています。

Webパフォーマンスの目標となる値

Webパフォーマンスでは、主に、以下の2つの指標を用います。

  • 表示速度 - WebブラウザでWebページが表示される速度
  • 可用性 - WebブラウザでWebサイトにアクセスした際に、エラーや遅延がなくアクセスできる率

現在、私が働くSpelldataでは

  • 表示速度 - 表示開始時間が0.5秒、表示完了時間が1秒を全体の期間の98%で達成する
  • 可用性 - 全体の期間で3%以下のエラー率

を目標値としています。

最近では、GoogleがWeb Vitalという指標を発表して運用を開始しましたが、商用のWebパフォーマンス計測システムでは使われていません。

Webブラウザの表示をWebブラウザの中から正確に計測する事はできません。
何故かというと、Webページのレンダリングは必ずOSのグラフィックス処理が絡みます。
Webブラウザの処理だけでは完結しません。

私は、Webブラウザの表示をWebブラウザ側から計測しようとする事を「箱の中から箱の外を観察する」と説明しています。

Webブラウザで計測できるのは、あくまでも、Webブラウザの中での計算処理です。
描画については、商用計測ツールでは、実際の描画を計測します。

例えば、Microsoft、Apple、Google、Verizon、各CDNサービスなど、多くのIT企業や通信企業、インターネットサービス企業が採用しているCatchpointであれば、描画開始はグラフィックス処理を観測し、描画の推移は0.2秒毎に取得して観測します。
(filmstripと云います)

Render StartとDocument Complete

表示開始時間(Render Start)とは、Webブラウザに最初の1ピクセル目が表示された時間です。
表示完了時間は、Document Complete = Loadを指します。

私が、Akamaiに勤めていた2006年~2009年頃は、ダウンロード時間が指標値でした。2006年当時は3秒ルールと言われていましたが、2009年には2秒ルールと、より速さを求められるようになりました。
現在、アメリカでは、ダウンロード時間が1秒を切るサイトが普通にあります。
例えば、Appleのデスクトップサイトは、米国においては、0.8秒でダウンロードが完了します。

技術と共に変わる目標数値

通信速度の発達によって、この目標数値は変わっていきます。
全国的に4.5Gが普及しており、5Gの基地局展開も着々と進められています。

人の感覚については、精神物理学という分野が扱っており、ヴェーバー—フェフナーの法則が有名です。
人の感覚は対数グラフとなるため、刺激量が小さくなるほどに、人の感覚は鋭敏化します。
表示が高速になればなるほど、人は速さに敏感になります。

刺激の種類によって定数は異なり、それをウェーバー比と云います。
視覚のウェーバー比は0.016です。

「5Gが普及すればWebパフォーマンスの高速化は必要無くなるのかな?」と疑問に思われる方がいます。
今は、もうネットワークにボトルネックは無く、フロントエンド、もしくはバックエンドにボトルネックがある事が殆どです。
計算処理に起因する遅延です。

ですから、5Gが普及しても、遅延は解決しません。
それどころか、「5Gなのに何故遅いんだ?」とユーザは疑問に思うでしょう。

更に、5Gになって通信が高速になり、今まで以上に高速通信を行う場所を選ばなくなるのであれば、通信する機会は更に増えていき、計算量が増大します。

人は、ウェーバー・フェフナーの法則で分かるように、高速になればなるほど、高速さに敏感になります。
人は快適になればなるほど、更なる快適さを求めるという事です。
計算量は増大し続ける一方で、人々は高速性という快適さも求める、それが私達が解決すべき命題だという事です。

コンピュータと高速化は決して離れる事はない密接な関係にあり、永遠の命題なのです。

Webパフォーマンス管理とは

「揺らぐ」数値を扱い管理する

この世界の全てのものは「揺らぐ」わけですから、表示速度もバラツキが生じます。
毎回計測して、必ず同じ値になるわけではありません。

Webパフォーマンスの計測も、時間帯やISP、ブラウザの種類などで変わります。
変化し続けていくわけですから、一回の「計測」で済むわけではなく、「計測し続ける」事が必要になります。

この点がソフトウェアエンジニアには理解しづらい点だと思います。
ハードウェアエンジニアは、数値の揺らぎを日常的に扱っていますが、ソフトウェアエンジニアは数値の揺らぎは馴染みがないでしょう。

ソフトウェアエンジニアにとっては、計算処理が主たる世界ですから、計算が「揺らぐ」事はあり得ません。
しかし、計算処理が行われるハードウェア自体は揺らぐわけですし、データの搬送路であるネットワークの性能も揺らぐわけですから、結果として、Webパフォーマンスの数値は揺らぎます。

数値の揺らぎ(バラツキ)を管理することが品質管理です。
24時間365日、Webサイトのパフォーマンスを計測していなければ、「管理」できません。

技術力が高いとか低いという話では、「〇〇ができる」という話になりますが、エンジニアリングや品質管理の世界では、如何にバラツキを小さくできるかが技術力です。
技術力は、その品質によって定量評価できます。

統計的品質管理の源流

そこで、「統計的品質管理」の理解が重要になってきます。
日本の製造業では、もう半世紀以上に亘って知られていて、企業文化の根幹を成す知識ですが、IT業界やWebサイトの制作では知られていないので、その源流をざっと辿ってみます。

「統計的品質管理の父」ウォルター・アンドリュー・シューハート博士

317564b828bc45cfef69d6ad2f38e785.jpg
ウォルター・アンドリュー・シューハート博士(1891 - 1967)

シューハート博士は、「統計的品質管理の父」と呼ばれています。
1918年にAT&Tの製造部門であるウェスタン・エレクトリックの検査技術部に配属され、通信システムの品質管理に携わっていました。
「統計的品質管理の父」が、実は、通信システムの分野の方だったというのは、とても興味深いと思いませんか?

アナログの電話回線では、銅線の中を通って弱くなった信号を、ある一定区間毎に中継増幅器というものを使って増幅します。
日本だと、電柱を立てて架空に設置しますが、米国だと地下に埋設します。
簡単に交換できる場所ではないため、この中継増幅器の品質を高める必要があったのです。

従来、この中継増幅器の完成品を検査して品質を確認していたものを、シューハート博士は製造工程単位で品質を管理する事も必要だという事で、「管理図」というものを考え出します。

品質の問題を、「特殊原因」と「共通原因(偶然原因)」から成り立つと考えて、それらを区別し、製造工程を共通原因だけが存在する統計的プロセス制御を行い、その制御を維持することが、未来の出力を予測して経済的に製造工程を管理するのに必要であると主張されたのです。

シューハート博士は、1925年に設立したAT&Tの研究機関であるベル研究所で、引退されるまで在籍して研究されていました。

ウィリアム・エドワーズ・デミング博士

DEM-1002 WED 1950s_650.jpg
ウィリアム・エドワーズ・デミング博士(1900 - 1993)

デミング博士は、元々は米国の農務省に勤務し、その後、統計家としてアメリカ国勢調査局に勤務していました。
農務省時代にシューハート博士が米国農務省で行った一連の講義をまとめて、1939年に「Statistical Method from the Viewpoint of Quality Control」 として出版しました。

第二次世界大戦の後、1951年、GHQが日本の国勢調査を行う際に、その計画立案のため、デミング博士を日本に招聘します。

そこで、日科技連(日本科学技術連盟)はデミング博士に講演を依頼します。
日科技連の人たちは、シューハート博士の技法を学んでいて、日本の復興のために、統計的制御の専門家の教えが必要だと考えていたのです。
現代の私達には信じられないかもしれませんが、第二次世界大戦以前は、日本の工業製品は「安かろう・悪かろう」という粗悪品の代名詞だったのです。

日本の製造業の人達は、デミング博士から統計的品質管理を学び、「安かろう・悪かろう」から「安くて高品質」の工業製品を作ることで世界市場を席捲していくことになります。

日本においてデミング博士にちなんだ「デミング賞」が品質に関する賞として日科技連で創設されましたが、米国においてはシューハート博士にちなんだ「シューハート・メダル」がアメリカ品質学会で創設されています。

品質管理の重要性

現在、世界的には、IT予算の1/4~1/3が品質管理関係に使われます。
しかし、日本はどうでしょうか? 皆さんのプロジェクトのどの位の割合の費用が、品質管理や品質保証に使われているでしょうか?

そもそも、何故、品質管理が重要なのでしょうか?

ITシステムの大事な品質概念 V&V

「ITシステムの品質管理」としてのWebパフォーマンスを語るときに、是非、押さえていただきたいのが、V&V という概念です。

Verification(検証) & Validation(妥当性確認)です。
Verification(検証)とは、対象が要求された仕様、設計、計画などの要求事項が満たされているかどうかについての確証を指します。
Validation(妥当性確認)とは、対象の機能や性能が本来意図された用途や目的に適っているか、実用上の有効性があるかについての評価を指します。

ri10_vmodel01.gif
情報システム用語辞典: V&VのソフトウェアV&V(ベームのVチャート)より引用

Webパフォーマンスは、Validation(妥当性確認)に該当する品質です。
Webサイトの場合は、きちんと表示されて、様々な機能が動くところまでの品質はVerificationであり、それが実用に耐えうる、もしくは快適な速度で反応できるかどうかの品質はValidationなのです。

この概念は、ISO 9000にも取り入れられています。

ISO 9000ファミリーについて深く学ばれると、ITシステムとしてのWebパフォーマンス管理について、より理解が深まると思います。
情報マネジメント用語辞典: ISO 9000

Webパフォーマンス向上の効果

Webパフォーマンスを日々計測し、そして改善を行うと、どのような効果を得られるでしょうか?
インターネット上では、「1秒高速化すると売上が…」みたいなデータがあれこれと掲載されています。

ここでは、実際にSpelldataで高速化を行った結果、どのような効果をお客様が得たのかをご紹介します。

売上の増大

何かを販売されているサイトでは、30%前後を最頻値として売上が改善されました。
最大で3倍まで伸びたお客様もいらっしゃいます。
そのWebサイトや企業ブランドに対するStickiness(粘着性)が高いほどに、高速化による売上増大の効果は高いです。

PV数の増大

こちらはメディアサイトや転職サイトなど、定常的にアクセスして利用する、Stickiness(粘着性)が高いサイトほど、やはり効果が高いです。
2~3倍ぐらいPV数が伸びました。

コストの削減

こちらは、サーバの台数が多い大規模サイトや、多数のサイトを運用されているお客様から評価されました。
Webパフォーマンスが悪いということは、計算リソースを効率的に運用できていないという事を意味します。
計算リソースを有効活用することでサーバ台数を減らしたり、一段階スペックを下げたりできるようになり、インフラ費用を削減できます。

また品質を良くすることで、障害発生率が低くなり、障害対応のコストが下がり、且つ、お客様に
安定したサービスを提供できるようになり、ブランド向上にも繋がります。

広告効果向上

新聞社などのメディアサイトで広告を運営している企業は、売上が3倍に伸びたと教えて頂きました。
また、広告を出す側の企業は、広告費用を削減しても、売上が変わらず維持できるようになったと教えて頂きました。

広告を出すのは、知ってもらう事が一番の目的です。
広告経由でWebサイトに来た初回訪問が勝負になります。
初回訪問は、キャッシュが効きませんから、本当の高速化をしないといけません。

高速化でビジネス上の恩恵を得るために

Webサイトの高速化は、ビジネスでの売上に大きな影響を与えます。
だからこそ、世界各国の大手企業は、Webパフォーマンス計測に費用を掛けて、計測・監視し、改善し続けています。

大事なのは、真に高速であることで、Google PageSpeed Insightsで高得点を得る事ではありません。
例え、高得点を取得したとしても、実際にユーザが高速な体験をできていないのであれば、上述したようなビジネス上の恩恵は得られないでしょう。

そして、Google PageSpeed Insightsのようなツールに頼るということは、自分ではボトルネック分析ができる技量がない事を暗に意味します。

パフォーマンスエンジニアリングは非常に高度な分野だからこそ、誰でもできるわけではないです。
だからこそ、Google PageSpeed Insightsのような分析ツールが重宝されるのだと理解しています。
しかし、Google PageSpeed Insightsのようなツールは、因果関係を明確にしてくれるわけではなく、やれば効果が得られるであろうという施策の適合度チェックです。

遅延の原因がその施策で解決しなければ、高速化には至らないという点は、しっかりと理解しておく必要があります。

そして、エンジニアの世界も医師の世界のように細分化されていく一方です。
ITエンジニアもフルスタックエンジニアと呼ばれるような全てをカバーしてできるようになるのは非現実的です。

それぞれに専門分野を極めて、専門家同士が連携して問題解決に当たる業界の体制づくりが求められていると考えます。

連載 他の記事

takehora
Webサイトの品質評価・改善のコンサルタントです。 VMwareで、日本人初のVCPトレーナー、AkamaiでProfessional Serviceのコンサルタント、Verizon Businessで主席コンサルタント、Keynote Systemsで日本代表を務めました。 Webサイトの配信品質(可用性、速度、情報品質)について評価・改善するSpelldataという会社を経営しています。
https://spelldata.co.jp
spelldata
表示開始0.5秒、表示完了1秒を目指せ! ― 統計的品質管理手法での Web サイトのパフォーマンス改善と、情報理論に基づくコンテンツ品質の向上をサポートします。
https://spelldata.co.jp
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away