プログラマでありたい

おっさんになっても、プログラマでありつづけたい

『Amazon Web Services パターン別構築・運用ガイド』を書きました

 たまに呟いていましたが、AWSを題材に『Amazon Web Services パターン別構築・運用ガイド』という本を書きました。今回は、所属している会社であるNRIネットコム株式会社の同僚たちと書いています。

Amazon Web Services パターン別構築・運用ガイド

Amazon Web Services パターン別構築・運用ガイド

本を書いた理由



 前回執筆した『Rubyによるクローラー開発技法』が好評だったこともあり、SBクリエイティブさんからAWS本を出さないかという打診を受けました。AWSは長年親しんできたこともあり、また仕事でもAWSに関する事業を進めている関係で、願ったり叶ったりでした。
 一方で、やはり本を出すというのは大変です。私個人の問題で済めば良いのですが、やはり家族にも負担をかけます。前回の出版から間もないこともあり悩みました。その結果、共著という形で社内のメンバーと分担して書くことにしました。お陰でだいぶスムーズに書くことができました。
 ちなみに、JAWSUGなど対外的な発表は私がすることが多いのですが、社内には私以上にAWSについて詳しい人間は何人もいます。そんなメンバーと一緒に執筆がしていると、改めて勉強になることが多く、一段階成長できたように思えます。

本書の構成



 章題は変わるかもしれませんが、5章構成になっています。

1. AWSの基本
2. AWSを利用する
3. パターン別構築例
4. AWSのセキュリティ
5. 管理と運用

 あっさりした章題ですが、450ページ以上の大作です。1&2章が、AWSの概念と基本的な利用の仕方、3〜5章が実際の構築運用を見据えたパートとなっています。EC2やS3,RDSは無論のこと、SNS,SQS,SESをはじめとするアプリケーションサービスなども取り入れ、AWSのポテンシャルを引き出す使い方を大公開しています。
 書く段階から意識してきたことは、単なる使い方ではなく考え方を伝えたいということです。AWSはサービスのアップデートが早いので単なる使い方を書くだけであれば、すぐに時代遅れになります。考え方を伝えることが出来れば、例え新しいサービスが出てきたとしても役に立つはずです。そういう前提のもと、構築・運用とセキュリティについてしっかり書いてきたつもりです。
 あとはCloudAutomatorやTwilio,SendGrid,Mackrelなど、AWSと一緒に使うことをお勧めするサービスを幾つか紹介しています。そのあたり、割りと自由に書いたので楽しかったです。

対象としている読者



 本書の対象としては、AWSを少し使ったことがあるものの、本格的に使うには至っていない人を想定しています。JAWSUGの参加者たちから、よく相談を受けるポイントを意識しています。AutoScalingの設定のポイントや、セキュリティグループとネットワークACLの使い分けなどが一例ですね。
 一方で1〜2章で基本的な使い方を書いたので、初めての人でも大丈夫なようにしています。ここの部分、さらっと書く予定が気が付いたら150ページ超です。社内やお客さんとの研修で使えるなぁと話しています。
 また、ElasticBeanstalkのWorker TierやRoute53,IAMの運用なども書いているので、熟練者でも楽しんで頂けるのではと思います。あとはCognitoを使ったモバイルの2Tierアーキテクチャなど、わりと新しい取り組みもしています。それ以外にもAWSの導入を検討するにあたって避けては通れないコストとセキュリティについても取り上げています。社内を説得する一助になればと思います。
 実際、私も他のメンバーが書いたところを読んで、なるほどなぁと思うところが多々ありました。この本は、インフラ寄りの人間、アプリ寄りの人間、AWSを使ったシステムの導入を提案する人間、小規模から大規模なAWSのシステムを運用し続けてきたメンバーで書き上げられています。色々な視点を織り込んだものになっているので、どんな人にもきっと新しい気付きがあると思います。

苦労した点



 AWSのサービスアップデート多すぎです。利用者としては嬉しいですが、書いていてこれ程大変なことはなかったです。特に最近でたIAMのManaged Policy。これのお陰で、最後の最後で書き直す場所が沢山でました。※いや、Managed Policyは素晴らしい機能ですよ。これ使えば、運用設計がだいぶ楽になります。

