プログラマでありたい

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

『Amazon Web Services パターン別構築・運用ガイド』の表紙ができました

連日ご案内している『Amazon Web Services パターン別構築・運用ガイド』。ついに表紙ができました。見てください!!


 デザイン全体は、メカニカルでしっかりとした感じに仕上がっています。高価格帯の本なので、イメージにあっていると思います。そして、中心の写真(絵)なんですが、これ何でしょうか?タイプライターっぽいですが、秤に見えなくもないです。私も帯を取って判断しようと思います。
 もうひとつの注目は、サブタイトルが変更されていました。

Before
プロの知識が絶対に身に付く

After
一番大切な知識と技術が身につく

 出版社や企画の出し方によると思いますが、一般的には書名とか表紙に関しては出版社側が決める事項となります。なので、書名の理由とか、表紙の意味を聞かないでくださいね。私も類推しているところなので。

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

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

See Also:
2015/03/04/102003
AWSパターン別本の狙い。例えばAutoScalingを使えるように。「Amazon Web Services パターン別構築・運用ガイド」の裏話
『Amazon Web Services パターン別構築・運用ガイド』を書きました
『Rubyによるクローラー開発技法』を書きました
本を書く前に準備したこと、執筆中にしていたこと

私とAWSの9年間


 新幹線の中で、もうすぐ発売される「Amazon Web Services パターン別構築・運用ガイド」の前書きを考えています。ふと、AWSとの出会いはどうだったのかなと思い、過去の記録と記憶をサルベージしてみました。

AWSとの出会い



 AWSとの出会いは、2006年のAmazon S3です。当時はアメリカのシリコンバレーで働いていて、レンタルサーバのようなものを探していました。幾つか探している時に、ちょうどAmazonがWebサービスを出すというニュースが飛び込んできました。ストレージのWebサービスとは何か、さっぱり見当つかなかったものの、とりあえず惹かれるものを感じ使いだしたのが最初です。実はそれ以前から、Amazon Web Serviceという名称は存在して、当時は商品を操作するAPIとして提供されてました。今でいうProduct Advertising APIですね。がっつり使っていたので、AmazonのAPIの延長という間隔で、それほど違和感は感じていませんでした。何か全く別の方向性で来たなぁくらいの感覚だったと思います。
 プログラムからストレージ自体を操作できるということで、面白がって用途を考えていました。一方で、米国の一般家庭での回線は結構遅いので、オンラインでストレージ使うのはバックアップ以外は厳しいなぁと感じました。また、当時はストレージ単価も今より高く、データのアップロードにも課金されてたような気がします。個人ユースで使うには少し高いとの感想を持ち、結局その後は積極的に利用しなくなりました。
 ちなみに過去のブログみたら、初めてS3の概念に触れた時のことがそのまま残っていました。後半、自分でも何を書いているか解らないけど。


Amazon S3 - Simple Storage Service - プログラマでありたい


 その後EC2が出て来たのですが、名前だけみてアマゾンのショップ関係のサービスなのかと思ってスルーしていました。たぶん使いだしたのは、2007年になってから。ルートアカウントのアクセスキーの生成日をみたら、2007年4月になっていたので少なくともその辺りでは使ってたっぽいです。ただ本格的に使い出すようになったのは、2007年末。どうやらSimpleDBに触発されて、再度使いはじめた模様です。自分は何をしようとしてたんだろう?そこからは、ちょくちょく使っていた模様です。

サービスごとの感想



 過去ログを見る限り、EBSが出たり固定IPが使えるようになったりで、狂喜してたみたいですね。今だと当たり前の機能だし、逆にないとどうやって使ってたんだろうと謎にもなります。ちょっと面白いので、当時の感想を引っ張りだしてみます。
aws カテゴリーの記事一覧 3ページ目 - プログラマでありたい

週末プログラマに朗報 Amazon Elastic Block Store(EBS)
 S3を使わずにデータを永続化できることが、画期的なことと捉えています。

エンタープライズ分野に本気で殴り込み Amazon EC2でOracle
 AWS上にOracleのライセンスを持ち込めるようになったことに、ひどく驚いていた模様。当時のクラウドは、許されざる者だったのか?

Amazon EC2をGUIで操作する公式管理ツール AWS Management Console
 GUIが使えるようになったのは、3年近く立ってからなんですね。
エンタープライズ分野でガチンコ勝負!!Amazon Virtual Private Cloud
 この辺りからビジネスで使うことを意識しだしてた模様

最大の失敗



 AWSの最初期から見続けてきた訳ですが。そんな中で失敗したなぁと思うことがあります。それは、今みたいに誰もがAWSを使うようになるとは全く予想しなかったことです。当初のAWSは、GUIのコンソールがないことからも解るように、ユーザビリティも最小限でした。機能的にも足りないことが多く、今でいうオンプレミスのインフラに比べるとナイナイ尽くしでした。クラウドというのは便利で凄いという認識はあったものの、単なるニッチなカテゴリーにとどまり続けると思っていました。先を見通す力が無かったと改めて思います。
 一方で、個人的には面白くエンジニア同士には勧め続けていました。社内にも布教し、2009年には社内ユースではそれなりに利用していました、また、2010年に発表した自社サービスのインフラに使ったりとしながら、なぜもっとビジネス展開を考えなかったんだろうなというのが反省です。
 ちなみに、この記事にあるように、2009年段階で後発のクラウドに対してAWSの圧倒的な優位性は認識してた模様です。(優位であるという論拠は、殆ど間違っていましたが。)


