辛宝Otto

辛宝Otto 的玄酒清谈

北漂前端程序员儿 / 探索新事物 / Web Worker 主播之一/内向话痨
xiaoyuzhou
email
ホームアーカイブPodcasts

bookを読み終えました-フロントエンドServerlessフルスタックのサーバーレスアーキテクチャ実践

90
AI 翻訳
この記事はAIを通じて中国語から日本語に翻訳されました。原文を表示
AI が生成した要約
Serverless (sls) is a concept in cloud-native computing that eliminates the need for server maintenance and management by providing computing resources as a service. It includes Function as a Service (FaaS) and Backend as a Service (BaaS). FaaS offers low costs and easy scalability, while BaaS allows for integration with other services. Use cases for FaaS include stateless functions, independent workloads, automatic scaling, and event-driven processes. However, there are disadvantages such as high learning costs and vendor lock-in. Sls can be used with server-side technologies to achieve separation of concerns. The text also discusses the use of vm2 and child_process.fork for isolation and executing user code, as well as other related topics such as HTTP support, process management, and resource limitations. It also mentions BaaS and the use of Redis as a simple key-value store. Additionally, it covers OAuth2 and OIDC for authorization and authentication, and the concept of IDaaS for third-party integration.

#サーバーレス

image.png

杨凯 中国工信出版集团

アウトライン#

  • 概要：革命的な影響、SLS の理解と現在の技術の位置づけ
  • FaaS：Serverless のコア思想の実際の応用技術
  • BaaS：SLS のもう一つの主要な分野

概要#

#cloudnative クラウドネイティブで最も頻繁に言及される概念は、サーバーレスです。

SLS の概念、SLS の開発理念、極低の運用コスト、大幅に削減されたサーバー費用

例えば、GitHub Pages では、開発者はファイルを静的なウェブサイトとしてデプロイし、ドメインを割り当て、サービスにアクセスします。多くの詳細が隠されています。

例えば、CDN では、詳細なノードについて心配する必要がなく、グローバルユーザーが高速にアクセスできます。

計算リソースをサービスとして提供することで、製品を提供する方法として、サーバーレスの考え方に合致し、技術の詳細を隠し、外部にサービスを提供できると考えることができます。

CNCF は 2018 年にサーバーレスのホワイトペーパーを発表しました。

SLS は、アプリケーションの構築および実行のいずれの場合でも、サーバーのメンテナンスや管理を行う必要がありません。

SLS コンピューティングプラットフォームは、FaaS または BaaS のいずれかの機能を含む必要があります。

次に、使用シナリオと利点と欠点を紹介します。

FaaS の利点：開発効率の向上、低コストのデプロイ、低コストの運用、低コストの学習、低コストのサーバー費用、柔軟なデプロイメントオプション、高いシステムセキュリティ

欠点：プラットフォームの学習コストが高い、デバッグコストが高い（実行時にクラウド上で実行されるため、ローカルでのデバッグやログのクエリが困難）、コールドスタート、ベンダーロックイン

使用シナリオ：

  • 関数自体は状態を持たず、永続化されたサーバーと統合
  • 関数が独立して動作し、大量の関数が相互に連携して計算すると、コストが上昇する
  • 自動スケーリング
  • イベント駆動、HTTP、データベースの変更、定期的なイベントなど
  • コールドスタートの要件が低いシナリオ

FaaS 自体は HTTP プロトコルをサポートしていないため、API ゲートウェイを使用して Web API を提供する必要があります。

SLS とサーバーテクノロジー#

モノリシックアプリケーション - レイヤー化アーキテクチャ、UI レイヤー、ビジネスロジックレイヤー、データアクセスレイヤー

3 層アーキテクチャを基に、企業アプリケーションアーキテクチャパターン、ドメイン駆動設計などの本を参考に、さらに分離

  • アプリケーションレイヤー
  • ドメインレイヤー
  • パーシステントレイヤー
  • インフラストラクチャレイヤー

それでも、コードを分割して関心の分離を達成することで、ログイン、権限チェックなどのロジックを切り離すことができるかどうかを考えることができます。

マイクロサービスアーキテクチャスタイルは、分散アーキテクチャから進化しました。複数の独立した小さなサービスを使用して、軽量で制御可能なソフトウェア開発と管理を行います。サービス間の通信は RPC を使用して行われ、各サービスは異なる技術スタックで機能を提供できます。

