写真：Kevin Ku （Unsplashから転載）

Indeed には、毎月3,000万件以上の新着求人が追加され、毎月2.5億人以上もの求職者が応募先の採用企業とつながっています。ユーザーがいつでも利用でき、すばやく拡張性がある Indeed のサービスは、どのように実現されているのでしょうか。その裏には、Site Reliability Engineering（SRE）チームの絶え間ない努力があります。

SREとは？

SREを一言でいうと「企業のコアインフラストラクチャーチームが効果的に運用されるよう支援するチーム」です。2003年、Googleが信頼性の問題に対応するために立ち上げた小規模なプロダクションエンジニアリングチームに端を発するSREは、もともとは、呼び出し対応やモニタリング、パイプラインのリリースなど運用に関する業務が主な職務でした。このチームが、企業全体のインフラを改善するためにサービスレベル指標（SLI）とサービスレベル目標（SLO）を作成しています。これが他の企業でも採用され始め、SREは業界基準となりました。

SREの職務は、他のエンジニアリングの職務とは異なります。チームメンバーは複数の事業分野を管轄し、ソフトウェアエンジニアリング（SWE）チームが構築したサービスの拡張性やパフォーマンス、レジリエンスの維持にあたります。また、プラットフォームチームと協力し、Kubernetesなどのインフラストラクチャーの管理や監視を行います。運用チームのプロセスを自動化するためのフレームワークを構築したり、ネットワークエンジニアチームのために、DNSや負荷分散、サービス接続を処理するアプリケーションを構築することもあります。

このようなSREの機能は、企業が今日のデジタル社会で生き残るために不可欠ですが、利用できるテクノロジーや方法が多岐にわたるため、SREのアプローチもチームによってさまざまです。

Indeed におけるSRE

Indeed では、信頼性の目標への取り組みを強化し、プロダクト開発チームが提供する価値を最適化するため、2017年にSREチームを立ち上げました。Indeed のSREチームは、各チームメンバーがそれぞれの担当部署を支援する、「エンベデッド」と呼ばれる方式で働いています。重要プロセスを自動化し、エンジニアの作業負荷を減らすため、その部署に合ったソリューションのプログラミングを行っています。

Indeed のSREチームの主な目標は次のとおりです。

信頼性を高めるベストプラクティスの推進：SREは、プロダクトチームがSLO、SLIなどの指標やエラーバジェットの方針を採用し、イテレーションを行うのをサポートします。IaC（Infrastructure as Code）モデルを推進し、データセンターやSLOなどのアセット管理を自動化するためのコードを作成します。また、Indeed におけるAWSへのプロダクト移行など、信頼性とスピードを改善するための重要なイニシアチブを実行します。

信頼性に関するロードマップの作成：Indeed のSREチームは、50％以上のリソースを、ロードマップを作成するための戦略的業務に使っています。具体的には、インフラストラクチャーの分析やシステムの再構築、新たなテクノロジーへの切り替え、新たなツールの構築などを実施するため、新しいプラクティスの導入方法やタイミングを見極めるための取り組みを行っています。プロダクトチームが提案を承認すると、SREが必要なコード変更のデザインや実装を支援します。

運用効率の最大化：SREはプロダクトチームと協力し、運用上の課題を特定して、より効率的なツールを構築します。プロダクトチームの振り返りにも貢献し、クリティカルインシデントへの対応や学びを深めるプロセスも支援しています。また、インシデント分析の専門知識を持ち、チームがインシデントのパターンを特定し、Indeed 全域の改善スピードを向上するのに役立っています。

Indeed のSREを支えるメンバーたち

Indeed のSREチームは、世界各国の多様なメンバーで構成されています。メンバーの数名に、Indeed のSREチームの一員となるまでのキャリアについて聞いてみました。

Ted（Staff SRE）

