developersio-2023-aws-api-publication-checklist

developersio-2023-aws-api-publication-checklist

Transcript

1. AWSを使ってAPI公開したくなったときに 検討すべき６つの項目 2023/07/08 AWS事業本部 コンサルティング部 菊池　聡規 ハッシュタグ #devio2023 1
2. 2 自己紹介 • 【名前】 菊池 聡規 • 【所属】 AWS 事業本部 コンサルティング部 • 【キャリア】 金融機関向けオンプレのインフラエンジニア１０年ほど→ 自社Webサービスをもつ企業で３年ほど→ クラスメソッドにジョイン • 【Blog】 https://dev.classmethod.jp/author/tooti/
3. このセッションでのAPIとは 3 • WebAPIのことを話します • API形式 ◦ REST API ◦ gRPC ◦ GraphQL
4. 想定受講者とゴール 4 想定受講者 ◦AWS環境でシステムを作っている方 ◦突然WebAPIを作ることになったけど何から考えればいいか分からない方 ◦どちらかというとインフラ寄りの方 ゴール ◦AWSでWebAPIを作るときの勘所が分かるようになる
5. アジェンダ 5 1. アーキテクチャ設計 2. セキュリティ 3. バージョン管理（デプロイ方法等） 4. 認証認可 5. APIドキュメント管理方法 6. 監視 7. まとめ
6. 1. アーキテクチャ設計 6
7. AWSでAPIといえば・・・ 7
8. API Gateway + Lambda 8 これだけでも色々考えることがありそう そもそもAPI Gatewayでいい？ ALB+ECS等の選択肢もあるのでは REST API or HTTP API どっちにする？ キャッシュどうする？
9. 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/
10. RESTかHTTPか 10 機能面 比較項目 REST API HTTP API エンドポイント リージョンエンドポイント、リージョン最 適化、プライベートエンドポイント リージョンエンドポイントのみ セキュリティ AWS WAFとの統合 AWS WAF統合は出来ない アクセス制御 リソースポリシーが使える Cognitoオーソライザーが使える JWTオーソライザーが便利 APIキー APIキー発行、キー毎のレート制限、 使用量把握 APIキー発行機能はない 開発 キャッシュ、リクエスト検証、カスタム ゲートウェイレスポンス 自動デプロイ機能で設定変更するとす ぐ反映 モニタリング X-Ray統合 X-Rayとの統合はなし 統合 NLBとのプライベート統合 ALBとのプライベート統合
11. RESTかHTTPか 11 コスト面 ◦仮に月１０００万回、APIがコールされた場合 ▪ REST API=1000万/100万 * 4.25USD = 42.5USD = 5,950円 ▪ HTTP API=1000万/100万 * 1.29USD = 12.9USD = 1,806円 月１０００万のリクエストはなかなかの規模のサービス。 規模が大きいサービスでなければコストの違いはそこまで気にしなくても。
12. RESTかHTTPか 12 パフォーマンス面 ◦ 実際どの程度差が出るのか計測してみる ▪ テスト条件 • API Gateway+Lambdaのシンプルな構成 • API Gatewayは両方リージョナルエンドポイント • Lambdaは固定レスポンスを返すだけ • テストはこちらのソリューションを使って実施(同時実行数100、5分ほど計測） ◦ https://aws.amazon.com/jp/solutions/implementations/distributed-load-tes ting-on-aws/
13. 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層のレスポンス時間のほうが全体に与える影響は大 きい。
14. キャッシュをどうするか 14 Webシステムにおけるキャッシュの基本 ◦クライアント（ブラウザ等）側でもつキャッシュとCDN等の中継サーバでもつキャッシュ の大きく２つがある ◦ オリジンがHTTPヘッダで指定するキャッシュ設定とCDNのキャッシュ設定の２つが ある キャッシュ キャッシュ キャッシュTTL 等の設定 レスポンスヘッダに キャッシュ関連ヘッ ダを含めて返す
15. キャッシュをどうするか 15 HTTPヘッダ指定によるキャッシュ ◦HTTPの仕様による２つのキャッシュモデル ▪ Expiration Model：レスポンスデータに保持期限があり切れたら再度取得してもら う（代表的ヘッダ：Cache-Controle） ▪ Validation Model：今保持しているキャッシュが最新かを問い合わせて、更新され ていた場合のみ取得（代表的ヘッダ：Last-Modified,ETag） ◦ これらはブラウザとCDN、双方に対しての指示である
16. キャッシュをどうするか 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/
17. キャッシュをどうするか 17 API Gateway（REST API）でのキャッシュ ◦ リクエストが発生していなくても時間で課金 ◦ オリジンとしては一つでもキャッシュ動作を変えるためにはパスを設定する必要あり ◦ オリジンのCache-Controlヘッダ等は無視してTTLのみに従いキャッシュを保持 ◦ X-CacheヘッダでAPI Gatewayによるキャッシュかどうかを判断できない
18. キャッシュをどうするか 18 CloudFrontでのキャッシュ ◦API Gatewayの前段にCloudFrontを置く ◦特にHTTP APIにおいて有用だがREST APIで使うのもアリ ◦ CloudFrontをバイパスされないように注意 ◦ REST APIならリソースポリシーでRefererヘッダを確認するのが良さそう カスタムヘッ ダ付与 カスタムヘッ ダ確認
19. CloudFrontでのキャッシュ ◦パス毎にキャッシュポリシーを設定 ◦オリジンのCache-Control及びExpiresヘッダに連動 ▪ CloudFront側でもTTL設定があるがCache-Controlヘッダ等の設定を基本的に 優先 ◦ 期限切れの時はLast-Modified,ETagヘッダを使ったキャッシュ期間の更新 ◦ リクエストヘッダ、クエリ、Cookie（+パス）でキャッシュキーを構成 キャッシュをどうするか 19
20. キャッシュをどうするか 20 参考ブログ ：https://dev.classmethod.jp/articles/cloudfront-stale-while-revalidate-stale-if-erro r/
21. 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
22. 2. セキュリティ 22
23. そもそもセキュリティ対策ってなんのためにするん ですっけ？ 23
24. ざっくりいうとシステムを守るため 24
25. ではどうやったらシステムを守れる？ 25
26. 自分達のシステムを深く知って どこにどういった攻撃をされると 辛いかを把握する つまり脅威モデリングを行う 26
27. 脅威モデリング 27 脅威モデリングとは ◦ システムやアプリケーションを深く分析して、起こりうる攻撃、脆弱性、対策を特定し て、優先順位をつけること ◦ 積極的に予防することで将来発生しうるインシデントを未然に防ぐことができる ◦ 脅威モデリングを学ぶのに参考となるサイト ▪ Microsoft 脅威のモデル化のセキュリティの基礎 ▪ メルカリの脅威モデリングプロセス ▪ 脅威分析において Microsoft Threat Modeling Tool をより便利に使う方法 ◦ 以降は特定した脅威への対策となりうるものを紹介します
28. AWS WAF 28 AWS WAFについて ◦ AWS WAFを使う場合の選択肢 ▪ AWSのマネージドルール：基本無料、コストを抑えたいとき ▪ その他セキュリティベンダのマネージドルール：コストは中程度、運用は自分たち で行う必要がある ▪ WafCharm：この中ではコストが高い、運用はこの中では最も楽
29. 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 ボットからのリクエストをブロックおよび管理するルー ルを提供
30. 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 攻撃対象領域をターゲットとした 攻撃を防御するように最適化されたルール集
31. 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からア クセスできないように制限する
32. HTTPヘッダでの対策 32 CloudFrontでセキュリティ関連ヘッダを付与する ◦CloudFront Functionsをビューワーレスポンスで使用 ◦ レスポンスヘッダにセキュリティ関連ヘッダを追加 参考 ：https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/ example-function-add-security-headers.html
33. レート制限 33 レートベース ◦ Webに公開する以上は大量アクセスがいつ来てもいいように対策をしておく必要が ある ▪ AWS WAFでやるパターン • 直近５分のアクセス件数で制限 • 30秒毎にチェックするのでブロックするまでに最大で30秒かかる
34. レート制限 34 レートベース ▪ API Gateway スロットリング機能でレート制限 • ルート毎に値を設定可能 ◦ １秒間にバケットに補充されるトークン数とバケット最大容量を設定 • トークンバケットアルゴリズム ◦ 一定間隔でバケットにトークンが補充 ◦ リクエスト毎にバケットの中にあるトークンを消費、トークンがない場合、httpリ ターンコード429を返す ▪ 上記よりも精緻なコントロールをしたい場合、自前で実装
35. 3. バージョン管理（デプロイ方法等） 35
36. 一度公開したAPIの仕様を変更するのは とても大変 36
37. なぜバージョン管理する必要があるのか 37 不特定多数の利用者＝一般向けに公開するAPI ◦ 仕様変更により API を使う外部システムやサービスにも影響が及ぶ から ◦ 外部のサービスがどのくらい影響を受けるかが API 提供側では読め ない ◦ 予告もなく API仕様を変更したら絶対にトラブルが起きる ◦ 変更を強行したら API を使うサービスで不具合を起こり、「いきなり仕 様変更する信頼できないサービス」と認識されユーザは離れる
38. なぜバージョン管理する必要があるのか 38 少数の特定された利用者＝自システム等限られた範囲で使うAPI ◦ ターゲットは自分のサービスだけなので 前者と比較すると影響範囲 は小さい ◦ しかし例えばモバイルアプリの場合、アップデートしない・できない端 末もあることを考慮する必要あり ◦ Web サービス上の API の場合はブラウザのキャッシュに気をつける ▪ API レスポンスとJavaScript等のクライアント側で動くコード、どちら もキャッシュされる可能性を考慮する必要あり
39. どのようにバージョン管理したらいいか 39 一度公開した API をできる限り変更しない ◦ 新しい API は別のエンドポイント、別のパラメータをつけた URI 等新しいアクセス形 式で公開する ◦ つまり複数のメジャーバージョンの APIを並行稼働する期間を設ける
40. どのようにバージョンを上げるべきか 40 メジャーバージョン更新の方針 ◦ 基本的に出来る限りメジャーバージョンを上げない ▪ 複数のバージョンを保持するのはメンテナンスコストがかさむから ◦ 後方互換性を保つのがどうしても難しい場合にのみバージョンアップを検討 ◦ 後方互換性を保つためのテクニック ▪ 例えばレスポンスデータの型を変えたいとき • 新しくデータ項目を追加し、そちらを変更後のデータ型にする • 既存のものはメジャーバージョン内ではそのままにし、次のメジャーバージョン アップで削除することをAPIドキュメント等に明記する
41. どのようにバージョンを表現するか 41 URI にバージョンを埋め込む ◦ 例：example.com/v2/users/、example.com/v1.1/users/ ◦ 一般的、最もわかりやすい ◦ 整数で(メジャーバージョンのみ)つけるのがおすすめ ▪ メジャーバージョンアップでなければ後方互換性は保たれているは ずだから ▪ バージョンの付け方の参考：https://semver.org/lang/ja/
42. どのようにバージョンを表現するか 42 バージョンをクエリ文字列に入れる ◦ 例：example.com/users?v=2 ◦ クエリ文字列なので省略可能である点がパス方式との最大の違い＝ デフォルトバージョンを決める必要がある ◦ デフォルトバージョンを何にすべきか大きくは以下２通り ▪ 最新を指す ▪ サポートする最も古いものを指す ◦ 省略したURIをエンドユーザが使っているとき突然APIが切り替わるこ とがあるのがデメリット
43. 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に ルーティング
44. 4. 認証認可 44
45. 様々な認証認可方式 45 認証認可方式の例 ◦ BASIC認証 ◦ APIキー ◦ トークンベース認証（OAuth, OpenID Connect）
46. 様々な認証認可方式 46 APIキーについて ◦ 一般公開データのみにアクセスするAPIならこれだけでもOK ◦ パブリックなAPI(例えばGoogle Maps APIとか)ではアプリケーションやプロジェクト 自体等、請求元を識別する用途等で使われる ▪ この場合はIPアドレスやRefererヘッダでキーの使用自体を制限したり、可能なら 中継サーバ等にキーを配置してキーが盗まれるのを防ぐようにする ◦ エンドユーザのデータが関連するAPIならトークンベース認証を使う ここの 識別に 使う
47. OAuth と OpenIDConnect について 47 OAuth と OpenID Connect(OIDC) の概念と違い ◦ OIDC＝認証プロトコル＝IDトークンを発行するための仕組み ◦ OAuth＝認可プロトコル＝アクセストークンを発行するための仕組み ◦ 認証＝身元を証明、それを確認するプロセスのこと ◦ 認可＝アクセスするコンテンツに対してアクセス可否を制御すること ◦ OIDC は OAuth の拡張仕様＝アクセストークンを発行するフローを流用して ID トークンも発行できるようにしたもの ◦ 参考 ：https://dev.classmethod.jp/articles/authentication-and-authorization-again/
48. OAuth と OpenIDConnect について 48 OIDC(OAuth)の要素 一般的なサーバサイドWebアプリケーションの場合
49. 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%
50. CognitoとAuth0 50 比較項目 Cognito Auth0 提供SDK JavaScript,Java,.NET,iOS,Android React、Next.js、Ruby等かなり豊富 ドキュメント Auth0と比較するとやや不親切か かなり豊富でハンズオン等も充実、説 明もわかりやすい その他機能 認証されたユーザに対してIAMロール を割り当てることができるので、クライ アントからS３等のAWSリソースを直 接触らせたい時などに便利 ユーザー毎にAPIで使用できる機能を 変えたい場合に、Auth0では、role機 能を使うことでロール単位でAPIに対 する権限を管理することが可能。 CognitoとAuth0の比較
51. 5. APIドキュメント管理方法 51
52. なぜ API ドキュメントが必要なのか ◦ 自組織以外の外部に使わせるAPIの場合、外部開発者がAPIのアクセスの仕方を 知るためにドキュメントは必須 ◦ 自組織内であっても他のチームにAPIの仕様を伝えるのは大事 ◦ APIのドキュメントは常に最新に保つのが重要 API ドキュメントの重要性 52
53. OpenAPI ◦ REST APIのための記述フォーマットで以下のようなことを定義ファイルに表現でき る ▪ 利用可能なエンドポイント(/users)とエンドポイントでの操作(GET等) ▪ 渡すパラメータと入出力形式 ▪ 認証方法 ◦ YAMLまたはJSONで記述 API ドキュメントの作成と保守 53
54. OpenAPI ◦ OpenAPI形式の定義ファイルに基づき以下を自動で生成可能(※一例) ▪ クライアントやサーバのコード ▪ APIドキュメント API ドキュメントの作成と保守 54
55. API ドキュメントの作成と保守 55
56. AWSでの実装例 AWS における API ドキュメント管理 56
57. GitHub Actionsコード例 AWS における API ドキュメント管理 57
58. OpenAPIの自動生成 58 参考ブログ：https://dev.classmethod.jp/articles/fastify-zod-openapi/
59. モダンアプリコンサルティングやってます 59
60. 6. 監視 60
61. Observability（可観測性） ◦ 「なにが」「どこで」「なぜ」起こっているのかを観測可能にすること ◦ Observabilityの３つの柱 ▪ メトリクス：「なにが」起きているかを検知する ▪ トレース：「どこで」問題が起きているか把握し対処する ▪ ログ：「なぜ」問題が発生したかを調査し根本対処する ここではAPI Gateway+LambdaでObservabilityを実現するための方法を紹介 Observability 61 参考：https://catalog.workshops.aws/observability/ja-JP
62. 62 メトリクス API Gateway ◦ REST API, HTTP API： ▪ 4xx,5xx,レイテンシ等を取得可 ▪ 詳細オプション有効化でメソッド毎に 取得出来るように Lambda ◦ 標準では呼び出し回数、エラー回数 や処理時間 ◦ Lambdaインサイトを有効にすると CPU時間、メモリ使用率等もとれるよ うに
63. 63 メトリクス メトリクス関連機能 ◦ 異常検出 ▪ 過去のデータに基づき自動で異常な値を検出できる機能 ◦ 複合アラーム ▪ 複数のアラームの条件が満たされたときにアラートとなる機能 https://catalog.workshops.aws/observability/ja-JP より引用
64. X-Ray ◦ API GatewayではREST APIはサポートしているが、HTTP APIでは非サポート ◦ API Gatewayの場合、設定は簡単でコンソールで有効化するだけ ◦ Lambdaの場合はコンソールで有効化することもできるがX-Ray SDK をLambda関 数に組み込むことでLambdaから呼ばれるAWSサービスの処理時間なども計測で きるようになる ◦ サンプリングレートには注意。リクエスト数が多いサービスだと思わぬ料金が発生す ることも。固定レートの設定でリクエストの何％を取得するかが決まる トレース 64
65. X-Ray トレース 65
66. X-Ray トレース 66
67. X-Ray トレース 67
68. API Gateway ◦ REST APIで取得できるログ：実行ログ、アクセスログ ◦ HTTP APIで取得できるログ：アクセスログ ◦ デフォルトでは無効、有効にするとCloudWatch Logsに出力 Lambda ◦ 標準出力をCloudWatch Logsに出力 ▪ JSON形式でフォーマットするのがオススメ ▪ Lambda Powertoolsというものもある ログ 68 参考：https://dev.classmethod.jp/articles/aws-lambda-powertools-python/
69. 7. まとめ 69
70. • キャッシュのコントロールはオリジンとCloudFrontで • 脅威モデリングをしっかり行って自社のシステムに沿った対策をしよう • APIはバージョン管理して既存バージョンを使うユーザに影響が出ないようにしよう • 認証認可にはOAuthとOpenID Connectを使おう • APIドキュメント管理にはOpenAPIを使おう • 監視はObservabilityを考慮してログ、メトリクス、トレースを取ろう まとめ 70