まとめというか感想



 11月から執筆の話が始まり、ようやくここまで辿りつけました。その間、やはり嫁さんや子どもたちには迷惑掛けっぱなしでした。今回も家族の協力のお陰で何とか書き上げることができたので、感謝の気持ちでいっぱいです。
 また今回は会社のメンバーと共著です。彼らと一緒に執筆できて、本当に良かったです。ややもすると、私がボトルネックになることが多く、それを適切にフォローしてもらうことにより何とか完成させることができました。ありがとうございます。
 3/25発売なので、あと数週間です。最後の最後まで校正して、できるだけ良い物を届けます。サブタイトルは、「プロの知識が絶対に身に付く」です。これ読んで、プロの知識を身につけましょうw
※タイトル・サブタイトルは、出版社側が決めました。


続き
AWSパターン別本の狙い。例えばAutoScalingを使えるように


Amazon Web Services パターン別構築・運用ガイド

Amazon Web Services パターン別構築・運用ガイド


See Also:
『Rubyによるクローラー開発技法』を書きました
本を書く前に準備したこと、執筆中にしていたこと

日本一熱いデータベース論、「理論から学ぶデータベース実践入門」

 技評さんから理論から学ぶデータベース実践入門を頂きました。ありがとうございます。
f:id:dkfj:20150224011323j:plain

著者の奥野さん



 著者は、漢(オトコ)のコンピュータ道で有名な奥野さんです。直接の面識はないものの、データベース設計に悩み調べて行き着いた先が奥野さんが出している情報ということはよくありました。そんなこともあり、心のなかで勝手にデータベースの師匠として崇めています。そんな奥野さんが扱うテーマは、MySQLではなくデータベースです。個別の製品の話ではなく、データベース理論です。実践入門と銘打っているだけあり、データベース設計の具体的なやり方、考え方が随所にあります。

何について書いているのか?



 ポイントは、説明とやり方を集めたノウハウ集ではなく、設計の考え方の指針を示している点です。例えば、ID設計の話。永遠の論争であるナチュラルキーとサロゲートキー、どちらが適切かという命題があります。それぞれの利点と問題点を上げて、どういう場合に適しているかの持論を展開しています。そこから、IDの欠陥の例として、IDの一部に意味がある場合をあげ、「CLN-CYC-0123-BL」のような製品コードを取り上げています。IDの中に複数の意味を込められまくった例ですね。思わずあるあると言いたくなる設計の失敗を、その設計が何故悪いのか論理的に説明しています。このように理路整然と問題の本質を指摘できれば、設計レビューも随分と意味があるものになるでしょう。

データベース論



 そのような感じで、データベースに関するありとあらゆるところに持論を展開しています。まだざっと目を通して興味を持ったところを拾い読みしている段階ですが、どこをとっても濃いです。じっくり考えながら読むと1ヶ月は掛かりそうな濃縮度です。
 私は今現在、それほどデータベースに関わる仕事はしていません。しかし、随分長い間、データベースと向かい合ってきました。今考えると、随分多くの間違った設計やSQLを残してきました。逆に、今でも良い設計だなぁと思えるものもあります。それらと照らし合わせながら、やっぱりそうだよねとか、そういうことだったのかと今更ながら気がつくことが沢山ありました。そういった意味で、かなり幅広く読まれるべき本の一冊だと思います。でも、入門ではないですよね。

まとめ



 ちなみに、この本を読んでいて感心したのが、よくここまで持論を書けるなという点です。自身の執筆経験から考えると、技術書で持論を書くのは中々難しいことなのです。いろいろなやり方・考え方がある中で、自分はこう考えるとハッキリ打ち出すのは、実は難しいことです。気を強くもって書かないと、誰もがそうだよね知っているよねという当たり障りない本になってしまいます。その中で、データベースという万人が扱う技術に対して、ここまで熱く持論を語れるのは奥野さんだけなのではないかなと思います。
 データベースの世界に入り込んだばかりの人も、あるいはずっと歩み続けた人も、奥野さん流のデータベース理論にまず触れてみるのがいいのではないでしょうか。たぶん自分のデータベース理論の構築につながるでしょう。時間を作って、個別のテーマを紹介しようと思います。

理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)

理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)

Capybara+PhantomJS+Nokogiriを利用してスクレイピング

CapybaraとPhantomJS、Nokogiriを利用してのクローラー・スクレイピングの紹介です。

PhantomJSとは?



