クラウドネイティブ変革のための6つの重要なデータ戦略

今日、多くの組織がデジタル変革戦略としてクラウドネイティブ プラットフォームを採用しています。クラウド ネイティブにより、企業は応答性に優れたユーザー フレンドリーなアプリケーションをより柔軟な方法で提供できるようになります。しかし、クラウド ネイティブ変換をサポートするデータ アーキテクチャは、自動的に処理されるだろうという期待から見落とされがちです。データがあらゆる組織の情報通貨となる中、企業はクラウド変革中によくあるデータミスをどのように回避できるでしょうか?クラウドネイティブ アプリケーションを構築するときに注意すべきデータの問題は何ですか?データから貴重な洞察を得るにはどうすればよいでしょうか?

[[230147]]

企業がクラウド ネイティブ変革に移行する際に考慮しなければならない 6 つの重要な要素は次のとおりです。

（１）サービス指向アーキテクチャ（SOA）を放棄し、マイクロサービスを採用する

依然としてサービス指向アーキテクチャ (SOA) に基づいたレガシー アプリケーションは数多く存在しますが、アーキテクチャの考え方は変化し、マイクロサービスが広く普及しています。開発者は、モノリシックなアプリケーションを構築するのではなく、連携して動作する多数の独立したサービスを作成することで、多くのメリットを得ることができます。マイクロサービス アーキテクチャにより、アプリケーション開発の柔軟性が向上し、コード ベースがシンプルになります。更新と拡張は個別に実装でき、サービスはさまざまな言語で記述でき、選択したさまざまなデータ レイヤーやプラットフォームに接続できます。この戦略により、開発者と運用スタッフはより調和のとれた形で連携できるようになります。このコンポーネント化されたアーキテクチャには、さまざまなデータ型、構造、プログラミング言語を簡単にサポートできるデータベース プラットフォームが必要です。

（２）12ファクターアプリとクラウドネイティブマイクロサービス

12-Factor App は、組織がクラウドネイティブ アプリケーションを構築するのに役立つ一連のルールとガイドラインです。これは良い出発点ですが、データ プラットフォームに関しては、さらに検討が必要な要素 (4 番目と 5 番目) がいくつかあります。

要因 4: サポート サービスを追加のリソースとして見る: ここでの「サポート サービス」は、主にデータベースとデータ ストレージを指します。つまり、マイクロサービスでは、スキーマと基盤となるデータ ストアの専用の単一所有権が必要になります。

5 番目の要素: ビルド段階と実行段階を厳密に分離します。ビルド段階と実行段階を分けるということは、アプリケーションをよりステートレスなプロセスとして実行する必要があることを意味し、状態は通常、バックグラウンド サービスに読み込まれます。これはさらに、データベースとデータ ストアがステートフル サービスである必要があることを意味します。

（３）継続的インテグレーション／継続的デリバリー

サービス プロセスの増加 (各サービスは個別にデプロイ可能) には、継続的インテグレーションまたは継続的デリバリー (CI/CD) と呼ばれる自動化されたデプロイメントおよびロールバック メカニズムが必要です。実際、成熟した CI/CD 機能がなければ、マイクロサービスの価値を十分に実現することはできません。この一時的なアーキテクチャは、データベース インスタンスも一時的なものであり、必要に応じて簡単に起動できる必要があることを意味することに注意してください。適切なクラウドネイティブ プラットフォームとサポート データ プラットフォームを使用すると、マイクロサービスを簡単に展開できるようになります。クラウド ネイティブ プラットフォームは、実行するサービスの管理を処理し、データベースは、必要に応じてデータのスケーリングと監視、シャードの追加、再バランス調整、再配置、またはフェイルオーバーを処理する必要があります。データベースとクラウドネイティブ ソリューションを組み合わせることで、データベースとプラットフォームの監視の運用上の負担が軽減され、企業は高品質のソフトウェアの開発と導入に多くの時間を費やすことができます。

（4）マルチクラウド展開モデルの重要性

