「Amazon API Gateway 経由でちょっとしたアクセスを流してみた」 #aws #jawsug #api #駅すぱあとWebサービス
こんな↓を記事を書いて 駅すぱあとWebサービス を API Gateway 経由で呼べるように設定をしました。
今回はこの環境を使って API Gateway のキャッシュ設定を有効にして、ちょっとした数のアクセスを流してみようと思います
まずは設定済みの Stages 画面に移動します
prod という stage 全体に関しての設定を行っていきます。Stages ペインの prod を選択して以下の画面から各種設定やSDKの作成、デプロイのロールバック等を行います。今回はまずSettings タブを選択して設定を行っていきます
Cache Settings について
Enable API cache 項目にチェックを入れて Cache capacity で必要に応じたキャッシュ容量を選択して、画面右下にある [Save Changes] ボタンをクリックして設定を保存します
設定保存後 Cache status が AVAILABLE となればキャッシュが有効になっているようです
CloudWatch Settings について
CloudWatch でアクセス数やレイテンシを確認するためには Enable CloudWatch Metrics の項目にチェックを入れて有効化する必要があります。CloudWatch でキャッシュヒットカウントも見ることが出来るので今回は有効化します。
他の値についても必要に応じてチェックを入れて有効化することにになります。
先ほどと同じく設定を保存する場合には [Save Changes] ボタンをクリックしてください
Throttling Settings について
スロットリングの設定について以下のドキュメントに Burst Limit と Rate の両方ともに 「The default setting is 1 request per second.」との記述があり1 秒間当たりのリクエスト数を指定するようです
よくある質問 - Amazon API Gateway （API を容易に作成・管理） | アマゾン ウェブ サービス（AWS 日本語）
今回はバックエンドの 駅すぱあとWebサービス無償版 の環境が借り物なので無茶しないように＆スロットリングの効果が分かりやすいように小さめの値を設定しています
メソッド個別の設定について
前述までの内容は prod stage 全体の設定を行っていました。API Gateway ではメソッド単位でこの全体設定を Override することが出来るようです
Settings が Inherit from stage の場合は全体設定がそのまま適用されます。Override for this method が選択されていると、Cloudwatch Settings と Throttling Settings を上書きすることが可能となりメソッド個別の設定を行えます
Cache タブについては Encrypt cache data を有効化するかどうかと Cache time-to-live (TTL) の設定が行えます
ここでUI設計の小さな罠があります。Settings と Cache は別々のタブとなっているので一見すると関係がなさそうですが、Cache タブをデフォルト状態から変更して [Save Changes] ボタンをクリックして変更を保存すると、もれなく Settings タブ側のSettings が Override for this method に変更されます
また逆にCache タブを設定したあとにSettings タブ側で Inherit from stage を選択保存してしまうと、Cache タブでの設定がデフォルトに戻るようです
Stage 全体の設定と同様に 同じタブ画面で Cache 設定も変更・保存出来ればこんなにわかりにくくならないと思うのですが・・・気が付かないと知らない内にメソッドの設定が Override for this method になるため、スロットリングの設定値やCloudWatchへの値の出力がされないなど挙動に関わる部分で怪しくなるので注意が必要です
また、これはAPI Gateway のUI全般に言えることなのですが、[Save Changes] ボタンをクリックして変更を保存しても、画面の内容が切り替わらないことが多いです。一旦別の画面に移動して戻ってくるか、ブラウザのリロードを行うことで解消しますがこの辺りも不便なのでカイゼンされると嬉しいですね
SDK Generation について
API Gateway の凄い機能の1つにSDKの作成機能があります。これは設定情報を元にSDK化してくれるもので、JavaScript用のSDKであればボタンをクリックするだけの手軽さです
選択できるPlatform は現在
の3つですが今後対応言語が増えるのかどうか楽しみですね
Deployment History について
文字通りこれまでのデブロイが記録されており反映したい対象を選択して [Change Deployment] ボタンをクリックするだけで、指定したバージョンに変更することができます
ロールバックもロールフォワードもボタンをクリックするだけとなります
実際にアクセスを流してみた
設定が完了したので実際にAPI Gatewayにアクセスを流して色々と見てみる。Apache Bench で軽く実行すればいいかと思ったら・・・なんだか上手くいかない？なんでだろうか？と思って調べてみるとこんな↓情報が！
AWS Developer Forums: Benchmark URL (with ab, wrk, or siege) ...
どーやら API Gateway 側の SSL/TLSハンドシェイクがTLSv1を強要する そうなのでこれに対応してないとダメということですね。
そんなこともあろうかと！というか使うタイミングがなくて検証してなかったこれ↓を使うことにします
名前とREADME.md の画像であとはわかるな！ではなく、これgolang で書かれていて中々の高機能っぽい感じなので1回使って見ようかと
golang なのでリリースページからバイナリをダウンロードして展開＆実行権限付与で準備は完了
今回は複雑なことはしないのでUsageに書いてある以下の形で
echo "GET http://localhost/" | vegeta attack -duration=5s | tee results.bin | vegeta report
-rate=50: Requests per second オプションと -duration=10s: Duration of the test を変更して http://localhost/ のところをAPI Gateway のアクセス先URLに変更しただけの簡単なもので試しました
Throttling Settings はBurst Limit ＆ Rate 共に3でキャッシュは0.5GBで有効化しています。メソッド個別設定はなく全体設定のみで実行しました
通常のアクセス
httpie によるアクセス
レスポンスヘッダーで Content-Type: application/xml;charset=utf-8 をちゃんと戻せています。最初の1回目からなのか X-Cache: Miss from cloudfront となっていました
簡易的なグラフであればAPI Gatewayの Dashboard で確認することが出来ます
更に詳細を見る場合には設定を行った CloudWatch で確認可能です。Backplane に ApiName として API Gateway で作成したAPI 名称が登録されているので必要な Metrics を選択して表示を行います。
2015/07/21 18:22 現在確認すると ApiGateway の ApiName という項目もあるようなのでこちらに統合されたりするのな？
未検証ですが・・・
また、Backplane に ApiName として表示される一覧には削除済みのAPI 名称がありこれの削除方法が見当たらない感じです。何かご存知であれば教えていただけると大変助かります。もしくはアップデート待ちなのか？？
2015/07/22 11:00 追記
どーやら ApiGateway > ApiName の方に統合された感じです。Backplane > ApiName の方は選択可能ですがグラフに値が出力されていない感じです。
この変更と共に ApiGateway > ApiName,Label や ApiGateway > ApiName,Label,Method,Resource などの細かい選択も可能となっています。
またBackplane > ApiName に値が出力されない為、これを参照している API Gateway の Dashboard のグラフも0直線のままです。今後修正されると思いますが・・・
Vegeta を利用したアクセス
以下のコマンドを流してみた時の実行結果とCloudWatch のグラフを見てみました
date
echo "GET https://xxxxx.execute-api.us-east-1.amazonaws.com/prod/station?name=東京&key=xxxxx" | ./vegeta attack -duration=10s -rate=200 | tee results.bin | ./vegeta report
10秒間のテスト実行で Requests per second は200の設定なので合計2,000アクセスを流すことになる。スロットリングの設定などは前述の通り。
Requests [total, rate] 2000, 200.10
Duration [total, attack, wait] 10.39498803s, 9.994999778s, 399.988252ms
Latencies [mean, 50, 95, 99, max] 17.649175ms, 12.397154ms, 51.867609ms, 648.366432ms, 648.366432ms
Bytes In [total, mean] 43265, 21.63
Bytes Out [total, mean] 0, 0.00
Success [ratio] 2.25%
Status Codes [code:count] 200:45 429:1955
Error Set:
429 Unknown
上記の場合で Status Codes の部分に注目すると 200 で帰ってきているのが45、429で帰ってきているのが1955 ということが分かる。テスト時間が10秒なのでこのぐらいの値でいい感じなのかな？そうーなると2回目以降に若干の疑問がのこります・・・
ちなみにトークンバケットアルゴリズムというものを利用してこの辺りを処理しているそうです
Note
API Gateway uses the token bucket algorithm for Limited throttle settings. For more information, see the Average rate and Burst size sections on the Token bucket page on Wikipedia.https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-stage-settings.html
次にCloudWatch のグラフを見てみます
CacheHitCount、CacheMissCount、Count、Latency を表示してみたグラフになります。このままだと分からないのでまずは Count のみを表示してみました
次は CacheHitCount のみを表示してみました
画像だと見づらいのですが、Count と CacheHitCount が同値の部分がありすべてキャッシュで解決されている様子が確認できました。
そーなるとリクエストヘッダーに必ず付いてくる X-Cache: Miss from cloudfront のヘッダーが気になります・・・
連続してアクセスを行ってみても↓のように X-Cache: Miss from cloudfront となっています
CloudWatch のグラフを確認してみるとやはりキャッシュにヒットしているようです
X-Cache: Miss from cloudfront は気にしないでいいような感じかも知れません。今後不要なヘッダーであれば削除される方向になると有難いなーと思います
まとめ
- API Gateway で作ったAPIに実際にちょっとアクセスを流してみた
- スロットリングの設定をして効いてる感じが分かった
- キャッシュにヒットしてるのも確認できた
- X-Cache: Miss from cloudfront は気にしないでいいかもしれない
- blog書いている途中にAPI Gatewayの画面が変更されてたりした
- UIに関してはじゃんじゃん改善してほしい
- データがあってAPIが無いとか、APIのマネージメントが大変とか利用出来そうなところがいろいろあって楽しみなサービス
- 今後の改善にも期待しています！
以上。
