GitHubは、チームがテーブルにもたらしたさまざまな文化、規範、テクノロジースタックのすべてのために、ソフトウェア開発をどのように行ったかを根本的に再考する必要があった。彼らは、さまざまなチーム、システム、テクノロジーが協調して連携できるようにするマイクロサービスアーキテクチャに移行している。
GitHubのソフトウェアエンジニアリング担当副社長であるSha Ma氏は、QCon Plus 2020で、GitHubが将来のスケーリングに対応するために現在のRuby on Railsモノリスを進化させるために、どのようにマイクロサービスアーキテクチャを導入したのかについて話した。
GitHubは、データ分離 (既存のデータを機能グループでグルーピング、機能ドメインにまたがる既存のクエリの分割) からマイクロサービスアーキテクチャの実装を開始した。次に、彼らはコアサービスと、他のサービスを構築するための基盤として機能するために、関連する最初に抽出する必要があるモノリスを特定した。
Ma氏は、並行して、協調して動作する多数の小規模な独立して実行されるサービスをサポートするために、運用上どのように変更する必要があるかを検討したと述べた。また、毎回車輪の再発明をしなくても誰でも使用できる再利用可能なワークフローテンプレートを作成することで、マイクロサービスの採用を簡素化した。
モノリスからマイクロサービスへの移行は、単なるアーキテクチャ上の決定以上のものであるとMa氏は述べている。彼女は、それが組織内のすべての開発者に文字通り影響を与え、彼らの働き方とコミュニケーションの仕方を根本的に変えると述べた (コンウェイの法則) :
チームは、契約、境界、および非同期通信にもっと注意を払う必要があります。チームはまた、テクノロジースタックに関してより多くの自律性を獲得するにつれて、より多くの決定を下す必要があります。
「大きなモノリスからより分散されたマイクロサービスアーキテクチャに移行するのは、長くて骨の折れる旅です」とMa氏は述べている。彼女は、それが一夜にしてシフトすることはなく、おそらくスコープははるかに大きく、人々が当初予想していたよりもはるかに長い時間がかかるだろうと述べた。「文化のシフトが必要です。ベストプラクティスのトレーニングが必要です。仕事のやり方を変える必要があります」と彼女は言った。
InfoQは、GitHubがマイクロサービスへの移行を開始した理由、モノリスがもたらしてきた利点とその維持方法、直面した課題、移行が組織に与える影響、および学んだことについてSha Ma氏にインタビューした。
InfoQ: Githubでモノリスからマイクロサービスへの移行を開始することにした理由は何でしょうか?
Sha Ma氏: GitHubでは、この考え方にシフトした主な理由は、過去18か月で私たちがどのように成長したかによるものです。エンジニアリング組織は約400人から1000人になりました。
また、Semmel、NPM、Dependabot、Pull Pandaなどの買収を通じて、幅広いテクノロジースタックを迅速に導入しました。Rubyの学習やモノリスの強化に多大な時間を費やすことなく、誰もが生産的に作業を継続できるようにするために、私たちは別の方法で作業を開始し、現在のRailsアプリの外側で大規模な開発を可能にする経路を作る必要があると判断しました。
InfoQ: モノリスソリューションがもたらしてきた利点は何でしたか? どのようにそれらを維持するつもりでしたか?
Sha Ma氏: モノリスは私たちに多くの単純さを生み出しました。起動の単純さと実行の高速化、コードの記述方法の単純さ、知識の共有による単純さ。また、多くの共有ツールを構築し、特定のシステム (フィーチャーフラグ、データベース、CI/CDワークフローなど) のスケーリングに関する多くの深い知識を蓄積しました。
たとえば、高度な並列処理と前処理により、モノリス全体を10分以内に構築できます。同様に、デプロイメントプロセスではすでにカナリアデプロイをサポートしています。
時間をかけて築き上げてきたこの知識を最大限に活用したいと考えています。
InfoQ: どのような課題に直面し、どのように対処しましたか?
Sha Ma氏: GitHubでは、最初に「なぜ」に答え、このシフトの目標を明確に表現することから始めました。たとえば、私たちにとっては、既存のモノリスの置換については、開発チームの半分がモノリスの外側で作業できるようにすることよりも重要でした。現在のコードベースを引き続き維持および改善する必要があることや、トラフィックの100％を新しいサービスに移行する計画があることなど、いくつかの基本ルールを確立しました。これにより、使用されなくなった古いコードパスをシャットダウンできます。
また、個々のチームがマイクロサービスの旅を簡単に開始できるように、データの分離、コアサービスの抽出、共有ワークフローなどに関するグローバルなアーキテクチャ上の決定から始めました。
InfoQ: マイクロサービスへの移行は、Githubの組織にどのような影響を与えましたか?
Sha Ma氏: 組織的には、これにより、チームとオーナーシップの領域についてより意図的に考えるようになりました。それが明らかになった方法の1つは、オンコールの責務をどのように再考するかにあります。
以前は、すべてのドットコムの開発者 (ほぼ全体のエンジニアリング組織) が、モノリス全体のオンコール責務をローテーションしていました。エンジニアリング組織がどんどん大きくなるにつれて、これはいくつかの問題を引き起こしました。人々は実際にその腕力を構築するのに十分な頻度のオンコールをしていませんでした。また、コードベースが非常に大きく複雑になっているため、プロダクション環境のインシデントに陥った中では問題を特定するのが困難でした。
そのため、熱心なエンジニアの小グループが既存のサービスカタログを調べ、リーダーシップチームと協力して、コードの各セクションに明示的なオーナーシップを割り当てました。特定の領域で活発な開発が行われていない場合でも、単一のチームにコードが所有され追跡可能であることを確認しました。
InfoQ: 何を学びましたか?
Sha Ma氏: この移行を行うために、新機能の開発が長期間中断されないように、計画をまとめることが重要です。最初のマイクロサービスを実際に作成する前に「どのようにして」についての仮定をたて、(モノリス内で) 準備作業を開始します。これを反復プロセスにし、この移行の過程で最初の仮定を再評価します。