血と汗となみだを流す

個人の思ったこと、やったことの吐き出し口です。

API Gatewayをはじめよう⑤(メソッドリクエスト(Method Request):リクエストの検証)

この記事は何?

  • API Gatewayのメソッド(Method)で、メソッドリクエスト(Method Request)で設定する項目について調べた結果のまとめです
  • メソッドリクエストだけでも内容がいっぱい詰まっているので、その中のリクエストの検証部分を書いています
  • リクエストの検証の設定で、GETパラメータやヘッダの必須チェック、POSTパラメータの属性(文字列や数字)チェックができる
  • POSTのチェックはモデルを予め作っておいて、それを紐付ける
  • 後続のlambdaを起動する前に、パラメータチェックできるのは良い

メソッド(method)には以下4つがある

  • メソッドリクエスト(Method Request) ←今回はこれ
  • 統合リクエスト(Integration Request)
  • 統合レスポンス(Integration Response)
  • メソッドレスポンス(Method Response)

メソッドリクエストで設定できる項目

  • 設定
    • 認証
    • リクエストの検証 ←今回はこれ
      • リクエストパス
      • URLクエリ文字列パラメータ
      • HTTPリクエストヘッダー
      • リクエスト本文
    • APIキーの必要性
  • SDK設定

リクエストの検証

  • API Gatewayの後ろ側にある処理やlambdaにパラメータを渡す前に検証ができる
    • パラメータエラーの時にlambdaを起動しないで済む
  • 検証の種類
    • クエリ文字列とヘッダ
    • クエリ文字列とヘッダと本文
    • 本文のみ
  • 各設定項目で詳細を設定するっぽい

URLクエリ文字列パラメータ

HTTP リクエストヘッダー

  • URLクエリ文字列パラメータと同様の定義をする

クエリ文字列パラメータとリクエストヘッダーをGETで検証

  • 以下の定義にしてみる f:id:Anorlondo448:20181021230656p:plain

  • テストで、何もパラメータ/ヘッダを付けずにリクエストを送ってみる f:id:Anorlondo448:20181021230924p:plain

  • ちゃんとエラーで返ってきた
{
  "message": "Missing required request parameters: [x-unko-header, param2]"
}
  • 必須パラメータ/ヘッダを付けてリクエストを送ってみる f:id:Anorlondo448:20181021231106p:plain

  • lambdaからのレスポンスが返ってきた

{
  "statusCode": 200,
  "body": "\"Hello Elastic!\""
}

リクエスト本文

参考ページと同じようにやってみる

  • モデルの作成 f:id:Anorlondo448:20181021231519p:plain
{
    "title": "testModel",
    "type": "object",
    "properties": {
        "param1": {
            "type": "string"
        },
        "param2": {
            "type": "number"
        }
    },
    "required": ["param1", "param2"]
}
  • postメソッドのリクエスト本文に作成したモデルを設定する f:id:Anorlondo448:20181021231615p:plain
  • param1もparam2も両方stringで送ってみる f:id:Anorlondo448:20181021231803p:plain
  • エラーで返ってきた
{
  "message": "Invalid request body"
}
  • 正しいリクエストを送ってみる f:id:Anorlondo448:20181021231858p:plain
  • lambdaからのレスポンスが返ってきた
{
  "statusCode": 200,
  "body": "\"Hello Elastic!\""
}

次回

  • APIキーの利用をやって、その次に認証を・・・

前回までの記事

API Gatewayをはじめよう④(APIをinvokeするIAMポリシーを付与する時にハマったこと)

前回

この記事は何?

  • メソッドリクエストの認証周りを調べている時に、Cognitoからユーザに渡すIAMの設定方法でハマったのでまとめておく
    • 具体的に言うと、ビジュアルエディタでAPIinvokeを付与する方法がわからなくてハマってた
  • API GatewayにはARNが2種類あり、実行はexecute-apiを使うということ

