サーバーレス アプリケーションを構築するためのヒントとリソース

サーバーレス テクノロジーは近年急速に人気が高まっていますが、サーバーレス テクノロジーに関連する誤解や不安は依然として多くあります。 サーバーレス テクノロジに関しては、ベンダーの依存関係、ツール、コスト管理、コールド スタート、モニタリング、開発ライフサイクルはすべて注目のトピックです。 この記事では、言及されたトピックのいくつかを検討するとともに、初心者が強力で柔軟性があり、コスト効率の高いサーバーレス アプリケーションを作成するのに役立つヒントと役立つ情報源へのリンクを共有します。

サーバーレステクノロジーに関する誤解

多くの人はサーバーレスとサーバーレス処理 (サービスとして機能、FaaS）はほぼ同じものです。 これは、違いがそれほど大きくなく、目新しさを導入する価値があることを意味します。 AWS Lambda はサーバーレス全盛期のスターの XNUMX つであり、サーバーレス アーキテクチャの最も人気のある要素の XNUMX つでしたが、このアーキテクチャは FaaS をはるかに超えています。

サーバーレス テクノロジーの背後にある基本原則は、インフラストラクチャの管理と拡張について心配する必要がなく、使用した分だけ料金を支払うということです。 AWS DynamoDB、S3、SNS または SQS、Graphcool、Auth0、Now、Netlify、Firebase など、多くのサービスがこれらの基準に適合します。 一般に、サーバーレスとは​​、インフラストラクチャを管理したり、スケーリングのためにインフラストラクチャを最適化したりする必要がなく、クラウド コンピューティングの能力を最大限に活用することを意味します。 また、インフラストラクチャ レベルのセキュリティがもはや心配ではないことも意味します。これは、セキュリティ標準を満たすことの難しさと複雑さを考えると、大きな利点です。 最後に、提供されるインフラストラクチャを購入する必要はありません。

サーバーレスは「心の状態」、つまりソリューションを設計するときの特定の考え方と考えることができます。 インフラストラクチャのメンテナンスを必要とするアプローチは避けてください。 サーバーレス アプローチでは、プロジェクトに直接影響を与え、ユーザーに利益をもたらすタスクの解決に時間を費やします。つまり、持続可能なビジネス ロジックを作成し、ユーザー インターフェイスを開発し、適応性と信頼性の高い API を開発します。

たとえば、フリーテキスト検索プラットフォームの管理と保守を回避できる場合は、そうするつもりです。 アプリケーションを構築するこのアプローチにより、複雑なインフラストラクチャの管理について考える必要がなくなるため、市場投入までの時間を大幅に短縮できます。 インフラストラクチャ管理の責任とコストを排除し、顧客が必要とするアプリケーションとサービスの構築に集中します。 パトリック・ドゥボワ氏はこのアプローチを次のように呼んでいます。 「サービスフル」、この用語はサーバーレスコミュニティで採用されています。 関数は、(ライブラリ全体または Web アプリケーション全体をデプロイするのではなく) デプロイ可能なモジュールとしてのサービスへのリンクとして考える必要があります。 これにより、アプリケーションの展開と変更を非常に詳細に管理できるようになります。 この方法で関数をデプロイできない場合は、関数が実行するタスクが多すぎるため、リファクタリングが必要であることを示している可能性があります。

クラウド アプリケーションを開発する際に、ベンダーに依存することに混乱する人もいます。 サーバーレス テクノロジにも同じことが当てはまりますが、これは決して誤解ではありません。 私たちの経験では、AWS 上でサーバーレス アプリケーションを構築し、他の AWS サービスをバンドルする AWS Lambda の機能を組み合わせることが、サーバーレス アーキテクチャの強みの一部です。 これは、組み合わせの結果が単なる項の合計以上のものとなる、相乗効果の良い例です。 ベンダーへの依存を避けようとすると、さらに多くの問題が発生する可能性があります。 コンテナーを使用する場合、クラウド プロバイダー間で独自の抽象化レイヤーを管理する方が簡単です。 しかし、サーバーレス ソリューションに関しては、特に最初から費用対効果が考慮されている場合、その努力は報われません。 ベンダーがどのようにサービスを提供しているかを必ず調べてください。 一部の専門サービスは他のベンダーとの統合ポイントに依存しており、すぐに使用できるプラグアンドプレイ接続を提供する場合があります。 リクエストをコンテナまたは EC2 インスタンスにプロキシするよりも、ゲートウェイ API エンドポイントから Lambda 呼び出しを提供する方が簡単です。 Graphcool では、サードパーティの認証ツールを使用するよりも簡単な Auth0 による簡単な構成が提供されます。

サーバーレス アプリケーションに適切なベンダーを選択することは、アーキテクチャ上の決定です。 アプリケーションを作成したとき、いつかサーバーの管理に戻ることは期待できません。 クラウド ベンダーの選択は、コンテナーやデータベース、あるいはプログラミング言語の使用を選択することと何ら変わりません。

検討：

• どのようなサービスが必要か、そしてその理由。
• クラウド プロバイダーが提供するサービスと、それらを選択した FaaS ソリューションとどのように組み合わせることができるか。
• どのようなプログラミング言語がサポートされているか (動的または静的型付け、コンパイルまたはインタープリタ、ベンチマークは何か、コールド スタート時のパフォーマンスは何か、オープンソース エコシステムは何かなど)。
• セキュリティ要件は何ですか (SLA、2FA、OAuth、HTTPS、SSL など)。
• CI/CD およびソフトウェア開発サイクルを管理する方法。
• どのインフラストラクチャ・アズ・コード・ソリューションを活用できますか。

既存のアプリケーションを拡張し、サーバーレス機能を段階的に追加すると、使用可能な機能が多少制限される可能性があります。 ただし、ほとんどすべてのサーバーレス テクノロジは、アプリケーション コアから独立して簡単に統合して拡張機能を作成できる、ある種の API (REST またはメッセージ キュー経由) を提供します。 明確な API、優れたドキュメント、強力なコミュニティを備えたサービスを探してください。間違いはありません。 統合の容易さは重要な指標となることが多く、おそらくこれが 2015 年に Lambda がリリースされて以来 AWS が成功を収めてきた主な理由の XNUMX つです。

サーバーレスが良い場合

サーバーレス テクノロジーは、ほぼどこにでも適用できます。 ただし、その利点は XNUMX つの適用方法だけに限定されるわけではありません。 サーバーレス テクノロジーのおかげで、今日のクラウド コンピューティングへの参入障壁は非常に低くなりました。 開発者がアイデアを持っていても、クラウド インフラストラクチャを管理してコストを最適化する方法がわからない場合は、それを実行してくれるエンジニアを探す必要はありません。 スタートアップがプラットフォームを構築したいが、コストが制御不能になるのではないかと懸念している場合、サーバーレス ソリューションに簡単に目を向けることができます。

コスト削減と拡張の容易さにより、サーバーレス ソリューションは、数百万人の視聴者を抱える Web アプリケーションまで、内部システムと外部システムの両方に同様に適用できます。 アカウントはユーロではなくセントで測定されます。 AWS EC2 の最も単純なインスタンス (t1.micro) を 15 か月間レンタルすると、何もしなくても 512 ユーロかかります (オフにするのを忘れたことがない人はいないでしょうか?!)。 比較すると、同じ期間内にこのレベルの支出に達するには、1 MB の Lambda を 3 秒間約 XNUMX 万回実行する必要があります。 この機能を使用しない場合は、料金はかかりません。

サーバーレスは主にイベント駆動型であるため、古いシステムにサーバーレス インフラストラクチャを追加するのは非常に簡単です。 たとえば、AWS S3、Lambda、Kinesis を使用すると、API 経由でデータを受信できる古い小売システム用の分析サービスを作成できます。

ほとんどのサーバーレス プラットフォームは複数の言語をサポートしています。 ほとんどの場合、Python、JavaScript、C#、Java、Go が使用されます。 通常、すべての言語のライブラリの使用に制限はないため、お気に入りのオープン ソース ライブラリを使用できます。 ただし、関数が最適に実行され、サーバーレス アプリケーションの優れたスケーラビリティの利点が損なわれないように、依存関係を乱用しないことをお勧めします。 コンテナにロードする必要があるパッケージが増えるほど、コールド スタートにかかる時間が長くなります。

コールド スタートとは、コンテナ、ランタイム、およびエラー ハンドラーを使用する前に、最初に初期化する必要がある場合です。 このため、関数の実行に最大 3 秒の遅延が生じる可能性があり、これはせっかちなユーザーにとっては最適なオプションではありません。 ただし、コールド スタートは、アイドル状態の関数が数分間続いた後の最初の呼び出しで発生します。 非常に多くの人が、これは些細な問題であり、関数をアイドル状態に保つために定期的に ping を送信することで回避できると考えています。 あるいは、この側面を完全に無視します。

AWSがリリースされましたが、 サーバーレス SQL データベース サーバーレス Auroraただし、SQL データベースはトランザクションを実行するために接続に依存しているため、このアプリケーションには理想的ではありません。これは、AWS Lambda で大量のトラフィックが発生するとすぐにボトルネックになる可能性があります。 はい、開発者はサーバーレス Aurora を常に改良しているので、試してみるべきですが、現在では次のような NoSQL ソリューションが使用されています。 DynamoDB。 しかし、この状況がすぐに変わることは間違いありません。

このツールキットには、特にローカル テストの分野で多くの制限も課されます。 Docker-Lambda、DynamoDB Local、LocalStack などのソリューションもありますが、これらには多大な労力と膨大な量の構成が必要です。 ただし、これらのプロジェクトはすべて積極的に開発されているため、ツールキットが必要なレベルに達するのは時間の問題です。

サーバーレステクノロジーが開発サイクルに与える影響

インフラストラクチャは単なる構成であるため、シェル スクリプトなどのスクリプトを使用してコードを定義し、デプロイできます。 または、次のようなコードとしての構成クラス ソリューションに頼ることもできます。 AWS CloudFormation。 このサービスはすべての領域の設定を提供するわけではありませんが、Lambda 関数として使用する特定のリソースを定義できます。 つまり、CloudFormation ではうまくいかない場合でも、このギャップを埋める独自のリソース (Lambda 関数) を作成できます。 この方法では、AWS 環境の外部で依存関係を構成することも含めて、何でも行うことができます。

これはすべて単なる構成であるため、特に CloudFormation のようなコードとしてのインフラストラクチャ ソリューションを使用している場合は、特定の環境、地域、ユーザーに合わせてデプロイメント スクリプトをカスタマイズできます。 たとえば、リポジトリ内の各ブランチにインフラストラクチャのコピーをデプロイして、開発中に完全に分離してテストできるようにすることができます。 これにより、開発者がコードが実際の環境で適切に機能するかどうかを理解したい場合のフィードバックが大幅にスピードアップされます。 管理者は実際の使用量に対してのみ料金を支払うため、複数の環境を導入するコストについて心配する必要はありません。

DevOps では、開発者が正しい構成を持っていることを確認するだけでよいため、心配が少なくなります。 インスタンス、バランサー、セキュリティ グループを管理する必要はなくなりました。 したがって、特に IAM 構成やクラウド リソースの最適化に関しては、インフラストラクチャを構成できることが依然として重要ではありますが、NoOps という用語が使用されることが増えています。

Epsagon、Thundra、Dashbird、IOPipe などの非常に強力な監視および視覚化ツールがあります。 これにより、サーバーレス アプリケーションの現在の状態の監視、ログ記録とトレースの提供、パフォーマンス メトリクスとアーキテクチャのボトルネックの把握、コスト分析と予測の実行などが可能になります。 これらは、DevOps エンジニア、開発者、アーキテクトにアプリケーションのパフォーマンスの包括的なビューを提供するだけでなく、管理者が XNUMX 秒あたりのリソース コストとコスト予測を使用して状況をリアルタイムで監視できるようにします。 管理されたインフラストラクチャを使用してこれを組織することははるかに困難です。

Web サーバーの展開、仮想マシンやコンテナの管理、サーバー、オペレーティング システム、インターネット ゲートウェイなどへのパッチ適用が必要ないため、サーバーレス アプリケーションの設計がはるかに簡単になります。これらすべての責任を抽象化することで、サーバーレス アーキテクチャはコアに集中できます。ソリューション、ビジネスと顧客のニーズ。

ツールキットはさらに優れている可能性がありますが (日々改良されています)、開発者はビジネス ロジックの実装と、アーキテクチャ内のさまざまなサービス間でアプリケーションの複雑さを最適に分散することに集中できます。 サーバーレス アプリケーション管理はイベント ベースであり、クラウド プロバイダー (SQS、S3 イベント、DynamoDB ストリームなど) によって抽象化されます。 したがって、開発者は、特定のイベントに応答するビジネス ロジックを作成するだけでよく、データベースやメッセージ キューを実装する最適な方法や、特定のハードウェア ストレージ内のデータを使用して最適な作業を組織する方法について心配する必要はありません。

他の開発プロセスと同様に、コードはローカルで実行およびデバッグできます。 単体テストは変わりません。 カスタム スタック構成を使用してアプリケーション インフラストラクチャ全体を展開できるため、開発者はテストのコストや高価な管理環境への影響を考慮することなく、重要なフィードバックを迅速に得ることができます。

サーバーレス アプリケーションを構築するためのツールとテクニック

サーバーレス アプリケーションを構築するための特別な方法はありません。 このタスク用の一連のサービスも含まれます。 AWS は今日、強力なサーバーレス ソリューションのリーダーですが、次の点にも注目してください。 Googleクラウド, 時間 и ファイアベース。 AWS を使用している場合、アプリケーションを収集するための推奨されるアプローチは次のとおりです。 サーバーレスアプリケーションモデル (SAM)、特に C# を使用する場合、Visual Studio には優れたツールがあるためです。 SAM CLI は Visual Studio で実行できることをすべて実行できるため、別の IDE またはテキスト エディターに切り替えても何も失われることはありません。 もちろん、SAM は他の言語でも動作します。

他の言語で記述している場合、サーバーレス フレームワークは、非常に強力な YAML 構成ファイルを使用してあらゆるものを構成できる優れたオープン ソース ツールです。 Serverless Frameworkはさまざまなクラウドサービスにも対応しているので、マルチクラウドソリューションをお探しの方におすすめです。 あらゆるニーズに対応する多数のプラグインを作成した巨大なコミュニティがあります。

ローカル テストには、オープン ソース ツールの Docker-Lambda、Serverless Local、DynamoDB Local、および LocalStack が適しています。 サーバーレス テクノロジとそのツールはまだ開発の初期段階にあるため、複雑なテスト シナリオをセットアップする場合は、懸命に取り組む必要があります。 ただし、単にスタックを環境にデプロイしてそこでテストするだけなら、信じられないほど低コストです。 また、クラウド環境の正確なローカル コピーを作成する必要もありません。

AWS Lambda Layers を使用して、デプロイされたパッケージのサイズを削減し、ダウンロードを高速化します。

特定のタスクには適切なプログラミング言語を使用します。 言語が異なれば、それぞれ長所と短所があります。 多くのベンチマークがありますが、AWS Lambda のパフォーマンスの点で最も優れているのは JavaScript、Python、C# (.NET Core 2.1 以降) です。 AWS Lambda は最近、ランタイム API を導入しました。これを使用すると、希望のランタイム言語と環境を指定できるので、試してみてください。

デプロイメント用にパッケージのサイズを小さくしてください。 小さいほどロードが速くなります。 特にライブラリのいくつかの機能を使用する場合は、大規模なライブラリの使用を避けてください。 JavaScript でプログラミングしている場合は、Webpack などのビルド ツールを使用してビルドを最適化し、本当に必要なものだけを含めます。 .NET Core 3.0 には QuickJit と階層型コンパイルがあり、パフォーマンスが向上し、コールド スタート時に非常に役立ちます。

サーバーレス機能はイベントに依存しているため、最初はビジネス ロジックの調整が困難になる場合があります。 この点で、メッセージ キューとステート マシンは非常に役立ちます。 Lambda 関数は相互に呼び出すことができますが、これを行うのは、応答を期待していない場合 (「起動して忘れる」場合)、つまり別の関数の完了を待つことで料金を請求されたくない場合に限られます。 メッセージ キューは、ビジネス ロジックの一部の分離、アプリケーションのボトルネックの管理、およびトランザクションの処理 (FIFO キューを使用) に役立ちます。 AWS Lambda 関数は、後の分析のために失敗したメッセージを追跡する滞留メッセージ キューとして SQS キューに割り当てることができます。 AWS Step Functions (ステートマシン) は、関数の連鎖を必要とする複雑なプロセスを管理するのに非常に役立ちます。 Lambda 関数が別の関数を呼び出す代わりに、ステップ関数は状態遷移を調整し、関数間でデータを渡し、関数のグローバル状態を管理できます。 これにより、再試行条件や、特定のエラーが発生した場合の対処方法を定義できます。これは、特定の状況では非常に強力なツールです。

まとめ

近年、サーバーレステクノロジーは前例のないペースで発展しています。 このパラダイムシフトに関連して、ある種の誤解があります。 インフラストラクチャを抽象化し、管理を拡張することにより、サーバーレス ソリューションは、開発および DevOps プロセスの簡素化から運用コストの大幅な削減まで、大きなメリットをもたらします。
サーバーレスのアプローチには欠点がないわけではありませんが、堅牢なサーバーレス アプリケーションを構築したり、サーバーレス要素を既存のアーキテクチャに統合したりするために使用できる堅牢な設計パターンがあります。

出所： habr.com