Amazon API GatewayのMock機能を使ってみる

　前回のJAWSUG千葉ネタですが、Amazon API GatewayのMock機能を使ってみようというお話です。時代は、2-Tierアーキテクチャやサーバレス・アーキテクチャだと勇ましいですが、足元をみるとレガシーから脱却できずに苦労しているという現実もあると思います。そんな時に、API Gatewayのモック機能を使って、部分的にでも文明の利器を感じるのは良いのではないでしょうか？

Amazon API GatewayのMock機能とは？

---

　最初期のAPI Gatewayには4つの機能がありました。Lambda連携とAWS Proxy,Http Proxyの3つです。4つ目の機能として追加されたのが、Mock機能です。最初の3つの機能は、API Gatewayを通じて別のリソースを呼び出す機能です。これに対して、Mock機能はAPI Gateway自身が直接的に値を返す機能です。名前の通り、バックエンドのサービスが出来る前に代わりに仮の値を返すサービスです。バックエンドのサービスが出来上がる前に、開発環境として利用するのが良いのではないでしょうか？

Amazon API GatewayのMock機能の使い所

---

　Mock機能は、どのように使えば良いのでしょうか？例えば、モバイルアプリの開発に使うのが良いのではと思っています。最近のモバイルアプリは、当たり前のようにサーバ側のシステムと連携します。その際の連携方法としては、JSON等の形式で連携することが多いです。まぁよくあることだと思いますが、スマホのアプリ側を作り出している時は、それに対応するためのサーバ側のAPIを同時に作ることが多いです。そして、開発途上でモバイル側のアプリの動作をみる場合は、当然ながらサーバ側のAPIが必要になります。API側の完成を悠長に待つことは出来ないので、スタブが必要となります。
　私が関わってる開発の現場では、S3のWebホスティング機能を利用しJSONファイルをアップしてスタブとして利用していました。こんな感じですね。

これはこれで簡単便利なのですが、幾つか残念なところがあります。

• 返り値を変更する為には、わざわざファイルをアップロードするのが面倒くさい
• レスポンスコードやヘッダーの変更ができない

　そこで登場するのが、Mock機能です。
こんな感じに変わります。

　見た目は余り変わりませんね。
でも、思った以上にメリットがあります。

• AWSのマネジメントコンソール上で、返り値の変更をできる
• レスポンスコードやヘッダーの変更が簡単

　特に後者がありがたいです。異常系テストで、アクセス拒否やサーバエラーが発生した時の挙動を簡単に再現出来るのは便利です。

Amazon API GatewayのMock機能の設定

---

　では、どうやって設定するのでしょうか？一度覚えてしまうと簡単ですが、まぁ最初は解りづらいこと間違いなしです。中の人いわくSwagger使えとのことです。といっても、最初からサードパーティのツールから入るのも取っ付きにくいので、AWSマネジメントコンソールの設定例をあげておきます。

まずは一連の流れを動画で見てください。

www.youtube.com

つぎに個々の動きについて、細かく切り出してみます。

1. APIの作成

2. リソース（Resource）の作成

3. メソッド（Method）の作成 1

4. メソッド（Method）の作成 2

5. メソッド（Method）の作成 3

6. メソッド（Method）の作成 4

7. メソッド（Method）の作成 5

8. メソッド（Method）の作成 6

9. テスト 1

10. テスト 2

11. デプロイ 1

12. デプロイ 2

　まぁ何というか面倒くさいですね。

感想

---

　まぁ賛否両論どちらかといえば非難轟々のUIですが、コーディングレスで管理コンソールだけでも試せるということは、敷居が低いという面で良いと思います。恐らく管理画面は、どんどん変わると思うので次はSwaggerの使い方の紹介でもしようと思います。

追記：
この辺りのことを、『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』という本でコッテリ解説しています

_
See Also:
JAWSUG千葉で、API Gatewayの話をしてきました。

参照：
Amazon API GatewayでMockを定義してみる - Qiita

Amazon Web Services パターン別構築・運用ガイド 　一番大切な知識と技術が身につく

