GitHubのWebとAPIをベアメタル上のKubernetesに移行する

GitHubは昨年1年間、github.com用のRuby on Railsアプリケーションとapi.github.comをKubernetes上で運用するための内部インフラストラクチャ拡張に取り組んできた。このマイグレーションは、Unicornプロセス上で動作するWebとAPIアプリケーションをPuppetで管理されるベアメタル(“メタルクラウド”)サーバへデプロイすることから始まり、メタルクラウド上にデプロイされたKubernetes内で動作するコンテナですべてのWeb要求とAPI要求を処理するようになった時点で完了した。

GitHubのエンジニアリングブログによると、GitHubにおけるデプロイと実行のアプローチは、運用開始から8年間にわたって基本的に大きく変わっていない。一方でGitHub自体は、新機能やソフトウェアコミュニティの拡大、職務を行なうGitHubberの増加、秒単位のリクエスト数の大幅な増加によってドラマティックに変化している。組織の拡大に伴い、既存の運用アプローチに新たな問題が顕在化するようになった – 独立して実行およびデプロイできる小規模サービスに機能を分割したいというチームが多くなったことや、サービスの数が増えてSREチームのメンテナンス作業時間が増えたため、基盤プラットフォームの拡張に十分な時間を割けなくなったことなどだ。GitHubのエンジニアには、新たなサービス実験やデプロイメントやスケールアップを行なうための、セルフサービスのプラットフォームが必要だった。

最初に評価したのは、他のプラットフォームと比較した場合のKubernetesの傑出した特質 – プロジェクトを精力的にサポートするオープンソースコミュニティの存在、最初の試験において数時間で小規模クラスタとアプリケーションのデプロイメントが可能であるという初期エクスペリエンス、さらには、acmqueueの記事“Borg, Omega, and Kubernetes”に代表されるように、“その設計を動機付けたエクスペリエンスに関する情報量が豊富であること”などだった。

プロジェクトの初期段階において、GitHubチームは、重要なWebトラフィックのワークロードをあえてマイグレーション対象にする、という決断を下した。この決定には多くの理由があった。例えば、

• このアプリケーションに関しては、GitHub全体が深い知識を持っているため、それがマイグレーションのプロセスで有効だと思われたこと。
• チームが開発した習慣やパターンが、大規模なアプリケーションにも小規模なサービスにも適していることを確認したいと考えていたこと。
• 重要で可視性の高いワークロードのマイグレーションによって、GitHubにおける今後のKubernetes採用の促進が期待されること。

マイグレーション対象に選ばれたワークロードの重要性を考慮すれば、実際のトラフィックを処理する前に、高いレベルの運用信頼性が必要だった。そのためにプロトタイプとして、いくつかのKubernetes“レビューラボ”クラスタが立ち上げられた。最終的に構築されたのは、任意のプルリクエストに対してGitHubの独立したデプロイメントを作成するための、チャットベースのインターフェースだった。各ラボは最終デプロイの翌日にクリーンアップされて、それぞれのKubernetesネームスペースを持ったものが新たに作成される。クリーンアップは単にネームスペースを削除すればよく、必要に応じてデプロイメントシステムが自動的に実行する。

GitHubのフラッグシップであるWebサービスに必要なパフォーマンス要件と信頼性要件を満足する – それには他データサービスに対する低レイテンシのアクセスが必要だ – ため、Kubernetesインフラストラクチャは、GitHubの物理データとPOPの動作するメタルクラウド上に実装された。この取り組みには多数のサブプロジェクトがかかわった。具体的には、Project Calicoネットワークプロバイダを通じたコンテナネットワーキングの利用、Kelsey Hightower氏のチュートリアル“Kubernetes the Hard Way”の実施、KunernetesノードとKubernetes APIサーバ構成定義のPuppet化、Kunernetes NodePort ServiceをサポートするためのGitHubの内部ロードバランシング(GLB)の拡張などである。

GitHubのデプロイメントシステムを拡張し、既存の運用サーバと併用する形で新たなKubernetesリソースのセットをgithub実運用ネームスペースにデプロイ可能にした上で、機能をトグルするFlipper方式のクッキーに基づいてルーティング関連のリクエストをサポートできるようにGLBを拡張することにより、ミッションコントロールバーのボタンひとつで、試験的なKubernetesバックエンドにオプトインすることが可能になった。内部ユーザによるロードが、問題の特定やバグ修正、さらにはKubernetesの運用に習熟する上で役に立った。

いくつかの初期障害テストでは、当初予想していなかった結果が得られた。特に単一ノード障害をシミュレートしたテストでは、実行中のワークロードの可用性に悪影響を与える形でクラスタが停止した。サービスを中断するような方法でデグレードしたKubernetesクラスタの状況を見て、現在のWebアプリケーションは、それぞれの物理サイト内の複数のクラスタ上で運用されている。また、不安定なクラスタから健全なクラスタに要求を転送するプロセスはすべて自動化された。

フロントエンドの移行は1ヶ月強で完了し、パフォーマンスとエラー率については目標値を維持することができた。マイグレーション作業中には、今日まで未解決な問題がひとつ発生している – ロードないしコンテナのチャーン率が高い状態において、Kubernetesノードのいくつかにカーネルパニックと再起動が発生するのである。SREチームはこの状況に満足せず、高い優先度で調査を継続しているが、幸運なことにKubernetesには、このような障害を自動的に回避して、目標とするエラー範囲内でトラフィック処理を継続する機能が備えられている。

GitHubエンジニアリングチームは、“このアプリケーションをKubernetesに移行した経験で自信を得た”。当初マイグレーションは、ステートレスなワークロードに意図的に制限されていたが、例えばStatefulSetsを使用して、Kubernetes上でステートフルなサービスを実行するパターンの試験を前向きに計画中である。

GitHubのKubernetes採用に関するより詳しい情報は、GitHub Engineering Blogで見ることができる。