こんにちは！なぜ大手テクノロジー企業が自社のインフラストラクチャ向けに独自のソリューションを開発することに執着するのかについて話したいと思います。答えは明らかのようです。それは NIH 症候群にほかなりません。しかし、この答えは客観的であることは言うまでもなく、完全とは程遠いです。 私は Yandex プラットフォーム エンジニアリング チームの CTO であり、私たちの目標は、コードの作成からサービスの運用に至るまで、開発サイクル全体の構築をエンジニアが効率化できるように支援することです。これにはプロセスの合理化も含まれます。私たちは、as-a-service サービスを開発するだけでなく、社内での導入も支援します。これは Yandex の規模で機能します。当社のサービスは社内の何千もの開発者によって使用されています。 開発サイクルを組織するためのツールの例 問題を解決するために、既製のツールを実装するのではなく、独自のツールを開発することがよくあります。たとえば、私はまだチームのプログラマーでしたが、C++ と Python で定量監視システムに取り組み、それを数百億の処理済みメトリクスに拡張するのを支援しました。したがって、私自身の経験に基づいて、どのような動機と開発経路が社内ツールの出現につながるかを知っています。以下では、当社のソリューションを例として使用して、その作成の根本的な理由を特定してみます。 ストーリー #1: Yandex 内部クラウド 社内ランタイム クラウド (RTC) の目標は、社内ユーザーにシンプルな展開およびトラフィック管理ツールを提供することです。 RTC ユーザーは、Yandex サービスを開発するエンジニアと同じです。そして、どこかで作成した何万ものアプリケーションを起動し、そこにユーザーリクエストを送信し、負荷を分散し、インシデントに対処するなどの作業を行う必要があります。 タスクの設定。 社内クラウドの必要性が浮上したのは 2010 年代初頭で、サービスの数はすでに数百に上り、割り当てられたコアの総数は年間数十パーセント増加していました。各サービスに専用サーバーを設置すると法外なコストがかかるため、単一サーバー上で複数のサービスのアプリケーションを実行できるツールが必要でした。当初、これらのツールにはいくつかの要件がありました。 運用リソースを節約し、リリース中のインシデントの数を減らすために、日常的なアクションを自動化する必要があります。 別の重要なタスクは、特にほとんどのサービスの負荷に日次パターンがあり、夜間はクラウドがアイドル状態だったため、クラウドの使用率を高めることでした。当時、すべての Yandex サービスがクラウドでホストされていたわけではなく、サーバーの数が絶え間なく増加したため、状況はさらに複雑になりました。 Yandex の開発速度に直接影響するため、機能やバグ修正をユーザーに迅速に展開することが重要でした。 IPv6 のみのサポートが必要です。ポッド間のエンドツーエンド接続を提供するために、当社の規模では IPv4 アドレスの範囲では十分ではないため、データ センターは IPv6 のみで構築されました。 本質的に、Kubernetes が必要でした (そして、時間が経つにつれて、RTC がそれに非常に近づいてきました)。ただし、ここに問題があります。k8s は 2014 年に発表されたばかりです。当時、Apache Mesos は存在していましたが、初期段階にありました。 私たちは、ある種の MVP を使用して問題の解決を開始しました。これは単純なツールのセットであり、日常的なアクションを自動化する一連の構成要素に似ています。次に例を示します。 基本的な機能の実装。 クラスターリソースの割り当て。 必要なバージョンのアプリケーションとさまざまなアーティファクトをクラスターに配信します。 クラスター上で必要なバージョンのアプリケーションを起動します。 時間が経つにつれて、これらの構成要素を使用して本格的なサービス レイアウト グラフをまとめることが可能になりました (継続的デリバリーと同様)。一定回数の反復を経て、RTC で実行されるサービスを管理するシステムである Nanny が 2013 年に登場しました。 リソース消費に基づいたアプリケーション分離の実装でした。当初、リソースを分離せずにさまざまなサービスからアプリケーションを起動しましたが、その結果、多数の運用上の問題やインシデントが発生しました。 Nanny のもう 1 つの基本的な側面は、 当時、既製のソリューションは、その時点で開発が停止していた LXC と、IPv6 のみを使用できず、dockerd を更新するときにすべてのコンテナーが再起動されるため、ユーザーに影響を与えずに dockerd を更新することができなかった Docker だけでした。その結果、私たちは開発を開始しました。 2014 年半ば頃、Linux カーネル cgroup 上のコンテナ化システム。サーバー上のほとんどのアプリケーションと一部のシステム エージェントは、2015 年にすでに Porto コンテナーに移行されています。 ポルト 当時、社内クラウドのリソース管理はリポジトリへのコミットによって行われていました。しかし、これは Yandex の開発を遅らせ、使用率を高めるという課題と衝突しました。これを解決するには、マップ リデュース システムをクラウドに配置する必要がありました。 - ビッグデータの保存と分散コンピューティングのための当社独自の内部システム。当時、当社は約 7 年間開発していました。社内クラウドに導入する必要がありましたが、ユーザー アプリケーションと並行して実行する必要もありました。 使用上の問題を解決します。 Yツァウルス YTsaurus を RTC に導入するには、リポジトリのコミットではなく動的にポッドを管理する機能が必要でした。そこで、2018年に私たちは、 、クラスター コンピューティング リソースを管理するシステム。 Yandex Planner は既存の Nanny 導入システムと統合され、YTsaurus の移行のブロックを解除し、RTC を本格的なクラウドに変換しました。当時 RTC には数万台のサーバーがありましたが、マップ リデュースの導入により、この数は大幅に増加しました。 Yandex プランナー 同じ期間に、k8s はより成熟したソリューションに進化し、2017 年に AWS サービスの 1 つになりました。しかし、それでも、次のすべての要件を満たしていませんでした。 新たな成長痛。 数万台のサーバーの規模 - 1 つの k8s インストールではまだ規模を処理できません。 デュアルスタック IPv6 と IPv4 のサポートが k8s に登場したのは 2020 年になってからであり、IPv6 は当初から私たちにとって重要でした。 ネストされたコンテナーのサポート。個別のバッチ スケジューラーとコンピューティング スケジューラーを作成することにしたため、これが必要でした。私たちはある時点でこのオプションの有効性を一般的なスケジューラの有効性と比較しましたが、すべてに対して一般的なスケジューラを作成しようとしない方が便利で有益でした。 YTsaurus は、単一のスケジューラを作成するのではなく、ネストされた Porto コンテナを作成する機能を積極的に利用しました。もちろん、k8s に同じデュアル スタックのサポートを自分たちで追加することもできます。ただし、Linux カーネルの開発経験から、すべてをオープンソースに送信できるわけではないことがわかっており、新しいバージョンへの更新を簡素化するために、上流のカーネルからのデルタを最小限に抑えるよう努めています。 RTC のアーキテクチャは Kubernetes のアーキテクチャと非常によく似ています。ユーザーは、指定されたアプリケーションをどのように起動するか、どのデータセンターで起動するかを記述する何らかの仕様の形式でサービスを宣言的に記述します。各データセンターには独自の Yandex Planner がインストールされており、一方ではすべてのクラスター オブジェクトのデータベースとして機能し、他方ではポッド スケジューラーとして機能します。データセンター内の各サーバーは、Yandex Planner からポッド仕様を受け取り、独自の Porto コンテナー化システムを使用してポッド仕様を起動するエージェントを実行します。 今日の私たちのソリューション。 現在、RTC は数万のサービスを開始し、500 万以上のコアを 100,000 台以上のサーバーに割り当てています。毎日、サービス仕様に対して 100,000 件以上の変更が行われています。 特に、ある時点から k8s エコシステムが機能の点で私たちを上回り始めてからはそうです。 k8s に切り替えて、既製のツールが最終的に必要なボリュームを提供してくれることを期待する方が良いのではないでしょうか?実際には、これほど大規模に事業を展開している企業はほんの一部であり、各企業が独自の社内クラウド ソリューションを持っているため、当社は k8s のニッチな消費者であり続けています。 予定。 k8s がスケールを処理できるとしたらどうなるでしょうか? 覚えておくべきもう 1 つの重要な点は、移行の問題です。 2018年7月の報道によると レポートによると、最新のアプリケーションの 90% は 2025 年までに引き続き使用され、これらのシステム開発のための技術的負債が IT 予算の 40% 以上を占めると予想されています。ユーザー サービスを Yandex Planner に移行した経験に基づくと、これは現実に近いものです。2023 年には、約 100,000 のコアがまだ Yandex Planner に移行する順番を待っていました。 Gartner がマルチプラットフォーム アプリケーションのモダナイゼーション ビジネス ケースを構築 2021 年に、開発戦略を選択する際に、ある展開システムから別の展開システムに移行するのにどれくらいのコストがかかるかを見積もりました。 Yandex のバニラ k8s への移行は非常に費用のかかる作業となり、数百人年がかかります。 このように単純な方法で、私たちの内なる雲は最終的に決まりました。たとえそのような目標を設定したとしても、今後 5 年間はそれを放棄することはできそうにありません。 k8sと比較して内部クラウド機能が不足していることについてはどうすればよいですか？実際には、お客様は Yandex Cloud でマネージド Kubernetes を使用できます。このオプションは主に、厳格なコンプライアンス要件を満たす必要があるプロジェクトに使用されます。これは 1% 未満の少数のチームです。上記の理由により、残りの人口は移動することにあまりメリットを感じていません。 同時に、私たちは k8 に積極的に注目し、一般に受け入れられている標準に近づく方法を検討しています。私たちはすでに、クラウドのブートストラップや Yandex 全体の規模での IaaC の編成など、いくつかのタスクで k8s を積極的に実験しています。理想的には、できる限りニーズに合わせた独自の実装を維持しながら、k8s インターフェイスを再利用したいと考えています。残っているのは、実際にそれを行う方法を見つけることだけです。 この記事ではビッグテクノロジー全般について説明しているため、このケースが特殊なものではないことに注意してください。をチェックしてください または 例としてのケース。 他の人はどうですか？ ボーグ 麻ひも ストーリー #2: モノリポジトリ 私たちのモノリポジトリである Arcadia は、便利な開発ツールを提供するという、社内クラウドと同じ主な目標を共有しています。これには、リポジトリの場合は開発エコシステム全体が含まれます。 問題と解決策の要件 。 バージョン管理システム (Arc)、 インターフェース（アルカナム）、 システムを構築します (自分で作ります)、 CI/CD (NewCI)。 Arcadia は、Yandex の内部クラウドとほぼ同時期に登場しました。モノリポジトリを作成した理由の 1 つは、Yandex 内でコードを再利用する必要性でした。これは当時、いくつかのビルド システムの存在によって妨げられていました。 Yandex 全体の規模で動作するには、効率的な分散ビルドをサポートする統合システムが必要でした。また、安定して使用できるものでなければなりません。 当社独自の ya make ビルド システムは 2013 年にデビューしましたが、当時は C++ コードのみを対象としていました。 make を行う前は CMake を使用していましたが、その速度のせいでモノリポジトリの規模まで拡張できませんでした。プロプライエタリな ya make は、Arcadia を使用するとはるかに高速に動作しました。私たちの問題を解決できるオープンソースのオプションは他にありませんでした。たとえば、Bazel はずっと後の 2015 年にリリースされました。 統合されたビルド システムの実装。 Yandex は以前、バージョン管理システムとして SVN を使用していました。 SVN は大容量でしたが、それでも制限があり、保守が困難でした。さらに、最終的には SVN の機能と利便性の限界に遭遇するだろうということも認識していました。たとえば、ヒューリスティックを使用して、リポジトリの必要な部分だけをダウンロードする機能や選択的チェックアウトを実装しました。その結果、2016 年に、SVN 以外のバージョン管理システムの実験を開始しました。 バージョン管理システムのスケーリング。 マーキュリアルが第一候補でした。しかし、私たちが抱えていた主な問題はスピードでした。私たちは Mercurial を製品化するために 1 年半努力しましたが、結果は期待外れでした。たとえば、最終的には FUSE をサポートするために Mercurial の一部を書き直す必要があり、そうでなければリポジトリ全体を各開発者のラップトップに持ち込む必要がありました。 最終的には、社内でソリューションを最初から作成する方が安価であることが判明し、2019 年に、git のような UX を備えた Arcadia ユーザー向けの新しいバージョン管理システムである Arc が登場しました。 Arc の基盤は、選択的チェックアウトではなく、FUSE (ユーザー空間のファイルシステム) です。さらに、YDB はスケーラブルなデータベースとして機能するため、Mercurial と比較して Arc の操作が大幅に簡素化されます。 なぜ git を使用しなかったのかとよく尋ねられます。規模と機能の制限もあるため、Arcadia トランクを git にインポートするだけの場合、この規模では git ステータスに数分かかります。同時に、git 上に構築された安定した FUSE 実装はありませんでした。Git 用の VFS は現在開発されておらず、EdenFS は最終的に Sapling に変わりましたが、これはずっと後のことです。 開発を開始するには、内部ユーザーがモノリポジトリにフォルダーを作成し、コードを記述し、ビルド マニフェストを追加してアプリケーションをビルドする方法を指示するだけです。その結果、ユーザーはプル リクエスト、CI 構成を受け取り、社内のコードを再利用できるようになります。 ソリューションの現状と将来の計画。 規模の点では、トランクには現在 1,000 万個のファイルが含まれており、リポジトリ全体では 2 TiB を超え、毎週 30,000 件を超えるコミットが行われています。 その結果、私たちが作成したエコシステムでは、多くのコンポーネントをゼロから作成する必要があります。しかし、現在は世界標準への準拠に向けて進んでいます。たとえば、Arc は、事前定義されたプロジェクトのセットに対する Git の操作をサポートしています。 繰り返しになりますが、ビッグテクノロジー全般を見る場合、一例として次のことに注意を払う必要があります。 そして 。 他の人はどうですか？ 苗木 パイパー これらの話の共通点は何ですか では、なぜ大手テクノロジー企業は独自のソリューションを発明しなければならないのか、またなぜ一般に受け入れられている標準に準拠したソリューションに置き換えることができないのでしょうか? 大企業は、将来的には当たり前になる問題の解決策を開発することを頻繁に求められます。このようにして、市場標準となる可能性を備えた革新的なソリューションが出現する可能性があります。 革新。 企業が解決した問題が、企業以外の誰かに直面しているとは限りません。特定の問題に関する大手テクノロジー企業の経験が、まったく異なる開発パスを選択することで業界全体がその問題を回避するのに役立つ場合があります。市場の発展を予測することは常に可能であるとは限りません。その結果、独自のソリューションのさまざまな例が非常に異なる結果をもたらしました。 ClickHouse は、オンライン分析処理 (OLAP) の分野を大きく豊かにした、真に成功した革新的なプロジェクトの一例です。ただし、これはすべてのプロジェクトに当てはまるわけではありません。 Porto はオープンソース プロジェクトとして始まりましたが、さまざまな理由で注目を集めることができませんでした。ネストされたコンテナーを作成する機能など、一部の機能は依然として独自のものです。 すべての企業がスケーラビリティの問題に直面しているわけではないため、この点はある意味で前の点と似ています。誰もが 640 キロバイトで十分だった時代がありましたよね。 規模。 実際、システム負荷の急激な増加は、Arcadia と社内クラウドの開発の最も重要な理由の 1 つでした。これが、Arc と Yandex Planner が開発された理由です。 Arc は、トランク内に数千万のファイルを含むモノリポジトリをユーザーが簡単に操作できる、ユーザーフレンドリーな VCS のニーズに応えて作成されました。 Yandex Planner は、数万のノードと数百万のポッドからなるクラスターを効果的に操作する必要性に応えて作成されました。 公開ツールには引き続きスケーリングの問題があります (結局のところ、これは比較的まれなシナリオであり、それに投資しても採算が合わないことがよくあります)。 企業内の問題を解決する社内ツールを考えてみましょう。このツールを積極的に使用する企業は、ニーズに合わせてツールをより適切に調整するためにリソースを投入し、最終的には高度に専門化されたツールに変換します。このプロセスは何年にもわたって続く場合があります。 慣性。 ここで、ある時点で、その特定の問題を解決するために広く受け入れられる標準が出現する可能性を考えてみましょう。この場合でも、専門性が社内ソリューションを決定する際の重要な要素となる可能性があります。システムの構築を検討してください。 Arcadia では ya make を使用していますが、Google の Bazel もあります。これらは概念的には似ていますが、詳細に入ると、各ワークロードの負荷パターンが大幅に異なる可能性があるため、多くの重要なシナリオは異なる方法で実装されています。その結果、一般に受け入れられている新しい標準をカスタマイズするために、すでに費やされているリソースをほぼ確実に再投資する必要があります。 前のセクションでプロジェクトをユーザーに適応させる問題を取り上げた場合、ここではユーザー自体の移行の問題を取り上げてみましょう。私の意見では、移行はテクノロジー分野で名前の次に重要な問題と呼ぶべきです。すでに社内ツールがあり、それを標準化されたツールに置き換えたい場合、必然的に移行が必要になります。 移住。 私たちは社内クラウドの開発経験から多くの移行例を知っています。大規模な移行には時間がかかるため、両方のツールを長期間同時にサポートする必要があります。このプロセスに多数のユーザーが関与する場合、管理上の問題は避けられません。ユーザーの参加なしで移行を試みるのは確かに価値がありますが、常に可能であるとは限りません。 率直に言って、この点は最近になって十分重要になってきています。以前は、ベンダーロックインへの懸念から、これを真剣に受け止める企業ははるかに少数でした。重要なプロセスを、いつでもコラボレーションを終了できるベンダーに任せるのは危険です。 JetBrains はその典型的な例で、IDE の使用を特定の企業に制限しています。もう 1 つの好例は、ロシアを拠点とするユーザー アカウントの停止を開始した Github Enterprise です。 事業継続性。 社内ソリューションは通常、この問題の影響を受けません。一方で、オープンソースのソリューションはまだ存在します。一方で、オープンソース モデルがずっと使用されるという保証はありません。たとえば、Facebook が社内で開発した Hadoop MapReduce スケジューリング ソフトウェアの改良版であるコロナは、コミットできないために最初に登場しました。 Hadoop をアップストリームに拡張するために必要なパッチ。 同時に、この問題の法的側面はオープンソースに影響を及ぼします。たとえば、golang や k8s でのコミットには CLA への署名が必要です。この問題は今後も続くのでしょうか? はい、客観的な理由に加えて、下された決定が現実的ではない可能性もあります。それが最高の NIH 症候群です。 NIH（アメリカ国立衛生研究所。 たとえば、コンピューティングに対するバッチの影響を排除するために、Linux カーネル内に独自のスケジューラを作成しようとしました。実際には何も良いことはありませんでした。 Linux カーネルの既存の機能を利用することもできたはずです。しかし、人件費が高くなればなるほど、問題を詳しく説明して解決するためにより多くの労力が費やされ、NIH症候群に罹患する可能性は低くなります。 ご覧のとおり、大企業向けの社内ソリューションが頻繁に必要となります。それらの大部分は将来、まだ成熟していない統一された世界標準ソリューションと統合されることになりますが、残りは歴史になるでしょう。いずれにせよ、独自のソリューションと既製のソリューションのどちらを選択するかを決めるのは依然として難しい問題であり、まずそのようなプロジェクトの背景を理解し、コストを見積もることなしには答えることができません。 要約すると 、