Amazon Web Services クラウドネイティブ・アプリケーション開発技法　一番大切な知識と技術が身につく

JAWSUG千葉で、API Gatewayの話をしてきました。

　JAWSUG千葉で、API GatewayとLambda縛りという素敵な勉強会がありました。機会を頂いて、私も話してきました。

Jawsug chiba API Gateway from Takuro Sasaki

www.slideshare.net

API Gateway

---

　昨年末にLambdaが発表されて、モバイルアプリ開発者の端っこの方に属している身としては狂乱麗舞しておりました。一方で、少しどうすべきかなぁという部分があります。AndroidやiOSまたはJavaScriptからLambdaを呼び出す場合は、CognitoでAWSの利用権限の管理をするのが一般的です。その実装をそれぞれのアプリに組み込むより、組み込んだものをAPIとして利用する方が疎結合になり楽だなと考えていました。
　そんな所で満を持してAPI Gatewayの登場です。アプリとAWS側がより疎結合に設計できるようになりました。API Gatewayを利用すると、もうアプリ側としてはAWSにつないでいるという意識すらなくなります。これぞ21世紀のアプリという感じになってきました。

　実際に、API Gatewayを使ってみると、UIが解りにくい。この1点に尽きます。色々な要素を出来るだけ簡潔に表現するために致し方ない面があったのだと思いますが、解りにくいです。ということで、取っ掛かりで挫折しないように使い方を中心に解説しています。API GatewayのUIは、どんどん変わっているので、すぐに差異が出てくるとは思いますが、まずは試して貰えればなぁと思います。次はSwaggerあたりの紹介もしたいですね。

www.youtube.com

Amazon Web Services パターン別構築・運用ガイド 　一番大切な知識と技術が身につく

クローラー／スクレイピング本がざくざく

　2015年8月末に、クローラー／スクレイピング本が2冊同時に発売です。Python版メインのものとJavaScript版メインのものです。なかなか市場のニーズ突いてきていますね。

実践 Webスクレイピング&クローリング-オープンデータ時代の収集・整形テクニック

JS+Node.jsによるWebクローラー/ネットエージェント開発テクニック

実践 Webスクレイピング&クローリング-オープンデータ時代の収集・整形テクニック

---

　実践 Webスクレイピング&クローリング-オープンデータ時代の収集・整形テクニックは、Pythonをベースにしたスクレイピング／クローラー本です。「インターネットを1つの巨大なデータベースとして扱えるようになろう」とキャッチコピーがあり、その為にいかに効率的にデータを取得するのか、またその為に注意するための法律面についての言及してあります。
　著者の@nezuqさんは、スクレイピングの勉強会である東京スクラッパーの主催者です。私も、Rubyのクローラー本を書いた際に、何回か発表の機会を頂きいろいろとお世話になりました。その縁もあり、今回献本いただき読ませて頂いています。ありがとうございます！！

　ざっくり読みましたが、非エンジニアやスクレイピング／クローラーを全然知らない人には良いのではないでしょうか。理由としては、200ページくらいと軽量なことと、Windows前提のPythonを選択していることが主な理由です。さっくり読めます。Webスクレイピング代行サービスとしてkimonoや、オープンデータ・WebAPIの紹介等もしています。また、データの整形ツールとして、nkfやAWK,Excelとの連携も紹介しています。基本的なスクレイピングする際によく使うものが紹介されています。ただし、ここの説明については、あまり深くないです。スクレイピングを始めるための押さえる技術のガイド本として活用すべきかと思います。道を教えて、あとは独学で補うというタイプです。

実践 Webスクレイピング&クローリング-オープンデータ時代の収集・整形テクニック

---

　もう一冊のクローラー／スクレイピング本は、JS+Node.jsによるWebクローラー/ネットエージェント開発テクニックです。こちらの方は読んでいませんが、430ページという分厚さで利用しているライブラリも「PhantomJS/CasperJS/CoffeeScript/Electron/Node.js/Rhino/Nashorn/JScript他」と色々な深いところまでやっていそうな予感です。読んでみようと思います。

