大規模オンプレミスなヤフーのサーバーインフラの裏側 〜 サーバー調達や運用の流れを紹介します

サイトオペレーション本部の藤見です。
サーバーの調達、運用（*1）を担当しています。

ヤフーはオンプレ環境で大量に物理サーバーを調達・運用しているCSP（*2）のひとつです。
オンプレ環境で物理サーバーの調達・運用はどのようなことをしているかをご紹介したいと思います。

イメージとしては主に下記のような仕事をしています。

ヤフーのサーバーインフラに関わる人たち

はじめに組織の概略について簡単にご紹介します。
下記のように複数のチームで横断的に担当しています。

サーバーインフラというカテゴリーでみても多くのタスクがあります。
今回は「調達」と「運用」の観点でそれぞれどのような事を行っているかご紹介します。

物理サーバーの調達

まず調達についてですが、個別の採用ベンダーなどはお伝えできないので傾向として下記にまとめました。
例外もありますが、おおまかな採用傾向として下記のように推移しています。

ベンダー属性としてOEM系からODM系ベンダーへも同時にシフトしています。
ここのポイントとしてはOEM→ODMへシフトした結果、採用ベンダーもシフトしていったと言えると思います。

主観ですが、OEM系、ODM系の比較を下記にまとめました。

OEM系→ODM系にシフトした背景ですが、1つは 価格競争力 です。
インフラにおいてプライスは重要な指標です。

また昔と今でヤフーのサーバーの買い方に違いがある事もポイントになっています。
昔のヤフーは、いろいろな部門が、いろいろな構成のサーバーを、いろいろなタイミングで購入していました。
この結果、納期面で有利なOEMを第一選択肢としていました。
またいろいろな構成のサーバーが入る事を考慮した結果、自営保守ではカバーしきれない範囲も多く、ベンダーが提供するサポートに依存している部分もありました。

しかし最近では 自社クラウド環境の普及により、決まった部門決まった構成決まったタイミングで購入するように になってきたため、 納期に関して余裕を持ったスケジューリングができるようになりました。
またクラウド環境で利用できるサーバーはかなりハイスペックなため、価格の数％の違いも大きなビジネスインパクトになります。
さらに決まった構成が入る事により標準化ができ、自営保守でカバーできる範囲が増えてきたので、ベンダーが提供するサポートを必要としないケースも出てきました。
その結果、最近ではODMベンダー系のサーバーが第一選択肢となる事が多くなりました。

またもう一つ強調したい点として、 コミュニケーション があります。
OEMとODMのコミュニケーションの違いをイメージにしたものが下記です。 従来のOEM系ベンダーだとサーバーベンダーとのコミュニケーションに限定されるケースが一般的でした。その結果、個別のパーツベンダーとの関係性が弱い部分がありました。極端なケースだとサーバーベンダーが注力・提案しないパーツの情報はヤフーに入ってこないこともありました。

一方ODM系ベンダーだとそういった制約は"ほぼ"なく、ヤフーがヤフーの戦略に基づいてパーツベンダーとコミュニケーションを取り、その内容を選定に反映させるスタイルを取ることができています。 この結果、パーツ検証、情報連携、品質管理についてもスピード感・質が向上したと感じています。

物理サーバーの運用

次に調達した後の物理的な運用についてです。

一般的にサーバーの保守形態としては「センドバック」「オンサイト」があります。
それぞれについて簡単に説明すると、

• 「センドバック」はDC（自社サイト）外で保守作業を行う、人は動かさずに物を動かす
• 「オンサイト」はDC（自社サイト）内で保守作業を行う、人を動かして物は動かさない

ヤフーでは基本的に「センドバック」保守を採用しています。
理由は「センドバック」保守が費用面で優秀な点、またセキュリティ観点でも不特定多数の人がDCへ入退館をする事は好ましくなく、さらにサポートエンジニアをオンサイトしてもらうオペレーションはかなりの調整・管理コストが必要となるため「オンサイト」保守は特殊事情を除いては選択していません。

