Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

developersio-2023-aws-api-publication-checklist

 developersio-2023-aws-api-publication-checklist

developersio-2023-aws-api-publication-checklist

t-kikuchi

July 10, 2023
Tweet

More Decks by t-kikuchi

Other Decks in Technology

Transcript

  1. 2 自己紹介 • 【名前】 菊池 聡規 • 【所属】 AWS 事業本部

    コンサルティング部 • 【キャリア】 金融機関向けオンプレのインフラエンジニア10年ほど→ 自社Webサービスをもつ企業で3年ほど→ クラスメソッドにジョイン • 【Blog】 https://dev.classmethod.jp/author/tooti/
  2. RESTかHTTPか 9 ざっくり比較 比較項目 REST API HTTP API 機能の豊富さ AWS

    WAF,リソースポリ シー,APIキー,キャッシュ等 多機能 機能は少ないがJWTオーソ ライザーなど独自の機能も あり コスト 受信したAPIコール100万回 あたり4.25USD 受信したAPIコール100万回 あたり1.29USD パフォーマンス HTTP APIよりかは高レイテ ンシ 低レイテンシ 参考ブログ:https://dev.classmethod.jp/articles/amazon-api-gateway-http-or-rest/
  3. RESTかHTTPか 10 機能面 比較項目 REST API HTTP API エンドポイント リージョンエンドポイント、リージョン最

    適化、プライベートエンドポイント リージョンエンドポイントのみ セキュリティ AWS WAFとの統合 AWS WAF統合は出来ない アクセス制御 リソースポリシーが使える Cognitoオーソライザーが使える JWTオーソライザーが便利 APIキー APIキー発行、キー毎のレート制限、 使用量把握 APIキー発行機能はない 開発 キャッシュ、リクエスト検証、カスタム ゲートウェイレスポンス 自動デプロイ機能で設定変更するとす ぐ反映 モニタリング X-Ray統合 X-Rayとの統合はなし 統合 NLBとのプライベート統合 ALBとのプライベート統合
  4. RESTかHTTPか 11 コスト面 ◦仮に月1000万回、APIがコールされた場合 ▪ REST API=1000万/100万 * 4.25USD =

    42.5USD = 5,950円 ▪ HTTP API=1000万/100万 * 1.29USD = 12.9USD = 1,806円 月1000万のリクエストはなかなかの規模のサービス。 規模が大きいサービスでなければコストの違いはそこまで気にしなくても。
  5. RESTかHTTPか 12 パフォーマンス面 ◦ 実際どの程度差が出るのか計測してみる ▪ テスト条件 • API Gateway+Lambdaのシンプルな構成

    • API Gatewayは両方リージョナルエンドポイント • Lambdaは固定レスポンスを返すだけ • テストはこちらのソリューションを使って実施(同時実行数100、5分ほど計測) ◦ https://aws.amazon.com/jp/solutions/implementations/distributed-load-tes ting-on-aws/
  6. RESTかHTTPか 13 パフォーマンス面 項目 REST API HTTP API 全リクエスト数 198323

    195449 全リクエストの平均応答時間 0.31617s 0.31997s 50パーセンタイル応答時間(中央値) 0.300s 0.304s 99パーセンタイル応答時間 0.799s 0.807s 全リクエストの平均待ち時間 0.31615s 0.31994s 全リクエストの平均接続時間 0.27873s 0.28417s 全リクエストの平均帯域幅 8.74 Kbps 4.8 Kbps ほぼ同じ性能。一般的にDB層のレスポンス時間のほうが全体に与える影響は大 きい。
  7. キャッシュをどうするか 15 HTTPヘッダ指定によるキャッシュ ◦HTTPの仕様による2つのキャッシュモデル ▪ Expiration Model:レスポンスデータに保持期限があり切れたら再度取得してもら う(代表的ヘッダ:Cache-Controle) ▪ Validation

    Model:今保持しているキャッシュが最新かを問い合わせて、更新され ていた場合のみ取得(代表的ヘッダ:Last-Modified,ETag) ◦ これらはブラウザとCDN、双方に対しての指示である
  8. キャッシュをどうするか 16 API Gateway(REST API)でのキャッシュ ◦TTLを秒単位で指定、TTLが切れるまでAPI Gatewayでキャッシュ(Cache-Control ヘッダmax-ageに近い動き) ◦各パスのメソッド毎にキャッシュ有無を設定できる ◦キャッシュキー(何をもって一意のリクエストとするか)はカスタムヘッダー、URL

    パ ス、クエリ文字列で構成できる ◦クライアントから Cache-Control: max-age=0 ヘッダをつけたリクエストをすればAPI Gateway上のキャッシュを消すことができる ▪ 参考:https://dev.classmethod.jp/articles/api-gateway-invalidatecache-key/
  9. キャッシュをどうするか 17 API Gateway(REST API)でのキャッシュ ◦ リクエストが発生していなくても時間で課金 ◦ オリジンとしては一つでもキャッシュ動作を変えるためにはパスを設定する必要あり ◦

    オリジンのCache-Controlヘッダ等は無視してTTLのみに従いキャッシュを保持 ◦ X-CacheヘッダでAPI Gatewayによるキャッシュかどうかを判断できない
  10. API Gatewayパターンでよいか 21 API Gateway+Lambdaパターン以外の選択肢 ▪ ALB+ECSやApp Runnerなども検討する • スタンダードな構成なので組織やメンバにノウハウがあるケースが多い

    • API Gateway+Lambdaに比べコストは高くなるが、全体の割合から考えるとDB のほうが影響があるケースが多い • API Gateway+Lambdaは専門的知識が必要になる部分が多い ◦ 例えばエンドポイント毎のLambdaの分割方針とか ◦ Lambdaに使うべき(Express.js等の)Webフレームワークはなにかとか ▪ 参考にさせて頂いた記事:https://zenn.dev/intercept6/articles/d63c390c02f436
  11. 脅威モデリング 27 脅威モデリングとは ◦ システムやアプリケーションを深く分析して、起こりうる攻撃、脆弱性、対策を特定し て、優先順位をつけること ◦ 積極的に予防することで将来発生しうるインシデントを未然に防ぐことができる ◦ 脅威モデリングを学ぶのに参考となるサイト

    ▪ Microsoft 脅威のモデル化のセキュリティの基礎 ▪ メルカリの脅威モデリングプロセス ▪ 脅威分析において Microsoft Threat Modeling Tool をより便利に使う方法 ◦ 以降は特定した脅威への対策となりうるものを紹介します
  12. AWS WAF 28 AWS WAFについて ◦ AWS WAFを使う場合の選択肢 ▪ AWSのマネージドルール:基本無料、コストを抑えたいとき

    ▪ その他セキュリティベンダのマネージドルール:コストは中程度、運用は自分たち で行う必要がある ▪ WafCharm:この中ではコストが高い、運用はこの中では最も楽
  13. AWS WAF 29 AWSマネージドルール ルールグループ ルール名 説明 ベースラインルールグ ループ Core

    Rule Set (CRS) OWASPに記載されているXSS等の一般的に発生す る脆弱性に対する保護 AWSManagedRulesKnownBadInputs RuleSet Log4jやSpring Core等の既知の脆弱性に対する保 護 ユースケース固有の ルールグループ AWSManagedRulesSQLiRuleSet SQLインジェクション攻撃等に対する保護。アプリ ケーションがDB接続しているなら AWSManagedRulesLinuxRuleSet AWSManagedRulesUnixRuleSet LinuxやPOSIX固有の脆弱性の悪用に関連するリク エストパターンをブロックするルール、使うときは一緒 に有効にする IP評価ルールグルー プ AWSManagedRulesAmazonIpReput ationList ボットやその他の脅威に関連付けられている IP アド レスをブロックする Bot Control ルールグ ループ AWSManagedRulesBotControlRuleS et ボットからのリクエストをブロックおよび管理するルー ルを提供
  14. AWS WAF 30 その他セキュリティベンダのマネージドルール ルール名 説明 Cyber Security Cloud Managed

    Rules for AWS WAF -API Gateway/Serverless- OWASP API セキュリティ/サーバーレス トップ 10 の脅威を含む脆弱性を軽減お よび最小限に抑えるためのルール集。 コードインジェクション、XML 外部エンティティ攻撃、サーバー側リクエスト フォー ジェリ、XSS、ディレクトリ トラバーサル、悪意のあるボット ルールセットなどの対 策を含む F5 Rules for AWS WAF - API Security Rules API 攻撃、Web 攻撃 (XML 外部エンティティ攻撃など)、サーバー側のリクエスト フォージェリから保護するためのルール Fortinet Managed Rules for AWS WAF - API Security OWASP Top 10 に対する保護に加えて、API 攻撃対象領域をターゲットとした 攻撃を防御するように最適化されたルール集
  15. HTTPヘッダでの対策 31 セキュリティ関連のHTTPヘッダ ヘッダ名 説明 X-Content-Type-Options ブラウザがContent-Type ヘッダーで指定したメディアタイプに従うようになる。 XSS防止に X-Frame-Options

    ブラウザがページをIFRAME等で読み込めるかどうかを制御。コンテンツが他の サイトに埋め込まれないことを保証することでクリックジャッキング攻撃を防ぐ Content-Security-Policy HTML内のどの要素(IMG,SCRIPT等)からの読み込みを許可するか、どのドメ インからの読み込みを許可するかを指定。XSS対策等で役立つ Strict-Transport-Security ブラウザにHTTPS を用いて通信を行うよう指示する。HTTPアクセスした場合は 無視されてしまうがpreloadをつけ事前登録すれば初回HTTPアクセスもHTTPS にすることができる Set-Cookie Secure属性をつけることでHTTPS プロトコルを使用して行われた場合にのみ サーバーに送信される。またHttpOnlyをつけることでCookieをJavaScriptからア クセスできないように制限する
  16. レート制限 33 レートベース ◦ Webに公開する以上は大量アクセスがいつ来てもいいように対策をしておく必要が ある ▪ AWS WAFでやるパターン •

    直近5分のアクセス件数で制限 • 30秒毎にチェックするのでブロックするまでに最大で30秒かかる
  17. レート制限 34 レートベース ▪ API Gateway スロットリング機能でレート制限 • ルート毎に値を設定可能 ◦

    1秒間にバケットに補充されるトークン数とバケット最大容量を設定 • トークンバケットアルゴリズム ◦ 一定間隔でバケットにトークンが補充 ◦ リクエスト毎にバケットの中にあるトークンを消費、トークンがない場合、httpリ ターンコード429を返す ▪ 上記よりも精緻なコントロールをしたい場合、自前で実装
  18. なぜバージョン管理する必要があるのか 37 不特定多数の利用者=一般向けに公開するAPI ◦ 仕様変更により API を使う外部システムやサービスにも影響が及ぶ から ◦ 外部のサービスがどのくらい影響を受けるかが

    API 提供側では読め ない ◦ 予告もなく API仕様を変更したら絶対にトラブルが起きる ◦ 変更を強行したら API を使うサービスで不具合を起こり、「いきなり仕 様変更する信頼できないサービス」と認識されユーザは離れる
  19. どのようにバージョン管理したらいいか 39 一度公開した API をできる限り変更しない ◦ 新しい API は別のエンドポイント、別のパラメータをつけた URI

    等新しいアクセス形 式で公開する ◦ つまり複数のメジャーバージョンの APIを並行稼働する期間を設ける
  20. どのようにバージョンを上げるべきか 40 メジャーバージョン更新の方針 ◦ 基本的に出来る限りメジャーバージョンを上げない ▪ 複数のバージョンを保持するのはメンテナンスコストがかさむから ◦ 後方互換性を保つのがどうしても難しい場合にのみバージョンアップを検討 ◦

    後方互換性を保つためのテクニック ▪ 例えばレスポンスデータの型を変えたいとき • 新しくデータ項目を追加し、そちらを変更後のデータ型にする • 既存のものはメジャーバージョン内ではそのままにし、次のメジャーバージョン アップで削除することをAPIドキュメント等に明記する
  21. どのようにバージョンを表現するか 41 URI にバージョンを埋め込む ◦ 例:example.com/v2/users/、example.com/v1.1/users/ ◦ 一般的、最もわかりやすい ◦ 整数で(メジャーバージョンのみ)つけるのがおすすめ

    ▪ メジャーバージョンアップでなければ後方互換性は保たれているは ずだから ▪ バージョンの付け方の参考:https://semver.org/lang/ja/
  22. AWSでの実装例 43 URIバージョン埋め込み方式での実装例 参考ブログ :https://dev.classmethod.jp/articles/aws-cdk-api-version-management-masterin g-system-configuration-and-deployment-with-github-actions/ ◦ API Gateway(HTTP API)の機能でバー

    ジョン毎にステージを用意 ◦ ステージ変数を使って各Lambdaバージョ ンを指すように設定 ◦ URIごとに異なるバージョンのLambdaに ルーティング
  23. 様々な認証認可方式 46 APIキーについて ◦ 一般公開データのみにアクセスするAPIならこれだけでもOK ◦ パブリックなAPI(例えばGoogle Maps APIとか)ではアプリケーションやプロジェクト 自体等、請求元を識別する用途等で使われる

    ▪ この場合はIPアドレスやRefererヘッダでキーの使用自体を制限したり、可能なら 中継サーバ等にキーを配置してキーが盗まれるのを防ぐようにする ◦ エンドユーザのデータが関連するAPIならトークンベース認証を使う ここの 識別に 使う
  24. OAuth と OpenIDConnect について 47 OAuth と OpenID Connect(OIDC) の概念と違い

    ◦ OIDC=認証プロトコル=IDトークンを発行するための仕組み ◦ OAuth=認可プロトコル=アクセストークンを発行するための仕組み ◦ 認証=身元を証明、それを確認するプロセスのこと ◦ 認可=アクセスするコンテンツに対してアクセス可否を制御すること ◦ OIDC は OAuth の拡張仕様=アクセストークンを発行するフローを流用して ID トークンも発行できるようにしたもの ◦ 参考 :https://dev.classmethod.jp/articles/authentication-and-authorization-again/
  25. CognitoとAuth0 49 CognitoとAuth0の比較 比較項目 Cognito Auth0 コスト 1000MAUあたり5.5USD B2C:1000MAU最安23USD B2B:500MAU最安130USD

    ※Enterpriseプランは要問い合わせ 監視 AWS HealthDashboardで確認 Auth0ステータスダッシュボードで確認 可能。RSS購読もできる 証跡 CognitoAPIの呼び出しをCloudTrail に記録 ブラウザからAuth0ダッシュボードで閲 覧、またはAPIを使った取得も可能 SLA 99.99% Enterpriseプランなら99.99%
  26. CognitoとAuth0 50 比較項目 Cognito Auth0 提供SDK JavaScript,Java,.NET,iOS,Android React、Next.js、Ruby等かなり豊富 ドキュメント Auth0と比較するとやや不親切か

    かなり豊富でハンズオン等も充実、説 明もわかりやすい その他機能 認証されたユーザに対してIAMロール を割り当てることができるので、クライ アントからS3等のAWSリソースを直 接触らせたい時などに便利 ユーザー毎にAPIで使用できる機能を 変えたい場合に、Auth0では、role機 能を使うことでロール単位でAPIに対 する権限を管理することが可能。 CognitoとAuth0の比較
  27. Observability(可観測性) ◦ 「なにが」「どこで」「なぜ」起こっているのかを観測可能にすること ◦ Observabilityの3つの柱 ▪ メトリクス:「なにが」起きているかを検知する ▪ トレース:「どこで」問題が起きているか把握し対処する ▪

    ログ:「なぜ」問題が発生したかを調査し根本対処する ここではAPI Gateway+LambdaでObservabilityを実現するための方法を紹介 Observability 61 参考:https://catalog.workshops.aws/observability/ja-JP
  28. 62 メトリクス API Gateway ◦ REST API, HTTP API: ▪

    4xx,5xx,レイテンシ等を取得可 ▪ 詳細オプション有効化でメソッド毎に 取得出来るように Lambda ◦ 標準では呼び出し回数、エラー回数 や処理時間 ◦ Lambdaインサイトを有効にすると CPU時間、メモリ使用率等もとれるよ うに
  29. 63 メトリクス メトリクス関連機能 ◦ 異常検出 ▪ 過去のデータに基づき自動で異常な値を検出できる機能 ◦ 複合アラーム ▪

    複数のアラームの条件が満たされたときにアラートとなる機能 https://catalog.workshops.aws/observability/ja-JP より引用
  30. X-Ray ◦ API GatewayではREST APIはサポートしているが、HTTP APIでは非サポート ◦ API Gatewayの場合、設定は簡単でコンソールで有効化するだけ ◦

    Lambdaの場合はコンソールで有効化することもできるがX-Ray SDK をLambda関 数に組み込むことでLambdaから呼ばれるAWSサービスの処理時間なども計測で きるようになる ◦ サンプリングレートには注意。リクエスト数が多いサービスだと思わぬ料金が発生す ることも。固定レートの設定でリクエストの何%を取得するかが決まる トレース 64
  31. API Gateway ◦ REST APIで取得できるログ:実行ログ、アクセスログ ◦ HTTP APIで取得できるログ:アクセスログ ◦ デフォルトでは無効、有効にするとCloudWatch

    Logsに出力 Lambda ◦ 標準出力をCloudWatch Logsに出力 ▪ JSON形式でフォーマットするのがオススメ ▪ Lambda Powertoolsというものもある ログ 68 参考:https://dev.classmethod.jp/articles/aws-lambda-powertools-python/
  32. 71