感想

---

　私がRubyによるクローラー開発技法というクローラー／スクレイピング本を出したのは、ちょうど1年ほど前です。その前には、Spidering hacksという10年ほど前の本があったくらいです。手前味噌ですが、クローラー本が予想外に売れたお陰で、クローラー／スクレイピングに対するニーズが意外に高いということが発見され、どんどん同種の本が出てくるのはありがたいことです。いつ発売か解りませんが、もう1冊スクレイピング本を書いている人も知っています。

『Rubyによるクローラー開発技法』を書きました
Rubyによるクローラー開発技法の目次

Rubyによるクローラー開発技法 　巡回・解析機能の実装と21の運用例

WEB+DB PRESS Vol.88でモバイル開発の話を書きました

　2015/8/22発売のWEB+DB PRESS Vol.88にモバイル開発の話を寄稿しました。内容としては、クラウドサービスを利用して、楽に開発しようよという話です。白状すると私が書いたのは最初の1章だけで、後は会社の後輩の@yanayanalteに書いてもらいました。

目次

---

　今回の特集は、5章構成です。背景のところから、ビルド・テスト・デプロイと一通りの工程を取り扱っています。

1. いまどきのモバイルアプリ開発事情　〜クラウドの活用でプロダクトの改善に注力する〜
2. CircleCIを使った自動ビルド　〜ヒューマンエラーを防ぎ安定した開発を実現する〜
3. Scirocco Cloudを使ったE2Eテスト　〜他機種・多端末での検証を省力化する〜
4. DeployGateを使ったデプロイ　〜ストレスなくα版アプリを配布する〜
5. Crashlyticsを使った障害検知　〜運用中のクラシュ情報を見える化する〜

特集の内容

---

　内容については、以下の特集説明のとおりです。

■特集1
モバイル開発最前線 ―― ビルドもテストもデプロイもクラウドで加速!
昨今、AndroidやiOSなどのモバイルアプリ開発におけるビルドやテスト、デプロイといったフェーズを省力化するためのクラウドサービスが多数登場しています。そこで本特集では、「いかに高速に開発するか」「設計や実装に注力するためにはどうするか」といった視点から、CircleCI、Scirocco Cloud、DeployGate、Crashlyticsといったクラウドサービスを組み合わせ、モバイルアプリ開発を効率化するための方法を余すことなく紹介します。

　最初の企画の段階では、クラウドサービスを利用することに特化せず、Jenkinsなどインストール型のツールなどの紹介や、バージョン管理や開発スキル向上の話まで盛り込もうとしてました。その企画案では、個々の内容が薄く特徴がなくなるという指摘を編集者さんに頂きました。それではということで、クラウドサービスを利用するということに特化した構成にしてみました。
　モバイルの場合、MacOSの問題やスマホ実機の問題があり、開発環境をクラウドに持っていくのは難しいと思われていました。しかし、最近ではその辺りの課題については殆ど解消されていて、逆にクラウドサービスを利用する方が便利になってきています。その辺りを書いているので、興味があれば読んでみてください。

執筆の背景にある狙い

---

　ここ1年くらいの仕事での関心事は、モバイルアプリチームの生産性の向上でした。生産性向上というのは、色々な尺度があるので一概には言えないのですが、私としては次の目標を立てて実現する方法を模索していました。

「チーム全体として、1ヶ月あたりでリリースできるアプリの数を増やす」

　その為には、以下のことを考えていました

• 個々のメンバーが、設計・コーディングなど開発の本質部分の時間に割り当てられる時間を最大化する
• 新規参入メンバーの習熟コストを最小限に出来るようにして、チームのスケールアウトを容易にする
• 技術向上の為の効率的な学習方法

