dshimizu/blog

アルファ版

Yahoo Japan Tech Conferecne 2018 に行ってきた

other Tech イベント

Yahoo Japan Tech Conferecne 2018 に行ってきた。

当日の内容は以下にまとめられている。

会場はYahoo! JAPANの本社がある東京ガーデンテラス紀尾井町　紀尾井タワー(東京ガーデンテラス 紀尾井カンファレンス)。 Yahoo Japanの技術的な取り組みに関して知ることが出来、とても豪華で楽しいイベントだった。 聴講セッションについてのメモとか所感などをまとめておく。

聴講セッション

A-1 データセンターネットワークの取り組みと大規模サーバインフラの戦略 村越 健哉 様、藤見 和英 様

Yahoo Japanのデータセンター内でのネットワークインフラのお話。一番聞きたかったセッションだった。

データセンターネットワークの取り組み

ネットワーク概要

まずはYahoo Jaoanのネットワーク概要について。 インフラ技術3部というところが35名弱のメンバーでプロダクションのネットワークを支えているとのこと。具体的には、CDN、バックボーン、データセンター内のネットワークまで全て。管理しているネットワーク機器は7000台超え。データセンターは東日本・西日本それぞれで複数持っていて、東西でASを1つずつ保持しており、BCPを取れるようにしているとのこと。米ワシントンにもデータセンターがありASを持って管理しているらしいがワシントンのデータセンターはActapio社が運用しているとのこと。

外部からのトラフィックを(Noth-Southトラフィックと呼んでいるそう)、これは増加傾向にあり、GYAOやニュースなどの動画トラフィックがメインで500Gbps超え。外部トラフィックの増加に対しては機器のインタフェースの増速やより高スペックな機器を使うなどのスケールアップにより対応してるとのこと。 また、データセンター内のトラフィック(East-Westトラフィックと呼んでいるそう)についてはNoth-Southのトラフィックよりさらに多く、全拠点合わせて10Tbps程もあるそう。これは分散処理(Haboop)やストレージとの通信が増加しているためだそうで、これを解消するためにはスケールアップでは限界に近づいているため、スケールアウトできるようCLOS Fabric Networkの導入を進めているとのこと。

規模の大きさに単純に圧倒された。それに対応するためのCLOSのアーキテクチャはまだ詳しく理解できていないので以下の資料やブログなどもよく読み込んでみようと思う。 既知のTop of Rackなアーキテクチャ(Traditional Network)のリプレースには歴史ある機器・構成であるため苦労しているそうですがこの辺りもやっぱりどこも変わらないのか...

データセンターネットワークの取り組みについて

上記のような状況において、Yahoo Jaoanのデータセンターネットワークの取り組みについてのお話が続いた。 まず、トラフィックについては内部ネットワーク(East-Westトラフィック)の方が増加傾向にあるとのことだったが、これはYahoo Japanに限ったことではなく、FacebookやMicrosoftもそういう傾向があるとのこと。

こういう傾向に先んじて対応してきたのがOTT(Over The Top)であるが、Yahoo Japanとしてはこれらをベースにうまく活用していこうとしているとのこと。 具体的なネットワークに対する取り組みに関してFacebookとの比較していた。Facebookと比較しているのはFacebookが情報をオープンにしているため。

Desigin

CLOS Fabric Networkを推進。ただし、CLOS Fabric NetworkはZone Securityのため、コアスイッチにACLを設定すると同じセキュリティポリシーでないと構築できない。例えばHadoopのサーバとヤフオクのサーバを同じCLOS Fabric Network上には設置できないという問題がある。 内部通信もセキュリティ担保のため各コアスイッチにACLを多用しており最大で11万行。ツールによる自動化で運用はできているが、大量に入っているためスケールアップが難しい。分散が必要。コアスイッチからiptablesベースのACLシステムを構築して開発環境でテスト中。 CROSS Fabirc NetworkをZone Securityではなくサーバのグループ単位で様々なセキュリティポリシーが共存可能。これにより柔軟なアクセス制御を可能にする

Box/Chip

メーカースイッチではなくホワイトボックススイッチについてのお話。 FacebookはWedgeやBackpackの上にFBOSSを乗せて使っているそうだが、YahooはBackpackやEdgeCoreを使い、OSの開発は難しいため Cumulus のOSを利用しているとのこと。

