developersio-2023-aws-api-publication-checklist

by t-kikuchi

Slide 1

Slide 1 text

AWSを使ってAPI公開したくなったときに検討すべき６つの項目 2023/07/08 AWS事業本部コンサルティング部菊池　聡規ハッシュタグ #devio2023 1

Slide 2

Slide 2 text

2 自己紹介 ● 【名前】菊池聡規 ● 【所属】 AWS 事業本部コンサルティング部 ● 【キャリア】金融機関向けオンプレのインフラエンジニア１０年ほど→ 自社Webサービスをもつ企業で３年ほど→ クラスメソッドにジョイン ● 【Blog】 https://dev.classmethod.jp/author/tooti/

Slide 3

Slide 3 text

このセッションでのAPIとは 3 ● WebAPIのことを話します ● API形式 ○ REST API ○ gRPC ○ GraphQL

Slide 4

Slide 4 text

想定受講者とゴール 4 想定受講者 ○AWS環境でシステムを作っている方 ○突然WebAPIを作ることになったけど何から考えればいいか分からない方 ○どちらかというとインフラ寄りの方ゴール ○AWSでWebAPIを作るときの勘所が分かるようになる

Slide 5

Slide 5 text

アジェンダ 5 1. アーキテクチャ設計 2. セキュリティ 3. バージョン管理（デプロイ方法等） 4. 認証認可 5. APIドキュメント管理方法 6. 監視 7. まとめ

Slide 6

Slide 6 text

1. アーキテクチャ設計 6

Slide 7

Slide 7 text

AWSでAPIといえば・・・ 7

Slide 8

Slide 8 text

API Gateway + Lambda 8 これだけでも色々考えることがありそうそもそもAPI Gatewayでいい？ ALB+ECS等の選択肢もあるのでは REST API or HTTP API どっちにする？キャッシュどうする？

Slide 9

Slide 9 text

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/

Slide 10

Slide 10 text

RESTかHTTPか 10 機能面比較項目 REST API HTTP API エンドポイントリージョンエンドポイント、リージョン最適化、プライベートエンドポイントリージョンエンドポイントのみセキュリティ AWS WAFとの統合 AWS WAF統合は出来ないアクセス制御リソースポリシーが使える Cognitoオーソライザーが使える JWTオーソライザーが便利 APIキー APIキー発行、キー毎のレート制限、使用量把握 APIキー発行機能はない開発キャッシュ、リクエスト検証、カスタムゲートウェイレスポンス自動デプロイ機能で設定変更するとすぐ反映モニタリング X-Ray統合 X-Rayとの統合はなし統合 NLBとのプライベート統合 ALBとのプライベート統合

Slide 11

Slide 11 text

RESTかHTTPか 11 コスト面 ○仮に月１０００万回、APIがコールされた場合 ■ REST API=1000万/100万 * 4.25USD = 42.5USD = 5,950円 ■ HTTP API=1000万/100万 * 1.29USD = 12.9USD = 1,806円月１０００万のリクエストはなかなかの規模のサービス。規模が大きいサービスでなければコストの違いはそこまで気にしなくても。

Slide 12

Slide 12 text

