やーまんぶろぐ

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

AWS認定プログラム ソリューションアーキテクト – プロフェッショナルに合格しました

AWS認定プログラム ソリューションアーキテクト – プロフェッショナルに合格しました。

合格に必要な情報をまとめておきます。

AWS認定プログラムについて

こちらにまとめています。模擬試験が2160円、本試験が32400円。
yamano3201.hatenablog.jp

AWS活用資料集

一番まとまってるしわかりやすいので、ここから入るとわかりやすいです。
AWS クラウドサービス活用資料集 | AWS

無料問題集

ある程度勉強したら問題集に取り組みます。
yamano3201.hatenablog.jp

模擬試験

模擬試験は悪問が多いそうです。受けなくても良いかもしれません。
【AWS認定】ソリューションアーキテクト プロフェッショナル(AWS CSA-Pro)に合格してきた【英語重要】

公式リンク

自分用のメモになりますが、受験前に一読するとヒントになると思います。
yamano3201.hatenablog.jp

有料サービス

個人的にはUdemyのPractice Testがおすすめです。
https://www.udemy.com/aws-certified-solutions-architect-professionalpractice-test/learn/v4/overview

80問×3で240問が買い切りです。
日本語に対応していないですが、解説もあり充実していました。

私の場合、試験の2週間前から1日20-30問くらいを解きながら勉強しました。

当日

170分の試験はけっこうつらかったです。

半分くらい過ぎたところから、明らかに頭が回らなくなって焦りました。

午後からの試験でしたが、
直前まで集中して勉強していたのが裏目に出てしまいました。

結果

結果はすぐに画面で確認することができます。
私の場合は80%でした。

総合評点: 80%

トピックレベルスコアリング:
1.0  High Availability and Business Continuity: 83%
2.0  Costing: 100%
3.0  Deployment Management: 87%
4.0  Network Design: 75%
5.0  Data Storage: 66%
6.0  Security: 75%
7.0  Scalability & Elasticity: 76%
8.0  Cloud Migration & Hybrid Architecture: 100%

所感

どんなに勉強しても受かるか心配だったのですが、
UdemyのPracticeTestで3回とも70%を超えたのが自信になりました。

有料ですが、一度は問題を解いてみるのがおすすめです。

AWS認定試験を受ける前に確認すべき公式リンク一覧 (ソリューションアーキテクト – プロフェッショナル)

AWS 認定ソリューションアーキテクト – プロフェッショナルを受ける前に確認すべき公式リンク一覧をまとめました。
aws.amazon.com

既にAWSについて詳しく知っている人向けの確認用のメモです。

EC2

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html

  • タグ
    • 環境ごとのEC2の保護にタグが使える

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html

  • シングルルート I/O 仮想化 (SR-IOV)
    • 高性能ネットワーキング機能

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html

  • HVM AMI
    • ハードウェアへの高速なアクセスを可能にするハードウェア拡張を利用できる

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html

  • EBS暗号化
    • 以下の暗号化を行う
      • ボリューム内の保存データ
      • ボリュームとインスタンスの間で移動されるすべてのデータ
      • ボリュームから作成されたすべてのスナップショット
      • それらのスナップショットから作成されたすべてのボリューム

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html

  • 複数ENI、複数EIP
    • 管理用ネットワーク作成

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-capacity.html

  • InsufficientInstanceCapacityエラー
    • リスタートか再作成

AutoScaling

http://docs.aws.amazon.com/autoscaling/latest/userguide/as-suspend-resume-processes.html

  • スケーリングプロセスの中断

CloudWatch

http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html

  • メトリクスとディメンションのリファレンス

ELB

CLBの問題が多い。今ならALB, NLBを使うのが普通。

http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

  • スッティキーセッション

VPC

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html

  • NACL
    • CIDR の範囲を指定してインバウンド、アウトバウンドのACLを設定

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html

  • VPC Peering
    • 2 つの VPC 間でプライベートなトラフィックのルーティングが可能
    • 今ならNLBを使ってPrivateLink接続のほうがシンプル

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html

  • DHCP オプションセット
    • 作成後に変更できないので、新しいセットを作成して新しく関連付けする

Route53

http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html

  • DNS フェイルオーバー
    • 異常になったらDNSレベルでフェイルオーバーができる

http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html

S3

http://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html

  • SSE
    • Amazon S3 で管理されたキーによるサーバー側の暗号化 (SSE-S3) の使用
    • AWS KMS で管理されたキーによるサーバー側の暗号化 (SSE-KMS) の使用
    • お客様が用意したキーによるサーバー側の暗号化 (SSE-C) を使用

