やーまんぶろぐ

気が向いた時にだけ書くブログ

AWS Fargateを触ってみた

Fargateとは、コンテナを扱う上で、サーバーやクラスタの管理が不要になるサービスです。

こちらを参考にチュートリアルを起動してみました。
www.ketancho.net

起動させたいコンテナイメージさえあれば簡単に動かせそうで、非常に興味深いサービスです。

メモ

  • VPCについて
    • GUIからだと新規VPCしか選べない
    • 作成後もVPCは変更できなそう
  • ALBについて
    • ALBと連携させることが可能
    • GUIだと新規しかつくれない
    • GUIからだとポートも選択肢が80だけ
    • ALBのリスナーは作成後に編集できるので、後から443に変更することできそう
  • CloudFormationについて

Amazon API Gateway のリソースポリシーでアクセスコントロール

Amazon API Gateway のリソースポリシーでアクセスコントロールできるようになりました。
Amazon API Gateway が、API のリソースポリシーをサポート

公式サンプルではAWSアカウントのホワイトリスト、IP範囲のブラックリストがあります。

他にも時間やユーザーエージェント(UA)やユーザーIDなどのキーが用意されていて、各種設定を組み合わせたアクセスコントロールが簡単に設定できます。
AWS Conditions that can be used in API Gateway Resource Policies - Amazon API Gateway

以下、UAとIP範囲のアクセスコントロールを例にメモしておきます。

UAとIP範囲のAND条件によるアクセスコントロール

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "arn:aws:execute-api:ap-northeast-1:XXXXXXXXXXXX:yyyyyyyyyy/*/GET/",
            "Condition": {
               "StringLike": {
                    "aws:UserAgent": "test"
                },
                "IpAddress": {
                    "aws:SourceIp": "ZZ.ZZ.ZZ.ZZ/ZZ"
                }
            }
        }
    ]
}

UAとIP範囲のOR条件によるアクセスコントロール

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "arn:aws:execute-api:ap-northeast-1:XXXXXXXXXXXX:yyyyyyyyyy/*/GET/",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "ZZ.ZZ.ZZ.ZZ/ZZ"
                }
            }
        },
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "arn:aws:execute-api:ap-northeast-1:XXXXXXXXXXXX:yyyyyyyyyy/*/GET/",
            "Condition": {
                "StringLike": {
                    "aws:UserAgent": "test"
                }
            }
        }
    ]
}

最後に

ステージング環境で、Webアクセスは社内からのアクセスに絞りたい、SIM利用のIoTデバイスからはUAによるアクセスに絞りたい場合は、UAとIP範囲のOR条件によるアクセスコントロールが使えそうです。

また、LBで使いたい場合は、API Gateway + NLBの構成も考えられそうです。
Amazon API Gateway でプライベート VPC とのエンドポイント統合をサポート

既存のセキュリティグループだとUAによるアクセスコントロールができないので、非常に使い勝手が良さそうです。

AWS Well-Architected Lens – Serverless Applications まとめ コスト編

アーキテクチャを検討する上で、とても役に立つフレームワークであるAWS Well Archtected Framework。
サーバーレス版が公開されたのでベストプラクティスについてまとめておきます。
https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf

運用編セキュリティ編信頼性編パフォーマンス編コスト編の5回に分けてメモしていきます。

解釈が間違っているかもしれないので、ご注意ください。

SERVCOST 1:最適なラムダメモリ割り当てを決定するための戦略は何ですか?

  • 最良のコスト/パフォーマンスを確保するには、テスト・シナリオに基づく最適なメモリー割り振りが必要
  • メモリのチューニングとタイムアウトの微調整は、パフォーマンスや運用だけでなく、コスト削減にもつながる。
  • メモリを少なくすると、各Lambda関数の実行に時間がかかり、100ミリ秒の請求単位で増分されるため、料金が高くなる可能性がある。
  • AWSは新しいサービスや機能をリリースするため、引き続きコスト効果を確認し最適化を繰り返す必要がある。

SERVCOST 2:ラムダ関数のコードロギングの戦略は何ですか?

  • LambdaはCloud Watch Logsを使用してログを取得できる。ログの取り込みとストレージ量にコストが発生する。
    • 環境変数によって必要なときはいつでも正しいログレベルを設定する。特別にアクティブ化されない限り、ログイングされたログはDEBUGではなくINFOにしておく。
  • ログのコストを削減する方法。
    • AWS LambdaのAmazon CloudWatch Logsグループのログ保持期間を使用する。
    • Amazon S3Amazon ESなどのより費用対効果の高いプラットフォームにログをエクスポートする。