プログラミングが大好きなので、コンピューターサイエンスを専攻してソフトウェアエンジニアになりました。ソフトウェアエンジニアとしてキャリアを積むうちに、例えば、どうすればシステムをクラウドに移行してコストを最小化できるか、どうすればレガシーサービスを複数のマシンに拡張できるか、サービスが意図されたとおりに動作していることを確認するには、どの指標をどれくらいの頻度で集めるべきか、などといった、インフラストラクチャー関連の課題に興味を持つようになりました。

その後、こういった問題がSWEとSREに関連していることに気づきました。それまで勤務してきたすべての企業で、SREの手法を無意識のうちに実施していたのです。そこで、Indeed の求人に応募することにしました。SREの文化が定着している Indeed なら、教えるだけではなく学ぶことができると考えたからです。

Indeed のSREチームでは、SWEとして働いていた頃に比べて、自分が取り組みたいことをより自由に決めることができます。大規模な障害の管理、社内ツールの構築、信頼性と拡張性の改善、廃止済みのインフラストラクチャーのクリーンアップ、新規プラットフォームへのシステムの移行など、幅広い選択肢があります。また自分の仕事が与えるインパクトも幅広く、複数のプログラミング言語で書かれた20以上のレポジトリの拡張性を一度に改善したり、1週間で新たな環境に移行することができます。SREを通して、コンテナオーケストレーションツールからフロントエンドのアプリケーションまで、サービスが物理的に管理されている方法について知識を深めることができ、エンジニアとして大きく成長することができていると実感しています。

Jessica（Senior SRE）

Indeed に入社するまでに、QA、フルスタックエンジニア、バックエンドエンジニアなど多くの職務を経験しましたが、その中で特に興味があるのは、自分で問題を特定しそれを修正することだと気づきました。機能の一部を生み出す役割に徹するのではなく、顧客とコミュニケーションを図り、気持ちを共有したいと思いました。そしてそれをきっかけに、オペレーションやインフラストラクチャー、信頼性に関する職務を積極的に探すようになり、SREの仕事にたどり着きました。

今は、役割ベースの認証コントロール（RBAC）サービスをクライアントに提供するチームをサポートしています。Indeed の採用企業向けサービスはすべて、RBACソリューションを利用して、ユーザーがアクションを実行する権限があるかどうかを判断しています。このサービスに問題が生じるとクライアントの採用プロセスに影響してしまうため、素早く一貫したレスポンスを提供する必要があります。

SREチームで働く一番のメリットは、レベルが高いエンジニアの仲間とチームで働けることです。ソフトウェアエンジニアがあまり遭遇することのない難問に、力を合わせて挑んでいます。さまざまな知識を学び合い、仲間をサポートできることをうれしく思っています。

Xiaoyun（Senior SRE Manager）

2015年にSWEとして Indeed に入社し、その後SWEマネージャーになりました。最初はプロダクト機能を担当していましたが、次第にエンジニア業務に対する熱意が高まってきました。cronのジョブを数時間から数分で実行できるようにするなど、サービスのパフォーマンス改善から始め、プロセスログのストリーミングを実行できるツールや、クエリのレイテンシを改善できるデータベース技術などに取り組むようになりました。

その後、Indeed にそのような分野を専門に扱うSREの職種があることを知り、特にSRE業務の幅広さと奥深さに魅力を感じました。SREチームのメンバーとなってからは、Indeed 全域のさまざまな技術やサービス、インフラストラクチャーに携わり、KafkaやHadoopなどの技術についても深く学ぶことができました。これまでにチームとして、複雑なAWS管理サービスにおける問題の診断と解決にあたり、成果を上げています。

また、信頼性を重視したコードを書くことも Indeed のSREの仕事です。SWE出身なので、そのスキルを活かして楽しくコード作成に取り組んでいます。

Yusuke（Staff SRE）

2018年に新卒で Indeed に入社しました。学校ではコンピューターサイエンスを専攻し、多くのコーディングに取り組むとともに、インフラストラクチャーやWebフロントエンド、モバイルアプリなどを学びました。幅広い技術を習得するうちに、SWEよりもSREのキャリアの方が、学んだスキルを活かすことができるのではないかと考えるようになりました。