http://docs.aws.amazon.com/AmazonS3/latest/dev/cors.html

  • Cross-Origin Resource Sharing (CORS)
    • クロスオリジンリクエストを明示的に有効にする

http://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html

  • 署名付き URL
    • 署名付き URL の作成者がそのオブジェクトをアップロードする権限が必要

http://docs.aws.amazon.com/AmazonS3/latest/dev/qfacts.html

  • マルチパートアップロード

RDS

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html

  • マルチ AZ
    • 異なるアベイラビリティーゾーンに同期スタンバイレプリカが自動的にプロビジョニングされる

DynamoDB

http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html

  • グローバルセカンダリインデックス
    • 1 つ以上の グローバルセカンダリインデックス を作成して、そのインデックスに対して Query リクエストを発行できる

RedShift

http://docs.aws.amazon.com/redshift/latest/mgmt/working-with-snapshots.html

  • スナップショット
    • 自動と手動の 2 つのタイプがある

http://docs.aws.amazon.com/redshift/latest/dg/c_workload_mngmt_classification.html

  • ワークロード管理 (WLM)
    • デフォルトで、同時実行レベルが 5の 1 つのキューと、同時実行レベルが 1 のスーパーユーザーキューを設定する

http://docs.aws.amazon.com/redshift/latest/mgmt/purchase-reserved-node-instance.html

  • リザーブドノード
    • プロジェクトの評価フェーズ、または概念実証を開発する場合はオンデマンドを使う

Kinesis

http://docs.aws.amazon.com/streams/latest/dev/introduction.html

  • Kinesis Data Streams
    • データレコードの大量のストリームをリアルタイムで収集し、処理する

IAM

http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

  • リクエストの許可または拒否
    • デフォルトでは、すべてのリクエストが拒否
    • 明示的な許可はこのデフォルトに優先
    • 明示的な拒否はすべての許可に優先

http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html

  • STS
    • AWS リソースへのアクセスを制御できる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供する

http://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html

  • AWS CloudTrail による IAM イベントのログ記録
    • 認証された AWS API 呼び出しおよび AWS サインインイベントもログに記録する

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html

  • ウェブ ID フェデレーション
    • IdPを使用してサインインし、認証トークンを受け取って、DynamoDBにアクセスする

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html

  • IAMロール
    • パスワードやアクセスキーが不要

http://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

  • クロスアカウントアクセス
    • 特定のアカウントにあるリソースを別のアカウントのユーザーと共有できる

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html

  • 一時的なセキュリティ認証情報のアクセス権限を無効
    • 一時的なセキュリティ認証情報は、期限が切れるまで有効で、取り消すことはできない
    • ただし、アクセス権限は、AWS リクエストのたびに評価されるため、アクセス権を変更することで認証情報を取り消すのと同等の効果を得ることができる

OpsWorks

http://docs.aws.amazon.com/opsworks/latest/userguide/common-issues-troubleshoot.html

  • UnrecognizedClientExceptionエラーの原因
    • IAM ユーザーまたはロール削除
    • ボリュームまたはストレージの設定編集
    • 手動でEIP追加

http://docs.aws.amazon.com/opsworks/latest/userguide/best-practices-updates.html

http://docs.aws.amazon.com/opsworks/latest/userguide/layers-elb.html

http://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-events.html

  • ライフサイクルイベント
  • Setup, Configure, Deploy, Undeploy, Shutdown

CloudFormation

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-findinmap.html

  • Fn::FindInMap
    • マッピングのキーに対応する値を返す
    • 例、regionごとのAMIを定義

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html

  • IAMロール
    • InstanceProfile リソースは、IAM ロールの外側で指定
    • Roles プロパティで対応するロール名を指定することによってそのロールを参照

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-waitcondition.html

  • WaitCondition
    • スタックの作成の外部での設定アクションを使ったスタックリソース作成を調整するため
    • 設定プロセスのステータスを追跡するため

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/conditions-section-structure.html

  • Conditions
    • 例、本稼働用のスタックの場合に動作を変える

CloudHSM

http://docs.aws.amazon.com/cloudhsm/latest/userguide/generate_ssh_key.html

  • CloudHSM
    • 暗号化オペレーションを処理し、暗号化キーの安全なストレージを提供するコンピューティングデバイス

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を使用することによってロールバックを達成できる。