企業のデータアーキテクチャを支える7つのテクノロジー

企業のデータアーキテクチャを支える7つのテクノロジー

7つの主要なテクノロジーが、企業のITを「再プラットフォーム化」して、大量で貴重なデータへの、より速く、より簡単で、より柔軟なアクセスを可能にします。

この記事は、7 essential technologies for a modern data architectureの引用・翻訳になります。

エンタープライズITインフラストラクチャの再プラットフォーム化は簡単な作業ではありません。プラットフォームの再構築は通常、主要なビジネス環境の変化によって引き起こされますが、最近のデジタルトランスフォーメーションはそれに当たります。シンプルに言うと、30年近くエンタープライズITを支配してきたこれまでの従来型のプラットフォームは、ビジネスを前進させるために必要なワークロードをもはや処理できなくなりました。

デジタルトランスフォーメーションの中心に考えるべきものはデータであり、データはビジネスで最も価値のあるものになっています。組織(企業)は、互換性のない形式、従来型のデータベースの制限、複数システムのデータを柔軟に組み合わせることができないなど、データの使用に苦労しています。下記で紹介する7つのテクノロジーはその状況を変えることができます。

ソフトウェアの構造を改善していくことは、データ利用に関する障壁を取り除くために必要な1つの主要な側面です。一方で、「データの俊敏性」を高めるには、より柔軟なデータベースとよりスケーラブルなリアルタイムストリーミングプラットフォームも必要です。

実際、少なくとも下記で紹介する7つ以上のITインフラに関するテクノロジーが組み合わされて、柔軟でリアルタイムに利用できる「データファブリック」を企業に提供しています。

すぐに置き換えられるテクノロジーとは異なり、下記の7つのテクノロジーは、多くのユーザーと多くのユースケースの両方のニーズを満たすように拡張できます。これらのテクノロジーはビジネスにとって、より速く、より高度な意思決定を実現し、より良い顧客体験を生み出す力を持っています。

1.NoSQLデータベース

RDBMS(リレーショナルデータベース)は、30年近くデータベース市場を支配してきました。しかし、従来のリレーショナルデータベースは、データ量が増え続け、データを処理する必要があるペースが加速している昨今において、十分ではないことが示されています。

NoSQLデータベースは、速度と拡張性を向上させるためにRDBMSに変わる技術として利用されています。MongoDBのようなドキュメントデータベースの場合、ソフトウェアエンジニアリングの観点からはるかに単純なモデルを構築することが可能になります。そして、この単純な開発モデルは、市場投入までの時間を短縮し、企業が顧客や内部ユーザーのニーズにより迅速に対応するのに役立ちます。

2.リアルタイムなストリーミングプラットフォーム

顧客の要求にリアルタイムで対応することは、顧客体験の向上のために重要になります。過去10年の間に、コンシューマビジネスの市場では大規模な変革が起こりましたが、それは特に不思議なことではなく、企業が顧客にリアルタイムに反応する能力(テクノロジー)を獲得したからです。

顧客の要望に24時間以内に回答することはあまり良いことではありません。なぜなら、顧客はすでに23時間前に商品の購入や行動の決断を実施しているためです。リアルタイムモデルに移行するには、イベントストリーミングが必要になります。

メッセージ駆動型アプリケーションは何年も前から存在しています。ただし、昨今のストリーミングプラットフォームに関する技術は、以前よりもはるかに優れており、はるかに低コストです。ビジネスを最適化するために、ストリーミングテクノロジーの最近の進歩は、これまでになかった多くの新しい方法を企業に提供します。また、顧客への対応は1つの側面であり、ストリーミングテクノロジーは、オペレーションにも価値を提供します。例えば、ソフトウェア開発チームとテストチームにリアルタイムのフィードバックループを提供することで、企業が製品の品質を向上させ、新しいソフトウェアをより早く公開するのにも役立ちます。

3.Dockerとコンテナ

コンテナーは、開発者とオペレーターの両方、および組織自体に大きなメリットをもたらします。

インフラストラクチャ環境の分離に対する従来のアプローチは、静的パーティション分割(物理サーバーまたは仮想マシンによる環境の分離)でした。この場合、分割した各パーティションに個別にリソースを割り当てます。静的パーティションを使用すると、問題のトラブルシューティングが容易になりますが、ハードウェアを十分に活用したリソース提供をすることが困難です。たとえば、Webサーバーは、利用可能なコンピューティング能力を平均で約10パーセントしか消費しません。

コンテナテクノロジーの大きな利点は、これらとは新しいタイプの分離された環境を作成できることです。コンテナーの理解が少ない人は、Ansible、Puppet、Chefなどのツールを使用しても同じメリットが得られると信じているかもしれませんが、実際、これらのテクノロジーは非常に補完的です。これらの自動化ツールでは、異なるインフラストラクチャとハードウェアのセットアップ間でワークロードを自由に移動することはできません。

