Sam Lambertは、2013年にGitHubの最初のデータベース管理者として入社し、現在はGitHubの技術ディレクターを務めています。このインタビューで彼は、今や1000万以上のユーザと2500万以上のプロジェクトを誇るサービスが、比較的シンプルな技術的スタックの上でどのようにスケールし続けてきたのかを考察しています。また、自作のパワフルなチャットボットであるHubotを使ってコラボレーションしつつ、従業員の約6割がリモートで働いているという、GitHubの大規模なオフィスレスな仕事環境についても触れています。
SCALE: 私としては、GitHubはテクノロジーのユーザーというよりは主にテクノロジーの提供者であると思っていますが、それは恐らくフェアではない見方でしょう。GitHubを支える技術や哲学について、一通り教えていただけますか？
SAM LAMBERT: 内部でソフトウェアやサービスを開発する時には、UNIX哲学を大きく取り入れています。私たちは、自分たちのインフラのシンプルさをずっと誇りにしたいと思っています。複雑さやエンジニアリングのやり過ぎを排除しようとし、実際そうしてきました。どうすべきで、何に取り組むかについては、より実用的な選択をしようとしてきたのです。
長い間、私たちのインフラの重要なところは、シェルスクリプトやシンプルなスクリプトで結合されていて、それは驚くほど効果的に動いているとともに、今もとてもうまく動いています。
そういった技術スタックを採用することでどんな結果が現われましたか？
GitHubのユーザとしてあなたが見ているもののコア部分は、Ruby on Railsのアプリケーションです。それは創業者たちが会社を立ち上げた時に作られて、もう7年になるものです。それはアプリケーションのコアである一方で、スタックの大きな部分をGitが占めています。プロキシやGitのリクエスト、データのアグリゲーションなどを行うデーモンをCで作っています。
MySQLは私たちのコアデータストアであり、ユーザ関連のメタデータを含めた全てのデータを保存するのに使っています。永続的でないキャッシュのためにRedisも少し使っていますし、memcachedのようなものも使っています。
C、シェル、Rubyといったものは、かなりシンプルで、モノリシックなスタックです。実際、複雑すぎる職場ではないですし、それぞれの小さなプロジェクトに対しても新しい言語を使わないようにしています。
私たちは、Rubyのコアコミッターと働いてきているので、持っているものをスケールさせ、技術の選択を実用的な観点から行うことができ、スタックを小さく保つことが可能です。実際、選んできたスタックに関して、できないことは何もないと言っていいでしょう。この仕組みを続け、進み続けていくには、私たちが得てきたものに色々なテクニックを適用し続けていく必要があります。
それは、GitHubでホストされているプロジェクトや色々な試みを考えると少々皮肉にも思えますね。新しいことに目を向けたり、仕組みを変えようと思ったことはないのですか？
私たちは新しい技術には確実に目を向けています。従業員には、それぞれが何をやるかに関しては大きな自由がありますし、色々なことや経験にトライできます。それが、なぜその技術を使っていないのかを知るためであることもあります。何かに目を付け、なぜそれが面白く、解決しようとしている問題が何であるかを理解すれば、恐らくそれが今やろうとしていることへの見方を拡げるアプローチの1つになるでしょう。あるいは、それが成熟するまで少しの間本棚にしまっておくことになるかもしれません。
しかし、世界のプロジェクトの半分がGitHub上で生まれているというのに、私たちはかなり保守的なスタックにこだわる傾向があるというのは、面白い皮肉です。私がGitHubに最初のDBAとして入社する際の面接のことを、CTOがよくジョークで言うんです。私はその面接で、「ここに座っていることに本当に驚いています。GitHubはもっと何か新しい先進的なデータストアを使っているものと思ってました」と言ったんですよ。Rubyをハックし、Cをハックし、最新でかっこいい技術を追うのではなくより安定したスタックを使って面白いことに取り組むのに時間を使うハッカーたちの、本当に実用本位な集団が、面接のプロセスが進むにつれて見えてきたのです。
Gitの全てを追いかけていく
チームを忙しくするようなチャレンジというのはありますか？
その大部分は、ボリュームです。言うまでもなく、私たちのユーザベースは成長し続けています。また、非常にテクニカルなユーザベースでもあるので、ユーザたちは分かりにくいかたちでAPIを使う方法を探そうとするようです。一般的なフレームワークを使っていると、巨大なユースケースの極限まで至らないと遭遇しないような問題がたくさんあります。巨大なスケールにあっては、Railsで使うパターンは最適化されていないものがいくつもあります。私たちはそういう問題に会うこともあるでしょうし、そういった機能の一部を書きなおす必要もあるかもしれません。
私たちが大量にGitを扱っているのは間違いありません。バックエンドのインフラでGitのようなものをスケールさせるのは、全く違います。他の誰かが解決しようとしていることとは違うんです。私たちは、Gitやアプリケーション自体をこの規模でスケールさせるという興味をそそるこのことに関しては、先駆者なのです。
私たちにはそういったことに取り組む素晴らしいチームがいますし、さらなる機能を作り上げようと本当に頑張っています。GitHubは、どこかのインフラ内にあるGitホストのようなものです。つまり、ユーザがコードにアクセスしようとした時、パブリックあるいはプライベートなリポジトリのバランスをとったり、認証やパーミッションが正しくなるようにするといった仕事をするということです。
Railsアプリケーションとして、github.comはとてもとても高速なサイトであり、私たちのモットーは、「高速になるまで世に出すな」なのです。
つまり、Gitはあなたたちの技術的なオペレーションのもっともユニークな一面だということですね？
まさにそういうことです。私たちが知られている面以外でユニークであろうとはしていません。それは私たちが本当に誇りに思っていることでもあります。「Gitデータを持っている会社に意味のある、私たちのアーキテクチャの独自の一部分を書くことだけやろう」と、よくみんなに言うんです。
車輪の再発明をする必要はなく、私たちのデータベースを開発する必要もなく、独自のフレームワークを作る必要もない。なぜなら、それらは全ておきまりのものの範囲に入るからです。単なるウェブサイトであり、ウェブホスティングです。おきまりではない範囲においては、カスタムアプリケーションを開発したり、それ専用のアプリケーションを作る必要性を受け入れるのです。
チームが取り組んでいるもので、エンジニアリングを最も加速させるメトリクスはなんですか？
私たちは、パフォーマンスに関してはかなりこだわっています。サイトは常に高パフォーマンスで、かつ継続的に高速である状態を保ちたいと考えています。github.comは、Railsアプリケーションとしては非常に高速なサイトですし、私たちのモットーは「高速になるまで世に出すな」なのです。
私たちが継続的に観察している特定のメトリクスがあるかという意味で言えば、Gitを保存するためのキャパシティがそれに当たります。それこそ私たちが成長させ続けていかなければならない者です。使用量が盛り上がれば盛り上がるほど、そういった種類のインフラに対する負荷が増大していることがわかります。そういった時にスケールし続けられるように、非常に面白いプロジェクトをやっています。
スケールの問題のほとんどは、すぐ目の前まで来ているものです。そういった問題はゆっくり徐々に現れるのではありません。
クラウドコンピューティングは使っていない
GitHubの背後にあるインフラはどんなものなんでしょうか？クラウドにあるんでしょうか、それともローカルなサーバ？
自前のデータセンターでホストしています。実は素晴らしいプロビジョニングの話があります。私たちは、ハードウェアをほとんどまるでクラウドにあるかのようにプロビジョニングできるんです。物理インフラのチームは非常に小さいですが、非常に献身的で、素晴らしいサービスを提供するために信じられないはたらきをしてくれています。
新しいサーバが必要になった時、どんなクラスのどんなシャーシを使ったホストが何台必要かをチャットボットであるHubotに伝えるだけでいいんです。そうすると、依頼の通り構築してデプロイして数分の内に応答をくれます。私たちは、こういったとてもフラットで、柔軟にもかかわらず物理的なインフラを使っているのです。誰かがこのインフラを使うごとに、それが素晴らしくそして優秀なはたらきをするのがわかります。
それはまるで、物理的なものに関してよくある面倒で時間のかかる調達のステップをやらなくていいようにしてしまったかのようですね。
実際には、ハードウェアの在庫に余裕をもたせています。物理インフラチームは、彼らが使う予定の空っぽでプロビジョニングするだけのマシンを割り当てるんです。例えば、データベースインフラチームがデータベースのために必要とするクラスのプールに何台のマシンがあるか調べているとしましょう。彼らは基本的にはすでにPuppetのロールを書いて、各ノードがどう動くかを分類しています。なので、彼らは自分でマシンを割り当てするか、自分たちのチーム用に確保するためタグ付けするだけでいいのです。
サーバの在庫は定期的に増やしているのですか？それともある時点での一定の制御された成長パターンがあるんでしょうか？
何台発注して何台割り当てたかを基準に、コントロールし続けるようにしています。しかし、サイトの使用率によっては増加率に合わせています。世界中のますます多くの会社が、自分たちはテクノロジーの会社であると考え始めている中で、GitHubの使用量もどんどん成長していく一方です。
とはいえ、私たちはうまくそれをさばいています。スケールの問題のほとんどは、すぐ目の前まで来ているものです。そういった問題はゆっくり徐々に現れるのではありません。急に現れて、問題が起こるなり私たちはそれに対処するのです。時には、面白いユースケースがあることもあります。誰かがサイトにおかしなものを持ち込んで、それがほんの小さなスケールの問題を明るみに出したとしても、私たちには素早く開発に取りかかれるアプリケーションがあって、社員はドメインを熟知しています。そして、その問題を確実に素早く乗り越えて修正版をデプロイし、運用を続けるのです。
私は、恒久的な居場所を持たない同僚たちを採用してきました。彼らは街から街を飛び歩き、どこからでも仕事をします。彼らはまさにノマドで、世界中どこにでもいます。
グローバルなエンジニアリングのネットワークを作る
夜も寝られないような問題や、常に頭に残る長期的な懸念はありますか？
私たちのインフラを守ることは、私たちが常に考えていることなのは確かです。夜も寝られないとまでは言いませんが、ずっと考えていることですね。
それから、私たちの組織をスケールさせることもです。組織が大きくなればなるほどより多くのエンジニアが必要になりますが、私たちのカルチャーに合わせた成長をする必要もあるわけです。採用は、あらゆるテクノロジー企業にとってチャレンジだと思いますよ。世界中から様々なバックグラウンドを持ち良質で有能な従業員を集め続けねばならないのです。しかも、同じエンジニアリングの価値観を持ち、既に持っていて提供できるものと同じことに取り組むのが好きな人たちを集めなければならないんです。
それから、GitHubの分散して仕事をするという慣習を受け入れ続けることについても考えています。今の所、60パーセントがリモートワークです。私は今の所イングランドにいますが、世界中に旅して、違うところから仕事をします。これは、私たちのカルチャーと分散して働く慣習をベースにすれば、当たり前に可能なことですね。
それはかなりユニークですね。その60パーセントの社員の方々は、自宅から仕事しているのですか？それとも支社から？
自宅から仕事しています。どこからでも仕事することができます。昨年私は多分世界中の5ヶ所か6ヶ所の街で働いていました。行くと決めた場所で、自分のラップトップから仕事するんです。1ヶ月前、私はウィスコンシンの森の中のキャビンで仕事してましたね。
私は、恒久的な居場所を持たない同僚たちを採用してきました。彼らは街から街を飛び歩き、どこからでも仕事をします。彼らはまさにノマドで、世界中どこにでもいます。それが私たちのカルチャーに溶け込んだ人たちに提供できるものです。
どこのオフィスから働かなくてはならないというのはありません。私たちのオフィスは、ソーシャルスペース以上のものです。社員が会って一緒に楽しむ場所というのはありますが、必ずしも一緒でなければならないわけではありません。
私とある同僚は、バックエンドの膨大なリファクタリング、具体的にはモノリシックな環境から分散環境への移行をしました。非常に多くの決断をし、たくさんのリファクタリングをして、新しいパターンを作りました。そのプロジェクトを通じて、私たちは面と向かって会話したことは一度もありません。チャットを通じ、プルリクエストを投げ合うことで一緒に仕事したのです。そして、プロジェクトの最後に会うことになったのですが、それは彼がGitHubに入社してから6ヶ月ほど経ってからでした。
繰り返しになりますが、これが私たちの働き方、私たちのカルチャーのはたらきなのです。生産性を高めたり、何かをやるために、物理的な位置を気にする必要はないのです。
長い間、新人研修はチャットルームに入って他の社員が何をしているか見ることでした。… 私は入社してから、チャットに入り、みんなの働き方や何をしているかを見ていただけで、その方法を学んだわけです。
Hubotが助ける番
プロビジョニングツールとしてのHubotに言及されていましたが、もう少し詳しく教えてくれませんか？Hubotは、GitHubが分散した働き方をどのように機能させられているかの鍵になっているように感じますね。
Hubotは、GitHubにおいてはなんでもできます。例えば、スタッフがどこにいるかHubotに尋ねれば、世界中のどこにいるか、あるいはどこかのオフィスの何階にいるかを教えてくれます。
おそらく40種類前後の色々なプロビジョニングコマンドがあると思います。MySQLのスタックを操作できます。フェイルオーバーもできますし、テーブルをdropすることも、バックアップすることも、クローンすることも、マイグレーションすることも、なんでもできます。アタックに対する緩和策を実行することも可能です。
基本的には、私たちのインフラに対して考えうることすべてを、Hubotを通じて行うことができるのです。どんなコードにもインタフェースは必要ありません。全部Hubotから実行できます。
つまり、自動化のエンジンであるにとどまらないという。。
そうです。それは自動化ではあるのですが、それだけにとどまりません。そういう背景があるという意味でもあるんです。
長い間、新人研修はチャットルームに入って他の社員が何をしているか見ることでした。みんな物理的には離れた位置にいますから、問題が発生した時には、アラートがチャットに表示され、チャットにいる人がみんな見えるようにグラフを引っ張り出すわけです。そうすると、誰が何をしているかみんなが見える。私は入社してから、チャットに入り、みんなの働き方や何をしているかを見ていただけで、その方法を学んだわけです。
以前働いていたチームで私がデバッグのようなことを行っていた方法を思い出すと、みんな各自のターミナルかダッシュボードに向かってグラフを眺め、その後しどろもどろでその方法を共有してみたり、ターミナルの出力を例として貼り付けたりしていたものです。
チャットでは、そこへ飛び込めばコンテキストは全てその中にあります。つまり、要するに車内の巨大なコンソールを得るようなものです。例えば、データベースの障害を示すアラートを受け取って数人がそこに飛び込むと、もう既に障害切り分けがされていて、問題に取り掛かられているのがわかるでしょう。大障害の際にも(滅多に起きませんが、恐ろしや)、実に協力的に一緒に行動できます。
Hubotを通じてステータスページや更新ページにツイートすれば、書き込もうとしたものを誰かがダブルチェックしてくれます。
これこそが協力的体験というべきで、さらに多くの企業がそれを受け入れています。巨大企業がこういった素晴らしいユースケースのためにHubotを使っているという話をあなたも聞くでしょう。本当に、これは注目すべき素晴らしいことです。
昔ながらの働き方、もう私はそこに戻れる気がしません。何かをやろうとするためにチャットを通じて協力する同僚やチームに囲まれるのに慣れてしまいました。伝統的な会社が解決できないようなたくさんのことができ、たくさんの問題を解決する、全く新しい働き方なのです。
