クラウドネイティブへの5つの課題とその解決方法

私たちはクラウドネイティブの世界に住んでいます。 コンテナー、マイクロサービス、サーバーレス機能など、クラウドネイティブのテクノロジーやアーキテクチャの利点をすべて聞くことなく、テクノロジーブログを読んだり会議に参加したりすることはほとんどできません。

しかし、クラウドネイティブ化への期待が高まる中、レガシーのモノリシックアプリケーションからクラウドネイティブ戦略に移行するときに発生する課題を見過ごしがちです。 これらの課題は克服できますが、クラウドネイティブの移行戦略の一環として対処する場合に限られます。

そのために、最も一般的な5つのクラウドネイティブの課題と、それらを克服するための戦略を見てみましょう。

クラウドネイティブとは何ですか?

ただし、最初に、クラウドネイティブの実際の意味について説明します。

「クラウド」というすべてのものに誇大宣伝が置かれているため、「クラウドネイティブ」は、人々が現代と考えるあらゆるタイプのテクノロジーや戦略を意味するために使用されることがあります。 その観点から見ると、クラウドネイティブは比較的意味のないもう1つの流行語にすぎません。

一方、特定の限られた意味で投資する場合、クラウドネイティブは有用な用語と概念です。 クラウドネイティブコンピューティングの特性として「疎結合システム」と復元力を強調するCNCFの定義が気に入っています。 CNCF定義は、クラウドネイティブテクノロジーの例として、テクノロジーとアーキテクチャーの具体的かつ限定的なリスト(「コンテナー、サービスメッシュ、マイクロサービス、不変インフラストラクチャー、宣言型API」)も指します。

この記事では、CNCFのクラウドネイティブの定義を使用します。 次に、上記のようなテクノロジーや戦略を使用するときに発生する特定の課題について説明します。

クラウドネイティブの採用に対する課題

1)永続的なデータストレージ

多くのクラウドネイティブテクノロジーの一般的な課題の1つは、データを永続的に保存することです。 不変のインフラストラクチャモデルを使用してデプロイされたコンテナ、サーバーレス機能、およびアプリケーションは、アプリケーションのシャットダウン時にすべての内部データが破壊されるため、通常、内部にデータを永続的に保存する方法がありません。

この課題を解決するには、データストレージをアプリケーションおよびホスト環境から切り離して、データストレージへのアプローチを再考する必要があります。 アプリケーション環境内にデータを保存する代わりに、クラウドネイティブのワークフローはデータを外部に保存し、データをサービスとして公開します。 次に、データにアクセスする必要があるワークロードは、他のサービスに接続するのと同じようにデータに接続します。

このアプローチ(Kubernetesのボリュームなどのさまざまなツールによって可能になる)には2つの利点があります。 それ自体が永続的であるように設計されていないアプリケーションの永続的データストレージを有効にするだけでなく、複数のアプリケーションまたはサービス間で単一のストレージプールを簡単に共有することもできます。

2)サービス統合

クラウドネイティブアプリケーションは通常、一連の異なるサービスで構成されています。 この分散された性質は、モノリスと比較して、拡張性と柔軟性を高めるのに役立ちます。

しかし、それはまた、クラウドネイティブのワークロードには、成功を収めるためにシームレスに接続する必要のある、より多くの動く部分があることも意味します。

一部には、サービス統合は、開発者がクラウドネイティブアプリを構築するときに取り組むべき問題です。 各サービスのサイズが適切であることを確認する必要があります。 ベストプラクティスは、単一のサービスで複数のことを実行するのではなく、ワークロード内の機能のタイプごとに異なるサービスを作成することです。 できるからといってサービスを追加しないことも重要です。 別のサービスの形でアプリをさらに複雑にする前に、サービスが特定の目標を達成していることを確認してください。

アプリケーション自体のアーキテクチャを超えて、効果的なサービス統合は、適切な展開手法の選択にも依存します。 コンテナーはおそらく複数のサービスをデプロイしてそれらを単一のワークロードに統合する最も明白な方法ですが、場合によっては、サーバーレス機能、またはAPIで接続された非コンテナー化アプリが、サービスデプロイのより優れた方法である可能性があります。

3)管理と監視

