tdtshのブログ

人に教えて頂いてなんとなく見始めたんですが、めちゃめちゃイイですね。

ネットワーク産業論 2011 by 夏野　剛

ネットワーク化とコンピューター技術の進化によって引き起こされたこの十年のIT革命は、経済・社会・政治・企業経営など社会のあらゆる面に大きな影響を与えている。しかし2000年代の十年はブロードバンドやケータイネットの黎明から発展段階で、この間に社会の基幹インフラとなった各種のネットワークがより大きな経済効果・社会効果を生み出すのはこれからの十年（2010年代）だと考えられる。本講では、ネットワークの特性がもたらす産業構造の変化、企業戦略に与える影響などを分析し、これからの十年に備え、その社会的インパクトを正しく理解することを第一の目標とする。対象となる産業も、ネットワークに直接かかわりのある通信産業やＩＴ産業に留めず、あらゆる産業、市場、社会体制、経済システムを対象に、どのような構造変化がもたらされているかを概説する。授業は講義だけでなく、ネットビジネスの最前線にいるゲストスピーカーの講演と、グループワークを織り交ぜ、実践的な知識を身につけた上でのその応用を目指す。

だそうです。

ウェブサービス界隈の人は必聴ですよコレは。
ちょっと長いけど、見終わったら2011年以前も遡ってみてみよう。

iTune U なんで、iPhone や iPad 等の iOS5以上なデバイスが必要ですが、学生さんとか、イマドキ1つは持ってるでしょ。

それにしても、無料でこんな慶応大学をはじめ素晴らしい講義が視聴できるなんて、なんて良い世の中なんだ。
Internetの登場以来、学習のためのコストはどんどん下がってきています。
私の子供たち世代はこういうのがあるんだから、わざわざ大学いかなくても良いんじゃないかな。

とりあえず東京大学は1つの授業をコマ切れにするのをやめることと、タイトルBGMと終了間際のブツッと言う音が爆音なのをなんとかして欲しい気持ちでいっぱいです。

先日ベタ褒めした「いますぐインス！ au のスマートフォン で iCloud のフォトストリームみたいなアプリ (au one Photo Air)」が、近々auスマートパス(390円/月)に入らないと使えなくなるようです。

月額390円でアプリやオンラインストレージ提供「auスマートパス」 – ケータイ Watch

代わりと言ってはなんですが、 Dropbox スマホの画像を自動でインポートする様すれば、個人的にはあまり困らないです。

ついでにこのやり方で5GBの追加枠をゲットすればいいと思います。

Dropboxベータテスト参加で追加5GBを獲得するための手っ取り早い方法 | ひとりぶろぐ

既にDropboxをお使いの方は、ここに書いてあるやつをダウンロードすればいいです。

ちょっとリンクがわかり難いので改めて書いておきますね。

Windows版

Mac版

 
Java版のbulkloaderが出ると信じて待つこと1年以上、for businessもスベッてしまい、いまだその気配もなく。

痺れを切らして、普段 GAE/Jな私が、Python版のbulkloaderを使ってみました。

普段GAE/Jなので、スタートガイド Python 開発環境 / Google codeを参考に、環境作りからはじめます。

 

Pythonをインストール

Download – Pythonから手繰り、私の場合はWindows (未だにXPデス)なので、Windows x86 MSI Installer なんをインストールします。最新は2.7.2の様です。
Macなら最初から入っていますし、Linuxも大概のディストリビューションで最初から入っています。

 

Google App Engine SDK for Python をインストール

GAE/JなヒトでもPython版SDKを既に入れている方もいるかもしれませんが、入れてないヒトは入れましょう。

Google App Engine SDK のダウンロードから、Google App Engine SDK for Pythonをインストールします。最新は1.5.2でした。

とりあえずCドライブ直下に置きました。
インストールディレクトリは c:\appengine-python-sdk-1.5.2 となりました。
これを環境変数PATHに追加しときます。

 

GAE/J側の準備

既存プロジェクトの web.xmlを編集し、GAE/J側のRemoteApiServletを有効化？します。

	<servlet>
		<servlet-name>remoteapi</servlet-name>
		<servlet-class>com.google.apphosting.utils.remoteapi.RemoteApiServlet</servlet-class>
	</servlet>
	<servlet-mapping>
		<servlet-name>remoteapi</servlet-name>
		<url-pattern>/remote_api</url-pattern>
	</servlet-mapping>

勿論この後デプロイします。

 

設定ファイル (yaml) を作成

