ビッグデータアーキテクチャのいくつかの主要テクノロジー-見出し-php.cn

エンタープライズ IT インフラストラクチャプラットフォームの再構築は複雑な作業です。プラットフォームの再構築は、主要なビジネス推進要因の変化によって引き起こされることが多く、まさにそれが今起こっていることです。簡単に言うと、30 年近くにわたってエンタープライズ IT テクノロジーを支配してきたプラットフォームは、ビジネスを前進させるために必要なワークロードの需要を満たすことができなくなりました。

ビッグデータアーキテクチャのいくつかの主要テクノロジー

デジタル変革の中核はデータであり、ビジネスにおいて最も価値のあるものとなっています。組織は、互換性のない形式、従来のデータベースの制限、および複数のソースからのデータを柔軟に組み合わせることができないために消費するデータに長い間悩まされてきました。新興テクノロジーの出現により、これらすべてが変わることが約束されています。

ソフトウェア導入モデルの改善は、データ使用の障壁を取り除く重要な側面です。「データの俊敏性」を高めるには、より柔軟なデータベースとよりスケーラブルなリアルタイムストリーミングプラットフォームも必要です。実際、企業に柔軟なリアルタイムの「データファブリック」を提供するために組み合わせることができる基盤テクノロジーが少なくとも 7 つあります。

置き換えられるテクノロジーとは異なり、これら 7 つのソフトウェアイノベーションは、多くのユーザーのニーズや多くのユースケースに合わせて拡張できます。企業にとっては、より迅速に、より多くの情報に基づいた意思決定を行い、より良い顧客エクスペリエンスを生み出すことができます。

1. NoSQL データベース

RDBMS は、30 年近くデータベース市場を支配してきました。しかし、データ量の継続的な増加とデータ処理速度の加速に直面して、従来のリレーショナルデータベースには欠点が明らかになりました。 NoSQL データベースは、その速度と拡張能力により、その地位を引き継ぎつつあります。ドキュメントデータベースの場合、ソフトウェアエンジニアリングの観点から見たより単純なモデルが提供されます。このよりシンプルな開発モデルにより、市場投入までの時間が短縮され、企業が顧客や社内ユーザーのニーズにより迅速に対応できるようになります。

2. ライブストリーミングプラットフォーム

顧客にリアルタイムで応答することは、顧客体験にとって非常に重要です。過去 10 年間に消費者向け産業が大規模な混乱を経験したことは不思議ではありません。これは、企業がユーザーにリアルタイムで対応できるかどうかに関係しています。リアルタイムモデルに移行するには、イベントストリーミングが必要です。

メッセージ主導型アプリは何年も前から存在しています。しかし、今日のストリーミングプラットフォームはかつてないほど大規模で、安価になっています。ストリーミングテクノロジーの最近の進歩により、ビジネスを最適化するための多くの新しい方法への扉が開かれました。イベントストリーミングは、ソフトウェア開発およびテストチームにリアルタイムのフィードバックループを提供することで、企業が製品の品質を向上させ、新しいソフトウェアをより迅速に開発するのにも役立ちます。

3. Docker とコンテナ

コンテナは、開発者と運用者だけでなく、組織自体にも大きなメリットがあります。インフラストラクチャ分離に対する従来のアプローチは静的パーティショニングであり、各ワークロードに個別の固定リソースブロック (物理サーバーか仮想マシンかを問わず) を割り当てます。静的パーティショニングによりトラブルシューティングが容易になりますが、十分に活用されていないハードウェアのコストは高くなります。たとえば、平均的な Web サーバーは、利用可能な総コンピューティング能力の 10% しか使用しません。

コンテナーテクノロジーの大きな利点は、新しい分離方法を作成できることです。コンテナーについて最もよく知っている人は、Ansible、Puppet、Chef などのツールを使用しても同じ利点が得られると信じているかもしれませんが、実際には、これらのテクノロジーは高度に補完的です。さらに、企業がどんなに努力しても、これらの自動化ツールは、異なるインフラストラクチャやハードウェア設定間でワークロードを自由に移動するために必要な分離を実現できません。同じコンテナーは、変更を加えることなく、オンプレミスデータセンターのベアメタルハードウェアまたはパブリッククラウドの仮想マシン上で実行できます。これが真のワークロードモビリティです。

4. コンテナリポジトリ

コンテナリポジトリは俊敏性にとって重要です。コンテナーイメージを構築するための DevOps プロセスとそれを保存するためのごみ箱がなければ、各コンテナーは実行する前にすべてのマシン上で構築する必要があります。リポジトリを使用すると、リポジトリを読み取るマシン上でコンテナイメージを起動できるようになります。複数のデータセンターにわたって処理する場合、これはさらに複雑になります。 1 つのデータセンターでコンテナイメージを構築した場合、そのイメージを別のデータセンターに移動するにはどうすればよいですか? 理想的には、企業は統合データプラットフォームを活用して、データセンター間でリポジトリをミラーリングできるようになります。

ここで重要な点は、オンプレミスとクラウドコンピューティング間のミラーリング機能は、企業のデータセンター間のミラーリング機能とは大きく異なる可能性があるということです。統合データプラットフォームは、組織内でデータセンターインフラストラクチャが使用されているか、クラウドコンピューティングインフラストラクチャが使用されているかに関係なく、これらの機能を提供することで、企業のこの問題を解決します。

5. コンテナオーケストレーション