SERVCOST 3:複雑さを軽減するために必要なLambda関数を実行するコード・アーキテクチャーはありますか?

  • 不要なLambdaの実行を避ける。
  • API GatewayやIoTと他のAWSサービスを直接統合すると、Lambdaのコスト増加と、これらのリソース管理を回避できる。
  • Lambdaのコードを最適化する。
  • 不要な呼び出しを避けるケースを検討する。下にいくほどコストやレイテンシを削減することができるが、一番下はRESTful APIの恩恵を受けることはできない。

SERVCOST 4:できるだけ短い時間で実行するようにコードをどのように最適化していますか?

  • 長時間Lambdaを実行する必要がある場合は、Lambda関数で実装する代わりにStep Functionsを使用して待機状態を実装する。
  • データストアやその他のサービス/リソースへの接続を維持するためにグローバル変数を使用してコードを最適化すると、パフォーマンスが向上し、実行時間が短縮され、コストも削減される。

AWS Well-Architected Lens – Serverless Applications まとめ パフォーマンス編

アーキテクチャを検討する上で、とても役に立つフレームワークであるAWS Well Archtected Framework。
サーバーレス版が公開されたのでベストプラクティスについてまとめておきます。
https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf

運用編セキュリティ編信頼性編パフォーマンス編コスト編の5回に分けてメモしていきます。

解釈が間違っているかもしれないので、ご注意ください。

SERVPER 1:サーバレスアプリケーションで最適な容量単位(メモリ、シャード、1秒あたりの読み書き)をどのように選択しますか?

  • Lambdaのデフォルトのメモリ設定とタイムアウト設定は、パフォーマンス、コストに望ましくない影響を及ぼす可能性がある。
  • タイムアウトを平均実行時間よりもはるかに高く設定すると、コードが誤動作したときに長く実行される可能性があり、その結果、コストが高くなり同時実行数の限界に達する可能性がある。
  • 一時的なネットワーキングの問題またはダウンストリームサービスの異常が発生した場合、サーバレスアプリケーションが実行を突然停止させる可能性がある。
  • さらに重要なのはアップストリームサービスを考慮せずに、負荷テストを行わずにタイムアウトを設定し、いずれかのパーツがタイムアウトになるとエラーが発生する可能性がある。

SERVPER 2:サーバーレスアプリケーションのパフォーマンスをどのように最適化しましたか?

  • サーバーレスのアーキテクチャーが成長するにつれ、さまざまなワークロード・プロファイルで共通に使用される特定のメカニズムが存在する。
    • パフォーマンステストにおいても、常にSLAと要求をキープするように、パフォーマンス向上と設計上のトレードオフを考慮する必要がある。
  • パフォーマンスを向上させるために、API Gatewayのキャッシュを有効にすることができる。
  • 同様に、DAXを有効にすることで、読み取り応答を大幅に向上させ、グローバルおよびローカルセカンダリインデックスを改善して、DynamoDBフルスキャン操作を防止する。
  • Lambda関数コード内のグローバルスコープを利用して、Lambdaコンテナを再利用することで、データベース接続とAWSサービスの初期接続と設定の処理に再利用される。
  • Lambda関数は必ずしもVPCにデプロイする必要はない。
  • CPUとネットワークの帯域幅は、Lambda機能用に設定されたメモリ設定に基づいて比例して割り当てられる。
  • 必要に応じてVPCへのアクセスを設定する必要がある。VPCに関数をデプロイするとENIを作成する必要があるため起動時間が増える。
  • Lamba機能がVPCとインターネットにアクセスする必要がある場合は、Lambdaからインターネット上で公開されているすべてのリソースへのトラフィックを許可するために、NATゲートウェイが必要です。
    • 高い可用性とパフォーマンスを実現するために、複数のAZにNATゲートウェイを配置することをお勧めする。

SERVPER 3:サーバーレスアプリケーションのどのコンポーネントVPCに導入するかは、どのように決定しますか?

  • VPC内の他のものにアクセスする必要がある場合はVPC内に作成する。(RDSまたはElasticache)
  • VPC内からインターネット上の公開AWSサービスやリソースにアクセスする必要がある場合はNATを作成する。

SERVPER 4:パフォーマンスのためにラムダコードをどのように最適化していますか?