システムアーキテクチャの設計は、組織のコミュニケーション構造に制約を受けます。コンウェイの法則。どのような組織構造があれば、どのようなアーキテクチャが設計されるか。例えば、小さな会社では、モノリシックアプリケーションがあり、規模が拡大すると、新しいメンバーは全体を再学習する必要があります。これはメッシュ構造であり、お互いに情報を同期する必要があり、コミュニケーションコストが指数関数的に増加します。

モノリシックアプリケーションをマイクロサービスに分割すると、自分のビジネスに集中し、不要な情報を隠すことができ、コミュニケーションコストを低減できます。

コンテナ化、クラウドコンピューティング、noops- devops の次の段階であり、開発者の運用投資を削減する理念です。

SLS とフロントエンド技術#

bff、バックエンドはフロントエンドにサービスを提供します。フロントエンドとバックエンドの間に接着剤層を作成し、情報を集約およびトリミングします。1 つのインターフェースで複数のインターフェースの操作を完了します。不要なフィールドを削除するなど。

これにより、インターフェースが柔軟になります。コミュニケーションコストが低くなります。パフォーマンスの最適化のためのリクエストの削減、データの公開の削減など。

GraphQL は、多言語のマイクロサービスアーキテクチャでは適用しづらく、改造コストが高いため、クロス言語の実装はほとんどありません。クロスデータベースの統一されたクエリの実装能力。サーバーレスと組み合わせることで可能になります。

FaaS テクノロジー#

イベント駆動。デザインモデルです。

FaaS 関数もイベント駆動であり、異なるトリガーがイベントソースとして機能します。例えば、http トリガー

関数は状態を持たないため、非常にシンプルです。

関数の作成。多くの技術的な詳細が含まれていますが、現在のバージョンでは何度も変更されています。

  • ランタイムの選択
    • デフォルト
    • カスタムランタイム、これが最も互換性が高い
    • カスタムコンテナ、GPU コンテナなど
  • 基本情報、名前、リージョン、トリガーイベントと http
  • コードのアップロード
    • デモの例
    • zip パッケージの圧縮
    • oss のアップロード
    • フォルダのアップロード
  • 仕様設計
    • CPU 0.05〜16g
    • メモリ 128M〜32G
    • 一時ディスク 512M、10G
    • コンテナデプロイを選択した場合、GPU T4/A10 の仕様も選択できます
    • インスタンスの同時処理数。同時に処理できるリクエストの数
    • タイムアウト時間 60 秒
    • タイムゾーン
  • 認証認証
    • 署名
    • jwt

2015 年、オープンソースコミュニティで Serverless Framework が登場し、SLS のフレームワークとエコシステムになることを目指し、ベンダーロックインの問題を解決しました。

詳細な記述は省略します。

7. 関数のライフサイクル#

module.exports.handler = function (request, response, context) {
// code
(async () => {
response.setStatusCode(200);
response.setHeader('content-type', contentType);
response.send(fs.readFileSync(path))

})().catch(err => {

response.setStatusCode(500);
response.setHeader('content-type', 'text/plain');
response.send(err.message);

});
}

8. ランタイムの理解#

デザインパターン 23 種類

メッセージキューは、高並行性の問題を解決し、システムの解耦を実現できます。ピークを削減し、メッセージの順序を保証します。

突然、情報トリガーのソリューション、サイト内メッセージ、SMS、WeChat プッシュなどを思いつきました。

9. 簡易 FaaS の構築#

各関数の安全性を確保し、お互いを妨げずに隔離するためのキー技術は、サンドボックスです。

  • Docker を使用した隔離
  • プロセスの隔離、Docker よりも劣る

マスターが関数呼び出しを監視し、子プロセスが関数を実行するようにします。結果をメインプロセスに通信します。

ここでは、child_process.fork()を使用して子プロセスを起動して隔離を実現します。

コードの実行には eval/Function を使用できますが、最適なソリューションは node のnew vm.Script(code)です。

しかし、vm にもリスクがあります。例えば、this.constructor.construcotr

プロトタイプチェーンの設計なので、プロトタイプチェーンがない方が良いです

const sandbox = Object.create(null)
vm.createContext(sandbox)
vm.runInContext(code,sanbox)

しかし、完璧ではありません。コミュニティではvm2を使用し、プロキシ機能を使用してラップすることで、より安全になります。

したがって、ランタイムには vm2 と child_process.fork の組み合わせを使用することで、隔離とユーザーコードの実行を実現できます。

HTTP プロトコルのサポートを実現するために、koa を使用できます。関数を動的にダウンロードして実行する...

