JAWS-UG 千葉支部 Vol.5 ～秋のAWS Lambda & API Gateway 祭り！！～ の参加メモ #jawsug #chibadan
↓なイベントに参加して
その後の懇親会でLTしてきましたので、簡単なメモを
会場は渋谷ヒカリエにあるmedibaさん。オシャレ！
以下メモ（個人的感想含む）
1.クラウドネイティブ化する未来
- ADSJのSA 西谷さんの話からスタート
- 最初にもらったオーダーは「AWS LambdaとAmazon API Gateway概要」というテーマ
- だけどそれは「AWS Black Belt Tech Webinar」でやったからそっちの資料を後でみてください
- 本当は30分間RESTful APIの話をしてやろうかと思ってましたw
- クラウドファーストはもはや当たり前
- 時代はクラウドファーストからクラウドネイティブへ
- クラウドのマネージドサービスをフル活用したアーキテクチャ
- 例えばサーバーレスアーキテクチャとしてEC2を使わないでAPI Gateway + Lambdaを用いて実装する
- これにより本来の目的であるビジネスロジックに集中できる
- マネージドサービスのため可用性やキャパシティ、セキュリティなど重要だけど手間がかかる部分に手を割かなくて済む
- 仮にEC2を使う必要が出てきても柔軟に組み入れることが可能
- ただしその場合はCodeDeploy、Elastic Beanstalk、OpsWorks等のサービスを利用して自動化は必須
- これで利用者は自分の一番したいことを「何がしたい」のか記述するだけでいい
- 時代はAPI！いよいよ日本にもAPI時代が来た！
- API Gateway に登録する際はマネージメントコンソールからポチポチ登録するとしんどい
- なのでSwaggerを利用して登録しましょうーみんなそうしてる
- /pets のようにRESTfulでリソースを定義するときは複数形の名詞にするのがいい。これは豆知識だそうですよー
- 「クラウドを使って楽をしよう」
- 現状だとすべてがそこに行けるわけではないけど、行ける部分はどんどん持って行った方が幸せになれるなーと感じた
2."時間の流れ" という無限リストを扱うAWS Lambda
- blogでおなじみの会社クラスメソッドの 都元さんのお話
- 自己紹介での人間CloudFormer！！
- API Gateway成分はゼロですｗ
- そしてLambda が出てくるのも後半の方にちょっとだけあるかなぁーどうかなぁー
- バッチ処理について
- 定期的なバッチ処理には色々と考えなくてはならない課題がある
- cronでバッチサーバを運用するのはよくある話
- 発火のタイミングはどうする？冗長化は？とか
- ジョブスケジューラー（JS）とジョブワーカー（JW）に分割して考える
- JWのMulti-AZ化は簡単で、SQSのProducer / Consumerパターンを利用すればいい
- JS側は簡単にはいかなかった
- 解決策その1としてBrian というOSSを作った
- QuartzというJava製OSSジョブスケジューラーが元
- 高機能だが複雑な為変更が困難
- また稼働にはRDS＋EC2を4台使うのでコストも高い
- 解決策その2としてJimmy
- 中身はこちらもQuartzを利用
- DynamoDBとSNSを使い単純化
- やっと Lambdaの登場ｗ
- そしてLambdaに要望！デプロイパラメータが指定したい。指定したパラメータはcontextから読み出したい
- Lambda Functionにタグがあればタグで解決できるかも知れない！
- タグが存在しなかったｗ
- configuration中のDescriptionに突っ込めばいけるんじゃないか案ｗ
- バッチ処理でみんな同じように悩んでるのでAWS側にスケジューラーが追加されたら嬉しいなぁ
3.モバイル✕API Gateway ときどきLambda
- NRIネットコムの 佐々木さんのお話
- AWSの一番分厚い本ｗ 書いてます
- WEB+DB PRESS Vol.88 にも記事書いてます
- Rubyによるクローラーの本も書いてます
- 会社にはPepperとNAOが居ます
- ちょっとアンケートを取ります。手を挙げてください。
- アンケートに全部該当した人はもう今日帰っていいですｗ
- モバイルアプリ開発の課題として、バースト時のサーバサイドのスケーラビリティの問題やOSや端末の多様化の問題がある
- 外部要因による開発期間が短くなる問題もある
- モバイルプッシュの後のサーバ負荷が半端ない
- 課題は2つに集約される。1つはサーバサイドの開発運用に関して。もう１つはアプリサイドの工数とリリース期間の短縮に関して
- AWSを利用するとどーやってカイゼン出来るのか？
- API GatewayのWebinarを聞いた時の感想は「全員失業だな。転職の準備をしようｗ」
- API GatewayのMock機能を利用してモバイルアプリ開発を行う
- 簡単に静的JSONを返すAPIを作れる
- おまけにレスポンスコードも変えられる
- 今度はLambdaを組み合わせてAPIの遅延を再現する
- Lambda側でSleep処理を入れることでレスポンスの遅いMockを作れる
- これを利用することによってUI/UXを適切に調整する
- 今資料を共有しているサービスをAPI Gatewayで置き換えてみた
- Mapping Templateは最初の難関
- API Gatewayの感想は基本的は簡単便利
- Getは簡単だけどPostは悩む
- 1つのリソースにGet/Postなどのメソッドは各1だけ
- CROSなどの情報が少ない
- マネージメントコンソールはよくできてるけど面倒
- CLIとか他のツールを使うことを検討中
- 実際の使い方や細かい説明も色々とあって非常に参考になりました
LT1.ラズパイからセンサーデータをAPI Gateway+Lambdaに送るよ
- ハンズラボの今井さんのお話
- 千葉県出身なのでJAWS-UG千葉にやってきましたｗ
- 小学校から大学まで千葉でした
- ハンズラボにはIoT部がある
- それに入るとラズパイを買ってもらえる
- 面白そうなので入ってみた
- そしたら本当にラズパイを買ってもらえたｗ
- ついでにセンサー類も買ってもらえた
- 買ってもらったので使ってみるが、せっかくだからAWSと組みわせる
- で、使おうと思ったらラズパイはデジタルセンサーしか使えない
- 買ってもらったセンサーはアナログでした・・・
- 調べ見たらAruduinoはアナログセンサーが使えるらしい
- なので、ラズパイ＋Aruduino＋アナログセンサーで使う
- センサーデータの値をAWSに送って可視化
- API Gateway＋Lambdaで作ってみる
- awkを通すと何も表示されなくてはまる
- mawkを使うと表示された
- Aruduinoが出力する改行コードがCRLFではまる
- DynamoDBと更新用のLambdaを作ってAPI Gatewayからたたけるようにした
- DynamoDBStreamとLambdaを使ってCloudWatchでデータを可視化した
- 料金は使った分だけなので今回は無料枠に収まり0円
- センサーは面白い！
- DynamoDBStream＆LambdaでCloudWatchにてデータ可視化は手軽でいいなぁーと
LT2.EC2レスに挑戦！ フルマネージドのポイントシステム
- ハンズラボの加藤さんのお話
- シンガポール店向けのポイントシステムとして実際に構築中の内容
- 好きなAWSサービスはLambda
- このマークが歩く寝袋に見えるｗ
- 何故EC2レスでフルマネージドサービスに拘るのか？
- 単純にエンジニアとしてわくわくする
- コスト圧縮になるため
- 運用が大変なのでこれもリソース圧縮できる
- あと、ボスの意向ｗ
- 動的なデータはすべてJSONにしてトラフィックを軽減している
- 静的なファイルはCloudFront
- 動的な情報をJSONで変更するのはAPI Gateway＋Lambda
- デザイン（画面構成？）の描画はクライアントのAjax
- API GatewayのAPI Keyは認証に使ってはだめ
- JWTというものがある
- 課題としてポイントのリアルタイム性をどう担保するか
- レイテンシーの問題
- Lambdaも1つのFunctionだけだと楽だけど共通化とかを考える面倒事が増える
- 認証周りの実例は聞きごたえありで非常に楽しかった
- ハンズラボさんぐらいの規模で大丈夫なら弊社でも使える仕組みだなーと
ここで本編終了ー
で、この後は懇親会でのお話に
懇親会LT1.API Gatewayで re:Inventのセッション探し
- SUPINF の@pottavaさんのお話
- JAWS-UG コンテナ支部の中の人
- 次回のコンテナ支部は2015/09/14（月）にあるよ！参加してねー
- ECSのメンバー来日してるので話してくれる予定
- re:Inventのセッション検索APIをAPI Gatewayで使ってみたら凄いのでは！？
- セッション検索・・・APIじゃなかったｗ
- ないなら作ればいい！なので作りました！！
- API GatewayとECSを使った構成で動かしてる
- さすがコンテナ支部！！
- そしてAPIはgolangで書かれてるじゃありませんか！素敵！！
- Lambdaでいいんじゃ？ｗ
- 切り口が楽しいLTでしたー
懇親会LT2. まだオンプレと同じ監視をして消耗してるの？
- blogでおなじみの会社クラスメソッドの 大栗さんのお話
- 資料がUPされてない？？
- 監視の話？この時懇親会が丁度盛り上がってたので・・・
- 途中でHeroku が提唱しているTwelve-Factor Appの話は出てた
- おまけにこのタイミングでナースコスも投入されたのでさらに撮影会が始まったりとなかなかの混乱ぶりがｗ
- 懇親会LT恐るべし
- まーblogの会社の中の人なので何かあればblogで公開されると信じてます！
- ちなみにHerokuはAPIのデザインガイドも公開していて非常に参考になりますよー
懇親会LT3.ドローンの安全運転をささえるLambda
- 次はドローンを持って登場の吉田さんのお話
- 会場でドローンを飛ばすと伺っていたのでてっきり小さい物かと思いきや・・・
- DJI社ドローン Phantom 3 じゃありませんか！！
- 間近で見るとやっぱり結構デカイ！さすがお高いだけあるかなぁー
- 先日あったMicrosoftのイベントでドローン取り上げられた
- そのイベント参加してそのセッションも見ましたが、すごい盛り上がりでした
- 海外ではドローンレースも盛ん
- 安全に止まることが一番重要
- 反復練習をしないと上達しないけど、やっぱり飽きる
- 何か楽しみながらやれる方法が必要
- IFTTTのDo Buttonを使って実現してみる
- Do Button→Slack→zapier→Lambda→DynamoDB
- いよいよ実際にドローンを飛ばしてのデモ！
- が、しかしドローン飛ばず！！
- キャリブレーションからやり直しなのでちょっと待ってｗ
- ちなみにドローンだとiPadの画面がタップ出来ないからDo Button押せないｗ
- 飛ばないというハプニングも含めて楽しいLTでした！
懇親会LT4.AWS SDK for Go を使って作ってみた話
- というわけで私ですｗ
- 直前がドローンが飛ばないドローンプレゼンのため会場のざわざわ感が半端ありませんｗ
- そして目の前ではドローンのキャリブレーションをやり続ける人が手にドローンを持ってドローンをグルグル回してました
- そんな楽しい雰囲気のなかLT出来た良かったです
- 伝えたいことをまとめると
- golang楽しいよ！golang！
- AWS SDK for Go の正式リリースまだですか？
- 高尾山に集合して欲しいんです！
- やっと公式に事例紹介されました！ちょー嬉しいです！！
- 以上！
- あーあとLambdaでGoが使えるようになると嬉しいなー
- というわけで、高尾山よろしくお願い致します
- 中央線と京王線で申込みが分かれてますが、会場は同じで内容も同じです
- 京王線側にはまだ余裕がありますので是非！
予定ではこれで懇親会LTも終了だったのですが飛び込みの参加者がっ！！
懇親会LT Ex1．Lambda を cron 的に使う
- 俺たちの松井さんのお話キター！！
- みんな欲しくて考えるLambdaをcron的に使う方法
- これまではS3→Lambda→S3でループさせる方法
- パティーンってｗ
- ただこれだと1回ミスするとそこでループが終了してしまう
- これを解消するのがマルチクラウドパティーンｗ
- Azure Job Scheduler と Lambdaを組み合わせる
- しかし、やはりAWSだけで実現するにはどうしたらいいのか？？
- Dead Dead Queue DeDeDeDe-Destruction パティーン
- SQSを2つ用意してDead Queue指定ののちお互いにキューを投げあう
- 一度も受信されなかったメッセージは Dead Queue には入らなかったとのこと
- Return to myself パティーン
- SQS、SNS、CloudWatch でアラームをトリガーにループが出来る
- これは面白い構成！そしてどれもお金のかからないサービスばかり！
- やっぱりAWSがスケジューラー的なものを用意してくれると嬉しいですねー
懇親会LT Ex2. JAWS FESTA 2015 の紹介
JAWS FESTA Kyushu 2015
- JAWS-UG 全国から金春さん
- 大阪から来ました。私のこと知ってますか？
- ここにいる人は全員 2015年11月3日に九州に来てください
- 今年のJAWS FESTAは九州でやります！
- もうちょっとしたら募集サイトとかも上がると思うので登録してください
- 今年は九州！！前後は平日かーうむー
2015/09/11 17:00 追記
申込みサイトが公開されました！
これで懇親会LTもすべて終了ですが・・・おや、前でドローンを持って変な踊り的な動きをしている人がいますねｗ
ドローンが飛んだのか飛ばなかったのか！？ナースコスってなによ？？って言う人は↓なまとめをご覧くださいw
盛りだくさんで非常に楽しいJAWS−UGでした！ほぼ1年ぶりの開催だそうですが千葉支部熱いですねーコアメンバーを募集中だそうなので興味ある方は是非！
運営ありがとうございました！また参加したいです。
以上。
社内新人向けAWS勉強会の講師をしてみた時のメモ #aws #jawsug #jawsug_bgnr
少し前になりますが今年弊社に入社した新入社員4人に向けて、AWSのハンズオンというか簡単な体験をしてもらう機会を貰ったのでその時の事をメモ程度に
新入社員に向けて社内で行われている開発体験研修の1コマとしてAWSのハンズオンがある感じで、他は↓な事をやってるみたいです
VAL の LABO: ヴァル研究所の新人研修【開発体験研修編】
そして書いてある通りに先生というか講師は全部社内の人が業務の合間を見ながら行っています。当然ながら通常であればこんなオッサンではなく人当たりの良い若い人が講師になるんですが・・・なぜか今年はオッサンに依頼がありました
最初は他にもっと相応しい人が他にいるので断ろうかと思ったのですが、丁度JAWS-UG初心者支部の第1回目に向けての流れを見ていて、AWSを全然触ったことがナイ人と一緒に色々と出来る機会は貴重なのかも知れないと考え受けてみることにしました
JAWS-UG初心者支部 | Doorkeeper
引き受けるとなったらまずは依頼元の要望やら目的をヒアリングしました。依頼したからには何かしらの意図があったりするだろうし、目的があるとわかりやすくなりますしね
ヒアリングで出た内容を元に、ざっくりアウトラインを作って依頼元に確認＆意見を貰うを行ってから資料作成を開始しました。しかし与えられた時間が11:00～17:30と長丁場なのが・・・時間の見積もりが全然わからんｗ
やはり公式の↓資料と
同じく公式の↓ブログは外せないし
ブログと言えば当然ながら↓も外せないなぁー
とか思ってたら、そもそもクラウドとは？的なところからの説明が必要あるとのこと・・・なんかハードルが上がった気がした瞬間でしたｗ
稚拙ながら↓な感じで資料を作り1時間程度の座学を行いました
資料のテンプレートは↓を利用しています。非常にいい感じでありがとうございます！
さて、次の要望は座学ばかりだと分からない場合は眠くなる！確かに！宜しいならば手を動かしてもらいましょうーってことで↓な資料を作り1時間程度ですが手を動かしてもらいました
この際にスケールアップはちょー簡単で性能向上を実感してもらうために↓なループするだけのコマンドラインプログラムを用意しました
次は手を動かしている中で疑問に思った部分が多々出てると思ったので、再び座学でそれを解消することにしました。ここも自前で資料を作ろうと思ったのですがADSJ さんが毎週開催している オンラインセミナーが素晴らしいので、その資料を利用しました
毎回無償で素晴らしい内容のセミナーをありがとうございます！毎回楽しく聞いてます！
今回はタイミングよく基本サービス特集だったので、以下のEC2の資料をお借りしました
どの資料を見ても非常によく纏まっていて全体を理解するのに大変助かってます。そして毎回この充実した内容の資料を作っているとは・・・凄すぎる
さて、ここまで進めて来て予定だと残り3つ資料を使おうかと思ってたのですが、やはり時間通りには進まず使えてあと1つが限界かなぁーという状況に
時間がないなら座学より手を動かそうってことで↓な資料で1時間程度ですが手を動かしてもらいました
実際にやってみるとまぁー終始バタバタしたり段取りの悪さで新人さんに迷惑かけまくり・・・大きなセミナーやらイベントやら勉強会やらで不特定多数の人に対してハンズオンしてる人はマジすげーなと実感しました
S3を使ったハンズオンではS3のスタティックホスティング＋ログの機能を見てもらおうと気軽に考えてたら・・・ログ出力はベストエフォート何ですね。勉強になりました。
なので、当日は↓なページを事前にS3でスタティックホスティングして受講対象者の皆さんにジャンジャン閲覧してもらいました。今はGitHubページですがｗ
↑に書いてある他にも勉強会の数日前のWebinarで取り扱われた↓の話もしたいし、他にもいろいろあるし・・・とアレもコレもになり伝えたいことをまとめるは難しいなぁーと
まとめ
良かったこと
- とにかくいい経験になった
- 当然だけどやってみないと分からないことが多かった
- 思っても見ないところで分からないと言われることもあった
- S3ログ確認のために用意した当日タイムテーブル用Webページは意外と便利だった
- 当然S3ログの時にも期待していたログ出力がされていたので良かった
- 打ち合わせと何をしてほしい、学んでほしいのかを早目に共有したことは良かった
- 当時は1対4ではなくサポートに1~2名付いてくれて助かった
- 全部終わった後に少しだけですが感想や意見を直接聞ける機会があってよかった
もうちょっと頑張れ自分
- 顔と名前が一致しない・・・入社の挨拶見たきりだからね・・・
- 打ち合わせは早目だったのに資料がギリギリだった
- 資料も早目に作って添削＆打ち合わせが必要でした
- 受講者のPC状態を把握しておく＆必要なものは事前に設定済みにしておく
- 説明しながら足りないものを補完していくの大変でした
- IAMアカウントを発行してなかった・・・持っているものだと思い込み良くない
- コマンドの打ち込みミスで先に進めない場合の回避策がなかった
- 事前に実行してOKになったものをコピペ用として保存しておくとかすれば良かった
- 作業してる人の進捗をする手段が欲しかった
- 単純に画面共有とかあれば良かったのかもしれない
- もっと座学よりも手を動かす方の比重が多くても良かったかもしれない
- 分からない場合も手を動かしてる方は自分で色々試行錯誤出来る
- 手を動かすならある程度ストーリーとゴールがあると分かり易くていいかもしれない
- これが全部終わるとWordPressでBlogが公開できますよ的な
- 用語のフォローが何かあった方が良さそう
- やっぱり分からない用語が多いと困る見たいだった
- もうちょっとゆるい感じでやっても良かったかもしれない
- 楽しくするための工夫が足りなかった
- 受講者の興味・関心とか知っていると少し違ったかもしれない
とにかく総じて勉強になりました。今回は機会を作ってもらえて本当に有難かったです。今後のコミュニティ活動に上手く生かしていけるといいなーと
また、新人さんたちには何かのきっかけになってくる or 何か少しでも残るものがあったらいいなぁーと。
以上
aws-sdk-go の変更に対応した話 その2 #aws #golang #jawsug
寒い時期に↓なツールを作り
春の時期に↓な変更に対応してみたのですが
その後さらに↓のような発表がありました
Developer Preview of AWS SDK for Go is Now Available | AWS Official Blog
https://aws.amazon.com/jp/blogs/aws/developer-preview-of-aws-sdk-for-go-is-now-available/
ついに AWS公式のDeveloper Preview 版のリリースとなりました！これに伴いリポジトリもawslabs/aws-sdk-goから↓に変更になっています
正式リリースに向けて修正・追加が活発に行われているので今後も楽しみです！
ですが・・・当然ながら色々と変更しないとビルドが通らないので今回も修正していきます
今回の変更は以下の部分になります
まず単純な置き換えからスタートで、awslabsではなくなったのでimport文を修正するところから
import (
"github.com/aws/aws-sdk-go/aws"
"github.com/aws/aws-sdk-go/service/rds"
)
今回の変更で一番影響が出たのが credential 周りの変更ですね。今までは
に aws.Creds や aws.DetectCreds などがありましたが、今回からは
という形に分離され、 DetectCreds のような便利メソッドは無くなってる感じ
Package: credentials — AWS SDK for Go
http://docs.aws.amazon.com/sdk-for-go/api/aws/credentials.html
当然便利だったので使ってたりしたので、この部分を修正することに。DetectCreds は
- input variable
- Environment variable
- /.aws/credentials
- IAM Role
の順で評価して credential 情報がOKなところでいい感じに値が戻ってきたのですが、よくよく考えると確かに /.aws/credentials ファイルの情報をプロファイル指定なしで利用するのはマズイ気がしますね・・・なので今回の修正では
- input variable
- Environment variable
- IAM Role
/.aws/credentials ファイルの情報を利用しないこととして、上記の順で評価していくように変更を加えた
rds-try/config/config.go 中の GetAWSCreds() で処理を行っている
番外編
これで今回の aws-sdk-go の変更に対応分は終わりなのだが、設定変更していないにも関わらず何故か travis ci でのテストが上手く通らず・・・失敗しているのは golint の部分で当然何の変更もなし
色々悩んで travis.yml を何回もコミットして試すがいい感じにならず・・・ci 試すためにコミットって微妙だなーと感じたんですが、こういう場合はどうするのが正解なんでしょうかねぇ？
ブランチ切ってそっち側で色々試せばよかったなぁーと後から思ったりはしましたが・・・
で、どうにもならないので手元で golint をかけて見ると・・・出るじゃありませんか！エラーが！なんでだろうなぁ？と思ってたら
あーあーSQLって文字が対象に追加されてますねぇーなるほどなぁーと。チェックする側の更新っていうところに全然発想が行かなかったので良い経験になりました。
こちらもSql から SQL に変更して無事に travis ci でのテストが通過するようになりました。
そしてコミットメッセージをtypoしてるし・・・
新しいサービスも続々追加されているのでそれに対応した状態でのaws-sdk-go の正式リリースが楽しみですね！
以上
「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のマネージメントが大変とか利用出来そうなところがいろいろあって楽しみなサービス
- 今後の改善にも期待しています！
以上。
「Amazon API Gateway を使って駅すぱあとWebサービス無償版を呼んでみた」 #aws #jawsug #api #駅すぱあとWebサービス
AWS Summit New York にて発表されたサービスのうちの1つである「Amazon API Gateway」を使って「駅すぱあとWebサービス無償版」を試しに呼び出してみた時のメモ書きです
そもそも「Amazon API Gateway」って何よ？って人はひとまず↓あたりを一読
え？「駅すぱあと」ってWebサービスなんてあるの？無料版もあるの？という人は↓あたりを
APIを作ってみる
何はともあれAPIを作らないと始まらないので、以下の画面で [Get Started] ボタンをクリックして先に進みます
すでにAPIが存在する場合は以下のような画面になりますので、[Create API] ボタンをクリックして先に進みます
以下の「New API」画面にて 必須項目である API name を入力して [Create API] ボタンをクリックして先に進みます
API name については日本語が入力可能でそのままAPIとして作成出来ますが、このAPI name で CloudWatch の Backplane に ApiName という項目で登録されます
なので、日本語というか2バイト文字を含んだ名称にするとこれに登録出来ないようで結果としてAPIとしては動作しているが CloudWatch での状態把握が出来ない状態となります
まーあまり2バイト入れる人もいないと思いますが、マネージメントコンソールが日本語化されているのでうっかりあるかも知れませんし・・・
ちなみに、日本語が入っていると↓な感じでエラーで何も表示されませんでした
また、このNew API の画面において既存のAPIがある場合は以下のように Clone from API という項目が追加されて既存のAPIを簡単にコピーすることが出来るようです
Resource を追加してみる
APIの作成が終了すると以下の画面が表示されます
この画面で Resource を追加していくわけですが、左右2ペインの画面で [Create Method] [Create Resource] ボタンは右端でも操作するペインは左側・・・最初本当にどこから Resource を追加すればいいのか分からなかった・・・
ついでに [Create Method] [Create Resource] ボタンと同じ並びに [Delete API] ボタンがまったく同じ色と形で置いてあるのも・・・これも削除するときにどうすればいいのか分かるまで時間がかかった・・・
[Create Resource] ボタンをクリックすると以下の画面が表示されます
Resource Name と Resource Path が必須項目なので入力を行います。今回 Resource Name は station と指定しました。これは呼び出す「駅すぱあとWebサービス無償版」に合わせた形です
Resource Path についてはResource Name を入力すると自動でResource Name と同じものが入ります。もちろん入力して変更することも可能です
[Create Resource] ボタンをクリックして次に進みます
Method を追加してみる
Method を追加したい Resource（今回は station）が選択されていることを確認して [Create Method] ボタンをクリックします
station の下にドロップダウンリストが追加されるので、station に追加したいHTTPメソッドを選択します。
今回は GET を選択しリスト横にあるチェックマークをクリックします
今回は「駅すぱあとWebサービス無償版」を呼び出しするので、 API Gateway は HTTP Proxy として動作するように設定します
Integration type は HTTP Proxy を選択し HTTP method を GET に Endpoint URL に 「駅すぱあとWebサービス無償版」のエンドポイントを設定します
この際に Endpoint URL にはリクエストパラメータを含めずに設定します
すべての設定が終わったら [Save] ボタンをクリックして先に進みます
Integration type については他に Lambda Function と AWS Service Proxy が選択できそれぞれ入力項目が異なります
Method の設定をしてみる
Method の追加が終わると以下の Method Execution 画面が表示されます
これはMethod 設定のダッシュボード的な画面で各項目の設定が表示され、各項目へ設定画面に遷移できます
各項目については
- 「Client」はそのまま呼び出し元のクライアントを指します
- 「Method Request」と「Method Response」については、実際にクライアントがアクセスするAPI Gateway で作成したAPIのリクエストとレスポンスになります
- 「Integration Request」と「Integration Response」については、今回はHTTP Proxyとして動作するので、originに対してアクセスするためのAPI リクエストとレスポンスになります
- 「エンドポイント」は今回はorigin サーバのエンドポイントを指します
Method Request を設定してみる
Method Request のリンクをクリックして詳細設定画面に移動します
URL Query String Parameters 項目の設定を行います。 URL Query String Parameters を展開して Add query string リンクをクリックして「name」と「key」を追加します
追加後にキャッシュを行いたい場合は Caching 項目にチェックを付けて下さい
Integration Request を設定してみる
続いて Integration Request のリンクをクリックして詳細設定画面に移動します
この Integration Request 項目では、前述の Method Request で受け取ったリクエストの内容を実際のorigin であるエンドポイントに渡す際の値のマッピング設定を行います
今回は Method Request と同様に URL Query String Parameters の設定を行います。URL Query String Parameters を展開して Add query string リンクをクリックして「name」と「key」を追加します
追加の際に Mapped from を入力しますが、入力フォーマットが決まっていて
method.request.{"path" | "querystring" | "header"}.{param_name}.
E.g. method.request.querystring.myparam
の形式で入力します。今回は method.request.querystring.name と method.request.querystring.key になります
この辺りはパススルーの設定や Nameが同一でいいなら簡単に自動生成してくれるとかあるとさらに便利になりそうなので今後に期待です
Mapping Templates については今回XMLを取得することになるので Content-Type に application/xml を指定してみました。
APIのテストを実行してみる
ここまで設定が終わればテスト出来るはずなのでテストを実行してみようと思います。以下の画面で TEST リンクをクリックして Method Test 画面に移行します
Method Test 画面では Query Strings の name と key を指定します。今回は name は駅名となるので「高円寺」を、key は駅すぱあとWebサービス無償版へのアクセスキーになるので発行されているキーを指定しました。
Query Strings の入力が終わったら [Test] ボタンをクリックしてテストを実行します。実行が終わると Response Body を始めとして Response Headers と Logs もその場ですぐに確認できますので非常に便利です
これで設定は完了っぽいのですが HTTP Proxy として動作させている場合には Response ヘッダーが気になります。特に駅すぱあとWebサービス無償版では日本語文字列を戻しているので Content type ヘッダーが適切でない場合、文字化けが起こる可能性があります。
エンドポイントに普通にアクセスすると↓なヘッダー情報が戻ります。その中で必要なのは Content-Type: application/xml;charset=utf-8 となるので、これを付加してみたいとおもいます
Method Response を設定してみる
手っ取り早く固定値で指定をしてみたいと思います。Method Response のリンクをクリックして詳細設定画面に移動します
Method Response 項目画面で Http Status の 200 左側にあるマークをクリックして詳細を展開します。その中で Response Models for 200 項目を編集を行います。Content type にはデフォルトで application/json が指定されていると思うのでこれを application/xml;charset=utf-8 と入力して保存します。Models はそのまま Empty としました。
これでレスポンスヘッダーにこの Content type が付加されることになるので文字化けは起こらなくなります
しかし、これでは固定値なのでエンドポイント側の仕様が変更された場合に困りますし、ヘッダーなので変更はあると思った方がいいのでエンドポイントのヘッダーをマッピングする方法を試してみます
まず同じく Method Response 項目画面で Response Headers for 200 項目に Add Header リンクをクリックして Name を追加します。ここでは Content-Type を指定します。また、Response Models for 200 の項目は必要ないので削除します。
このままではエンドポイントのレスポンスヘッダーとのマッピングが行えないので続けて次の設定を行います
Integration Response を設定してみる
マッピングの設定は Integration Response の詳細設定画面で行います。先に Method Response の設定を行わないとマッピング設定出来ないのは結構わからなかった・・・これ今後はどっち側からでも設定できるようになると嬉しいですねぇ
Integration Response 項目画面で HTTP status regex の - 左側にあるマークをクリックして詳細を展開します。Header Mappings の項目には先ほど Method Response で追加したヘッダー項目が Response header の欄に入力済になっているはずです。この Mapping value 欄に追加を行います。
追加する項目はエンドポイントのContent-Typeヘッダーなので integration.response.header.Content-Type と入力してマッピングを設定します。
あとは、前述のTESTを行いヘッダーとして意図したものが出力されているか確認します。これでヘッダーのマッピングを行うことが出来ました。先に Method Response の設定 からというのを忘れないようにしないと！
Deploy APIを実行してみる
Resources ペインの右側にある青い [Deploy API] ボタンをクリックしてデプロイ項目の詳細画面に移動します
デプロイ先に関する設定を行います。Deployment stage は新規のデプロイなので New Stage を選択し、必須項目の Stage name には例の通り prod と入力します。この名称は URL の一部として利用されることになります。最後に [Deploy] ボタンをクリックしてデプロイを行います。
2度目以降は既存の Deployment stage が選択可能になるので、同じ場所にデプロイを行う際には選択を行います。
Stages 画面にて表示されている Invoke URL がAPI Gateway 経由でアクセスする際のエンドポイントになります。先ほど入力した prod という名称が利用されていることも確認できます。
この状態で公開され利用できますのでブラウザで表示してみました。
文字化けもなくデータが取得できることが確認出来ました。
まとめ
- 弊社の「駅すぱあとWebサービス無償版 」へのHTTP proxy として設定してみた
- マネージメントコンソール上からの設定で簡単に利用できる
- API Gateway を使うことによって運用面での煩わしい部分を軽減できそう
- API Gateway が制約になることにより形が統一出来る可能性がある
- 形が統一・整理出来るとこれも運用面での効果は大きい
- UIが非常に操作しにくい
- UIで値が更新されたりされなかったりするのはカイゼン期待
- Saveしないと反映しないページとしなくてもいいページと操作の統一感が欲しい
- 細かい所は色々あるが、とにかく楽しいしワクワクするサービスなのでどんどんアップデートしてほしい！
以上。
更に詳しくAPI Gatewayが知りたい方は当然ながら例のブログで！
AWS Black Belt Tech Webinar Amazon API Gateway の資料も公開されてました！
あと、このエントリーとは別にアクセスを流すところまで書いてます！
aws-sdk-go の変更に対応した話 #aws #golang #jawsug
ちょっと前に↓なツールを作ってみたのですが
その後にAWSのBlogに↓な感じの記事が上がりました
Preview the Latest Updates in the Master Branch – AWS SDK for Go | AWS Official Blog
https://aws.amazon.com/jp/blogs/aws/preview-the-latest-updates-in-the-master-branch-aws-sdk-for-go/
当然ながらもうすぐ正式リリースが近いに違いない！と思い多いに喜んでいたわけですが・・・develop branchの内容ってすごい変更じゃないですかーヤダー
こちらも当然の結果になるのですが、今までままではビルドが通らない・・・よろしいならば修正だっ！ということで修正してみました。
まずは、構成が丸ごと変更になったのでimport文が全滅ですね・・・従来は
import (
"github.com/awslabs/aws-sdk-go/aws"
"github.com/awslabs/aws-sdk-go/gen/rds"
)
と書いてましたが、新しいものはgenではなくservice以下にすべて移動となっているので
import (
"github.com/awslabs/aws-sdk-go/aws"
"github.com/awslabs/aws-sdk-go/service/rds"
)
に変更しました。正直import文ぐらいなら何の問題もないんですが・・・今回の変更では構造体名称が変更になっているので、これが結構面倒な感じでした。例えば
message := &rds.DescribeDBInstancesMessage{
DBInstanceIdentifier: aws.String(dbIdentifier),
}
となっているのを、新しいものでは*Messageが全部*Input変更になっていたので
input := &rds.DescribeDBInstancesInput{
DBInstanceIdentifier: &dbIdentifier,
}
と、対応する形に変更しました。また、構造体のメンバーで今までは aws.String型という単純にポインタ型を再定義したものしか受け付けませんでしたが、これも単純にStringのポインタで問題なくなったので修正しました。
*Newも引数が以前はそれぞれで、クレデンシャルとリージョンを指定していましたが
aws_rds := rds.New(aws_creds, conf.Rds[name_flag].Region, nil)
新しいものではConfig構造体が用意され、その構造体にクレデンシャルとリージョンを指定すればよくなったので
aws_conf := aws.DefaultConfig
aws_conf.Credentials = conf.GetAWSCreds()
aws_conf.Region = conf.Rds[name_flag].Region
と、変更を行いました。毎回引数で個別に指定するよりは管理しやすくなった印象です。
で、今回一番ハマったのがテストコードで利用していたAWS APIのモック作成で使った以下のコードです。
// Override endpoints
// see also
// endpoints - GoDoc
// https://godoc.org/github.com/awslabs/aws-sdk-go/gen/endpoints#AddOverride
test_region := "rds-try-test-1"
endpoints.AddOverride("rds", test_region, server.URL)
aws_creds := aws.Creds("awsAccesskey1", "awsSecretKey2", "")
aws_rds := rds.New(aws_creds, test_region, httpClient)
新しくなった方ではそもそもendpoints.AddOverride自体がなくなっていて、さてどうしたものかと思ってましたが、以下のようにすることで従来より簡単に実現できるようになっていました。
// Override endpoints
test_region := "rds-try-test-1"
aws_conf := aws.DefaultConfig
aws_conf.Credentials = aws.Creds("awsAccesskey1", "awsSecretKey2", "")
aws_conf.Region = test_region
aws_conf.Endpoint = server.URL
aws_conf.HTTPClient = httpClient
このConfig構造体に値を設定するだけでコントロール可能なのは柔軟でいいですねー
という感じで、より使いやすい方向に改善されているaws−sdk−goの正式リリースが待ち遠しいですが、とりあえず現行最新版で動作するように変更できました。
同じ作業を行う方の参考になればと思います。
golintを通るように変更してみた #golang
少し前になりますがGunosyさんで行われた↓なgolangの勉強会 #gunosygo に参加
初めての参加でしたが、テーマがNotHttpNightということでバラエティに富んだ発表が聞けて非常に刺激と参考になりました。
その中で↓なLTがあり、その時のTLを見てみるとやはりみなさんgolintを通している模様・・・
せっかくちょっと前に↓なツールを作ってみてたので、実際にgolintで怒られないように変更をしてみました。
まず、一番多かったのは
logger.go:16:7: don't use underscores in Go names; const file_name_text should be fileNameText
アンダースコアを使ってる変数を直せという指示。これは個人的にスネークケースで書く方が好きなので至るところで出ていて、正直結構面倒な作業でした・・・そしてあまり好きじゃないキャメルケースに変更なのですね。
アンダースコアだめなのは、「ブランク識別子」として利用するかなのかなぁ？
その次はコメントが無い、もしくは指定の形式になっていないというもの
config.go:14:6: exported type Config should have comment or be unexported
これも公開しているものには変数・関数・構造体 ・・・etcであれ決まったフォーマットでコメントを付ける必要があるので結構な作業でした。
あとはちょっと変わっていたのは、特定の文字列で大文字を指定されることがありました。↓な感じでJSONとかIDとか。
このあたりの理由とかもきになりますし、 #gunosygo のLTにあるようにソース読んでみるといろいろわかって面白そうですねー
しかしひたすらgolint→置換→test→（最初に戻る）を繰り返してたな・・・
