2020.12.09

リクルートでのWeb Issue調査の取り組み

林仁

前口上

こんにちは。RECRUIT Job for Student 2020（通称、夏バイト）に参加していた、しにゃいと申します！この記事では、期間中携わったリクルートで行われている web issueの追従、調査の取り組みについて書いていきます。

またこの記事はリクルートエンジニアアドベントカレンダーの3日目の記事です。

自己紹介

しにゃいと申します。(Twitter: @Shinyaigeek, GitHub: @Shinyaigeek )

普段はWeb フロントエンドを触る機会が多く、特にWeb パフォーマンスを改善することや、ASTをイジイジして開発者体験を向上することが好きです。

昨年リクルートが主催したスピードハッカソンに参加したのですが、そこでリクルートのエンジニアの方々と交流し、こんな人たちと働いてみたいと感じリクルートの夏バイトに参加しました。

夏バイトではASG(Application Solution Group)という、アプリケーション開発における技術支援やR&D、育成に取り組むチームに配属されました。

攻めのブラウザ仕様変更対応

リクルートでは、ユーザーが触れるフィールド環境での不具合や脆弱性を未然に防ぐために Web Browser の仕様変更を追従し、サービスに影響が出そうかを調査しています。

問題意識の共有

リクルートでなぜWeb Issueの追従、調査が行われているのか、根底にある問題意識について共有させていただきます。

Chrome 76から, imgタグのloading属性がデフォルトサポートされるようになりました。当初は loading 属性のデフォルト値として auto が取られていました。これによって loading 属性を指定していない画像でも画面上に見えるようになって初めて画像を読み込む、というのをJSなしでHTMLだけで実装できるようになりました。

これにより画像の読み込みタイミングが変わるため、canary 版に flag 付きで ship された際に影響の調査を行ったところ、リクルートのサービスで画像が表示されないものがあると確認されました。

では、なぜこのようなことが起こったのでしょうか。

これらのサービスでは、loading属性がサポートされる前からJavaScriptによって画像の読み込みを制御していました。

ページがロードされて最初は画像を表示せず読み込みだけして、読み込みが終了したら画像を表示するということをしていました。

詳しい実装は以下になります。