かつてはCiscoとJuniperでメーカー冗長を取っていたが、最近だとArista NetworksとCiscoやWhiteboxはBroadcomで同じチップなので、チップのダイバーシティ(多様性)のためASICにも注目されているとのこと。汎用ASIC、カスタムASICのそれぞれメリットがあるため利用を検討しているそうで、例えば汎用ASICはBroadcomで安い、タイムリーにその速度のインタフェースが利用可能、カスタムASICは大量のACLの投入やTelemetroy(?)が可能、などがあるらしい。

スイッチのシャーシは普通は1つのOSで構成されるが、Facebook BackpackではFabricカードとLINEカードそれぞれにOSがあり、これにより1つのシャーシの内部で複数のOSにより論理的にCLOS Fabricを組まれており、1つのOSではないので冗長性が取れているのがメリットらしい...より詳細には以下のブログに書かれているとのことなのでこれも読んでおこうと思う。

Automation

自動化について。 Yahoo Japanではネットワークに関する自動化、可視化については自分たちでツールを作っており、既存のネットワークについては自動化と可視化ができているとのこと。

IOS、Arista EOS NX-OS といったOSごとの違いを抽象化して可視化。ただ、障害の予兆やCLOS Fabricのケーブルの配線ミスの検知は難しいとのこと。 これに関しては、Apstraの製品がCLOS Fabricに特化しているそうで、採用している。intentベースはやりたい設定をコンフィグとして生成する、自前でできないものはカバー。 HadoopネットワークリプレースをやっているがApstra製品を使ってCLOS Fabricを作っているらしい。

ネットワークの話は以上だった。 他社のネットワーク構成の詳しい話を聞ける機会は少ないと思っていたので、大規模環境でのネットワークの取り組みの話を聞けたのはとても勉強になった。CROSのアーキテクチャについては資料や過去ブログ、関連情報をみて理解を深めておこうと思う。

大規模サーバの戦略

続いてサーバ関連のお話。キーワードとして全体最適化とOCPを挙げられており、それに関してのお話。 サイトオペレーション本部というところが商用インフラの担当部隊で、データセンター、ネットワーク、ストレージ、サーバ、OS、インフラのツールやOpenstackなどのプライベートクラウドの基盤といったアプリケーションレイヤまで幅広く担当しているとのこと。

全体最適化

まずは全体最適化について。 サーバは10万台。機種は80モデル以上、パーツ点数は20万点以上の環境で、担当メンバー10人1チームが2チームあり、それに加えて業務委託の方が数10名。構成の検討からデバイスや筐体、機種の検証、比較、物理作業、保守・トラブル・故障対応、分析を行い、業務委託の方は配線やラッキングなどの物理作業を行うそう。

構成の検討 サーバ台数が多いので、サーバ1台ごとに最適化するのではなく全体最適化してトータルコスト削減を目指しているとのこと。例えばある時期にSSDを購入する場合、容量が80Gとか120Gとかあるが用途等によってバラバラに買うのではなく、その時期に買う型番を決めておき、パーツ管理や問題・バグを引く頻度のリスクを削減しているらしい。

検証〜保守 内製のインストーラなどがうまく動くか、独自のOSがうまく動作するか、個々のデバイス付属のユーティリティが動作するか使い勝手が落ちていないか、物理作業、配線のしやすさ、ボタンの押し間違えなどが起こらないかなどを検証し、それぞれ点数付けして、各モデル・各ベンダーの比較表を作って判断しているとのこと。

保守 独自の保守フローがあるので各ベンダー、関係会社にできるか、提供していただけるか、ない場合は作っていただけるかなどを検討するとのこと。

分析 大規模サーバの統計的な分析を行ない、将来のサーバやパーツ選定時に利用しているとのこと。 故障時のデータを管理したり、パーツの価格は適正か、市場ではどうかなどを確認できるようにしたり、CLIやBMC、データを取得するツールなどが使いやすいかなどを数値比較。

OCP

続いてOCPサーバのお話。 現在、全体の80%程度は一般的な1U/2Uのサーバらしいが1000ノード程度OCPサーバを導入しているとのこと。 HyperScaleの思想で特定のサービス、特定の負荷、ワークロードに特化したスペック・構成にするのではなく、どこでも使いまわせるように構成でき(ex ヤフオクで使っていたものを広告用に転用する)、ユーザ手動でパーツ選定やHW設計ができ、ベンダーの影響を受けず、使いたいものを使いたい時に使えるのがメリット。また、物理運用面ではラッキング作業時に背面移動の必要なかったり、OCPに準拠しており独自仕様のない　IPMI も良いそう。

