血と汗となみだを流す

クラウドエンジニアになるための修業の場

KubenetesのapiVersionに指定する項目について調べた

概要

  • KubernetesでPodとかReplicaSetをyamlで作るときの apiVersion の書き方が気になったので調べた

たとえば

  • Podの時
apiVersion: v1
  • ReplicaSetの時
apiVersion: apps/v1
apiVersion: extensions/v1beta1

気になった点

  • Podは何でv1だけで良いのか?

調べた結果

  • KubernetesAPIcoreとかappsとかのグループに分かれている。
  • coreはレガシーグループと呼ばれ、
    • RESTのPATHは/api/v1配下にある
    • apiVersionの指定はapiVersion: v1になる
    • Podはcoreグループ
  • その他のグループ(appsとかextensionsとか)は、
    • RESTのPATHは/apis/[グループ名]/[バージョン番号]配下にある
    • apiVersionの指定はapiVersion: [グループ名]/[バージョン番号]になる
    • ReplicaSetはappsグループ、Ingressはextensionsグループ
  • 参考

まとめ

  • coreグループのAPIのみ、apiVersion: v1という形式になる
  • 他グループのAPIapiVersion: [グループ名]/[バージョン番号]になる

インフラエンジニアのためのAPI Gateway入門〜API Gatewayがわからないからわかったところだけ伝える〜

この記事は #インフラ勉強会 Advent Calendar 19日目(12/19)の記事です!

adventar.org

概要

  • AWSのマネージドサービス「API Gateway」についての記事になります。
  • サービスの内容について書こうと思いましたが思った以上に奥が深く、すべてを把握することが出来なかったため、「どんなものか」をふわっと伝える内容になります。
  • ※完全に筆者の主観で書いているため、認識の齟齬や間違いが含まれている可能性がありますのでご了承ください。

内容

  • API Gatewayの使い所
  • 他のマネージドサービスと違うところ

API Gatewayの公式ページ


API Gatewayの使い所

  • Lambdaの前段として
    • AWSサービスと組み合わせて使う場合は主にLambdaとの組み合わせになるかと思います
    • LambdaはREST APIのような形式で実行できないため、Lambdaを実行するためのAPIとして使われることが多いようです
      • 2018年11月のバージョンアップで、ALB(Application Load Balancer)のbackendにLambdaが指定できるようになりました
      • 既存のendpointがALBで一部のPATHのみLambda、のようなことができるようになりました
  • APIの抽象化として
  • backendのリファクタリングをしたいが、APIの呼び元からの実行形式を変えたくない場合など、API Gatewayを挟んで抽象化しておくことができます
  • レスポンスのキャッシュ機能
    • backendからのレスポンスをAPI Gatewayがキャッシュすることができるため、backendの負荷を減らすとともに応答速度の向上が見込めます
    • ただしキャッシュするデータ量によってコミット料金が掛かるのでキャッシュするデータと料金の兼ね合いになるかと思います

他のマネージドサービスと違うところ

  • バージョン管理と環境別デプロイ
    • 「ステージ」という機能があり、API Gateway単体でバージョン管理や環境別デプロイが実施できます
    • AWSアカウントで環境を分けてたりする場合、API Gatewayだけどうしたもんかと悩むなど・・・
  • 性能の制限を設定できる
  • APIキー毎にキャパシティの制限が掛けられます。
    • 例えば外部に提供するAPIを、無料/有料で使用できるキャパシティを変えるなど
    • ↑実際やっているという例を聞いたこと無いけど・・・
  • SDKの自動生成機能
  • 言語固有の方法でAPIを実行するときのSDKを生成する機能があります。
  • 一部のメソッドで対応していない言語有り(ANYメソッドでRubyのSDKは出力できない)

まとめ

  • SDK周りがまだ不安定ですが、REST APIとして使う分にはとても良い
  • APIを提供する機能だけでなく、横も縦も幅広い機能です。正直全部理解できる気がしない。がんばる

API Gatewayをはじめよう⑦(ANYメソッドでRubyのSDKは出力できない)

この記事は何?

  • API GatewaySDKRubyで生成しようとしてエラーになり、ハマった記録です。
  • ※2018/10/31現在

ハマったポイント

  • 作成したリソースをデプロイし、SDKの生成をしようとしたらエラーとなった。
  • 公式ドキュメントを見てもどこにも記載がなかったのでAWSのサポートに聞いた
  • サポートに聞いたところ「ANYメソッドではRubySDKは対応していない」とのことだった
  • GETやPOSTメソッドならSDK生成できた
  • Javascript Androidなど他のプラットフォームは出力できた

発生する条件

  • メソッドを「ANY」で作成する
  • ステージにデプロイし、SDKの生成でプラットフォームをRubyにする

発生する現象

  • 以下のエラーが出て、SDKが出力されない
Generation failed during BUILD stage: no operations found for the service

f:id:Anorlondo448:20181014232444p:plain

結果

  • ANYメソッドがサポートされるまで待つか、GET/POSTなどのメソッド単位でリソースを作成するしか今はなさそう

前回までの記事

API Gatewayをはじめよう⑥(メソッドリクエスト(Method Request):APIキー/使用量プラン)

この記事は何?

  • API Gatewayのメソッド(Method)で、メソッドリクエスト(Method Request)で設定する項目と、使用量プランについて調べた結果のまとめです
  • メソッドリクエストだけでも内容がいっぱい詰まっているので、その中のAPIキー部分を書いています
  • APIキー使用量プランと関連づいているので、使用量プランについても書いています