アプリケーションの一部として実行しているサービスが多いほど、それらを監視および管理することが難しくなります。 これは当てはまります。追跡する必要があるサービスの数だけではなく、アプリケーションの正常性を保証するには、サービス自体だけでなく、サービス間の関係を監視する必要があるためです。

クラウドネイティブ環境でサービスを正常に監視および管理するには、1つのサービスの障害が他のサービスにどのように影響するかを予測し、どの障害が最も重要であるかを理解できるアプローチが必要です。 動的なベースライン設定、つまり静的なしきい値を、アプリケーション環境を継続的に再評価して正常なものと異常なものを判別するしきい値に置き換えることも重要です。

4)クラウドロックインの回避

ロックインリスクはクラウドに固有のものではありません。 それらは、ほとんどすべてのタイプのテクノロジーから発生する可能性があり、何十年にもわたって俊敏性への脅威となってきました。 ただし、クラウドネイティブのアプリケーションまたはアーキテクチャの場合、特定のクラウドプロバイダーまたはサービスに依存しすぎる脅威は、特定のワークロードを特定の方法で簡単にデプロイできるため、特に大きくなる可能性があります。特定のクラウドからのサービス。

幸いなことに、事前に計画を立てていれば、このクラウドロックインリスクを軽減することは簡単です。 コミュニティベースの標準(OCCIが推奨する標準など)を守ることは、ワークロードをあるクラウドから別のクラウドに簡単に移動できることを保証するために非常に役立ちます。 同様に、クラウドネイティブに移行するために使用するクラウドサービスを計画するときは、検討しているサービスのいずれかに、真にユニークで他のクラウドでは利用できない機能があるかどうかを検討してください。 もしそうなら、それらはあなたを閉じ込めることができるので、それらの機能を避けてください。

たとえば、さまざまなパブリッククラウドのサーバーレスコンピューティングプラットフォームでサポートされる特定の言語やフレームワークは、多少異なります。 たとえば、AWS LambdaはGoをサポートしていますが、Azureはサポートしていません。 そのため、Goでサーバーレス関数を作成しないことをお勧めします。 AWSを使用して最初にホストすることを計画している場合でも、この依存関係により、将来、別のクラウドに移行することが困難になります。 安全に賭けることができるJavaのような言語を使い続けてください。

5)クラウドネイティブ配信パイプラインアプリの構築

定義上、クラウドネイティブアプリはクラウドで実行されます。 クラウドは、パブリッククラウドでも、プライベート、オンプレミス、組織の環境でのハイブリッドクラウドでもかまいませんが、不変のインフラストラクチャとクラウド管理プロセスを意味します。 ただし、多くのアプリケーション配信パイプラインは、パブリッククラウドまたはコンテナで実行されているアプリケーションやサービスと統合すると、曇りにさらされていなかったり、不格好だったりする可能性がある従来のオンプレミス環境で主に実行されます。

これはいくつかの点で課題を引き起こします。 1つは、ローカル環境からオンプレミスにコードをデプロイすると、遅延が発生する可能性があることです。 もう1つは、ローカルで開発およびテストを行うと、本番環境のエミュレーションが難しくなり、展開後の予期しないアプリケーションの動作につながる可能性があることです。

これらのハードルを克服する最も効果的な方法は、CI / CDパイプラインをクラウド環境に移動することです。これは、不変のインフラストラクチャとクラウドのスケーラビリティやその他のメリットだけでなく、本番環境を模倣してパイプラインをより近くすることもできます。可能な限り—アプリに。 このようにして、コードはデプロイされた場所の近くに記述され、デプロイがより速くなります。 また、本番環境と同じテスト環境を起動するのも簡単になります。

完全にクラウドベースの開発は万人向けではなく、一部の開発者はクラウドベースのものよりもローカルIDEの親しみやすさと応答性を好みますが、CI / CDパイプラインが可能な限りクラウド環境で実行されるようにしてください。

結論

どのようにスピンしても、クラウドネイティブになることは困難です。 レガシーアプリケーションと比較して、クラウドネイティブアプリケーションはより複雑で、問題が発生する可能性のある場所が多くあります。 とはいえ、クラウドネイティブコンピューティングの課題は克服できます。課題に対処できる戦略を実装することが、クラウドネイティブアーキテクチャのみが提供できる俊敏性、信頼性、およびスケーラビリティを解放する鍵となります。