また、サーバベンダーやパーツサプライヤー、調達やデリバリーなどのサービスを提供しているディストリビューターの各社計30社程と協業しており、ラッキング業務のナレッジなどを提供したり、様々なパーツの故障率などに関する統計データを提供して、選定するパーツ等の話をしているそう。

将来的には「自立したインフラ」を目指し、外部依存を無くして、Yahooが主体的に管理できるようにしていくとのこと。

大規模インフラ環境におけるサーバの構築から運用までのノウハウが聞けた。 機器選定における検証や分析などかなり細かくしっかりやられている印象でさすがだと思った。検証時の点数付けのポイントや分析データ管理などをどうやっているのか具体的なところが知りたかった。 実際に導入されているOCPサーバが会場に展示されて、見ると小さくて扱いやそうな印象だった。 また、Yahoo Japanほどの規模とそこにいらっしゃるエンジニアだとOCPサーバのメリットも大きい気はするが、一般的には保守の面がかなりネックになりそう。全20名+αの人数で保守周りもどうやっているのか気になった。

A-3 Yahoo! JAPANを支える開発基盤 PaaS 甲斐 遼馬 様/Joshua McKenty 様(Foundry Pivotal Software, Inc.)

2つ目のセッションはYahoo! JAPANを支える開発基盤のお話。

Yahoo! JAPANを支える開発基盤

以下のリンク先にある内容と類似のお話。

全社共通でCloud Foundryを利用しているとのこと。多くのベンダーで採用されており、他のCloud Foundryのプロダクト、例えばIBMのBluemixや富士通のCF(?)などのノウハウを活用できるというメリットがあることと、動作環境を選ばず、OpenStack や vSphereの複数のIaaS基盤と組み合わせたり、DBや開発言語を利用できるのがメリットある。

また、PaaSで動くCI/CDとして以下のツールを利用しているそう。 concourseはWebUIでタスクの繋がりを見ることができ、YAML+Dockerで容易に環境構築可能なこととやCloud Foundryにもすでに機能化されているらしい。

導入した目的としては、これまでの開発手法だと開発後の運用保守に手間がかかっていたため、PaaS上で効率よく開発できるようにし、より付加価値の高いサービスを開発できるようにするとのこと。共通化したい部分をCloud FoundryのBuildpackという機能で共通化できるそうで、これらによって開発者の負担を減らしていくそう。

PaaSの今後

2016年に一部導入、その経験を元に本格的に2017年に本格導入、2017年度末はクラスタ数を5->10(dev+stg+prodがサービス開発エンジニア向けに解放されている環境)　30,000リクエストをさばけるような規模のクラスタを構築していくとのこと。 (sandbox環境はプラットフォーム開発本部のテスト環境) Cloud Foundryと外部プラットフォームの接続にはCloud FoundryのCredentialsという値を発行してプラットフォーム側に格納して有効化する必要があったが、これをcliツールで自動でプロビジョニングをできるようにし、開発者の負担を減らしていくことを目指しているとのこと。

色々できるというのはわかったけど、Cloud FoundryもOpenStackも使ったことがないのでいまいちピンとこなかった...

Cloud Foundryは全然触ったこともないので話を聞いただけではどんな良さがあるのかわからなかったけどOpenStack や vSphereのほか、Bluemixなどの商用プロダクトとも連携できるというのは初めて知った。

Complexity and Autonomy(複雑さと自律性)

Pivotal Cloud Foundry Field CTO のJoshua McKenty氏から複雑さと自律性についてのお話。 英語セッションで同時通訳のレシーバーがあったもののなかなか追うのが難しかった。

Agile Manifesto にある通り、最も重要なのは価値あるソフトウェアを早くかつ継続的に提供して顧客を満足させること。このためには自動化が不可欠。 しかし実現は難しい。これは人を相手にしているからとのこと。

「No plan survives contact with the enemy. ( Correlli Barnett(Helmuth von Moltke the Elder))」...いかなる戦術も眼前の敵には無力。

複雑さについて

簡単な問題とはケーキを作るようなもの。レシピさえあればできる。入り組んだ問題とはロケットを作るようなもの。複数のレシピが必要で、組み合わせる必要がある。複雑な問題とは子育てのようなもの。レシピはなく、突発的な問題が起こる。

