WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Use Swift on AWS Lambda with Xcode

Use Swift on AWS Lambda with Xcode

SwiftAWS LambdaXcodeServerless
元の動画を見る

ハイライト

Swift AWS Lambda ランタイムを使用すると、開発者は Swift で AWS Lambda 関数を作成し、Xcode のローカル ランタイム シミュレーターでデバッグし、Amazon Linux 2 Swift ツールチェーンを介して AWS Lambda にデプロイするためにパッケージ化できます。

主要内容

多くの Apple プラットフォーム アプリにはサーバー側ロジックが含まれています。クライアントはインターフェイスとデバイスの機能を担当し、サーバーはデバイス上にないデータへのアクセス、バックグラウンド タスクの処理、またはより計算量の多い作業の実行を担当します。問題は、両者が異なる言語、異なるツールチェーン、異なるデバッグ方法を使用することが多く、チームもクライアントとサーバーの 2 つのリズムに分かれることになります。

サーバーレス機能は、この問題をイベント処理機能に還元します。 AWS Lambda はイベントを受信し、オンデマンドでコンピューティング リソースを割り当てるため、開発者がアイドル時に専用サーバーを維持する必要がなくなります。講演で与えられた判断は単純明快だ。コンピューティングリソースの使用量はシステムコストに影響し、Swiftのリソースフットプリントの低さと開発のしやすさは、このような短時間のイベント駆動型タスクに適しているというものだ。

Apple が提示したソリューションは、Swift AWS Lambda ランタイムでした。開発者は Swift パッケージで実行可能製品を作成し、ランタイム ライブラリを導入してから、Lambda.run処理ロジックを登録します。最小バージョンにはクロージャが 1 つだけあります。パフォーマンス重視のバージョンは NIO に接続できますEventLoop;共通の JSON ペイロードを直接渡すことができます。Codableタイプ。

開発エクスペリエンスを大きく変えるのは、ローカル デバッグです。講演のデモでは、Lambda と iOS アプリを同じ Xcode ワークスペースに配置します。開発者はLambdaターゲットを設定するLOCAL_LAMBDA_SERVER_ENABLED=true、ランタイムは、ローカルマシン上で AWS Lambda ランタイムエンジンをシミュレートする HTTP サーバーを起動し、リッスンします。localhost:7000呼び出しエンドポイント。 XcodeはiOSアプリとLambdaの2つのプロセスを同時に管理します。ブレークポイントは、クライアントリクエストから Lambda 処理関数に至るまでヒットし、その後クライアント応答処理に戻ることができます。

導入プロセスも Swift から離れていません。サンプル スクリプトは、Swift.org Amazon Linux 2 イメージに基づいて Docker イメージを作成し、コンテナ内で Lambda 実行可能ファイルをコンパイルし、実行可能ファイルと依存関係を AWS Lambda に必要な zip に圧縮してから、AWS CLI を介して新しいコード バージョンをアップロードして通知します。オンラインになった後、AWS Lambda ランタイム エンジンは作業を取得し、ユーザー関数を呼び出し、結果を送信します。 API Gateway、S3、SQS、SNS、またはカスタム イベントはすべてトリガー エントリになる可能性があります。

詳細

クロージャーを使用して最小限の Lambda を作成する

(02:02) 最小 APIAWSLambdaRuntime始める。Lambda.runコンテキスト、イベント ペイロード、および完了ハンドラーを取得するクロージャーを受け取ります。ランタイム ライブラリはプログラムのライフ サイクルを管理し、基盤となるプラットフォームとの対話を担当します。

import AWSLambdaRuntime

Lambda.run { (_, name: String, callback) in
    callback(.success("Hello, \(name)!"))
}

キーポイント:

  • import AWSLambdaRuntimeSwift AWS Lambda ランタイム ライブラリの紹介。
  • Lambda.runLambda 処理エントリを登録すると、イベント ペイロードが利用可能になったときにランタイムがそれを呼び出します。
  • 最初のパラメータは context ですが、この最小限の例では使用されないため、次のように記述されます。_。
  • name: Stringイベント ペイロードです。この例では、それを文字列入力として受け取ります。
  • callback(.success(...))作業が完了すると、結果がランタイムに返されます。

