サーバーレスアーキテクチャ: クラウドコンピューティングの進化

Cloudscape でサーバーレス アーキテクチャが勢いを増す中、MongoDB に基づくサーバーレス アーキテクチャとそれが時代の変化にどのように適合するかについて、いくつかの考察を述べます。

導入

コンピュータの登場以来、ソフトウェアの構築は複雑なプロセスでした。過去 10 年間で、アプリケーション開発の複雑さを軽減するために、インフラストラクチャ (IaaS と PaaS)、ソフトウェア アーキテクチャ (SOA とマイクロサービス)、および方法論 (アジャイル、継続的デリバリー、DevOps) に対する新しいアプローチが登場しました。マイクロサービスはここ数年ホットなトレンドとなっていますが、スケーラブルでコスト効率の高いアプリケーションを構築するための新しいアプローチを提供することで、サーバーレス アーキテクチャが勢いを増しています。サーバーレス コンピューティングは、サーバーとストレージのプロビジョニング、インフラストラクチャの維持、ソフトウェアのアップグレードを自動的に行い、消費したリソースに対してのみ課金することで、開発者をアプリケーション構築の従来のコストから解放します。

サーバーレス コンピューティングとは何ですか?

サーバーレス コンピューティングは、クラウド コンピューティングにおける抽象化のレベルが低いものです。これはサーバーが存在しないという意味ではありませんが、基盤となるインフラストラクチャ (物理ホストと仮想ホスト、VM、コンテナー) とオペレーティング システムは開発者の想像の範囲外になります。アプリケーションは、イベントによってトリガーされるステートレス コンピューティング コンテナーで実行されます (たとえば、ユーザーがアップロードした写真によってフォロワーへの通知がトリガーされます)。開発者はアプリケーションを作成し、インフラストラクチャを利用してアプリケーションを実行するための適切なリソースを割り当てます。アプリケーションの負荷が増大すると、インフラストラクチャはアプリケーションのコピーを作成し、需要に合わせて拡張します。

サーバーレス コンピューティングは複数の言語をサポートしているため、開発者は最も好みのツールを選択できます。ユーザーには、アプリケーションによって消費される実行時間とリソース (RAM など) に対してのみ課金されます。したがって、プロビジョニング不足またはプロビジョニング過剰という概念はなくなりました。

たとえば、アプリケーションの実行に 500 ミリ秒かかり、15 MB の RAM を消費する場合、ユーザーには 500 ミリ秒の実行時間と 15 MB の RAM の使用料金のみが課金されます。

サーバーレス アーキテクチャは、マイクロサービスの自然な拡張です。マイクロサービスと同様に、サーバーレス アーキテクチャ アプリケーションは特定のコア コンポーネントに分割されます。マイクロサービスは類似した機能を 1 つのサービスにグループ化できますが、サーバーレス アプリケーションは機能をより細かいコンポーネントに分割します。カスタム コードは、ステートレス コンピューティング サービスで実行される独立した自律的なきめ細かいアプリケーションとして開発および実行されます。

これを説明するために、マイクロサービスとサーバーレス アーキテクチャの違いを示す簡単な例を見てみましょう。

図 1 では、クライアントは「User」マイクロサービスと対話します。コンテナには、コンテナ内の「ユーザー」サービスのすべての機能が事前に構成されています。このサービスは、さまざまなアプリケーション (update_user、get_user、create_user、delete_user) で構成されており、サービス全体の負荷に基づいて拡張されます。サービスはアイドル時にハードウェア リソースを消費し、ユーザーは十分に活用されていないリソースに対しても料金を支払うことになります。

写真

サーバーレス アーキテクチャでは、「ユーザー」サービスはより細かい機能に分割されます。図 2 では、各 API インターフェースは特定のアプリケーションとファイルに対応しています。クライアントが「ユーザーの作成」要求を行う場合、「ユーザー」サービスのコードベース全体を実行する必要はありません。代わりに、create_user.js のみが実行されます。独立した関数は必要なときにのみリソースを消費し、ユーザーは関数が実際に実行された時間に対してのみ料金を支払うため、コンテナを事前にプロビジョニングする必要はありません。この粒度により、機能を個別にテストおよび展開できるため、並行開発作業も容易になります。

写真

サーバーレスコンピューティングのメリット

使用量に応じてコストが増加します:

サーバーレス コンピューティングの最大の利点の 1 つは、アプリケーションの実行時間に対してのみ料金を支払うことです。機能が実行されていない場合は課金されないため、「アイドル」リソースの概念はありません。これは、1 時間に数回しか使用されないアプリケーションの場合に特に便利です。つまり、専用のハードウェア、VM、またはコンテナーはほとんどの時間アイドル状態になっており、ユーザーは十分に活用されていないリソースに対して料金を支払っていることになります。サーバーレス コンピューティングを使用すると、企業はインフラストラクチャ全体を構築でき、顧客がアプリケーションを使い始めるまでコンピューティング リソースの料金を支払う必要がありません。

弾力的なスケーラビリティ:

サーバーレス アーキテクチャの弾力的なスケーラビリティもシンプルです。アプリケーションを拡張する必要がある場合、インフラストラクチャは負荷を処理するためにアプリケーションのコピーを作成します。一例としては、天気予報のリクエストに応答するチャットボットが挙げられます。サーバーレス アーキテクチャでは、チャットボット機能はユーザーの位置を取得し、温度を応答することで応答を処理します。少数のリクエストであれば問題にはなりませんが、チャットボット サービスに毎秒数千のリクエストが殺到するとどうなるでしょうか。このシナリオでは、チャットボット機能は、関数のコピーを何千もインスタンス化することで自動的に拡張されます。リクエストが減少すると、環境はアイドル状態のインスタンスを終了してスケールダウンし、ユーザーの需要に応じてコストを調整できるようになります。

迅速な開発と反復:

サーバーレス コンピューティングは、迅速な開発、プロトタイプ作成、反復を必要とする企業に最適です。 IT 運用に依存しないため、開発が高速化されます。アプリケーションはシングルスレッドなので、アプリケーションのデバッグとデプロイが容易になります。構築プロセスも、より小さく、管理しやすい部分に分割されます。これにより、継続的デリバリー パイプラインを通じてプッシュできる変更の数が増え、迅速な展開とより反復的なフィードバックが可能になります。アーキテクチャにより大規模なコード変更を迅速に行うことができるため、反復処理が高速になり、結果として顧客からのフィードバックが増加し、製品と市場の適合性が向上します。

システム管理の軽減:

サーバーレスとは​​、インフラストラクチャの運用要素を完全に排除することを意味するのではなく、システム管理が少なくなることを意味します。管理、構成、拡張するサーバーはありません。パッチやアップグレードを行う必要はありません。高可用性を実現するために、サーバーは複数の可用性ゾーンに自動的にデプロイされます。サポートも簡素化されました。夜中に問題が発生した場合、クラウド プロバイダーが問題解決の責任を負います。

開発者の生産性:

サーバーレス アーキテクチャを使用することで、開発者はアプリケーションの管理に関する運用タスクを気にすることなく、コードの作成に集中できるようになります。これにより、革新的な機能を開発し、ビジネスにとって最も重要なコアビジネスロジックに集中できるようになります。

MongoDB Atlas とサーバーレス コンピューティング

MongoDB Atlas を使用すると、ユーザーはサーバーレス環境から、表現力豊かなクエリ言語、柔軟なスキーマ、常時可用性、分散型水平スケーラビリティなど、MongoDB の豊富な機能を活用できます。

MongoDB Atlas は、運用タスクの設定という面倒な作業なしにデータベースのすべての機能を提供するサービスとしてのデータベースです。開発者は、プロビジョニング、構成、パッチ適用、アップグレード、バックアップ、障害回復について心配する必要がなくなります。 Atlas は、さまざまなインスタンス サイズにわたってスケールアウトするか、自動シャーディングによって、アプリケーションのダウンタイムをゼロに抑えながら、柔軟なスケーラビリティを提供します。

Atlas のセットアップは簡単です。

写真

アプリケーションのニーズに合ったインスタンス サイズを選択し、「確認とデプロイ」をクリックします。インスタンスのサイズに応じて、MongoDB クラスターを数秒でプロビジョニングできます。

写真

MongoDB Atlas は、サーバーレス アーキテクチャの構築に関心のあるユーザーに多くのメリットを提供します。

サプライヤーの独立性:

