Serverless Application Lens - AWS Well-Architected Framework - ⻄⾕ 圭介(@Keisuke69) シニアソリューションアーキテクト アマゾン ウェブ サービス ジャパン株式会社

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Keisuke Nishitani (@Keisuke69) Manager, Senior Solutions Architect Amazon Web Service Japan K.K Everything will be serverless. ⾳楽 x キャンプ x マンガ フジロッカー ブログ: https://www.keisuke69.net/

AWS Well-Architected フレームワーク AWS が蓄積したクラウドのアプリケーション設計におけるベストプラクティス https://aws.amazon.com/jp/architecture/well-architected/ 運⽤の 優秀性 セキュリ ティ 信頼性 パフォー マンス効率 コスト 最適化 ⼀般的なベストプラクティス IoT 向け レンズ HPC 向け レンズ サーバーレス アプリケーション向け レンズ

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. ホワイトペーパ パフォーマンス 効率 コスト 最適化 運⽤の 優秀性 セキュリティ 信頼性 IoT HPC サーバーレス アプリケーション フレームワーク全体 （英語＆⽇本語） 5 つの柱ごと （英語のみ） 3 つのレンズごと （⼀部英語のみ）

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

定義 • サーバーレスのワークロードを構築する際に考慮すべき領域 • コンピューティングレイヤー • ビジネス ロジックがデプロイおよび実⾏されるランタイム環境 • AWS Lambda • Amazon API Gateway • AWS Step Functions • データレイヤー • ビジネス ロジックが必要とする状態を保存するための安全なメカニズムを提供 • Amazon DynamoDB • Amazon Simple Storage Service (S3) • Amazon Elasticsearch Service • AWS AppSync

定義 • メッセージングおよびストリーミングレイヤー • コンポーネント間の通信およびストリーミングデータのリアルタイム分析と処理を管理 • Amazon Simple Notification Service (Amazon SNS) • Amazon Kinesis Data Streams • Amazon Kinesis Data Analytics • Amazon Kinesis Data Firehose • ユーザー管理とIDレイヤー • インターフェイスの外部顧客と内部顧客の両⽅に ID、認証、認可を提供 • Amazon Cognito

定義 • エッジレイヤー • プレゼンテーションレイヤーおよび外部顧客への接続を管理 • 異なる地理的場所に居住する外部顧客への効率的な配信 • Amazon CloudFront • システムのモニタリングとデプロイ • システムモニタリングレイヤー: メトリクスを通じてシステムの可視性を管理 • Amazon CloudWatch • AWS X-Ray • デプロイレイヤー: リリース管理プロセスを通じてワークロードの変更を昇格させる⽅法を 定義 • AWS Serverless Application Model

定義 • デプロイアプローチ デプロイ コンシューマーの影響 ロールバック 適したイベントモデル デプロイ速度 すべてを⼀度に実⾏ すべてを⼀度に実⾏ 古いバージョンを再デプロ イ 同時実⾏数が少ないもの 即時 ブルー/グリーン 前もってあるレベルの本番 環境テストですべてを⼀度 に実⾏ トラフィックを以前の環 境に元に戻す 中程度の同時実⾏ワーク ロードでの⾮同期および同 期のイベントモデル 数分 ~ 数時間の検 証を⾏ い、その後すぐに顧客にも 対応する Canary/Linear 1~10% の⼀般的な初期ト ラフィックシフト、その後 段階的に増加、または⼀ 度にすべて増加 トラフィックの100%を 以前のデプロ イに戻す 同時実⾏性の⾼いワーク ロード 数分~数時間

Lambdaバージョン管理 個々のLambda関数に対して 1 つ以上の変更不可能なバージョンを発⾏可能 以前のバージョンは変更不可になる Lambda関数の各バージョンには⼀意のARNが付与される Lambdaエイリアスは、開発、ベー タ、本稼働など、Lambda関数に様々な バリエーションを与える エイリアスと特定のバージョンを紐付けられる 新しいバージョンをプロダクションに昇格させるときにより安全なデプロイが可能 静的にエイリアスを指定しておくことで変更を少なくすることができる 例） API Gatewayとの統合で本番稼働⽤エイリアスのARNを指定 本番稼働⽤エイリアスは特定のLambda バージョンを指している