API GatewayのARN(Amazon Resource Name)

  • API Gatewayは「リソース」と「ステージ」がある
  • 「リソース」でメソッドやレスポンスの定義などを作成して、「ステージ」にデプロイして使う
  • 「リソース」を対象とする操作におけるARNは apigateway: (公式) f:id:Anorlondo448:20181018233516p:plain
    • 許可/不許可を選択できるアクションは以下だが、API Gatewayのメソッドの定義と同じ文字列なので紛らわしい・・・
      • 読み込み:
        • GET: リソースの情報を取得できる
        • HEAD: GETと同じだけど、リソースの表現(情報?)を返さない。テストシナリオで主に使用
        • OPTIONS: 対象サービスに使用できる通信オプションに関する情報を取得するために呼び出し元が使用できます。(公式に掻いてあるけどわからん。普通のRESTのOPTIONSを許可するだけ?)
      • 書き込み:
        • DELETE: リソースを削除できる
        • PATCH: リソースを更新できる
        • POST: 子リソースを作成できる
        • PUT: リソースを更新できる(子リソースを作ることもできる)
  • 「ステージ」にデプロイしたものを操作するARNは execute-api: (公式) f:id:Anorlondo448:20181018233556p:plain
    • InvalidateCache: APIキャッシュを無効にできる
    • Invoke: APIを実行できる

次回

  • API Gateway沼にハマってて中々進まないけど、認証からめたメソッドリクエストをやる

Amazon LightsailでAmazon Linuxのサーバを建てたら優しさに溢れていた

概要

いろいろ触ってみた

  • WordPressとかLAMPとかプレインストール済みのインスタンスもすぐ建てられる! f:id:Anorlondo448:20181018175103p:plain
  • ロードバランサやDBも建てられるっぽい?! f:id:Anorlondo448:20181018190627p:plain f:id:Anorlondo448:20181018190556p:plain

  • 起動はAmazon Linuxだと30秒くらいで、EC2普通に建てるよりだいぶ早い!!!

  • AWSコンソールのEC2/VPCを見たけど、建てたインスタンスVPCは見えなかった(別空間?)
  • セッションマネージャーのような、ブラウザでCLI操作ができる!接続簡単!
  • ユーザはec2-user。suしたらrootにもなれる! f:id:Anorlondo448:20181018175122p:plain
  • httpd入れてApache起動したら、グローバルIPから80にアクセスできた f:id:Anorlondo448:20181018180017p:plain
  • デフォルト22と80が空いているっぽい!よく使うからね! f:id:Anorlondo448:20181018175138p:plain
  • rebootできた!しばらくしたら再接続可能となった
  • rebootによるパブリックIPの変更は無し! f:id:Anorlondo448:20181018180326p:plain
  • CPU/Network IN/OUTなどのメトリクスがみれた! f:id:Anorlondo448:20181018182437p:plain
  • ネットワーク関連の設定を一切しなくても、Public IPとPrivate IPが自動で振られた! f:id:Anorlondo448:20181018182951p:plain
  • Private IPはVPC Peeringで別VPCと接続した時の通信に使うっぽい
  • VPCPeeringの設定は「アカウント」内にある(ちょっと難し目の設定は切り離されてるのかな?) f:id:Anorlondo448:20181018183104p:plain
  • 「法律上のおしらせ」という、プライバシーポリシーやカスタマーアグリーメントページへのリンクがあった f:id:Anorlondo448:20181018184600p:plain
  • 全体的に親切&あちこちでテンションが高くて何か嬉しくなる f:id:Anorlondo448:20181018175216p:plain f:id:Anorlondo448:20181018183848p:plain

EC2を普通に建てたほうが良さそうな点

  • 自分でprovisioningしたり、ネットワーク調整(Publicアクセスしないようにしたり)したいときとかかな・・?
  • 他のリソースに繋ぐときは、リソースがあるVPCとVPCPeeringして繋ぐ形になるので、他リソースと接続する前提なら普通のEC2のほうがよいかも

感想

  • 全体的に優しさに溢れていてわかりやすい&親切!
  • 料金体系わかりやすい&安い
  • ちょっとした検証をしたいときなど、手軽に建てらててすごい便利
  • Lightsail使っていくぞ!

API Gatewayをはじめよう③(リソースで設定する項目)

前回

この記事は何?

  • リソース(resource)を作成する時に指定する項目やパラメータなどについて調べました

