ITシステムのスケーラビリティを管理するための第一歩は、現代の膨大なデータ量を理解することです。ビッグデータは2000年代中盤に急激に台頭し、成長を続けてきました。今日ではデータ量はさらに増大し、多くの組織にとって膨大なデータを管理することは新たな課題となっています。

テクノロジーにどっぷり浸かっている人でも、ビッグデータの「ビッグ」が示すサイズが実際にどの程度なのかを理解するのは難しいことです。例えば、扱うデータの単位がペタバイト(PB)からエクサバイト(EB)になる日はそう遠くないでしょう。その時、ペタバイト(PB)からエクサバイト(EB)に対応できるようにすることは生易しいことではなく、ハードウェア、ソフトウェア、人的資源への多大な投資が必要となります。

エクサバイトがどれくらいのデータ量かはイメージしにくいので、簡単に説明します。1エクサバイトは1,024ペタバイトに相当します。1ペタバイトのストレージがあれば、1枚3メガバイト(MB)の写真を3億枚ほど保持できるのに対し、1エクサバイトでは3兆枚ほど保持できます。

まだイメージしにくいと思いますので、視点を変えて星に例えてみます。Backblazeによれば、データ量を体積に置き換えたとき、1 ペタバイトが地球の大きさだとすると、1 エクサバイトは太陽の大きさになるそうです。太陽の体積を満たすには地球が130万個必要になります。

自社が250 ペタバイトものデータを管理していると発表している企業がありますが、前述した通り、250ペタバイトという値は近い将来小さい部類になってしまうことでしょう。では、組織が扱うデータをペタバイトからエクサバイトの規模に移行するには何が必要なのでしょうか。

ストレージから始める

エクサバイト規模のデータを分析することについて考える前に、まず1,000ペタバイト以上を保存できるインフラがあることを確認してください。

250ペタバイトからであれば、たった1エクサバイトへの拡張でも、ストレージ能力を4倍にする必要があることを意味します。これを実現するには、データセンターのスペースを追加すること、ストレージ用のディスクやノードを追加すること、ソフトウェアを1,000ペタバイト以上のデータに対応させること、演算ノードとネットワーク帯域幅の拡張によりサポートを強化することが必要となります。

ストレージノードを追加するにあたっては、容量の追加をより最適にかつ効率的に行うことが重要です。これは、高密度のストレージノードを利用するとともに、このような大量のデータを管理するためのフォールトトレランスやレジリエンスの仕組みを実装することで実現できます。

スケーラビリティに注意を向ける

何よりもまず注意を向ける必要があるのは、アナリティクス機能のスケーラビリティです。それと同時に、経済性、セキュリティ、ガバナンスへの影響も検討する必要があります。では、どうすればスケーラビリティを実現できるのでしょうか。

ただデータノードを増やすだけでは不十分です。水平方向と垂直方向の両方のスケーラビリティを組み込むこと、そして同時に高レベルのトレランス、レジリエンス、可用性を確保することが、非常に重要です。システムを機能的で管理しやすいものにする上で最優先されるのは、データ管理の簡素化、そしてメンテナンス、アップグレード、可用性といった観点からソフトウェア管理を合理化することです。

さらに、データが絶えず更新・削除されながら移動・拡大している動的なものであることを踏まえれば、1,000ペタバイト以上のデータを分散型の多並列処理システム内で演算処理できることは必須条件となります。Apache Ozoneのようなオープンソースのソリューションは、メタデータをシステム全体に分散させてエクサバイト規模のデータを扱えるよう設計されており、これを活用すればデータ管理のスケーラビリティを促進できるだけでなく、大規模環境でのレジリエンスと可用性の確保にもつながります。

なお、IDCによると、世界全体のデータ量は、2025年には163ゼタバイト(ZB)にまで膨張すると予想されており、これは今日の世界に存在するデータ量の10倍にあたります。その上、そのデータ量のうち、非構造化データが80%占めると見積もられています。これについては「(4)データのタイプを考慮する」で改めて取り上げます。

