こちらの記事は以前にNewsPicks Tech Guideに投稿された記事をインポートしたものです。元の記事はid:monzoupによって書かれました。
NewsPicks エンジニアの文字です。こんばんは。 今回は QCon NY 2019 のセッション「Driving Technology Transformation at WeWork」の参加レポートをお届けします。
- セッション紹介
- WeWork とは？
- WeWork の現状
- 1. 開発基盤
- 2. データエコシステム
- 3. マルチクラウド／ハイブリッドインフラ
- ハイブリッドインフラ
- WeK8s の登場
- オンプレへのチャレンジ
- まとめ
- あわせて読みたい
セッション紹介
登壇者は WeWork の Fellow Engineer である Hugo Haas さんです。ローカルなシェアオフィスビジネスとして始まった WeWork ですが、今では中国を含む世界中でビジネスを展開しており、事業ドメインも大きく広がっています。一方で WeWork では、当初テクノロジーはそれほど重視されていなかったそうです。このセッションでは、急成長を続ける WeWork の事業成長をどのように支えてきたのか、そのためにどのような改革を行ってきたのかがテクノロジーの側面から語られました。
WeWork とは？
ところで WeWork についてご存知ない方も多いと思いますので、簡単にご紹介します。
WeWork の正式名称は The We Company で、アメリカに本社を置く企業です。WeWork は全世界でコワーキングスペースを提供しており、その特徴は ① クリエイティブでデザイン性の高いワークスペース ② オンライン／オフラインのコミュニティ ③ 主として法人向けのバックオフィスサービス などを備えていることです。初期はスタートアップや起業家を中心にサービスを提供していましたが、最近では大企業の利用も増えています。
2010 年に設立された WeWork ですが、瞬く間に成長し直近の時価総額は 5 兆円を超えています。事業ドメインも広がっており、現在の主要事業としては ① オフィスシェア事業の WeWork ② 共同生活型デザインのアパート運営を行う WeLive ③ 学校を運営する WeGrow が存在します。
ちなみに最近では「1 時間に 3,000 万円の赤字を生んでいる」というニュースが話題になりました。まさに普通の企業とは桁が違う事業規模となっています。
このような成長を続ける WeWork ですが、テクノロジーの側面から見た記事は少ない印象です。急成長・多数の新規事業・多国籍展開 ── WeWork の事例からは、何かしら学べるところがあるはずだと考え、セッションを聴講することにしました。
それではセッションの内容をかいつまんで紹介していきます。
WeWork の現状
まず最初に WeWork の現状について。WeWork は毎年倍々ゲームで成長中。
- 466,000 人の会員
- 485 の物理的なワークスペース
- 105 の都市
- 28 の国（中国も含む！）
という規模でグローバルにビジネスを展開している。エンジニアは約 1,000 人で、4 つの拠点（SF・NY・テルアビブ・上海）に分散している。
なぜテクノロジーが必要か？
WeWork はテクノロジーが事業の中心ではないため、当初テクノロジーやエンジニアリングを重視していなかった。一方で、以下のように幅広い課題を抱えていた。
- 不動産管理
- 調達先管理
- 販売管理
- 請求管理
- コミュニティマネジメントに関わるツール群
- 新しい拠点の配置場所や価格戦略に関わる分析
これらをカバーするために、WeWork はテクノロジーカンパニーになる必要があった。
初期のテクノロジースタック
説明のため単純化すると、初期のテクノロジースタックは US を拠点としたパブリッククラウドで稼働していた。
- コミュニティアプリ（Heroku）
- 不動産管理アプリ（AWS）
それぞれのシステムは完全に分かれており、全く別のやり方で開発されていた。いずれのアプリのデータも最終的には共通の DWH にインポートされていたが、それぞれのデータは上手く統合されておらず、そこから何かしらのインサイトを得ることは難しかった。また監視方法もバラバラで、サービスの状態を正しく把握することも出来なかった。
ここから分かる通り、WeWork には以下の変化が必要だった。
- アプリ毎に異なる開発基盤の統合
- DWH の見直し
- US 依存のインフラの見直し
以降では、実際にどのような変革を実施してきたのかを説明する。
1. 開発基盤
Slack の例と同じように、WeWork にもまたインフラ組織や開発基盤を担う組織は存在しなかった。そこで 2 年前に開発基盤を担う組織を設立した。この組織の目的は「良いプロダクトをより早く作れるようにすること」である。これを実現するためにすべきことは次の 2 つだと考えた。
- インフラ基盤およびツール群を提供し、エンジニアが対象ドメインの問題に集中できる環境をつくる。それぞれのシステムは多数の異なるツールを使って開発されている。これらを統合し、エンジニアが自分たちのドメインの問題に集中できるようにする。
- 良いやり方を強制し、必要に応じて正しい設定を奨励するようなバリデーションを行う。例えば目標サービスレベルを定義し、アプリケーションをデプロイすると、開発者は目標サービスレベルに基づいて適切なアラートを受け取ることが出来るようにする。
開発基盤グループは DX (Developer Experience) を向上させるために、テスト・CI・インフラ・データ分析基盤・モニタリング環境など、幅広いソリューションを提供する。GitOps・DevOps のためのツールセットも用意した。
メトリクスの定義
さて、開発基盤グループの目的は「良いプロダクトをより早く作れるようにすること」だった。この目的を達成できているか、どうやって測定すれば良いのだろうか？これは既存のリサーチ、特に Accelerate の『Building and Scaling High Performing Technology Organizations』を参考に考えた。
開発基盤のツールセットは一連の開発フロー全体をカバーしている。そのため、上手くすれば我々はエンジニアリングに関する何らかのメトリクスを取得することが出来るはずだ。最終的に、我々が見つけたメトリクスは次の 4 つである。
- Lead Time for Changes：コードをコミットしてからプロダクションで稼働するまでの時間。例えば手動の QA が必要になっていると、このメトリクスは悪化する。
- Deploymenet Frequency：どれだけの頻度でデプロイしているか。小さな変更よりも大きな変更をまとめて行う方がリスクが高いと言える。
- Time to Restore Service：障害発生から復旧までの時間。どれほど早く原因を突き止めて修正版をリリース出来るか。
- Change Failure Rate:：どれぐらいの頻度でリリースし、そのうちどれだけにバグがあったか。
これらのメトリクスは、ハイパフォーマンスなテクノロジー組織であるか否かを測るのに有用である。開発基盤はこれらのメトリクスを追跡できるように設計されており、チームの目標はこれらのメトリクスを改善し続けることである。
2. データエコシステム
前述した通り、数年前の WeWork では、それぞれの開発者が別個のサービスを開発・運用していた。それぞれのサービスは大小のデータベースを持ち、共通の DWH に取り込まれていたが、上手く活用できていなかった。KPI を設計し、必要なイベントを収集し、そこからインサイトを得る ── そのような環境を整えるには、データエコシステムを整備しなければならない。
アーキテクチャ
WeWork のデータエコシステムは、次のようなステップでデータを処理する。
- Ingest：必要なイベントを収集する。
- Store：ストレージにデータを保存する。
- Compute：イベントをストリーム処理をしたり、保存したデータをバッチ処理する。
- Consume：データを出力したり、クエリして可視化する。
イベントを収集するためのコレクターは Kafka の薄いラッパーである。収集されたイベントはそのままストリーミング処理しつつ、データレイクにも保存される。ストリームに流れるイベントや、保存されたデータを処理するためのスケジューラとして Airflow を利用している。
データの民主化への取り組み
基盤を整えるだけでは、我々の問題は解決しない。WeWork には多くの事業やシステムが存在し、世界中で稼働している。個別のサービスのデータは全て DWH に格納されるが、利用者はそのデータが何を意味しているのか分からないので、意味のある分析をすることが難しい。
データドリブンな企業カルチャーを作るためには、データを民主化し、誰でも簡単に使用できるようにしなければならない。そこで重要なのは ① データの定義を簡単に把握出来るようにすること ② データの信頼性を高めること である。
データ基盤は普通とても複雑である。様々なデータソースとジョブが連鎖し、必要なデータセットが生成される。スキーマの変更により、ある日突然どこかのデータが連鎖的に壊れるかもしれないし、複雑な経路で生成されたデータは、どのような意味を持っているのか把握することが難しい。
これを解決するために、我々は Marquez というサービスをつくり、ジョブやデータのメタデータを管理するようにしている。これにより、データ基盤を健全な状態に保てるようになった。
著者補足：Marquez について
Marquez については当セッションだけでは今ひとつイメージ出来なかったのですが、以下のイベント動画が参考になりました。
データ基盤においては様々なジョブが連携して必要なデータセットを生成していきます。Marquez は、それぞれのジョブとその入出力の定義（メタデータ）をバージョン付きで集約管理するための API と UI を提供します。これにより、データ基盤に以下のようなメリットをもたらします。
- 定義のわかりやすさ：ジョブやスキーマ定義を UI で検索し把握することが可能。誰がデータを管理しており、どのような頻度で更新されているのかが分かる。
- 問題箇所の特定のしやすさ：ジョブとデータセットの依存関係を可視化し、影響する後続処理を容易に特定できるようにする。スキーマの変更履歴もトラッキング可能。
- 問題復旧の簡単さ：ジョブに対するトリガーを登録することが可能。トリガーをカスケードさせることで、ジョブ失敗時の復旧なども容易になる。
これらの機能により、データ基盤をヘルシーな状態に保つことが出来るというコンセプトのようです。まだまだ開発中という雰囲気なので、今後の発展に期待しましょう。
3. マルチクラウド／ハイブリッドインフラ
最初に述べた通り、WeWork は現在 28 の国・485 の物理的なワークスペースで事業を展開している。そこでマルチクラウド／ハイブリッドインフラへの対応が必要になってくる。
マルチクラウド
まず第一に、物理的に遠く離れた場所でサービスを提供する場合、レイテイシが問題になる。我々の初期のインフラは US に置かれていたが、オーストラリアや南アフリカからはほど遠い。様々な地域でサービスが稼働するようにしなければならない。二番目の問題は中国で、技術スタックやクラウドベンダーが異なる。真にグローバルにサービスを展開しようとした場合、マルチクラウドへの対応が必須になる。
ハイブリッドインフラ
例えば WeWork では、会員はカードリーダーを使ってオフィスに入室することが出来る。また世界中でミートアップが開催されていて、コミュニティマネージャが居ない時間帯にも外部の人々が出入りする。参加者はアプリを使ってイベントの参加申請を行い、一定時間のみ入室を許可される。
しかし、例えばオフィスのインターネットが停止したら？カードリーダーがクラウドを使って稼働していたら最悪だ。誰も入退室が出来なくなってしまう。この種の問題 ── 可用性・レイテイシ・帯域幅 など ── に対応するため、我々は各ワークスペースにもアプリを展開したい。これはつまり、クラウドだけでなくオンプレにも我々の開発基盤で構築したアプリを展開出来る必要があることを意味する。
WeK8s の登場
これらの問題に対応するため、我々は WeK8s と呼ぶインフラを構築した。これは k8s と Helm を基礎に、サービス管理には Valut、サービスメッシュとして Istio、モニタリングに Grafana と Prometheus を採用している。また、デプロイには Argo CD を利用している。
WeK8s はその下にあるものを全て抽象化している。クラウドベンダーがマネージドな k8s 環境を提供している場合はそれを使っているが、エンジニアは下層のレイヤーが何であるかを意識する必要はない。もちろん開発者のデスクトップにも k8s クラスタを展開することが可能になっている。つまり、WeK8s は ① 異なる種類のクラウドベンダー ② 物理的なワークスペース（オンプレ環境） ③ 開発者のラップトップ を問わずに展開出来るようになっている。
オンプレへのチャレンジ
ワークスペースにサービスを展開するには、いくつかの WeWork らしいチャレンジがある。第一に、ワークスペースはデータセンターではない。物理的な空間や冷却機構などに制約が存在する。第二に、ワークスペースには技術者が存在しない。コミュニティマネージャはいるが、彼らにサーバーにログインしてもらうわけにもいかない。第三に、デプロイの規模が跳ね上がる。パブリッククラウドだけでなく、485 もの各ワークスペースにデプロイする必要がある。
WeWork では現在こういった問題に取り組んでいる。例えばオンプレ環境は自動化を進めている。クラウドからイメージを取り寄せて PXE ブートするようにしたり、何か異常があれば、最新のイメージで起動し直すことで自動的に復旧するようになっている。
このように、我々はいわゆるクラウドベースの企業とは異なる側面を持っている。
まとめ
WeWork のセッションについて紹介しました。急成長中のグローバル企業ならではの工夫が見られるセッションでした。 まとめると、WeWork のテクノロジー活用の特徴は以下の通りです。
- 開発基盤を整えてエンジニアの DX を改善するためのソリューションを提供している
- エンジニアリングに関するメトリクスを定義し計測することで改善を進めている
- 健全なデータエコシステムを維持するために Marquez を活用している
- どんな場所でも動くマルチクラウド／ハイブリッドなインフラを構築している
いずれも参考になりましたが、個人的には 2. のメトリクス定義と 3. のデータエコシステムについての工夫が参考になりました。いずれも出来ていない会社が多いのではないでしょうか。3. に関して言えば、（我々のような小さな規模の会社であっても）データ基盤は様々な問題を抱えがちです。誰が作ったのか分からないスキーマがあり、ソースコードを読まないと内容が推測できないデータがあり、ジョブが途中で失敗すると影響範囲が読めず、復旧に苦労する ── こんな悩みを抱えている会社は意外と多いのではないかと思います。データを民主化するために、健全で信頼性の高いデータエコシステムを構築するという WeWork の取り組みは大変興味深いものでした。
