最新のクラウドネイティブアーキテクチャ: マイクロサービス、コンテナ、サーバーレスについて知っておくべきこと

この記事の目的は、現代のソフトウェア業界の重要なトピックであるクラウドネイティブ アプリケーションに光を当てることです。この投稿では、マイクロサービス、コンテナ、サーバーレス アプリケーションについて説明します。ここでは、これらのテクノロジーの実際的な利点と欠点について説明します。

マイクロサービス

マイクロサービス アーキテクチャは、最新のソフトウェア アプリケーションを構築するための強力なアプローチとして高い評価を得ています。では、マイクロサービスとは何でしょうか?マイクロサービスとは、ソフトウェア アプリケーションに必要な機能を、複数の独立した小さなソフトウェア サービス、つまり「マイクロサービス」に分割することと簡単に説明できます。各マイクロサービスは、独自の重点タスクを担当します。マイクロサービスが連携して大規模でスケーラブルなアプリケーションを形成するには、マイクロサービス間で通信してデータを交換する必要があります。

[[246733]]

マイクロサービスは、モノリシック アプリケーションの複雑さと柔軟性の欠如を克服する必要性から生まれました。モノリシック アプリケーションとは、必要なすべての機能が同じサービスにまとめてコーディングされているアプリケーションです。たとえば、次の図は、支払い処理とイベント予約を担当するモノリシック イベント (コンサート、ショーなど) 予約アプリケーションを表すものです。

ユーザーはアプリを使ってコンサートやショーを予約できます。ユーザーインターフェースが必要です。さらに、イベントを見つけるための検索機能、ユーザーの予約を処理して保存するための予約ハンドラー、イベントの検索を支援するイベント ハンドラー (空席があることを確認してから予約にリンクする) も必要になります。実稼働レベルのアプリケーションでは、支払い処理など、さらに多くのタスクが必要になりますが、ここでは上の図に示されている 4 つのタスクに焦点を当てます。

このモノリシック アプリケーションは、小規模から中規模の負荷に適しています。単一のサーバー上で実行され、単一のデータベースに接続し、同じプログラミング言語で記述されている可能性があります。

さて、ビジネスが急激に成長し、数十万または数百万人のユーザーに対応する必要がある場合はどうなるでしょうか?当初の短期的な解決策は、アプリケーションを実行しているサーバーが、より高い負荷に耐えられる強力なハードウェア仕様を備えていることを確認し、そうでない場合は、サーバーにメモリ、ストレージ、および処理能力を追加することです。これは垂直スケーリングと呼ばれ、重いアプリケーションを実行するためにハードウェア機能 (RAM やハード ドライブの容量など) を増やす行為です。ただし、アプリケーションの負荷が増加し続けるため、これは通常、長期的には持続可能ではありません。

モノリシック アプリケーションのもう 1 つの課題は、プログラミング言語が 1 つまたは 2 つに制限されることで生じる柔軟性の欠如です。この柔軟性の欠如は、アプリケーションの全体的な品質と効率に影響します。たとえば、node.js は Web アプリケーションを構築するための一般的な JavaScript フレームワークであり、R はデータ サイエンス アプリケーションで人気があります。モノリシック アプリケーションでは両方のテクノロジを同時に使用することは困難ですが、マイクロサービス アプリケーションでは、R で記述されたデータ サイエンス サービスと Node.js で記述された Web サービスを簡単に構築できます。

アクティビティ アプリケーションのマイクロサービス バージョンは次の形式になります。

このアプリケーションは、複数のサーバーにわたって拡張可能であり、これは水平スケーリングと呼ばれる手法です。各サービスは、専用のリソースを持つ別のサーバーまたは別のコンテナーにデプロイできます (これについては後で詳しく説明します)。さまざまなサービスをさまざまなプログラミング言語で記述できるため、柔軟性が向上し、さまざまな専門チームがさまざまなサービスに集中できるため、アプリケーションの全体的な品質が向上します。

マイクロサービスを使用するもう 1 つの大きな利点は、継続的デリバリーの容易さです。継続的デリバリーとは、ソフトウェアを頻繁にいつでもデプロイできる機能です。マイクロサービスによって継続的デリバリーが容易になる理由は、モノリシック アプリケーションの場合よりも、1 つのマイクロサービスにデプロイされた新しい機能が他のマイクロサービスに影響を与える可能性が低いためです。

マイクロサービスの問題点

マイクロサービスに大きく依存することの大きな欠点は、マイクロサービスの数と範囲が拡大するにつれて、長期的には管理が複雑になりすぎる可能性があることです。 Prometheus などの監視ツールや Docker などのコンテナ テクノロジを活用して問題を検出し、ホスト環境の汚染やサービスの過剰エンジニアリングを回避する方法があります。ただし、これらの方法には労力と時間が必要です。