　まぁざっくりと言うと、長い時間を掛けて個々人の生産性を極限まで上げることを目指すのではなく、人を増やしてもよいからチーム全体のアウトプットを増やす方向性です。その為には、コンピュータが出来る部分はコンピュータにやらせて、設計・コーディングといった人間にしか出来ない作業に集中できるようにするということです。そうすると、面倒くさい手順的な部分は覚えずに済むし、量をこなせるので習熟も早くなるということが期待できます。
　改めて考えると、根本的にはSIerの発想ですね。ただSIerの陥りがちな罠である、最低限のスキルに達していない人間を前提としたコーディングルールやフレームワークでガチガチで固めるという方法は取りませんでした。ルールではなくシステムやコードレビューを前提とすることで、チームの拡大にともなって個々人の生産性が落ちるといったことは発生しませんでした。結果としては、チームの規模としては2倍程度の拡大に対して、アウトプットとしては4倍近くまで達しているので概ね上手くいったのではないかと考えています。

　そんなこんなで試行錯誤したことのうち、主にシステム面の部分を記事化しました。技術の習得やスキルトランスファーの話も、いつかまとめてみたいものですね。

感想

---

　雑誌の寄稿というのは初めてで、その雑誌がWEB+DB PRESSでした。他の執筆者陣はそうそうたるメンバーで、その中に並んで名前が載り非常に光栄です。また私の方は企画と序文を書くだけで、あとの部分は全部@yanayanalteがやってた訳ですが、申し訳ないなぁと思いつつ、やれば出来るだろうと思ってました。実際、頭で思い描いてた通りに実現してくれて非常にありがたいです。今年はもう一冊本を書こうと思っているので、是非また巻き込もうと思います。

WEB+DB PRESS Vol.88

See Also:
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

DevLOVE関西で、クラウド時代のエンジニアについて考えた

　前回のJAWSUG大阪で共著者の佐藤さんが話した「Slerがawsで運用してきた話」が好評で、DevLove関西でお話する機会を頂きました。私もご相伴して、「Amazon Web Services パターン別構築・運用ガイド」の著者陣2人で講演となりました。

devlove-kansai.doorkeeper.jp

オープニング

---

　まずはDevLOVE関西の主催者の@yohhatuさんのオープニングスライドです。DevLoveのコンセプトが簡潔かつ明確に宣言されています。「DevLOVE関西は素振りの場。現場は実践の場」という言葉が良いですね。あと、第96回目というのが凄いです。
※公開されていないようなので、貰ったのをS3にアップしています。

クラウドがアーキテクチャを変え、 エンジニアの役割も変わる

---

　私のセッションでは、クラウドの台頭でアーキテクチャが変わり、その結果エンジニアの役割も変わりつつあるのではという話をしました。長年AWSを使い続けて、またモバイルやデジタルマーケティングといった変化の早い分野の業務を担当していて、そこはかとなく感じていたことを言語化してみました。

DevLove Kansai AWS from Takuro Sasaki

www.slideshare.net

　まだうまくまとめられていないですが、確信していることはあります

• 従来のアプリ／インフラエンジニアという枠組みでは対処しきれないことが増えている
• 汎用的な部分はクラウドやフレームワークで用意されている分、それぞれの分野で深い知識をエンジニアには逆に求められるようになってきている
• （両方を極めているスーパーマンみたいのがたまにいるので、凡人には困る）

　私は、1つの分野を極める方向に進みたかったのですが、自身の性格のためか色々な事に少しづつ手をだすエンジニアになりました。結果、スライド中にある赤魔道士みたいな中途半端な存在になったのですが、まぁ最近は割りきって専門性の高い人達につなぐことに徹しています。そんな働き方もあるんだよと紹介したつもりです。

アプリエンジニアからクラウド専用のインフラエンジニアになってみて

---

　2つ目がメインのセッションです。共著者の佐藤さんによるアプリエンジニアからインフラエンジニアにジョブチェンジした話です。

アプリエンジニアからクラウド専用のインフラエンジニアになってみて from Sato Shun

www.slideshare.net

　具体的な話が盛り込まれて、かなり面白い内容でした。彼はいつも私のムチャぶりに巻き込まれているのですが、常に期待以上の成果を出してくれる頼もしさです。Infrastructure as codeやAPI Gatewayのくだりが、現場からの生の声が聞こえて参考になります。