半自律型のチーム

半自律型のチームとは。チームがいろんなことを試している。間違っていても良いという感覚が重要。なぜそれが必要かを全員が分かっており、素早い意思決定ができる。 組織は完璧を求めるべきではない。「半」自律型であることが重要。 また、開発者だけで組織されたチームは効果を発揮しない。

実験するマインド

継続的に何かをするためには実験を行い続ける必要がある。どんな計画であっても敵の前では無駄。思い通りにはいかない。 人は思い通りには動かない。人と貴方たちは常に対立している。完璧な計画なんてない。

必要なスキルの変化

コードを書いたり読んだりだけでなく、人の話を聞く、コミュニケーションをとる、振り返る、反省することも必須。 ただツールを使うのではなく、仕事の仕方を常に学び続ける。 盆栽や俳句では、観察者と観察者の距離を短くしようと、不要なものを捨てて調整する。

まとめとしては以上。 ちょっと色々聞き取れなかった部分もあって見返すとよくわからないけど、ITエンジニアが人を相手にしたり複雑な問題に取り組むにはコードの読み書き以外にも多様なスキルが必要ということなのかと思った。そうだとするとその意見には賛成で、Team Geekにも似たようなことが書かれていたと思うけど、物事をよりよく進めていくためには一緒にやる相手のやっていることを理解して耳を傾けて歩み寄ることが重要なんだと思っている。

C-5 アプリケーションの高速デプロイを可能にする技術 - Yahoo! JAPAN の Kubernetes as a Service 藤江 貴司 様、河 宜成 様(ゼットラボ株式会社)

以下のSplunkのセッションと迷いつつ k8s のお話を聴講。

Yahoo Japanでのk8sの利用事例。 100以上のサービスを全てコンテナ化するためのコンテナ実行環境としてk8sを検討。 Google TrendsでもOpenStackを抜き、DIAMOND&PLATINUMスポンサーにも世界トップクラスのIT企業が名を連ねていることから各社k8sに力を入れていることがわかる。そんな背景から2017年にYahoo Japanもk8sの本格導入を開始したそう。

導入においてはゼットラボ社が開発したKubernetes as a Serviceを利用してすでにズバトクのサービスでプロダクション環境で稼働しているとのこと。

なお、ゼットラボ社はYahoo Japanの完全子会社。ちなみにZコーポレーションとは別会社とのこと。

コンテナ化以前のCI/CD

リポジトリへのpushは自動化できていたがデプロイは手動だったとのこと。機能追加やパッケージが増えたりデプロイにかかる時間が増大、さらにアクセス増によるVMの増加でその運用管理コスト増大・故障時の対応増大...などなど、環境維持コストが高まってきた。

コンテナ化後(k8s導入後)のCI/CD

開発環境をVMからローカル化に移行、kubernetesクラスタを構築、CI/CDのパイプラインを組みやすいツールに変更して開発からデプロイまでをシームレスに実行可能にし、容易なスケールアウト、高速デプロイを達成。結果、本質的な開発に割くリソース確保が可能になったとのこと。

Kubernetes as a Service の紹介

Kubernetes as a Serviceの仕組みや機能の紹介。 kubernetes導入で解決しないこと、起こる弊害。ノード(VM)の追加。VMの脆弱性、障害。約3ヶ月ごとにリリースされるkubernetesのバージョンアップ。コンポーネントの管理。 特にYahoo Japanのような数万台規模の環境でKubernetesを手動で管理するのは現実的ではない。 これらKubernetesの問題を解決しないことを解決するためのKaaS。k8sの管理コスト削減したりk8sクラスターを払い出すフルマネージドのツールとのこと。

クラスタの追加は、開発者がKaaSに対してクラスタを追加するというリクエストを送ることで、YahooのIaaS(OpenStack)から必要なコンポーネントを作成され、社内のDNSにクラスターのドメインを登録まで行われる。他、構成を変えたり複数のクラスターを作ったりもできるOpenStackのフレーバーを変えることもできるとのこと。 オートヒーリングや水平スケールなども運用工数削減のための機能がたくさんあるらしい。

