SpeedData

マイクロサービスとサーバレス

マイクロサービスとサーバレス・アーキテクチャの利点と妥協点を探る

2023年8月18日
翻訳: 島田 麻里子

この記事は米Catchpoint Systems社のブログ記事「Exploring the Benefits and Trade-Offs of Microservices and Serverless Architectures 」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。


サーバレス・コンピューティングは、実際どの程度需要があるのでしょうか?
2014年にAmazonが普及させたサーバレス・コンピューティングは、2018年の時点ですでに最も成長率の高いパブリッククラウドサービスの座を獲得していました。
市場総額は2022年に90億米ドルを突破し、2032年には900億米ドルに達すると予測されており、この比較的新しい分野はかなり順調に成長していると言えるでしょう。

この包括的な4部構成のブログシリーズでは、異なるモデルをバランスよく見て、その長所と短所を比較検証し、サーバレス・アーキテクチャの魅力が高まっている背景にある説得力のある理由(あるいは、サーバレス・アーキテクチャを使うべきでない場合)を掘り下げていきます。
Amazonプライム・ビデオの実際のケーススタディに深く踏み込み、私たち自身の経験も活用します。
保守性、スケーラビリティ、パフォーマンス、市場投入までの時間、コストといった大きな問題を念頭に置きながら、特定の選択がなされた理由を具体例を用いて説明します。

サーバレス・アーキテクチャの複雑さと奥深さ、そしてその選択肢をナビゲートしますので、シートベルトをお締めください。

マイクロサービス:複雑なアプリケーションを分解し、拡張性と柔軟性を高める

サーバレスに飛び込む前に、その前身、つまりサーバレスを可能にした技術であるマイクロサービスについて触れておきましょう。
アプリケーションをより小さく、相互接続されたサービスに分割することで、マイクロサービスは開発者や企業にとって魅力的な選択肢となる様々な利点を提供できるようになりました。
以下は、マイクロサービス・アーキテクチャへの移行を推進する最も重要な原動力の一覧です。

スケーラビリティ(拡張性)

マイクロサービスでは、アプリケーションの個々のコンポーネントを独立して拡張することが容易になり、リソースの割り当てが改善され、ワークロードの増加への対応が向上しました。

フレキシビリティ(柔軟性)

マイクロサービス・アーキテクチャは、各サービスが異なるテクノロジー、フレームワーク、またはプログラミング言語を使用して開発および展開できるため、テクノロジーの選択においてより高い柔軟性を提供します。

ファースター・デプロイメント(開発サイクルの高速化)

マイクロサービス内の小さく独立したコンポーネントは、開発、テスト、展開が迅速に行えるため、開発サイクルが短縮され、新機能の実装が容易になります。

レジリエンス(回復力)

マイクロサービス・アーキテクチャでは、1つのサービスに障害が発生しても、完全なシステム破壊に繋がる可能性は低いです。
モノリシックなシステムでは、1つの障害が壊滅的な影響を及ぼす可能性があるのとは対照的です。

サーバレス: インフラレス・コンピューティングの導入によるコスト効率と敏捷性の向上

マイクロサービスとサーバレス・アーキテクチャは、スケーラビリティ、フレキシビリティ、ファースター・デプロイメントなど、いくつかの共通の目的を共有する相互補完的なアプローチです。
マイクロサービスはアプリケーションをより小さく独立したコンポーネントに分割することに重点を置き、サーバレスはインフラ管理を排除し、開発者がサーバを構築したり保守したりすることなくオンデマンドでコードを実行できるようにすることで、このアイデアをさらに発展させるのです。
このテクノロジーは、これら2つのパラダイムを組み合わせることで、開発者が業務プロセスを合理化しながら、拡張性の高い効率的なアプリケーションを構築することを可能にします。

サーバとインフラ管理の複雑さを一掃することで、サーバレス・テクノロジーは最新のアプリケーション開発に魅力的な選択肢となる多くのメリットを生み出しています。
ここでは、多くの組織が従来のサーバレス以外の選択肢ではなく、サーバレスアーキテクチャを選択している主な理由を紹介します。

費用対効果

サーバレス・アーキテクチャは通常、従量課金モデルを採用しており、リソースを事前に割り当てるのではなく、使用したコンピューティングリソースに対してのみ料金を支払うため、結果的にコストを削減することができます。

スケーラビリティ(拡張性)

サーバレス・プラットフォームは自動的にスケーリングを管理するため、アプリケーションは手動による介入や複雑なインフラ管理なしに、様々なワークロードやトラフィックを簡単に処理することができます。

運用経費の削減

サーバレス・アーキテクチャでは、開発者はサーバを管理したり保守したりする必要がないため、コードを書いたり新機能を提供したりすることに集中できます。

より迅速な市場投入

サーバレス・アーキテクチャは、インフラ管理を取り除くことで、開発者がアプリケーションを迅速に展開して開発サイクルを短縮し、製品リリースを早めることを可能にします。

イベント駆動型アーキテクチャ

サーバレス・プラットフォームは、多くの場合、イベント駆動型アーキテクチャをサポートし、APIコールやデータの変更などのイベントやトリガーに、アプリケーションが応答することを可能にするため、開発者自身がこれらのアーキテクチャを構築することなく、より柔軟で応答性の高いシステムを実現することができます。

適切なバランスを見つける ― プライム・ビデオのケーススタディ

サーバレス界隈は、最近の Amazonのプライム・ビデオのブログ記事で盛り上がっています。
この記事では、ストリーミング配信の大手企業が、オーディオ/ビデオ監視サービスにおいて、スケーリングとコストという大きな問題にどのように取り組んだかが記されています。
分散サーバレス・コンポーネントで構築された初期のアーキテクチャは、コストのかかる運用と、かなりのスケーリング・ボトルネックに繋がり、増加するストリームを効率的に監視するシステムの能力を妨げていました。

主なコスト要因は、オーケストレーションのワークフローとコンポーネント間のデータ転送でした。
特筆すべきは、ストリームの毎秒のステータス遷移の数が多いため、すぐにアカウントの容量制限に繋がってしまったことです。
さらに、異なるコンポーネント間でビデオフレームをAmazon S3バケットを介して送信することが、高額なTier1プロバイダコールを引き起こしました。

プライム・ビデオは、これらの課題を克服するためにサービスを再構築し、分散型からモノリシック・システムに移行したようです。
これにより、すべてのコンポーネントを単一のプロセスに統合し、ビデオフレームの保存に中間のS3バケットが不要になり、オーケストレーションロジックの複雑さが軽減されました。
データ転送はプロセス・メモリ内で容易に行われ、単一インスタンス内のコンポーネントを制御するオーケストレーションが実装されました。

モノリシック・アーキテクチャへの移行は、インフラコストを90%以上削減し、サービスのスケーリング能力を大幅に向上させました。

プライム・ビデオによるモノリシック・アーキテクチャへの思いがけない移行と、その結果もたらされた機能強化と大幅なコスト削減は、DevOpsやシステム・アーキテクチャのコミュニティで活発な議論を巻き起こしています。
マイクロサービスとサーバレス・アーキテクチャの世界的パイオニアであるAmazonが、自社製品の一部で伝統的なモノリス構造の復活を暗示しているのでしょうか?

モノリスは悪いものでしょう?

しかし、Prime Videoのケースをよく読むと、見かけ以上のことが起こっていることがわかります。
次回のブログでは、プライム・ビデオの事例をさらに詳しく掘り下げ、Amazonのアーキテクチャ上の決断の複雑さを分析します。