入社後は、Indeed の求人検索用のプラットフォームを構築するバックエンドチームの担当になりました。まず、SLIとSLOを定義し、これらの指標のモニターを設置し、キャパシティを計画するための定期的なプロセスを策定しました。その次に、信頼性とパフォーマンスの向上のため求人処理システムを再構築し、レジリエンスのより高いツールで導入プロセスを改善しました。また、クラウドネイティブ技術の採用と、アプリケーションのクラウドへの移行をサポートしました。調査メモの追跡と共有のため、社内ナレッジベースツールの構築も行っています。

さまざまなスキルを活用できるところが、Indeed のSREで働くメリットです。サポート対象であるシステムの性質や規模に合わせて、コーディング、技術、インフラストラクチャーに関する専門知識を提供することができます。SREチームには異なる専門分野をもつメンバーが集まっていて、お互いに助け合いながら問題解決にあたっています。

SREとして働くには

幅広いスキルを身につける

SREはさまざまなシステムを扱うため、技術的なスキルを幅広く習得することが大切です。SWEスキルに加え、基盤となるインフラストラクチャーへの高度な理解も求められます。方針やツールに関して幅広い提案をする仕事のため、新しい技術を学んだり、学びを人に説明する意欲が役に立つ職種です。

広い視野をもつ

SREは、信頼性に関するプラクティスとコアシステムを俯瞰的にとらえる必要があります。共有インフラストラクチャーを担当している場合には、SREの意思決定は企業全体に影響を及ぼすことになります。変更の優先順位を決める際は、影響を受けるシステムが従業員にどう使われているかや、その理由を理解する必要があります。さまざまなチームとの協働は、個人のキャリア開発に役立つので、SREとしてのキャリアアップにつながります。

Indeed で働く

今ソフトウェアエンジニアとして働いている場合、SREへのキャリアチェンジをすることで、サービスを実行するために必要なあらゆる技術と関わることができます。他社のSREチームなどでオペレーション業務に従事している場合でも、幅広いアプローチを採用している Indeed で働くことで、業務の幅が広がります。SREが支援するすべてのチームが、それぞれ固有の信頼性の課題に直面していることから、関心に合わせてプロジェクトを選ぶことが可能です。

Indeed のSREとして働くことは、個人の成長にもつながります。SREの文化は組織にしっかりと定着し、進化を続けています。SWEなど他のメンバーと協力し、互いに学び合いながら働くことができる仕事です。

可能性が広がる、やりがいのある仕事にチャレンジしたい方は、募集中の求人の詳細を今すぐご覧ください。

写真：Jonathan Chng (Unsplash)

この数年、Indeed がユーザー向けWebアプリケーションの読み込み速度が低下していました。私たちは、パフォーマンスを改善するためにさまざまな方法を検証しました。その中には大幅な改善につながる方法もあれば、そうでないものもありました。

読み込み速度は40％向上しましたが、ユーザーエクスペリエンスの観点では、この読み込み速度が必ずしも重要な要因ではないことも学びました。

パフォーマンス指標

次の主な2つの指標を使用して、読み込み速度を測定しました。

• FirstContentfulPaint – ユーザーがそのページの最初のコンテンツを表示したとき。DomContentLoadedEventEnd – – ページがインタラクティブになったとき。クリティカルCSSとJavaScriptがすべて解析され、実行された瞬間に測定されます。

Indeed は、単一の指標ではなく、加重平均指標を採用しました。その結果、感知された読み込み時間を正確に測定することができ、次の重要な2つの疑問の解消につながりました。

• ユーザーにページが表示されるまで、どのくらいの時間がかかったか。
• ユーザーがページを操作できるようになるまで、どのくらいの時間がかかったか。

GoogleのWeb Vitalsではなく上記の指標を採用した理由は、トレードオフが伴うものの、幅広いユーザー層に対応しているためです。この2つの指標を使用したところ、何百ものアプリケーションやさまざまなWebブラウザから、分かりやすく観測可能で、報告価値のあるデータが得られました。

読み込み速度が向上した成功例