RESTかHTTPか 12 パフォーマンス面 ○ 実際どの程度差が出るのか計測してみる ■ テスト条件 ● API Gateway+Lambdaのシンプルな構成 ● API Gatewayは両方リージョナルエンドポイント ● Lambdaは固定レスポンスを返すだけ ● テストはこちらのソリューションを使って実施(同時実行数100、5分ほど計測） ○ https://aws.amazon.com/jp/solutions/implementations/distributed-load-tes ting-on-aws/

Slide 13

Slide 13 text

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層のレスポンス時間のほうが全体に与える影響は大きい。

Slide 14

Slide 14 text

キャッシュをどうするか 14 Webシステムにおけるキャッシュの基本 ○クライアント（ブラウザ等）側でもつキャッシュとCDN等の中継サーバでもつキャッシュの大きく２つがある ○ オリジンがHTTPヘッダで指定するキャッシュ設定とCDNのキャッシュ設定の２つがあるキャッシュキャッシュキャッシュTTL 等の設定レスポンスヘッダにキャッシュ関連ヘッダを含めて返す

Slide 15

Slide 15 text

キャッシュをどうするか 15 HTTPヘッダ指定によるキャッシュ ○HTTPの仕様による２つのキャッシュモデル ■ Expiration Model：レスポンスデータに保持期限があり切れたら再度取得してもらう（代表的ヘッダ：Cache-Controle） ■ Validation Model：今保持しているキャッシュが最新かを問い合わせて、更新されていた場合のみ取得（代表的ヘッダ：Last-Modified,ETag） ○ これらはブラウザとCDN、双方に対しての指示である

Slide 16

Slide 16 text

キャッシュをどうするか 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/

Slide 17

Slide 17 text

キャッシュをどうするか 17 API Gateway（REST API）でのキャッシュ ○ リクエストが発生していなくても時間で課金 ○ オリジンとしては一つでもキャッシュ動作を変えるためにはパスを設定する必要あり ○ オリジンのCache-Controlヘッダ等は無視してTTLのみに従いキャッシュを保持 ○ X-CacheヘッダでAPI Gatewayによるキャッシュかどうかを判断できない

Slide 18

Slide 18 text

キャッシュをどうするか 18 CloudFrontでのキャッシュ ○API Gatewayの前段にCloudFrontを置く ○特にHTTP APIにおいて有用だがREST APIで使うのもアリ ○ CloudFrontをバイパスされないように注意 ○ REST APIならリソースポリシーでRefererヘッダを確認するのが良さそうカスタムヘッダ付与カスタムヘッダ確認

Slide 19

Slide 19 text

CloudFrontでのキャッシュ ○パス毎にキャッシュポリシーを設定 ○オリジンのCache-Control及びExpiresヘッダに連動 ■ CloudFront側でもTTL設定があるがCache-Controlヘッダ等の設定を基本的に優先 ○ 期限切れの時はLast-Modified,ETagヘッダを使ったキャッシュ期間の更新 ○ リクエストヘッダ、クエリ、Cookie（+パス）でキャッシュキーを構成キャッシュをどうするか 19

Slide 20

Slide 20 text

キャッシュをどうするか 20 参考ブログ：https://dev.classmethod.jp/articles/cloudfront-stale-while-revalidate-stale-if-erro r/

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

2. セキュリティ 22

Slide 23

Slide 23 text

そもそもセキュリティ対策ってなんのためにするんですっけ？ 23

Slide 24

Slide 24 text

ざっくりいうとシステムを守るため 24

Slide 25

Slide 25 text

ではどうやったらシステムを守れる？ 25

Slide 26

Slide 26 text

自分達のシステムを深く知ってどこにどういった攻撃をされると辛いかを把握するつまり脅威モデリングを行う 26

Slide 27

Slide 27 text

脅威モデリング 27 脅威モデリングとは ○ システムやアプリケーションを深く分析して、起こりうる攻撃、脆弱性、対策を特定して、優先順位をつけること ○ 積極的に予防することで将来発生しうるインシデントを未然に防ぐことができる ○ 脅威モデリングを学ぶのに参考となるサイト ■ Microsoft 脅威のモデル化のセキュリティの基礎 ■ メルカリの脅威モデリングプロセス ■ 脅威分析において Microsoft Threat Modeling Tool をより便利に使う方法 ○ 以降は特定した脅威への対策となりうるものを紹介します

Slide 28

Slide 28 text

AWS WAF 28 AWS WAFについて ○ AWS WAFを使う場合の選択肢 ■ AWSのマネージドルール：基本無料、コストを抑えたいとき ■ その他セキュリティベンダのマネージドルール：コストは中程度、運用は自分たちで行う必要がある ■ WafCharm：この中ではコストが高い、運用はこの中では最も楽

Slide 29

Slide 29 text

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 ボットからのリクエストをブロックおよび管理するルールを提供

Slide 30

Slide 30 text

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 攻撃対象領域をターゲットとした攻撃を防御するように最適化されたルール集

Slide 31

Slide 31 text

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からアクセスできないように制限する

Slide 32

Slide 32 text

HTTPヘッダでの対策 32 CloudFrontでセキュリティ関連ヘッダを付与する ○CloudFront Functionsをビューワーレスポンスで使用 ○ レスポンスヘッダにセキュリティ関連ヘッダを追加参考：https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/ example-function-add-security-headers.html

Slide 33

Slide 33 text

レート制限 33 レートベース ○ Webに公開する以上は大量アクセスがいつ来てもいいように対策をしておく必要がある ■ AWS WAFでやるパターン ● 直近５分のアクセス件数で制限 ● 30秒毎にチェックするのでブロックするまでに最大で30秒かかる

Slide 34

Slide 34 text

レート制限 34 レートベース ■ API Gateway スロットリング機能でレート制限 ● ルート毎に値を設定可能 ○ １秒間にバケットに補充されるトークン数とバケット最大容量を設定 ● トークンバケットアルゴリズム ○ 一定間隔でバケットにトークンが補充 ○ リクエスト毎にバケットの中にあるトークンを消費、トークンがない場合、httpリターンコード429を返す ■ 上記よりも精緻なコントロールをしたい場合、自前で実装

Slide 35

Slide 35 text

3. バージョン管理（デプロイ方法等） 35

Slide 36

Slide 36 text

一度公開したAPIの仕様を変更するのはとても大変 36

Slide 37

Slide 37 text

なぜバージョン管理する必要があるのか 37 不特定多数の利用者＝一般向けに公開するAPI ○ 仕様変更により API を使う外部システムやサービスにも影響が及ぶから ○ 外部のサービスがどのくらい影響を受けるかが API 提供側では読めない ○ 予告もなく API仕様を変更したら絶対にトラブルが起きる ○ 変更を強行したら API を使うサービスで不具合を起こり、「いきなり仕様変更する信頼できないサービス」と認識されユーザは離れる

Slide 38

Slide 38 text

なぜバージョン管理する必要があるのか 38 少数の特定された利用者＝自システム等限られた範囲で使うAPI ○ ターゲットは自分のサービスだけなので前者と比較すると影響範囲は小さい ○ しかし例えばモバイルアプリの場合、アップデートしない・できない端末もあることを考慮する必要あり ○ Web サービス上の API の場合はブラウザのキャッシュに気をつける ■ API レスポンスとJavaScript等のクライアント側で動くコード、どちらもキャッシュされる可能性を考慮する必要あり

Slide 39

Slide 39 text

どのようにバージョン管理したらいいか 39 一度公開した API をできる限り変更しない ○ 新しい API は別のエンドポイント、別のパラメータをつけた URI 等新しいアクセス形式で公開する ○ つまり複数のメジャーバージョンの APIを並行稼働する期間を設ける

Slide 40

Slide 40 text

どのようにバージョンを上げるべきか 40 メジャーバージョン更新の方針 ○ 基本的に出来る限りメジャーバージョンを上げない ■ 複数のバージョンを保持するのはメンテナンスコストがかさむから ○ 後方互換性を保つのがどうしても難しい場合にのみバージョンアップを検討 ○ 後方互換性を保つためのテクニック ■ 例えばレスポンスデータの型を変えたいとき ● 新しくデータ項目を追加し、そちらを変更後のデータ型にする ● 既存のものはメジャーバージョン内ではそのままにし、次のメジャーバージョンアップで削除することをAPIドキュメント等に明記する

Slide 41

Slide 41 text

どのようにバージョンを表現するか 41 URI にバージョンを埋め込む ○ 例：example.com/v2/users/、example.com/v1.1/users/ ○ 一般的、最もわかりやすい ○ 整数で(メジャーバージョンのみ)つけるのがおすすめ ■ メジャーバージョンアップでなければ後方互換性は保たれているはずだから ■ バージョンの付け方の参考：https://semver.org/lang/ja/

Slide 42

Slide 42 text

どのようにバージョンを表現するか 42 バージョンをクエリ文字列に入れる ○ 例：example.com/users?v=2 ○ クエリ文字列なので省略可能である点がパス方式との最大の違い＝デフォルトバージョンを決める必要がある ○ デフォルトバージョンを何にすべきか大きくは以下２通り ■ 最新を指す ■ サポートする最も古いものを指す ○ 省略したURIをエンドユーザが使っているとき突然APIが切り替わることがあるのがデメリット

Slide 43

Slide 43 text

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にルーティング

Slide 44

Slide 44 text

4. 認証認可 44

Slide 45

Slide 45 text

様々な認証認可方式 45 認証認可方式の例 ○ BASIC認証 ○ APIキー ○ トークンベース認証（OAuth, OpenID Connect）

Slide 46

Slide 46 text

様々な認証認可方式 46 APIキーについて ○ 一般公開データのみにアクセスするAPIならこれだけでもOK ○ パブリックなAPI(例えばGoogle Maps APIとか)ではアプリケーションやプロジェクト自体等、請求元を識別する用途等で使われる ■ この場合はIPアドレスやRefererヘッダでキーの使用自体を制限したり、可能なら中継サーバ等にキーを配置してキーが盗まれるのを防ぐようにする ○ エンドユーザのデータが関連するAPIならトークンベース認証を使うここの識別に使う

Slide 47

Slide 47 text

OAuth と OpenIDConnect について 47 OAuth と OpenID Connect(OIDC) の概念と違い ○ OIDC＝認証プロトコル＝IDトークンを発行するための仕組み ○ OAuth＝認可プロトコル＝アクセストークンを発行するための仕組み ○ 認証＝身元を証明、それを確認するプロセスのこと ○ 認可＝アクセスするコンテンツに対してアクセス可否を制御すること ○ OIDC は OAuth の拡張仕様＝アクセストークンを発行するフローを流用して ID トークンも発行できるようにしたもの ○ 参考：https://dev.classmethod.jp/articles/authentication-and-authorization-again/

Slide 48

Slide 48 text

OAuth と OpenIDConnect について 48 OIDC(OAuth)の要素一般的なサーバサイドWebアプリケーションの場合

Slide 49

Slide 49 text

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%

Slide 50

Slide 50 text

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の比較

Slide 51

Slide 51 text

5. APIドキュメント管理方法 51

Slide 52

Slide 52 text

なぜ API ドキュメントが必要なのか ○ 自組織以外の外部に使わせるAPIの場合、外部開発者がAPIのアクセスの仕方を知るためにドキュメントは必須 ○ 自組織内であっても他のチームにAPIの仕様を伝えるのは大事 ○ APIのドキュメントは常に最新に保つのが重要 API ドキュメントの重要性 52

Slide 53

Slide 53 text

OpenAPI ○ REST APIのための記述フォーマットで以下のようなことを定義ファイルに表現できる ■ 利用可能なエンドポイント(/users)とエンドポイントでの操作(GET等) ■ 渡すパラメータと入出力形式 ■ 認証方法 ○ YAMLまたはJSONで記述 API ドキュメントの作成と保守 53

Slide 54

Slide 54 text

OpenAPI ○ OpenAPI形式の定義ファイルに基づき以下を自動で生成可能(※一例) ■ クライアントやサーバのコード ■ APIドキュメント API ドキュメントの作成と保守 54

Slide 55

Slide 55 text

API ドキュメントの作成と保守 55

Slide 56

Slide 56 text

AWSでの実装例 AWS における API ドキュメント管理 56

Slide 57

Slide 57 text

GitHub Actionsコード例 AWS における API ドキュメント管理 57

Slide 58

Slide 58 text

OpenAPIの自動生成 58 参考ブログ：https://dev.classmethod.jp/articles/fastify-zod-openapi/

Slide 59

Slide 59 text

モダンアプリコンサルティングやってます 59

Slide 60

Slide 60 text

6. 監視 60

Slide 61

Slide 61 text

Observability（可観測性） ○ 「なにが」「どこで」「なぜ」起こっているのかを観測可能にすること ○ Observabilityの３つの柱 ■ メトリクス：「なにが」起きているかを検知する ■ トレース：「どこで」問題が起きているか把握し対処する ■ ログ：「なぜ」問題が発生したかを調査し根本対処するここではAPI Gateway+LambdaでObservabilityを実現するための方法を紹介 Observability 61 参考：https://catalog.workshops.aws/observability/ja-JP

Slide 62

Slide 62 text

62 メトリクス API Gateway ○ REST API, HTTP API： ■ 4xx,5xx,レイテンシ等を取得可 ■ 詳細オプション有効化でメソッド毎に取得出来るように Lambda ○ 標準では呼び出し回数、エラー回数や処理時間 ○ Lambdaインサイトを有効にすると CPU時間、メモリ使用率等もとれるように

Slide 63

Slide 63 text

63 メトリクスメトリクス関連機能 ○ 異常検出 ■ 過去のデータに基づき自動で異常な値を検出できる機能 ○ 複合アラーム ■ 複数のアラームの条件が満たされたときにアラートとなる機能 https://catalog.workshops.aws/observability/ja-JP より引用

Slide 64

Slide 64 text

X-Ray ○ API GatewayではREST APIはサポートしているが、HTTP APIでは非サポート ○ API Gatewayの場合、設定は簡単でコンソールで有効化するだけ ○ Lambdaの場合はコンソールで有効化することもできるがX-Ray SDK をLambda関数に組み込むことでLambdaから呼ばれるAWSサービスの処理時間なども計測できるようになる ○ サンプリングレートには注意。リクエスト数が多いサービスだと思わぬ料金が発生することも。固定レートの設定でリクエストの何％を取得するかが決まるトレース 64

Slide 65

Slide 65 text

X-Ray トレース 65

Slide 66

Slide 66 text

X-Ray トレース 66

Slide 67

Slide 67 text

X-Ray トレース 67

Slide 68

Slide 68 text

API Gateway ○ REST APIで取得できるログ：実行ログ、アクセスログ ○ HTTP APIで取得できるログ：アクセスログ ○ デフォルトでは無効、有効にするとCloudWatch Logsに出力 Lambda ○ 標準出力をCloudWatch Logsに出力 ■ JSON形式でフォーマットするのがオススメ ■ Lambda Powertoolsというものもあるログ 68 参考：https://dev.classmethod.jp/articles/aws-lambda-powertools-python/

Slide 69

Slide 69 text

7. まとめ 69

Slide 70

Slide 70 text

● キャッシュのコントロールはオリジンとCloudFrontで ● 脅威モデリングをしっかり行って自社のシステムに沿った対策をしよう ● APIはバージョン管理して既存バージョンを使うユーザに影響が出ないようにしよう ● 認証認可にはOAuthとOpenID Connectを使おう ● APIドキュメント管理にはOpenAPIを使おう ● 監視はObservabilityを考慮してログ、メトリクス、トレースを取ろうまとめ 70