<img data-src="https://nanikanogazounourl.img" style="display:none;" id="img" />
<script>
  const img = document.getElementById("img");
  img.addEventListener("load", () => {img.style = "display: block;";}
  img.src = img.getAttribute("data-src")
</script>

const img = document.getElementById("img");

img.addEventListener("load", () => {img.style = "display: block;";}

img.src = img.getAttribute("data-src")

</script>

CodeSandbox
https://codesandbox.io/s/elated-goldstine-giecg?file=/index.html

loading属性がサポートされるようになると、前述の通りloading属性は実装当初はデフォルト値としてautoを取っていたので、画像が見えるようになるまで読み込みが開始されなくなります。

自前で実装したJavaScriptによる読み込みの制御と、ネイティブのloading属性による読み込みの制御が合わさると、自前で実装した読み込みの制御によって、最初にimg要素そのものが表示されなくなっています。自前で実装した読み込みの制御だと、読み込みが終了してから画像が表示されるようになるわけですが、ネイティブの読み込みの制御によって画像が表示されるようになるまで読み込みが始まらないため、結果として画像が読み込まれないままとなってしまい障害として現れかねない状況でした。

こうしたブラウザの仕様変更によって新たに生じる障害や脆弱性のリスクを、それがshipされる前に防ぎたいという問題意識があります。

Web Issueの検知

Chrome, Safari, Firefoxといったブラウザの仕様変更についての情報や、SSL/TLS周りの情報、webの最新動向が掲載されている記事のRSSを購読しslackに流しています。

購読しているものとしては, Chromium BlogやGoogle Developers Blog、Let’s Encryptなどが挙げられます。

Web Issueの調査

ブラウザの変更が検知された際に、サービスの担当者や社内に報告すべきかどうかを以下の三つの軸を用いて評価します。

深刻度
影響範囲
期限

深刻度とは、サービスに対してどれほどの影響が出てユーザーがどれほどの不利益を被るか、というものです。例えばサイトに繋がらないレベルのものであれば深刻度がかなり高く見積もられますし、逆に軽微なレイアウト崩れや、些細な機能が使えなくなるといった問題は深刻度が小さく見積もられることになります。

また、影響範囲とはその障害がどれほどのユーザーに影響を与えるかという指標です。例えばChromeを使っているユーザー全員に影響が出るとなれば大きな影響範囲となります。

最後に期限とは、その変更がいつshipされるか、そしていつまでに対応すべきかという指標になります。

Web Issueの共有

Web issueを調査しそれがリスクがあるとされれば、稼働中のサービスで影響が出る前に対応するためにその問題の詳細や対応を社内へと共有します。

先ほど挙げた3つの軸の評価によって、誰に共有するかや、どのように共有するかを変えています。

Heavy Ad Intervention

ここでは、Heavy Ad Interventionを例にとって、検知 -> 調査 -> 共有の流れを見てみましょう。

SlackでRSSからHeavy Ad Interventionについての記述が流れてきました。

まずchrome platform statusでの、Heavy Ad Interventionの記述を見てましょう。

Chrome will unload ad iframes that use an egregious amount of CPU or network bandwidth.

An ad will be subject to unload if it has not received a user gesture and:
* Used the main thread for more than 60 seconds total
* Used the main thread for more than 15 seconds in any 30 second window (50% utilization over 30 seconds)
* Used more than 4 megabytes of network bandwidth to load resources

簡単に訳すと, ChromeはCPUを著しく利用する、あるいはネットワークの帯域幅を多く取る、平たくいうと "重たい広告" を読み込まないとする変更です。

その閾値は以下の三つとされています。

メインスレッドを60秒以上利用する
メインスレッドを30秒中半分利用する
広告リソースを読み込む際のネットワークにおける帯域幅が4MB以上

これを元に深刻度、影響範囲、対応期限の三つの軸でこのissueを評価してみます。

Heavy Ad Intervention の対象になると広告が表示されなくなってしまいますが、リクルートが出している広告の中で該当するような広告は少ないと考え、深刻度は低いと判断しました。

影響範囲については、Chromeを使っているユーザー全てに適用されます。影響範囲はかなり広いといえます。

対応期限については、すでに対応版Chromeが8月に安定版でリリースされていることを考えると、なるべく早く対応したいです。

これらを踏まえると深刻度は低いとしましたが、影響範囲の広さともし仮にリクルートが出している広告の中でHeavy Ad Interventionの対象になるようなものがあれば、広告の効果がいっさい出なくなると考え、担当者に共有する対応としました。

今後の展望

あるweb issueについて具体的にどのサービスに影響が出そうかといった判断については、リクルートが運営するサービスの数が一個人が把握しきれないほど多く、暗黙知となっている部分もまだまだあり、結果としてWeb Issueの調査に人手と時間がかかってしまっているのが現状です。

今後、静的解析などで自動化できる部分は自動化を進めていってこうしたコストを下げていきたいです。

終わりに

最後に、リクルートでアルバイトした感想を述べたいと思います。

アルバイトで得られたものとして技術的な成長ももちろんあるのですが、個人的には技術者として今後生きていく上での人生の道が定まり、道を歩む速度が上がったことを挙げたいです。

アルバイト生に対してでも、個人の意思や対話の機会を尊重してくださり、今後何をやっていきたいのか考える機会になりました。

自分が今から歩んでいくエンジニアキャリアの先にいる先輩方と、業務を超えてコミュニケーションをとる機会も多く、自分の道に先があることを実感し勇気付けられましたし、リクルートの社員の皆さんの学ぶ意欲、学ぶ姿勢を目の当たりにし良い刺激を受けられました。

こんな素敵な環境で働いてみたいという方は、リクルートのアルバイトに申し込んでみてください！

現場で関わってくださった社員の皆さん、ありがとうございました！

Recruit Tech Blog

タグから見つける