設計の原則 スピーディ、シンプル、単数 => 関数は簡潔で短く、単⼀の⽬的のものにする 合計リクエストではなく同時リクエストを検討する => 同時実⾏に基づいて評価する 共有なし => 関数のランタイム環境と基盤となるインフラストラクチャは短命であり、ローカルリソースの保証 はない ハードウェアアフィニティがないと仮定する => ハードウェア依存する実装は⾏わない ステートマシンでオーケストレーション => トランザクションのオーケストレーションにステートマシンを使⽤ イベントを⽤いたトランザクションのトリガ => ⾮同期なイベント動作 失敗と重複を考慮した設計 => リクエスト/イベントは、失敗および複数回実⾏される可能性がある。冪等性の 担保と適切なリトライ実装

シナリオ RESTful Microservices Alexa スキル モバイルバックエンド ストリーム処理 ウェブアプリケーション

RESTful Microservices 特徴 • レプリケートが簡単で、⾼いレベルの耐障害性と可⽤性を備える • プラットフォームでできる限りマネージドサービスを活⽤ • セキュリティやスケーラビリティなど、⼀般的なプラットフォームの管理に伴う⼿間のかかる作業が 軽減 注意事項 • API Gatewayのログ記録を活⽤して可視性を⾼める • 地理的に変化する可能性がある⼀般的な顧客の所在地を理解する • 顧客の⼊⼒リクエストがデータベースのパーティション化⽅法に与える影響を理解する • セキュリティフラグとなる異常な動作のセマンティクスについて • エラー、レイテンシー、キャッシュヒット / ミスを理解して設定を最適化する

Microservices

Alexaスキル 特性 • インスタンスやサーバーを管理せずに、完全なサーバーレスアーキテクチャを作成 • コンテンツとスキルをできるだけ疎結合化 • APIとして公開されている魅⼒的な⾳声体験を提供して、さまざまな Alexa デバイス、リージョン、 ⾔語にわたる開発を最適化 • ユーザーの需要に合わせてスケールアップおよびスケールダウン 注意事項 • Alexa Smart Homeからのメッセージを検証 • Lambda関数のタイムアウトが8秒未満で、その期間内にリクエストを処理できることを確認 • DynamoDBのベストプラクティスに従う。必要な読み取り / 書き込みキャパシティーが分からない 場合は、オンデマンドテーブルを使⽤する • スキルベータテストツールを使⽤して、スキル開発に関する早期フィードバックを収集 • ASK CLI を使⽤して、スキルの開発とデプロイを⾃動化

Alexaスキル

モバイルバックエンド 特性 • クライアントからアプリケーションデータの動作をコントロールし、API から必要なデ ータを明⽰的に選択 • ビジネスロジックをモバイルアプリケーションからできるだけ疎結合化 • 複数のプラットフォームにわたる開発を最適化するためビジネスロジックはAPI化 • マネージドサービスを活⽤して、⾼いレベルのスケーラビリティと可⽤性を提供 • モバイルバックエンドのコストを最適化 注意事項 • Lambda 関数のリソース使⽤を最適化 • AWS AppSync で GraphQL スキーマから⾃動的にプロビジョニングすることを検討 • AWS AppSync のサーバー側データキャッシュを使⽤ • Amazon Elasticsearch Serviceドメインを管理するときは、ベストプラクティスに従う • リゾルバーで設定された AWS AppSyncのきめ細かなアクセスコントロールを使⽤して、必要に応じて GraphQLリクエストをユーザ単位またはグループレベルにフィル タリング

モバイルバックエンド

