課題
GitHubの400万ものユーザーの検索ニーズを満たすと同時 に、顧客サービスの継続的な向上に役立つ運用の洞察を 提供するにはどうすればよいか。
ソリューション
Elasticsearchを利用して、重要なイベントデータと800万 以上のコードリポジトリをインデックス化。
概要
エンドユーザーと開発者の両方にとって強力な検索が可能に
- ApacheSolrからElasticsearchへの移行により、スケ ールアウトが可能になり急激に拡大するユーザーのニ ーズ対応に
- ほとんどのタイプのデータをインデックスして検索可 能に
- 開発者アプリケーションでプログラムによる高度な検 索が可能に
- 新しいデータのアップロードをほぼリアルタイムでイン デックス化
検索データの分析から洞察
- インデックスされたログデータからクエリを実行して 不正ユーザーを検出
- すべてのアラート、イベント、ログをインデックスし、特 定のコードの例外の割合を追跡して、GitHubプラット フォーム内のソフトウェアバグを発見
- 標準SQL以上のクエリを作成
上級ユーザーのための高度な検索
GitHubは、世界最大のソフトウェア開発プロジェクトのための 共有Webサービスであり、その顧客ベースは、要求レベルの高 い400万人以上のテクニカルユーザーで構成されています。この GitHubの検索を支えているのがElasticsearchです。GitHubで はElasticsearchを利用し、コードリポジトリ数800万以上、ドキ ュメント数20億以上の拡大し続けるデータを常にインデックス 化しています。Elasticsearchを利用したことで、GitHubのユー ザーはこのデータを簡単に検索できるようになりました。
GitHubの運用エンジニアであるTim.Pease氏は次のように 述べています。「検索はGitHubの中核部分です。GitHub.com/ searchにアクセスすれば、リポジトリ、ユーザー、イシュー、プル リクエスト、ソース コードすべてを検索できます。」
GitHubがElasticsearchを導入した目的の1つは、GitHub.com で公開・提供されているものすべてをインデックスして、見つけ やすくすることです。当然、フルテキスト検索は完全にサポート されますが、幅広い条件に基づく検索も可能で、操作はきわめて 簡単です。
「Clojure を主要な言語として使用し、前月アクティビティのあっ たプロジェクトといった条件で検索ができます。こうした機能は すべて Elasticsearch によって動いているのです。」(Pease 氏)
Elasticsearchの柔軟なアーキテクチャにより、構造化データも 非構造化データも区別なく保存・検索できます。また、広範囲に わたる検索機能を組み合わせることで、極めて容易に検索を実 現できます。
「Elasticsearchを使用すると、標準のSQLデータベースではサ ポートされていない多くのクエリをデータに対して実行できま す。」(Pease 氏)
ファイアウォール内のセキュリティ分析に関する洞察を 提供
GitHubでは、Elasticsearchの検索インデックスと分析の機能 を組み合わせて複数のプロジェクトを推進しています。たとえ ば、GitHubでは、Elasticsearchクエリの分析機能を利用する と、保存されている監査データとログデータを使用してユーザー のセキュリティ関連のアクティビティを追跡できることに気付き ました。
「Elasticsearchクエリを使用して、ユーザーが実行したアクシ ョンの1つ1つをすぐに確認できます。そのため、アカウントの盗 難や乗っ取りがないか、ユーザーが不正な行為をしていないか を的確に監視できます。」(Pease 氏)
GitHubは、GitHub.comに搭載されているさまざまなソフトウ ェアコンポーネントで生じるコードの例外を追跡・分析する方法 を検討し、当初検討したのは一般的なNoSQLデータベースでし た。当時、コード例外は2次インデックスに保存され、分析機能 を使用して例外の経時分析が行われ、結果は再びデータベース に保存されていました。
GitHubのテクニカルスタッフであるGrant Rodgers氏は次のよ うに述べています。「NoSQLデータベースはGitHubのユースケ ースには適していませんでした。すべてをElasticsearchに移行し てそのヒストグラムファセットクエリを使用したところ、非常に うまく機能しています。」
GitHubではElasticsearchのヒストグラムファセットクエリ機 能と、その他の統計ファセットを使用して、特定のタイプのコー ド例外が占める割合の増加を追跡しています。このプロセスに より、ソフトウェアシステムのバグが明らかになっています。
「Elasticsearch のヒストグラムファセットクエリ機能はきわめ て有効であるため、このアプリケーションの使用をさらに拡大 することを検討しています。」(Rodgers 氏)
「Elasticsearchクエリを使用して、ユーザーが実行したアクシ ョンの1つ1つをすぐに確認できます。そのため、アカウントの盗 難や乗っ取りがないか、ユーザーが不正な行為をしていないか を的確に監視できます。」
数百万ものユーザーに合わせて拡張
GitHubでは当初、検索にSolrを使用していましたが、Solrは効 果的な拡張ができず、管理のしやすさという点でも不十分でし た。
「GitHubの利用者が増えるにつれ、1つのSolrクラスタとSolr インスタンスで処理できるストレージ スペースではすぐに足りな くなりました。」(Pease 氏)
社内のデータをSolrでシャーディングして負荷に対処する か、Elasticsearchに移行するかの選択を迫られましたが、迷い はありませんでした。Elasticsearchのシャーディング機能の方 が優れていると判断し、移行を決定しました。」(Pease 氏)
Elasticsearchの自動シャードリバランス機能により、パフォー マンスが向上し、フェイルオーバー状況に対応できます。レプリ カシャードは、クラスタ内の新しいノードに自動的に分散され、 ノード障害の場合は、シャードは自動的に障害ノードから稼働ノ ードに移行されます。
高度なシャーディングによる高パフォーマンス
20億以上のドキュメントがすべてElasticsearchでインデックス され、ユーザーによるコードのアップロードや変更が絶えず行わ れている環境においては、検索のパフォーマンスが重要な指標 となります。GitHubでは、平均で1分あたり300件の検索要求を 処理しています。
ユーザーがGitHubのリポジトリに新しいコードをプッシュする と、すぐにElasticsearchでインデックスされます。データは直ち に検索可能になり、パブリックリポジトリだけでなく、ログイン ユーザーであればアクセス権のあるプライベートリポジトリにつ いても検索結果が返されます。
検索データへのアクセスを最適化するために、GitHubでは広範 囲にシャーディングを使用しています。GitHubのElasticsearch メインクラスタには、シャードが約128個あり、各シャードには およそ120GBが保存されています。
1つのリポジトリ内での検索を最適化するために、GitHubではリ ポジトリIDに基づいたElasticsearchルーティングパラメータを 使用しています。「そうすることで、1つのリポジトリのソースコ ードを1つのシャードに配置できるのです。ユーザーが1つのリポ ジトリページでのみ検索を実行すると、実際に1つのシャードだ けが検索されます。GitHubのメイン検索ページからの検索に比 べ、このようなクエリは速度が2倍になっています。」(Pease 氏)
