「私のサービスは毎月1億PVくらいになりそうなんですけど、どのインスタンスがいいですか?」
こんな質問をときたま受ける。マジレスすると、
などなどの理由で、ずばっと答えられないので、相手をガッカリさせることがある。
責任のある答えは「試しに作って測定してください。測定して、足りなければ増やせばいいので」というのが私の典型的な回答になる。
もちろん、超ざっくりでいいなら、こんな例えをしてみる。
こんな適当なことを言われたらみなさん怒ると思います。まったくアプリの苦労をわかってないといわれ、あらゆる言葉で罵倒されることでしょう。というわけで測るしかないのです。
世の中のWebページやWebサービスの指針としてPage Viewが重視されるようになったのはいつからだろう。
私のなかの超適当な印象だと(年数は適当。調べたいけどもうわからない)
こう考えると、hitとかいっていた時代は技術者が牽引してた時代だったなあと。そんな時代じゃないので最初のような質問がでてくるのは当然かしれない。
ついにAWSが南半球へ。BRICSへ。
ちょっと使ってみた感覚だと、サンパウロリージョンからKDDI柏までは300msecを微妙に切るくらいのpingで、あまりジッタがない感じ。hopもアイルランドに比べると少ないようだ。
日本むけのサービスを南米リージョンで展開することはないだろうけれども、南米という正直いって質を担保することがむずかしいという印象がある場所で、他地域と同じクラウドサービスが使えることは少くない企業にとってプラスになるでしょう。
日本企業でも南米向けサービスで使うところがでてこないかしら。。
私はいろんなプレゼンで、AWSで一番好きなサービスはSpotInstanceと公言している。
これはどんな理由かといえば、まだHP研究所の研究者だったころに「EC2のcloneがほしい」と自分が思ってXenからユーカリに移行したころにSpotInstanceみたいなのをおもいついて論文を用意してるときに、AWSから出たから。
社内にあるデスクトップはコアが余っているので、そこに提供側が値段をつけて、みあったコアに値段をつけて貸しだす。たんにコンピュータに値段をつけさせるだけではなく、人の力をかりるともっと効率的な社会になる! 的なものだった。
しかし、そのビジョンを語るよりは実際に製品がでたときの衝撃はすごかった。
とはいえ、もともとネットワーク出自の私としては日本でDirectConnectがはじまったらそっちにするかもしれない。また、インフラ屋としてはAPI全てといいたいところ。
* 17:26 simpleDBでは足りませぬか。RT @ixixi: AmazonRDS的なAmazonDDS(Document-oriented Database Service)欲しい。MongoDBとかCouchDBで。(以下略 #jawsugAWSというのはよくもわるくも自由度が高い。基本サービスのひとつであるEC2は仮想サーバの内側に何をインストールして、どんなシステムを組むのも利用者のまったく自由。自分が相対するのは、現場を持つインフラエンジニアから、マネージャやCTOまで幅広い。みなそれぞれ尊敬できる人も多い。
* 17:39 @ixixi
MongoDBについてはMongoDBいれて使えば。。と思ってしまうのでありました。MongoDBを使いたいのに、DBをさわりたくない!
というのは今のところあまりなさそうに思えますが。。ほしいところを教えてください! in reply to ixixi
なんだかんだいってWindows XPとIE6は消えない気がするので、それに対する有効な方法を考えるのがエンジニアというものだろう。
とはいえ消えいくデバイスサポート、セキュリティパッチなど問題は山づみなのでそのためにWindowsXPをEC2上で仮想化して使いたいときだけ使いたい、という話はよくいただく。技術的には何の問題もなくあっさり行ってしまうのもわかる。
しかし、Windowsには、ライセンスという壁がある。現在のところ、Microsoftのデスクトップ製品はパブリッククラウドでは、もちろんEC2もそうだが、動かしてはいけない。ライセンスのことを決めるのは、ライセンスを持っているMicrosoftだけである以上、しかたがない。
実際に話を聞くと、
ということが多い。あれ、もしかしてXPじゃなくていいの? と聞くと、大抵はXPはどうでもいいものらしい。
となると答は簡単だ。Windows Server 2003を使え! 外からアクセスできるもんなら Adobe Browser labでいいじゃん。
さて、これでもうどうでもいいや、という気もするのだが
http://www.publickey1.jp/blog/11/kindle_fireamazon_silk.html からの引用。
「Kindle Fire」には、クラウドとデバイスのあいだで分散処理を行う全く新しいWebブラウザ「Amazon Silk」が搭載されています。
Amazon Silkはローカルのデバイス上で動作するWebブラウザの背後に、クラウドであるAmazon EC2で動作するサービスがつねに存在し、両者が連動して高速なWebブラウジングを実現する
とある。みんな実はこういうの欲しいんだよね。。
本日は#dnstudyがあった。
http://togetter.com/li/206956 あたりを見ると雰囲気がよくわかる。
自分もAmazon Route53の紹介プレゼンをした。
Windows用S3クライアントの鉄板といえばCloudBerryなのだが、これをプロフェッショナル版にした。
自分にとって重要なのは同期機能。同期機能は、Cyberduckでも対応していて、それはそれでいいかんじなのだが、やはり使ってみるとCloudBerryはいいかんじ。
http://www.cloudberrylab.com/amazon-s3-explorer-pro-cloudfront-IAM.aspx
CloudBerry Explorer PRO offers some advanced features over Freeware version. It makes managing files Amazon S3 in evenEASIER, more secure and cost efficient. By providing a user interface to Amazon S3 accounts, files, and buckets, CloudBerry lets you manage your files on cloud just as you would on your own local computer.
 | ||
| Features | FREEWARE | PRO |
| Amazon S3 | | |
| Amazon CloudFront | | |
| PowerShell | | |
| Compression | - | |
| Encryption | - | |
| Search | - | |
| Multithreading | - | |
| FTP Support(*) | - | |
| Sync | - | |
| Multipart Upload | - | |
| Large Objects | upto 5 GB | upto 5 TB |
| Support | forum only | via email, 48 hours response |
| Expiration | doesn't expire | doesn't expire |
| Price | FREE | $ 39,99 |
どうにかこうにか有明でのイベント終了。
当然行くべき客先のほうが重要なので、会場いったり客先いったり、さらに採用面接やったりとんでもない面倒臭さだった。
今回のイベントでも、サーバーワークスの大石さんの切腹プレゼン(じゃっかん違う資料すが)は冴えていた。
それにひきかえ、ミニブースでやろうとしていた自分のプレゼンの残念さはひどい。それよりもデモのほうがいいのはあきらかだった。
国際展示場でのイベント。
今回は外をあるく人をとめるためにプレゼンを用意していた。しかしやってみると、ぜんぜん響かず、響くのはデモだった。というわけで、デモ発表に切りかえることになった。
はじめてAWSのコンソール画面を見せてサーバをほいほいと作っていくのはよく響くことはわかっているのだが、今回も要望されたのは、コンソールの日本語化だった。そういう時は必ずAPIをたたくサードパーティツールがあることは説明する。
まったくどうでもいい話だが、会場で買った唐揚げ弁当がどうしょうもないまずさであった。とはいえ食べれるけどね。。
どんな事であっても自分に関係するものの限界を知りたがる人はいる。それこそ素材の強度からビルの強度にしろ、鶏舎あたりの鶏の生産効率まで。
この仕事をしていると、典型的なのは、事故率、故障率、拡張余地、物理的安全策、などなど多岐にわたる。それらをベンダに聞きたくなるのはわかるのだけど、すくなくともサービス提供者であるAWSにはやって欲しい事を示すほうがきちんとしたものを引きだせると思う。
ベンチマーク大好きな人は、「そうはいっても測定しないと」と、すぐおっしゃられます。しかしながら、その測定条件はいくらでも変わっていくことを理解した上での目安にしてほしい。
AWSのようなクラウドベンダとしては、やって欲しい事とその計画を聞いて、事業計画をして、投資をするのだから。
あちこち会社のロゴを隠しているところが散見されるいつものNHK。
自分にとっては、わざわざ録画を保存しておくほどのものではなかった。あるとしたら誰かに説明するよりも、これを見せたほうが楽かもしれないなあという程度。
世の中にはいろんな活動をしている人がいるようです。
AWSにもGAEにも当然それぞれのいいところがあるので、これらをうまくつないだソリューションを作れるとすばらしい展開が考えられます。AWSは全てがAPIで制御できることがキモなので、GAEからそれを呼べばいいと考えるのは当然の成行。
https://github.com/apetresc/aws-sdk-for-java-on-gae/network を見る限り、活発にメンテナンスもされているよう。
The official AWS SDK for Java doesn't work on Google App Engine, because the SDK uses the Apache HttpClient whose socket creation antics are not permitted inside the GAE sandbox. There are a number of ways of working around this problem, but this particular fork takes the brute force approach of ripping out Apache HttpClient, and hardwiring the GAE-specific UrlFetchService in its place.
http://marchjudd.blogspot.com/2011/08/810windows-update.html に詳しいのだが、インストール時にコンパイルを伴うというMSのupdateが今月行われる。
案の定、t1.microでは辛いらしい(当然だ..)
AWSの場合だと、この時だけでも上のインスタンスにあげてもらうことはできるが、家のAtomは死にそうだった。
ようするに、/proc/sys/dev/raid/speed_limit_min でRAID構成の速度をおさえているのに文句をいわれても困る、ということ。
dev.raid.speed_limit_min = 50000
dev.raid.speed_limit_max = 200000
というあたりでさくっと指定してしまうべき。
性能をひきだすちょっとしたtipsとしては、使う前に初期化をしてしまうことがおすすめである。
初期化といってもむずかしいことはなくて、単に/dev/zeroとかで埋めてしまうだけである。
dd if=/dev/zero of=/dev/sdb bs=1M
rails consoleで create_domainなのだが、斬新すぎると思いました。
「ドイツでは、ある企業が情報漏えいをすると、その企業の責任者は禁固刑に処せられるケースがあるが、それでもAmazonを採用するドイツ企業があることを思い出してほしい」という話がでたのでちょっと書いておく。
条約における民事上の責任は civil penalty のようなものを意味しており、わが国におけるhttp://www.meti.go.jp/policy/netsecurity/downloadfiles/Cybercriminallawreport.pdf にある解説より。このpdfはとてもわかりやすいので超おすすめ。
損害賠償を第 13 条の制裁(sanction)の一種であると解釈することには疑問があるとの意見 もある。刑事責任、民事責任、または行政的制裁とすることが締約国の法原則に従い選択可 能となっているのは、ドイツのように法人の刑事責任を認めていない国の存在を考慮してい るからであるとも考えられる。法人の刑事責任を肯定している日本においては,法人の責任 は刑事責任でなければならないとすれば、大きな改正が必要となるとの指摘があった。
 "amazon web services... | |
 |
http://donrails.araki.net/archives/id/7360
に書いたDebian6(squeeze)の東京リージョン用のAMIだが、32bitのほうを修正した。(古いAMIも、3/7の朝7:40頃に削除した)
これからはami-9e1ab19fを使ってください。あわせて、元記事と http://wiki.debian.org/Cloud/AmazonEC2Image DebianのWiki も修正しました。
修正点:が、ちょっと時間がなくなったのでインスタンスストアはまだです。
なんだか今日から世界がかわるかもしれないなーと思ったのは、AWSの問い合わせフォームにFワードが入力されていたということであった。どうやらやっと認知されたようだという実感がしてきました。
とにかく朝からチラシをくばりまくり、質問にこたえまくり、2時間ほどお客様訪問し、ふたたび質問にこたえまくりで、足がパンパン，喉ガラガラになって18時に撤収。
その後さらに21時ころまでレセプションパーティーだった。
今日明日と日経CloudDaysTokyoというイベント．東京ミッドタウンでAWSのパートナーさんが主役のイベントでメタな質問の引きうけ係として一日立ちんぼ。
そして夜。ついに待っていた日がきた!
入社前からこの日を待ち、入社してからは無事この日を迎えられるように祈っていた日が今日。
自分が個人でできることとして、AWS東京リージョンにDebian Squeeze登録しました。debianで検索しても2つしかでてこない、こんな日はめったにないのでキャプっておいた。いずれこれが上から下まで埋まる日がくるのだろう。
そして、Debian Projectとしてhttp://wiki.debian.org/Cloud/AmazonEC2Image
というのを案内することにした。EC2用のimageの情報をまとめています。
小島さんにB型インフル感染の恐れあり、ということで昨日は家から仕事をされていた。どうやらそれは疑惑で終わったようで今日はいつもの通り出社されていた。
今日から入社の2人もいるのでいることが重要な日にいてよかった。
大韓航空のA380は成田インチョンからのスタートらしい。長距離線にもってくると思ってたのに意外。747SRみたいに足まわり強化とかあるのかどうか知りたいところ。また、あの翼のしなり方を見ると、離着陸の回数が増えると翼も相当いたむんじゃないの。。という気がする。
http://t.co/s74MfQl AWS CloudFormation: 複雑なシステムもクラウドレシピからワンクリックで作成可能ってなわけで、かねてから期待していたAWSで複数のインスタンスにわたる設定を一発でやってしまうサービスが登場した。
自分としてはchefやpuppet使いの方に特におすすめである。が、それに慣れている人にはいらないものでもあるんだよな。
AWSのアカウントでは使わないサービスを設定できます。
場合などに活用ください。
ちょっと面倒ですが、ひとつずつ見ていくことにします。
http://aws.amazon.com/jp/ にアクセスします。
アクセスしたら、アカウントと書いてあるバーのボタンをクリックします。
すると、AJAX的に、アカウントに関するいくつかの詳細選択肢が出現します。
ここでは、左上の「アカウントアクティビティ」をクリックします。
すると、メールアドレスとパスワードの入力がうながされます。
すると、現在使用可能なサービスのいちらんが表示されます。
ここでは、Import/Exportサービスの利用を停止することにします。
すると、「サービスの表示/編集」という画面が表示されます。
この画面で一番下までスクロールすると、「サービスをキャンセル」という文字があるのでクリックします。
すると、確認画面になります。
問題なければ、「Cancel this Service」というボタンを押します。
次の画面では、確認のためのemailが送られたというおしらせが表示され、現時点で有効なサービスが表示されます。
これをくり返すことで、不要なサービスをあやまって使わないように設定することができます。
アカウント毎にサービスを使いわけるためには、IAM以前にはこの方法が有力でした。
朝9時に渋谷というのは、どうにも時間がかかりますね。。電車はのろのろだし、ギュウギュウだし。転職1日目なので9時から研修。
研修が午後まであって、どうにもならないので、夜あたりにtwitterに書こうかと思っていたら、@KenTamagawaによって
本日から、AWSの日本チームのSolution Architect 第1号として @ar1 さんがAWSチームに入りました！荒木さん、宜しくお願い致します。皆さま今後ともどうぞお見知りおきを！
という宣言を出されてしまい、自分で考えるまでもない状況になりました。
そんなわけで、皆様、御要望ご利用お待ちしてます!