簡易版は完成しましたが、スループットのパフォーマンス、セキュリティと安定性、開発効率を考慮する必要があります。

実行ごとに子プロセスを作成して実行するため、プロセスの作成と破棄の管理はパフォーマンスのオーバーヘッドです。高並行時には多すぎるプロセスがクラッシュの原因になる可能性もあるため、プロセスプールを考慮する必要があります。

クラスターを使用することで、child_processをさらに抽象化してラップし、より使いやすくすることができます。

クラスターと vm2 を組み合わせて koa を使用すると、ソリューションを実現できます。

gpt に尋ねた結果、generic-poolを検討することができます：このモジュールは、さまざまなリソース（プロセスを含む）を管理するための汎用のプールを提供します。プロセスプールを作成して、頻繁に子プロセスを起動および停止することを避けることができます。柔軟な構成オプションを提供し、プールのサイズ、リソースの割り当てポリシーなどをカスタマイズできます。

ユーザーコードが無限ループを使用している場合、タスクを終了することはできません。タイムアウトを設定します。 vm/vm2 にはタイムアウトがあります。たとえば、5000ms に設定します。

非同期呼び出しの問題、デフォルトのタイムアウトは機能しない場合、タイマーを自分で実装することを検討できます

安定性を確保するために、リソース制限が必要です。CPU、メモリ、ディスクの高負荷使用。リソースを制限するために、Linux では CGroup を使用し、Docker でもこの機能を使用しています。

CGroup の概念について詳しく説明しましたが、詳細は省略します。コマンドを使用して、プロセスの最大 CPU リソースを 20% に制限することができます。やや複雑ですが、gpt の回答は良かったです。

効率を向上させるために、組み込みのフロントエンドの一般的なサービス。

  • シンプルなキーバリューストア、get/set を実現するために vm2 を使用

もちろん、Redis が最適です

BaaS テクノロジー#

backend as a service。

![[Pasted image 20230923233047.png]]

Firebase などの例を挙げ、多くの使いやすい基本サービスを提供しています。クラウドデータベース、クラウド関数、認証、ホスティング、ストレージなど。

クラッシュレポート、パフォーマンスモニタリング、テストラボ、アプリディストリビューションなどの機能もあります。

拡張系のオペレーション機能もあります

  • アプリ内メッセージング
  • 分析
  • a/b テスト
  • クラウドメッセージング、IM などのプッシュメッセージ
  • リモート構成

国内の LeanCloud/bmob などと比較すると、総合性にはまだ差があります。

データベースの設計原則など。

例えば、posts と comments の 2 つのテーブルのクエリでは、select 1+n の問題が発生し、まず情報を見つけてからデータを n 回クエリする必要があります。SQL では、join を使用します。

例えば、最新の 5 件のコメントの内容、所属する記事のタイトル。

SQL を使用すると、簡単です。事前に埋め込みのソリューションにすると簡単です。参照になった場合は、より多くの冗長なコンテンツを保持する必要があります。新しいコレクションを作成し、最新のコメントのコレクション、冗長なフィールドを保持します。読み取り書き込みの問題がある場合は、キャッシュに変更し、1 時間ごとに更新します。問題は、削除時に複数の削除を同期する必要があることです。

ネストされた場合は、1 回のクエリで実行できるため、クエリのパフォーマンスが向上します。ネストされた複雑なデータの場合は、うまくいきません。データをまとめてソートし、実装もメモリに配置することになります。大量のデータの場合はうまくいかないかもしれません。

CDN、オブジェクトストレージなどの機能についても簡単に紹介しました。

ユーザー認証では、OneID はあまり人気がありませんが、OAuth 2.0 の導入により、IETF の組織に組み込まれ、標準化が実現されました。

OAuth は認証ではなく、認可を解決するものであり、OIDC - OpenID Connect を導入しました。

さらに、ID トークンとアクセストークンを分離しました。

JWT は rfc 7519 です。

サードパーティとの連携はかなり困難ですが、IDaaS（auth0、authing などのウェブサイト）が登場しました。

  • 身分認証アカウントの認可
  • SSO シングルサインイン、1 つのアプリケーションにログインして、複数のアプリケーションを共有する
  • OAuth2 を外部に提供する
  • パスワードをリセットするためのメール、SMS の統一送信
  • 企業の ID ログイン
  • 2 要素認証

見てみると良いですが、いくつかの user/rule/rules/hooks などがあります

以上です。

読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。