クラウドベンダーは、そのベンダー固有のデータベースのみを提供することが多いため、開発者のニーズに合わない可能性があります。 MongoDB Atlas は基盤となるクラウド プロバイダーからの独立性を提供し、開発者がニーズに合った適切なツールを選択できるようにします。開発者は、データベース管理の運用タスクを気にすることなく、MongoDB のクエリ言語の豊富な機能と柔軟なデータ モデルを活用できます。別のクラウド プロバイダーに移行する場合、別のデータベース テクノロジを使用してデータを再入力する必要はありません。 MongoDB Atlas は現在 AWS でのみ利用可能で、Microsoft Azure と Google Cloud Platform (GCP) のサポートも近日中に開始される予定です。

MEANスタック:

サーバーレス アーキテクチャは、ビジネス ロジックをバックエンドからフロントエンドに移動する傾向を加速します。これにより、フロントエンド フレームワークの選択がさらに重要になります。 AngularJS はこの要件に最適であり、サーバーレス アーキテクチャの人気のあるフロントエンドです。 AngularJS は、インタラクティブな機能と AJAX (高速で動的な Web ページを作成するためのテクノロジ) が豊富なコンポーネントを提供する、動的な Web アプリケーション用の構造化された JavaScript フレームワークです。これらのツールは、NodeJS、ExpressJS、MongoDB と組み合わせて、MEAN スタック (MongoDB、ExpressJS、AngularJS、NodeJS) を形成します。サーバーレス スタック全体で JavaScript と JSON を使用すると、大きな利点があります。フロントエンドで作業する人は、アプリケーション (バックエンド) コードとデータベース クエリを簡単に理解できます。さらに、スタック全体で同じ構文とオブジェクトを使用すると、チームは複数の言語でのベストプラクティスを理解する必要がなくなり、コードベースを理解する障壁が低くなり、ソフトウェアのパフォーマンスと開発者の生産性が向上します。

迅速な展開:

MongoDB Atlas を使用すると、数分または数秒で MongoDB クラスターをプロビジョニングおよびデプロイできます。開発者はサーバーの構成や管理について心配する必要がなくなりました。 MongoDB Atlas をサーバーレス プラットフォームに統合するには、サーバーレス アプリケーションに接続文字列を渡す必要があります。

写真

MongoDB Atlas には、MongoDB へのアクセスを防止、検出、制御する広範な機能があり、最新のデータベースの中で最も完全なセキュリティ制御を提供します。

ユーザー権限管理: 業界標準のメカニズムを使用してデータベース レベルで認証と承認を行い、機密データへのアクセスを制御します。

暗号化: ネットワーク上で移動中のデータと永続ストレージに保存されているデータを保護します

すぐに使用できる安全なシステムを確保するために、認証と IP アドレスのホワイトリストが自動的に有効になっています。

IP アドレスのホワイトリストは、第三者がデータにアクセスするのを防ぐための追加レイヤーを追加する MongoDB Atlas の重要なセキュリティ機能です。クライアントの IP アドレスが MongoDB Atlas グループの IP ホワイトリストに追加されていない限り、クライアントはデータベースにアクセスできません。

AWS では、MongoDB Atlas の VPC ピアリングが開発中であり、まもなく利用可能になり、シンプルで強力なソリューションを提供します。これにより、アプリケーション サーバーが含まれる VPC 内の AWS セキュリティ グループ全体をホワイトリストに登録できるようになります。

スケーラビリティ:

サーバーレス関数はスケールアウトすることが予想されるため、ダウンストリームのセットアップは関数とスケールに対応できるように設計する必要があります。リレーショナル データベースは、このモデルでは機能しなくなる傾向があります。 MongoDB Atlas は、拡張性を中核原則として設計されています。クラスターが特定のしきい値に達すると、MongoDB Atlas から警告が発せられ、ワンクリックで新しいサーバーをプロビジョニングできます。

柔軟なアーキテクチャ:

サーバーレス アーキテクチャはイベント駆動型であるため、多くのユースケースはモノのインターネット (IoT) とモバイル デバイスを中心に展開されます。 MongoDB は、柔軟なドキュメント モデルにより、イベント、地理空間、時系列、テキスト、バイナリなど、あらゆる種類のデータを保存および処理できるため、これらのユース ケースなどに最適です。ドキュメント構造に新しいフィールドを追加するのは簡単なので、イベント駆動型アプリケーションによって生成されるデータの変更を簡単に処理できます。開発者はスキーマの変更に費やす時間を減らし、革新に費やす時間を増やすことができます。

元のリンク:

https://dzone.com/articles/serverless-architectures-the-evolution-of-cloud-c