by Andreas Skouloudis and David Coursey
この記事は、2023/07/24 に公開された「Why Reinvent the Wheel? The Challenges of DIY Open Source Analytics Platforms」の翻訳です。
テクノロジー支出の削減を強いられる中で、高度な分析に、オープンソースを活用する組織の中には、必要なデータ処理エンジンを備えた独自のランタイムを構築して保守することを検討することもあるかもしれません。もしくは、レガシーな Cloudera ランタイム (CDHまたはHDP) の古いバージョン (現在は廃止) を独自に保守すれば良いと考える場合もあるでしょう。しかし、どちらの選択肢も多大なコストとリスクを伴います。この方法でコスト削減になると言う考えは、高度な分析プラットフォームを構築するだけでなく、運用するためには複雑さと専門知識が必要となることへの考えが足りていないことから生じているのかもしれません。
カスタムしたオープンソースディストリビューションの管理と運用に関わる5つの主要な活動について詳しく説明します。
カスタムプラットフォームの開発
1. オープンソースプロジェクトの統合と継続的なアップグレード
おそらく、独自のプラットフォーム開発を評価する組織の間で最も大きな誤解は、初期の開発にかかる労力でしょう。最初のステップとして、データ処理エンジン (Apache Impala、Apache Sparkなど) だけでなく、ストレージ (Apache Ozoneなど）、スケジューリング／オーケストレーション (Apache Zookeeperなど) 、セキュリティ/ガバナンス (Apache Ranger、Apache Atlasなど) に必要なすべての基盤サービスを含め、必要なすべてのオープンソースプロジェクトの最新バージョンを統合する必要があります。このプロセスは複雑な開発ワークフローであり、多大なエンジニアリング作業を必要とします。各オープンソースプロジェクトの利用可能なバージョンは、それ自体で完全に機能します。しかし、他のオープンソースパッケージのどのバージョンとも統合することを意図して構築されたものではありません。その結果、プラットフォーム開発チームは、最終的にカスタムディストリビューションの残りの部分と適切に統合される各プロジェクトの適切なメジャーおよびマイナーバージョンを特定するために、多くの異なる組み合わせをテストする必要が出てきます。機能する組み合わせが見つかるまでのすべてのテストは、プラットフォームが機能要件と非機能要件を満たしていることを確認するために、数回のテストサイクルを必要とします。
エンジニアリングチームは、関連するオープンソースプロジェクトの新バージョンがオープンソースコミュニティで利用可能になると、プラットフォームを継続的にアップグレードすることが必要になります。その後、チームは新バージョンがプラットフォームの他の部分と互換性があることを確認するだけでなく (必要に応じて他のオープンソースプロジェクトに必要なアップグレードを行う)、これまでに構築されたすべてのカスタムパッチ/スクリプトを再適用し、すべてのエンドユーザーアプリケーション (データエンジニアリングパイプライン、機械学習モデルなど) を再認証する必要があります。Cloudera Data Platform (CDP) に含まれるオープンソースプロジェクトのリリース頻度を考えると、このプロセスは年間、何度も繰り返す必要があります。以下の図を参照。
CDP では、Cloudera はオープンソースエコシステム内の25以上のプロジェクトの依存関係を管理し、年間数百のオープンソースコミットの流入に対応しています。プラットフォームが顧客ベースのすべての機能的および非機能的要件を満たすことができることを確認するために、範囲、環境のフットプリント、ワークロードの観点から、さまざまなシナリオにわたって4つの異なるタイプのテスト (コミット前の CI テスト、スモークテスト、非機能テスト、および準備テスト) を実施します。
オープンソースコミュニティで利用可能になった最新の安定性、信頼性、およびパフォーマンスの改善を継続的にお客様に提供するために、Cloudera は、バグ修正、統合ホットフィックス、CVE セキュリティ修正、およびマイナープラットフォーム認証を含む Long Term Support (LTS) リリースで、事前に統合され、事前にテストされた最新のランタイムを提供します。LTS リリースは、既存のクラスタに簡単に配布できるパーセルとして最新の改良を提供することで、クラスタのアップグレードプロセスを劇的に簡素化します。LTS リリースに加え、Cloudera は Service Pack と呼ばれる定期的なメンテナンスリリースを提供しています。Service Pack には、セキュリティアップデート、ホットフィックス、パフォーマンスアップデート、マイナーアップデートが含まれ、プラットフォームのセキュリティポスチャと信頼性を保証します。
2. カスタム監視・管理ツールの統合
カスタムランタイムの作成と管理の複雑さの追加レイヤーは、CDP ランタイムで利用可能な独自の Cloudera 機能 (Cloudera Manager や Cloudera Observability など) によって、すぐに実行できる一般的なプラットフォーム管理タスクに必要なすべての関連ツールを特定し、構成することです。カスタム・オープンソース・プラットフォームの管理に関わる管理タスクの数を考えると、個々のワークロードのパフォーマンスを最適化するためのワークロード最適化ツール (またはアプリケーションパフォーマンス管理ツール)、環境レベルおよびホストレベルのメトリクスとダッシュボードのための環境監視ツール、フィルタリングとフィルタによる検索のためのログ検索ツール、ユーザー定義のトリガーに基づいてアラートを送信するためのアラートツールなど、必要なツールのカテゴリは多岐にわたります。
これらのツールの中には、オープンソースのものもあれば、そうでないもの (ワークロード管理、ログ検索など) もあります。一方、Cloudera のサブスクリプション (全ての層) には、これらのタスクに必要なすべての管理ツールが追加費用無しで含まれています。
継続的なプラットフォーム管理
上記で紹介したツールは Cloudera の管理機能と同様の機能を提供しますが、プラットフォームのライフサイクルを通してより大きな管理労力を必要とします。
3. 環境設定と監視
オープンソースプロジェクトで構成される分析スタックには、多くの設定という複雑さがあります。100ノード以下の典型的な Cloudera デプロイメントでは、400以上のサービスが実行されており、それぞれが独自の環境変数 (グローバルなものもあればローカルなものもある)、複数の設定ファイル、独自のコマンドラインオプションなどを使用しています。オープンソースプロジェクト専用のサードパーティソリューションがないため、これらの設定のほとんどは手動で行う必要がありますが、Cloudera Manager はその複雑さを管理するためのシンプルなインターフェイスを提供できます。他のオープンソースや市販のソフトウェアでは利用できない Cloudera Manager の機能の良い例として、Kerberos 認証があります。ユーザー認証のライフサイクルを合理化するために、Cloudera Manager では自動 Kerberos 設定、直接 AD への Kerberos 統合、Kerberos サービスのチューニング/監視機能を提供します。
Cloudera Manager は、その構成機能に加えてプラットフォームのテナントが使用するすべてのオープンソースプロジェクトと管理サービスのメトリクスを可視化し、プラットフォーム管理者の意思決定に役立つ重要な洞察を提供することができます。これらのメトリクスには、各サービスが収集する特定の変数やメトリクス (全体、利用率、ネットワーク I/O、書き込まれたデータなど) だけでなく、問題解決や環境管理に役立つ複合メトリクスやアラートも含まれます。カスタムランタイムの管理/監視に使用できるオープンソースまたは独自の監視ツールは、いずれも環境のパフォーマンスと健全性において、Cloudera Manager レベルのきめ細かさを提供しないため、プラットフォーム管理はより複雑になり、プラットフォームのダウンタイムが発生しやすくなります。
4. 問題解決
高度な構成と統合の複雑さを持つ多くの分析サービスを持つカスタムランタイムでは、問題解決は困難なテーマとなります。独自のカスタムプラットフォームを保守している組織では、ミッションクリティカルなサービスで発生した問題に対応するための時間と技術的専門知識が限られています。一方、Cloudera には、Cloudera ランタイムに含まれるオープンソースプロジェクトに関する数十年にわたる深い専門知識と、実際のコードレベルに至るまで、複雑さに関係なくプラットフォームの問題を特定し解決するためにお客様を支援するのに必要なリソースがあります。Cloudera サポートはまた、CDM (Cloudera Diagnostic Methodology) として知られる独自のトラブルシューティングのブループリントを開発し、徹底的かつ完全な問題解決を達成するための計画を提供しています。
Cloudera のサポート組織には、全世界に分散する500人以上のサポートリソースがあり、重要な問題に対して24時間365日のカバレッジを実現できることに加え、CDP ランタイムに含まれる様々な Apache オープンソースに150人以上のコミッターがいます。Cloudera のソフトウェアエンジニア/Apache コミッターは、専門知識が必要な場合、サポートケースの問題解決に直接関与することができます。
また、問題解決プロセスをさらに加速させるため、Cloudera Observability を導入しました。これは エッセンシャル層に含まれ、すべてのお客様にご利用いただけます。Cloudera Observability は、高度なサービスヘルスとパフォーマンスメトリクスにより、プラットフォームやワークロードに関連する問題を迅速に診断し、根本原因分析を行い、検証により問題を未然に防ぐことを可能にします。
より具体的には「検証」は Cloudera の最も強力なプロアクティブで予測的なサポートの差別化要因の1つです。MyCloudera カスタマーポータルを介して、問題のサマリーとソリューションパスの常時キュレーションされたリポジトリとして MyCloudera 内のお客様専用のナレッジベースを活用し、320以上の既知の問題シグネチャに関するセルフサービスの推奨を得ることができます。検証アラートは、Cloudera Manager 内に構築された Cloudera Diagnostic Bundle と、環境および製品レベルの診断の包括的なコレクションによって提供されます。バンドルには個人を特定できる情報やその他の機密データが含まれていないため、お客様は安心して活用いただけます。Cloudera 診断バンドルを活用することで、解決までの時間を30%短縮し、クラスタへの悪影響やダウンタイムを引き起こす前にこれらの既知の問題を修正することで、何千もの既知の問題を回避することができます。
5. セキュリティと CVE 修復
セキュリティは当社のソフトウェア・エンジニアリング・プロセスの中核分野の 1 つですが、Cloudera が貢献しているオープンソースプロジェクトや、当社の製品を構成する他の依存関係 (別名: サプライ チェーンセキュリティ) にセキュリティの脆弱性が存在する可能性を無視することはできません。
Cloudera は、一連のツールとデータフィードを使用して継続的な分析を実行します。これにより、セキュリティ上の問題や脆弱性を特定し、最小限の遅れで修復を行うことができます。すべてのリリース候補は、静的アプリケーション・セキュリティ・テスト (SAST)、動的アプリケーション・セキュリティ・テスト (DAST)、ソフトウェア構成分析 (SCA)、手動ペネトレーションテストなどの広範な分析を受けます。
トリアージと検証のプロセスは、脆弱性が社内で特定されるか、外部チャネルを通じて報告されるとすぐに開始されます。 検証中、製品セキュリティチームは、悪用の可能性、影響を判断し、コードベース内の脆弱性のすべての用途を見つけるために、問題のコードを徹底的に分析します。脆弱性が有効であると判断された場合、Cloudera はサービスレベル契約 (SLA) 内でホットフィックスを開発し、サポートポータルを使用してお客様に配布します。特に、開発チームが脆弱性を含む OSS コードに精通していない場合、多くの場合、これは非常にリソースを要しますが、 Cloudera の開発者はこれらのコードリポジトリを毎日操作しています。
一方、独自のオープンソースランタイムを管理する組織は、セキュリティ脆弱性が公開された後、カスタムプラットフォーム用のホットフィックスを開発し、実装しなければなりません。しかし、プラットフォームの他のコンポーネントとの互換性を確保するために、その構築と実装には深い専門知識が必要となります。また、上流プロジェクトがそのコードと衝突する修正を実施した場合、この分岐は重複作業や無駄な作業につながる可能性もあります。その結果、脆弱性をタイムリーに特定する専任のセキュリティ SME がいないことに加え、カスタムランタイムにホットフィックスを適用するのに多大な労力を要するため、自社で支えるカスタムプラットフォームがサイバーセキュリティのリスクにさらされる期間が長くなってしまうのです。
結論
今回のブログ記事では、カスタムディストリビューションの構築と管理に関連する労力と課題の概要を説明いたしました。その労力は、プラットフォームの構築、運用、セキュリティ確保に必要なリソースの増加につながります。
そのようなリソースの雇用と維持に関連するコストは非常に高く、Cloudera サブスクリプションのコストと最終的には同等もしくはそれ以上になります。また、専門知識を持つ人材が辞めてしまった場合などの継続的なリスクは言うまでもありません。さらに、カスタムプラットフォームは、アップグレードサイクルの長期化、新しい環境のプロビジョニングの遅延、問題の発見と解決に要する時間の増加により、テナントのエクスペリエンスに悪影響を及ぼし、プラットフォームのダウンタイムやパフォーマンス低下の可能性が高まります。もう一点、内部または外部から特定されたセキュリティ脆弱性の解決が遅れることは、技術組織全体のセキュリティポスチャを弱体化させることも認識する必要があります。
CDP の高度な機能について詳しく知りたい場合は、プラットフォームの概要をご覧いただくか、Cloudera にお問い合わせの上、お客様の現状についてお話しできればと思います。