ja en en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja en zh ja en ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja fr ja ja ja ja ja ja en en ja ja en ja ja ja ja ja ja ja ja ja zh ja en en ja ja zh ja zh zh zh ja zh zh zh ja zh ja zh ja zh zh zh zh zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja zh ja ja ja ja ja zh ja ja zh zh ja ja ja ja ja zh ja ja ja ja en en ja ja ja en ja
運、 緯度、 レモン ? Indeed の低レイテンシなデータセンターの見つけ方 - Indeed エンジニアリング・ブログ
既に発表された研究 ( これやこれ ) のように、私たちが内部で持つ数値データも、速さの効能を立証しています。
単一のデータセンターでプロダクトを実行していて、物理的な近さが有益なこともあります。この場合、移動 (引っ越し) は選択肢にはありません。おそらく、キャッシュ化を行うか、静的資源に CDN を使用します。
物理的に、データセンターが顧客サイトのユーザーのどんなに近くだとしても、もしユーザーの ISP が自社で所有する施設への専用ファイバーを持っていて、ニュージャージー経由でニューヨークに接続する方がその ISP にとって安いのであれば、おそらくそうするでしょう。
そうして数か所のデータセンター内に、テストサーバーを設定しました。テストサーバーに、できるだけ多くの場所から ping を送り、その結果を元々のデータセンターの ping にかかる時間と比較しました。
そうして、エンジニアリング・マネージャーとの廊下での何気ないやりとりから、今日私たちが使用しているメソッドに雪だるま式に発展しました。
本物のユーザーリクエストを使用して、可能性のある新しいロケーションをテストすることが重要でした。
なんにせよ、ユーザがどのようにデータセンターを感じるかということについて、同じユーザを使うことに勝る手段はありません。
数度に亘る議論の末、そして、開発  (Dev)  と運用 (Ops) の仕事の末、フルーツテストを私たちは生み出しました。
これは、フルーツを基にしたテストサーバーのホスト名にちなんで名付けられました。
このテクニックを使用して、提案されていた新しいデータセンターは、ほとんどの西海岸の求職者のレスポンスタイムから平均し 30ms 削れると私たちは予想しました。
全てのフットプリントを新しい施設に移行した後、私たちはこの数字が正しかったことを確認しました。
まず、使用できる可能性のありそうなデータセンターが、対象になるかを調査しました。
スペースやコストのせいで不適切な環境に対して、テストを実行するのは無意味です。
そのハードルをクリアした後には、軽量な Linux のシステムと Web サーバーを設定します。
この Web サーバーは、 lemon.indeed.com のように、フルーツにちなんだ名前を持つ仮想ホストを一つもっています。
その仮想ホストが 0.js、1.js、というように最大 9.js まで名付けられた 10 件の静的な JavaScript ファイルを配信できるように設定します。
サーバーが準備でき次第、 Proctor 内にテスト・マトリックスを設定します。 Proctor は自社開発したオープンソースの A/B テスト・フレームワークです。
各テストバケットに、フルーツとパーセンテージを割り当てます。それからサイトへの各リクエストは、パーセンテージに基づいてランダムにテストバケットの一つに割り当てられます。
各フルーツは、 (新規、既存のどちらにせよ) テスト中のデータセンターに対応します。
テスト・マトリックスを本番環境にパブリッシュしたら、ここからは楽しい工程が待っています!
図 1:フルーツテストのリクエスト、応答、ログ
サイトはクライアントにフルーツテスト実行を指示。
0.js のリクエストと応答が dcDNSCallback を呼出。
dcDNSCallback が 0.js のリクエストのレイテンシーをサイトに送信。
[1-9].js のリクエストと応答が dcPingCallback を呼出。
dcPingCallback が [1-9].js のリクエストのレイテンシーをサイトに送信。
テストバケット内のリクエストは JavaScriptを受信します。その JavaScript は、ブラウザに対して、タイマーを開始し、選択したフルーツのサイトから 0.js のファイルを読み込むように指示します。このファイルは空のコメントと dcDNSCallback の関数を呼び出す指示を含みます。 lemon.indeed.com では “l” を渡して、テストフルーツを示します。
/* */ dcDnsCallback("l");
その後、dcDnsCallback が以前のタイマーを停止し、 indeed.com にリクエストを送信します。
これは、測定したリクエストのレイテンシをログします。
dcDnsCallback の関数は2つの目的があります。
ユーザーのシステムは DNS キャッシュの中にフルーツのホスト名の IP アドレスをおそらく持たないので、 DNS 解決と、一回のリクエストの応答にどれくらいの時間がかかるのか、わかるのです。
それから、このセッション内でのそのフルーツホストへの後続のリクエストは、 DNS の解決にほとんど時間がかからないので、応答時間を計った結果がより正確になります。
dcDnsCallback の呼び出し後、テストは9個の静的な JavaScript ファイルをランダムに選び、同じ手順 (タイマーを開始、ファイルを取得、ファイル内で関数の実行) を繰り返します。これらのファイルは以下のような内容になっています。
/* 3firaei1udgihufif5ly7zbsqyz59ghisb13u1j26tkffr7h67ppywg12lfkg7ortt5t3xoq5 */ dcPingCallback("l");
これら 9件のファイル (1.js から 9.js) は基本的に、 0.js と同じですが、 dcPingCallback の関数を代わりに呼び出し、全体の応答の長さを定義済みのサイズに調整するコメントを含みます。
1.js は最小で、たったの 26B ですが、 9.js は重く、 50KB もあります。
異なるサイズのファイルを持つ事で、レイテンシが低いけれど、利用可能な帯域幅が限定されるため、大きなファイルには不釣り合いに時間を食うデータセンターを調査しやすくなりました。
また、これは帯域幅が充分広いため、処理という観点では、処理開始時の TCP 接続の確立に一番時間がかかるようなデータセンターを識別してくれます。
dcPingCallback の関数が実行されるとすぐに、タイマーは止められ、フルーツ、 JavaScript のファイル名、読み込みにかかった時間の情報は、 Indeed に送られ、ログされます。
これらのリクエストは、表示されたブラウザのページの末尾におかれ、ユーザー・エクスペリエンスにおいて、テストの影響を最小限にするため、非同期で実行されます。
indeed.com において、ログを取るエンドポイントはこのデータを受信し、ソースの IP アドレスとユーザーが見ているサイトを記録します。
それから、 Logrepo と Indeed で呼んでいる (ええ、謎な名前ですよね)  特別な形式になったログストアに、その情報を書き込みます。Logrepo のログを集めた後、 Imhotep を使用しインデックスを作ります。これはクエリや、グラフ作成を楽にしてくれます。
テストの性質により、私たちはフルーツテストを数週間実行し、本物の求職者から何十万、果ては何百万とサンプルを集め、情報に基づいた意思決定を行えるようにします。
テストが終了したら、 Proctor のテストをオフにし、フルーツテストのサーバーをシャットダウンしてしまうだけで終わりです!他にインフラ的な変更は不要です。
このアプローチの良い点は、他のタイプのテストにも柔軟なところです。
もちろん、新規のデータセンターの所在地をテストする際に主に使用しますが、もしこのアプローチを重要な部分に煮詰めると (まさにフルーツジャムと一緒!)、テストのすることといえば、決められた量のデータのセットを、ランダムなユーザーのサンプルからダウンロードし、かかった時間を教えてくれることです。
この結果を解釈するのは、テストのデザイナー次第です。
データセンターのテストをする他にも、2つの異なるキャッシュ技術をテストしたり、異なるバージョンのウェブや、アプリのサーバーの性能の違いをテストしたり、または、  Anycast/BGP IP の地理的な分散 (過去に実施済) を調べることができます。
サンプルのサイズが、統計的に充分多様であれば、有効な比較が可能ですし、最適な人々、つまりユーザーの視点から、それを得ることが出来るのです。
いいけど、なんでフルーツテスト?
現行の、それから今後使用する可能性のあるデータセンターの所在地を表す、ユニークな名前を考えた際、私たちが考えたのは以下の様な名前でした。
運用 (Operations) チームが簡単に識別できること
ユーザーには曖昧で、かつ、あまりミステリアスすぎないこと
ビジネス上で意味をもたないこと
アルファベットの文字に対して異なるフルーツを考えるのは非常に簡単だったので、デザインをする中でプレースホルダとしてフルーツを使用しました。そして、デザインを進めていくにつれ愛着が湧き、結果採用した、というわけです。
チケットを開いて、ナツメ、マルメロ (筆者のお気に入り)、エルダーベリーのテストを有効にするのは、味のある作業です!
データを山ほど集めたところで、がんがんグラフにしていきます!
そんなわけで、フルーツテストのシリーズ第二弾に続きます。
« Indeed SF エンジニアリング・オフィス:
600%の成長を遂げた2015年 Status:堅牢なシステム・ヘルスチェックのための Java ライブラリ »
@ Indeed テックトーク
Indeedのオープンソースプロジェクト»
Indeed ユニバーシティ»
エンジニア採用 @ Indeed Tokyo
Indeedの採用情報を全て見る
CPU スロットリング 2
Uncategorized 1
エンジニアリング 27
エンジニアリング文化 25
データサイエンス 13
Toggle More
2022年4月 (2)
2022年2月 (1)
2021年6月 (1)
2021年3月 (1)
2021年2月 (1)
2020年12月 (1)
2020年11月 (1)
2020年10月 (1)
2020年9月 (1)
2020年8月 (1)
2020年7月 (1)
2020年3月 (1)
2020年1月 (2)
2019年12月 (2)
2019年11月 (1)
2019年10月 (1)
2019年9月 (3)
2019年8月 (3)
2019年7月 (2)
2019年3月 (1)
2019年2月 (1)
2018年12月 (6)
2018年11月 (1)
2018年10月 (5)
2018年9月 (1)
2018年6月 (2)
2018年4月 (1)
2018年2月 (1)
2018年1月 (1)
2017年12月 (2)
2017年11月 (5)
2017年6月 (2)
2017年3月 (1)
2017年1月 (1)
2016年12月 (1)
2016年10月 (1)
2016年9月 (1)
2016年3月 (2)
2016年2月 (1)
2015年12月 (2)
2015年9月 (1)
2015年7月 (1)
2015年3月 (2)
2015年2月 (1)
2015年1月 (2)
2014年12月 (1)
2014年11月 (1)
2014年10月 (1)
2014年9月 (1)
2014年8月 (1)
2014年6月 (1)
2014年4月 (1)
2014年2月 (2)
2013年12月 (1)
2013年10月 (2)
2013年9月 (1)
2013年8月 (1)
2013年3月 (2)
2013年2月 (2)
2012年12月 (1)
2012年11月 (2)
Toggle More
Back to top
©2022 Indeed - Cookies, Privacy and Terms of Service