ストリーム処理 特性 • ストリーミングデータを処理するためのインスタンスやサーバを管理することなく、完全なサーバーレスアーキテクチャを作成 • Amazon Kinesis Producer Library (KPL) を使⽤して、データの取り込みを処理 注意事項 • Kinesis ストリームのベストプラクティスに従って、より⾼い取り込みレートに対応 • ストリーム処理の同時実⾏は、シャードの数と並列化係数によって決まる • 重複したレコードが発⽣する可能性があるので、コンシューマー/プロデューサーで再試⾏とべき等性を実装 • Kinesis Data Firehoseを活⽤して、データを継続的にAmazon S3、Amazon Redshift、または Amazon Elasticsearch Serviceにロード • Kinesis Data Analyticsを活⽤して、標準 SQLでストリーミングデータのクエリを実⾏し、その結果のみをAmazon S3などに ロード • Lambda の最⼤再試⾏回数、最⼤レコード期間、関数エラーに対するバッチの⼆分化、 および失敗時の送信先エラーコント ロールを使⽤して、より弾⼒性のあるストリーム処理アプリケーションを構築

ストリーム処理

Webアプリケーション 特性 • ⾼いレベルの弾⼒性と可⽤性を備えた、数分でグローバルに展開できてスケーラブル • 適切な応答時間で⼀貫したユーザーエクスペリエンスを実現 • できる限りマネージド型サービスを活⽤ • 需要に応じたコスト最適化 注意事項 • AWSにサーバーレスウェブアプリケーションのフロントエンドをデプロイするためのベストプラクティスに従う • SPAの場合、AWS Amplify コンソールを使⽤ • 認証と認可に関する推奨事項については、セキュリティの柱を参照 • ウェブアプリケーションバックエンドに関する推奨事項については、RESTful マイクロサービスのシナリオを参照 • パーソナライズされたサービスを提供するウェブアプリケーションの場合、API Gateway の使⽤量プランと Amazon Cognito ユーザープールを活⽤して、さまざまな ユーザーがアクセスできる範囲を絞り込む

Webアプリケーション

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

ベストプラクティス メトリクスとアラート • ビジネスメトリクス • カスタマーエクスペリエンスメトリクス • システムメトリクス • 運⽤メトリクス • CloudWatch アラームを個々のレベルと集計レベルの両⽅で設定 ⼀元化され構造化されたログを記録する • アプリケーションロギングを標準化して、トランザクション、相関識別⼦、コンポーネント 間のリクエスト識別⼦、およびビジネス上の成果に関する運⽤情報を出⼒

ベストプラクティス 分散トレース AWS X-Rayを使⽤したアクティブトレース テスト 単体テストは普通のアプリケーションと変わらない 結合テストはサービスに変更があって予期しない結果が⽣じる可能性があるため、モックやシ ミュレータではなく実環境を利⽤する デプロイ IaCとフレームワークを使⽤して隔離されたステージとAWSアカウント間にデプロイ 本番環境へのデプロイは、⼀⻫切り替えではなくCanaryまたはLinearデプロイを優先し、新し い変更が徐々にエンドユーザーに適⽤されるようにする

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

ベストプラクティス Identity and Access Management APIへのアクセスはAPI Gatewayで利⽤可能な４つのメカニズムを⽤いてコントロール • AWS_IAM 認証 • Amazon Cognito のユーザープール <= IdPがない場合 • API Gateway Lambda オーソライザー <= 既存のIdPがある場合 • リソースポリシー プライベートエンドポイントとリソースポリシーを組み合わせることで、特定のプライベート IP範囲 内の特定のリソース呼び出しに制限 最⼩権限のアクセスに従い、特定の運⽤の実⾏に必要なアクセスのみを許可する 発⾒的統制 CI/CD パイプライン内に統合できる OWASP 依存関係チェックなど、商⽤およびオープンソースのソ リューションを活⽤

ベストプラクティス インフラストラクチャ保護 すべてのレイヤーでトラフィックをコントロール データ保護 • ログに機密データが含まれている可能性があるため、API Gatewayアクセスログを有効に して、必要なもののみを選択 • 機密データはすべて暗号化 • リクエストパスやクエリ⽂字列は暗号化されない • 処理やデータ操作の前に機密データを暗号化 • アプリケーション固有の深いレベルの検証は、個別のLambda関数、ライブラリ、フレーム ワーク、サービスとして実装する • データベースのパスワードや API キーなどのシークレットはSecrets Managerに保存

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