ダイアログ

---

　その後が、DevLOVEならではのコンテンツということで、ダイアログがありました。参加者自身でテーマを決めてグループになって話し合うという内容でした。出てきたテーマは、下記の４つです。

• （API Gateway等の）テスト環境をどうするか
• 企業内でAWSを導入するには、どうしたらよいのか
• Infrastructure as codeの実際について
• クラウド利用の費用対効果

　最初はぎこちなかったのですが、徐々に会話も活発になり色々な現場の話が出てきました。私はぶらぶらしながら色々な話に軽く参加していたのですが、あるあるという話から成る程という考え方まで色々あって面白かったです。まさにコミュニティーという感じで良かったです。

その他

---

　ブログ書きながら、TwitterやFacebookみていたら立て続けに似たようなテーマの発表がありました。私が言語化しようとしてうまく出来なかった部分が、うまく表現できているて凄く参考になりました。是非見てください。さすが堀内さん

ベンチャーCTO、AWSエバンジェリストを経て考える、クラウド時代に向き合うエンジニア像のこれから from Yasuhiro Horiuchi

www.slideshare.net

こちらも面白い
若手インフラエンジニアたちが語る技術トレンドと数年後の未来

感想

---

　今回は、初DevLOVE関西でした。最近は、JAWSUG以外のイベントにも参加するように心掛けています。やっぱり、まったく違う文脈の人と話せるのは面白いですね。バックグランド的には、DevLOVE系の人の方が近い人も多く、もっと参加しようと思いました。またよろしくお願いします。

Amazon Web Services パターン別構築・運用ガイド 　一番大切な知識と技術が身につく

Amazon API Gatewayの設定の構造

　Amazon API Gatewayの登場で、2Tier-Architectureのピースが揃ったように思えます。いろいろ試してみたいのですが、ちょっと設定の構造が初見でよく解らなかったので一旦整理してみます。理解が間違っていたら、是非指摘してください。

Amazon API Gatewayの用途と構造

---

　まずは、Amazon API Gatewayの公式ドキュメントを眺めてみます。幾つかの用語が出てきています。API,Resource,Method, Method's Settings,Models and Mapping Templates, Stagesまず最初の4つを整理してみます。

　まずAPIを作ります。APIは、オブジェクト指向でいうところのクラスのようなものでしょう。クラスの中に、Resourceを作ります。リソースは、APIにアクセスする為のパスです。まずはデフォルトの/（ルート・ディレクトリ？）を作り、任意にサブディレクトリのような感じで複数作っていきます。
　リソースを作ると、次にMethodの設定を行います。Methodoは、HTTPのプロトコルに対応していて、GETやPOSTの他にHEADやPUTなどが作成します。現実的には、GETとPOSTだけを使うことになるのではと思います。なお、１つのリソースに対して、設定できる同一種別のMethodは１つのみです。/getDataというリソースに対しては、GETは1つだけ設定できます。またPOST等の違うメソッドも設定出来ます。設計上は、1つのリソースに1つのMethodにしておいた方がよいと思います。
※RESTのURIは何を表現するということで、名詞を使うらしいです。そして、どうするという部分を表現するのがMethodとのことでした
　最後にメソッドの設定です。ここがAPI Gatewayの肝になります。設定としては、Lambda Function, HTTP Proxy, AWS Service Proxyの3種類が設定できます。基本設定では、Lambda FunctionとHTTP Proxyを設定でき、Advance SettingでAWS Service Proxyが選択できます。この辺りにAWS側の意図が少し見えてきます。

StagesとModels

---

　StageとModelもAPIにひも付きます。Stageは、利用用途です。例えば、本番用やテスト用など、URLやキャッシュ・ログ・監視やバーストの上限などを変更できます。そもそも、テスト用などでAPI Gatewayの接続先が切り替えられるか気になるところですが、画面コンソールを見る限りは、できなさそうです。もう少し継続調査します。
　次にModelです。これは、API Gatewayの接続先からの返り値をマッピングする為のモデルです。返り値としては、JSONに変換して出力する形になります。デフォルトでは、エラーと空だった場合のものが用意されています。

