企業がアプリケーションを構築する必要がある場合、リーダーが下す最も重要な決定の1つは、どのような種類のソフトウェア開発を使用するかということです。選択できるソフトウェア・アーキテクチャーは多数ありますが、拡張性、柔軟性、性能の高さから、サーバーレスおよびマイクロサービスのアーキテクチャーの人気が高まっています。また、クラウド・サービスへの支出は今後4年間で2倍になると予想されており、サーバーレス・インスタンスとマイクロサービス・インスタンスはクラウド・コンピューティング環境で広く使用されているため、どちらも急速に成長するはずです。
サーバーレス・アーキテクチャーは一般に、スタートアップや、すばやく構築して迅速に拡張する必要がある企業に好まれていますが、バックエンド・インフラストラクチャーの実践的な管理が必要な組織ではマイクロサービスがより人気があります。サーバーレスおよびマイクロサービス・ソリューションは、Microsoft(Azure)、Amazon(AWS Lambda)、IBM、Google Cloudなど、すべての主要なクラウド・コンピューティング・テクノロジー企業によって提供されています。
ここでは、サーバーレスとマイクロサービスの独自性の理由と、自分にとって最適なモデルの選択方法について詳しく説明します。
サーバーレスは、サーバーレス・アーキテクチャーまたはサーバーレス・コンピューティングとも呼ばれ、基盤となるインフラストラクチャーの管理を気にすることなく、開発者がアプリケーション・コードを構築および実行できるようにするソフトウェア開発のアプローチです。
サーバーレス環境では、オペレーティング・システム(OS)やソフトウェア・アップデートのインストール、セキュリティーや監視などの定期的な保守タスクは、クラウド・サービス・プロバイダー(CSP)にアウトソーシングされます。
サーバーレス・フレームワークとは、その名前に反し、サーバーのないコンピューティングを意味するものではありません。ただし、サーバーレス・プラットフォームでは、開発者ではなくCSPがサーバーのプロビジョニングを処理するため、開発者はコードとビジネス・ロジックに集中できます。サーバーレス・アプリケーションのもう1つの利点は、クラウド・プロバイダーがより柔軟でコスト効率の高いオンデマンド・モデルでリソースをプロビジョニングできることです。サーバーレスの場合、コードの実行が開始されると課金が開始され、実行が終了するときに終了します。Infrastructure as a service(IaaS)やFunction as a service(FaaS)とともに、サーバーレスは主要なクラウド・サービスになっています。
マイクロサービス(マイクロサービス・アーキテクチャーとも呼ばれる)は、アプリケーション全体が独立した多数の相互接続された小さな部分から構成されるクラウド・コンピューティング・アーキテクチャー・アプローチです。マイクロサービス・アプリケーションには、多くの場合、データベースとデータベース管理モデルを含む独自のスタックがあります。
マイクロサービスは、表現状態転送(REST API)、イベント・ストリーミング、およびメッセージ・ブローカーの組み合わせを使用して通信します。通常、マイクロサービスはビジネス機能(検索エンジンやオンライン注文処理向けのマイクロサービスなど)によって分類され、境界コンテキストと呼ばれる行分離サービスが使用されます。
サーバーレスと同様、マイクロサービスの資産はクラウド・インフラストラクチャーの資産と密接に結びついています。クラウド・インフラストラクチャーのユースケースが世界中で急増しており、マイクロサービスへの支出は今後4年間で60億米ドルに達すると予想されています。
マイクロサービスはアーキテクチャーの定義のコンテキストでよく語られますが、最も一般的な企業上のメリットの観点から見ると、そのビジネス価値を理解しやすくなります。
サーバーレス・アーキテクチャーとマイクロサービス・アーキテクチャーは、複雑なアプリケーションの柔軟性と拡張性を強化するという共通の目標を共有します。この2つには多くの類似点がありますが、次のような重要な違いがいくつかあります。
サーバーレスとマイクロサービスはどちらも「非常にスケーラブル」だと考えられており、高レベルの性能を達成しながら、ユーザーを増やすソフトウェア・ソリューションを実現します。
その違いは、2つのアーキテクチャーが組織に提供する制御のレベルと自動化のレベルにあります。サーバーレス・テクノロジーでは、トリガー・イベントに基づいて個々の機能を自動的に拡張できるようにし、マイクロサービスでは、各サービスをオンデマンドで個別に拡張できます。マイクロサービス・アプローチでは、より多くの手動設定が必要ですが、開発者はより細かく制御できるようになります。
繰り返しになりますが、開発に関しては、サーバーレスとマイクロサービスの実装の違いは、組織が必要とする制御レベルに帰着します。
マイクロサービスでは、Dockerによって作成されたコンテナや、Kubernetesなどのコンテナ・オーケストレーション プラットフォームを使用して、各サービスと機能を個別に構築、テスト、およびデプロイする必要があります。このアプローチではサーバーレスよりもカスタマイズ性が高いですが、開発者による調整、時間、監視も多く必要になります。
一方、サーバーレスは、高い俊敏性と複雑さの軽減を実現しながら、迅速な開発およびデプロイメント・サイクルを実現するように構築されています。サーバーレス・アーキテクチャーでは、OSのインストールや構成、サーバー管理、ソフトウェアの更新など、基盤となるインフラストラクチャーの管理はCSPにアウトソーシングされます。これにより、アプリケーション機能を自動的にパッケージ化、デプロイ、拡張できるようになります。
サーバーレス・アーキテクチャーでは、インフラストラクチャーのすべてのプロビジョニング、管理、スケーリングはサードパーティー(通常はCSP)によって管理されるため、開発者はビジネス・ロジックとコードの作成とデプロイのみに集中できます。
また、サーバーレス・モデルでは、コードがユーザーの近くで実行されるため、レイテンシーが短縮され、速度と性能が向上します。ただし、開発者はサーバーレス・モデルでのコードの作成に集中できますが、サーバーのOSやプロビジョニングなど、基盤となるインフラストラクチャーについてはほとんど、あるいはまったく制御できません。
マイクロサービス・アーキテクチャーでは、開発者はデプロイ予定の各マイクロサービスをサポートするスタックを管理する必要があります。これには、適用可能なインフラストラクチャー、開発プロセス、ネットワーク構成が含まれます。マイクロサービスでは開発環境をより細かく制御できる一方で、アプリケーション開発を可能にする方法論であるDevOpsに関しては、開発者に高いレベルの専門知識も求められます。
粒度とは、システムがどの程度小さな部分に分解されるかを指します。サーバーレスとマイクロサービスはどちらも、その前身であるモノリシック・アーキテクチャよりも粒度が細かいと考えられています。
モノリシック・アーキテクチャーでは、ユーザー・インターフェースやロジック、データベース操作など、サーバーレスやマイクロサービスとは異なるアプリケーションのすべての機能が統合されています。モノリシック・アーキテクチャーのシンプルさは、焦点を絞ってシンプルなアプリケーションを開発する必要がある一部の企業にとってこれまでも、そして今でも魅力的です。
マイクロサービス・ベースのアーキテクチャーは、モノリシック・アーキテクチャーよりも細分化されていますが、サーバーレスほどは細分化されていません。マイクロサービス・アーキテクチャーは、モノリシック・アプリケーションを、個別にデプロイできる、より小規模で独立したサービスに分解します。サーバーレス・アーキテクチャーはさらに細分化されています。サーバーレス・モデルでは、各アプリケーションをサービスよりもさらに小さい個々の機能に分解します。サーバーレス・アーキテクチャーでは、各機能はビジネス・ロジックの断片を表し、特定のイベントによってトリガーされた場合にのみ実行されます。
サーバーレス環境では、コードの開発とデプロイに必要な重要なインフラストラクチャーの管理は、ランタイム(アプリケーションまたはサービスが実行されるようにプログラムされている環境)を含むCSPにアウトソーシングされます。つまり、機能の実行中に保管されているデータは、機能が完了した瞬間に失われます。
一方、マイクロサービス・アーキテクチャーは、専用の仮想マシン(VM)上で実行され、その状態を保管できます。
マイクロサービス・アーキテクチャーは、課金モデルのため、多くの場合サーバーレスよりもコスト効率が低くなります。サーバーレス機能は、コードのデプロイメントをトリガーするイベントの数に応じて課金されますが、マイクロサービスでは、インフラストラクチャーやその他のリソースのプロビジョニングに基づいて費用を前払いする必要があります。
マイクロサービス・アーキテクチャーでは、組織は使用するかどうかに関係なくリソースに対して課金されますが、サーバーレス・アーキテクチャーでは使用量に応じてのみ課金されます。
組織のニーズに応じて、サーバーレス・アーキテクチャーとマイクロサービス・アーキテクチャーの最も優れた部分を「サーバーレス・マイクロサービス」と呼ばれるモデルに組み合わせることができます。
サーバーレス・マイクロサービスは、マイクロサービスがサーバーレス機能として構築されたハイブリッド・アーキテクチャー・フレームワークです。サーバーレス機能は拡張性が高いためマイクロサービスに適しており、マネージド・サービスと簡単に組み合わせることで、マイクロサービスのオペレーション・コストを削減できる場合があります。
このアプローチにより、開発者はサーバーレス環境にありがちな、より特殊な機能の構築に集中できます(ただしインフラストラクチャーの管理に頭を悩ませる必要はなし)。サーバーレス・アーキテクチャーとマイクロサービス・アーキテクチャーを組み合わせることで、拡張性、コスト効率、柔軟性など、アーキテクチャーを個別に使用する場合と同じメリットが多く得られます。ただし、考慮に値する課題もいくつかあります。
クラウド・コンピューティングの使用が拡大し続け、企業がテクノロジーを活用して新たなビジネス価値を生み出す新しい方法を模索する中、サーバーレスとマイクロサービスの両方のユースケースが拡大しています。
ハイブリッドクラウドは、パブリッククラウド、プライベートクラウド、オンプレミスのインフラストラクチャーを組み合わせて、単一の柔軟でコストが最適ITインフラストラクチャーを作成します。サーバーレスは、テクノロジーに必要な俊敏性、柔軟性、拡張性を提供することで、ハイブリッドクラウド戦略を採用している企業をサポートします。
サーバーレスは、データ・アプリケーションのコードの作成とデプロイのコストと複雑さを大幅に軽減します。サーバーレス環境では、開発者はインフラストラクチャー管理のすべての日常的なタスクではなく、コードとビジネス・ロジックに集中できます。
マイクロサービスはクラウド・コンピューティング環境では必要ありませんが、そのアーキテクチャーによって分散型アプリケーション・コンポーネントとなるため、クラウド・コンピューティング環境に非常に適しています。マイクロサービス・アーキテクチャーは、サービスと機能を独立して動作させ、アプリケーションをサポートするためにデプロイされます。さらに、マイクロサービスは拡張性が高いため、サーバー上で複数のインスタンスを実行できます。これは、クラウド・コンピューティング環境にとってもう1つの大きなメリットです。
自動運転車やストリーミング・ビデオをサポートするアプリケーションなど、ほぼリアルタイムでデータを処理する必要があるアプリケーションは、特にマイクロサービスに適しています。マイクロサービスを使用すると、操作をリアルタイムで実行できるため、すぐに出力を提供でき、次のようなタイプのアプリケーションが機能できるようになります。
企業がIT機能を再設計することを決定するリファクタリングは、マイクロサービス・アーキテクチャーでよく使われるユースケースです。多くの場合、IT部門は、モノリシック・モデルを、マイクロサービスが実現する柔軟性と効率性の高いモデルに向けてリファクタリングしようとしています。
アプリケーションに適したアーキテクチャーを選択することは、ビジネスが行うことができる最も重要な決定の1つです。ここでは、サーバーレス・アーキテクチャーとマイクロサービス・アーキテクチャーのどちらが適しているかを判断するための質問をいくつか示します。
これらは、検討したい質問のサンプルにすぎませんが、意思決定を行うためのフレームワークを作成するのに役立ちます。
一般的に、迅速に移行して反復することを目指す企業はサーバーレス・アーキテクチャーを選択することが多いですが、より複雑で要求の厳しいアプリケーションを扱う企業や、開発サイクルの長期化を気にしない企業はマイクロサービスを選択します。しかし、これらは大まかな一般化であり、決定を下す前に両方のテクノロジーの長所と短所を考慮する必要があります。
サーバーレス・コンピューティングは、クラウドでアプリケーションを構築および運用するための、よりシンプルでコスト効率の高い方法を提供します。Kubernetesの知識を必要とせずにサーバーレス・アプリケーションやワークフローを管理者がデプロイできる従量課金制のサーバーレス・プラットフォーム、IBM Cloud Code Engineの詳細についてご説明します。