Amazon Web Services ブログ

アプリケーションロードバランサー(ALB)のターゲットにAWS Lambdaが選択可能になりました

本日より、アプリケーション ロードバランサー (ALB)はAWS Lambda functionをターゲットにすることをサポートします。ウェブサイトの構築やウェブアプリケーションをAWS Lambdaを使いサーバレスなコードとして作成、管理し、ウェブブラウザやクライアントからのリクエストに簡単なHTTP(S)フロントエンドを提供するように設定できます。

アプリケーションロードバランサーからLambda関数をトリガするには

Amazon EC2コンソールまたはAWS LambdaコンソールのLoad Balancingにて、Lambda関数をALBに関連付けることができます。 Lambdaコンソールで操作する方法からやってみましょう。 以下の例では、Add TriggersリストからApplication Load Balancerを選択して、HelloWorld Lambda関数のトリガーを設定できます。

トリガーを設定するには、使用するApplication Load Balancerと、AWS Lambdaに転送するリスナー、ホスト、およびURLパスを指定します。 ALBを持っていない場合は、トリガーの設定を選択すると、ALBを作成するためのリンクを利用します。

リスナーは、ALBがトラフィックを受信するポートです。 たとえば、80番ポートにはHTTPリスナー、443番ポートにはHTTPSリスナーがあります。各リスナーを異なるLambda関数に送信するか、複数のリスナーが同じ関数に送信するかを選択できます。

また、ALBに送信されるリクエスト内のホストまたはホストとURLパスに基づいて、異なるLambda機能にトラフィックを送信することもできます。 これは、特定のドメインまたはURLからの要求をインスタンス（または旧オンプレミスホスト）で処理し、AWS Lambdaが提供するサーバーレスインフラストラクチャで他の要求を処理するハイブリッドアプリケーションで役立ちます。 たとえば、ユーザーアカウント管理機能を既存のアプリケーションからサーバーレスセットアップに移行することを選択できます。 ALBによって提供されるコンテンツベースのルーティングを使用して、”/account/”で始まるすべての要求がLambda機能をトリガーするように指定できます。

構成を完了したら、「追加」を選択してApplication Load Balancerトリガー設定を終了し、指定されたトラフィックをAWS Lambdaに転送を開始します。 リスナー、ホスト、パスの設定に適合するリクエストがALBに到着すると、着信要求とロード・バランサに関するすべての詳細を提供するイベントでLambda関数が呼び出されます。

要求には、HTTP GET、HEAD、PUT、POST、DELETE、PATCH、OPTIONSメソッドが含まれ、要求および応答の本文にはテキストまたはバイナリを使用できます。 AWS Lambdaで設定したApplication Load Balancerは、HTTP(S)リクエストをAWS Lambdaイベントに変換します。

ALBがAWS Lambdaに必要な変更を行った後の変換済みリクエストの例を次に示します。

{
'requestContext': {
'elb': {
'targetGroupArn': 'arn:aws:elasticloadbalancing:us-east-1:XXXXXXXXXXX:targetgroup/sample/6d0ecf831eec9f09'
}
},
'httpMethod': 'GET',
'path': '/',
'queryStringParameters': {},
'headers': {
'accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'accept-encoding': 'gzip',
'accept-language': 'en-US,en;q=0.5',
'connection': 'keep-alive',
'cookie': ‘name=value',
'host': 'lambda-YYYYYYYY.elb.amazonaws.com',
'upgrade-insecure-requests': '1',
'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Firefox/60.0',
'x-amzn-trace-id': 'Root=1-5bdb40ca-556d8b0c50dc66f0511bf520',
'x-forwarded-for': '192.0.2.1,
'x-forwarded-port': '80',
'x-forwarded-proto': 'http'
},
'body': '',
'isBase64Encoded': False
}

リクエストが到着すると、AWS Lambdaは、クライアントに提供するステータスコード、説明、ヘッダ、および本文を指定するパラメータで応答する必要があります。 簡単な例として、以下はHTMLの “Hello World”メッセージをレンダリングするPythonで書かれたAWS Lambda関数です：