f:id:dkfj:20150214123247p:plain
 PhantomJSは、ヘッドレスブラウザと呼ばれるWebKitのエミュレータです。ヘッドレスブラウザとは、GUIではなくCUIから利用できるブラウザでプログラムから呼ばれます。UIのテストツールとしてSeleniumのようなサービスがあります。Seleniumはブラウザを直接操作するので、環境依存や動作が重いといった幾つかの問題点があります。そこでよく利用されるのがPhantomJSです。Seleniumに比べて、軽量というメリットがあります。RubyからPhantomJSを扱うライブラリとして、Poltergeistがあります。

Capybaraとは?



 Capybaraは、WebシステムのUI層のテストをサポートするためのライブラリです。主にDSL機能とDriver機能があり、テストフレームワークやブラウザ&ブラウザシミュレータを透過的に扱うことができます。
f:id:dkfj:20150214123816p:plain

Nokogiriとは?



f:id:dkfj:20140415021125p:plain
 Nokogiriは、Rubyで実装されたHTML/XMLの構文解析器(パーサー)です。Rubyの構文解析器としてはデファクト・スタンダードで、スクレイピングする際の必須のツールとなっています。Rubyで実装されたクローラー・スクレイピングライブラリの大部分は、内部的にNokogiriを利用しています。使い方の詳細は、下記のリンクを参照していただければと思います。
Ruby製の構文解析ツール、Nokogiriの使い方 with Xpath

PhantomJSとCapybaraのインストール



 PhantomJSのインストールは、Windowsでは少し面倒くさいことが多いです。PhantomJSのサイトからダウンロードしてパスを通すことが必要です。Mac+HomeBrewであれば、下記のコマンドでインストールできると思います。

brew install phantomjs

 その後に、PoltergeistやCapybaraをインストールします。

gem install nokogiri
gem install poltergeist
gem install capybara

 Windowsのnokogiriのインストールはハマる確率が高いです。ビルド済みのgemをダウンロードする方をお勧めします。x86-mingw32(32ビット版)もしくは x64-mingw32(64ビット版)と書かれているものがWindowsようです。
※最近、64ビット版も提供されるようになったようですね。

スクレイピング



 下記がCapybaraとPhantomjsとNokogiriを使ったサンプルスクリプトです。

require 'capybara'
require 'capybara/dsl'
require 'capybara/poltergeist'

class Scrape
  #DSLのスコープを別けないと警告がでます
  include Capybara::DSL

  def initialize()
    Capybara.register_driver :poltergeist_debug do |app|
      Capybara::Poltergeist::Driver.new(app, :inspector => true)
    end

    Capybara.default_driver = :poltergeist
    Capybara.javascript_driver = :poltergeist
  end

  def visit_site
    page.driver.headers # => {}
    #ユーザエージェントの設定(必要に応じて)
    page.driver.headers = { "User-Agent" => "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36" }
    #リファラーの偽装(特に不要)
    #page.driver.add_headers("Referer" => "http://yahoo.co.jp")
    page.driver.headers
    visit('http://www.yahoo.co.jp')
    #スクリーンショットで保存
    page.save_screenshot('screenshot.png', :full => true)
    #within(:xpath, "//*[@id='toipcsfb']/div[1]/ul[1]") do
    #Nokogirオブジェクトの作成
    doc = Nokogiri::HTML.parse(page.html)
    puts doc.title
  end
end

scrape = Scrape.new
scrape.visit_site

ポイントとしては、次のとおりです。
・Capybara DSLのスコープを別ける
  しないと、次のように警告でますよ
  including Capybara::DSL in the global scope is not recommended!
・Nokogiriを使ってる
  Capybaraの記法に慣れていない場合は、Nokogiriを作ってしまうのも1つの手です。
  無駄が多いけど

このサンプルでは、面倒くさいのでJavaScriptによって動的に構築された部分とってませんが。。。

まとめ



 JavaScriptバリバリのサイトからスクレイピングしたい場合、PhantomJSはお勧めです。少し重いものの、Seleniumでブラウザを動かすより断然軽量です。またブラウザのインストールが不要なので、サーバサイドで動かすことも容易です。今、PhantomJSをAWS Lambdaで動かそうかなと試しています。これが出来ればかなり面白いことが出来そうですね。
 この辺りの話をまとめた、「Rubyによるクローラー開発技法」という本を出しています。ひたすらクローリングとスクレイピングしているので、何か参考になることがあればと思います。


