翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS Lambda 関数を実行する
<a name="run-lambda-functions"></a>

**注記**  
AWS IoT Greengrass は、現在 Windows コアデバイスにこの機能をサポートしていません。

AWS Lambda 関数を AWS IoT Greengrass コアデバイスで実行されるコンポーネントとしてインポートできます。このようにするのは、次のような場合です。
+ コアデバイスにデプロイする Lambda 関数にアプリケーションコードがあります。
+ AWS IoT Greengrass V2 コアデバイスで実行する AWS IoT Greengrass V1 アプリケーションがあります。詳細については、「[ステップ 2: AWS IoT Greengrass V1 アプリケーションを移行する AWS IoT Greengrass V2 コンポーネントを作成してデプロイする](set-up-v2-test-device.md#run-v1-applications)」を参照してください。

Lambda 関数には以下のコンポーネントに依存関係が含まれています。関数のインポート時に、これらのコンポーネントを依存関係として定義する必要はありません。Lambda 関数コンポーネントをデプロイすると、デプロイにはこれらの Lambda コンポーネントの依存関係が含まれます。
+ [Lambda ランチャーコンポーネント](lambda-launcher-component.md) (`aws.greengrass.LambdaLauncher`) は、プロセスと環境設定を処理します。
+ -[[Lambda manager component]](lambda-manager-component.md) (Lambda マネージャーコンポーネント) (`aws.greengrass.LambdaManager`) は、プロセス間通信とスケーリングを処理します。
+ [Lambda ランタイムコンポーネント](lambda-runtimes-component.md) (`aws.greengrass.LambdaRuntimes`) は、サポートされている各 Lambda ランタイムのアーティファクトを提供します。

**Topics**
+ [要件](#run-lambda-functions-requirements)
+ [Lambda 関数のライフサイクルを設定する](#lambda-lifecycle)
+ [Lambda 関数のコンテナ化を設定する](#lambda-containerization)
+ [Lambda 関数をコンポーネントとしてインポートする (コンソール)](import-lambda-function-console.md)
+ [Lambda 関数をコンポーネント (AWS CLI) としてインポートする](import-lambda-function-cli.md)

## 要件
<a name="run-lambda-functions-requirements"></a>

コアデバイスと Lambda 関数が AWS IoT Greengrass Core ソフトウェアで関数を実行するには、次の要件を満たす必要があります。
+ <a name="core-device-lambda-function-requirements"></a>コアデバイスは、Lambda 関数を実行するための要件を満たしている必要があります。コアデバイスが、コンテナ化された Lambda 関数を実行させる場合、そのデバイスは要件を満たす必要があります。詳細については、「[Lambda 関数の要件](setting-up.md#greengrass-v2-lambda-requirements)」を参照してください。
+ Lambda 関数が使用するプログラミング言語をコアデバイスにインストールする必要があります。
**ヒント**  
プログラミング言語をインストールするコンポーネントを作成し、そのコンポーネントを Lambda 関数コンポーネントの依存関係として指定できます。Greengrass は、Lambda でサポートされるすべてのバージョンの Python、Node.js、Java ランタイムをサポートします。Greengrass は、非推奨となった Lambda ランタイムバージョンに追加の制限を適用しません。これらの非推奨になったランタイムを使用する Lambda 関数は AWS IoT Greengrass で実行できますが、AWS Lambda で作成することはできません。Lambda ランタイムの AWS IoT Greengrass サポートの詳細については、「[AWS Lambda 関数を実行する](#run-lambda-functions)」を参照してください。

## Lambda 関数のライフサイクルを設定する
<a name="lambda-lifecycle"></a>

Greengrass Lambda 関数ライフサイクルは、関数が開始する時期とどのようにコンテナを作成して使用するかを定義します。また、ライフサイクルでは、AWS IoT Greengrass Core ソフトウェアがファンクションハンドラーの外部にある変数や前処理ロジックをどのように保持するかも決定されます。

AWS IoT Greengrass は、オンデマンド (デフォルト) および長い存続期間のライフサイクルをサポートしています。
+ **オンデマンド** 関数は、呼び出されたときに起動し、実行するタスクが残っていないときに停止します。関数を呼び出すたびに、サンドボックスとも呼ばれる個別のコンテナが作成され、既存のコンテナが再利用可能でない限り、呼び出しが処理されます。どのコンテナでも、関数に送信したデータを処理することがあります。

  オンデマンド関数の複数の呼び出しを同時に実行できます。

  関数ハンドラーの外部で定義した変数や前処理ロジックは、新しいコンテナが作成されるときに保持されません。
+ **存続期間が長い** (または*固定された*) 関数は、AWS IoT Greengrass Core ソフトウェアが起動すると開始され、単一のコンテナで実行されます。同じコンテナが、関数に送信するすべてのデータを処理します。

  AWS IoT Greengrass Core ソフトウェアが以前の呼び出しを実行するまでキュー状態になります。

  関数ハンドラーの外部で定義する変数と事前処理ロジックは、このハンドラーの毎回の呼び出しのために保持されます。

  初期入力なしで作業を開始する必要がある場合は、長い存続期間の Lambda 関数を使用してください。例えば、存続期間が長い関数は、機械学習モデルを読み込んで処理を開始し、関数がデバイスデータを受信したときに準備が整うようにすることができます。
**注記**  
長い存続期間の関数には、ハンドラーの各呼び出しに関連付けられたタイムアウトがあります。無期限に実行されるコードを呼び出す場合は、ハンドラーの外部で開始する必要があります。関数の初期化を妨げる可能性のあるブロッキングコードがハンドラーの外部にないことを確認してください。  
これらの機能は、デプロイ中や 再起動中など、AWS IoT Greengrass Core ソフトウェアが停止しない限り実行されます。これらの関数は、関数がキャッチされない例外に遭遇した場合、そのメモリ制限を超過した場合、またはハンドラータイムアウトなどのエラー状態に入った場合は実行されません。

コンテナの再利用の詳細については、「*AWS Compute Blog*」の「[Understanding Container Reuse in AWS Lambda](https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/)」を参照してください。

## Lambda 関数のコンテナ化を設定する
<a name="lambda-containerization"></a>

デフォルトでは、Lambda 関数は AWS IoT Greengrass コンテナ内で実行されます。Greengrass コンテナは、関数とホスト間の分離を提供します。この分離により、ホストとコンテナ内の関数の両方でセキュリティが向上します。

ユースケースでコンテナ化せずに実行する必要がある場合を除き、Lambda 関数を Greengrass コンテナで実行することをお勧めします。Greengrass コンテナで Lambda 関数を実行することで、リソースへのアクセスを制限する方法をより細かく制御できます。

以下の場合、コンテナ化を使用しないで Lambda 関数を実行できます。
+ コンテナモードをサポートしていないデバイスで AWS IoT Greengrass を実行する場合。例えば、特殊な Linux ディストリビューションを使用する場合や 以前のカーネルバージョンが古くなった場合などです。
+ 独自の OverlayFS がある別のコンテナ環境の Lambda 関数を、Greengrass コンテナで実行すると、OverlayFS の競合が発生する場合。
+ デプロイ時に決定できない、またはデプロイ後にパスが変更される可能性のあるローカルリソースにアクセスする必要があります。このリソースの例としては、プラガブルデバイスがあります。
+ プロセスとして作成された以前のアプリケーションがあり、それを Greengrass コンテナで実行すると問題が発生します。


**コンテナ化の相違点**  

| コンテナ化 | メモ | 
| --- | --- | 
| Greengrass コンテナ |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/run-lambda-functions.html)  | 
| コンテナなし |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/run-lambda-functions.html)  | 

Lambda 関数をデプロイするときにコンテナ化を変更すると、関数が期待通りに動作しない場合があります。Lambda 関数が、新しいコンテナ化設定で利用できなくなったローカルリソースを使用する場合、デプロイは失敗します。
+ Greengrass コンテナでの実行からコンテナ化を使用しない実行へと Lambda 関数を変更すると、関数のメモリ制限は破棄されます。アタッチ済みのローカルリソースを使用する代わりに、ファイルシステムに直接アクセスする必要があります。Lambda 関数をデプロイする前に、すべてのアタッチ済みリソースを削除する必要があります。
+ コンテナ化を使用しない実行からコンテナでの実行へと Lambda 関数を変更すると、Lambda 関数はファイルシステムに直接アクセスできなくなります。関数ごとにメモリ制限を定義するか、デフォルトの 16 MB のメモリ制限を受け入れる必要があります。これらの設定は、デプロイ時に Lambda 関数ごとに設定できます。

Lambda 関数コンポーネントのコンテナ化設定を変更するには、コンポーネントをデプロイするときに `containerMode` 設定パラメータの値を次のいずれかのオプションに設定します。<a name="lambda-function-component-container-mode-parameter"></a>
+ `NoContainer` - コンポーネントは、分離されたランタイム環境では実行されません。
+ `GreengrassContainer` – コンポーネントは、AWS IoT Greengrass コンテナ内の分離されたランタイム環境で実行されます。

コンポーネントをデプロイおよび設定する方法の詳細については、「[AWS IoT Greengrass コンポーネントをデバイスにデプロイする](manage-deployments.md)」および「[コンポーネント設定の更新](update-component-configurations.md)」を参照してください。