「センドバック」についても工夫があります。
保守のタイミングで都度送り出すのではなく、 決まったサイクルで送り出すようにしています。その方が運送・荷作りの調整がスムーズなためです。 また都度送り出さないため、良品の部材がセンドバックで手元に届くまでに時間がかかります。 サーバーにトラブルが発生して交換が必要になった場合には、予め各DCに配置しておいた予備部材から交換する事で復旧時間を早めています。 センドバックする際の荷作り箱（=通い箱）にも工夫があります。 適当なダンボールなどを利用すると各種トラブルが起きるため

• 施錠ができる
• 荷作りの仕方が統一できる
• 緩衝材で固定できる

を考慮したものを利用しています。

予備部材の配置は過去の故障率の統計などから算出をしています。
物理サーバーに関わる統計データを自社で扱えるのもヤフーならではだと思います。

「センドバック」保守を基本としているため自社（サーバーチーム、データセンターチーム、NOC）を含めたメンバーで自営保守（自分たちである程度の切り分け）をできるように手順書にして展開しています。

また下記のようにオペレーションミスを防ぐために、ケーブル色やケーブリング（タグ付け）なども視認性・操作性が良くなるように工夫しています。 （用途ごとにケーブル色を分けており、タグ記載内容やタグ貼り付け位置・形状がオペレーションの邪魔にならないような配置になっています）

さらに、自営保守をした結果と実際のベンダー側での解析結果のすり合わせも行っています。 これは自営保守の精度を高める事で不要な保守作業を減らす事が目的です。 ハードウェアの不良は特定できない・再現できない事が多く、予防的に交換しています。

サーバーの選定（調達）においてはサーバーチームで検証をしますが、基本的な姿勢として「現場感」を大事にしています。
そのためオンサイト作業できるタイミングがあれば直接作業するようにしています。
実際の運用の大部分はNOC（Network Operation Center）にお願いする事になるので情報連携も密にするように心がけています。

OCP（Open Compute Project）

最後に調達と運用とは別トピックになりますが、最近注力している取り組みとして「OCP」を紹介します。
OCP はOpen Compute Projectの事で新しいコンセプトの（サーバーを含む）プロダクトです。

OCPの利点としてベンダーロックインがなく、情報がオープンソース化されておりベンダー・エンドユーザーともにアクセス・コントリビューションができるという従来にないコンセプトで設計されたプロダクトです。

具体的な利点の一例としてフロントアクセスが挙げられます。 従来のサーバーだとフロント/リアで両サイドでの作業が必要であり、作業者はラックの前後を都度移動が必要でした。 フロントアクセスになるとこのようなオペレーションが不要になります。

また対象サーバーを特定するためにUIDというボタンを点灯させての確認作業を行う必要がありましたが、これも移動の必要がなくなりました。

他の工夫としてOCP導入時にはラックレベル（L11 Level）納品を実施しています。
ラックレベル納品とはラック内の必要なコンポーネントを 納品前にDC外で組み上げ 、出荷・納品・設置を行います。
これにより導入時の一連の作業がワンストップ化でき、効率化できます。
対して従来の導入方法はコンポーネントレベル納品（L10 Level）と定義しています。
コンポーネントレベル納品は一度それぞれのコンポーネント（サーバー、ラックやケーブルなど）をバラバラに納品して 納品後にDCで組み上げ をします。
それぞれの納品のイメージは下記です。
また過去にL11納品の紹介動画も作成したのでこちらご覧頂くと理解しやすいかと思います。
Yahoo! JAPAN's OCP Supply Chain & Deployment using MiTAC OCP Accepted™ and OCP Inspired Servers

最後に

ご紹介したようにヤフーではオンプレ環境でサーバーを調達・運用しています。 個々の取り組みには多くのメンバーが関わっており、ベンダーとのコミュニケーション、データ集計・活用からDC作業まで多岐にわたる非常に深い仕事だと思っています。ヤフーのサーバーインフラの取り組み・雰囲気を知っていただけたら幸いです。

*1 完全物理レイヤーです。
*2 Contents Service Provider
*3 チーム名は抽象的に記載しています。
*4 Network Operation Center
・掲載写真は全て許可が下りた場所で撮影したものです