Error

{
  "$schema" : "http://json-schema.org/draft-04/schema#",
  "title" : "Error Schema",
  "type" : "object",
  "properties" : {
    "message" : { "type" : "string" }
  }
}

Empty

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "title" : "Empty Schema",
  "type" : "object"
}

　API Gatewayを実装していく場合は、ひたすらこのモデルを定義していく形になるのではと思います。恐らくAWS Service Proxyの場合は、ある程度テンプレート的なものが用意されていくと思いますが、それでもデータの型によってそれぞれ違ってきます。コンソールで試しに作っていたのですが、これは最終的にはコードとして管理しないと手に負えなくなる予感がします。

AWS Service Proxyの利用

---

　AWS Service Proyについては、まだ余り試せていません。DynamoDBの結果などをそのまま取得できれば胸熱です。このAWS Service Proxyについては、IAM Roleを利用して権限設定をします。ロールの設定の際に、Principal（信頼関係）の設定が必要なのですが、現状では選択肢としてAPI Gatewayがでてきません。次のような感じで、apigateway.amazonaws.comを設定しましょう。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "apigateway.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

まとめ

---

　まだ全然時間が取れていないので、未知数の部分が多いですが、昨年のLambdaに引き続き楽しいサービスなのは間違いないです。最近は、サーバを立てずにどうやって実現するかを考えているのですが、その重要な要素の1つになります。一方で、API Gatewayの実体は、ApacheやNginxのrewrite proxyのようなものと、AWS系のリソースを呼び出せるアプリケーションエンジンの組み合わせと推測できます。当然オーバヘッドはあるので、どれくらいのパフォーマンスなのか測っていく必要があると思います。（誰かやってくれると思うけど。）

参照：docs.aws.amazon.com

Amazon Web Services パターン別構築・運用ガイド 　一番大切な知識と技術が身につく

IoTは製造業とユーザをダイレクトに直結する

　昨日、オフィスグリコについて書いていて考えていたことがあります。メーカーであるグリコにとって、あの販売形態は重要な意味があるのではないかという点です。一般的な流通形態は、卸売店・小売店を経由してエンドユーザである消費者に届きます。オフィスグリコは、ロジスティクスの具体的な事は知りませんが、限りなくメーカーとユーザを直接結びつけています。このことは、恐らく大きな意味を持つようになるのではと思います。

　実は、この構造は最近のIoTでも同じなのではと思います。IoTが注目されている点は、機器にセンサーを付けることによって今まで集めることが出来なかったデータを収集できることにあります。一例をあげれば、AppleWatchのようなもので、一日の脈拍や運動量というデータを集めることができます。まだ、それほど進んでいませんが、家電にセンサーを付けることにより、その家電が実際にどう動いたか（頑張ってプラットフォームを作れば）集めることができます。冷蔵庫やクーラーの稼働状況を可視化するということも可能ですね。
　このIoTは、別の側面から見るとメーカーとユーザを直接結びつけることになります。今までであれば、製品がどのように使われているかは、アンケートを取ったり、サンプリングして観察するくらいしか方法がなかったです。これが、直接メーカーが確認できる可能性が出てきているのです。これは大きな意味があるのではないでしょうか。例えば、コマツが車両にセンサーやGPSを付けて出荷することにより、製品保守の向上だけにとどまらず需給予測や市況判断まで出来るようになりました。
　こういった事例がどんどん出てくるのではと思います。つまりメーカーがサービス業に転換する可能性です。そうなると、世の中の仕組みがどう変わるのか。どこが儲かるようになるのか。その辺り、考えています。この前、「データの見えざる手」を読んで、IoTやセンサーの何たるかが少し解ってきて、俄然興味がでてきています。

See Also:
オフィスグリコの規模

データの見えざる手　ウエアラブルセンサが明かす人間・組織・社会の法則