シャーディング ワーキンググループ

このシャーディング ワーキンググループの当初の焦点は、100倍のスケーラビリティという長期目標を持つデータベースのスケーラビリティを向上させることでした。

属性

プロパティ値
作成日2020年2月11日
終了日2020年6月22日
Slack#wg_database-sharding（社内からのみアクセス可能）
Google Docシャーディング ワーキンググループ アジェンダ（社内からのみアクセス可能）
録画シャーディング ワーキンググループ プレイリスト

成果 - クローズ

私たちはこのシャーディングに焦点を当てたワーキンググループをクローズし、異なる焦点を持つスケーリング ワーキンググループを開設することにしました。このシャーディング ワーキンググループの当初の焦点は、100倍のスケーラビリティという長期目標を持つデータベースのスケーラビリティを向上させることでした。このグループ発足時には、6〜12ヶ月以内にデータベースのスケーラビリティの限界に達するという理論がありました。その後の分析とインクリメンタルなスケーラビリティへの取り組みにより、私たちには大幅に余裕があることが示されました。分析に基づき、現在のアーキテクチャが今後12ヶ月の需要に十分対応できると高い確信を持っています：データベース容量と飽和分析（イテレーション1）。この分析は毎月継続されます。また、データベースチームによって優先付けされたインクリメンタルなデータベーススケーラビリティの改善領域も特定しました：GitLab.com の PostgreSQL データベースの合計サイズと成長を削減。継続的な分析とインクリメンタルなデータベース改善により、データベーススケーラビリティの緊急性が大幅に低下しました。

さらに、私たちはシャーディングが長期的なスケーラビリティニーズに対する望ましいアプローチではないというコンセンサスに達しました。この決定は調査、概念実証、研究、インタビュー、さまざまな実装提案を通じて形成されました。このワーキンググループをクローズする決定に貢献した項目の簡単なリストを示します：

このワーキンググループのコアメンバーは、長期的なスケーリング戦略と実装を決定するためにスケーリング ワーキンググループに引き続き参加します。このワーキンググループページの残りの部分は参照目的のために残されます。

ビジネス目標

GitLab.com で現在持っているものより100倍の余裕を提供するスケーラビリティアプローチ。さらに、顧客データを分離する機能がデザインと実装に影響する要因となっています。

背景

このワーキンググループ発足時、予測される顧客の成長をサポートするためにデータベースのスケーリングの「限界に達する」という逸話的な情報がありました。早期の見積もりでは、6〜12ヶ月後にスケーリングの限界に達すると予測していました。この見積もりはデータベース容量と飽和分析（イテレーション1）によって継続的な12ヶ月のウィンドウに改訂されました。データベースのスケーラビリティを向上させつつ、パフォーマンスも向上させるソリューションとしてデータベースシャーディングが提案されました。その後、議論の範囲をデータベースシャーディングだけに焦点を当てることから拡大しています。データベースシャーディング技術を使用したソリューションであっても、重大なアプリケーションの変更が必要になります。

顧客の分離の目標は複数の目的を果たします。顧客データの分離には、おそらくデータを複数のサーバーに分散させることが含まれます。このレベルの分散により、単一のデータベースアーキテクチャの単一障害点を排除することで可用性が向上します。また、顧客データをより良く分離するソリューションを提供するよう顧客からより多くのリクエストを受けています。

調査領域

スケーラビリティと顧客の分離というビジネス目標をサポートするために、以下の調査領域を特定しました。

名前空間シャーディング

詳細は Postgres シャーディング（&1854） Epic に記載されています。この調査領域は最上位の名前空間でのシャーディングに焦点を当てています。初期の調査はデータベースを中心にテーブルのシャーディングに焦点を当てていました。調査により以下のことが示されました：

テナントシャーディング

テナントシャーディングというタイトルの提案が最近導入されました。名前空間でシャーディングする代わりに、テナントという上位エンティティを導入します。テナントエンティティを導入することで、GitLab.com は SAAS マルチテナントアプリケーションのモデルでマルチテナント SAAS プラットフォームになります。よく知られた例としては Slack、Pagerduty、Datadog などがあります。これらの例は各々ユーザーにスコープ付きの分離されたテナンシーを提供しています。

インクリメンタルなスケーラビリティ改善

シャーディングの調査と並行して、データベースチームはインクリメンタルなデータベーススケーラビリティ改善の領域を継続的に探しています。これらの取り組みはこれらの Issue / Epic の下で追跡されています：

データベースパーティショニングの実装

パーティショニングはシャーディングとは別に扱う重要なテーマです。データベースシャーディングが私たちのビジネス目標を達成するための選択されたソリューションであると最終的に決定した場合、データベースパーティショニングは PostgreSQL でデータベースシャーディングが構築される基盤です。シャーディングに使用しない場合でも、パーティショニングはクエリパフォーマンスを直接向上させるため、それ自体でも優れたツールです。データベースパーティショニングの最初のイテレーションは監査イベントに実装されます。パーティショニングの実装によりパフォーマンスの向上とツールの実装（例：マイグレーション）が達成され、その後のパーティショニングとシャーディングの実装に活用できると考えています。

調査サマリー

名前空間とテナントという異なるシャーディングアプローチが評価されています。これらは競合するアプローチですが、どちらも同じビジネス目標の達成という目標を持っています。私たちはまだ潜在的な最初のイテレーションとこれらのアプローチの実装の詳細に取り組んでいます。どちらの場合も、データベースとアプリケーションレベルで必要な変更を特定し定量化する必要があります。

名前空間とテナントのシャーディングの調査を続ける一方で、インクリメンタルなスケーラビリティ改善とデータベースパーティショニングの実装を継続し、すぐにパフォーマンスとスケーラビリティの向上を実現できます。

完了基準

役割と責任

ワーキンググループの役割担当者職位
エグゼクティブステークホルダーChristopher LefelhoczVP of Development
ファシリテーターCraig GomesEngineering Manager, Database
シャーディング ワーキンググループ DRICraig GomesEngineering Manager, Database
機能リードNailia IskhakovaSoftware Engineer in Test, Database
機能リードJosh LambertGroup Manager, Product Management, Enablement
機能リードGerardo “Gerir” Lopez-FernandezEngineering Fellow, Infrastructure
機能リードStan HuEngineering Fellow, Development
機能リードAndreas BrandlStaff Backend Engineer, Database
メンバーChun DuDirector of Engineering, Enablement
メンバーPat BairSenior Backend Engineer, Database
メンバーTanya PazitnyQuality Engineering Manager, Enablement
メンバーMek StittriDirector of Quality Engineering

ミーティング記録

アジェンダドキュメントは「Sharding Working Group Agenda」で検索すると Google Drive で見つかります。

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License