さまざまな方法を試しましたが、その中でもパフォーマンスが最も向上したのは次のような方法でした。

早めに <Head/> をフラッシュする

ブラウザのページ読み込み時には、JS、CSS、HTMLファイルといった静的リソースをダウンロードして解析する際に、通常、最も多くのリソースを使用します。この消費リソースを抑えるために、静的コンテンツを早期に送信して、ファイルが必要になる前にブラウザでファイルのダウンロードと解析が開始されるようにしました。その結果、このようなリソースによってレンダリングを妨げる時間を大幅に短縮することができます。

複数のアプリケーションでHTMLのheadタグを早期にフラッシュすることで、読み込み時間が5～10％向上しました。

ただし、この実装にはいくつかのトレードオフが伴います。HTMLドキュメントを複数のチャンクに分けてフラッシュすると、紛らわしいエラーにつながるためです。レスポンスの最初の部分をフラッシュすると、ステータスコードやCookieなどのレスポンスの一部を変更できなくなります。レスポンスの最後の部分よりも前にエラーが発生した場合でも、このヘッダーを変更することはできません。Indeed では、このような複雑な問題を解決するために、一般的なライブラリをいくつか実装しました。

クリティカルパス上のファイルを減らす

合計バイト数とは別に、ページの読み込み時間を短縮する上で重要なのが、クリティカルレンダリングパス上で必要になる合計リソース（特にレンダリングを妨げるリソース）の数があります。一般的に、読み込むファイルの数が増えるほど、ページの読み込み速度は遅くなります。たとえば、10のファイルで100KBのページを表示するよりも、5つのファイルで100KBのページを表示する方が速度は大幅に向上します。

A/Bテストでは、レンダリングを妨げるファイルの数を60％（30から12）削減しました。なお、ページ読み込み時の合計バイト数はほぼ変わりませんでした。このテストでは、デスクトップとモバイルの検索ページにおいて、95パーセンタイルのdomContentLoadedEventEndで2秒以上改善されました。また、largestContentfulPaintでも大幅な改善が見られました。

さらに深く掘り下げるために、CSSファイルを1つ増やした場合の消費リソースを調査しました。トラフィックが最も多いページを対象に、CSSファイルの数を1つ減らすテストを実施したところ、ページの読み込み時間は統計的に有意に短縮され、95パーセンタイルで約15ms（ミリ秒）になりました。

CSS-in-JSのランタイム負荷を抑える

Emotion library上に構築された、最新のコンポーネントライブラリを使用するアプリケーションが増えたことで、ページの読み込み速度が40％低下していることが分かりました。

Emotion libraryは、業界でも話題のCSS-in-JSをサポートしていますが、CSS-in-JSコンポーネントをレンダリングすると、JavaScriptバンドルに余分なバイトが追加されることが分かりました。この新しいレンダリング戦略のランタイム負荷とバイト数の増加が、読み込み速度が低下する原因となっていました。そこで、よく使用されるコンポーネントの多くを事前コンパイルするwebpackプラグインを使用することで、レンダリングによる負荷を削減して、この問題を解決することができました。

この方法によって大幅に改善し、95パーセントタイルで全体で40％だった速度低下が約5％にまで抑えられました。ただし、CSS-in-JSを使用した方法は、従来のレンダリング手法よりもランタイム負荷が高くなりました。

Indeed 側で解消できない要因

改善テストと並行して、ページの読み込み速度に影響を及ぼしているユーザーのターゲット層やロケール、使用デバイスを分析しました。

デバイスの種類やオペレーティングシステム

一般的にiOSよりも消費電力が低いAndroid端末では、firstContentfulPaintの読み込み時間が63％、domContentLoadedEventEndの読み込み時間が107％低下しました。

Windowsユーザーは、iOSユーザーと比較して、domContentLoadedEventEndの読み込み速度が26％低下しました。Windowsデバイスには古いものが多いことから、これはある程度予想通りの結果となりました。

このデータからは、重要な学びがありました。

