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

エンタープライズ 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 にアプローチできれば、クラウド プロバイダー間の移動が容易になります。