See Also:
『Rubyによるクローラー開発技法』を書きました
RubyでWebスクレイピングの話をしてきました。第1回Webスクレイピング勉強会@東京
Ruby製の構文解析ツール、Nokogiriの使い方 with Xpath
あらためてRuby製のクローラー、"anemone"を調べてみた
オープンソースのRubyのWebクローラー"Anemone"を使ってみる

バッチ処理について再考

 作業途中のメモです。バッチ処理の定義を確認しようとしてWikipediaをはじめとして幾つかのサイトをみてました。その時に目に入ったのが、下記の文章です。

利点
バッチ処理には以下のような利点がある。
・多くのユーザーがコンピュータのリソースを共有できる。
・処理をコンピュータのリソースがあまり忙しくない時間帯(多くは夜間、休日)にシフトできる。
・人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。
・高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。

バッチ処理 - Wikipedia


 これだけみると、人件費に対してコンピュータリソースが高い時代の産物なんですよね。今は、クラウドの登場で、有り余るコンピュータリソースをほぼ自由に低コストに使える時代です。そもそもバッチ処理である必要があるか、考える必要がありますね。特に夜間バッチについて。


 東急ハンズさんは、夜間バッチを廃止したそうです。たまには立ち止まって、何故その設計になっているのか、根本のところから問い直す必要性を最近感じています。


AWS 東急ハンズの事例 AWSサミット2013


Amazon Web Services パターン別構築・運用ガイド

Amazon Web Services パターン別構築・運用ガイド


See Also:
5分で何となく解るAmazon Cognito
Lambdaで作るクローラー/スクレイピング
S3のイベント通知機能(S3 Event Notifications)に対するユースケースを考える

JAWSUG関西 特別編でS3とCloudSearchとSWFの話をしてきました

 ちょうどタイミングが合いそうだったので、JAWSUG関西で発表してきました。担当したセッションは、サービス紹介です。S3+CloudSearchとSWFの2セッションを担当しました。

Amazon S3 & Amazon CloudSearch



JAWSUG Osaka S3 CloudSearch

 一つ目は、S3 + CloudSearchです。S3の概要の他に、お気に入りの機能であるS3 Webホスティング機能のデモをしています。また、新機能の紹介としてS3イベント通知を取り上げています。
 つづいてのCloudSearchについては、CloudSearchの機能というより、そもそも全文検索エンジンとはなんぞやという話がメインになっています。全文検索エンジン周りの技術は、いろいろ追いかけてて時代があって好きなんですね。ただ構築・運用するのは面倒くさいということで、CloudSearchは素晴らしいサービスだと思います。
 発表後に気がついたのですが、ひとつあります。そもそもS3とCloudSearchを選んだ理由として、S3とCloudSearchを組み合わせると簡単にS3のオブジェクト検索を出来ますよということを言いたかったのです。完全に忘れていました。すいません。

Amazon Simple Workflow Service



JAWSUG Kansai Simple Workflow Service (SWF)

 2つ目は、Simple Workflow Service(SWF)です。これを選んだ理由は、実はAmazon Mechanical Turkの紹介をしたいがためです。Mechanical Turkは、AWSの別のクラウドです。Cloudではなく、Crowd(群衆)です。いわゆるクラウドソーシングのクラウドですね。
 そんな理由からSimple Workflow Serviceを選んだのですが、そもそもあまり触ったことがなかったのですね。ついでに覚えようと思っていたのですが、いろいろ忙殺されて時間がとれずでスライドが出来たのが当日の朝です。そういったことで、Mechanical Turkまで辿りつけずです。残念なので、次回紹介します。Mechanical Turkを使うネタは幾つか考えてあります。

まとめ



 今回の勉強会のテーマは、フルマネージドサービスでした。私自身も最近の関心事項は、いかにEC2を使わずにAWSのマネージド・サービスを利用して楽に出来るかに移りつつあります。今回紹介したサービス群は、その重要なファクターになります。資料としてまとめることで、いろいろ頭の中を整理できて良かったです。皆様も、是非フルマネージドの世界へ

See Also:
5分で何となく解るAmazon Cognito
Lambdaで作るクローラー/スクレイピング
S3のイベント通知機能(S3 Event Notifications)に対するユースケースを考える
マルチプロトコルの凄いやつ。Amazon SNS(Simple Notification Service)
Amazon SNSとSQSの素敵な関係。或いは、Jenkinsからパトライトを光らせる。
マイナー三兄弟なAmazon SNS,SQS,SESを激しくお勧めする。

