インタビューGitHub は、モノリシック アプリケーション アーキテクチャをマイクロサービスに分解する取り組みについて説明し、2018 年に Microsoft に買収された後も、一部のサービスを AWS 上で実行していることを明らかにしました。
GitHub のソフトウェア エンジニアリング担当 VP である Sha Ma 氏は、11 月の Qcon Plus 仮想開発者イベントでこのテーマについて講演し、その後私たちと少し時間を過ごしました。
オンライン コード シャックは世界で最も忙しいサイトの 1 つであり、5,000 万人を超える開発者によって使用され、1 億を超えるリポジトリをホストしています。
GitHubのソフトウェアエンジニアリング担当副社長Sha Ma氏がQcon Plus仮想開発者イベントで講演
GitHubは2008年にRuby on Railsウェブアプリケーションフレームワークを使って初めて構築されました。「GitHubのアーキテクチャはRuby on Railsに深く根ざしています」とMa氏は述べ、さらに「モノリシックなアーキテクチャのおかげでここまで来られた」と付け加えました。これには毎日複数のコードデプロイと「1日10億回以上のAPI呼び出しに対応できる」高い拡張性が含まれます。
コマンドラインインターフェースを使って作業できる環境は維持されるべきです。そのため、認証機能をモノリスの外部にコアサービスとして分離し、有効化することを優先しています。これにより、Webフロントエンドが利用できない状況でも、より多くのシステムを利用できるようになります。
サイトの規模を見れば、Ruby on Railsやモノリシックアーキテクチャはスケールしないという主張が誤りであることが分かります。では、なぜGitHubは今移行を進めているのでしょうか？
この決断はごく最近のことだとマー氏は語った。「今年の初めから始まりました。オックスフォードに拠点を置くSemmleをはじめ、多くの企業を買収しました。彼らの主な開発言語はCとPythonです。また、Dependabot、JavaScriptパッケージ管理のNPM、そしてPull Pandaも買収しました。社内では、マイクロソフト社内にあった姉妹チームをいくつか統合したため、Azure DevOpsの多くのメンバーがチームに加わり、C#からTypeScriptまで、あらゆる言語での作業に慣れています。」
「かつては単なるRuby on Railsの会社だったGitHubに加わった多様性は、私たちに考えさせました。技術スタックとスキルセットの多様性をもたらした開発者たちが、どのように協力して生産的に働けるようにするか？その考えから、モノリスを唯一の開発オプションとして使うことはもはや現実的ではないと気づいたのです。」
つまり、GitHub は Ruby から移行しているということですか?
「私たちの戦略は完全な置き換えではありません」とマー氏は述べた。「GitHubの創設者たちはRubyコミュニティに深く関わっていました。彼らは貢献者でした。」GitHubは長年にわたり、一流のRuby開発者を採用してきました。「実は、私たちは独自のRubyバージョンを保守しています」と彼女は語った。
GitHubでうまく機能するようになれば、Rubyオープンソースに貢献していきます。Rubyコードベースでは、GitHubのパフォーマンスを最大限に高めるために、高度なカスタマイズを施してきました。このやり方から完全に離れることはないと考えていますし、今でも多くの人がこのコードベースで高い生産性を発揮しています。私たちにとって、近い将来はハイブリッド環境になると思います。
パフォーマンスが重要なコードは、他の言語で書かれている場合もあります。「認証を分離した際に、モノリスの外側にあるサービスをGo言語で書き直すことになりました」と彼女は言います。
MySQLについてはどうですか?
MySQLは全体的に良好なパフォーマンスを示していますが、同社の障害報告の一部では問題として指摘されています。GitHubは別のデータベースマネージャーへの移行を検討したことがありますか？
「Rubyと同様に、当社には数多くのシステムの拡張を手がけてきた世界的に著名なDBA（データベース管理者）がいます。当面はMySQLを使い続けるつもりです。なぜなら、MySQLには豊富な専門知識があるからです」とマー氏は述べた。
さらに、機能グループをマイクロサービスに分割するプロセスにより、データの細分化も可能になります。「モノリス型でありながら、拡張性も確保できました」とMa氏は語ります。「パフォーマンス面でも、保存可能なデータ量でも、MySQLソリューションにはまだまだ多くの可能性が残されていると感じています。」
Microsoftによる買収はGitHubのインフラにどのような影響を与えましたか？買収前は、GitHubは主に自社のデータセンターでホストされていました。Azureに移行する予定はありますか？
「移行の可能性を検討しています」とマー氏は述べた。「実は、まだAWS上にホスティングしているものもあります。例えば、当社のデータ分析の多くはAWS上で行われており、Azureへの移行を検討するプロジェクトを開始しました。特に、社内価格設定がより有利なため、移行は特に重要です。しかし、当社のデータの80～90%は、物理的に管理しているデータセンターにホスティングされていると言えるでしょう。」
移行手順と落とし穴
Qconで、Ma氏は移行を実現するために同社が行っている取り組みの一部について説明しました。「優れたアーキテクチャはモジュール化から始まります」と彼女は述べました。「モノリスを分割するための最初のステップは、機能に基づいてコードとデータを分離することを検討することです。これは、マイクロサービス環境で物理的に分離する前に、モノリス内で行うことができます。」
彼女はまた、いくつかの落とし穴についても説明しました。「コードロジックを抜き出すことから始めても、モノリス内の共有データベースへの呼び出しに依存しているケースを数多く見てきました。これは多くの場合、分散モノリスにつながり、マイクロサービスのメリットを全く享受できずに複雑さを管理しなければならないという、最悪の事態に陥ってしまいます。」
Ma 氏は、「依存関係の方向は常にモノリスの内側から外側に向かうべきであり、その逆ではないことを念頭に置くことが重要です」と説明しています。
「モノリシックアーキテクチャからの移行において、データ分離を正しく行うことは不可欠です」とMa氏は述べた。「例えば、リポジトリに関連するもの、ユーザーに関連するもの、プロジェクトに関連するものをすべてグループ化しました。データベーススキーマの機能グループを作成することで、最終的にはマイクロサービスアーキテクチャに必要な異なるサーバーやクラスターにデータを安全に分割できるようになります。」
このプロセスは、ドメイン境界を越えるデータベースクエリを修正することを意味します。「GitHubでは、モノリスにクエリウォッチャーを実装し、クエリが機能ドメインを越えるたびに警告を発します。その後、これらのクエリを、ドメイン境界を尊重し、アプリケーション層で必要な結合を実行する複数のクエリに書き換えます」とMa氏は述べています。
GitHubのクラウドネイティブへの移行はどの程度進んでいるのだろうか？「それほど進んでいません」とMa氏は答えた。「まだ初期段階です。長年にわたり、Rubyの微調整方法やMySQLの微調整方法など、サイトを現在のパフォーマンスレベルに保つための多くの知識が蓄積されているからです。クラウドネイティブソリューションを検討するとしても、おそらくGitHub自体の中核ではない、Actionsや、再構築中のProjectsといった新しいサービスになるでしょう。」
GitHubはコンテナのオーケストレーションにKubernetesを使用していますか？「Kubernetesを積極的に活用しています。多言語対応や新規サービスの開発に対応するため、1年半前から複数のチームに共通する多くの要素をテンプレート化し始めました。Kubernetesテンプレートを備えた「microservices in a box」と呼ばれるシステムです。すべてのサービスにログ記録が必要なため、Splunkに自動的にログインしています。また、すべてのサービスをデプロイする必要があるため、既存のデプロイプロセスに自動的にデプロイされます。そのため、運用面では迅速に作業を開始できます。」
移行期間中、GitHubは新しいマイクロサービスの作成と同時にモノリスにコードを追加するのでしょうか？「もちろんです」とMa氏は言います。「私たちの戦略は置き換えではなく、有効化であるため、モノリス内のコードは維持・改善する必要があり、現在もその作業を行っています。」しかし、マイクロサービスが完成したら、既存のコードを完全に置き換えて使用するという考え方があります。そのため、「モノリスの内外で複数のバージョンを維持する必要はありません」。
認証の抽出は優先事項です。これは、ウェブサイトがダウンした場合でも開発者が作業を継続できるようにする役割を担っているためです。「GitHubがダウンすると、実際にはGitの操作が一切できなくなり、問題となります」とMa氏は語ります。「コマンドラインインターフェースを使って作業を継続できる必要があります。だからこそ、モノリスの外側にあるコアサービスとして認証を抽出し、有効化することを優先しています。これにより、Webフロントエンドが利用できない場合でも、より多くのシステムを利用できるようになります。」
GitHubがマイクロサービスアーキテクチャを実現したと言えるようになる時期の目安はありますか？「数年かかるでしょう」とMa氏は語りました。「この変化は単なるアーキテクチャ上の決定ではありません。文化的な変化でもあります。…最終的には、すべての新しいサービスがマイクロサービスとして構築される方向に引力が移り、既存のサービスの多くはモノリスから再構築・リファクタリングされるでしょう。しかし、当面は、少なくともモノリスの一部となるコアサービス群は引き続き運用していくことになるでしょう。」
これは実用的なアプローチです。「マイクロサービスは、技術的負債や不適切なアーキテクチャに対する解決策ではありません」とMa氏は語ります。「マイクロサービスの道を選んだ人が、マイクロサービスが扱いにくくなったためにモノリスに戻るという傾向が見られると思います。マイクロサービスは優れたアーキテクチャに取って代わるものではありません。何をグループ化すべきか？ドメインの境界を越えるものをどのように探すべきか？チームやオンコールをどのように構成すべきか？といった点を検討することで、モノリスとマイクロサービスの両方の世界でメリットのある、より優れたアーキテクチャのプラクティスへと導かれました。私たちが行っている多くの準備作業は、実際にはモノリスから抽出する前の段階で行っているのです。」®
