サーバーレス。 あなたはすでにどこかでこの用語に出くわした可能性が高いですが、それは正確に何を意味するのでしょうか? さて、開始するには、サーバーレス、または サーバーレス コンピューティングは、サーバーが関与していないという意味ではありません。 サーバーレス コンピューティングは、サーバーやハードウェアなどの物理リソースを管理するために必要なリソースやチームを持たない組織や、それに伴うすべてのメンテナンスとライセンスを持たない組織にとって大きなメリットとなり、コードやアプリケーションの開発に集中できます。
サーバーレス モデルの利点
サーバーレス アーキテクチャでは、アプリケーションが開発されるとき、通常、多くの異なるサービスで構成されます。 要求に応じて展開されると、これらのサービスは、個々の機能 (FaaS とも呼ばれる) またはサービスとしての関数としてデプロイされます。 ここでも、コンテナーまたは仮想マシン内のコードがクラウド プロバイダーによって管理されるという利点があります。 メンテナンス、パッチ、スケーリングについて心配する必要がなくなりました。 サーバーレス アーキテクチャのその他の利点は次のとおりです。
費用
当然ながら、物理サーバーをレンタルまたは購入する必要がなければ、組織は、物理インフラストラクチャを管理し、コード/アプリケーションの実行に使用される時間とメモリの支払いのみを行うという従来のルートを見逃す方が費用対効果が高くなります。
スケーラビリティ
前述したように、サーバー リソースの管理の大半は、スケール アップとスケールダウンを含め、クラウド プロバイダーに対して行われます。 開発者は、クラウド プロバイダーで自動的に行われるように、システムの微調整に時間を費やしたり、他のチームにサポートを頼ったりする必要はありません。
アプリケーション開発に重点を置く
ほとんどの管理、メンテナンス、および警察がクラウド プロバイダーにプッシュすることで、開発者はアプリケーションの完成に集中できます。
サーバーレス モデルの欠点
サーバーレス アーキテクチャへの移行には、多くの方法がありますが、従来のモノリシック モデルに比べていくつかの欠点があります。 基盤となるインフラストラクチャメトリックにアクセスできないという主な課題。 もう 1 つの要因は、サーバーレス アプリケーションが分散され、場合によっては異なるクラウド プラットフォーム間で分散され、プロセスの管理が困難になる点です。 組織は、サーバーレス環境に移行する際に、何を引き分けるかを決定する必要があります。 サーバーレス モデルのその他の欠点には、次のようなものがあります。
リソースの制限
サーバーレスで提供されるペイ・ツー・プレイ・モデルの性質上、使用できるリソースには制限があり、コード、要求、その他のサード・パーティー・リソースの実行時間には制限があります。 高いパフォーマンスを必要とするワークロードの場合、組織は自社のサーバーを購入する方が適しています。
応答時間
コードが使用されていない場合、クラウド プロバイダーは通常、コードをずっと絞り込みます。 ただし、リソースが要求される時間が来ると、そのコードのバックアップを開始するまでにかかる時間に遅延が発生する可能性があります。 専用サーバーで継続的に実行されているアプリケーションは、待機時間の問題による影響を受けることはありません。
セキュリティとプライバシー
主要なクラウド プロバイダーにサーバー リソースの制御を放棄すると、より安全になると思われるかもしれませんが、必ずしもそうであるとは限りません。 クラウド プロバイダーは、攻撃や脆弱性からクライアントを保護するために役割を果たしますが、保護する必要があるコンポーネントや要素の膨大な量は、従来のインフラストラクチャに必要なものをはるかに上回ります。 そして
モニタリング
サーバーレス環境では、アプリケーションのバックエンドパフォーマンスメトリックの可視性と制御が失われるため、監視を実行するのが難しくなる可能性があります。 また、アプリケーションを実行するリソースに対して課金される方法と内容を正確に把握することが困難になる場合もあります。 また、問題が発生した場所を見つけるために、何百ものページとログのグループを掘り下げて見つけることができます。
サーバーレス アプリケーションの監視
従来のセットアップのようにアプリケーション スタック全体を制御できなければ、サーバーレス環境での監視は少し難しい場合があります。 サーバー側のメトリック、レンダリング時間、および要素レベルのパフォーマンスの内訳に関する洞察を持たないと、問題が発生したときに問題を解決することが困難になる可能性があります。 サーバーレス環境のアプリケーションでも、運用環境で監視する必要がある要素はあります。 あなたはそれを設定し、それを忘れることはできません。 予期しない問題のトラブルシューティングを行い、アプリケーションのパフォーマンスを最適化する作業が必要になる可能性があります。 注意すべき点がいくつかありますが、以下で説明します。
エラー
当然ながら、アプリケーションやリクエストが失敗した場合や、失敗の原因を知りたいので、エラーは監視の重要な要素です。 時には、エラーは誰にも知らないで起こります。 アプリケーションの重要なステップまたはコンポーネントがダウンしていることに気付く人が、数日かかる場合があります。
潜在
アクションと応答の間に要する時間は、待機時間です。 たとえば、Web アプリケーションの場合、ユーザーがフォームの送信ボタンを押した後にかかる時間が考えられます。 成功した要求と失敗した要求の間にかかる時間を把握することは重要です。 サーバーレス環境では、アプリケーションが実行されていないときに、アプリケーションがスロットルされるため、追加のリソースは使用されず、課金されません。 ただし、スピン アップを行うと、必要なリソースの処理にかかる時間に多少の待機時間が発生する可能性があります。 これはコールドスタートと呼ばれます。 コールド スタートが多い場合は、ユーザー エクスペリエンスに影響を与える可能性があります。
交通
トラフィックとは、システムにどの程度の需要が課されているかを指し、サービスによっては通常は 1 秒あたりの HTTP 要求です。
ドットコムモニタを使用したサーバーレスアプリケーションの監視
AWS Lambda などのサーバーレスコンピューティングプロバイダーを使用すると、選択したリージョンからウェブサイト、ウェブアプリケーション、API をデプロイできますが、それらのサイトとウェブアプリを同じリージョンから監視することも必要です。
Dotcom-Monitor プラットフォーム内のソリューションでは、Web サイト、Web アプリケーション、および API の実際のブラウザーベースの監視を設定できます。 場所、事前に定義されたパフォーマンスしきい値、稼働時間のアラートを使用してモニターを設定し、アプリケーションまたはサイトが期待どおりに動作していない時期を正確に把握できるようにします。 さらに、Web アプリケーション監視ソリューションと EveryStep Web Recorderを使用すると、ショッピング カートのプロセスやフォーム、ログイン ページなどの複数ステップのユーザー トランザクションをスクリプト化し、予期しないエラーがないかどうかの手順を監視できます。 EveryStep Web レコーダーは、キーワード検証監視などの追加の監視機能を簡単に追加します。 キーワードの監視方法については、この Wiki の記事で学習できます。 ある場合は、すぐにアラート通知が表示されるため、問題がより多くのユーザーに影響を与える前に問題を修正できます。 すべてのドットコムモニタソリューションをチェックしてください。
結論: サーバーレス アプリケーションの監視
時間はお金です。 また、アプリケーションの実行にミリ秒単位でクラウド プロバイダーに支払いを行う場合、毎秒がカウントされます。 同様に、ユーザーがアプリケーションで経験を積む場合も、取引を中断する可能性があります。 ユーザーが最高のエクスペリエンスを得られるようにし、アプリケーションやサイトで予期しないダウンタイムやパフォーマンスに関連する問題を確実に監視します。
30日間無料で全体のドットコムモニタープラットフォームをお試しください!