ベストプラクティス スロットリング リクエスト数が処理ロジック / バックエンドで処理できる数を超えると、サービスAPIに影響 する可能性があるため、APIレベルでスロットリングを有効にする ダウンストリームはLambdaほど⾼速にスケールできない可能性があるため、サービスの障害 から特定のワークロードを保護するために、同時実⾏のコントロールが必要 ⾮同期呼び出し キュー、ストリーム、pub/sub、Webhooks、ステートマシン、およびイベントルールマネー ジャを使⽤して⾮同期的に実装 フロントエンドは、全体的な実⾏が完了するまで操作全体をブロックするのではなく、最初の リクエストの⼀部としてリアルタイムの変更をサブスクライブするか、レガシーシステムで は、追加のAPIを使⽤してステータスをポーリング

ベストプラクティス 障害管理 • ⾮同期呼び 出しが失敗した場合は、可能な限りキャプチャして再試⾏する • Lambda Destinationsを使⽤して、エラー、スタックトレース、再試⾏に関するコンテキ スト情報を SNS トピックや SQS キューなどの専⽤のデッドレターキュー (DLQ) に送信 • Step Functions を使⽤して、サーバーレスアプリケーション内のカスタム試⾏ / キャッ チ、バックオフ、再試⾏ロジックの量を最⼩限に抑える • PutRecords (Kinesis) や BatchWriteItem (DynamoDB) などの⾮アトミック運⽤では部 分的な障害が発⽣することがあるため、常にレスポンスを検査し、プロ グラムによって部 分的な失敗に対処 • Kinesis または DynamoDB ストリームから消費する場合は、最⼤レコード期間、最⼤再試 ⾏回 数、失敗時の DLQ、関数エラー時の Bisect バッチなどの Lambda エラー処理コント ロールを 使⽤して、アプリケーションにさらなる弾⼒性を構築 • トランザクションベースで、特定の保証と要件に依存する同期処理の場合、失敗したトラン ザクションのロールバックは、アプリケーションのロジックを疎結合化して簡素化する

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

選択 安定したバーストレートを使⽤して、サーバーレスアプリケーションで パフォーマンステストを実⾏し、その結果を⽤いてキャパシティーユ ニットを調整する。変更後のロードテストを試して、最適な設定を選択 • Lambda: 異なるメモリ設定をテスト • API Gateway: 地理的に分散した顧客にはエッジエンドポイント、同 ⼀リージョン内の場合はリージョナルを使⽤ • DynamoDB: 予測不可能なトラフィックにはオンデマンドを使⽤

最適化 キャッシュの活⽤ API GatewayとAWS AppSync キャッシュ、Amazon DynamoDB Accelerator (DAX) グローバルセカンダリインデックスとローカルセカンダリインデックス API Gatewayのコンテンツエンコーディング クライアントに送信される容量が減るため、データの転送にかかる時間が短縮 Lambda関数のタイムアウトを平均実⾏時間より少し⻑くする ダウンストリームの⼀時的な問題に対象

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

ベストプラクティス 費⽤対効果の⾼いリソース サーバーレスアーキテクチャは、正しいリソース割り当ての観点から管理しやすい キャパシティープランニングの労⼒を効果的に削減 ログ記録の取り込みとストレージ 適切なログ記録レベルを設定し、不要なログ記録情報を削除して、ログの取り込みを最適化 新規および既存の CloudWatch Logs グループのログ保持期間を設定 直接統合 カスタムロジックがなければLambda関数は不要 API Gateway、AWS AppSync、Step Functions、EventBridge、および Lambda Destinations は、 多数のサービスと直接統合でき、より多くの価値と運⽤オーバーヘッドを削減

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

まとめ サーバーレスアプリケーションは、差別化につながらない重労働から開放されるが、 それでも考慮すべき重要な原則がある 信頼性のために、障害経路を定期的にテストすることで、本稼働環境に到達する前に エラーをキャッチできるようにする パフォーマンスの最適化に役⽴つ AWS ツールの活⽤ コスト最適化のために、トラフィック需要に応じてリソースのサイズを設定する 安全なアプリケーションが組織の機密情報資産を保護し、すべてのレイヤーでコンプ ライアンス要件を満たすようにする