コンテナの場合は、同じコンテナをオンプレミスのデータセンターのハードウェアであったり、パブリッククラウドの仮想マシンで実行できます。変更は必要ありません。真のワークロードモビリティを実現できます。

4.コンテナリポジトリ

コンテナリポジトリは俊敏性の向上にとって重要です。コンテナイメージを構築するためのdevopsプロセスと、それらを格納するためのリポジトリがなければ、各コンテナは、そのコンテナを実行できるすべてのマシン上に直接構築する必要があります。リポジトリを使用すると、そのリポジトリから読み取るように構成された任意のマシンでコンテナイメージを起動できます。

これがさらに複雑になるのは、複数のデータセンタにまたがる場合です。コンテナイメージが1つのデータセンターに組み込まれている場合、イメージを別のデータセンターに移動するにはどうすればよいですか?理想的には、コンバージドデータプラットフォームを活用することで、データセンター間でリポジトリをミラーリングできるようになります。ここで重要なのは、オンプレミスとクラウドの間のミラーリング機能が、オンプレミスのデータセンター間とは大きく異なる可能性があるということです。コンバージドデータプラットフォームは、組織で使用している物理インフラストラクチャやクラウドインフラストラクチャに関係なく、これらの機能を提供することで、この問題を解決します。

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

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

これまで見てきたような、MapR-DBやMongoDBなどのドキュメントデータベース、MapR-ESやApache Kafkaなどのイベントストリーミングプラットフォーム、Kubernetesなどのオーケストレーションツール、そしてDockerコンテナにソフトウェアを構築してデプロイする、これらの新しいインフラストラクチャコンポーネントを理解した後に、マイクロサービスの実現を考えることができます。

6.マイクロサービス

歴史的に言えば、マイクロサービスの概念は新しいものではありません。これまでと現在の違いは、NoSQLデータベース、イベントストリーミング、コンテナオーケストレーションなどのテクノロジーを活用して、何千ものマイクロサービスにスケールできることです。データストレージ、イベントストリーミング、インフラストラクチャオーケストレーションに関する新しいテクノロジーがなければ、大規模なマイクロサービスの展開は不可能です。膨大な量のデータ、イベント、およびコンテナインスタンスを管理するために必要なインフラストラクチャは、必要なレベルに拡張できません。

マイクロサービスとは、俊敏性を提供することです。本質的にマイクロサービスは、通常、単一の機能、または機能の小さなグループで構成されます。作業の機能単位が小さく、焦点が絞られているほど、サービスの作成、テスト、および展開が容易になります。これらのサービスはそれぞれ分離されている必要があります。そうしないと、マイクロサービスの俊敏性の約束が失われます。マイクロサービスは他のテクノロジーを活用して実現されますが、通常は負荷分散されたRESTAPIまたはイベントストリームのいずれかを介して行われます。イベントストリームを使用すると、要求と応答のトピックを活用して、イベントの履歴を簡単に追跡できます。このアプローチは、リクエストフロー全体とリクエスト内のすべてのデータを後から参照できるようになるため、トラブルシューティングに大きなメリットがあります。

マイクロサービスは小さな作業単位をカプセル化し、相互に分離されているため、時間の経過とともにサービスを交換またはアップグレードする際のハードルはほとんどありません。密結合に作られた古いモデルでは、関係するシステムや接続の処理をシャットダウンしてから、後でそれらの再起動、再連携を確認する必要がありました。また、手動構成ではエラーが発生しやすくなるため、負荷分散はこれらの実装のもう1つの大きな問題でした。

7.Function as a Service

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

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

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

FaaSは、マイクロサービスの採用における次のフェーズになります。ただし、FaaSに取り組む際に考慮しなければならない主要な要素が1つあります。それは、ベンダーロックインです。 FaaSは、特定のストレージメカニズム、特定のハードウェアインフラストラクチャ、およびオーケストレーションを隠します。これらはすべて、開発者にとって素晴らしいことです。しかし、この抽象化の技術は標準化されていないため、FaaSの利用はベンダーロックインになる可能性が高いです。 パブリッククラウド上のFaaSからの移行は、それまでのIT資産のほぼ100%を作り直す必要があり、破棄せずにはほぼ不可能です。コンバージドデータプラットフォームからのイベントを活用することにより、FaaSにさらに系統だった方法でアプローチすると、クラウドプロバイダー間の移動が容易になります。

引用

7 essential technologies for a modern data architecture

サーバ・クラウドカテゴリの最新記事