テクノロジースタックを吟味する

以上のようなスケールへの対応は、単一目的のソリューションを多数寄せ集めることでも可能ですし、すべての機能を網羅した統合プラットフォームで対応することもできます。

ただ、これまでよりも格段に多いデータ量を扱いながら、不正行為への対応、サイバーセキュリティ、オブザーバビリティ(第5回で紹介)、インテリジェントオペレーションを実現していくためには、各種ツールを併用するよりも統合プラットフォームによる一元的なアプローチを取るほうが、パフォーマンス的にも経済的にも優位性があるケースが多いです。どのようなアプローチを取るにしても、十分に吟味したうえで対応していくことが求められます。

データのタイプを考慮する

とりわけ非構造化データが極めて大量にある場合、どうすればデータライフサイクルを管理することができるのでしょうか。

構造化データはあらかじめ定義されている項目や表の形式で整理されていますが、非構造化データにはきちんと定義されたスキーマや構造がありません。そのため、データベース管理のための従来型のツールや手法を使うだけでは、非構造化データからの検索、分析、洞察抽出を行うことは、いっそう難しくなっています。

こうしたなか、大量の非構造化データを分類・分析することが可能なツールが出現してきました。これらのツールは、自然言語処理や画像認識をはじめとする高度な手法を用いることにより、非構造化データから有益な洞察を抽出することができます。

例えば、これらのツールは画像内の物体を検索したり、自動検出したりすることが可能です。これにより、一時停止の標識、歩道、歩行者などの物体を見つけることができ、緊急サービスや警察の業務などに役立ちます。

ライフサイクル全体にわたってデータを評価する

Clouderaの調査によると、自社がデータライフサイクルの全ての段階で分析に携わっていると回答したIT部門の意思決定者の割合は、全体のわずか12%にとどまっています。データから洞察、さらには価値へとつなげるまでの、あらゆる段階の分析を行う機能を持っていなければ、組織はイノベーションを推進するために必要な力を欠くことになります。Clouderaではデータライフサイクルを次のように整理し、コントロールしています。

- 取り込み:クラウド環境でもハイブリッド環境でも、データ構造に関係なくあらゆるデータソースに接続し、どこにでもデータを配信。重要なビジネスイベントに即座に対応するため、そのイベントをリアルタイムで処理して任意の宛先に送信。 - 準備:エンタープライズデータエンジニアリングチーム向けに開発された統合ツールセットとクラウドネイティブサービスを用いた、複雑なデータパイプラインのオーケストレーションと自動化。 - 分析:データの採取、探索、検索、アクセス、分析、可視化を大規模に実行すると同時に、セルフサービスとしてデータを低コストですばやく簡単に分析。 - 予測:データサイエンスチームのイノベーションを加速。チームが協力して、モデルのトレーニング、評価、公開、監視や独自のML Webアプリの構築と管理を行い、ビジネスに関する洞察やアクションにつながるモデルをより短い時間でより多く提供。 - 公開:開発者が拡張性とパフォーマンスに優れたアプリケーションを迅速に開発、デプロイできるよう支援。ユーザーが独自のダッシュボードやビジュアルアプリをすばやく作成・公開することを可能に。

世界中のデータ量が今後増加の一途をたどることは間違いありません。減ることのないデータへの対応はより難しくなるでしょう。しかし適切な方法で対応にあたることで、それらのデータに対処ですることは可能なのです。

著者プロフィール

大澤 毅(おおさわ たけし) Cloudera株式会社 社長執行役員


IT業界を中心に大手独立系メーカー、大手SIer、外資系 IT企業のマネジメントや数々の新規事業の立ち上げに携わり、20年以上の豊富な経験と実績を持つ。Cloudera入社以前は、SAPジャパン株式会社 SAP Fieldglass事業本部長として、製品のローカル化、事業開発、マーケティング、営業、パートナー戦略、コンサルティング、サポートなど数多くのマネジメントを担当。2020年10月にCloudera株式会社の社長執行役員に就任。