「リソース」の設定項目ざっくりまとめ

  • リソースで定義したリソースPATHは、API Gatewayを呼ぶ時のendpointのPATHの一部として使われる
    • /searchとか
    • /detailとか
  • プロキシリソースとして設定すると、全てのPATHのリクエストを処理してくれる
    • /search とか /detail 個別に処理するのでなく/配下をまとめて処理してくれる
    • backend側で上記のPATH情報が取得できる
  • CORS設定をしてクロスドメイン通信を可能にできる

リソース設定内の項目について

プロキシリソースとして設定

greedyパスパラメータegを使用して全てのサブリソースへのリクエストを処理します
{proxy+}. プロキシリソースを作成すると、ANYと呼ばれる特別なHTTPメソッドも作成されます。
ANYメソッドは全ての有効なHTTP動詞をサポートし、1つのHTTPエンドポイントまたはLambda統合にリクエストを転送します

greedyパス

  • 一般的なPATHに分類されるrequestのグループのPATHと動作を個別に指定する代わりに、PATHへの全てのrequestを傍受してそれらを同じ機能にルーティングする

リソース名

  • リソースの名称
  • どこで使われてるかわからん
  • 入力時にリソースパスと連動しているように見えるけど、別のものを入力できた
  • 保存後、確認できる場所なし(リソースパスは見えるが・・・)

リソースパス

波括弧を使用してパスパラメータを追加できます。
たとえば、リソースパス {username} は、"username" という名前のパスパラメータを表します。 
プロキシリソースとして /{proxy+} を設定すると、そのサブリソースへのすべてのリクエストがキャッチされます。
たとえば、/foo への GET リクエストがこの対象となります。
/ へのリクエストを処理するには、/ リソースで新しい ANY メソッドを追加します。
  • endpontのPathとなる文字列
  • {}で囲むとパスパラメータとなり、backend側(Lambda)で指定した文字列を取得できる

リソースパスをlambdaで取得してみる

  • プロキシリソースでリソースパスを{/proxytest+}とし、 /testPathへアクセスしてみる f:id:Anorlondo448:20181013190825p:plain
  • Lambda側は受け取ったeventを出力するようにしておく
console.log('Loading event')

exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify(event)
    };
    return response;
};
  • 結果(一部抜粋)
{
  "resource": "/{proxytest+}",
  "path": "/testPath",
  "httpMethod": "GET",
  "headers": null,
  "multiValueHeaders": null,
  "queryStringParameters": null,
  "multiValueQueryStringParameters": null,
  "pathParameters": {
    "proxytest": "testPath"
  },
  • 任意のPATHでLambdaまで処理が渡ってた!
  • 階層を深くして、/testPath/param1にアクセスしてみる f:id:Anorlondo448:20181013194044p:plain
"pathParameters": {
    "proxytest": "testPath/param1"
  },
  • 取れてた!PATHごとに個別に設定したくないときはまとめられて便利!

CORSを有効

API Gatewayはプリフライトリクエストに応答し、小規模なパフォーマンスの向上が得られます。
この選択では基本的なCORS設定でOPTIONSメソッドを設定し、全てのオリジン、全てのメソッド、および複数の共通ヘッダーを許可します。
この設定を更に制御する場合は、リソースの作成後に[アクション]ボタンの[CORSの有効化]を選択できます

プリフライトリクエス

  • サーバから応答するメソッド一覧を収集する
  • リクエストを投げる前に、そのリクエストが受け入れられるか事前にチェックする

次回

  • メソッド(Method)について

API Gatewayをはじめよう②(API Gatewayの階層)

前回

この記事は何?

  • AWSコンソールで設定できる項目を書き出した
  • API Gatewayのリソースの階層(API、リソース、メソッド)について
  • リソースやメソッドなどについては次回以降書きます

項目全体

  • API
    • リソース(Resource )
      • メソッド(Method)
        • メソッドリクエスト(Method Request)
        • 統合リクエスト(Integration Request)
        • 統合レスポンス(Integration Response)
        • メソッドレスポンス(Method Response)
    • オーソライザー(Authorizer)
    • ゲートウェイのレスポンス(Gateway Response)
    • モデル(Model)
    • リソースポリシー(Resource Policy)
    • ドキュメント(Document)
    • ダッシュボード(Dashboard)
    • 設定(Setting)
  • 使用量プラン(Usage Plan)
  • APIキー
  • カスタムドメイン
  • クライアント証明書
  • VPCリンク
  • 設定

API Gatewayのリソースの階層

  • 最上位は「API
  • その下にリソース(resource)、更にその下にメソッド(method)を作る
    • メソッド(method)には以下4つがある
      • メソッドリクエスト(Method Request)
      • 統合リクエスト(Integration Request)
      • 統合レスポンス(Integration Response)
      • メソッドレスポンス(Method Response)
  • リソースのPATHがendpointの一部となる

次回

  • リソース(resource)について

API Gatewayをはじめよう①(Blackbeltを見て、API Gatewayがどんなことができるか知る)

この記事は何?

  • API Gatewayの奥が深すぎて、全てを理解するには時間が掛かりそうだから少しずつ触って吸収していくためのoutputです。
  • 果たしてこの順番でやっていくのが正しいかわかりませんが、一通りやったらどの順番が良いか改めてまとめ直す予定です。

まず最初に

  • Blackbeltを見て、API Gatewayがどんなことができるかを知りました
  • しかし2016年の資料なので、現時点(2018年)の仕様とは異なるかも
    • SlideShare中はACM未対応となっているが、現在は対応しているなど

Blackbeltから学んだ「API Gateway」とは

  • API管理の課題を解決してくれる
    • APIのバージョン管理
    • モニタリング
    • 管理とマネタイズ
    • 認証とアクセス権限の管理
    • トラフィック管理
    • アタックからの保護
    • インフラの管理とメンテナンス
  • responseをキャッシュしてくれる(TTL3600s)
  • 内部的にはCloudFrontを使っている
  • 「Usage Plan」という、外部にAPIを提供するときの無料/有料プランみたいなのが作れる
    • APIキーの所有者が使用できるリソースを制限するなど
    • 秒間リクエスト/バーストの許容/リクエスト可能数など
  • 認証・認可(※後述)
  • request/responseを他のデータ形式に変換できる
    • レガシーなbackendからのレスポンスをフィルタしたり、プライベートな情報を削除したり
    • GETリクエストのクエリストリングを元にPOSTデータを作る
    • LambdaからJSONを受け取りXMLに変換
    • Mockを作って、固定レスポンスを返すなど
  • API Gatwayと通信するためのSDKを生成できる
  • API定義をimport/exportできる
    • Swagger V2.0定義ファイルをサポート
  • backendにLambdaやEC2などと通信できる

価格

  • $4.25/100万リクエス
  • キャッシュのプロビジョニング料金
    • 何GiBキャッシュするかをコミットしておく

認証・認可

  • AWS Signature Version 4
    • IAMポリシーをアタッチしたIAMユーザのcredentialを使ってリクエストに署名
    • CognitoとSTSのようなtemp credentialを利用するとIAMロールと紐づく形で認証・認可が行われる
    • API Gatewayが生成するクライアントとSDKを利用する場合は自動的に利用可能
  • Custom Authorizer
    • OAuthやSAMLなどのベアラートークンを用いてAPIへのアクセウsを管理
    • lambdaファンクションを用いてAuthirozationヘッダの値を検証する
    • backendの呼び出し前にトークンの検証を行うファンクションを呼び出す
  • Cognito User Pools
    • User Poolsで認証を行う
    • 取得したIDトークンを基にAPIコール
  • いずれもメソッド単位で指定可能

次は

  • API Gatewayを構成するリソース郡を見ていく

ENI(Elastic Network Interface)の上限数について調べてみた

概要

  • AWSコンソールで確認したところ、ENIの制限数が350なのに、350以上のENIが存在していた
  • ENIの制限事項を調べたら、オンデマンドインスタンスの上限でも決まることがわかった
  • LambdaやECSタスクのENIもカウントされることがわかった

ENIの制限 

LambdaのENI使用数

ECSタスクのENI使用数

プライバシーポリシー