• 機能とコード追加によるパフォーマンスへの影響は比例していません。新型の安定したデバイスでは、100KBのコードを追加してもパフォーマンスに影響がないのに対し、旧型のデバイスでは読み込み速度が大幅に低下することが分かります。
• パフォーマンスはデバイスやOSの性能によって大きく異なるため、パフォーマンスを理解するには、RUM（リアルユーザーメトリクス）を使用してアプリケーションをテストすることが重要です。

通信方式とネットワーク遅延

私たちは、Network Information APIを使用して、さまざまな接続方式に関する情報を収集しました。このAPIはすべてのブラウザでサポートされているわけではないため、不完全なデータではありますが、注目すべき調査結果が得られました。

• 4Gの接続タイプと比較した場合、読み込み速度は3Gの4倍、2Gの10倍、2G未満の場合は20倍に向上しました。つまり、ネットワーク遅延が全体の遅延に占める割合は非常に大きいと考えられます。
• 通信方式の情報が送信されるブラウザでは、4Gがトラフィック全体の95％を占めています。すべてのタイプのブラウザでは、この割合は50％以下にまで減ります。

ネットワーク速度は国によって大きな差があり、一部の国では、ページの読み込みに20秒以上かかることもあります。地域によっては、サイズの大きい画像や動画などを減らして負荷を軽減することにより、低速なネットワークでも、シンプルかつ高速なユーザーエクスペリエンスを実現できます。

このようにすることでパフォーマンスを簡単に高めることはできますが、複雑さは解消されません。

読み込み速度などの要因によって生じる結果

パフォーマンスがWebに与える影響はさまざまです。Amazonなどの企業の報告によると、わずか1秒の読み込み速度低下が16億ドルの売上損失につながると言われています。一方で、パフォーマンスの影響に対する解釈は曖昧であるといった報告事例もあります。

今回のテストにおいては、パフォーマンスの向上に伴って、エンゲージメントも向上するという結果が出ました。ただし、それがパフォーマンスの向上だけに強く相関しているかどうかは分かりません。

信頼性と読み込み速度

現時点では、このようなエンゲージメントの向上は、読み込み速度の向上ではなく、信頼性の向上に基づくものであると考えています。

静的資産をコンテンツデリバリーネットワーク（CDN）に移行したテストでは、エンゲージメントの向上が見られましたが、同時に信頼性と可用性も向上しました。パフォーマンスは向上しても、信頼性が向上しないテストでは、エンゲージメントにも大幅な向上は見られませんでした。

一度の大幅な向上がもたらす影響

パフォーマンスが1秒以上向上した（信頼性は向上しない）テストでは、主要なパフォーマンス指標（KPI）に大きな変化は見られませんでした。

Indeed のデータによると、商用でないアプリケーションの場合、パフォーマンスが多少変化してもエンゲージメントの大幅な向上にはつながらないことが分かっています。

エンゲージメントとパフォーマンス

今回の調査結果では、指標を分析する際に、パフォーマンスとエンゲージメントを同一視してはならないことが分かりました。明確な例として、モバイルiOSユーザーとモバイルAndroidユーザーのパフォーマンス指標の違いが挙げられます。

Androidユーザーはレンダリング速度がiOSユーザーの半分程度でしたが、iOSユーザーと比較してエンゲージメントの低下は見られませんでした。

読み込み速度が重要な場合

1年間にわたって読み込み速度を改善するための方法を検証した結果、パフォーマンス向上につながる方法がいくつか見つかりました。このような改善は測定可能でしたが、主要なパフォーマンス指標（KPI）に変化をもたらすほどの重要性はありませんでした。

ある程度の読み込み速度は必要ですが、重要な要因はそれだけではありません。ユーザーのデバイスや接続タイプは、ユーザーエクスペリエンス全体において大きな役割を担います。これらすべての要因を完全に制御することはできませんが、読み込み速度の向上を目的として特別に設計されていないアーキテクチャ戦略でも受け入れることができるというメリットもあります。読み込み速度を多少妥協して他の部分を改善することで、ユーザーエクスペリエンス全体の向上につながります。