データ分析

Broadcom、柔軟なデータ管理を実現し顧客の保護機能を向上させる

#da

※この投稿は米国時間 2021 年 4 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 本日は、Broadcom のデータ分析担当シニア ディレクターである Padmanabh Dabke 氏と、GCP 移行担当テクニカル ディレクター兼アーキテクトである Zander Lichstein 氏にお話を伺います。Google Cloud を利用してデータ分析インフラストラクチャをモダナイズし、運用の簡素化、サポートやインフラストラクチャのコスト削減、データ分析エコシステムの堅牢性の大幅な向上を実現した様子についてご紹介いただきます。

Broadcom Inc. は、半導体およびインフラストラクチャ ソフトウェア ソリューションを設計、製造するグローバル テクノロジー リーダーとして知られている企業です。2019 年に Symantec を買収したことで、Broadcom はミッションクリティカルなインフラストラクチャ ソフトウェアのフットプリントを拡大しました。Broadcom の一部門である Symantec は、デスクトップ、モバイル デバイス、メールサーバー、ネットワーク デバイス、クラウド ワークロードにインストールされたソフトウェアを介して、世界中の何百万人ものお客様を保護するセキュリティ製品を備えています。

これらのアクティビティにより、毎日膨大な数の興味深いイベントが発生します。私たちは、何十ものチームと何百ものシステムを備えており、それらが一体となって保護、検知、免責、インテリジェンスを実現しています。そしてそのすべてについて、データレイクでの膨大な量のデータを処理する必要があります。Broadcom の Security Technology and Response(STAR)チームは、このデータレイクを活用して、保護機能や分析アプリケーションを提供しています。STAR チームは、データシステム管理の柔軟性を高めてリソースの競合をなくし、チーム間でコストのアカウンタビリティを果たせる方法を必要としていました。

データレイクはこれまで十分に機能してきましたが、事業の拡大に伴って技術的な要件も増えてきました。データレイクとその上に構築されたアナリティクス アプリケーションのレガシー実装をモダナイズする必要がありました。さらにモノリシックなアーキテクチャだったため操作が難しく、アプリケーション開発者の選択肢が極度に狭まっていました。この変革を加速させるために、Broadcom は Google Cloud を選択しました。Broadcom のシステムは複雑で大規模であるにもかかわらず、Google Cloud への移行は 1 年もかからず、お客様にとっても完全にシームレスなものでした。そしてアーキテクチャの最適化機能と Google Cloud のプラットフォーム機能によって運用モデルが簡素化され、サポートとインフラストラクチャのコストが低減し、データ分析エコシステムの堅牢性が大幅に向上しました。さらにデータレイクで報告される問題の数が減り、リソースの割り振りやノイジー ネイバーの問題に関する Symantec の内部リサーチャーからの毎月のサポートコールが 25% 減少しました。

私たちのデータはどこから来て、どのように使用されているのか

脅威からの保護を実現するには、巨大なフィードバック ループが必要になります。サイバー攻撃が検知、遮断されると、脅威の種類、脅威の出所、想定される被害など、システムからテレメトリーやサンプルが送られてきます。私たちはテレメトリーを分析して、良いもの、悪いもの、ブロックすべきもの、安全または危険なウェブサイトを特定し、それらの情報を新たな保護機能に変換して、お客様に提供します。そして、このサイクルが繰り返されます。

かつては、エキスパートがフロッピー ディスクを郵送してこれを行っていました。しかし最近では、脅威の数やデータの量が大幅に増えているため、機械学習(ML)や自動化機能を使って分析の大部分を処理する必要があります。これにより、従業員は最近の特に危険な脅威への対応に集中できるようになっています。これらの新しいテクノロジーが現場に導入され、そのサイクルが継続されます。

レガシー データ プラットフォームの欠点

当社のレガシーデータ プラットフォームは、オンプレミス ソリューションから発展したもので、単一で巨大、比較的柔軟性の低いマルチテナント システムとして構築されていました。大規模なインフラストラクチャ チームが保守していたときはうまくいっていましたが、Google Cloud に組み込まれている多くの機能を活用できていませんでした。また、この設計には明らかな制約がいくつかあり、アプリケーション チームの悪い慣習を助長してしまうことすらありました。十分なアカウンタビリティを果たせず、変更やアップグレードは困難を極め、パフォーマンスは低下しました。私たちは、特定ベンダーの Apache Hadoop スタックの上にエコシステムを構築していました。私たちは常にこのことによる制約を受けており、すべてのアップグレード サイクルをユーザーベースに対して調整する必要がありました。

私たちのデータ プラットフォームは変革を必要としていました。そして一元化されたプラットフォームから、分散化され、運用が簡単で、コスト効率の高いクラウドベースのデータレイクに移行したいと考えていました。また、Infrastructure as Code(IaC)やコンテナ化など、いくつかのアーキテクチャの変革を望んでいました。

エフェメラル クラスタによる「分割統治」

