GitHubがどのようにDNSインフラストラクチャを改善したか

GitHubは、何年もの間、非常によく要求に応えてきた、かなりシンプルなDNSインフラストラクチャから、GitHubの規模で動き、よりよいサポートを提供する新しいアーキテクチャに移行したことについて、GitHubのシニアインフラストラクチャエンジニアのJoe Williams氏が書いている。

GitHubが、DNSを扱うために、新しいモデルにした理由のうち、多くのアプリケーションがDSNの解決性能や有効性の影響を受けやすいことについて、Williams氏は言及している。このことは、顧客のパフォーマンス低下の原因になるかもしれず、古いインフラストラクチャでは、特に、構成やコードを変更すると問題があり、機能が停止する可能性もある。その上、機能不全の根本原因を見つけるのは難しく、エンジニアが使えるツールは、tcpdumpだけだ。これらの問題を改善することの他に、GitHubエンジニアは、以下のことを目的としている。

• 内部向けゾーンや外部向けゾーンを扱う方法に柔軟性を与える。明示的に構成しなければ、外部から内部向けゾーンを見えないようにする。その一方で、内部ネットワークを出ることなく、外部向けゾーンに到達できることを保証する。
• キャッシュと権威間の役割の分離を改善する。
• 自動変更に対して、デプロイベースとAPIベースのワークフローの両方をサポートする。
• 信頼性を改善するために、いかなる外部依存も避ける。

GitHubが設計し、その結果としてのアーキテクチャは、3種類のノードを含む。

• キャッシュは、データセンタにあり、データセンタの境界を超えることを要求することなく、ライブデータをアプリケーションに供給する責任を持つ。
• エッジは、リージョンレベルで権威を持ち、キャッシュからの要求を扱って、データセンタのゲートウェイとして動く。そして、ゾーン転送の実行を管理する。
• 権威は、DNSマスタとしての機能を果たし、エッジノードからのゾーン転送を管理する。また、レコードの作成、修正、削除のHTTP APIを提供する。

GitHubの新しいDNSインフラストラクチャがもたらしたもう1つの分野は、ロギングだ。ロギングの要求に基づき、GitHubエンジニアは、キャッシュにはUnbound、エッジホストにはNSD、そして、権威にはPowerDNSを使うことを選んだ。

すでに述べたように、github.comドメインを使う外部向けのゾーンは、github.netドメインを使って、内部向けゾーンからアクセスできる。外部のDNSプロバイダで伝える必要はない。これは、Unboundによって可能になった。さらに、内部向けDNSが失敗した場合、外部ネットワークにアクセスするためのオプションもサポートする。

Williams氏の投稿には、さらに多くの詳細が書かれているので、ぜひ全部読んでみよう。