EventLoop を使用してパフォーマンス重視のシナリオを処理する

(02:33) 2 番目の API はプロトコル指向であり、パフォーマンス重視のユースケースを指向しています。 NIO EventLoop を公開することで、Lambda 処理関数とネットワーク処理スタックが同じスレッドを共有できるようになり、コンテキストの切り替えが減少します。その代償として、ハンドラーはイベント ループをブロックできなくなります。

import AWSLambdaRuntime
import NIO

struct Handler: EventLoopLambdaHandler {
    typealias In = String
    typealias Out = String

    func handle(context: Lambda.Context, event: String) -> EventLoopFuture<String> {
       context.eventLoop.makeSucceededFuture("Hello, \(event)!")
    }
}

Lambda.run(Handler())

キーポイント:

  • EventLoopLambdaHandlerEventLoop のハンドラー プロトコルです。
  • typealias Inそしてtypealias Out入力と出力の型を宣言します。これらは次のとおりです。String。
  • handle(context:event:)戻るEventLoopFuture<String>、結果はNIOの非同期モデルに渡されます。
  • context.eventLoop.makeSucceededFuture(...)現在のイベント ループに未来を正常に作成します。
  • Lambda.run(Handler())実行のために構造体ハンドラーをランタイムに渡します。

Codable を使用して JSON ペイロードを処理する

(02:59) 次に、音声により文字列ペイロードがリクエスト/レスポンス構造に置き換えられます。 Lambda ペイロードは通常、JSON、Swift に基づいていますCodableJSON 型と Swift 型の間でシリアル化を行うことができます。

import AWSLambdaRuntime

struct Request: Codable {
    let name: String
    let password: String
}

struct Response: Codable {
    let message: String
}

Lambda.run { (_, request: Request, callback) in
    callback(.success(Response(message: "Hello, \(request.name)!")))
}

キーポイント:

  • Request入力イベントを表します。講義内のデモでは、登録フォームを運ぶためにこれを使用します。nameそしてpassword。
  • ResponseLambda によってクライアントに返される JSON 結果を表します。
  • 両方のタイプが続きますCodable、ランタイムは JSON ペイロードを Swift 型に変換し、Swift の結果を JSON に変換し直すことができます。
  • クロージャパラメータrequest: Requestハンドラー関数をビジネス タイプに直接対応させます。
  • Response(message: ...)は戻り値であり、完了ハンドラーがランタイムに返します。

Xcode でのクライアントと Lambda のデバッグ

(04:22) スピーチの Xcode デモでは、ワークスペースを使用して 2 つのプロジェクト (Lambda パッケージ マネージャー プロジェクトと iOS アプリ) を保持します。 Lambda ターゲットが直接実行される場合、実際の AWS Lambda ランタイム エンジンがローカルに存在しないため、エラーが報告されます。解決策はスキームを編集して変更することですLOCAL_LAMBDA_SERVER_ENABLEDに設定true。

(05:09) 再度実行すると、ローカルサーバーがリッスンします。localhost:7000、呼び出しエンドポイントでイベントを受信します。 iOSアプリ経由URLSessionこのアドレスに登録リクエストを送信します。 Xcode は、iOS アプリと Lambda 関数という 2 つのプロセスを同時に管理します。講義では、リクエストの構築、Lambda 関数の入力、レスポンスの処理の 3 か所でブレークポイントがヒットしました。戻り値の確認にもLLDBを使用しました。

(07:08) このデバッグ モードはローカルでのみ使用します。デプロイされた Lambda が HTTP 経由でクライアントにアクセスできるようにするには、AWS API Gateway を通じてエンドポイントを公開する必要があります。デモの焦点は開発フェーズにあります。クライアントとクラウドの機能は同じ Xcode デバッグ セッションで連携できます。

パッケージ化して AWS Lambda にデプロイする

(07:53) デモのデプロイには、AWS CLI をラップするスクリプトを使用します。このスクリプトは、まず Swift.org Amazon Linux 2 イメージに基づいて Docker イメージを作成し、次にコンテナ内で Lambda 関数をコンパイルします。次に、実行可能ファイルと依存関係を zip 圧縮します。これは、AWS Lambda が予期するパッケージ形式であり、最後に zip をアップロードして、新しいコード バージョンを通知します。

