セッション内容

登壇者は Slack の Senior Director of Infrastructure Engineering である Julia Grace さんです。彼女は Slack の最初のインフラ担当エンジニアで、2 年間で 100 人ものエンジニアを抱えるインフラ組織をつくりあげました。このセッションでは、彼女が Slack にジョインしてからの歴史を振り返りながら、どうやって Slack のインフラを進化させてきたかが語られました。

2015 年：フェーズ 0

〜 2.5M DAU。この頃はインフラ組織は存在しなかった。

2016 年：フェーズ 1

〜 4M DAU。創業者が書いたコードがまだ動いていた。エンジニアは 150 人ほどに増えていたが、相変わらずインフラ組織は無かった。

当初 Slack は小〜中規模のチームを念頭にデザインされていたため、この頃に少しずつアーキテクチャ上の破綻をきたしはじめた。最も分かりやすい例は「グリーンドット」（オンラインであるかを示す緑色のアイコン）だった。当時この機能は壊れていたが、多くのユーザーは気付かなかった（笑）。「グリーンドット」の裏側では、全てのユーザーのステータス変更を全ワークスペースにブロードキャストしていたため、ひどい頃は Web Socket の全トラフィックの 80%（！）を「グリーンドット」の更新メッセージが占める有様だった。全メッセージが 16M / min なのに、実に 13M が「グリーンドット」のためのメッセージだった。

この頃に 「Slack のようなプロダクトドリブンな組織に、どうやってエンジニアリング主体の組織をつくるか？」 を考え始めた。ヘッドカウントも予算も無かった。そこで緩やかにプロセスを変えていくことにした。この頃に彼女が意識していたのは以下の 3 つのポイントだった。

社内向けのエヴァンジェリズム活動を始める。なぜインフラへの投資が必要なのかを PR し、自分たちの仕事を他の部署が見えるようにした。
会社のプロセスに従う。既にあったやり方を否定することなく、会社のやり方に合わせてプランニングし進捗をレポートするようにした。
スポンサーとなるエグゼクティブを見つける。自分たちがやっていることを理解し、サポートしてくれるエグゼクティブを探した。

2017 年：フェーズ 2

エヴァンジェリズム活動の結果、2016 年末までに、約 10 人のインフラ組織を組成することができた。「グリーンドット」問題も解決。この頃の Slack のテクノロジースタックは以下の通りだった。

バックエンド：モノリス（PHP） + メッセージングサービス（Java）
フロントエンド：ライブラリを利用していないプレーンな JavaScript

当時は PHP から Hack / HHVM に移行中で、そのために Facebook から何人かエンジニアを採用していた。

当時インフラ組織が引き継いでいたのは、Java によるリアルタイムメッセージングサービスだけだった。この頃はマイクロサービスアーキテクチャになっておらず、モノリスとメッセージングサービスがあるだけだった。しかし US 外からのパフォーマンス問題を解決するため、2 番目のマイクロサービスとして Go 言語によるキャッシュサービスを開発した。

またこの頃に DB のシャーディング方法も変更しはじめた。Slack では MySQL を利用しており、ワークスペース単位でシャーディングしていたが、サービスの成長に伴い問題が発生しはじめた。そこで Vitess を使うことにした。

※ Vitess への移行は言うは易しで非常に大変だったそうで、昨年の QCon SF で詳細が語られています。

Scaling Slack - The Good, the Unexpected, and the Road Ahead

この頃の最大のチャレンジのひとつは採用だった。ヘッドカウントはあったが、どんなエンジニアを採用すれば良いのか分からなかった。チームで話し合ってジェネラリストを採用することに決めた。

2018 年〜現在

インフラエンジニアが 10 人から 100 人弱まで増えた。サービスも急速に成熟し、0 → 1 フェーズが終わって 1 → ∞ フェーズに入った。この頃には検索やランキングを担う 3 つ目のマイクロサービスを切り出すことに成功した。

マイクロサービスのテンプレートも出来て、いまや必要なのはジェネラリストではなくスペシャリストになった。例えばデータベースストレージのスペシャリストや、ジョブキューシステムのパフォーマンスをチューニングすることに情熱を傾けられるようなスペシャリストが求められた。また、次の 10 年を見据えてデータサイエンスや機械学習専門のシニアリーダーを採用することにした。

製品管理プロセスも構築した。あとから考えると、もっと早くに PM を採用すべきだった。PM は製品仕様を整理し、エンジニアと一緒にプロダクトを構築する。これによって何をやるべきかが明確になり、大きな利益をもたらした。

投資すべき分野を見定めて企業も買収した。買収の素晴らしいところは、投資すべきと定めた領域を一気に立ち上げることが出来ること。Slack では k8s とサービスメッシュに投資することにして、そのためにサービスメッシュ分野の企業を買収した。今 Slack は k8s に移行しつつある。

フロントエンドのインフラもリードし、組織全体で一丸となってプロダクトを作ることが出来るようになった。もっと組織を細分化すべきだとも思ったが、上手くいっていたのでそのバランスを保つようにした。

所感

改めてサービスの成長は全てに優先するのだなと感じました。我々エンジニアはついついアーキテクチャやプログラムの美しさにこだわってしまいがちですが、このセッションで紹介された Slack の舞台裏を知ると、巷のエンジニアリング議論などが非常に瑣末な話に思えてきます。

一方で彼女のようなパワフルなインフラ責任者がいなければ、Slack がここまで成長することは無かったでしょう。インフラ組織が無い会社でその必要性を説き、必要なエンジニアを採用し、適切な分野に技術投資をすることでシステム基盤を整えてきたというのは、口にするのは簡単ですが途方もないパワーが必要な仕事です。彼女が一番最初に述べた 3 つのポイント ① 社内向けのエヴァンジェリズム活動 ② 会社のプロセスに従う ③ スポンサーとなるエグゼクティブを見つける というのは、どんな会社であれ参考になる考え方ではないでしょうか。

ちなみに Slack の技術スタックの変遷については、StackShare にもまとめられているのでこちらも是非ご覧ください。2013 年に素朴な LAMP スタックで構築された Slack が、どのように変化してきたかが分かるようになっています。

stackshare.io