参照:
JAWS-UG KANSAI特別編 「AWSを使い倒せ。AWSのフルマネージドサービス活用によるネイティブクラウドシステムへの誘い」 - JAWS-UG KANSAI | Doorkeeper

Apple TVを中心としたホームシアター・オーディオ環境の一例

 何度かブログに載せていますが、過去5年ほど家庭の映像・音楽関係の視聴環境を試行錯誤してきました。その間に、結婚したり子供が産まれたりと、いろいろとメインの利用者が変わっています。一度、ここで整理してみたいと思います。

前提としての主な視聴者



 最近、家でテレビや音楽を聞くのは、3歳の息子です。見聞きする内容は、もっぱらYoutubeの電車の映像と、子供向けの童謡やジブリ・ディズニーのテーマ曲です。後は毎週テレビでやっている機関車トーマスとチャギントンです。それ以外は1歳の娘向けに、オルゴールメロディやNHKのいないいないばあをつけるくらいです。またDVDで子供向けのタイトルが幾つかあるのですが、基本操作が面倒くさいので見ていません。嫁さんについては、Huluで映画をたまに見るくらいで、私に至っては息子に強制的に見せられるYoutubeの映像を見るくらいです。

家庭内の視聴環境



 そんな我が家の視聴者のニーズを満たす環境は、次のとおりです。

  • 東芝REGZA Z7 + タイムシフト
  • SONY ホームシアターシステム HT-CT660
  • Apple TV + Hulu
  • Mac mini
  • iPad

 接続形態は、このような形です。

f:id:dkfj:20150125170526p:plain

 図を見て貰うと解るように、いろいろな機器の連携の中心にApple TVがいます。Apple TVの便利なところは、TVとオーディオのどちらでも出力できるところと、Apple系製品から画面転送やiTunesライブラリの参照ができるところ、更にHuluの機能を組み込んでいるので文句なしです。欲を言えば、メディアサーバの機能も欲しいところですが、9割の人間には不要なのでこのままで良いでしょう。
 REGZA Z7ですが、タイムシフトというか録画機能が欲しくて、先代のテレビが壊れたタイミングで買い替えました。基本的にはテレビはみないのですが、予想以上に便利です。定期予約やタイムシフトから、子供向けの番組をちょっと見せるという芸当は、子育て世代には想像以上に便利です。忘れず録画するとか、毎回同じ時間に見るということが中々できないですからね。また、ほぼ同時期に買ったSONYのホームシアターシステムですが、イメージ的にはアンプとスピーカーが一体型になっているものです。Apple TV経由で聞いていますが、iPhoneやiPadからブルートゥースで直接音楽を流し込むということも出来ます。いずれにせよ、手軽に簡単に音楽を楽しめます。
 iPadは、ほぼ子供のYouTubeリモコンになっています。AppleTV単体でもYoutubeをみれるのですが、UI的に使いにくいので子供はもっぱらiPadを使ってYoutubeを見ています。iPadでみると姿勢が悪く近いところで見がちなので、AppleTV経由でテレビに転送して見せるようにしています。最後にMac Miniです。これは、我が家のメディアサーバとして活躍しています。(それ以外にも、ホームサーバとして活躍していますが割愛。)音楽も全部これに入れているのですが、AppleTV経由で使えば、Rometeを使えばiPhoneをリモコンとして選曲できるので便利です。iPhone/iPadのを直接流すという手もありますが、子供向けの曲などは、入れてなかったりします。
f:id:dkfj:20150125205526p:plain

家庭内の視聴環境



 改めて見直すと、マニアックな構成になっております。しかし、実際のところ視聴時間という意味では、あまり無かったりするので、単なる利便性を追求する趣味なのかもしれません。これが正解というものはないですが、また面白いものを考えてみたいですね。Mac miniがホームサーバとして常時動いているので、これにIoTの機器を何かつけて近未来の家を目指してみるのも面白いかもしれません。Enjoy!!

See Also
Mac miniを買ったった! (Late 2014 MGEN2J)
Apple TVでNAS上の動画・音楽を再生する方法
AirPlayを使って、AppleTV+AVアンプでホームオーディオ・システムを構築する話
Hulu(フールー)の契約したった。或いはAppleTVとの連携について
笑える程の凄さ!未来のテレビがここに Apple TV

Apple ハイビジョン対応 Apple TV MD199J/A