(09:33) この展開機能は 2 つの基本コンポーネントに依存しています。まず、Swift.org は 2020 年 5 月に Amazon Linux 2 用の Swift ツールチェーンのリリースを開始しました。これは、EC2 や AWS Lambda などの AWS コンピューティング サービスで使用できます。 2 番目に、Swift Lambda ランタイム ライブラリは AWS Lambda ランタイム API を実装し、単純なクロージャからパフォーマンス重視のイベント ハンドラーまでのマルチレイヤー API を提供します。

(10:14) ランタイム ライブラリにはライフサイクル ループとステート マシンが含まれており、ランタイム エンジンのキューから作業を取得し、その作業をユーザー関数に渡し、結果をランタイム エンジンに送信します。また、AWS Lambda ランタイム コンテキスト用に調整された非同期 HTTP クライアントも埋め込まれています。コンパイルされたプログラムは、ユーザー コード、ランタイム ライブラリ、および Swift の依存関係を実行可能ファイルにリンクします。これらは、要件に応じて静的または動的にリンクできます。

(11:15) AWS Lambda はサーバーレス関数の複数のコピーをオンデマンドで実行できるため、関数はステートレスのままである必要があります。このスピーチでは、グローバルな可変状態を避け、必要以上に長くメモリを保持しないように特に注意を促しています。トリガー エントリは、S3、SQS、SNS、API ゲートウェイ経由で公開される HTTP エンドポイント、またはユーザーが追加したカスタム イベントから取得できます。

重要ポイント

  • Swift で書かれた登録バックエンドを作成します: iOS 登録フォームを Swift Lambda に送信し、次のように入力します。Request: Codable、出力用Response: Codable。実行する価値がある理由: この講演では、iOS アプリの使用法が完全に示されています。URLSessionローカル Lambda を調整し、Xcode の 2 つのプロセスにわたるブレークポイントを使用してデバッグします。開始方法: 最初にローカルを使用するLOCAL_LAMBDA_SERVER_ENABLED=trueチューニングしてくださいlocalhost:7000、オンラインになったときに API Gateway を介して HTTP エンドポイントを公開します。

  • 負荷の高い計算タスクをクライアントから Swift Lambda に移動: サーバーレス関数の即時実行に適していないバックグラウンド タスクまたはデバイス上の計算タスクを処理します。実行する価値がある理由: Transcript は、サーバー コンポーネントの価値を、クラウド データへのアクセス、バックグラウンド タスク、およびコンピューティング集約型タスクに明らかに置いています。 Swift のリソース フットプリントは小さいため、オンデマンド コンピューティングにも適しています。開始方法: クロージャベースを使用するLambda.run最初のバージョンを作成し、ペイロードと戻り値を確認し、Amazon Linux 2 Docker イメージを使用してパッケージ化してデプロイします。

  • イベント駆動型のクラウド処理パイプラインを構築: S3、SQS、SNS、またはカスタム イベントで Swift Lambda をトリガーさせます。実行する価値がある理由: ランタイム ライブラリは拡張可能な統合ポイントを提供し、講演ではこれらの AWS イベント ソースがリストされます。開始方法: まずイベント ペイロードを定義しますCodableと入力し、クロージャ API を選択するか、EventLoopLambdaHandler。

  • クライアントと Lambda 用のローカル デバッグ テンプレートのセットを作成します: iOS アプリと Lambda パッケージを同じ Xcode ワークスペースに配置し、スキーム環境変数とブレークポイントの場所を事前設定します。実行する価値がある理由: このスピーチは、Xcode がクライアントと Lambda 実行可能ターゲットの両方を同時に管理できるため、デバッグのリクエストと応答がより簡単になることを証明しています。開始方法: デモ構造をコピーします: Lambda 実行可能製品は、クライアントが使用する Swift AWS Lambda ランタイムに依存します。URLSessionローカル呼び出しエンドポイントを呼び出します。

関連セッション

コメント

GitHub Issues · utterances