cmd.exe を起動し、appcfg.py で create_bulkloader_config を実行します。

cd c:\appengine-python-sdk-1.5.2
appcfg.py create_bulkloader_config --url=http://{appId}.appspot.com/remote_api --application={appId} --filename=config.yml

High Replicationの場合は、–application の引数のアタマに s~ をつけないといけないみたいです。
こんな風に。

cd c:\appengine-python-sdk-1.5.2
appcfg.py create_bulkloader_config --url=http://{appId}.appspot.com/remote_api --application=s~{appId} --filename=config.yml

自動生成されたconfig.yml には、そのとき appengine側に存在する kind のスキーマを反映したものになっているようです。

アップロード/ダウンロードするkindが限定されている場合などは、このymlファイルを編集して対象kindだけのymlファイルを作っても良い。

自動生成されたymlファイルは、TODO: の記述がいくつかあり、ココを適宜修正する必要があります。
最低でもconnector (と connector_options )を編集します。

  connector: # TODO: Choose a connector here: csv, simplexml, etc...
  connector_options:
    # TODO: Add connector options here--these are specific to each connector.
↓
  connector: csv
  connector_options:
    encoding: utf-8

 

CSVアップロード

ダウンロードするには、こんな感じ。

appcfg.py download_data --filename=test2.csv --config_file=test.yml --url=http://{appId}.appspot.com/remote_api --application=s~{appId} --kind={ClassNameOfKind} -v

アップロードはこんな感じ。

appcfg.py upload_data --filename=test.csv --config_file=test.yml --url=http://{appId}.appspot.com/remote_api --application=s~{appId} --kind={ClassNameOfKind} -v

参考にさせて頂いた先人の知恵

pomu0325: [GAE] bulkloaderをGAE/Jで使う

Javaプログラマの為のGAE/py bulkloader – GAE/py環境設定 – - 高卒文系プログラマの日常 by zetta1985

きのふよりけふ、けふよりあした　 未分類

CSVファイルのデータをアップロードする方法 – 気楽に開発メモ

Using the bulkloader with Java App Engine – Ikai Lan says

前から少し気になってた さくら Internet のVPSを使う機会がありました。いやいや、イイですね！

レンタルサーバでいいじゃん的な案件でも、独自SSL欲しいとかイロイロわがまま言い出すと数千円/月~高いので1万円前後します。それでいて、自由度が少ない。JavaServlet 動かすなんて無理。

VPSならそりゃVM(仮想サーバ)のrootが貰えるんで、ミドルウェア構築するのが苦じゃない場合はそっちの方がメリット大きいです。でも、格安VPSってパフォーマンス悪そうですね。

そんな訳で全く期待値が低い状態で、さくらのVPSを使ってみたんですが、コレがまた結構サクサクじゃないですか。手元にあるHPのML115と比較しても、Apacheとかのコンパイルが早い。下手したら半分位かも。
CentOSなんですけどどうやら64bit版らしいです。64bit版はじめてだったんですけど、多少./configure のオプションで勝手が違いますが、それ以外は特に不都合ないですね。

時間帯とかイロイロな変数が影響するんでしょうが、 サーバのスペックに加えレイテンシも含めて考慮すると素の北米の Amazon Web Services の Smallインスタンスよりもコッチの方が快適です。それでいて 980円/月 なんだから、こりゃいいな、と。

いや、嬉しい誤算です。

ついでに ｊｐドメインもさくらで取ったんですが、コレは1日強待たされましたが、DNSモドキもついて4000円強なんで、個人的にお気に入りの格安レジストラVALUE-DOMAINを使う理由が1つ減りました。

試用期間2週間は無料で使えるんで、是非お試しを。
※さくらの回し者じゃないですよ。

IaaSプロバイダはどうやってマーケットを広げるのか？ PaaSレイヤを提供するのは簡単だが、そうすると顧客にはロックインされるという懸念が持ち上がる。顧客が管理の主導権を持てるというIaaSの利点でを維持したまま、どうやってPaaSの利点である、熟練を要する運用業務を顧客から不要にする、ということを提供できるだろうか

その答えは運用を容易にするツールの提供だ。それはIaaS上に用意された、優れた（ベストプラクティスな）インフラで、可用性とスケールを実現するものだ。

これがまさにAWS Elastic BeanstalkがTomcatを用いて行ったことである。

IaaSとPaaSの違いはなくなろうとしている － Publickey

個人的にはベンダロックインよりも、運用がどれだけ容易になるかが最大の関心事だったりする。
運用にもスケールするかどうかが含まれていると考えています。