ITベンダー製のクラウドは、Amazon EC2に対抗出来るのか? - プログラマでありたい

感想



 振り返ってみると、どっぷりイノベーションのジレンマにハマっていたことに気が付きました。AWSのような破壊的イノベーションは、持続的イノベーションと同じ尺度で比較してもダメだということを身をもって体感しました。一方で、クラウドというカテゴリの誕生から、その成長の過程を見続けることにより多くのことを学んできています。見るだけではなく、プレイヤーとしても活動してきている訳ですし。最近、LambdaやCognitoなど、アーキテクチャを根本的に変えるサービスがでてきています。これこそが、次の破壊的イノベーションの最有力候補と考えています。これ使って色々企みたいところですね。
 前書きを考えようとしたら反省文になってしまいました。そっちの方は頭を切り替えて、考えます。どんな前書きが来るか、楽しみにしていてください。3月25日発売です!!

See Also:
AWSパターン別本の狙い。例えばAutoScalingを使えるように。「Amazon Web Services パターン別構築・運用ガイド」の裏話
『Amazon Web Services パターン別構築・運用ガイド』を書きました
『Rubyによるクローラー開発技法』を書きました
本を書く前に準備したこと、執筆中にしていたこと

AWSパターン別本の狙い。例えばAutoScalingを使えるように。「Amazon Web Services パターン別構築・運用ガイド」の裏話

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

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

 先日、『Amazon Web Services パターン別構築・運用ガイド』を書きましたというエントリーで、執筆のご案内をしました。せっかくの機会なので、もう少し踏み込んで目標などを解説していきたいと思います。ちなみにタイトルを「AWSパターン別本」と省略していますが、今勝手に考えました。元のタイトル長すぎで、覚えられません。

本書の目標



 今回書いた本の目標として、例えば「読んだ人がAutoScalingくらいを苦もなく使えるようになる」というのがあります。AWSを使いこなしている人にとっては、AutoScalingなんて当たり前と思うかもしれません。しかし、意外に敷居が高いものなのです。AutoScalingを実現するには、最低限、次の事項を理解していて設定できる必要があります。

  • MultiAZ,SingleAZにしろ、ある程度ネットワークを理解している
  • セキュリティグループの設定できる
  • 自分が作成したインスタンスからAMIを作成できる
  • CloudWatchの設定ができる。
  • 動的サイトの場合、アプリのセッションの維持の方法について方針を立てられる

 これだけでも結構たいへんです。実際、JAWSUGの初心者向けセッションに登壇した際に、何度かアンケートをとったことがあります。大体40人位の受講者で実施することが多いのですが、AutoScalingについて聞いたことがある人は、いつも9割くらいです。また使えるようになりたいと聞いてみると、7〜8割くらいの人が挙手します。それに対して実際に構築したことがある人はせいぜい2〜3人です。
 まずはこのギャップを埋めることができれば、結構役立てて貰えるのではと考えました。AWSは、ハンズオンなどで直に学べる機会や、マイスターシリーズやブラックベルトシリーズなど良質のコンテンツが提供されています。一方で、そういったものがあると知らない人も多いのも事実です。本というアプローチは、そういった人たちの何割かにリーチできるのではと思います。

本書のステップ例



 仮に目標をAutoScalingとしたら、この本では次のような要素で解説をしています。まず2章の「AWSを利用する」の部分で、アカウントの作り方からネットワークの作成とセキュリティグループの説明をしています。そしてEC2の使いかたとして、起動からAMIの作成まで取り扱っています。そしてELBの説明です。3章の「パターン別構築例」で、みんな大好きWordPressを例に、Web複数台+DB構成でシステムを構築しています。一旦基本のシステムが出来たあとに、AutoScalingに変更するといった塩梅です。順を追って説明しているので、じっくり読んで貰えればきっと出来るようになると思います。また、例えAWSのコンソールが多少変わったとしても、何のためにするのかということも併せて書いているので、そこの部分は役に立つはずです。

AutoScalingの先に



 次に、この本がAutoScaling使えない初心者向きかというと、そうでもないです。もう一歩先まで目指しているで、例えばAutoScalingで利用するインスタンスは、ElasticBeanstalkを使ったらどうなるのかや、それ以前に静的サイトであればS3 WebHostingで良いよねという話も載せています。
 また後半では、AutoScalingは良いけどアプリケーションのセッションはどう考えるのかとか、デプロイどうするのかとか、そもそもインスタンス起動時の初期化処理はどうなっているのかなどについても触れられています。あとは、AutoScaling時のログをどう考えるかなどですね。ここまで行くと、けっこう中上級者の人でも楽しんで頂けるのではないでしょうか。この辺りの方式については、ただ1つの正解はないと思っています。1つの考え方として、自分の考えるアーキテクチャと較べて貰えればと思います。

まとめ



 改めて見返してみると、いろいろなテーマを取り上げています。社内の教育やお客さんへの説明に使いたいと考えていたので、かなり網羅的になっています。その辺りどう反応して貰えるか、楽しみです。次は、SIerという立場である私が、この本を出したりJAWSUGで登壇していることについて書いてみたいと思います。


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

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


See Also:
『Amazon Web Services パターン別構築・運用ガイド』を書きました
『Rubyによるクローラー開発技法』を書きました
本を書く前に準備したこと、執筆中にしていたこと

『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)に対するユースケースを考える