各コンテナには、静的なハードウェアパーティションではなく、独自のプライベートオペレーティングシステムがあるように見えます。仮想マシンとは異なり、コンテナーはコンピューティングとメモリの静的なパーティショニングを必要としません。これにより、管理者は大量のメモリを気にすることなく、サーバー上で多数のコンテナを起動できるようになります。 Kubernetes などのコンテナオーケストレーションツールを使用すると、コンテナの起動、移動、環境内の別の場所での再起動が非常に簡単になります。

新しいインフラストラクチャコンポーネントが配置された後、MapR-DB や MongoDB などのドキュメントデータベース、MapR-ES や Apache Kafka (Kubernetes などのオーケストレーションツール) などのイベントストリーミングプラットフォーム、および Docker コンテナーを構築するための DevOps プロセスを実装した後ソフトウェアをデプロイする場合、これらのコンテナにどのコンポーネントをデプロイする必要があるかという問題を理解する必要があります。

6. マイクロサービス

歴史的に、マイクロサービスの概念は新しいものではありません。現在の違いは、実現テクノロジー (NoSQL データベース、イベントストリーミング、コンテナオーケストレーション) が数千のマイクロサービスの作成に合わせて拡張できることです。データストレージ、イベントストリーミング、アーキテクチャオーケストレーションに対するこれらの新しいアプローチがなければ、大規模なマイクロサービスの展開は不可能になります。大量のデータ、イベント、コンテナーインスタンスの管理に必要なインフラストラクチャは、必要なレベルまで拡張できません。

マイクロサービスは俊敏性を提供することがすべてです。マイクロサービスは通常、1 つの関数または小さな関数セットで構成されます。作業の機能単位が小さく、集中しているほど、サービスの作成、テスト、デプロイが容易になります。これらのサービスは分離する必要があります。そうしないと、企業は俊敏性を備えたマイクロサービスの約束を失うことになります。マイクロサービスは他のサービスに依存できますが、通常は負荷分散された REST API またはイベントストリーミングを通じて行われます。イベントストリーミングを使用すると、企業はリクエストとレスポンスのトピックを使用してイベントの履歴を簡単に追跡できます。このアプローチには、リクエストフロー全体とリクエストからのすべてのデータをいつでも再生できるため、トラブルシューティングに大きな利点があります。

マイクロサービスは小さな作業をカプセル化し、相互に分離されているため、ほとんど障壁なくサービスを時間の経過とともに置き換えたりアップグレードしたりできます。レガシーモードでは、RPC のような密結合に依存すると、すべての接続を閉じてから再確立する必要がありました。手動構成ではエラーが発生しやすいため、これらを実装する場合、負荷分散は大きな問題になります。

7. Functions as a Service

マイクロサービスが業界を支配するのを見てきたように、サーバーレスコンピューティング、またはおそらくより正確には Functions as a Service (FaaS) と呼ばれるサービスの台頭も見られるでしょう。 FaaS は、コードを軽量フレームワークでラップし、コンテナに組み込み、オンデマンドで (ある種のトリガーに基づいて) 実行し、軽量フレームワークのおかげで自動的に負荷分散できるような方法でマイクロサービスを作成します。 FaaS の利点は、開発者がその機能にほぼ完全に集中できることです。したがって、FaaS はマイクロサービスアプローチの論理的な結論のように見えます。

イベントのトリガーは FaaS の重要なコンポーネントです。これがないと、作業を行う必要がある場合にのみ関数が呼び出され、リソースが消費されます。関数の自動呼び出しにより、FaaS は真に価値のあるものになります。誰かがユーザーのプロファイルを読み取るたびに、セキュリティチームに通知するために実行する必要がある機能である監査イベントが発生することを想像してください。より具体的には、特定の種類のレコードのみをフィルターで除外する場合があります。これは完全にカスタマイズ可能なビジネス機能なので、オプションにすることもできます。 FaaS のようなデプロイメントモデルを使用すると、このようなワークフローを完了するのが非常に簡単であることに注意することが重要です。

イベントの統合

サービスをトリガーする背後にある魔法は、実際にはイベントストリーム内のイベントだけです。特定の種類のイベントは他の種類よりもトリガーとして頻繁に使用されますが、企業がトリガーにしたいイベントはどれもトリガーになる可能性があります。トリガーとなるイベントはドキュメントの更新であり、新しいドキュメントに対して OCR プロセスを実行し、OCR プロセスからのテキストを NoSQL データベースに追加します。もっと興味深い考え方をすれば、画像がアップロードされるたびに、機械学習フレームワークを通じて画像の認識とスコアリングを行うことができます。ここには基本的な制限はありません。トリガーイベントが定義されている場合、何らかのイベントが発生し、そのイベントが関数をトリガーし、関数がその作業を完了します。

FaaS は、マイクロサービス導入の次の段階になります。ただし、FaaS に取り組む際に考慮しなければならない大きな要素が 1 つあります。それはベンダーロックインです。 FaaS は、特定のストレージメカニズム、特定のハードウェアインフラストラクチャ、およびオーケストレーションを隠します。これらはすべて開発者にとって素晴らしいことです。しかし、この抽象化により、ホスト型 FaaS 製品は、IT 業界がこれまで経験したことのないベンダーロックインの最大の機会の 1 つとなっています。これらの API は標準化されていないため、これまでに行われた作業のほぼ 100% を失わずに、パブリッククラウドの FaaS 製品から移行することはほぼ不可能です。統合データプラットフォームからのイベントを活用することで、より構造化された方法で FaaS にアプローチできれば、クラウドプロバイダー間の移動が容易になります。