def lambda_handler(event, context):
    response = {
       “statusCode”: 200,
       “statusDescription”: “200 OK”,
       “isBase64Encoded”: False,
       “headers”: {
           “Content-Type”: “text/html; charset=utf-8”
        }
    }

    response[‘body’] = “””<html>
    <head>
    <title>Hello World!</title>
    <style>
    html, body {
       margin: 0; padding: 0;
       font-family: arial; font-weight: 700; font-size: 3em;
       text-align: center;
    }
    </style>
    </head>
       <body>
          <p>Hello World!</p>
      </body>
    </html>”””
    return response

あなたの関数が作成され、ALBトリガが設定されれば、これで設定は完了したはずです！

別の利点として、Amazon API GatewayがLambda関数をトリガするために使用するパラメータとALBのパラメータとの間には、多くのオーバーラップと共通性があります。 これにより、どちらかのサービス、あるいはその両方で同じLambda関数を使用することが容易になります。 既にAPI GatewayでAWS Lambdaを使用している場合は、この新機能をすぐにご利用いただけます。

 

高度な設定：複数値ヘッダーとフェールオーバー構成

アプリケーションロードバランサには、AWS LambdaでALBを使用するときに設定する必要がある2つの高度なオプションがあります。複数値ヘッダーとヘルスチェック設定のサポート。 これらのオプションは、Amazon EC2コンソールの[ターゲットグループ]セクションで設定できます。

 

マルチバリューヘッダーを有効にするには、「属性」で「属性の編集」を選択します。 マルチバリューヘッダーを有効にすると、複数の値とともに送信されるHTTPヘッダーとクエリ文字列パラメーターが、AWS Lambdaイベントおよび応答オブジェクト内の配列として表示されます。

たとえば、クライアントが “？name = foo＆name = bar”のようなクエリ文字列を提供しているとします。 マルチバリューヘッダーを有効にしている場合、ALBはこれらの重複パラメーターをイベントオブジェクトの[名前]：[‘foo’、 ‘bar’]として提供します。 ALBは同じ処理をHTTPヘッダーの複製に適用します。

別の高度な機能として参考になるかもしれないものが、ALBのヘルスチェックです。 ヘルスチェックを有効にすると、ロードバランサはLambda関数にリクエストを送信し、Lambda関数がまだ機能していることを確認します。

ヘルスチェックを有効にすると、ロードバランサがフェイルオーバー構成の一部である場合に便利です。 たとえば、ドメインがAmazon Route 53でホストされている場合は、複数のアプリケーションロードバランサ、CloudFrontディストリビューション、S3バケット、およびその他のリソース間でフェイルオーバーを構成できます。 フェールオーバーにより、ある場所またはデプロイでアプリケーションに問題が発生した場合、DNSレベルのフェイルオーバーによって着信トラフィックが別のリソースに再ルーティングされます。

ヘルスチェックのデフォルト設定は、次のスクリーンショットに示されています。 デフォルトを変更する必要はほとんどありませんが、必要に応じて、発生頻度、機能の確認に使用するURLパスなど、ヘルスチェックの設定を調整することができます。

 

追加の高度な機能を設定する場合は、EC2コンソールの[ロードバランシング]セクションで他のオプションを選択できます。 たとえば、コンテンツ・ベースのルーティング・ルールを追加したり、組み込み認証を有効にしたり、Webアプリケーション・ファイアウォール（WAF）を設定したり、Application Load Balancerから直接HTTPリダイレクトを送信したりすることができます。

各Application Load Balancerには、LambdaTargetProcessedBytesとStandardProcessedBytesの2つの新しいCloudWatchメトリックも含まれています。 これらのメトリックは、ターゲットとしてのAWS Lambda機能によって処理されるデータの量、およびEC2インスタンス、コンテナ、IPアドレスターゲットなどの他のターゲットによって処理される量を示します。

 

ご利用と価格

ALBのLambda関数ターゲットはN.Virginia、Ohio、North California、Oregon、Mumbai、Seoul、Singapore、Sydney、東京、Canada Central、Frankfurt、Ireland、London、Prais、São Paulo、GovCloudでご利用可能です。

ALBの1時間当たりの価格に変更はありません。 AWS Lambdaに対するALBのロードバランサキャパシティユニット（LCU）は、データ処理時間が0.4 GBになりました。

 

筆者:

ColmMacCárthaighはAWSのプリンシパルエンジニアです。 彼はネットワーキング、暗号化、およびオープンソースの技術に取り組んでいます。

 

 

 

 

 

飜訳はSA 小梁川が担当しました。

原文はこちら