SERVPER 5:どのようにデータベース接続を初期化していますか?

  • Lambda関数が実行された後、別のLambda関数呼び出しを予期してしばらくの間、ランタイムコンテナを維持します。
  • グローバルスコープを活用する。
    • たとえば、Lambda関数がデータベース接続を確立した場合、接続を再確立する代わりに、元の接続が後続の呼び出しで使用される。
    • Lambda関数ハンドラコードの外側でデータベース接続やその他のオブジェクト/変数を宣言することで、関数が再度呼び出されたときに最適化される。
  • コードにロジックを追加して、接続を作成する前に接続がすでに存在するかどうかを確認できる。

AWS Well-Architected Lens – Serverless Applications まとめ 信頼性編

アーキテクチャを検討する上で、とても役に立つフレームワークであるAWS Well Archtected Framework。
サーバーレス版が公開されたのでベストプラクティスについてまとめておきます。
https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf

運用編セキュリティ編信頼性編パフォーマンス編コスト編の5回に分けてメモしていきます。

解釈が間違っているかもしれないので、ご注意ください。

SERVREL 1:ピークワークロードのサーバレス制限を考慮しましたか?

  • サービスの不正使用から守るために、デフォルトのサービス制限がある。
    • 適切に制限を監視しないと、サービスの劣化または抑制をもたらす可能性がある。
    • 多くの制限はソフトリミットであり、それを超える場合は上限緩和申請することができる。
  • AWS Trusted Advisorを使用して、サービスが制限の80%を超えているかどうかを検出できる。
  • また、ワークロードの超過が予測される場合は、事前に制限を引き上げることもできる。
    • 制限を引き上げる場合は、スケール対応したりサービス不能攻撃を吸収するために、サービス制限と最大使用量との間に十分なギャップがあることを確認する。
    • 関連するすべてのアカウントとリージョンでこれらの制限を考慮する必要がある。
  • さらに、Lambdaの同時実行制限機能を使用して、ビジネスクリティカルなパスを分離し、予期しないイベントの負荷が他のリソースに影響しないようにする必要がある。
    • プロファイル、脅威モデル、および組織構造によって、異なるアカウントのワークロードを分離することも推奨される。
    • 同時実行数の管理 - AWS Lambda
  • サーバレスアプリケーションがスパイクするかどうかに関わらず、非同期パターンに従って、サーバレスアプリケーションをより弾力性のあるアプリケーションに設計する。

SERVREL 2:サーバーレスアプリケーションへのアクセスレートをどのように規制していますか?

  • リクエストの数が、バックエンドで処理できる処理数を超えると、サービスAPIが影響を受ける可能性がある。
  • 契約プランによってアクセスパターンをコントロールするには、APIレベルでスロットリングを有効にする必要がある。
    • https://image.slidesharecdn.com/20161116awsblackbeltapigateway-161116105747/95/aws-black-belt-online-seminar-2016-amazon-api-gateway-44-638.jpg?cb=1479431239
  • API内の適切なHTTPステータスコード(スロットル用の429など)を返すことで、それに応じてリトライを行いスロットリングされたアクセスを処理するのに役立つ。
    • https://image.slidesharecdn.com/20161116awsblackbeltapigateway-161116105747/95/aws-black-belt-online-seminar-2016-amazon-api-gateway-49-638.jpg?cb=1479431239
  • より細かい制御は使用量プランとAPIキー発行で可能となる。疑わしいリクエストをしている場合、管理者が簡単にアクセスを切断することもできる。
    • https://image.slidesharecdn.com/20161116awsblackbeltapigateway-161116105747/95/aws-black-belt-online-seminar-2016-amazon-api-gateway-43-638.jpg?cb=1479431239
  • APIキーを取得する一般的な方法は、開発者ポータルを用意する方法です。これにより、サービスプロバイダとして、コンシューマとリクエストに関連付けられた追加のメタデータが提供される。
    • アプリケーション、連絡先情報、ビジネスエリア/目的をキャプチャし、DynamoDBのようなデータストアに格納します。
    • これにより、コンシューマーの追加検証とIDによるロギングのトレーサビリティが提供され、コンシューマーに変更のアップグレード/問題を連絡することができる。

