ケーススタディ: クラウドに依存しない製品を迅速に構築して提供する方法

2 年前、オブジェクトおよびグラフ データベースのプロバイダーである Objectivity は、クライアントのために新しいデジタル エコシステムの構築に取り組んでいました。クライアントは大きな市場シェアを持っていましたが、技術的に革新的でもデジタルに精通していませんでした。これを解決するため、彼らはポートフォリオを管理するためのソフトウェア プラットフォームを構築する計画を立てました。

[[325346]]

このクライアントの利点は、デジタル資産に近くなり、デジタル エコシステムを最新の状態に保つのが容易になり、より高度なエンドユーザー機能の開発が可能になることです。さらに、ソリューションはサードパーティのシステムや IoT センサーと統合して、より多くのデータを処理してユーザーに提供する必要があります。ビジネスの観点から見ると、これらはすべて「データが新たな金」である理由として最適ですが、時間と予算には限りがあります。

この顧客との話し合いの後、Objectivity は 3 か月後に最小限の実行可能な製品 (MVP) を納品しました。この間、Objectivity はチームを編成し、ビジネス ドメインを理解し、製品ビジョンを作成し、アーキテクチャを定義し、商業化に間に合うように実用的な最小限の実行可能な製品 (MVP) を提供しました。

Objectivity は短期間で非常に多くのことを行う必要があったため、適切な優先順位を設定し、許容できる制限について合意することが重要でした。結果は単なるプロトタイプ以上のものになりました。 Objectivity は、製品の商業的な実証後に潜在顧客がその製品を購入したいと希望する場合、はるかに短い期間で製品を発売できるはずだと予想しています。さらに、プロジェクトをさらに困難にしたのは、製品がクラウドに依存せず、簡単に拡張でき、マルチテナントに対応できる必要があったことです。技術者にとって、これは重要な疑問を提起します。この目標を達成するには、どのような技術的なトレードオフを行う必要があるのでしょうか?

技術的な考慮事項

ソフトウェア側では、ソリューションは、一部のコンポーネントをあまり手間をかけずに変更できるように設計する必要があります。顧客はこれらのオプションを使用する場合（電子商取引の支払いプロバイダーを変更する場合など）もあれば、使用しない場合もあります。データベース エンジンの変更に備えていた古き良き時代を覚えている人も多いかもしれませんが、それ以降、ほとんど変更はありません。

懐疑論者は「ベンダーロックインのリスクはどれほど大きいのか」と疑問に思うかもしれません。また、Google が 2018 年に Maps API の価格を 14 倍 (場合によっては) に値上げしたことを覚えている人もいるかもしれません。これは、脅威が現実であることを証明しています。

では、これはクラウド非依存にどのように当てはまるのでしょうか?クラウドの独立性は簡素化できますか? 「クラウドに依存しないアーキテクチャは誤解である」または「クラウド コンピューティング (およびその速度) を信じるなら、クラウドに依存しないアーキテクチャを信じることはできない」と言う人もいます。次の画像は、利用可能なオプションの範囲を示しています。

この文脈では、クラウド ネイティブとは、特定のクラウド コンピューティング プロバイダーの強み (つまり、パフォーマンスの向上、スケーラビリティの向上、コストの削減) を活用できることを意味します。

一般的に、企業が非依存アーキテクチャに先行投資するほど、クラウド コンピューティング サービスへの切り替えコストは低くなります。しかし同時に、より複雑で非依存的な設計は生産性を低下させ、配信プロセスを遅くします。建築家は、制約にとらわれず、合意された時間と予算の制約を遵守する、満足のいく最適なソリューションを見つけるという課題に直面しています。それで、どうやってそれを行うのですか?たとえば、AWS のエンタープライズ戦略家である Mark Schwartz 氏が提案した切り替えコストを考えてみましょう。彼は企業に以下の点を考慮するよう勧めています。

• クラウドプロバイダーを離れるコスト。
• 上記が起こる可能性。
• クラウド切り替えリスクのコストを軽減します。

さらに、ソリューションの次のような複数の側面を考慮する必要があります。

• 展開方法;
• ホスティング モデル。
• ストレージ;
• プログラミング言語。

物語は続く