昨今のWEBサービス開発は、php等のスクリプト言語で作るのがあたりまえです。
初期の開発者の単価が抑えられ、ホスティングサービス等を利用しやすいから。

で、幸運にもWEBサービスが流行ったら、フロントエンドのWEBアプリケーションも色々と性能改善をしつつ機能追加とかするのも大事ですけれど、ある程度の規模を超えるとストレージのレイヤ（データベース側）でがんばってスケールさせる必要が出てくる訳で、ミドルウェア含むインフラ層にもエンジニアを惜しみなく投入して、あの手この手で分散化する必要が出てきます。

最近は知りませんが少なくとも私の知る限り、php は Apache等のhttpデーモン のプロセスまたはスレッドにくっついて動く訳でして、永続的接続とかいう仕組みは有っても、アプリケーション全体でDBコネクションの数を制御したり、プーリングしたり、使いまわしたり、データベースアクセス専門のオブジェクト(DAO)をこさえて使いまわす、なんて事が簡単には出来ない訳でして、そこはもう Java Servlet の方が1階層タンデムな分そこのへんの作りこみが楽だから、ある程度の規模までならデータベースアクセスの観点からパフォーマンス面で有利だと思う訳でして、私がWEBアプリケーションとしてはマイナーな Java を選ぶ理由の1つです。

TCP/IPのコネクションを張るのはそこそこリソースを消費する訳だから、php でApacheのプロセス（スレッド）上減数に合せてコネクションを貼りっぱなし、なんて構成を最初はとったりする訳ですが、RDBMSサーバ側のリソースも結構ふんだんに用意する必要がありますし、規模が大きくなってくると、最近は安くなったとはいえスケールアップさせるのはソコソコ金がかかるんで、水平に垂直に分割したりレプリケートさせたりキャッシュしたりインフラ層でイロイロやらないといけないんで、安定させて性能を出すにはそれなりのコツというか、DBAなんていう職業が成立してしまう位イロイロな匠の技がある訳ですし、24時間365日運用するには、やはり訓練もドキュメンテーションもそれなりに必要になってきます。

で、最初の「運用がどれだけ容易になるか」の話ですが、こういう「インフラ系エンジニア」の下働きは、それなりに優秀な人材を集めなければいけないしコストがかかります。WEBサービスもマネタイズできないと単なるボランティアですからやはり収益性は大事な訳です。

誤解を恐れずに言うならば、インフラ系エンジニアは「システムの能力を最大限に引き出し（必要に応じて向上させて）たり、セキュリティ含むITをとりまくあらゆるリスクを軽減する為にイロイロとがんばる」訳ですが、それで収入が増えるとか言う事は無い、と考えられる事が多いわけです。特に経営層に。

これらはだんだんとコモディティ化してきているから、もし外注できるなら、どうせ金かけるなら優秀なソフトウェアエンジニアを中に雇いたい訳です。サービスをより良くするスピードこそ、競争力であり、収入を増やす為に必要だからです。

こういう事を書くと世の中のインフラ系のエンジニアの方を敵に回しそうなんで一応書いておきますが、価値を生むとか生まんとか以前に情報システムは運用してナンボ、作るだけじゃダメな訳で、運用管理も誰でも簡単に出来る訳じゃないです。Salesforceの様に、運用こそ差別化の最大要因だと言い切ってしまいたい所です。

さらにさまざまな問題を回避する事で、問題が発生した場合に損失しうる企業価値を損なわずにすむという面もありますんで、一概に要らないと言っている訳では無くて、AmazonやGoogleとかが、規模の原理を活かして、自社の優秀なエンジニアと運用のベストプラクティスを、IaaSやPaaSで提供しはじめている訳ですから、少なくともWEBサービスにおいては、ストレージ層も含めて「スケールする」インフラがセットで提供されはじめた今、「事業」として考えた場合、「外注」されやすい分野である事は間違いないでしょう。

要るとか要らないとか言う以前に、土俵というか、世の中のルールというかが変わって来たぞ、と。

そういう観点で、Google App Engine と AWS Elastic Beanstalk を比べると、App Engineの方が楽そうなんだよなぁ。
でも、既存システムの移行の難易度で言うと、格段にBeanstalkの方が楽そうだなぁ。
App Engineの方がスケールしそうだしなぁ。でもAWSの方が自由度高いしなぁ。

と、これからは、クラウドをコーディネートする力が求められそうですね。
纏まりなくてすいません。