Apple ハイビジョン対応 Apple TV MD199J/A

SONY ホームシアターシステム HT-CT660

SONY ホームシアターシステム HT-CT660

5分で何となく解るAmazon Cognito

 年末年始でじっくり調べてみようと思っていたのがCognitoです。先日ようやく時間が取れて、何となく解ってきたので簡単にまとめてみます。Cognitoは、モバイル向けに設計されたユーザーアイデンティティおよびデータ同期のサービスです。主な機能としては、以下の3点です。

  • FacebookやGoogleなどのOpenID ConnectベースのIdentity Providerを利用して認証できる
  • Cognito Syncで、同一ユーザの複数の端末のデータを同期できる
  • 認証/未認証のユーザにIAM Roleを利用して、AWSリソースのアクセス制御

 上記の説明を聞いても、Cognitoの良さはさっぱり解らないと思います。私もCognitoの説明を読んでも、Facebookで認証できるのかぁくらいにしか感じませんでした。Cognito Syncの同期機能も、ほーっと思ったけど必要とする場面はどれくらいあるのだろうなぁと思いました。

Cognitoの重要性



 しかし、Cognitoのユースケースが出始めることで、ようやくCognitoの重要性が解ってきました。Cognitoの重要な機能は、安全簡単にAWSリソースのアクセス制御ができることなのだと思います。モバイル・アプリの場合、サーバサイドのプログラムのようにアクセスキーとシークレットアクセスキーを埋め込むことはできません。配布するために、アプリ内からキーを取り出される可能性があるからです。かといって、インスタンスのようにIAM Roleを発行するということも出来ません。モバイルからAWSのリソースを利用しようとすると、従来であればSecurity Token Service(STS)とToken Vending Machine(TVM)を利用して一時的な認証と認可の仕組みを構築する必要がありました。
 これ非常に面倒くさいですよね。ということで、どういうアーキテクチャが主流だったかというと、下の図のような形だと思います。

f:id:dkfj:20150119232504p:plain

 いわゆる三層構造(3Tier Architecture)です。AWSのリソースの制御はEC2側でやってしまって、モバイル側には結果をJSON等で返すだけという形です。この構成だと、当然全てのリクエスト・レスポンスがEC2を通ることになるので、この部分の性能と可用性が重要になります。必然的に、ELBやAutoScalingを利用することになります。EC2は、直接的な利用料がAWSサービスの中でも比較的高いことや、構築運用監視に人手が必要なため、コストが高くつきます。

Cognitoがもたらすアーキテクチャの変化



 では、Cognitoを利用するとどう変わるのでしょうか?EC2を経由せず、モバイルから直接AWSのリソースにアクセスする構造を簡単に実現できます。2Tier構成です。

f:id:dkfj:20150119233617p:plain

 CognitoはIAM Roleを利用して、認証/未認証のユーザにそれぞれアクセス認可を与えることができます。この未認証ユーザにもというところが味噌で、これのお陰でモバイル・アプリに簡単安全にアクセス認可する仕組みとして利用できます。事実、CognitoのIdentity Poolを作成する時に、実はIdentity Providerの設定は必須ではありません。実装面では、Cognitoの設定をしておけば、後はSDKを取り込んで少しコードを書くだけで、簡単に利用可能です。従来のようにSTS+TVMを使って独自の認証認可の仕組みを実装する必要はありません。Cognitoのウリは、安全簡単に認可の仕組みを組み込めるので、アーキテクチャすら変える力があるということです。

まとめ



 ということで、ここ最近Cognitoについて考えてきたことをまとめてみました。Cognitoは、2Tierアーキテクチャの要になると思います。ただ、まだドキュメント読んだりサンプルコードを動かしているレベルなので、今後本格的にアプリを開発し運用してみると考え方は変わるかもしれません。しかし、Lambdaが出てきたこともあり、AWSはシステムのアーキテクチャ自体を変えるような何かを考えているのではと思います。今年はそこを見極めてみたいですね。たぶんそのうちに、Node.js向けのCognito SDKもでるでしょうし。ツッコミどころあれば、ご指摘頂ければ幸いです。

See Also:
Lambdaで作るクローラー/スクレイピング
S3のイベント通知機能(S3 Event Notifications)に対するユースケースを考える


Amazon Web Servicesクラウドデザインパターン設計ガイド

Amazon Web Servicesクラウドデザインパターン設計ガイド