2018年も、残り一カ月となりました。 WebパフォーマンスのAdventカレンダーを今年も開催したので、その初日のエントリーとして(遅れているものの)、今年のWebパフォーマンスを振り返ります。
ベアメタル回帰
今年のWeb(に限らず)パフォーマンスで特徴的だったのは、ベアメタルへの回帰でしょう。
IT業界が長い方はご存じだとは思いますが、集中と分散、仮想と物理のサイクルは繰り返されて来ました。 今後も繰り返されるでしょう。
仮想化技術の宿命
クラウドコンピューティングの基礎となっているのは、仮想化技術です。 AWSをはじめとして、多くのクラウドコンピューティングのプラットフォームを提供している事業者は、コンピューティングリソース(計算能力)を塊として扱い、それを物理の枠を超えて、論理の単位で切り出す方法として、各種ハイパーバイザーをベースにした仮想化技術を用いています。
仮想化技術は、必ず、仮想化する故に、物理マシン(ベアメタル)よりも性能が落ちます。 その性能が落ちる間接コスト(オーバーヘッド)は、PCのパーツによって異なります。
実際、どの位、オーバーヘッドが存在するか、それは「Virtualization Overhead」で検索すれば、色々な資料が出てきます。
例えば、CMG(Computer Measurement Group)のインド支部で2016年に発表されたSandeep Joshi氏のスライドは、EC2での検証もあり、参考になります。
www.slideshare.net
仮想化技術は、高価な汎用機のリソースをパーティショニングする事で、複数台の論理的に分離されたコンピューティング環境を実行し、高価なコンピューティングリソースを有効活用するものでした。 そのアイディアをx86アーキテクチャに持ってきたのがVMwareで、使い切っていないコンピューティングリソースを遊ばせているのは、IT不良資産だから、有効活用しましょうという事で、コスト削減策として売り出したものです。 ですから、パフォーマンスが落ちる事は必然でした。
そうは言っても、高負荷になったときにどうするんだ?という運用上の問題を解決するために、動いたまま仮想マシンをより潤沢なコンピューティングリソースを持つ物理マシンへと移動するVMotionという技術が生まれたわけです。
仮想化技術は、パフォーマンスがちょっと悪くなるというのが前提なわけです。
Oracle Cloud Platformの登場
クラウドコンピューティングの登場から10年が経過し、広汎に普及しているのですが、一方でパフォーマンス問題はあるわけで、その不満がゆっくりと蓄積した10年とも言えるでしょう。 ここに切り込んだのがOracleで、シアトルに数名で乗り込んでクラウドコンピューティングの部署を立ち上げて、AWSやMicrosoft Azureのメンバーなどを採用して作り上げたのが、Oracle Cloud Platformです。 現在、シアトルのOracle Cloud Platformの部署は3000名を超えるそうです。
Oracle Cloud Platformの特長は、ベアメタルクラウドである点です。 AWSやMicrosoft Azureなどを構築してきたクラウドプラットフォームの技術者達が、「次世代のクラウドプラットフォームをつくるなら」という想いで設計したのは、パフォーマンスを追求したベアメタル化だったのです。
ストレージにNVMeやiSCSIを採用し、ベアメタルマシンと組み合わせて提供される事で、高速なディスクアクセスを各種ストレージサービスで提供しています。 それらのマシンがAWSより低価格で提供されるというのは、米国では衝撃のデビューだったのです。 このサービスが東京リージョンにもやってきます。
これに対抗するかのようにAWSも、ベアメタル化へと踏み切っています。
携帯網の高速化
このベアメタルへの回帰の背景には、CPU同様にムーアの法則に従い、無線ネットワークが高速化しているという状況も絡んでいます。
これは、ネットワーク機器メーカーNortel NetworkのCTOのPhil Edhorm氏の発言から、エドホルムの法則と言われています。 「WiFi、無線の通信帯域は、18か月毎に倍になり、いずれ有線回線と同じスピードに収束する」というものです。 2030年には、この3つの通信帯域は同じになるだろうと言われています。
現在、携帯各社は、下り100Mbpsの帯域を実現しており、4.5Gと言われるLTE-Advanced Proで、MIMO(multiple-input and multiple-output)がOnになる来年には、下り1Gbpsを超えます。
通信回線の幅(帯域幅)と速度(レイテンシ)が高速化するという事は、当然ながら、サーバの応答速度が重要となります。
今までのWebパフォーマンスは、回線の帯域幅と速度の問題から、ページ容量やコネクション数などを小さくすることがGoogleを中心に提唱されてきました。 しかし、今年の春ぐらいから状況は変わっていて、画像の最適化などは効果が期待できない状態です。
2~3MBのページ容量のWebページであっても、サーバが高速であれば、1秒以内に表示する事が可能になっています。
当然ながら、HTML、CSS、JSのminifyなどは意味がありません。ファイルをgzip圧縮して容量を減らし配信する事は、高速化の効果がなくなりつつあります。
(※)追記
この件が疑問に思われる方がいらっしゃったので、説明します。
通信回線をエスカレーターとして考えてみて下さい。(自分で歩いて降りたり、登ったりは禁止です)データの流れはレイテンシ×帯域幅で決まります。 だからエスカレーターです。 狭い幅のエスカレーターば、2人しか並べないですが、広い幅のエスカレーターは4人並べます。 幅が広いエスカレーター(帯域が広がった)であれば、そこに2人乗っても、3人乗っても、4人乗っても、上の階、下の階に到達する時間は変わらないのと同じです。
変わるボトルネック箇所
通信環境の変化に伴い、ボトルネック箇所は変わりました。 まず、TCP Slow Startの影響自体は変わらないので、最初の100~200msぐらいで100KB超の画像やCSS、JavaScriptなどのファイルを配信すると、TCPのWindowサイズが小さいので、そこは遅延します。 しかし、200~300ms以降は、十分にWindowサイズが大きくなっているので、ボトルネックとなりません。
Above the fold(日本ではファーストビューと言われる)の部分に大きな画像を持ってくる場合は、ある程度、テクニックが必要ですが、高速なCDNであれば、それすら気にする必要はないです。
では、どこにボトルネックが移ったのでしょうか?
Webパフォーマンス計測では、「待機時間」が短縮できる時間、ボトルネックと判断します。
多くの場合、この赤い部分は、サーバのリソースに依存します。 CPU、メモリ、記憶領域です。
特に記憶領域です。
HDD、SSD、M.2のどれを使っているのかで、相当違います。
上記の記事では、これらの4つをディスクパフォーマンス計測の定番であるCrystalDiskMarkで計測して比較しています。
ここで、クラウドやCDNの使っているサーバの世代やクラスでの性能差が出てくるのです。
だからこそ、ベアメタルへの回帰なのです。
仮想マシンベースでのシステム構築では、現在の高速化した通信回線を活かしきれないのです。
画像が「遅延」する本当の理由
画像が遅延する場合、計測して、待機時間が長いのか、読込時間が長いのかによって、原因が推測できます。
待機時間が長い場合は、主にサーバでのファイル探査の時間が長いか、CPUの割込処理やコンテキストスイッチの増大が考えられます。 読込時間が長い場合は、ネットワーク距離が短い場合には、ディスクI/Oの遅延が考えられます。
いずれにせよ、「容量」そのものではないです。
だからと言って、数十MBの画像をどんどん使って良いと言ってるわけではありません。 容量自体は、確かに重要なのですが、数MB程度であれば、サーバがしっかりしていれば、ボトルネック要因とはなりません。
画像の容量の最適化は、配信側・ユーザ側の通信費の節約のために重要で、パフォーマンスよりコストの視点に移ったと考えるべきです。
画像の非同期デコーディング
画像周りで重要な変更がHTMLの仕様で入りました。 decodingという属性です。
<img class="abc" src="./images/hoge.jpg" decoding="async" alt="Hoge">
というように指定すると、画像の非同期デコーディングとなり、表示完了までの時間が高速化されます。 JavaScriptベースのLazyLoadを使う必要が無くなります。
LazyLoadのJavaScriptの読込・コンパイル・実行時間も減らせるのでお勧めです。
Mobile Edge ComputingからMulti-access Edge Computingへ
5Gが2019年に前倒しでサービス開始となるようですが、Mobile Edge Computingは、Multi-access Edge Computingへと名称が変わりました。
Edge側に計算能力を持たせて処理させるEdge Computingは、携帯網だけでなく、WiFi機器の設置場所のサーバであったり、CDNのEdge Server上でも計算能力を持たせるなど多様化し、Multi-access Edge Computingと名称が変わったわけです。 携帯網の側は、まだ具体的なサービス開始に至っていませんが、CDNでは、いくつかサービスが開始されています。
MECは、IoTの分野で注目されていますが、Webにも大きなインパクトを齎します。 MECの利用については、分散コンピューティングの実装が必須なわけですが、最初は、簡単に実装できるようにPaaSとしてAPIベースでのサービス開始となるでしょう。 その次に、第二のIaaSとして素のEdge側のコンピューティング環境が提供されるようになるでしょう。
レスポンス時間が数ミリ秒の世界へと大幅に短縮されるため、インタラクティブ性が向上し、アイディア次第で、よりダイナミックなアプリケーションやWebサイトを作る事が可能になります。
分散コンピューティングというと小難しく感じるでしょうが、サーバが必要とする最終データを送るまでの前処理のロジックをEdge側に持っていくというアプローチから始めると良いでしょう。 また、P2P技術を応用して、スーパーノード型P2Pのスーパーノードの機能をEdge側に実装することで、物理的なロケーションベースでのスーパーノードとの接続となり、高速で安定したサービス運用が可能となります。
2020年改正民法債権法施行まであと1年
2020年改正民法債権法施行まで、あと1年となりました。 品質検査・品質保証が契約の前提となっているので、経産省・IPAを中心に、非機能要求に関するモデル化が進められています。
システムの品質の不透明性、それに起因する低品質さは、以前より日本市場の問題であり、世界に進出しても勝てない要因でもありました。
経済産業省は、「産業構造・市場取引の可視化」として、システム品質の可視化に取り組んでいます。
今年は、「非機能要求グレード2018」が公開されました。
法律が変わるということは、当然、契約書も変わるわけで、経産省では、契約書モデルも公開しています。
今までは、請負契約が主流でしたが、今後は、実際の開発以外は準委任契約が主流となります。
準委任契約という言葉に馴染みが無い方のために説明します。 準委任契約とは、依頼者に成り代わって、代理人として、委任された行為を行う契約です。 報酬は、代理人として働くと約束した時間分となり、納品ベースではなくなります。
どうして、開発フェーズ以外は準委任契約となったのでしょうか?
それは、請負契約で必須となる要件や仕様を定めるという事が、高度になりすぎて、一般の顧客にはできない作業になったからです。 そうであるならば、要件定義や設計、テストや検収、運用、保守などは、「プロフェッショナル」である業者が代理人として、専門知識を駆使してやってあげる方が理に適っています。
準委任契約は、納品の義務を負わず、時間ベースでの報酬となりますが、「善管注意義務」(善良な管理者の注意義務)を負います。
つまり、お客様から言われた事をきちんとやるというレベルではなく、プロフェッショナルとしての責務を果たせ、という義務なのです。 ですから、従来の瑕疵担保責任より重い責任になります。 その一方で、納品しないと支払ってもらえないというわけではないので、お客様から無理難題な仕様を求められてもプロの観点から却下できますし、時間が掛かれば掛かっただけ、代金を請求できます。
「そもそも要求仕様が、パフォーマンスが出ないようなものなのに、それでどうやって品質保証しろっていうんだ?」という問題は、設計フェーズが準委任契約になる事で、設計段階で非機能要求がプロの観点で設計される事で解決されるわけです。 もちろん、その設計そのものがパフォーマンスが出ないものであれば、「善管注意義務」違反となり、設計者は責任を負う事になります。
SLAの提示が必須に
売買においても、品質保証は必須となるため、各種Webサービスや、CDNは、SLAの提示が必須となります。 また、そのSLAが達成できているかどうかを証明するため、定常計測が必須となります。
単に計測すればいいというわけではなく、裁判になったときに、証拠として使えるレベルのデータの品質が保証されなければなりません。 だから、商用の計測サービスなのです。
自社で計測システムを立ち上げたり、無料の計測サービスを使っていると、いざ裁判になった場合に、データの信頼性の保証が難しいです。 値がどうして正しいと言えるのか、統計分析の観点から証明しないといけないです。 しかし商用サービスを使えば、その責任は全て、計測サービス事業者に負担させることができます。
仕事で、CDN業者や、各種Webサービス、インフラ事業者と、お客様の代理人として折衝して、パフォーマンスの遅延原因が彼らにあることを伝える事がちょくちょくあります。 しかし、品質管理で重要な統計学の知識が欠如していますし、品質管理のデータの取得の仕方を知らないので、自分たちの独自な方法で計測したデータを持ってきて、自分たちは遅くないと主張します。 ですから、毎回、どうして、その方法の計測ではダメなのかを、一から説明しています。
「このデータはどうして正しいと言えるのか」
これをちゃんと考えると、計測することが、どれだけ難しい事であるのか、徐々に理解できると思います。
海外では、自前で計測するのではなく、商用サービスを利用することで、「ものさし」が統一されますから、話が速いのです。 大企業の間では、殆どの有名なところは、Catchpointを計測サービスとして使っているため、パフォーマンスの問題が生じても話が速いです。 ユーザ企業だけではなく、データセンター、回線、CDNなど、プラットフォームを提供している企業もCatchpointで計測しているため、Catchpointのデータの信頼性の話はすっ飛ばして、企業の垣根や立場を超えて、関係者同士が遅延要因の対策について、データに基づいた話ができるのです。
非機能要求としてのWebパフォーマンス
品質保証は面倒かもしれません。 しかし、品質が保証されない市場は、発展しません。 受注金額も下がる一方でしょう。
品質が信用できなければ、顧客はお金を払う事をためらうでしょう。
今、IT、特にWeb業界が直面している問題は、品質が担保されていない事なのです。
Webパフォーマンスを改善すれば、機会損失が最小化され、売上が向上します。
「安かろう悪かろう」から、「高い分だけ高品質」へと社会全体がシフトしなければ、低迷する日本経済を盛り上げることはできないです。 製造業での品質に関する問題の報道が最近多いですが、品質を追求したからこそ、日本は世界市場に乗り出す事ができて、経済大国になれたという事を忘れてはいけません。 Web制作に携わっていて「お給料が上がらないなぁ…」と悩んでいるのであれば、それは品質に問題があるからかもしれません。
追記
「img decoding="async"は、Safariは対応してない」って言う方が多いんですが、deveoper.mozzila.org
の表で確認してのそのように理解されているのでしょう。
実は、46で対応してます。
追記2 (2019-12-10)
Kiteさんに、Safariがdecoding="async"に対応していると書いているのは間違いだとご指摘を受けました。
残念ながら、Safari Technology Preview というのは Mac や iPhone などに標準でインストールされている Safari ではなく、一般配布前の新機能をいち早く試せるいわゆる Nightly 版のようなものです。間違っている部分を残したまま、早めに記事を修正されたほうがよろしいかと思います。
残念ながら、Safari Technology Preview というのは Mac や iPhone などに標準でインストールされている Safari ではなく、一般配布前の新機能をいち早く試せるいわゆる Nightly 版のようなものです。間違っている部分を残したまま、早めに記事を修正されたほうがよろしいかと思います。
— 𝐊𝐢𝐭𝐞 (@ixkaito) 2019年12月9日
失礼しました。オフィシャルアナウンスメントの方を参照として出すべきでした。 お詫びいたします。