クラウドネイティブアプリケーション

マイクロサービス アーキテクチャは、クラウド ネイティブ アプリケーションに適しています。クラウド ネイティブ アプリケーションは、クラウド コンピューティング アーキテクチャ用にゼロから構築されたアプリケーションとして簡単に定義されます。つまり、分散型のスケーラブルなインフラストラクチャにデプロイされることを想定してアプリケーションを設計すると、そのアプリケーションはクラウド ネイティブになります。

たとえば、冗長なマイクロサービス アーキテクチャを使用してアプリケーションを構築すると、アプリケーションはクラウド ネイティブになります。このアーキテクチャにより、アプリケーションを分散形式でデプロイできるようになり、スケーラブルになり、ほぼ常に利用可能になります。クラウドネイティブ アプリケーションは、常に AWS などのパブリック クラウドにデプロイする必要はなく、独自の分散クラウド インフラストラクチャ (ある場合) にデプロイできます。

実際、アプリケーションを完全にクラウドネイティブにする理由は、マイクロサービスを使用するだけではありません。アプリケーションでは継続的デリバリーを使用し、中断することなく運用アプリケーションに更新を提供できるようにする必要があります。アプリケーションでは、メッセージ キューや、コンテナーやサーバーレスなどのテクノロジも使用する必要があります (コンテナーとサーバーレスは、最新のソフトウェア アーキテクチャにおける重要なトピックです)。

クラウドネイティブ アプリケーションでは、多数のサーバー ノードへのアクセス、事前にデプロイされたソフトウェア サービス (メッセージ キューやロード バランサーなど) へのアクセス、継続的デリバリー サービスとの簡単な統合などが想定されています。

クラウドネイティブ アプリケーションを AWS や Azure などの商用クラウドにデプロイする場合、アプリケーションはクラウドでのみ利用可能なソフトウェア サービスを使用することを選択できます。たとえば、DynamoDB は、実稼働アプリケーションで AWS 上でのみ使用できる強力なデータベース エンジンです。もう 1 つの例は、Azure の DocumentDB データベースです。また、Amazon Simple Queue Service (SQS) などのクラウド専用のメッセージキューもあり、これを使用して AWS クラウド内のマイクロサービス間の通信が可能になります。

前述したように、クラウドネイティブ マイクロサービスは、サービス間の冗長性を可能にするように設計する必要があります。イベント予約アプリケーションを例にとると、アプリケーションは次のようになります。

各マイクロサービスには複数のサーバー ノードが割り当てられ、冗長なマイクロサービス アーキテクチャを展開できるようになります。何らかの理由でプライマリ ノードまたはサービスに障害が発生した場合、セカンダリ ノードが引き継いで、クラウド ネイティブ アプリケーションの永続的な信頼性と可用性を確保できます。ダウンタイムは大きな収益損失につながる可能性があるため、この可用性は、e コマース プラットフォームなどのエラー許容型アプリケーションにとって非常に重要です。

クラウドネイティブ アプリケーションは、開発者、企業、スタートアップに多大な価値をもたらします。

Prometheus は、マイクロサービスとクラウド コンピューティングの分野で注目に値するツールです。 Prometheus は、複雑なマイクロサービス アーキテクチャを監視し、アクションが必要なときにアラートを発行するために使用できるオープン ソースのシステム監視およびアラート ツールです。 Prometheus はもともと SoundCloud のシステムを監視するために作成されましたが、その後独立したプロジェクトへと進化しました。このプロジェクトは現在、クラウド ネイティブ アプリケーションの持続可能なエコシステムを構築するための基盤である Cloud Native Computing Foundation の一部となっています。

クラウドネイティブの限界

クラウド ネイティブ アプリケーションでは、アプリケーションの一部またはすべてを移行する必要がある場合、いくつかの課題に直面します。これは、アプリケーションがデプロイされている場所に応じて、さまざまな理由で発生する可能性があります。

たとえば、クラウドネイティブ アプリケーションが AWS などのパブリック クラウドにデプロイされている場合、クラウドネイティブ API はクロスクラウド プラットフォームではありません。したがって、アプリケーションで使用される DynamoDB データベース API は AWS でのみ機能し、Azure では機能しません。これは、DynamoDB が AWS のみに属しているためです。 DynamoDB は AWS の本番環境でのみ使用できるため、API はローカル環境では機能しません。

もう 1 つの理由は、クラウド ネイティブ アプリケーションを構築するときに、必要なときにほぼ無制限の数のサーバー ノードを使用できることや、新しいサーバー ノードを非常に迅速に使用できることなど、いくつかの前提が立てられるためです。実際のサーバー、ネットワーク ハードウェア、ケーブルを購入する必要があるオンプレミスのデータ センター環境では、これらの前提を保証することが難しい場合があります。