APIキーと使用量プランとは?

  • API キーを使用する使用量プランの作成と使用
  • APIキーはユーザ認証に使う物では無い
  • 使用量プランと合わせて、APIキーごとのリクエストの制限を行う
    • このキーはこの制限まで、こっちのキーはこの制限まで、みたいな使い方
  • 使用量プランとは
    • APIキー毎に「1秒あたりのリクエスト数はこれだけ」「一定期間内のリクエスト数はこれだけ」などを設定する
    • たとえば、Aプランはここまで使えて、Bプランはここまで使える、みたいなパターンが作れる

APIキー

作成

  • 左ペインのAPIキーから[アクション]-[APIキーの作成]で作成できる f:id:Anorlondo448:20181030220126p:plain
  • 名前説明を入力する
  • 自動生成カスタム(自分で入力)を選ぶ f:id:Anorlondo448:20181030220153p:plain
  • これで生成完了する
  • APIキー 表示でキーの文字列が表示できる f:id:Anorlondo448:20181030220220p:plain

編集

  • 名前説明を入力する
  • APIキーの有効/無効を切り替えできる

プランに関連付ける

  • 使用量プランを作成しておく必要がある

使用量プラン

生成したAPIキーを実際使ってみる

  • メソッドリクエストのAPIキーの必要性をtrueにする f:id:Anorlondo448:20181030220454p:plain
  • ステージにデプロイする
  • APIキー無しでアクセスしてみる
$ curl https://xxxxxxxx.execute-api.us-east-1.amazonaws.com/dev/postlambda
{"message":"Forbidden"}
  • APIキーを付けてアクセスしてみる
$ curl https://xxxxxxxx.execute-api.us-east-1.amazonaws.com/dev/postlambda  --header 'x-api-key:xxxxxxxxyyyyyyyyzzzzzzzzaaaaaaaabbbbbbbb'
{"statusCode":200,"body":"\"Hello Elastic!\""}

次回

  • 認証周りを少しずつでも理解する!

前回までの記事

SendGrid Send With Confidence Tourに参加しました

この記事は何?

Eメールはオワコン?

  • メールの利用自体は増え続けている
  • メールによるコミュニケーションが好まれている
    • デジタルコミュニケーションに必須
    • 最も普及しているデジタルID
    • あらゆるWebサービスのIDとして利用されている
      • ECサイトSNSの登録時はメールアドレスがほぼ必須
    • 一般消費者がセキュアに利用可能
    • 非常に高いROI
  • 用途は変化したがメールは生き続け、サービス提供の上で必須なものとなっている

難しいメール配信

  • 正当なメールの20%が受信トレイに到達していないという調査結果がある

メール戦略

  • EメールはどのチャネルよりもROIが高い
    • $1投資で$38のリターンがある
  • 送られる時間、件名の長さ、絵文字の使用などの違いによる効果を知ることが大事
  • 近年メールを送る件数は減っている
    • 対象をしぼってメールを送ることで開封率やクリック率をあげる
  • 誰が購読者であるかを理解することにより、戦略を建てる
    • 女性が多い、モバイルが多い、など
  • よく寝られた戦略をもってメールを送信する必要がある
    • Subject Line(件名)
    • Copy(コンテンツ)
    • Image(画像)

Subject Line(件名)

  • 最初に購読者の目に入る物
  • これが購読者の心に響かないと行けない
    • ディスカウントだったり、質問だったり、続きが気になるようなもの
    • 懸命にいくつの単語を含めるのがよいか
      • 7単語 が平均的(英単語で?)
      • 4単語が最もengagementが高い
  • モバイル機器で長い件名は不利
  • 絵文字は?
    • 何を提供しているかがわかりやすい
    • 受信箱の中で目立たないといけない
    • 差別化はできるけど、受信箱の中で目障りになってしまうかもしれない
    • 受信箱に正しく表示されるのかテストが必要
  • 件名にFirst Nameを使ってもengagementは上がらない
    • 「◯◯さんにオススメ!」みたいなやつ
  • First Name以上の何らかの惹きつけるものが必要

Copy(コンテンツ)

  • 統一的なトーンを使う
  • ユーモアなど、購読者に響くものを使う
    • あえて砕けた表現をつかって、限定的な層を狙うなど
  • 誰かを排除するようなトーンは使わない
  • いろいろなデバイスで受信されるので、デバイスにあった表示方法
  • メールに商品情報を載せてしまって、商品購入までのステップを減らす

Image(画像)

  • 多くの画像を入れすぎないようにする
  • たくさん画像を載せるのでなく、メールの内容に合うものを入れよう

メール送信者と受信者の関係の構築

  • 受信者が送信者をどう考えているか?を考える
  • Eメールの開封率やクリック率が低い場合は、受信者との関係を見直さないといけない
  • SendGrid側で実績や数値などのレポートを作成している
  • 信頼関係を増すには「特別感があるか」など、購読者第一を考える
  • コンプライアンスも重要
    • 地域性による規制
    • 日本でもメール送信の同意が必要であり、解約方法も明示的でないといけない。

SendGridについて

  • 74,000以上のユーザが利用している
  • 毎月450億通以上のメールを送信しており、送信件数は増加の一方である
  • SendGridの支部は日本に無いが、株式会社構造計画研究所が代理店をやっている
    • 日本語Webサイト/ドキュメント/サポート/日本円決済などの日本向けサポート
  • SendGrid社がTwilioによる買収されるが、SendGridのサポートに変化はない
  • 毎年ベンチマークレポートを出している
    • 近年メールを送る件数は減っている
    • 対象をしぼってメールを送ることで開封率やクリック率があがる

SendGridの始め方

  • サイトアクセスし、アカウント作成する
    • 悪用されるのを防ぐために、アカウント作成の前に審査がある
  • 無料で12,000/月送信可能で、ほぼすべての機能が使える

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沼にハマってて中々進まないけど、認証からめたメソッドリクエストをやる
プライバシーポリシー