テクノロジーロードマップ
GitLab が成長・成熟し続けるにつれて、複数の大規模サイトでのより速い成長とエンタープライズへの注力が今後12ヶ月の主要課題となる重要な転換点に近づいています。これらはすべて、セキュリティ、可用性、パフォーマンスへの揺るぎない注力というコンテキストの中にあります。
これらの課題に対応するために、環境を運用する際に非常に高いレベルの予測可能性を達成する必要があります。これは、セルフマネージドインスタンスと GitLab サイトの両方をサポートするために必要な柔軟性を提供しながら、より厳格な標準化を伴い、高度なツールを活用した高度な自動化の使用を可能にします。しかし、予測可能性に対する高い信頼度があっても、リスクは管理しなければならない要因です: 環境に変更を加える際に必然的に問題が発生します。したがって、許容可能なリスクを定量化し、障害に直面した際に安定性を回復するために素早く対応し、単一のエンジニアリングユニットとしてそれを行える必要があります。
企業として、GitLab はソフトウェア開発の未来としてクラウドネイティブを提唱しています: 顧客は GitLab から完全な DevOps プラットフォームとして提供される単一アプリケーション（Issue トラッキングとソースコード管理から CI/CD と監視まで、組み込みのコンテナレジストリと Kubernetes 統合を含む）として恩恵を受けます。このモデルを私たち自身が完全に取り入れる必要があります。このコンテキストでは、最も重要な技術的戦略的投資はステートレスコンポーネントにおける私たち自身のクラウドネイティブへの完全移行になります。これにより、フィーチャーの革新と倹約を保ちながら、スケールでさまざまな設定を操作・微調整する能力が得られます。それと並行して、こうした顧客によって課せられる厳格な要件を満たすためのエンタープライズレベルの機能も開発する必要があります。
マルチラージサイト: クラウドネイティブ
クラウドネイティブは、クラウドコンピューティングを中心に構築されたアプリケーション開発・運用へのアプローチであり、個々のマシンからオンデマンドのクラウドリソースに依存してエンドレスな変更ストリームに適応しながら高いサービスレベルを提供するサービスへと焦点を移します。コンテナなどの技術と、一貫した方法で高頻度でデプロイするマイクロサービスなどの戦略に依存しています。これは最大の追い風に対する私たちの信念に反映されており、高度な予測可能性を可能にし、サービスレベルをより適切に管理できるようにします。
今日、GitLab はモノリシックな GitLab Rails コードベースといくつかのサポートサービス（Gitaly、GitLab Workhorse、Registry、CI ランナー、GitLab Shell、GitLab Pages など）で構成されています。GitLab はすでにクラウドネイティブのいくつかの側面を採用していますが、成功するためにはこのモデルに近づく必要があります。
ただし、クラウドネイティブへの全面的な切り替えはできません: 2つの並行しているが異なるパス（複数の大規模サイトでスケールしながらセルフマネージドインスタンスをサポートする）に沿って実行するさまざまな環境をサポートする単一のコードベースを進化させる必要があります。したがって、クラウドネイティブのより完全な採用に着手する際も、両方のパスにまたがるバランスを見つけ、一方から他方への必要な移行を可能にする必要があります。このバランスには、暴走したマイクロサービスの管理不可能なセットを作るという罠に陥ることなく適切な場合にモノリスから特定のワークロードを抽出する機会を特定しながら、このコンテキストでいくつかのサポートサービスがどのようにスケールするかを再考することを含めて、ニーズを継続的に評価することが求められます。
ステートのコンパートメント化
コンテナ技術を採用するためには、特に共有 POSIX ストレージ（NFS）を使用するものにおいて、可能なすべてのアプリケーションコンポーネントから共有ローカルステートを削除する必要があります。ビルドログと GitLab Pages は環境内での NFS の主要な2つのユーザーであり、この依存関係は排除される必要があります。
現時点ではステートフルサービスをクラウドネイティブに移行しませんが、クラウドネイティブ機能に合わせる必要があります。特に、メインデータベース（Postgres）はアプリケーションでクラウドネイティブ戦略をサポートする必要があります。そのために、ほぼゼロダウンタイムの Postgres アップグレード（つまり、せいぜいデータベースのフェイルオーバーのみを必要とするアップグレード）を実装する必要があります。これはデータベース論理レプリケーションによって行われ、スケールでデータベース変更を検証するための本番環境に似たデータとトラフィックを持つテスト環境を提供します。
クラウドネイティブを採用する上での重要な側面は Registry であり、現在、データベースリソースへのより緊密な依存から始まる大規模な変更が進行中です。Registry なしでは、クラウドネイティブは機能しません。
リスクの管理
変更は環境にリスクをもたらす主要なチャンネルです。CI/CD において大きな進歩を遂げており、デプロイメントの頻度は今や時間単位で測定されます。より高いデプロイメント速度では、デプロイメント後のリスクを慎重に管理するためのツールが必要です。フィーチャーフラグは変更を早期に出荷し、安全に広いオーディエンスに展開するための重要なツールであり、フィーチャーが安定しておりパフォーマンスが高いことを確保します。GitLab はすでにフィーチャーフラグを広範に使用していますが、現在の実装はリスク管理をサポートする際の潜在能力を全力発揮するためにスケールする必要があります。また、回復不可能な失敗した変更のロールバックも実行できる必要があります。
最終的に、リスクを定量化し、それによってどれだけ受け入れる意思があるかをさらに定量化できる必要があります。エラーバジェットはこれを行うためのフレームワークを提供します。エラーバジェットへの組織的な遵守により、エラーバジェットが枯渇した後に何が起こるかを組織として処理するために必要なステップを考えることができます。したがって、エラーバジェットの完全な技術的・組織的実装を提供する必要があります。
エンタープライズ
ディザスタリカバリ
エンタープライズに深く入り込むにつれて、特にマルチラージサイトのコンテキストでは、ディザスタリカバリが純粋に技術的な要件から重要なビジネス上の懸念事項へと移行する重要な機能になります。ディザスタリカバリはセルフマネージドインスタンス上の Geo を通じて管理されていますが、GitLab.com はサイズと成長の両面でスケールにおいて特別な課題を提示しています。さらに、GitLab.com は幅広いユーザーを持つパブリックインスタンスです。Geo はインスタンスレベルで動作しますが、これは GitLab.com には適していない場合があります。GitLab.com のディザスタリカバリ要件（リカバリタイム、ユーザータイプ）を決定し、この独自の状況を処理するために Geo を有効化するよう取り組む必要があります（これは時間の経過とともに他のマルチラージサイトに影響します）。ディザスタリカバリワーキンググループは前述の質問に回答する任務を負っています。
リポジトリストレージ
リポジトリストレージを強化するための多くの作業が行われており、この作業を完了させる必要があります。特に、Gitaly クラスタリングは、顧客の需要を満たすために必要な可用性、耐久性、パフォーマンスの適切なレベルを提供するストレージ階層の管理において重要です。
コスト管理
DevOps がアプリケーション開発、デプロイメント、管理を合理化するにつれて、コストはアプリケーションが対処しなければならない懸念事項になります。リアクティブからプロアクティブなコスト管理へとシフトする必要があります: アプリケーションが新しい機能とスケールを獲得するにつれてコストフットプリントも増加し、これらはアプリケーション外でリアクティブな基準だけでは完全に管理できません。アプリケーション自体がコスト管理を支援するための認識を持つ必要があります。この認識は主に基礎となるインフラ技術との統合を通じてもたらされます。これはクラウドネイティブ戦略とよく整合しています: アプリケーションが堅牢なサービスを提供するために必要なインフラの量を管理している場合、リソースにタグを付け、コストを最適化・管理するための意思決定を提供するために必要なメタデータも提供できる必要があります。
ロードマップ
取り組まれているおよび進行中のすべてのアーキテクチャブループリントの単一リストは、アーキテクチャタスク Issue ボードにあります。