SERVREL 3:サーバーレスのアーキテクチャー内での非同期呼び出しとイベントに関する戦略は何ですか?

  • 非同期呼び出しは、HTTPレスポンスの待ち時間を短縮する。イベントドリブンアーキテクチャにより、非同期でコードを実行できるため、待ち時間が制限される。
  • フロントエンドシステムは、全体の実行が完了するまでブロックするのではなく、最初のリクエストでジョブIDを受け取り、そのステータスをポーリングする。
    • イベントループ、並行処理技術を使用してアプリケーションの一部を遅延ロードすることによって、フロントエンドをより効率的にすることができる。
  • また、フロントエンドは、カスタムリトライとキャッシングによってより堅牢になるため、非同期呼び出しでは重要な要素になる。
    • 許容可能なSLA内で応答が受信されなかった場合、異常、一時的な状態、ネットワーキング、または劣化した環境によって発生した場合は、途中のリクエストを停止することができる。
  • また、同期呼び出しが必要な場合は、実行全体がAPI Gatewayの最大タイムアウトを超えないようにし、その調整が外部サービス(AWSステップ関数など)によって行われていることを確認することをお勧めする。
    • リクエストライフサイクルに沿って発生する可能性があります。

SERVREL 4:サーバーレスアプリケーションのテスト戦略は何ですか?

  • テストは、通常、ユニットテスト、統合テスト、受入れテストによって行われる。堅牢なテスト戦略を開発することで、さまざまな負荷や状況下でサーバレスアプリケーションをエミュレートできる。
  • 単体テストはサーバーレスではないアプリケーションと異なるものであってはならず、必要な変更を加えずにローカルで実行できる。
  • 統合テストは、制御できないサービスを模倣すべきではありません。実稼働環境とまったく同じ環境を提供できるため、実際のサービスを使用する。
  • 受け入れまたはエンドツーエンドテストは固有の推奨事項はありません。
  • 一般に、AWS Marketplaceで利用可能なLAmbdaおよびサードパーティのツールは、パフォーマンステストのコンテキストでテストハーネスとして使用できる。
  • パフォーマンステスト中の注意点を次に示す。
    • 呼び出された最大メモリなどのメトリクスは、CloudWatchログで確認できる。メトリクスは、最適なメモリーと適切なタイムアウト値を示す場合がある。
    • Lambda機能がVPC内で実行されている場合は、サブネット内の使用可能なIPアドレス空間に注意する。
    • モジュール化されたコードをハンドラの外部にある別々の関数に作成することにより、より多くのユニットテスト可能な関数が可能になる。
    • Lambda関数の静的コンストラクタ/初期化コード(つまり、グローバルスコープ、ハンドラの外側)で参照される外部化された接続(リレーショナルデータベースへの接続プールなど)を確立すると、Lambda実行の場合に外部接続のしきい値に到達しない環境が再利用される。
  • それに応じてDynamoDBの読み書きテーブルのスループットを調整し、パフォーマンステストサイクル全体のスループットの変化に対応するように自動スケーリングを設定する。

SERVREL 5:サーバレスアプリケーションにどのように弾力性を持たせていますか?

  • 変更が失敗した場合に以前のバージョンに戻すことができると、サービスの可用性が保証される。
  • まず、監視メトリクスを配置する必要がある。環境負荷の「正常」状態を判断し、CloudWatchで適切なメトリクスとしきい値パラメータを定義して、「正常でない」状態を過去のデータに基づいて判断する。
  • また、デプロイを監視し、自動化されたアクションを実装する。Lambda機能のバージョニングやAPIバージョンなどの機能を使用すると、デプロイが失敗した場合に以前の状態に戻すことができる。
  • サーバーレスアプリケーションの特定の部分は、pub / subなどのパターンを使用して、イベント駆動型のさまざまなコンポーネントへの非同期呼び出しによって指定される。
  • 非同期呼び出しに失敗した場合は、できるだけキャプチャしてリトライする必要がある。そうしないとデータが失われる可能性があり、ユーザーエクスペリエンスが低下する可能性がある。
  • Lambda関数については、Lambdaクエリにリトライロジックを組み込んで、スパイキーなワークロードがバックエンドを圧倒しないようにする。
    • また、Lambdaロギングライブラリを活用して、CloudWatchログにエラーを追加しカスタムメトリクスとして取得する。
  • AWS SDKは、ほとんどの場合に、デフォルトでバックオフとリトライのメカニズムを提供している。しかし、ニーズに合わせて調整するべきです。
  • AWS X-RayおよびサードパーティAPM(Application Performance Monitoring)ソリューションを使用すると、分散トレースでスロットリングを識別したり、待ち時間にどのような影響が生じるのかを把握できる。
  • 失敗する可能性のある非同期呼び出しの場合、個々のLambda関数に対してデッドレターキュー(DLQ)を有効にし、専用のDLQリソース(Amazon SNSAmazon Simple Queue Service(Amazon SQS)を使用)を作成することをお勧めする。
  • 可能な限り、Step Functionsを使用して、サーバーレス・アプリケーション内のカスタム試行/キャッチ、バックオフ、およびリトライの量を最小限に抑える必要がある。
  • さらに、PutRecords(Kinesis)やBatchWriteItem(DynamoDB)などの操作では、部分的な障害が発生した場合でも正常に返されるので、常に応答を検査し、プログラムで対処する必要がある。
  • トランザクションベースの同期処理の場合、Sagaパターンで説明されているように、アプリケーションのロジックを分離し単純化したStep Functionsを使用することによってロールバックを達成できる。