Google Cloud 上にデータ プラットフォームを構築した際、大規模で集中管理されたマルチテナント型の Hadoop クラスタから、小規模で一時的な Dataproc クラスタ上にほとんどのアプリケーションを移行して実行しました。そして、私たちのアプリケーションのほとんどが同じ実行パターンに沿っていることに気づきました。こうしたアプリケーションは定期的に起動し、一定の時間枠の最新のテレメトリーに基づいて分析結果を生成します。分析結果は他のアプリケーションで使用されるか、現場のセキュリティ エンジンに直接 push されます。新たな設計では、個々のアプリケーションの要件を推測することで、共通クラスタの全体的な容量を一元的に計画する必要がなくなりました。また、アプリケーション開発者は、プラットフォーム内のコンピューティング、ストレージ、ソフトウェア スタックを自由に選択できるため、彼らにとってもメリットがありました。

また、データ移行後は、私たちのスタック内で Google Cloud やオープンソースのソリューションを使用できるように切り替えました。クラウドベースの分散型アーキテクチャに基づくデータレイクでは、ユーザーは Cloud Storage の共有データ、共有された Hive Metastore によるメタデータ サービス、Cloud Composer によるジョブ オーケストレーション サービス、IAM と Apache Ranger による認証機能にアクセスできます。また、Cloud SQLBigtable を採用しているユースケースもいくつかあります。HBase に基づいたいくつかの基幹システムも、Bigtable に簡単に移行できました。パフォーマンスが向上しただけでなく、メンテナンスも明らかに簡単になりました。コンテナ化されたワークロードには Google Kubernetes Engine(GKE)を使用し、秘密情報の保存には Secret Manager を使用します。また、チームメンバーの中には Cloud Scheduler Cloud Functions を使用している人もいます。

チームでスピードアップを実現

多彩なアプリケーションと 200 人以上のデータ分析チームメンバーを擁する STAR は、Google Cloud 上で大きなフットプリントを持っています。私たちは、テクノロジー スタックと当社のセキュリティ要件を深く理解しているパートナーを必要としていました。Google Cloud のサポートにより、通常であれば長い時間を要する移行作業が加速しました。Professional Services Organization(PSO)チームは、移行プロジェクトの開始当初から私たちのコアチームの延長であるかのように機能し、毎日のスタンドアップ ミーティングに参加して必要なサポートを提供してくれました。Google Cloud PSO チームは、IaC(Infrastructure as Code)の迅速かつ安全な設定も支援してくれました。私たちの求める最先端の要件の中には、Google Cloud 自身のロードマップに組み込まれたものもあり、これにより真のパートナーシップが生まれています。

これまでは、データレイクのメジャー バージョンのアップグレードを 1 回行うだけで、ほぼ丸 1 年かかっていました。しかし、この Google Cloud での変革により、さらに多くのことを同時に行えるようになりました。データレイクとそのアプリケーションの移行と再設計だけでなく、同様に複雑でミッション クリティカルな他の数十のバックエンド システムの移行と最適化にも、1 年程度しかかかりませんでした。大がかりな作業でしたが、全体的にはスムーズに進み、Google Cloud チームはどのような問題についても私たちと連携して対処してくれました。

クラウド データレイクでスムーズな船出を実現

データレイクをモノリシックな実装から Google Cloud に移行したことで、アプリチームが本来の業務に集中できるプラットフォームを提供することが可能になりました。これにより、エンジニアはシステム開発を柔軟に行えるようになり、コストのアカウンタビリティとアプリ固有のパフォーマンスの最適化が実現し、チーム間のリソースの競合を完全に排除できるようになっています。

管理を分散させたことで、チームにできることが増え、独自の決定を下せるようになっただけでなく、コスト効率も格段に向上しました。ユーザーが独自の永続的クラスタまたは一時的クラスタを実行することで、ユーザーのコンピューティング リソースはコアデータ プラットフォームのコンピューティング リソースから切り離され、ユーザーは独自のスケーリングを行えるようになっています。これは、ユーザー固有のストレージのニーズについても同様です。

また、クラウド プロバイダ間でのポータビリティが確保されているため、ベンダー ロックインに悩まされずに済みます。さらに、Composer の Google Cloud 専用オペレータの柔軟性と可用性が優れており、これによって Dataproc や外部の GKE クラスタ上でジョブを送信、実行できるようになっています。

私たちは移行後、素晴らしい環境を手に入れています。各システムの処理能力は安定しており、データレイクのお客様も大変満足しています。アプリケーション オーナーは、自分のシステムを自己管理できるようになっています。スケーリングの問題もすべて解決しています。これらのメリットに加えて、現在は移行後の処理を見直し、さまざまなコストの最適化を図っています。

Google Cloud 上に構築された新しいデータレイクのおかげでチャンスが広がったことを嬉しく思っています。今では、データの管理に多くの時間を割く必要がなくなり、イノベーションに振り分けることのできるリソースが増えています。

Broadcom の詳細をご覧ください。Apache Hadoop を Dataproc に移行する方法を紹介した最近のブログもご参照ください。

-[Broadcom] GCP 移行担当テクニカル ディレクター兼アーキテクト Zander Lichstein

-[Broadcom] データ分析担当シニア ディレクター Padmanabh Dabke