タグ付けされた質問 「serverless」

すべてのクラウドプロバイダーは、「サーバーレス」ソリューションをマーケティングしています。約束は、開発者が現在ソフトウェアを開発する方法をサーバーレスで置き換えることであり、運用では運用環境でソフトウェアを管理します。 「サーバーレス」とは何ですか？それについてどこでもっと知ることができ、今日どのようにそれを使用することができますか？

42 terminology  serverless 

次の設定があります。 複数のワーカーを作成し、計算を実行し、計算が完了した後に終了します。 そのため、毎回異なるインスタンスがタスクを実行するため、各ホストには独自のログファイルがあり、ファイルの膨大なリストが作成されます。 それは良い習慣ですか？そうでない場合、この特定のユースケースでタスク処理を記録するより良い方法は何でしょうか？ PS：私のインフラストラクチャはサーバーレスです。したがって、今のところ、（AWS）CloudWatchにログインしています。ただし、AWSとは独立して質問に回答し、可能な限りサーバーレス設定に合わせてください。

14 serverless  logging 

serverless.comで、AWS Lambda関数にシークレットを公開する最も簡単な方法は、それをserverless.ymlファイルに保存することです（たとえば、KMSで暗号化されます）。 しかし、暗号化された秘密をGitにコミットすることは、世界で最高のものではありません。シークレットを変更する必要がある場合は、コードの変更が必要です。 しかし、セキュリティだけの観点から、より良い代替策は何ですか？たとえば、シークレットをS3（暗号化）に保存し、Lambdaがその場所とKMSキーにアクセスできるようにすることができますが、実際には意味のある方法でより優れていますか？

12 security  aws-lambda  serverless  encryption 

「再試行ストーム」は、クライアントが設定された回数再試行するように設定された場合に発生します。サービスの通常の動作ではパケット損失が発生するため、再試行ポリシーが必要です。 この例を見てみましょう： たとえば、サービス全体が1秒あたり80,000リクエストをサポートし、キャパシティの約80％で実行されるようにスケーリングされている場合、サービスが1秒あたり101,000リクエストを受信する原因となったトラフィックのスパイクにより、1,000リクエストが失敗します。 再試行ポリシーが有効になると、エラーが検出された場所に応じて、追加で1,000以上のリクエストが発生し、サービス全体として1秒あたり最大102,000のリクエストがプッシュされます。毎秒失敗したリクエストの数。 予測されたピークトランザクションを超えるサービスの大規模な過剰プロビジョニング以外は、非効率的です。「リトライストーム」を回避するためにどのような戦略を採用できますか？

10 serverless  cloud  distributed-systems