AWS Well-Architected Lens – Serverless Applications まとめ セキュリティ編

アーキテクチャを検討する上で、とても役に立つフレームワークであるAWS Well Archtected Framework。
サーバーレス版が公開されたのでベストプラクティスについてまとめておきます。
https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf

運用編セキュリティ編信頼性編パフォーマンス編コスト編の5回に分けてメモしていきます。

解釈が間違っているかもしれないので、ご注意ください。

SERVSEC 1:サーバーレスAPIへのアクセスをどのように承認し、認証しますか?

SERVSEC 2:Lambda機能がアクセスできるAWSサービスについて、どのように境界を強制していますか?

  • Lambda関数がアクセスできるものに関しては、最小特権アクセスに従うこと、指定された操作を実行するために必要なものだけを厳密に許可することが推奨される。
  • API Gateway APIキー機能はセキュリティのメカニズムではなく、メータリングのために使用される。APIキーごとの使用状況を追跡することができる。
    • https://image.slidesharecdn.com/20161116awsblackbeltapigateway-161116105747/95/aws-black-belt-online-seminar-2016-amazon-api-gateway-43-638.jpg?cb=1479431239
  • カスタムオーソライザを使用する場合、クレデンシャル情報や機密データをクエリ文字列のパラメータやヘッダーに使用することはお勧めしない。
  • 複数Lambda関数でIAMを共有することは、最低特権アクセスに違反する可能性があるので注意。

SERVSEC 3:サーバーレスのアプリケーションログをどのように分析していますか?

  • CloudWatchのメトリクスフィルタを利用すると、サーバレスアプリケーションの標準出力を、正規表現のパターンマッチングによってカスタムメトリクスに変換して件数をグラフ化することが可能です。
    • さらに、アプリケーションのカスタムメトリクスに基づいてCloudWatchアラームを作成することで、アプリケーションの動作を素早く把握できる。
  • AWS CloudTrailログは、監査とAPI呼び出しの両方に使用する必要がある。
  • トラブルシューティングの際に、ステージ全体ではなく個々のメソッドに対してAPIGatewayログを有効にすることを検討する。
  • サーバーレスアプリケーションの設計によっては、機密データが含まれている場合があるので注意する。
  • Lambda関数のコード内でCloudWatchに対するAPI呼び出しを行うと、不要なデータがログに取り込まれる可能性がある。
  • API Gatewayはリクエスト/レスポンスの全てを記録することがあり、コンプライアンス要件に違反する可能性がある。ロギングを有効にする前に、コンプライアンスチームに確認する。

SERVSEC 4:サーバーレスアプリケーション内の依存関係の脆弱性をどのように監視していますか?

  • アプリケーション依存関係の脆弱性スキャンに関しては、CI / CDパイプライン内に統合可能なOWASP Dependency Checkなどの商用ソリューションとOSSの両方が多数存在する。バージョン管理ソフトウェアリポジトリの一部として、AWS SDKを含むすべての依存関係を含めることが重要です。

SERVSEC 5:VPCアクセスの場合、AWS Lambda関数がアクセスできるネットワーク境界をどのように強制していますか?

  • Lambdaは、VPN接続を介してAWSの外部にあるリソースにアクセスするように設定できる。
  • セキュリティグループとNACLがネットワーク境界の基礎になる。コンプライアンス上の理由によりアウトバウンドトラフィックのフィルタリングが必要な場合、プロキシを配置することが考えられる。
  • コードレベルでのみネットワーク境界を実施することはお勧めしない。