今日の企業は、災害復旧状況に備えるため、異なるクラウド コンピューティング インフラストラクチャでのホスティング アプリケーション間の財務上の差異を利用するため、セキュリティを強化するため、または単にベンダー ロックインを回避するためなど、さまざまな理由でマルチクラウド戦略を採用しています。アプリケーション コードは、実行が想定されるプラットフォームから独立している必要があります。

（５）全体論と非全体論

従来のデータ アクセスおよびデータ移動の方法では、実現が困難です。従来のアプローチでは、データ ウェアハウス/データ レイク内の他の運用データ ストアとプライマリ データ ストアにデータのコピーを作成し、数時間または数日後にデータを一括して更新することがよくありました。組織がマイクロサービスと設計パターンを採用すると、異なるタイプのデータ ストア間でのデータ転送の遅延によって俊敏性が損なわれ、組織がビジネス イニシアチブを前進させることができなくなります。

ストラングル パターンを使用してモノリシック アプリケーションをマイクロサービス アーキテクチャに徐々に移行すると、特定の機能が新しいアプリケーションやサービスに徐々に置き換えられます。つまり、関連するデータ ストアもパーティション分割およびコンポーネント化される必要があり、各マイクロサービスには独自の関連するデータ ストア/データベースが存在することになります。

データの観点から見ると、これは次のことを意味します。

• マイクロサービスが追加されるたびに、データベース インスタンスの数も増加し、これも需要の増減を示します。
• これらのマイクロサービスが相互に通信するには、あらゆるプラットフォームや言語で柔軟かつ拡張可能な、便利な REST API などの追加の HTTP 呼び出しを行う必要があります。多くの場合、マイクロサービスは変更を示すイベントを単に公開し、リスナー/サブスクライバーは関連するアプリケーションを更新します。

（6）クラウドネイティブデータベースの基本要件

1 ミリ秒未満の応答時間は、いくつかの特殊なアプリケーションでのみ使用されます。しかし、今日のマイクロサービス アーキテクチャの世界では、すべてのアプリケーションに必須となっています。このレイテンシ要件には、高性能でスケーラビリティの高いデータベース ソリューションが必要です。

アクティブ-アクティブデータレプリケーション

バッチ モードでのデータ複製は、かつては一般的なアプローチでした。しかし、リアルタイム アプリケーションの場合、イベント ストレージとイベント ソーシングのレプリケーションがより魅力的になります。データを共有する必要のある疎結合のマイクロサービス アプリケーションでは、調整可能な一貫性を備えたアクティブ/アクティブ データ レプリケーションが必要です。多くのお客様がアクティブ/アクティブ展開モデルを使用する理由は、次のように多数あります。

• 継続的に更新されるマイクロサービス間で共有されるデータセット。
• ユーザー エクスペリエンスに影響を与えないように、データ センター間でデータをシームレスに移行します。
• 障害シナリオを軽減し、2 番目のデータ センターにフェールオーバーしてダウンタイムを最小限に抑えます。
• 大量の受信トラフィックを処理し、シームレスな同期により複数のサーバーに負荷を分散します。
• 複数の地理的な場所にわたってデータを同期する必要がある、地理的に分散されたアプリケーション (マルチプレイヤー ゲームやリアルタイム入札/投票アプリケーションなど)。

データの高可用性

モノリシック アプリケーションを、それぞれ独自のライフサイクルを持つマイクロサービスに分割する場合、データの可用性をどのように確保しますか?クラウドネイティブ アプリケーション開発者は、リカバリ ポイント目標 (失われるデータの量)、リカバリ時間目標 (インシデントが発生した場合、サービスの復元にどのくらいの時間がかかるか)、高可用性機能、インストール トポロジ、およびフェイルオーバー戦略に基づいてデータ ストレージを選択する必要があります。単一ノードのデータベース インスタンスは、障害シナリオに影響を与えるだけでなく、可用性に影響を与えるクライアントのダウンタイム イベント (バージョン アップグレードなど) にも影響を与えます。

高可用性の要件は多くの場合、アプリケーションの重要度によって異なりますが、適切なデータベースとクラウドネイティブ ソリューションを組み合わせることで、オンプレミスからミッション クリティカルなアプリケーションまで、幅広いユース ケースに対応するさまざまな高可用性インストール戦略がサポートされます。