クラウドに依存しないソリューションは、幸運にも災いにもなり得ます。ビジネスの将来の成功につながることもあれば、実現を遅らせることもあります。したがって、資産管理プログラムでは次の側面が重要です。

• クラウド プラットフォームを切り替えるコスト。企業は、何らかのクラウド プロバイダーの出口戦略を採用しなくても、Microsoft Azure と IBM Cloud の両方でソリューションを実行し、どちらの方法でも意味を成すことができます。
• 小規模から中規模の先行投資。顧客は多額の先行技術投資を避けたいと考えており、新製品を定義する際には機能実験のための余地を残しておく必要があることを理解する必要があります。
• 不可能ではありますが、企業はオンプレミスでデータセンターを運用する準備をする必要があります。当時、新製品の潜在的な企業顧客がクラウド プラットフォームのインストールにそのような制限を課す可能性があると想定されていました。

アプリケーション アーキテクチャとそのバリエーションを評価する 1 つの方法は、適応性機能を使用することです。このコンセプトは、進化計算のアイデアを利用して、特定の設計が特定のプロジェクトの重要な目標セットの達成にどれだけ近いかを計算します。

したがって、次のシナリオを想定します。

アーキテクチャの適合性 = 生産性 - 初期投資 - 切り替えコスト + 社内サポート

これを念頭に置いて、次のオプションを検討してください。

解決

すべての要件を満たすため、ハイブリッド アプローチが選択されました。さらに、新しいプロジェクトでのコンテナ化に関しては、企業がベンダーロックインを回避しようとしている場合、考えるまでもないことです。ソリューションの大部分は、管理された Kubernetes クラスターで実行される一連のサービスとワーカーとして .NET Core に実装されています。永続ストレージの設定に時間を無駄にしないために、マネージド PostgreSQL をすべてのコンポーネントの共通データ ストアとして使用します。 Postgres は、複数のクラウド プラットフォームでマネージド サービスとして利用できるオープン ソース データベースです。また、プラットフォームのもう 1 つの重要な側面である JSON ドキュメントもサポートしています。

IoT 統合に関しては、クラウド ネイティブ実装 (Azure IoT Hub など) が選択されました。よりスケーラブルなアプローチを採用するだけでなく、実装もはるかに高速になります。また、必要に応じて、別のクラウド プラットフォームで動作するように簡単に書き換えることができます。コンテナホスト型 IoT ハブの調査結果から、特にセンサーとの双方向通信のサポートに関しては、単一のソリューションでは期待に応えられないことがわかりました。切り替えコストをさらに削減するために、IoT イベントに対して標準メッセージ形式が定義され、メッセージの変換は Kubernetes クラスターの外部 (Azure 関数など) で行われ、残りのすべての処理はクラスター内で行われるようになっています。

最終結果

Objectivity は、Azure クラウド プラットフォーム上で実行されるソリューションを、顧客への商用デモに間に合うように提供しました。データ ストレージのトレードオフは、長年にわたり実証されてきました。 Objectivity は自社製品の一部を Azure および IBM Cloud プラットフォームにインストールしており、すべての機能が正常に動作しています。 Kubernetes もうまく機能します。ただし、プロバイダーごとに微妙な違いがあることを覚えておくことが重要です。たとえば、Ingress コントローラーは IBM Cloud Platform では自動的にインストールされますが、Azure Cloud Platform では自分でインストールする必要があります。さらに、Kubernetes にはクラウド プロバイダーごとに異なるストレージ クラスがあります。

プレゼンテーションの数か月後、Objectivity は IoT Watson を使用して 2 番目の IoT インスタンスも開発し、クラウド ネイティブ アプローチが適切なトレードオフであることを証明しました。ただし、さまざまなキューの実装間の違いに注意することが重要です。特に .NET の経験がある場合、Azure Service Bus を使用して新しい機能を提供するのは非常に簡単です。ただし、RabbitMq に切り替えた後、特定のキューイング機能がサポートされていないことに気付く場合があります。この段階では、顧客がコードにそれらを実装する必要があり、不必要な複雑さが生じます。これらの課題を回避するには、高速配信のために既に知られているものを選択するのではなく、最初からキューに依存しない実装に固執してください。