SERVSEC 6:サーバレスアプリケーションで機密データをどのように保護していますか?

  • API Gatewayは、すべての通信でSSL/TLSを使用する。URLの一部であるリクエストパスとクエリ文字列は暗号化されないので注意が必要です。
  • 暗号化されたHTTPペイロードAPI GatewayやLambdaから受信すると複合されるので、標準出力に出力された場合、機密データがCloudWatchログを介して誤って公開される可能性があるので注意。(ここ自信なし)
  • 不正な入力や傍受された入力は、システムへのアクセスを得るか、誤動作させる攻撃として使用することができる。
  • 機密データは、すべてのレイヤーで常に保護される必要がある。
  • API Gateway, Lambdaに関して、機密データはデータ操作前にクライアント側で暗号化されるか、HTTP POST要求の一部として送信される必要がある。ヘッダを暗号化することも含まれる。
    • これにより、CloudWatchログのデータが公開された場合のデータ漏洩が防止される。
  • 暗号化されたデータはDynamoDB、Amazon ES、またはAmazon S3のいずれかに永続させる。
  • 機密データが暗号化されていないAPI Gatewayでのログ記録を有効にすることもお勧めしない。API Gatewayのログを有効にする前に、コンプライアンスチームと相談してください。

SERVSEC 7:入力検証に関するあなたの戦略は何ですか?

AWS Well-Architected Lens – Serverless Applications まとめ 運用編

アーキテクチャを検討する上で、とても役に立つフレームワークであるAWS Well Archtected Framework。
サーバーレス版が公開されたのでベストプラクティスについてまとめておきます。
https://d1.awsstatic.com/whitepapers/architecture/AWS-Serverless-Applications-Lens.pdf

運用編セキュリティ編信頼性編パフォーマンス編コスト編の5回に分けてメモしていきます。

解釈が間違っているかもしれないので、ご注意ください。

SERVOPS 1:サーバレスアプリケーションの異常をどのように監視し、対応していますか?

  • サーバーレス・アーキテクチャーの性質上、分散トレースを行うことは基本。
  • サーバーレスアプリケーションを変更すると、展開、変更、およびリリース管理が必要。
  • AWS X-Rayの分散トレース機能を使用することで、可視化されたサービスマップから迅速にトラブルシューティング行う。X-Rayは、パフォーマンスの低下を特定し、レイテンシ分布を含む異常を迅速に理解できる。
  • 個別レベルと集約レベルのアラームの設定が必要。
    • 個別レベルには以下のメトリクスが含まれる。
      • Lambda: Duration
      • API Gateway: IntegrationLatency
    • 集約レベルには以下のメトリクスが含まれる。
      • Lambda: Throttling, Errors
      • Step Functions: ActivitiesTimedOut, ActivitiesFailed, ActivitiesHeartbeatTimedOut
      • API Gateway: 5XXError, 4XXError
  • ビジネスとアプリケーションの洞察を捕捉するために、CloudWatchのカスタムメトリクスを使用する。

SERVOPS 2:変更の影響を最小限に抑えながら、サーバーレスアプリケーションをどのように進化させていますか?

  • API Gateway ステージ変数は、リリースするときに変更の数を最小限に抑えるのに役立つ。たとえば、ステージ変数は$ LATESTではなくLambdaのエイリアス名を参照できる。
  • AWS SAMを使用して、サーバレスアプリケーションをパッケージ化、デプロイ、モデリングする。また、SAM Localを使用すると、Lambda関数をローカルに開発する際のデバッグサイクルを高速化できる。
  • Lambda環境変数は、ソースコードと設定を分離するのに役立つ。たとえば、Lambda関数内で呼び出されたリソース名を変更する場合は、コードではなく環境変数のみを変更する。
  • 複数サーバーにまたがって共有している構成や鍵を制御する場合、環境変数に対してAmazon EC2システムマネージャ(SSM)のパラメータストア機能を検討する。パラメータストアで追加の遅延が発生する可能性があるため、SSMパラメータストアまたは環境変数の使用を決定する際にベンチマークを実行する必要がある。
  • 注: A/Bテストは、LambdaのTraffic Shifting機能で実現できる。変更時の停止時間をゼロにすることを推奨。
  • SAM Localは、パフォーマンスの目安としては使用しない。AWS環境では、計算リソースとネットワークレイテンシーが大きく異なるため、別途テストが必要。
  • API Gatewayステージ変数とLambdaエイリアス/バージョンは、ステージを分けるために使用してはいけない。これは、デプロイ単位のモニタリングの可視性を低下し、ツールの複雑さが増す。(ここ自信なし)
  • X-Rayは、AWS Lambdaの初期化や使用されているサービスの絞り込みなど、サービスメトリクスの詳細を提供している。CloudWatchのメトリクスだけでなく、X-Rayも使用する。これは、異常を特定して対応する際に役立つ。