gRPC-Go エンジニアリングプラクティス
新年の始まりにあたり、gRPC-Go プロジェクトに参画して最初の丸1年が経とうとしています。この機会に、gRPC-Go の開発状況と、プロジェクトの管理方法についてご報告したいと思います。私自身、オープンソースプロジェクトに本格的に貢献するのはこれが初めてなので、今年は私にとって学びの多い年でした。この1年間、チームは作業習慣とコミュニケーションを継続的に改善してきました。まだまだ改善の余地はあると思いますが、1年前と比べると格段に良い状態にあると信じています。
リポジトリの健全性
私が gRPC-Go チームに加わった当初、以前のテクニカルリードが数ヶ月間不在でした。その当時、PR は 45 件オープンされており、最も古いものは1年以上前のものもありました。新チームメンバーでありメンテナーとして、古い PR の蓄積は、優先順位の評価や状況の把握を困難にしていました。コントリビューターにとって、PR を放置することは無礼であり、他のコミットとのコンフリクトでリベースを要求する際に不便をもたらすものでした。この状況を解決するため、私たちはそれらの PR のマージまたはクローズに全力を尽くし、現在では、状況が再発しないように、毎週会議でアクティブなすべての PR のステータスを確認しています。
同時に、103 件のオープンなイシューがありましたが、その多くは既に修正済み、または古い、あるいはトリアージされていませんでした。それ以来、それらのうち 85 件を修正またはクローズし、毎週ローテーションで新しいイシューのトリアージと優先順位付けを行うプロセスを導入しました。PR と同様に、毎週の会議で担当イシューと高優先度イシューもレビューしています。
新規イシューと PR に対する継続的な SLO は、トリアージと最初の応答まで 1 週間です。
整理のために、イシューと PR の ラベル も一新しました。通常、すべてのイシューに優先度 (P0-P3) とタイプ (例: Bug, Feature, Performance) を適用します。また、様々な状況で適用するステータスラベルのコレクションもあります。タイプラベルは、リリースノートの生成を容易にするために、PR にも適用されます。
バージョン管理と後方互換性
最近、バージョンポリシー を文書化しました。私たちの目標は、実験的な API やセキュリティリスクの軽減 (特に #1392) を除く、限られた状況を除いて、完全な後方互換性を維持することです。もし、動作の回帰に気づいた場合は、遠慮なくリポジトリで イシューを開いて ください (ただし、常識的に お願いします)。
gRFC
gRPC の 提案リポジトリ には、事前に設計が必要な gRPC の大幅な機能変更に関する提案が含まれており、これらは gRFC と呼ばれます。このプロセスの目的は、可視性を提供し、コミュニティからのフィードバックを募ることです。各変更は、私たちの メーリングリスト で議論され、変更が行われる前に検討されます。私たちは、後方互換性を壊すメタデータ変更 (gRFC L7) を行う前にこれを利用し、新しいリゾルバ/バランサー API の設計 (gRFC L9) にも利用しました。
リグレッションテスト
私たちのリポジトリのすべての PR は、単体テストとエンドツーエンドテストに合格する必要があります。現在のテストカバレッジは 85% です。リグレッションが特定された場合は、失敗したシナリオをカバーするテストを追加し、問題が修正されたことを証明するとともに、将来的な再発を防ぎます。これは、全体的なカバレッジ数も向上させるのに役立ちます。また、すべての PR に対してカバレッジレポートを再度有効にする予定ですが、非ブロッキング方式で行います (関連イシュー: 関連イシュー)。
正確性のテストに加えて、パフォーマンスに影響を与えると疑われる PR は、ベンチマークを実行します。私たちの オープンソースリポジトリ 内と、Google 社内にもベンチマークセットがあります。これらは、ストリーミングとユニタリーの両方で、ユーザーにとって最も重要だと考える様々なワークロードで構成されており、一部は最適な QPS、スループット、またはレイテンシを測定するように特別に設計されています。
リリース
gRPC-Go の GA (General Availability) リリースは、2016年7月に他の言語と同時に行われました。チームはそれから2016年末まで数回のパッチリリースを行いましたが、リリースノートは含まれていませんでした。その後のリリースでは、定時性 (6週間ごとにマイナーリリースを実施) とリリースノートの品質が向上しました。また、パッチリリースにも迅速に対応しており、オンデマンドまたはより深刻な問題に対しては、1週間以内に古いリリースにバグ修正をバックポートしています。
リリースを行う際には、リポジトリ内のテストに加えて、他の gRPC 言語実装との相互運用性テストの完全なスイートも実行します。このプロセスはうまく機能しており、将来のブログ投稿でさらに詳しく説明します。
オープンソース以外の作業
私たちは、gRPC の開発において「オープンソースファースト」のアプローチをとってきました。これは、可能な限り gRPC の機能はオープンソースプロジェクトに直接追加することを意味します。しかし、Google のインフラストラクチャ内で作業するために、私たちのチームは gRPC の上にさらに機能を追加する必要がある場合があります。これは通常、stats API や インターセプター、または カスタムリゾルバ のようなフックを通じて行われます。
Google の gRPC の内部バージョンをオープンソースバージョンに追随させるために、週次またはオンデマンドでインポートを行っています。インポートの前には、gRPC に依存する Google 社内のすべてのテストを実行します。これにより、オープンソースでのリリース前に問題を検出する別の方法を得ることができます。
今後の展望
2018年には、これまでと同様のことをさらに行い、イシューへの対応とプロジェクトへの貢献の受け入れに関する SLO を維持する予定です。また、貢献したいと考えている方々がより多くのイシューを選択できるように、「Help Wanted」ラベルをより積極的に付けるようにしたいと考えています。
gRPC 自体については、現在、パフォーマンスが主要な焦点の一つであり、これが多くのユーザーに透過的に利益をもたらすことを期待しています。短期的に、高並行性においてレイテンシを 30% 以上削減し、QPS を約 25% 向上させるはずの、エキサイティングな変更を完了させています。その作業が完了したら、次に パフォーマンス関連のイシュー のリストに取り組む予定です。
ユーザーエクスペリエンスに関しては、より良いドキュメントを提供したいと考えており、godoc のコメントと例を改善し始めています。gRPC を使用する全体的なエクスペリエンスを向上させたいと考えているため、分散トレーシング、モニタリング、テストに関するプロジェクトと密接に連携し、本番環境での gRPC サービスの管理を容易にする予定です。さらに多くのことを行いたいと考えており、これらの取り組みから始め、フィードバックに耳を傾けることで、着実に改善をリリースできることを期待しています。