とにかく運用工数削減のニュアンスの言葉がよく出ていた気がする。Kubernetesは使ったことなく、Kubernetesクラスタの運用の大変さを味わったことはないけど、クラスタというだけでやばそうな気がする。Podなどの単語もその場ではわからなかった。というか今も詳しくわかってない。そんな程度の知識しかないのでまずはKubernetesを触ってみるところから始める必要がありそう... KaaSは最初から導入するのではなく、Kubernetesの運用が手に余るような状態になってきたところで使うイメージなんだろうか... また、会場の中でもk8sを使っている方はほとんどいないかった。

B-6 テクノロジーとブランディング ～人を惹きつける技術～ 内田 伸哉 様

ブランディングの技術についてのお話。

まずは過去のYahoo　Japanのプロモーションの紹介。

2013年9月に行われた「さわれる検索」というプロモーション。 インターネットで送れるものは視覚と聴覚。3Dプリンタの登場により触覚も送れるのでは？という発想の元、さわれる検索というものを開発。3Dデータベースを検索してそれがアウトプットされるというサービス。コードがGitHubで公開されていてると言ってたような気がして、確かに過去のプレスリリースでもそんなことが書かれていたけど探したけど見つからなかった。

2017/3月、3.11から6年、東京の人々が3.11を思い出すための広告。

2016/4/1 インターネット20年の歴史の絵巻物。

公式キャラクターの宣伝動画。 若年層に弱いので親しみやすいキャラクターを作成。

これらのブランディングの目的は Yahoo をどう好きになってもらうか。どう選んでもらえるかの心理制御が大事。

続いて以下。

自分は見ていないが完成動画を見るには2つのスマホが必要らしい。Twitterでも話題に。 作ったきっかけは、"「君の名は。」はDVD発売に伴って話題を作りたい。"、"Yahooはユーザに驚く体験を届けたい。"と言う双方の思いを組み合わせて何かできるのではないかと思ったから。

ペア動画でのユーザ間の画像をどうSYNCさせるかと言う課題の技術的な側面。

  1. mp4でテストすると動画プレイヤーが立ち上がり、プレイヤー依存ですぐに再生されたりされなかったり古い端末の方もいたり。連続的にGIFを送る形に変更。
  2. 同期を重要点のみに変更。より多くの利用者のため。動画再生にはスマホのスペックによって色々問題がある。
  3. リクエスト負荷分散。ミュージックステーションで放映することになり負荷増。対応するためのアーキテクチャを設計。

色々な技術を駆使してペア動画で盛り上がれる世の中を作った。 Yahooが面白いことを提供すれば結果的にYahooを好きになってもらえるという形。 どう世の中を盛り上げるかどう世の中を盛り上げていくかというところを考えてこう言ったものを提供している。

ブランドの技術

1. 広い技術

狭い技術とは、ハードウェア、プログラミング、VRやAR…など。 広い技術とは、デザイン、世の中の心を掴む、炎上させたりバズらせる、モテる、などのファジィなもの。

PS VRとうんこドリル、これを同率で考えられるか？最先端の技術かどうかだけではなく、小学生の心をうまくつかむ技術。記事のタイトル等で世の中にウケるかどうかまで見れる技術、設計。互いに尊重するのが大事。自分がどこの技術を持っているのか。 テクノロジーの技術者、プロモーションの技術者が集まって設計をすることが重要。

2. 良さ 日本のマーケットは先端、最新を意識しすぎて定性的な良さが希薄になっている。 「最先端でも面白くなければだめ、根本的な良さを求める」 人工知能、ビッグデータ、ブロックチェーンの言葉が入っている企画書は面白いか？

言葉だけ踊るのではなく、何が良いのかを具体的に考える。見極める。 良さがある上でテクノロジーを使うか使わないかを判断している。

3. メッセージ

一番大事。いつ何を言うか。良さを明確に表せるか。

ブランディングとは人の心を動かす技術。

D-7 Yahoo!ショッピングのサービスデータ活用事例 藤木 貴之 様

(あとで書く...)

まとめ

Yahoo Japan Tech Conference 2018 に参加してきたので内容のメモと感想を書いた。 Yahoo Japanの技術的な取り組みに関して知ることが出来た。また、セッション以外にも多数のブース、会場のスタッフの方々のお気遣い、ランチセッション、様々なノベルティなどなど、無償なのにとても豪華で素晴らしい1日を過ごせたイベントだった。ありがとうございました。

参考

dshimizu 読者になる

広告を非表示にする
コメントを書く