|
オープンソースの詳細については、以下をご覧ください。 51CTO オープンソース基本ソフトウェアコミュニティ https://ost..com 多くの企業と同様に、ByteDance のオープンソースへの取り組みは、ゼロから始まり、徐々に深化していき、一般的に次の 3 つの段階を経ています。 第一段階はオープンソースの活用です。ビジネスの成長を加速させるために、既存の、確立された、成熟したオープンソースの技術とツールを活用します。 実際、ByteDanceの事業展開の初期段階、つまり独自の技術プラットフォームとインフラを構築していた頃は、パブリッククラウドを積極的に活用し、さらに関連するオープンソース技術やミドルウェアを幅広く採用することで、独自の技術プラットフォームを迅速に構築しました。この技術プラットフォームは、DouyinやToutiaoといったByteDanceの事業の発展を牽引してきました。 第二段階は、オープンソースへの参加です。オープンソースをより深く活用していくことで、既存のオープンソースプロジェクトの最適化など、自社のビジネスシナリオにおいて多くのイノベーションを実現していきます。この第二段階では、私たちの成果をコミュニティに還元し、コミュニティメンバーと経験を共有していきます。 第三段階は、積極的なオープンソース化です。経験を積み、プロジェクトを洗練させていくにつれて、完全なプロジェクトを独自に開発する可能性もあります。そして、コミュニティへの還元を目的として、いくつかの完全かつ体系的なプロジェクトをオープンソース化するという第三段階へと進みます。 積極的なオープンソース活動といえば、いくつか統計もまとめました。2015年頃にRcproxyプロジェクトのオープンソース化を開始して以来、私たちは一貫して独自のオープンソースプロジェクトに貢献してきました。 過去数年間の統計からわかるように、私たちは合計 100 以上のプロジェクトをオープンソース化しており、もちろんこれらのプロジェクトには厳格な分類も行っています。 例えば、通常のプロジェクトとは、完全なシナリオベースのソリューションや完全な機能ループを提供するエンドツーエンドのソリューションです。これが私たちのメインプロジェクトです。 通常のプロジェクトに加えて、関連するデモ、CLI、SDKのオープンソース化にも協力しています。これらは補助的なオープンソースプロジェクトです。 通常のプロジェクトだけを見ても、ByteDanceはこれまで、フロントエンドWebフレームワーク「Modern.js」、クラウドネイティブミドルウェアコレクション「CloudWeGo」、機械学習分野では高性能分散トレーニングフレームワーク「BytePS」や連合学習プラットフォーム「FedLearner」など、50以上のプロジェクトをオープンソース化してきました。 量的に見ると、通常プロジェクトの中で最も多いオープンソースプロジェクトはインフラ関連です。次に多いのはAI、アルゴリズム、プラットフォーム関連のオープンソースプロジェクト、そしてフロントエンドやオーディオ/ビデオ関連のオープンソースプロジェクトです。 1. オープンソース委員会の責任と業務範囲2015 年から現在に至るまで、オープンソース プロジェクトの大部分は、当社のエンジニアの個人的な興味によって推進されてきました。 これにより素晴らしいオープンソース文化が育まれましたが、その過程では標準化の問題や、少し前に起こったいわゆる盗作論争など、いくつかの問題にも遭遇しました。 この経験から、オープンソースはエンジニアの個人的な関心だけで推進できるものではなく、企業レベルの戦略、標準、そしてプロセスの導入も必要であることを認識しました。これが、ByteDanceのオープンソース委員会が取り組むべき最初の課題です。 さらに、会社が成長し、エンジニアがオープンソースに注力するようになるにつれて、より重要な戦略的プロジェクトにエネルギーとリソースを合理的に割り当てる必要性が高まりました。これが、オープンソース委員会を設立したもう一つの本来の目的です。 もちろん、オープンソース委員会は、オープンソース分野における企業、組織、コミュニティ間のよりよい協力を促進する必要もあります。 オープンソース委員会を設立することを決定してから正式に設立されるまで、私たちは約 6 か月をかけて準備を進めました。 オープンソース委員会が設立された後、私たちが最初に直面した疑問は、「どのようなプロジェクトがオープンソースに適しているのか」ということでした。 当社の標準は次のとおりです:
プロジェクトがオープンソース化された後、CNCF と Cloud Native Technology Committee のプロジェクト分類メカニズムも参照し、プロジェクトをさまざまなレベルに分割しました。 これらのプロジェクト格付けメカニズムに基づいて、次の質問は、どのプロジェクトがよりスムーズに成熟段階に入り、より多くの企業リソースを獲得し、より高い優先度でオープンソース化できるかということです。 当社の標準は次のとおりです:
これらの基準に基づいて、プロジェクトをオープンソースにするかどうかを決定したら、オープンソース プロジェクトが成功できるかどうかも確認する必要があります。 成功または失敗を測るには、一連の価値観または価値観の体系が必要です。 私たちの考えをいくつかご紹介します。
これらの点を説明した上で、具体的なオープンソースプロジェクトを3つご紹介します。これらのプロジェクトを組み合わせることで、先ほど述べたコンセプトのいくつかを視覚的に理解していただければ幸いです。 2. CloudWeGo: マイクロサービスの通信とガバナンスに焦点を当てる本日ご紹介する最初のオープンソース プロジェクトは、マイクロサービス ミドルウェアのコレクションである CloudWeGo です。 CloudWeGo は、実際にはエンタープライズ グレードのクラウド ネイティブ アーキテクチャ向けのミドルウェアのコレクションであり、企業が独自のマイクロサービス システムを迅速に構築するのに役立ちます。 CloudWeGo も ByteDance のインフラストラクチャ チームによるオープンソース プロジェクトであり、マイクロサービスの通信とガバナンスに重点を置いており、高パフォーマンス、スケーラビリティ、高信頼性、使いやすさなどの注目すべき特徴を備えています。 CloudWeGoのプロジェクトはすべて、ByteDance社内での大規模導入を通じて検証されています。オープンソース化後、各機能のイテレーションは可能な限り速やかに社内でテストと検証が行われています。これは真のエンタープライズレベルの導入プロジェクトであり、オープンソースユーザーとByteDance社内の事業部門は同じサービスフレームワークを使用しています。 第二に、CloudWeGo が提供する機能、特にプロトコル サポートとサービス ガバナンスは、実際のビジネス上の問題点を解決でき、コード行ごとに最適化することでユーザー サービスのパフォーマンスを効果的に向上させることができます。 最後に、CloudWeGoの開発は、いくつかの著名なオープンソースプロジェクトの設計アイデアや実装を参考にしています。このプロジェクトは、オープンソースコミュニティへの貢献だけでなく、オープンソースコミュニティのエコシステムをさらに充実させるため、オープンソース化されました。 最初のフェーズでは、CloudWeGo は次の 4 つのプロジェクトをオープンソース化しました。
現在、CloudWeGo は GitHub で 4.3K 以上のスターを獲得しており、Kitex と Netpoll を合わせると 2.6K 以上のスターを獲得しています。 現在、CloudWeGo-Kitexは、Alibaba Cloudのクラウドサービスエンジン(MSE)、アプリケーションリアルタイムモニタリングサービス(ARMS)、Tencent Cloudのマイクロサービスエンジン(TSE)との連携をサポートしています。さらに、サービスガバナンスなどの高度な機能も開発中です。 前述の通り、ByteDanceはVolcano Engineと呼ばれるエンタープライズ向けサービススイートも提供しています。CloudWeGoプロジェクトは現在、Volcano Engineの関連製品との統合を進めています。統合が完了すると、関連製品と機能が段階的に一般公開され、オープンソースユーザーがクラウドに迅速に移行しやすくなります。 CloudWeGo はコミュニティ文化とコミュニティ構築を重視し、メンバー促進の仕組みを確立し、コミュニティの中核となるコミュニティ開発者を積極的に育成しています。 CloudWeGoはこれまでに5名のコミッターを育成し、コミュニティの発展に多大な貢献をしてきました。これらのオープンソース貢献者の方々に感謝の意を表したいと思います。 同時に、私たちは、より多くの志を同じくする友人がコミュニティの構築に参加し、提案を提供し、コミュニティの発展に尽力してくれることを歓迎します。 3. Elkeid: クラウドネイティブ時代により適している次に、もう一つの非常に重要な分野、セキュリティ分野におけるオープンソースプロジェクトの実践についてお話しします。このオープンソースプロジェクトは「Elkeid」(姚光/毓君)と呼ばれています。これは北斗七星の一つで、北斗七星の星座の一つです。このプロジェクトが解決する問題は、ホストセキュリティです。 Elkeid は、ByteDance の社内セキュリティおよびリスク管理チームによって社内開発された新しいホスト セキュリティ ソリューションであり、いくつかの特徴的な機能を備えています。 重要な特徴の一つは、ByteDance社内の数百万台ものサーバーをサポートできる大規模さです。もちろん、これについて説明する前に、ByteDance社内のサーバー群の規模についても簡単に触れておきます。 もう 1 つの特徴は、Elkeid がカーネル モード テクノロジを使用してほとんどのメトリックと情報を収集することです。 このアプローチにより、パフォーマンスが大幅に向上し、より多くの豊富なデータの収集が可能になり、検出機能が大幅に強化されます。 上の図は、いくつかの利点を提供する Elkeid の全体的な技術アーキテクチャを示しています。
なぜこのプロジェクトをオープンソース化することにしたのでしょうか?実は、当初は既存の主流のホストセキュリティソリューションをベースに、自社の業務システムのセキュリティ強化を目指していました。 しかし、当社の事業量、規模、ニーズが拡大し続けるにつれ、従来のソリューションでは当社のシナリオに対応する上でボトルネックとなることが徐々に明らかになってきました。 その後、前述のカーネルモードのオープンソースホストソリューションをベースにElkeidを開発し、その実現可能性と価値を業界に証明しました。 さらに、ハイブリッド クラウドとクラウド ネイティブ テクノロジーの急速な発展により、従来のホスト ソリューションでは、コンテナ化とクラウド ネイティブ コンピューティングという新しいアプリケーション パラダイムに適応することがますます困難になっています。 この傾向を見て、私たちも自社開発した Elkeid をオープンソース化し、業界と協力してより多くのリソースを活用し、より多くのシナリオをカバーし、より多くの戦略を開発し、それによってプロジェクト全体の有効性を向上させたいと考えています。 4. ByteHouse: 次世代のテクノロジーアーキテクチャの強化本日の最後のケーススタディは、データウェアハウスとデータ分析という非常に重要な分野に焦点を当てています。この分野では、オープンソースから進化したByteHouseというテクノロジーをご紹介します。 ByteDanceは2019年からClickHouseを積極的に活用しています。現在、ByteDance内でClickHouseは15,000以上のノードを運用し、合計600PBのデータを管理し、1日あたり1億件以上のクエリリクエストを処理しています。その応用シナリオも非常に多岐にわたります。 ClickHouseには多くの利点があり、要約すると高速、効率的、そして費用対効果が高いと言えます。もちろん、ClickHouseが適さないシナリオもあります。 たとえば、キーと値のペア、ブログやドキュメントのストレージ、多くのドライブを使用するクエリはサポートされておらず、十分にサポートされていません。 もちろん、これらの制限に加えて、ByteDanceがClickHouseをより広範囲に使用していくにつれて、フェーズ2ではいくつかの問題も発生し始めました。これらの問題の多くは、ClickHouseのアーキテクチャに起因していました。 ビジネスが成長し拡大するにつれて、ClickHouse クラスターのコンピューティング能力が徐々にボトルネックになり、その時点でクラスターを拡張する必要があります。 ただし、容量を拡張すると、いわゆるリバランスを実行するためにデータもそれに応じて移動する必要があります。 しかし、リバランスのプロセス中には、他にも多くの費用が発生し、多くの運用準備作業が必要になります。 これには、データ損失のリスクへの対処と、元のデータの一貫性と正確性の確保が含まれます。そのため、クラスタ拡張の絶好の機会を逃してしまう可能性があります。 ClickHouse のこれらの問題に基づいて、第 3 フェーズで対応するテクノロジの最適化を開始しました。 最も重要な技術的最適化は、コンピューティングとストレージを分離したアーキテクチャ(分解インフラストラクチャとも呼ばれます)を使用したことです。 以下のアーキテクチャ図を見ると、より明確にわかります。以前は、ストレージとコンピューティングの両方を単一のノードで実行していました。しかし、当社の分離型インフラストラクチャ、つまりストレージとコンピューティングを分離したアーキテクチャでは、汎用ストレージ層を提供します。 コンピューティング層は柔軟にスケールアップとスケールダウンが可能です。コンピューティング能力がさらに必要な場合は、コンピューティングノードを追加するだけで済みます。ストレージ容量がさらに必要な場合は、ストレージ層に必要な容量を拡張できます。 もちろん、弾力的なスケーリングは無限のスケーラビリティをもたらします。データはストレージ層で共有されるため、理論的には水平方向にスケーリングして、可能な限り多くのコンピューティングリソースを活用できます。これにより、クラスタ管理者にとってより使いやすくなります。 もちろん、この新しいアーキテクチャにはいくつかの課題も伴いますが、私たちはそれに対応するソリューションを設計しました。例えば、考えられる課題の一つはパフォーマンスです。共有ストレージアーキテクチャはパフォーマンスの低下を招くでしょうか? ByteHouse を開発する際には、データ キャッシュ レイヤーを追加することで、リモート読み取りおよび書き込み操作のパフォーマンスの低下を補います。 2 番目の課題は、ByteHouse エンジンの読み取りと書き込みの分離アーキテクチャの下で、データ ストレージ システムをさまざまなシナリオやさまざまな実装スキームに適応させることができるようにすることです。 例えば、ローカルストレージを使用している場合はHDFSに適応し、元のデータファイルの移行はそれほど手間がかかりません。また、異なるパブリッククラウドにデプロイする場合は、異なるクラウドストレージシステムに迅速に適応できるようにする必要があります。 そのため、物理ストレージシステム全体の基盤に、社内でVFS(仮想ファイルシステム)と呼んでいる抽象化レイヤーを構築し、異なるストレージシステムへのアクセスインターフェースを提供する必要があります。これが第3段階であり、一連の技術的最適化を実施しました。 第 4 段階では、ビジネスの最適化や機能の革新を達成したときに、コミュニティへの還元も行いたいと考えています。 コンテナ化とクラウド時代をベースとしたコンピューティング エンジンである ByteHouse の大きな特徴は、コンピューティングとストレージを分離し、それぞれを独立して拡張およびスケーリングできるアーキテクチャです。 同時に、さまざまなビジネス ワークロードの特性に基づいてリアルタイムのコンピューティングとストレージ リソースの割り当てを実現し、最高の TCO を実現できるようにユーザーを支援します。 私たちは、これらのアーキテクチャ設計と技術革新に基づいて、ByteHouse を継続的に製品化し、ワンストップの軽量クラウド データ ウェアハウスとして位置付け始めました。 ByteHouseに加えて、開発者がこのテクノロジーをより有効に活用できるよう、豊富なツールと機能も提供しています。これには、複数のソースからのデータのインポート、クエリの観測性と診断機能の強化、マルチテナント環境における多層的なデータアクセス制御の実現などが含まれます。 オープンソースの詳細については、以下をご覧ください。 51CTO オープンソース基本ソフトウェアコミュニティ https://ost..com |