LamveryにSwaggerベースのちょっとリッチな機能付きAPI Gateway integrationを追加しました
経緯
API Gatewayの"x-amazon-apigateway-integration"っていう独自要素に色々突っ込んでるSwagger記述サンプルを見て複雑な気持ちになってる
— Masashi Terui (@marcy_terui) April 11, 2016
書いたコードをサクッと上げてサクッとWebから叩ける用にしたいだけなのに何故こんなにJSONを書かないといけないのか
— Masashi Terui (@marcy_terui) April 11, 2016
ということでサクッとAPIが定義できるようにしました。
ここで説明しないインストール方法や使い方の詳しい情報はGitHubのREADMEやQiitaの記事でご確認ください。
使い方（コマンド）
lamvery api [-d] [-n] [-r] [-s <stage-name>] [-w]
-dは恒例のDry run!!-nが後述の自動オプション付加の無効化-rで削除-sはAPI Gatewayで言うステージ（dev,prod環境使い分けるとかに使う）-wで新規作成時に設定ファイルにAPIを識別する番号を保存（更新する時に指定しなくて良いようにする）
設定
こんな感じで設定を書きます。
api_id: myipugal74 stage: dev cors: origin: '*' methods: - GET - OPTION headers: - Content-Type - X-Amz-Date - Authorization - X-Api-Key configuration: swagger: '2.0' info: title: Sample API schemes: - https paths: /: get: produces: - application/json parameters: - name: sample in: query required: false type: string responses: '200': description: 200 response schema: $ref: '#/definitions/Sample' definitions: Sample: type: object
ちなみにこれとほぼ同じ雛形は以下のコマンドで生成できます。
lamvery init
で、本来ならこれをAPI GatewayでLambda backendによって動かすためには x-amazon-apigateway-integration っていう要素に色々突っ込まないといけないわけですが、その辺は同じくLamveryでデプロイしたFunctionに向くように自動でよしなにやってくれるという感じです。
差分表示
こんな感じでDiffっぽくSwagger定義の差分が見れます。Dry runにすれば事前に確認だけすることが可能。
最後に
これぐらいサクッと書いてサクッとAPI公開できると「ああ、サーバレスっていいなあ」って思えそうな感じ。
ただ、認証の定義とかは未対応だし、自動オプション付加のやり方とかもうちょっとスマートに出来ないか悩み中で、もしアイデアあればいただけると嬉しいです。
-n（x-amazon-apigateway-integrationの自動付加をしないオプション）をつければ単純に差分表示＆Dry run対応のSwagger importerとしても使えるので、良かったら使ってみてご意見ください。
明日、ぺちかん北海道なのに俺、何やってんだ。。。
各社のサービスから見えるServerlessの本質とは何か
前置き
ポエム系です。以下は私の見解ですが、異論は大いに認めます。
あと、エイプリルフールは全く関係ありません。ごめんなさい。
まず、本日2016.04.01、MicrosoftがAzure Functionsというサービスを発表しました。
これで、AWS Lambda・GCPのCloud Functions・Azure Functionsという、三大（？）クラウドの所謂Serverlessと呼ばれるジャンルのサービスが出揃ったわけです。
AWS Lambda (サーバーレスでコードを実行・自動管理) | AWS
Google Cloud Functions Documentation | Cloud Functions | Google Cloud Platform
ドキュメントを読んで分かったAzure Functionsの実体
とりあえず、気になるサービスが出てきたらドキュメントを読んでみるようにしているのですが、そこでAzure Functionsがどんなものなのかなんとなく窺い知ることができました。
ランタイムとしてはC#, Node.js, Python, F#, PHP, batch, bash, Java等をサポートするようです。
「おお、多いなスゲー」とか思ったんですが、読み進めてみるとAzureのPaaS系サービスであるApp Serviceの一機能であるWebJobsと関連しているような記述が出てきます。
バックグラウンドジョブを行うWebJobsにスケジュール実行だけではないStorageやQueueからのイベント実行を追加したようなものがAzure Functionsの今のところの実体のようです。
ちなみにCloud Functionsは今のところ基盤としてContainer Engineを使用しており、コンテナクラスタからオンデマンドで実行環境（コンテナ）を割り当てていくような実装のようです。今はGKEインスタンスがユーザから見えちゃってるんですが、これは無くなってユーザは意識せずに使えるようになる予定のこと。
Lambdaは中身が全然見えないのですが、上記のCloud Functions完成形って感じの雰囲気ですよね。
さて、ここで考えてみたいのは以下です。
PaaSとServerlessって何が違うの？
よく言われる、ユーザが管理しなくて良いマネージドサービスを使って運用フリーなシステムを作るっていうのがありますが、
それって（狭義の）PaaSでも一緒じゃね？*1
っていう話なんですね。
ここで注目したいのが、Azureが今までPaaSとして提供してきたものにEvent Drivenな要素を足してServerlessなサービスと銘打って出してきたということです。
つまり、"PaaS(狭義) + Event Driven = Serverless"であるという一つの定義が見いだせるわけです。
あとは、課金体系ですね。PaaSは基本的にアイドル状態でも課金が発生しますが、Serverless系のサービスは真に動いている分しか課金が発生しません。
Serverlessの本質とは
これは私の見解なので異論は大いに認めます（2回目）
まず、最近話題のServerless(Architecture)と呼ばれているものについて、ずっと違和感を感じていました。
「API Gateway + LambdaでAPIシステム作るのがCoolだ」みたいな話ですね。
こんなことを言うとたぶん誰かに怒られる気がするのですが、
いや、普通にPaaS使った方が良いんじゃない？
っていう。全部がそうだとは言いませんが、けっこうそういうケースが多いんじゃないかなと。
扱いやすさを求めるならHerokuでRailsとか、性能を求めるならApp EngineでGolangとかで良いと思うんですよね。
最近なら、AWSにこだわりたいならAWS上でのライフサイクルを自動化してPaaSのように使わせてくれるMobingiという手もあります。
https://mobingi.co.jp/mobingi.co.jp
ただ単に「インフラ運用したくない！！１」ってだけなら、そっちの方が管理も楽だし制約も少ないので良いと思うんです。
（管理が大変だからこういうツールを作りたくなるわけで）
じゃあ、何が本質でどんな場面でServerless系のサービスが良いのかっていうと、そこで出てくるのがやっぱりEvent Drivenじゃないかと。
その中でAPI Gatewayがどんな存在になるかというと、Lambdaに対してWeb hookだったりとか、ユーザの行動イベントをHTTPリクエストとして別システムから伝えるためのインターフェースだと思うわけです。
AWSはその辺り別サービスにして徹底的に疎結合になってるのがさすがって感じですね。だからこそ色んな使い方ができているというのはあると思います。（他はHTTPが単にトリガーの一つの扱いのはず）
クラウドのサービスとサービスの間をイベント連携する、あるいは他システムやユーザの行動を絡めたりもして、システムをイベント駆動で作り上げていく、それがServerlessの本質というか最大のメリットなのではないかと。
そういう風に考えると、多様なイベントに対応し、これからもどんどん増やしていくであろうAWS Lambdaがやっぱり一日の長があるといった印象です。
つまり何がいいたいかっていうと
っていうか、Lambdaのマイクロサービスとかサーバレスの話はもういいから、イベントドリブンコンピューティングの話しようぜ
— Masashi Terui (@marcy_terui) March 23, 2016
あと、もう一つ
App Engineを昔のCPU時間課金に戻して、Event Driven要素足せばそれだけで最強のServerless実行環境になるので、Google先生におかれましては是非ご検討のほどよろしくお願いします
— Masashi Terui (@marcy_terui) April 1, 2016
*1:広義のPaaSはIaaSの上に乗るマネージドサービス全般、狭義のPaaSはHeroku,App Engine等のアプリケーション実行環境を指すと思ってます
Lamveryが速攻でLambdaのVPCサポートに対応したぞ！
本題
念願の（？）LambdaのVPCサポートが来ましたね！
これはもうすぐにでも使いたいやつなので、速攻で対応しました。
v0.12.0～対応済みとなっております。
他にも随時機能が増えたりしてるので、以下の記事やREADMEをご確認ください。
設定ファイルはこんな感じ
vpc_config以下が該当部分です。
今後、SecurityGroupとかIDじゃなくて名前で解決できるようにしたい。
profile: private region: us-east-1 versioning: true default_alias: test configuration: name: lamvery-test runtime: python2.7 role: {{ env['AWS_LAMBDA_ROLE'] }} handler: lambda_function.lambda_handler description: This is sample lambda function. timeout: 10 memory_size: 128 vpc_config: subnets: - subnet-cadf2993 security_groups: - sg-4d095028
補足
VPC内でのLambdaの起動（や削除等も含めた諸々）にはENIに関する権限が必要になります。
以下の様なIAM Role Policyの設定が必要です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeNetworkInterfaces",
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:AttachNetworkInterface",
"ec2:DetachNetworkInterface"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:<region>:<account-number>:key/<key-id>"
]
}
]
}
最速だろコレは！
Lambda(Python)のスケジュール実行をコード(YAML)化してコマンド一発で設定！LamveryのCloudWatch Events対応とその他アップデートまとめ。
以前、QiitaやCloud RoadshowのLTで、AWS Lambda for Pythonのデプロイを便利にする拙作のツール(OSS)をご紹介しました。
その後もちょっとずつ改善を重ね、以下の様な機能追加・変更を行いました。
- 差分表示を整えた
- Lambdaの設定だけ変更するコマンドを追加 *1
- デプロイパッケージ(zip)の容量削減
- アーカイブ*2にライブラリを含まないオプションの追加
- リージョン毎にLambdaの容量に制限があるので合計容量も差分表示するようにした（下記参照）
下2つは @ijin さんにインスパイアされた機能です。ありがとうございます。
そして今回、一つ目玉的な機能として、CloudWatch Events対応をリリースしました。
これは、主な用途としては兼ねてよりAmazonらしからぬコンソールの画面先行でAPI待ちだった Scheduled Eventsに対応するものです。
つまり、Lambda functionのスケジュール実行がコマンド一つで設定できるようになります。
定義もテンプレートエンジン付きのYAMLで簡潔かつ柔軟に記述できます。
最近、こんなのが話題になりましたが、
Python限定でFunction毎の管理という面で少し方向性は異なりますが、こっちの方が手軽だし便利で高機能なので、是非使ってみてください。 *3
使い方・設定の解説などはREADMEに書いていますが、後日Qiitaあたりに日本語でまとめようと思います。
今回のアップデート以外の部分については以下にまとめてます。
ざっくり使い方
Functionを実装してデプロイした上で、以下のような設定ファイルを記述（lamvery init で雛形生成可）します。
profile: private region: us-east-1 configuration: name: lamvery-test runtime: python2.7 role: {{ env['AWS_LAMBDA_ROLE'] }} handler: lambda_function.lambda_handler description: This is sample lambda function. timeout: 10 memory_size: 128 events: - rule: foo description: bar schedule: 'rate(5 minutes)' targets: - id: test-target-id input: this: - is: a - sample: input
コマンドを叩きます。
lamvery events
これだけ！
もちろん、Dry runをサポートしているので -d を付けて事前に更新内容だけ確認することもできます。
また、これを作る過程と使っていてLambda(Python)及び、CloudWatch Eventsについてかなりの知見や想定が溜まっているので、それもどこかで放出したいと思います。 *4
以上です。
是非使ってみてフィードバックをいただければ嬉しいです。
*1:それまではdeploy時と一緒にやる選択肢のみ
*2:アップロードするためのZIPアーカイブ
*3:正直、アレで1400 Starとか、やっぱり「何ができるか」よりも「誰が作ったか」が大事なんだな感あって、ちょっと悔しい
*4:JAWS Days 2016のタイムテーブルでLambda枠がまだ埋まってない(2015-01-23現在)んだけど、入れてくれたりしないかなー|дﾟ)ﾁﾗｯ
色々あって書ききれてない2015年を振り返ってみる
2015年の前半は割りと残しておきたいことはちゃんと文章に残しておけてたんだけど、後半は色々あって書けてないので、補完する意味も込めて振り返ってみる。 今年は副業としてフリーランス的な活動を始めたこともあり、普段の本業とそれ以外（副業・自学・勉強会やイベントなど）の活動で分けてまとめてみる。とはいえ、全く仕事の役に立たないことはあんまりしないので境目は曖昧な感じです。
あと、最後の方に来年に向けた割りと大事めなお話が書いてあります。
1~2月
本業
まず、この前の１２月の転職しているので、基本的には軽めのタスクをこなしつつ色々新しい環境の把握やらなんやらしてた感じ。 特に大きな理想と現実のギャップみたいのはなかった。そもそもごく一部の企業を除いて地方でそんな恵まれた環境なんてないことは知っていたし、それでもクラウド案件はそれなりに多いにもかかわらず、思ってたよりオンプレ依存が強かったくらい。それもある程度は織り込み済みだったので、クラウドシフトやフロー改善その他も含めて色々展開していくことでバリューを出せたら良いなという気持ちを新たにした。
本業外
AWS SDK for Golangがベータリリースされたり、札幌でもGolangのMeetupが開催されたりでさすがにそろそろ触ってみないと不味いかなと思い、所謂イベント駆動開発してみたりとか、なんか作ってみたりとかした。あと、Azureに興味を持ち始めて、クラウドを組み合わせて使うことを本気で考え始めたのがこの辺。
www.slideshare.net
3月
本業
この辺りからAWSに詳しい人的な印象が社内に広く広まってきた感がある。色んな人から質問されたり、オブザーバとして打ち合わせに駆りだされたり、営業支援で東京に出張する場面が増えてきた（そして気がついた月3,4回とかで東京に行ってたｗ）
本業外
JAWS Days 2015に北海道組でありながら東北勢の温かいバックアップを受けて登壇させてもらった。ついでに会社としてもスポンサーさせてもらったり、Auroraのネタ話すのに５日前までプレビュー来なかったりとかトラブルも色々あったけど今までと違う関わり方でとても有意義な時間だった。来年のJAWS Daysも既にアナウンスされてましたが、はちょっと色々あってどうするか考え中です。。。
www.slideshare.net
4月~5月
本業
所属する会社がマザーズに上場した。そもそもこれを知ってたから入社したみたいな所はあった。上場企業に勤めたいとかそういうのはどうでも良いんだけど、札幌発のテクノロジー企業で上場は少なくとも自分がこの業界を志してからは聞いたことがなかったし、しかもそれがインフラメインの会社で、傍から見るにクラウドを本当の意味で使いこなしているようには見えなかった。だから、そこに自分が入ることで生み出せる価値がきっとあるはずだと思ったのが大きい。それに、良い流れが来始めていたので、より頑張ろうという気持ちになった。
本業外
業務でIoTの機運が高まってきたこともあり、IoTあるじゃんという勉強会に顔を出して、クラウド・サーバサイドエンジニアとして分からないなりにちょっとお話したり。
GCPに興味を持って触り始めたのもこの辺な気がする。
www.slideshare.net
6月
本業
IoT関連の仕事の話が出始める。色々と首を突っ込んで巻き込まれる形で色々やっていたようであまりやっていないような、よく覚えていないｗ
イベントに登壇・参加するために東京に行くと抱き合わせでAWS案件で色々営業について回るとかで出張は楽しかったけどツラい感じだった。
本業外
これは会社として回ってきた話なのでどちらかと言うと本業に近いのだけど、ニフティさん主催のWebセミナーに出演させてもらった。
あと、AWS Summit 2015に参加して、昼食ついでに一杯引っ掛けた状態で新しいDevOps Proの試験に受かるという快挙（？）を成し遂げたｗ
7月
本業
IoT関連の仕事が具体化し始める。というか、うん、いややめとく。
とりあえずそういった関係でかなり忙しくなり始めた。
本業外
July Tech Festaにプロポーザルが通ったので、マルチクラウド的な話をした。あと、東京めっちゃ暑かった。
マルチクラウドについては未だにだいぶ荒削りだけど、いくつか確信を得る体験はこの前後含めあったので、上手く伝えられるようにしていきたい。
www.slideshare.net
一方、YAPCとPyConも行かせてもらえそうだったので出したけど、落ちた。。。
PyConは札幌でやったイベント（後述）のネタ使い回しだったのでまあ良いとして、YAPCの方のネタは少し発展してクラウドも絡めて「クラウドがフレームワークに見える」とか「インフラをモデリングする」とかそういう概念を言語化する機会を求めていて、文章だけじゃ伝えきれなそうなので、どこかそういう場がないかな・・・ってずっと思ってるけど、未だに出会えてない。
あと、去年に一回関西・東京に混ぜてもらってChefのやつをやったきり、やるやる詐欺になってたInfra as Codeの勉強会というかカジュアルなイベントをやった。上述のYAPCのネタをここでやろうかとも思ったんだけど、自分の持ち時間は短めにしてできるだけ色んな人に話してもらいたかったので自粛した。これは参加者からまたやってほしいと嬉しい声を沢山いただいていて、自分でも楽しかったのでまたやりたい気持ちはあったんだけど、また延び延びになってて申し訳ない・・・やりたい気持ちはもちろんあるので、今色々抱えてる問題が解消されたらやります。
8~9月
本業
とにかくめっちゃ忙しかった。忙しすぎてYAPCもPyConもいけなくなったけど、Kinesis、LambdaとかOpsWorksとかDynamoDBとか、コアなプロダクト使ってガッツリ開発する経験ができたので、それはそれで良かったのかなと思ってる。
本業外
忙しさのピークとdb tech shocase、PyCon Mini Sapporoというイベント登壇２連チャンが重なるという不運だったけど、どちらも札幌発開催の大きめのイベントで絶対外したくなかったので気合で乗り切った。
www.slideshare.net
www.slideshare.net
特にAuroraの方は話題のサービスであることも相まって今年一番のヒットになりました。色々犠牲にして用意した甲斐があった。ありがとうございます。
この後個人事業になる副業の方が、ピークではないものの忙しい期間と被ってしまい疲れたのもあるけど、それよりも期限のないタスクがそれに甘えて遅くなったり、クライアントさんに気を遣わせてしまったりということが少しあったので、ちょっとこの辺のコントロールは考えなきゃなと思った。
10~11月
本業
忙しさが落ち着いてきた。で、落ち着いた所で色々これからの話をしていたのだけど、詳しくは色々問題があるので省くが、モチベーションが激落ちする出来事というか扱いを受けた。
本業外
個人事業主になった。正直、これがあったおかげでやりきれない想いを収めることができていたと思う。本当にありがたい。詳しくは以下から。
AWS Cloud Roadshow 2015でLTをしたけど、客層の見通しが甘すぎた上に途中の画面切り替えに失敗して過去最高レベルでスベった（ウケ狙いじゃないので盛り上がらなかった・響かなかったという意味で）反省しか無い。。。
www.slideshare.net
GCPUG札幌の立ち上げと第一回勉強会をやった。この時の資料は主観たっぷりの比較ネタなので口頭のフォロー無しの資料だけ公開すると問題がありそうなので自粛しました・・・ｗ
こっちもそろそろ2回目に向けて動き出さなくては・・・誰かモチベーションください。。。
12月
本業
モチベーション激落ち継続中。仕事はそれなりにちゃんとやってます（当然ですがｗ）
本業外
こっちは頑張った。AWS×Kintone勉強会でBigQueryをぶっ込むとか（メインはあくまでAWSです！）
マルチクラウド #とは from Terui Masashi
www.slideshare.net
アドベントカレンダーは３つ参加した。
まとめ的と来年に向けて
本当に色々な経験をさせてもらった。コミュニティにも会社にもその他関わった皆様に感謝の念は付きない。ありがとうございます。
ただ、それとこれとは別問題で、本業（会社）の方についてはこのままのモチベーションでダラダラ行くのだけは誰も得しないので、来年の早い段階で何かしら決着付けないとと思ってます。
正直、今は副業の方を頑張ろうという気持ちです。そのまま独立するというのもアリかなと思ってる。というわけで、やる気出してウェブサイト作った！
何かあればよろしくお願いします！
副業フリーランス活動を認めてもらうこと・札幌（リモートでも可）勤務が必須条件ですが、色々な選択肢を考えたいので転職オファーでもOKです。
ちなみに会社の人に見られる可能性大ですが、それでも問題はないので大丈夫です。
それも含めて来年早々に決着付けたいという意思表示と受け取ってもらえれば。
ということで、来年もよろしくお願いします！
AWS Price List APIから欲しい情報だけ抜き取るAPIをAPI Gateway + Lambdaで作った
この記事はAWS Advent Calendar 2015の11日の記事です。
経緯
それは昨日(2015-12-10)の出来事でした。
全世界待望（？）の料金を取得するための公式APIが公開されました。
過去にこんなのやこんなのを作って、公式HPで使っているデータソースのJSONのURLやフォーマットが変わる度に(´・ω・｀)ｼｮﾎﾞｰﾝとしてきた身としては、「これは！！」となったわけです。
で、喜び勇んで試しに叩いてみたら
@marcy_terui RDSで26MB。。でけぇよ！
— Michael H. Oshita (@ijin) 2015, 12月 10100万行超えのJSONやばすぎでしょｗ
— Masashi Terui (@marcy_terui) 2015, 12月 10そんなこんなで
@ayakomuro たしかに。ほしいやつだけ返してくれる簡易APIでラップするの良いですね！
— Masashi Terui (@marcy_terui) 2015, 12月 10みたいな話になったので勢いで作ってみましたよと。
成果物
ソース
APIドキュメント（swagger-ui）
フィードバックはGitHubの方からお願いします :-)
エラー処理とか雑なんでエラー時に普通にスタックトレースとか返ってくるので、Issueに貼り付けてやってくださいｗ
使い方
APIドキュメント見れば大枠はわかると思うので、ここでは各属性の指定方法を説明したいと思います。
とりあえずコマンドからのサンプルを貼っておきます。これをベースに説明したいと思います。
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '[{ "key": "instanceType", "value": "m4.4xlarge" }, { "key": "location", "value": "US West (Oregon)" }, { "key": "operatingSystem", "value": "Linux" }] ' 'https://eaoftu7rfi.execute-api.us-east-1.amazonaws.com/public/v1/offer/AmazonEC2?term=OnDemand'
Method
POSTのみに対応します（CORS対応のためにOPTIONも叩くことはできます）
URL
まず、ベースとなるのが以下の部分です。
https://eaoftu7rfi.execute-api.us-east-1.amazonaws.com/public/v1/offer/
次に、その後の AmazonEC2 の部分がサービスを示します。それぞれ何が使えるかは本家のAPIに準拠します。
なので、以下の offerCode で何が使えるか確認できます。
https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/index.json
そして、クエリストリングの term で購入方式を指定します。ここは、確認した範囲では OnDemand or Reserved しかないようです。EC2やRDS等以外の Reserved の概念が存在しないサービスについては OnDemand を指定してください。
Body
JSONフォーマットで各プロダクトの属性名が key 、その内容を valueで指定します。それぞれの内容は公式APIのデータが以下のようになっており、その中の attributes の内容がそのまま該当します。
{
"formatVersion" : "v1.0",
"disclaimer" : "This pricing list is for informational purposes only. All prices are subject to the additional terms included in the pricing pages on http://aws.amazon.com. All Free Tier prices are also subject to the terms included at https://aws.amazon.com/free/",
"offerCode" : "AmazonRDS",
"version" : "20151001000000",
"publicationDate" : "2015-11-15T04:02:20Z",
"products" : {
"FNR4GZ675EW5UXJW" : {
"sku" : "FNR4GZ675EW5UXJW",
"productFamily" : "Database Instance",
"attributes" : {
"servicecode" : "AmazonRDS",
"location" : "US West (Oregon)",
"locationType" : "AWS Region",
"instanceType" : "db.t2.small",
"currentGeneration" : "Yes",
"instanceClass" : "Burstable performance instances",
"vcpu" : "1",
"memory" : "2",
"piopsOptimized" : "No",
"networkPerformance" : "Low",
"engineCode" : "10",
"databaseEngine" : "SQL Server",
"databaseEdition" : "Express",
"deploymentOption" : "Single-AZ",
"usagetype" : "USW2-InstanceUsage:db.t2.small",
"operation" : "CreateDBInstance:0010"
}
},
複数の条件は全て AND で繋がります。指定された条件を全て満たすデータが返却されます。
結果
上記コマンドの結果は以下のようになります。
[
{
"product": {
"sku": "8YGPZRQEKSSY8VWV",
"productFamily": "Compute Instance",
"attributes": {
"enhancedNetworkingSupported": "Yes",
"currentGeneration": "Yes",
"operation": "RunInstances",
"instanceType": "m4.4xlarge",
"vcpu": "16",
"storage": "EBS only",
"location": "US West (Oregon)",
"memory": "64 GiB",
"processorFeatures": "Intel AVX; Intel AVX2; Intel Turbo",
"networkPerformance": "High",
"usagetype": "USW2-HostBoxUsage:m4.4xlarge",
"processorArchitecture": "64-bit",
"tenancy": "Host",
"servicecode": "AmazonEC2",
"dedicatedEbsThroughput": "2000 Mbps",
"instanceFamily": "General purpose",
"locationType": "AWS Region",
"licenseModel": "No License required",
"preInstalledSw": "NA",
"clockSpeed": "2.4 GHz",
"physicalProcessor": "Intel Xeon E5-2676 v3 (Haswell)",
"operatingSystem": "Linux"
}
},
"price": [
{
"sku": "8YGPZRQEKSSY8VWV",
"termAttributes": {},
"effectiveDate": "2015-12-01T00:00:00Z",
"offerTermCode": "JRTCKXETXF",
"priceDimensions": {
"8YGPZRQEKSSY8VWV.JRTCKXETXF.6YS6EN2CT7": {
"description": "$0.000 per Linux m4.4xlarge Dedicated Host Instance hour",
"pricePerUnit": {
"USD": "0.0000000000"
},
"rateCode": "8YGPZRQEKSSY8VWV.JRTCKXETXF.6YS6EN2CT7",
"endRange": "Inf",
"beginRange": "0",
"appliesTo": [],
"unit": "Hrs"
}
}
}
]
},
{
"product": {
"sku": "ZPAH28S2QQZ64QB5",
"productFamily": "Compute Instance",
"attributes": {
"enhancedNetworkingSupported": "Yes",
"currentGeneration": "Yes",
"operation": "RunInstances",
"instanceType": "m4.4xlarge",
"vcpu": "16",
"storage": "EBS only",
"location": "US West (Oregon)",
"memory": "64 GiB",
"processorFeatures": "Intel AVX; Intel AVX2; Intel Turbo",
"networkPerformance": "High",
"usagetype": "USW2-DedicatedUsage:m4.4xlarge",
"processorArchitecture": "64-bit",
"tenancy": "Dedicated",
"servicecode": "AmazonEC2",
"dedicatedEbsThroughput": "2000 Mbps",
"instanceFamily": "General purpose",
"locationType": "AWS Region",
"licenseModel": "No License required",
"preInstalledSw": "NA",
"clockSpeed": "2.4 GHz",
"physicalProcessor": "Intel Xeon E5-2676 v3 (Haswell)",
"operatingSystem": "Linux"
}
},
"price": [
{
"sku": "ZPAH28S2QQZ64QB5",
"termAttributes": {},
"effectiveDate": "2015-12-01T00:00:00Z",
"offerTermCode": "JRTCKXETXF",
"priceDimensions": {
"ZPAH28S2QQZ64QB5.JRTCKXETXF.6YS6EN2CT7": {
"description": "$1.109 per Dedicated Usage Linux m4.4xlarge Instance Hour",
"pricePerUnit": {
"USD": "1.1090000000"
},
"rateCode": "ZPAH28S2QQZ64QB5.JRTCKXETXF.6YS6EN2CT7",
"endRange": "Inf",
"beginRange": "0",
"appliesTo": [],
"unit": "Hrs"
}
}
}
]
},
{
"product": {
"sku": "BMEYUTP658QKQRTP",
"productFamily": "Compute Instance",
"attributes": {
"enhancedNetworkingSupported": "Yes",
"currentGeneration": "Yes",
"operation": "RunInstances",
"instanceType": "m4.4xlarge",
"vcpu": "16",
"storage": "EBS only",
"location": "US West (Oregon)",
"memory": "64 GiB",
"processorFeatures": "Intel AVX; Intel AVX2; Intel Turbo",
"networkPerformance": "High",
"usagetype": "USW2-BoxUsage:m4.4xlarge",
"processorArchitecture": "64-bit",
"tenancy": "Shared",
"servicecode": "AmazonEC2",
"dedicatedEbsThroughput": "2000 Mbps",
"instanceFamily": "General purpose",
"locationType": "AWS Region",
"licenseModel": "No License required",
"preInstalledSw": "NA",
"clockSpeed": "2.4 GHz",
"physicalProcessor": "Intel Xeon E5-2676 v3 (Haswell)",
"operatingSystem": "Linux"
}
},
"price": [
{
"sku": "BMEYUTP658QKQRTP",
"termAttributes": {},
"effectiveDate": "2015-12-01T00:00:00Z",
"offerTermCode": "JRTCKXETXF",
"priceDimensions": {
"BMEYUTP658QKQRTP.JRTCKXETXF.6YS6EN2CT7": {
"description": "$1.008 per On Demand Linux m4.4xlarge Instance Hour",
"pricePerUnit": {
"USD": "1.0080000000"
},
"rateCode": "BMEYUTP658QKQRTP.JRTCKXETXF.6YS6EN2CT7",
"endRange": "Inf",
"beginRange": "0",
"appliesTo": [],
"unit": "Hrs"
}
}
}
]
}
]
制限事項
ざっくり構築方法
1. ソースを取得
git clone git@github.com:willyworks/aws-price-api.git
2. Lambda functionをデプロイ
virtualenv -p /path/to/python2.7 .venv . .venv/bin/activate pip install -r requirements.txt lamvery deploy
デプロイは拙作のこちらを使ってます。詳しくはLambda縛り Advent Calendar 2015の16日で書きたいと思ってます。
3. Amazon API Gateway Swagger ImporterでAPIを定義する
Amazon API Gateway Swagger ImporterでAPIを一発で定義する ｜ Developers.IO
4. Lambda functionの紐付けとMapping Templates設定
こんな感じ。
Mapping Templates↓
{
"offer" : "$input.params('offer')",
"term": "$input.params('term')",
"condition": $input.json('$')
}
4. CORS設定
5. Deploy API!!
所感など
- Price List API生で使うのツラい
- 変更通知がSNSで受けれるらしいし、データストアに突っ込んで通知をトリガーに更新させることを想定してる？
- LambdaもAPIのデータ受け取るのに一番時間かかってる。Lambdaから叩ける低レイテンシなキャッシュほしい。*2
- Reservedで期間指定できるようにしたり、もうちょっとAPIの改善もしたいかも
というわけで
以上です！当初は以下のどちらかにしようと思ってましたが、予定を変更してお送りしました！
この辺はまたの機会に！
個人事業主になりました
念のためはじめに言っておきますが会社は辞めてないですよ
色々書いて、最後のオチに持ってこようかとも思ったんですが、万が一の誤解を解くのが面倒なのでｗ
経緯
まず、私の勤めている会社で今年の春ぐらいかな？副業が解禁されました。
で、最近とある方面から個人としてお仕事のお話をいただけることがあって、その中で確定申告が必要な収入に達したので、確定申告の方法を調べていたら、どうやら副業でも個人として確定申告が必要なら個人事業主になった方が節税になるという情報を得て、ちょっとやってみようかなと思い立ったわけです。副業の対象に個人事業主は想定されていなかったんですが、試しに相談してみたら規定を見なおしてOKもらえました。会社に感謝です。
まあ、今現在安定して月収5万～10万円の保証なんてどこにもないわけですが・・・
正直、節税は割りとついでの意味合いで、こうやって形にすることで本業外で色々と動きやすくなると良いなーという想いがあったりする感じです。
どんな感じで働くの？
とりあえずは本業に影響を与えないことが前提なので、平日はフルタイムで出社して働いているので、休日や夜間がメインとなります（連絡くらいは多少遅れることはあるかもしれませんが、もちろんできます。手を動かすのはという感じ）なので、正直なかなか厳しいだろうなーとは思ってはいます。。。
何ができるの？
- クラウド（主にAWS、GCP勉強中）インフラ設計・構築
- Chef等を用いた所謂自動化・DevOps等の開発・運用フロー改善
- インフラからアプリケーションコードまで踏み込んだパフォーマンスチューニング
- PHP,Pythonを用いたアプリケーション開発（Go, Rubyもちょっとだけできます）
- 上記に関わるコンサルティングや技術支援
特に上の３つはそこそこできる方だと思っています。少なくとも道内では「この人には敵わない」って人は思い浮かばないです（勝っているとは言っていない）
特に、本業でもDeveloperとArchitect的なロールの両方をやっているので、インフラからアプリケーションまで含めて全体として最適なアーキテクチャを組んだりアプリケーションの設計をすることは普段から心がけていて、そのあたりはあまり他の人にはないバリューの出せるポイントかなーなんて思ったりしています。
なんか、こうやって自分の宣伝するのって恥ずかしいですねｗ
自分を見つめなおす良い機会になった気もしますがｗ
屋号は？
形だけに近くとも、せっかくの機会なので付けました。
Willyworks（ウィリーワークス）です。よろしくお願いします。
Willyの語源は学生時代にやっていたアメリカンフットボールのポジションの通称から取ってます。
正確にはWeak-side Linebacker(WLB)といい、簡単に言うと人数が少ない方（Weak-side）を広く守りつつ、時に鋭く前線に突っ込む（Blitz）みたいなポジション（僕の認識では）です。なんとなく自分の仕事にも当てはまるかなと感じたので。イギリス英語のスラングかなんかでアレな意味があるらしいですが。。。worksはそれっぽい感じで語呂が良かったのでｗ
というわけで
フルタイムじゃないので相談しづらいでしょうが、何かありましたらお気軽にご相談くださいませ。
