香港のラマ島(南丫島, Lamma Island)でハイキングしました


一週間香港で英語を勉強してたのですが、土曜日は1日フリーだったので近くの離島に行ってみることにしました。
(マカオは以前行ったことあるし、ケチくさい人間なのでギャンブルはどうも性に合わなくて…)
 
ホテルからブラブラ歩きながらセントラル(中環)を通り抜けて港まで。

 
30分くらいで行けて結構ポピュラーなところらしくてそこそこ船混んでました。

 
船の中から。行ってきまーす的な。

 
船の中の様子。

 
前方にはモニターにDockerみたいなロゴが表示されてますが、嘔吐袋が準備されております。笑

 
島に到着すると地図があって。もう一個の港までのハイキング経路とか載ってる。
ローカルの友達がちょうどイイんじゃん?って言ってたのでハイキングしてみることに。

 
売ります買います系の掲示板っぽいのがあったり。

 
ワンコとか。

 
港のそばはお土産物屋さんとか、レストランとかが沢山。

 
漁業の島なのでやっぱりシーフードなところが多かったです。

 
ハイキングのはじまり。Welcome to the Jungle的な。最初5分で暑すぎて後悔がはじまる。笑
このハイキングは夏にするものじゃない。。思わず急な雨用に持ってきた折り畳み傘を日傘にしました。。

 
割りと有名らしいビーチは奥の方の景観がなんかなー的なところはあるけど、ローカルっぽい人が楽しんでました。あんまり人が多すぎないのも良い感じ。

 
一応海パン持ってきたけど、暑すぎるので入るのはやめておきました。。

 
道はイイ感じに舗装されてるので、ビーサンとかでも大丈夫だと思います。

 
但し、坂は結構多いです。

 
確かに景色はとても良い。

 
これで暑くなければ気持ちイイんだけど。。

 
何やら景色が良さそうなとこがある、と。回り道して行ってみたけど、そこまででもなかったかな。。

 
徐々にもう一つの港の方へ。

 
何やら印象的なペイントが施された建物や、

 
村役場みたいなところとか。

 
神風洞(Kamikaze Grottos)。人間魚雷が置いてあったらしい。。

 
自然豊かでナイスなところです。

 
天后宮。漁業とかの神様らしい。

 
中にはなんかスゲーのいました。

 
そんなこんなで汗びっしょりになった最初から捨てるつもりで持ってきたシャツを捨てて
Tシャツに着替えて港へ。

 
船乗って香港島に帰ります。

 
帰りの船からの景色もナイスでした。

 
ただいま〜的な。

 
そんなこんなでセントラルの翠華餐廳でメシ食ったり、

 
ティーカップなカワイイ紅茶飲んだり。

 
Causeway Bayウロウロしたり。とにかく暑いので水分補給重要なのですが、この野菜ジュースは他と比べて値段も日本とあんま変わらなくてよく飲みました。

 
にしても、いたるところで日本のラーメン屋さんみかけました。

 
晩御飯は期間限定のしゃぶしゃぶ鍋を吉野家で。笑

 
具だくさん。

 
美味しかったけど、食べるのにコツがいるっていうか。。
日本のってある程度調理された状態で出てくるけど、これはフツウに鍋。

 
チョロっとSOHOの立ち飲みやで飲んだりしましたが、そんなこんなで次の日の早朝の飛行機で日本帰りました。
帰りの飛行機の中でみた”おみおくりの作法”は面白かったなぁ〜

 
ってか、前回香港にきた時は作らなかったけど、今回はオクトパスカードを作ったので、
セブンイレブンでもこれで買い物できるし、バスとかお釣りの事を考えなくて乗れるのでナイスです。

 

るるぶ香港・マカオ'15 (るるぶ情報版海外)
ジェイティビィパブリッシング (2014-06-25)
売り上げランキング: 50,454

香港のQ Languageという学校で1週間英語勉強してきました


一昨年はセブ島で、昨年はクアラルンプールで、1週間英語勉強しましたが、
今年は香港のQ Languageという学校で学ぶ事にしました。
 
理由としては、7月で飛行機のマイルの期限で、保持マイル的にはアジア圏しか行けるところがなかったのですが、
元々イギリス領だったところだし、、くらいな感じで、軽い気持ちで申し込みました。笑
 
■ 香港に行く前にやったこと
 
1. 学校に連絡して手続き
 
Q Languageのホームページのフォームからでx月x日から一週間勉強したいんだけど的なのを送ったら、
1Weekで15hoursのレッスンでHKD2,190で、24hoursのレッスンだとHKD3,510だよ的な返事がきました。
ネット上にもこの情報はあって↓に載ってたりしました。
http://www.languagecourse.net/pdf/q_language_hong_kong_prices_0_en_4698.pdf
VISAは要らないし、泊まるところも自分で手配するので大丈夫です的なメールのやりとりをした後に、
Paypalで入金しました。¥56,295 JPY。円安なご時世ですやねぇ。
で、領収書なかなか送ってくれなかったり、授業の前にpre assignmentがあるからって言われたっきり、
それがいつなのか催促してもなかなか返事がこなかったり、、
↓のブログがバズったりしてますが、外資系で働いてる自分的にも日常茶飯事のことなのでそんなもんかくらいな。笑
メールに返信をしないアメリカ人のメンタリティ | ktdiskのブログ
 
2. ホテルの予約
 
Expediaで良さそうなとこ探してたら iClub Hotel Sheung Wan ってところが新しくて良さそうで。
学校にも歩いて10分かからないくらいだから、ここにしようってことで。
7泊して67,080円。今回は日曜日に到着して、次の日曜日に出発だったので(土曜日に観光したかったので)
7泊にしたけど、ホテル的には週末は割高で、平日は7,818円で、週末が10,946円なので、
土曜日に帰っちゃう感じにすれば、もうちょっと割安な感じでイケたかな、とは思います。
が、マイルで予約できる航空券って土曜の夜出発とかってそんなにフレキシブルには選べなかったりしますやね。
 
3. 香港の友達に連絡
 
香港ローカルなヤツで同じ会社だったけどもうやめちゃった元同僚と、久しぶりに会いたいなって事で。
色んな話できてとても良かったです。なんかこういうのあると旅のテンション上がりますね。
 
 
■ 香港に向けて出発〜ホテルにチェッキン
 

 
ANAで行ったのですが、成田空港のなかり奥のゲートから飛行機乗りました。
機中では、テラスハウス(普通にこういうの好きですw)と深夜食堂(マスター憧れちゃうわぁ〜)みました。
 
空港ついたらSIMカード!
ゲート出てすぐのところでサクっと買えました。SIMフリーのNexus7に入れて使います。

 
4Gの8日間のSIMカードが118香港ドル。フツウにクレジットカードで買えるのもナイスですね。日本円で1955円の決済でした。

 
空港までの移動はAirport Expressっていうヤツで100香港ドル。30分かからずに市街に出れます。
 
ホテルはモダンな感じで、朝食も無料で食べれるし、ナイスなところでした。

 
朝食はこんな感じ。
パンとクロワッサンとオレンジジュースと果物とヨーグルト(早めな時間に行かないとなくなるw)

 
 
■ Q Language School
 
・Day1
 
レッスンは10時からで、その前にAssignmentがあるから9時15分に来てねってメールがきてたので、9時ちょっと過ぎくらいにホームページに載ってた建物の14階にいったら、まだ空いてなくて。
エレベーターで下に降りようとしたら、金髪の女性が乗ってきて、生徒だったら10階に行けば誰かいるよ的なことを教えてくれて、10階にいったらエラいっぽい人が個室で働いてて。
声かけたら、おー、そうかそうか、みたいな感じで、教室に通されてTOEICみたいな穴埋め試験を解かされる。確か50問くらいで、正解数に合わせてクラスが割り振られるみたいな感じ。
上から2つめのランクです的な事を言われた後、一週間の時間割を渡されて、同じタイミングで入学なクラスメイトがいて、彼らと一緒に初回授業を待つ、と。
 
これが1週間の時間割。1つの授業は3時間(間に休憩挟む)で、午前は10時〜1時過ぎ。午後は2時から5時過ぎって感じになってます。午前中は全部Level4Aってヤツで上から2つめのクラスで、午後は月・火・木とLevel3っていうレベル。この合計8コマ。
 
んで、出来上がった1週間のスケジュールが↓こんな感じ。

 
授業がはじまる頃になると、生徒が集まりだす。6人で本当にバラッバラな感じ。
ウクライナの主婦の人とか、ローカルの人とか、シベリアからきた女の子ととか、イタリアからきた18歳のイケメンとか。
 
先生のByronはヤケに男前で、学校のYoutubeのビデオに出てたりもしてました。
週末何したの?的な話(英会話学校の月曜日って必ずそうなる)で、キャンプしてた、とか。腕とか太いし、ワイルドや。
カリフォルニア生まれのユタ育ちって事で、発音も馴染みある感じの。

 
授業はどういう時がlittleで、どういう時がa fewで、とかそういうヤツ。例文かかされて先生にチェックしてもらうとか、
皆んなでディスカッションしたりとか、あっという間に3時間。
ローカルの人が香港の選挙について凄いアツくなってて。中国本土が選んだ3人にしか投票できなくなるんだとかで。
実際にそこに住んでる人から生の声が聞けたりするの、凄い面白い。
 
午後は、Terrenceっていうチャイニーズアメリカンな先生。
サンフランシスコに住んでたって事で、発音とかもこれまたよく聴く感じの。
ZooやAquariumは今後どうなってくか?的なディスカッションしたり。
 
夜はせっかく香港だからって事で、100万ドルの夜景みてきました。とてもキレイでしたが野郎1人で行くにはちょっと。笑

 
もの凄く混んでて、特に帰りは1時間くらいトラム待ったりしたので、ガッツリ夜遅くとかに行くのが良いのかもしれませんね。

 
 
・Day2
 
午前中のBarry先生はイギリスっぽい発音で、そうそうこういうのに慣れたかったのよね、と。
授業の内容はpick up, pick out, pick a fight,,,とにかく例文を使って発表しまくる。
いやー、勉強になった。
 
午後のGrant先生はオーストラリア人。Love&Relationshipについて。先生のオリジナル教材。
この日の午後の授業は6人中4人がロシアとかモルドバとかウクライナとか、しかも皆さんそれはノリが良く、とても楽しい授業でした。

 
夜はCauseway BayにDouban(http://www.douban.com/)っていう中国のSNSのUI/UXの話を聞きに行こうと思って
↓に申し込んでいて、
Working in UX in China – experience sharing developing UX for 100 million users at Douban
↓実際にそこ行ってみたら、明日だよ、と。笑

 
メシ食ったり街をブラブラしてホテルに帰りました。
 
 
・Day3
 
Byron先生の授業。ガッツリ勉強した後にGo Fishってカードゲームやったりしました。

 
午後は授業なかったので、Tsim Sha Tsuiに電車でいって有名っぽい店で炊き込みご飯的なの食べた後に、

 
博物館に行ってきました。(イタリア人のイケメンが昨日行ったら良かったよって言ってたので)
アヘン戦争とか、観光にきてた中国の人も、黒歴史的になんだかなぁ的な感じで展示物をみてました。

 
日本統治時代はいかに悲惨だったか的な展示物をアジアで見るたびに、なんだかなぁと思います。

 
夜もTsim Sha Tsuiで会社絡みの友達とDalin Pochaって韓国料理屋さんであれやこれや話し込みながら飲んだり食ったりして。バーが密集してるエリアとかも案内してもらったり。

 
 
・Day4
 
午前のBarry先生の授業は不定詞とか動名詞とか。あとはmake our, make over, make xxx的なヤツをガッツリ。
↓は前回の授業の復習の様子

 
午後のGrant先生の授業は、新聞の見出しとかってイロイロ省略したりするけど、そのやり方とかそういうの。実は高校生の頃に1年間交換留学で日本に住んでた事あるらしくて、日本に相当詳しかったりも。
 
夜は雑誌とかでも有名な九記牛腩で牛スジ煮込みカレー麺的なヤツ。美味かった!けど、ちょっと胃もたれするかもw

 
常に店の外に人が並んでる感じですが、回転早いのでサクっと少人数でいく分には問題ないかな、と。

 
そっからSOHOの辺りをブラブラしつつ、

 
せっかくなのでセントラルから山の方にズドーンって通ってる、エスカレーターの一番上まで行ってみることにしました。エスカレーターの途中でスーパーがあったりして、アサイー的な飲み物かったり。

 
上まで行ったら、なんにもなかったので、フツウに徒歩で下りました。。(エスカレーターは上りしかない)

 
途中途中でシャレオツなとこあったけど。

 
そのまま港の方まで行って。

 
スゲーいいところで格闘技エクササイズサークルみたいな人たちがいました。こんなところで運動したら気持ちよさそう。

 
船乗って向こう岸まで。

 
向こう岸から見た香港島もキレイでした。

 
お約束のブルース・リーとか。

 
 
・Day5
 
最終日。本当にあっという間でした。先生はRichard。イギリス人で発音もモロにイギリスって感じ。
イギリスだとto be gutted about〜なんていう言い回しがあるとか教えてくれたりとか、クラブやバーでfancyってbuyと同じように使えるよとか。
 
そんなこんなで終わりもアッサリ。それじゃね〜くらいな感じで学校をあとにしました。お世話になりました。

 
午後は、こっちの友達が参加するってことで、香港で開催されていたオープンソースカンファレンス(http://2015.opensource.hk/)にいってきました。
 
コンビニで買ったサンドイッチを食べながら電車で長距離移動。

 
2回電車を乗り継いでその名も大学(university)って駅まで。

 
そこからタクシーでビヨ~ンと。京都リサーチパークみたいな雰囲気のところ。

 
受付して諸々受け取って、

 
AWSのパートナーさんのブースとか。

 
そんなに沢山のセッションは出れなかったけど、

 
PredictionIOって機械学習のセッションとか立ち見だったし(中身はSparkとかElasticsearchとか使ってる)

 
OpenStackの話はあんまり良くわからなかったけど、

 
日本のShimono Kenjiさんの発表は、Q&Aの時間帯に通訳的なこと出来たり、セッションの後にスマートウォッチ関連のビジネスしてる人と彼を繋ぐことが出来たり、行って良かったな、と。

 
んで、まぁ、記念撮影的な。

 
そこから友達がMongkokにあるトラディショナルな香港料理の店連れてってくれて、

 
そのままビール一杯千円するようなとこ行ったりして、

 
最後はオクトパスカード(Suicaみたいなヤツ)で買える屋台のソフトクリーム食って帰りましたとさ。
にしても、友達のHinにはこの旅でガッツリもてなされてしまったので、今度は東京でお返ししないとな〜

 

ということで、学校の事や、英語学習に関してあんまり触れておらず恐縮ですが、以上です。笑
#っていうか、友達と飲んだり食ったりしながら話するっていうのが一番勉強になるかもしれないなと。。
#トピック的に仕事絡みの話は同業種の人じゃなきゃ難しいし。。。
 

D09 地球の歩き方 香港 マカオ 深セン 2015~2016
ダイヤモンド・ビッグ社
売り上げランキング: 13,433

[Day3] IVS CTO Night & Day powered by AWS in Miyazaki #CTONight


IVS CTO Night & Day powered by AWS 2015 Spring 3日目のレポートです。
Day1の様子はコチラ Day2の様子はコチラ
 

 
Day3. IVS Launch Pad
 
■ Launch Pad
 
言わずもがなLaunch PadはIVSの目玉の1つですが、2年間に渡ってLaunch Padのステージ担当をしてきた自分にとっては、今後の人生を変えるかもしれない大舞台の言葉には出来ないような緊張感と、サービスにかける強い想いを感じることができるプレゼンテーションを生でみることが出来るというのは本当に大きくて、そう言った場にCTOの皆さまにご参加いただけるのは運営冥利につきるところだったりします。
 
それぞれのプレゼンテーションの内容や結果に関しましては各種メディア様の方でまとめていただいてますので、そちらもご覧頂ければと思います。
 
Launch Pad 勝者はソーシャルシッティング「KIDSLINE(キッズライン)」 #IVS 2015 Spring Miyazaki
http://thebridge.jp/2015/06/ivs-launch-pad-2015-spring


 
優勝は経沢香保子氏のベビーシッターサービス「キッズライン」――IVSのプレゼンバトル
http://jp.techcrunch.com/2015/06/12/ivs-spring-2015-launchpad/


 


 
■ “本当に叶うAmazonウィッシュリスト”
 
AWSからの優勝特典として”本当に叶うAmazonウィッシュリスト”を贈呈させていただきました!

 
 
Day3. CTO Tech Pitch
 
■ CTOによるテクノロジーに関するピッチ
 
Launch Padの興奮も冷めやまぬ中、CTOの皆さんによるピッチ大会を行いました。コンテスト形式ではなく、技術的に深い話をお聞かせいただきました。
 
1. 「React.js のアーキテクチャ上の課題」株式会社テンエックスラボ 鳥居 晋太郎
 
テンエックスラボの鳥居さんからは、クライアント側でのアーキテクチャに関しての設計および実装に関してお話していただきました。

 
自身で実装を進めていく中で、後からOSSでより良い実装が出てくるという話はよく聞きますが、そういった経験をすることは技術者としては、とても得るものがあるのではないかと思います。

 
 
2. 「App Ape Analytics Web API」 FULLER株式会社 藤原 敬弘
 
藤原さんは、FULLERのサービスであるスマホアプリ視聴率サービスで使われている技術を

 
構成図を元に詳細にご紹介いただきました。

 
 
3. 「High Performance Computing」 アマゾンデータサービスジャパン 松尾 康博
 
元CTOなソリューションアーキテクトの松尾からは、HPCに関するお話をしていただきました。

 
Web系のスタートアップではあまり見かけないような技術を分かりやすく、楽しく、発表してくれました。

 
 
4. 「iQON を支えるクローラー」VASILY 今村 雅幸
 
この日が誕生日だった、Vasily CTO今村さんによるクローラーの話。
CEOからの一言をトリガーに構築したスケーラブルなプラットフォームのお話をしていただきました。

 
Happy B-Day!!

 
言われた事を形にしてしまう技術力、素晴らしいですね!

 
 
5. 「OSSプロジェクトに会社を巻き込んでみようとしている話」株式会社ユーザベース 竹内 秀行
 
竹内さんからは、データ可視化に関する「E2D3」を会社で!という観点でお話いただきました。

 
乾杯のご発声に、セッション登壇に、今回のIVS CTO Night & Dayでは竹内さんに大活躍していただきました!

 
 
6. 「ウェルネスAiとグラフDB」株式会社 FiNC 南野 充則
 
FiNCの南野さんからは、現在取り組まれているグラフDBについてお話いただきました。

 
どうしても一般的なRDBMSを使ってJoinで解決しようとすると煩雑になってしまうところを
解決されようとしているところは皆さんの参考になったのではないかと思います。

 
 
Day3. Panel Discussion
 
■「CEOからCTOへ」
株式会社SHIFT 代表取締役社長 丹下 大
freee株式会社 代表取締役 佐々木 大輔
株式会社VASILY 代表取締役 CEO 金山 裕樹

モデレーター
アマゾンデータサービスジャパン事業開発マネージャ 畑 浩史

 
CTO Night & Dayに豪華CEOの皆さんをお招きしてパネルディスカッションを行いました。

 
Vasily CEOの金山さんからは↓のようなTweetもありましたが、


 
内容はCTOの皆さんを鼓舞するアツいものになり、

 
結果、笑顔な雰囲気になりました。

 
freeeの急成長をずっと支えてきた平栗さんも!

 
CEOの皆さま、ご登壇ありがとうございました!

 
 
■「会社での CTO のロール: 創業時と今」
株式会社クラウドワークス CTO 大場 光一郎
株式会社Viibar CTO 松岡 剛志
ChatWork株式会社 専務取締役 CTO 山本 正喜
株式会社nanapi CTO 和田 修一

モデレーター
アマゾンデータサービスジャパン ソリューションアーキテクト 松尾 康博

 
急成長中の組織を率いるCTOの皆さんによる深いディスカッションになりました。

 
こちらのセッションは↓でも取り上げていただきいておりますので、是非ご覧いただければと思います。
1on1は仕組み化して「やらない理由」を作らないことが大切ーー新進気鋭4社のCTOが語る社内コミュニケーションの方法 #IVS
http://thebridge.jp/2015/06/aws-cto-night-and-day-at-miyazaki-2015


 
それぞれ違ったアプローチを取りつつも、常に組織の事を考えて日頃の業務に取り組まれている皆さんの強い意志を感じたセッションでした。

 
 
■ 「スタートアップでのイケテル技術選定、今・これから」
株式会社はてな 執行役員最高技術責任者 田中 慎司
クックパッド株式会社 執行役CTO 舘野祐一
グリー株式会社 取締役 執行役員常務 CTO 藤本 真樹

モデレーター
アマゾンデータサービスジャパン
ソリューションアーキテクチャ部長 大谷 晋平

 
日本人のエンジニアであれば憧れの存在であろう、高い技術力をお持ちのCTOの皆さんによる技術選定に関するディスカッション。

 
カジュアルな語り口調の中に、失敗談等も織り交ぜながら、でも、”この人たち凄い!”と思わせる大変興味深い雰囲気のセッションでした。

 
濃ゆい話の数々をありがとうございました!

 
 
■ ハイトラフィックなアプリケーションでのフロントエンドの技術選択 -サーバーとクライアントの役割分担について-」
株式会社アカツキ CTO 田中 勇輔
株式会社サイバード シニアプロデューサー 島村友造
KLab 株式会社 執行役員 CTO 安井 真伸

モデレーター
アマゾンデータサービスジャパン ソリューションアーキテクト
今井 雄太

 
最後のパネルディスカッションは非常に現場寄りな話題が多く出たものになりました。


 
アプローチの仕方も様々で、ゲームの開発に馴染みのないようなCTOの皆さんにも参考になる部分が多かったのではないかと思います。

 
早朝からのハードなスケジュールの中で、詳細まで突っ込んだ議論をしていただき、ありがとうございました!

 
 
Day3. Party
 
■ Farewell CTO Night
 
IVS CTO Night & Dayの最後は、シェラトン・グランデ・オーシャンリゾートの42階のグランシャリオで行いました。
会場からの眺めは絶景でした!


 
乾杯のご発声はnanapiの和田さんに行っていただきました。

 
最後のパーティーということで、スタッフたちも一緒に楽しく盛り上がりました。
皆さまが楽しまれている様子の一部を掲載させていただきます。

 

 

 

 

 

 

 
そして、クロージングはお誕生日のVasily今村さんの一本締めで!

 
よ~ぉ

 
パンッ!

 
ありがとうございました!!
 
 

ということで、もの凄い濃かった3日間、CTOの皆さんが醸し出すとても良い雰囲気もあって、運営する側としても、とても刺激的で、何より凄く楽しませていただきました!
また、スタッフとしてご参加いただきました、nanapi小島さんと遠山さん、Casy高橋さん、本当にありがとうございました!

 
今後とも #CTONight を何卒よろしくお願い致します!

[Day2] IVS CTO Night & Day powered by AWS in Miyazaki #CTONight


IVS CTO Night & Day in Miyazaki 2日目のレポートです。Day1の様子はコチラ

 
 
Day2. AWS Morning Session
 
■ AWS Solutions Architectによるラウンドテーブル
 
早朝から任意参加でAWSに関するセッションを行いました。
 
・8:30 – 9:00
西谷 モバイル開発を支えるAWS Mobile Services
今井 ビッグデータキーワード超整理 -YARN,Hive,Tez,Presto,Impala,Spark-
松尾 いまさら聞けないEC2
大谷 Amazon RDS for Aurora Deep Dive
清水 Amazon Kinesis 入門
篠原 Amazon CloudSearch Deep Dive

・9:15 – 9:45
西谷 AWS Lambda概要
今井 Amazon Machine Learning入門
松尾 EC2チューニングTips
大谷 ECS Deep Dive
清水 2-Tier Architecture Deep Dive
篠原 利用者が実施するAWS上でのセキュリティ対策

 
CTOの皆さんたちには、Amazon Machine Learning, Amazon RDS for Aurora, セキュリティ対策といったセッションが人気でした!
 
 
Day2. オープニングのご挨拶

■ Infinity Venture Partners 小林 雅
 
オープニングのご挨拶はIVS主催の小林さんから!

 
■ アマゾンデータサービスジャパン 畑 浩史
 
AWS Startup担当事業開発マネージャーの畑からCTO Nightとは?といったところを改めて。

 
 
Day2. Keynote
 
■ 『WE ARE CTOs. SO, WHAT COMES NEXT?』 グリー 藤本 真樹
 
前回のCTO Night & Dayのアンケートで、ダントツに”あの人の話が聞きたい!”という人が多かった
藤本さんからキーノートのスピーチをいただきました。

 
途中、会場内のCTOの皆さんを藤本さん自ら質問して回るというインタラクティブでユーモラスなところもありつつ、

 
後半は日本のCTOが置かれている状況を、世界を相手に戦ってきた藤本さんならではの視点でお話いただき、
Twitterの #CTONight ハッシュタグでCTOの皆さんから多くのツイートがありました。

 
 
Day2. Session
 
■ 『CTO のための Security 戦略』 ウェブペイ 曾川 景介
 
決済サービスを運営する企業のCTOということで、ウェブペイ曾川さんからは、ユーザーのデータを守るための
実践的な内容と心構えについてお話いただきました。

 
特に、 /security ページで、しっかりセキュリティへの取り組みを公開することが大事というところは、
皆さんに響いたところなのではないかと思います。


 
こちらのセッションがきっかけになって、アンカンファレンスでセキュリティに関するディスカッションが
議題として採用されました。
 
 
■ 『Bay Area Startup Report』 アマゾンデータサービスジャパン 篠原 英治
 
私の方からは、先日出張で一週間働いてきたSan FranciscoのAWS Pop-up Loftの様子や、
その期間にベイエリアのStartupのCTO/エンジニアからいただいた質問やその回答の内容を紹介させていただきました。
PairyやCookpadの事例で海外のCTOをうならせる事が出来たというエピソードなど、
どこかで披露したい!と思っていたのでとても良い機会でした。

 
AWSのソリューションアーキテクトとして、少しでも皆さまのお役に立てればと思っておりますので、
引き続きよろしくお願いします!

 
 
■ 『エンジニアからCTOへ』 MonotaRO 安井 卓
 
FCバルセロナファンの安井さんは、壇上でユニフォームを着てのご登壇となりました。
slashdotやsourceforgeの開発というバックグラウンドを持つ安井さんが、
エンジニアから上場企業のCTOになった軌跡を熱いメッセージと共に語ってくださいました!

 
発表資料は↓こちらです。

 
 
■ 『会社としてのリファレンスコードを描く』 ユーザベース 竹内 秀行
 
CTO事件簿的なスリリングな出来事のご紹介も踏まえつつ、例えばアスペクト指向プログラミングといった
技術者としての竹内さんのこだわりといった部分もお話いただきました。

 
発表資料は↓こちらです。

 
 
■ コーヒーブレイク
 
↓のTweetが発端となり、


 
一時、ブレイク会場はマカロン奪い合い状態になりました。笑

 
 
Day2. アンカンファレンス
 
■ テーマ決め
 
今回は事前にFacebookグループでアンカファレンスのお題を投票しておいていただいた事で、
投票数の多かったテーマを1テーブル約10人でディスカッションしていただきました。

 

 
■ ディスカッション
 
今回も本当に濃いディスカッションだらけで、内容は公開出来ませんが、
日頃なかなか相談出来ないようなことを、CTO同士でぶつけあっていただきました。

 

 

 
■ 発表
 
発表時間を設けて、テーブル毎にどういうディスカッションをしたのか共有いただきました。

 

 
 
Day2. Party
 
■ 乾杯
 
乾杯のご発声は藤本さんにお願いしました。
元G社で働いていたCTOの皆さんが正座でお話を聞く、という一幕も。笑

 
というか、正座のまま乾杯。笑

 
■ 歓談
 
たくさんの方に料理美味しい!!というコメントをいただきました。

 
パーティーの最後に集合写真を撮らせていただきました!

[Day1] IVS CTO Night & Day powered by AWS in Miyazaki #CTONight


前回の京都に引き続き、Infinity Ventures Summitと共催で『IVS CTO Night and Day powered by AWS』を宮崎のシーガイアで開催しました!

 
今回も約100人のCTOの皆さまにお集まりいただいて、3日間に渡って
非常に濃いカンファレンスとなりましたので、レポートとして振り返っていきたいと思います。
 
 
Day1『Welcome CTO Night』
 
 
■ 乾杯
 
乾杯のご発声は2014年のTech CrunchのイベントでCTO of the yearに選ばれたユーザベースの竹内さん


 
パーティー中の歓談はとても盛り上がり、前回に引き続きご参加いただいた、
オモロキ CTOの和田さんからは、自身のPodcast(wada.fmのエピソード35『Podcastフロム宮崎』)にて、
“肌感覚で前回よりもイイ感じだった”とコメントいただきました。
 
 
■ CTO実態調査
 
そして、皆さんお待ちかねのCTO実態調査の結果発表。


@keisuke69 が考えた生々しい過激なアンケート(プライベート/お金/モチベーション…etc)。
前回よりもステージが上のご回答も多く、ガッツリ会場がザワつきました。
非常にセンシティブな内容のため公開することは難しいですが、今後も継続していきますので、
CTOの方は是非本イベントにご参加いただければと思います。
 
 
■ Lightning Talks
 
1. ノイエジーク 辻亮佑「心が強い男」
最近話題沸騰中のairClosetのノイエジークCTOの辻さんからは、
激しい負荷を受け続ける中で鍛えられたメンタルについてお話いただきました。

 
2. ガイアックス 肥後彰秀「障害あるあるとその考察」
障害対応はエンジニアとしての腕の見せ所という部分もありますが、
仕組み化して捌きたいもの。あるあるネタだけで終わるわけではなく、
Reactioを活用した対応についてもご紹介いただきました。


 
3. Connehito 島田達朗 「Q&Aコミュニティのテキスト解析」
コミュニティサービスのデータを使ってword2vecで解析したという話。
数々の興味深い結果に会場からもなるほどといったリアクションがあがっていました。

 
vector(‘可愛い’) – vector(‘息子’) + vector(‘娘’) の結果とか微笑ましいですね(*´∀`*)

 
4. アクトキャット 角 幸一郎 「開発メンバーを増やすときの秩序だったプラクティス with sideci」
炎上ブログを書いた人が、こんなに笑顔が素敵なCTOだったとは、、と皆さんお感じになったのではないかと思いますが、
そんな角さんからは現場のエンジニアがストレス無く効率的に働くことが出来るようなサービスをご紹介いただきました。


 
5. レコチョク 稲荷幹夫「雇われCTOの事件簿」
以前、経営コンサルタントだった稲荷さんからは、経営戦略という視点でお話をいただきました。
CTOは技術だけでなく、経営者として数字を見ていかなければならないという点で参考になった方も多かったのではないかと思います。


 
6. ワンモア 草地亮介「CTOやってみて変わったこと」
CTOになって1エンジニアとしての殻をやぶっていった草地さんのイイ話!

 
7. スパイスライフ 五十嵐邦明「花粉症疎開制度を実施して分かったこと」
花粉症の時期に沖縄からリモートで働かれていた五十嵐さんからは、
素敵な写真と、効率良く働くことが出来た!というお話をいただきました。


 
8. コーチ・ユナイテッド 富田陽介「途中からやってきたCTOの話」
Cytaを運営されているコーチ・ユナイテッドの富田さんからは、今までの変遷や、構成図(CloudSearchもご利用いただいています!)、そして神南エンジニアリング勉強会の事などをシェアしていただきました。

 
 
お料理やお飲み物も豪華でした!



 


 
 
Day2に続きます。
[Day2] IVS CTO Night & Day powered by AWS in Miyazaki #CTONight

Flickr の new unified search experience について


Twitter眺めてたら、昔サンフランシスコに住んでた頃に、職場一緒でご近所さんだった
友達の @superic が↓こんなツイートしてて。


↓コレまた面白そうじゃないですか、と。”search is never finished”とかアツいこと言ってるし。
Find every photo with Flickr’s new unified search experience
 
ってことでチョロっと紹介してみたいと思います。
 

 
With over 10 billion images on Flickr, search is one of our most important features – and based on feedback we’ve collected from the global Flickr community, we’ve decided it’s time for a transformation.
Flickrには100億もの画像があって、検索は最も重要なfeatureの1つです。
グローバルなFlickrコミュニティからのフィードバックを元にtransformationの決断をしました。
 
Today, we’re thrilled to bring you a new unified search experience that is intelligent, intuitive and fast.
今日私たちは、intelligentでintuitive(直感的)で高速な新しいunified search experienceを提供します。
 
 
(↓例えば、”flower”で検索した場合)
Universal Search
 
 
Whether you’re trying to find that special photo from last year’s family reunion or you need an image for a presentation, the new Flickr search has you covered. Just try it for yourself!
例えば、あなたが去年のfamily reunionのspecialな写真を探そうとしたり、プレゼンテーションに使うイメージが必要な時とか、新しいFlickr searchにお任せください。まずは試してみてね!
 
 
・Now you can filter images by color, size and orientation. Imagine searching for panoramic flower photos with red, yellow and magenta hues – it’s really possible!
・色、サイズ、方向、で画像をフィルタリングすることができます。例えば『パノラマな花の画像で色合いが赤/黄/マゼンタ』なんてことが出来ちゃう!
 
 
・Search for “London Eye” and you’ll no longer get photos of eyes in England, but find the giant Ferris wheel. Our new advanced search algorithms understand your intent and bring you higher quality results time after time.
・”London Eye”で検索した時に、イングランドで撮影された目の画像が出てくる事はないでしょう。その代わりに、大きい観覧車が表示されます(そういう名前の有名な観覧車があるみたいですね〜)。私たちの新しいadvancedな検索アルゴリズムは、あなたの意図を理解して、higher qualityな検索結果を提供します。
 
 
・You can even search for a holiday or location – finding your favorite photo from that New Years Eve you spent in Hawaii has never been easier!
・holidayやlocationで検索できます。例えば、大晦日にハワイで撮ったお気に入りの写真を見つける、とか今までは簡単じゃなかった。
 
 
Last but not least, our team of image recognition experts has built spectacular technology that recognizes the content in your images. You don’t even have to tag or label the photos yourself to make them easy to find (but the tags are easy to change and as always, your privacy settings are respected).
最後に大事なことを言うと、私たちの画像認識エキスパート達は、Flickr上の画像を認識するためにspectacularなtechnologyを構築しました。もうtagとかlabelであなたの画像を探しやすくする必要はありません。(とは言え、tagは今まで通り簡単に変更できて、あなたのプライバシー設定は継続して有効です)
 
 
(↓Everyone’s で”flower”で検索した場合)
2 Color Search
 
 
The unified view of your search results now includes different sections for your photostream, your albums, photos from people you follow, and photos from the wider Flickr community.
検索結果のunified viewは、photostream, albums, photos from people you followといったセクションも表示するようになりました。
 
We’ve also dramatically improved loading and scrolling performance and we give you a new thumbnail view so that you can more easily scan results. Search results for people and groups are just one click away, and you can more easily find active groups on any topic.
私たちは画像のロードとスクロールのパフォーマンスを劇的に向上させました。結果を簡単にスキャン(ザザーっと見る的な感じですかね)出来るようにするためにサムネイルを新しくしました。検索結果の people と groups はワンクリックで移動できます。どんなトピックに関してもactiveなgroupsを簡単に見つけることが出来ます。
 
 
(↓minimalistっていうグループ?を選んだ場合)
2 Color Search + Minimalist
 
 
Perhaps more than any other feature, search is never finished. With this new experience in place, we’ll continue our work to serve you the best results on Flickr for every search you can imagine.
これからも沢山の機能が追加されるでしょう。検索に終わりはありません。Flickrのユーザーが考えるベストな検索結果を提供するために、我々は今後も開発を続けていきます。
 
 
If you have issues or feedback, we want to hear from you. Please share your thoughts in the Help Forum.
もし、何か問題やフィードバックがあれば、是非あなたのご意見をHelp Forum(https://www.flickr.com/help/forum/)に寄せてください。
 

 
興味深いのはブログを書いた Andrew Stadlen さんはIQ Engines(http://iqengines.com/)っていうスタートアップにいて、
Yahoo!に買収されてFlickrチームにいるって感じみたいですね。
日本でもそういうケースを見かけますが、友達のEricもLookFlowをやっててY!に買収って背景があるので、
日本よりもやっぱり活発なのでしょうか?
 

Canon デジタルカメラ PowerShot SX410IS 光学40倍ズーム PSSX410IS
キヤノン (2015-03-19)
売り上げランキング: 15,705

Prezi が Amazon CloudSearch を導入したよっていう話


今朝、いつものように、フトンの中でTwitterを眺めてたら、↓のようなツイートがありました。


 
へーって思って↓を読んでたら、面白かったので、ちょこっと内容を紹介したいと思います。
『PREZI: SEEKING CLOUD-BASED SEARCH THAT “JUST WORKS”』
 

During the course of our research on search in the cloud, we’ve been collecting some case studies on uses of SaaS-delivered search.
クラウド上の検索サービスについて調査するにあたって、SaaS-deliveredな検索のユースケースを集めてきました。
 
Two of the major reasons that companies give us for moving their search to a cloud-based model are that
彼らが言う、cloud-based modelなサービスへの移行に関するメジャーな理由は2つです。
 
first, they need a scalable, flexible model that can vary with the demands of the business,
1つ目は、scalableでflexibleなモデルで、ビジネスのディマンドの変化に対応可能であることで、
 
and second, that search is not their core business so they prefer to rely on outside experts who can deliver a solid reliable foundation on which they can build specialized applications.
2つ目は、検索そのものはビジネスのコアではないわけなので、外部の(検索に)特化した専門家が作ったsolidでreliableな基盤を活用する方が好ましいということです。
 
 
Businesses that are dynamic information exchanges require this kind of scalable reliability.
dynamicな情報交換を行うビジネスにおいて、scalableでreliableな基盤は必須です。
 
They need to make their information available quickly, and cater to the dynamics of their users. Search is critical to their business.
情報を瞬時に利用可能にし、ユーザーにダイナミクスを提供する必要があって、検索は彼らのビジネスにとってクリティカルです。
 
Prezi (prezi.com) is a good example of this kind of use.
Preziのユースケースは上記にぴったり当てはまります。
 
This cloud-based software company enables its customers to brainstorm and collaborate, create unusual presentations, and share the results, no matter their location or device.
このcloud-basedなsoftware companyは、ブレインストーミングとコラボレーション、unusual(Preziならではのユニーク)なプレゼンテーションの作成、そしていかなる場所やデバイスにも成果物をシェアすること、を可能にします。
 
Their search needs at this stage are basic—good matching of queries to documents and quick updating of their index.
彼らの検索のニーズは、basic-goodにドキュメントを検索出来ることと、クイックに検索インデックスを更新出来ることでした。
 
They started with about 200 million documents, but the volume to grow to 1 terabyte, doubling annually.
彼らは2億ドキュメントからはじめたが、データのボリュームは年間で倍になるペースで1テラバイトになります。
 
Prezi did not want to hire or develop the expertise to build search from scratch, and they needed flexible, scalable search to match their growing business.
Preziは検索サービスをスクラッチで構築したくなかったし、その為の人員のハイヤリングもしたくありませんでした。
彼らに必要だったのは、彼らのビジネスの成長に見合ったflexibleでscalableな検索サービスだったからです。
 
Their customers need to find materials both they and others have developed, and they want to find images by topic without the time consuming delays of creating and standardizing tags.
Preziのカスタマーは、自分もしくは他のユーザーによって作られたmaterialsを探し当てる必要があり、
彼らは、スライドの作成やタグのstandardizingに伴うtime consumingな遅延なくトピック毎のイメージを探したいと思っています。
 
 
To make its materials searchable quickly and easily, Prezi developed a database of images that are associated with the text in the same slide.
materialsをquickに、そして簡単にsearchableに検索可能にするため、Preziは画像データベースを作成して、同じスライドの中のテキストと関連付けをしました。
(つまりPrezi上では1つ1つのスライドは画像になってて、テキスト情報とは別に保存されているって事ですかねー)
 
The contents change constantly, however, and they need to upload those images and make them searchable automatically using the related text.
コンテンツはコンスタントに変更されるが、その都度、画像をアップロードして自動的に関連語句を検索可能にする必要があります。
 
Furthermore, they anticipate adding and indexing new sources.
更に、新しいデータソースを追加およびindexingに対しても事前に対処をしておく必要があります。
 
For this purpose, they envisioned using search as “a materialized view over multiple sources.” In other words, a single gateway to all their information.
その為に、検索サービスを複数のデータソースのマテリアライズドなビューという位置づけで捉えました。
別の言い方をすると、彼らの全ての情報に対するsingle gateway。
 
 
To accomplish this, they needed stable, reliable and expandable search.
これを達成するため、stableでreliableでexpandableな検索サービスが必要でした。
 
The materials had to be accessible to its users no matter their device or location.
そして、どんなデバイスや場所からでもアクセス可能でなければなりませんでした。
 
Peter Neumark, a Prezi software engineer told us that they were looking for search that they could “pay for, use and forget about.”
Preziのsoftware engineerのPeter Neumarkさんは、”pay for, use and forget about”な検索サービスを探してたと我々に語りました。
 
 
 
Selecting a Search Infrastructure
 
Prezi’s previous search solution was slow, and didn’t function well enough as a key-value store.
Preziの以前の検索ソリューションは遅くて、key-valueストアとしてあまり機能的ではありませんでした。
 
They also required a solution that allowed them to relate an image to its neighboring text easily.
画像をneighboringなテキストに簡単に関連付けるソリューションが必要でした。
(ステミングとかシノニムとかって感じですかね〜?)
 
They decided to look at Amazon’s CloudSearch to solve these problems and deliver relevant material to searchers quickly and reliably.
彼らは、これらの問題を解決するため、そして、quickでreliableにrelevantなmaterialをデリバーするためにAmazonのCloudSearchを導入することにしました。
 
In other words, they were looking for search that “just worked”.
他の言葉で言えば、彼らは“just worked”な検索サービスを探していました。
 
They didn’t want to maintain it themselves, and, because they were familiar with them, they wanted to continue to use the AWS API’s, which they like.
彼らは自身で保守運用は行いたくないと思っていて、そして、彼らに馴染みがあり、彼らが好んで使っていたAWSのAPIを使い続けたかったということです。
 
When they did head-to-head testing, they found that CloudSearch was cheaper, faster, more reliable and expandable, and easier to synch with their Amazon DynamoDB database.
head-to-head testingを行った結果、CloudSearchはcheaperでfasterでreliableでexpandableでAmazon DynamoDBと簡単に同期が取れることが分かりました。
 
They liked its auto-scaling features that would grow with their data and their business.
(CloudSearchの)auto-scaling機能は彼らのデータやビジネスの成長にとって好ましいものでした。
 
 
 
Rolling out CloudSearch and Future Plans
 
Prezi are “happy campers”.
Preziは”happy campers”です。(辞書引くと、幸せものです的なのが出てきますが、そんな感じですかね〜?)
 
They deployed CloudSearch in 3 weeks, and are seeing lower cost, lower latencies, and virtually no need to pay attention to their basic search foundation.
彼らはわずか3週間でCloudSearchを導入しました。lower costでlower latencyで、実質的にbasicなsearch foundationに注意を払わなくてよくなりました。
 
Their next step will be to roll out additional domains and sources.
彼らの次のステップはadditionalなドメインとデータソースを導入することです。
 
They like the idea of adding domains rather than changing the initial schema.
彼らはドメインのスキーマを変更することよりもドメインを追加することを好みます。
 
They will also make the search function more visible on their site, now that they no longer need to worry about its reliability and speed.
彼らは検索機能をサイト上でもっとvisibleにしようとしています。彼らはもう検索のreliabilityとspeedを心配する必要はありません。
 

 
Amazon CloudSearchについては以前Solr勉強会(#SolrJP)で発表した資料とかもあるので、よろしかったらご覧ください↓

 

Preziで始めるズーミングプレゼンテーション 第2版
筏井 哲治 高橋 佳佑
日経BP社
売り上げランキング: 103,420

Amazon ECS の動的な Network port mapping について


Dockerは docker run する時に、-P フラグを立てると、Dockerホストの、自動的にランダムにエフェメラルポートレンジの中のhigh port(well knownじゃないヤツ)に割り当てを行います。
これはDockerのドキュメントの Linking Containers Together(https://docs.docker.com/userguide/dockerlinks/) に書いてあって、
↓のようにDockerコンテナの5000番ポートが、Dockerホストの49155番ポートにマッピングされてる例とか。

$ sudo docker ps nostalgic_morse
CONTAINER ID  IMAGE                   COMMAND       CREATED        STATUS        PORTS                    NAMES
bc533791f3f5  training/webapp:latest  python app.py 5 seconds ago  Up 2 seconds  0.0.0.0:49155->5000/tcp  nostalgic_morse

 
Amazon ECSでは、DockerホストであるEC2と、Dockerコンテナのポートのマッピングに関しては、
↓のドキュメントのようにTaskのパラメータとして定義します。タスクって?って感じですが、要はコンテナの定義のことです。
http://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html

"portMappings": [
    {
        "containerPort": integer,
        "hostPort": integer
    }
    ...
]

 
EC2上に複数のDockerのコンテナを立ち上げて、例えばそれらがxxポートをリスンするものだったとして、
ユーザーとしてはホスト側のポートは上記のように、よしななポートをマッピングして欲しいですね、と。
 
コチラに関しては、上記のドキュメントの中には↓のように記載されています。

If you want an automatically assigned host port, use the following syntax:
"portMappings": [
    {
        "containerPort": integer
    }
    ...
]

ただ、書かなければ良いって話なのですね、と。
 
ということで、さっそく試してみたいと思います。
 
 
■ Docker Imageの作成とDocker Hubへのアップロード
 
ECSのドキュメントのDocker Basicsの”To create a Docker image of a PHP web application”に沿って
やっていきたいと思います。
 
まずはギッハブからコピってきます。

$ git clone https://github.com/awslabs/ecs-demo-php-simple-app
Cloning into 'ecs-demo-php-simple-app'...
remote: Counting objects: 71, done.
remote: Total 71 (delta 0), reused 0 (delta 0), pack-reused 71
Unpacking objects: 100% (71/71), done.
Checking connectivity... done.

 
Dockerfileを見ると、UbuntuにApacheとかPHPとかインストールして、80番ポートでリスン的なのが分かります。

$ cat Dockerfile 
FROM ubuntu:12.04

# Install dependencies
RUN apt-get update -y
RUN apt-get install -y git curl apache2 php5 libapache2-mod-php5 php5-mcrypt php5-mysql

# Install app
RUN rm -rf /var/www/*
ADD src /var/www

# Configure apache
RUN a2enmod rewrite
RUN chown -R www-data:www-data /var/www
ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2

EXPOSE 80

CMD ["/usr/sbin/apache2", "-D",  "FOREGROUND"]

 
私のMacの環境でDocker imageを作ります。
boot2docker startで仮想マシンを立ち上げて、環境変数をホゲホゲって話は
↓この辺を参考になさっていただければ、と。
https://docs.docker.com/installation/mac/
 
しばらくボケっとしながらビルドが終わるのを待ちます。

$ docker build -t shinodogg/amazon-ecs-sample .
Sending build context to Docker daemon 363.5 kB
Sending build context to Docker daemon 
Step 0 : FROM ubuntu:12.04
Pulling repository ubuntu
〜略〜
tep 11 : CMD ["/usr/sbin/apache2", "-D",  "FOREGROUND"]
 ---> Running in d855e0fc614e
 ---> adfdd9bcf446
Removing intermediate container d855e0fc614e
Successfully built adfdd9bcf446
$ echo $?
0

 
では走らせてみましょう。

$ docker run -p 80:80 shinodogg/amazon-ecs-sample

 
アドレスは↓よん、って事ですので、、

$ boot2docker ip

The VM's Host only interface IP address is: 192.168.59.103

 
↓のように、良さ気でございます。

 
ってことで、Docker ImageをDocker Hubへ。コマンドラインでログインして、

$ docker login
Username: shinodogg
Password: 
Email: xxxx@gmail.com
Login Succeeded

 
Docker Hubにpushします。貧弱な回線だとちょいちょい時間かかりますね。。

$ docker push shinodogg/amazon-ecs-sample
The push refers to a repository [shinodogg/amazon-ecs-sample] (len: 1)
Sending image list
Pushing repository shinodogg/amazon-ecs-sample (1 tags)
〜略〜
adfdd9bcf446: Image successfully pushed 
Pushing tag for rev [adfdd9bcf446] on {https://cdn-registry-1.docker.io/v1/repositories/shinodogg/amazon-ecs-sample/tags/latest}

 
 
■ ECS用のEC2インスタンスを起動
 
MarketplaceからAMIを持ってくるのも良いのですが、実際にどんなものか知りたいので、
EC2をAmazon Linuxで普通に立てて、そこに諸々インストールしていきたいと思います。
↓に沿ってやっていきます。
Installing the Amazon ECS Container Agent
 
EC2はt2.mediumにしてみます。

 
EC2からECSをホゲホゲ出来るようにIAM Roleを付けてあげます。↓をまんまです。
http://docs.aws.amazon.com/AmazonECS/latest/developerguide/IAM_policies.html#instance_IAM_role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecs:CreateCluster",
        "ecs:RegisterContainerInstance",
        "ecs:DeregisterContainerInstance",
        "ecs:DiscoverPollEndpoint",
        "ecs:Submit*",
        "ecs:Poll"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

 
ポートはアレがアレで、一旦、自分のIPで全開放してみます。

 
EC2が立ち上がったら、dockerコマンドをインストールして、Dockerのサービスを立ち上げます。

$ sudo yum install docker -y
$ sudo service docker start
Starting cgconfig service:                                 [  OK  ]
Starting docker:	                                   [  OK  ]

ECSエージェントをインストールします。
ココでクラスタ名(shinodoggって書いてある太字のところ)が聞かれるのは理由があって、
この時点でClusterが起動していないと↓のようなエラーが出て止まってしまうので、
ECSのクラスタを作ってから叩きましょう。
msg=”Error registering” module=main err=”Cluster not found.”

$ sudo docker run --name ecs-agent -d \
> -v /var/run/docker.sock:/var/run/docker.sock \
> -v /var/log/ecs/:/log -p 127.0.0.1:51678:51678 \
> -v /var/lib/ecs/data:/data \
> -e ECS_LOGFILE=/log/ecs-agent.log \
> -e ECS_LOGLEVEL=info \
> -e ECS_DATADIR=/data \
> -e ECS_CLUSTER=shinodogg \
> amazon/amazon-ecs-agent:latest
Unable to find image 'amazon/amazon-ecs-agent:latest' locally
Pulling repository amazon/amazon-ecs-agent
68db83900ab7: Download complete 
86ae36d94914: Download complete 
b39579a0c13b: Download complete 
36d93670e9b5: Download complete 
Status: Downloaded newer image for amazon/amazon-ecs-agent:latest
ac73fd6a55f02a6c0b7251d09cdc8700d4c89a7e00aae4ff42bf7575dd90bddc

 
 
■ ECSを使ってEC2上にコンテナを2つデプロイ
 
ココからは、Management Consoleを使っていきます。
 
まずはTaskの定義からしていきます。タスクって用語がややこしいのですが、そのDockerインスタンスに
どんなリソース(CPUとかメモリとか)割り当てるか〜とか、ポートどうするー?とか、そういうヤツです。
 
タスクの定義自体はECSのドキュメントのDocker Basicsにあるので、それをそのまま使います。

 
JSONタブにそのままコピペすると、

 
Builderタブでイイ感じに見えます。ついでなのでCPUとメモリの値をイジったりしつつ、

 
意図的にホスト側のポートの設定を削除します。

 
で、このTaskからServiceを作ります。これも名前がややこしいですが、
Scheduling Amazon ECS Tasksのページをみると(スケジューリングって言葉も慣れない人にはアレですね、、笑)
・Create Service: The service scheduler is ideally suited for long running stateless services and applications.
・Run Task: The RunTask action is ideally suited for processes such as batch jobs that perform work and then stop.
って事なので、今回はWebなアプリケーションなので、Create Serviceの方で、Clusterを shinodogg という名前で作ります。

 
この状態で上記のECSエージェントを走らせると、ログがイイ感じにズコズコ流れるかな、と。
あ、ちなみにECSエージェントのログファイルは /var/log/ecs/ecs-agent.log にあります。
 
マネージメントコンソールではServiceのStatusがActiveになっていてTaskが2つRUNNINGになっています。
(Taskのリビジョンが3に上がってるのは気にしないでください…笑)

 
EC2で docker ps を叩くと、ちょーっと見づらいですが、
↓のようにホストの49155番ポートと49156番ポートがそれぞれ立ち上げたDockerコンテナの
80番ポートにマッピングされているのが分かります
0.0.0.0:49156->80/tcp
0.0.0.0:49155->80/tcp

$ sudo docker ps
CONTAINER ID        IMAGE                                COMMAND                CREATED             STATUS              PORTS                        NAMES
43280236f478        busybox:buildroot-2014.02            "\"sh -c '/bin/sh -c   4 minutes ago       Up 4 minutes                                     ecs-console-sample-app-3-busybox-e8b18898b7af93ddaa01      
4137bedb3bcd        shinodogg/amazon-ecs-sample:latest   "/usr/sbin/apache2 -   4 minutes ago       Up 4 minutes        0.0.0.0:49156->80/tcp        ecs-console-sample-app-3-simple-app-c2da8c81ccb3f2cbdf01   
ae6d023c81ba        busybox:buildroot-2014.02            "\"sh -c '/bin/sh -c   4 minutes ago       Up 4 minutes                                     ecs-console-sample-app-3-busybox-d488f69e80a6d59edd01      
4a7bc27d9de1        shinodogg/amazon-ecs-sample:latest   "/usr/sbin/apache2 -   4 minutes ago       Up 4 minutes        0.0.0.0:49155->80/tcp        ecs-console-sample-app-3-simple-app-dadb83dae896d2afbc01   
2d6ea464a2c4        amazon/amazon-ecs-agent:4023248      "/agent"               10 minutes ago      Up 10 minutes       127.0.0.1:51678->51678/tcp   ecs-agent  

 
では、ブラウザからアクセスしてみましょう。
 
・49155番ポート

 
・49156番ポート

 
無事に、よしなにホスト側のポートとマッピングされていることが確認できました(´▽`)ノ
ってことで、検証環境はキレイにお掃除しておきます、と。
 
お仕事でいろんな人とお話させていただいている中でも、最近Dockerがすごい来てる感ありますが、
↓はプロダクションでDockerを使っている方の記事とかありますね。

WEB+DB PRESS Vol.86
WEB+DB PRESS Vol.86
posted with amazlet at 15.05.05
結城 洋志 沖元 謙治 足永 拓郎 林 健太郎 大竹 智也 内田 誠悟 伊藤 直也 中山 裕司 hiroki.o 泉水 翔吾 佐藤 太一 高橋 俊幸 西尾 泰和 舘野 祐一 中島 聡 橋本 翔 はまちや2 竹原 麻植 泰輔
技術評論社
売り上げランキング: 902

 
最後に、本投稿は私が個人的に行ったものであり、所属する企業や団体における公式見解ではございません。

AWS Elastic BeanstalkのMulti-Container Docker Environmentsおよびebコマンドを使ったデプロイについて


先日、AWS Elastic Beanstalk Supports Multi-Container Docker Environmentsで発表がございましたが、
1つのEC2インスタンスに複数のDockerコンテナを配置することが出来るようになりました。
こちらは、Amazon EC2 Container Serviceのテクノロジーがベースになっています。
今回は、このMulti-Container Dockerを使った環境の構築と、
ついでにebというElastic Beanstalk用のコマンドラインツールを使ったアプリケーションのデプロイを試してみたいと思います。
 
なお、本投稿は私が個人的に行ったものであり、所属する企業や団体における公式見解ではございません。
 
 
■ Multi-container Dockerの設定で構築
 
Elastic Beanstalkの用語として以下のようなものが挙げられます。
・Application: Environmentの集合体。フォルダのようなイメージ。(動くコードそのものではない)
・Version: デプロイするコード。S3をリポジトリにしてバージョン管理。
・Environment: Versionがデプロイされた環境。複数Environmentにそれぞれ異なるVersionをデプロイすることも出来る。
なんとなくApplicationというと、動くコードそのものをイメージしてしまいそうになるのですが、
そうではないので念の為ご注意いただければと思いますmm
 
で、実際の構築のやり方は Multicontainer Docker Environments with the AWS Management Console に書いてありますが、Multi-containerは上でも少し触れたように、ECS(EC2 Container Service)が元になっているので、そのAPIを叩けるようにしたり、
ログの格納用に使用するS3バケットへのputの設定をaws-elasticbeanstalk-ec2-role(EBで環境構築する際にデフォルトで作成されるIAM Role)に対して行います。
↓のワーニングはそのことを言っています。

 
具体的にはIAMの画面でPolicyを作ってRoleの画面でAttache Policyの設定をします。

 
サンプルのアプリケーションで構築が完了すると↓のような画面になります。

 
払いだされたURLにアクセスすると↓こんな感じ。

 
試しに、プロビジョニングされたEC2インスタンスにSSHで入ってみると、
↓のようにdockerやecsが動いてるような感じしますね。

 
dockr psを叩いてみると、以下のように、プロキシ用のNginx、PHPのアプリ、ESCのエージェントが動いているのが分かります。

$ sudo docker ps
CONTAINER ID        IMAGE                            COMMAND                CREATED             STATUS              PORTS                         NAMES
a5139cf480ab        nginx:1                          "nginx -g 'daemon of   3 hours ago         Up 3 hours          443/tcp, 0.0.0.0:80->80/tcp   ecs-awseb-multiDockerTest-env-upq3tpm3fh-2-nginx-proxy-b0d1f6d898ddea93fa01   
c4acd0810b38        php:5-fpm                        "php-fpm"              3 hours ago         Up 3 hours          9000/tcp                      ecs-awseb-multiDockerTest-env-upq3tpm3fh-2-php-app-e684be8ba8d7d5bbd001       
b9ab2fda98d4        amazon/amazon-ecs-agent:latest   "/agent"               3 hours ago         Up 3 hours          127.0.0.1:51678->51678/tcp    ecs-agent

 
上記がそれぞれどういう役割なのか?という構成に関しては、以前一緒のチームでソリューションアーキテクトとして働いてて、
今はUSでサービスチームの一員として活躍している安川さん(@thekentiest)の、
昨年のAWS Black Belt Tech Webinarの記事が分かりやすくてよく紹介させていただいているのですが、
↓のような感じになっています。

 
デプロイされたものは/var/appの中に格納されています。

$ ls /var/app/current
Dockerrun.aws.json  cron.yaml  php-app  proxy
$ cd php-app/

index.phpを見てみると

<body id="sample">
  <div class="textColumn">
    <h1>Congratulations!</h1>
    <p>Your Docker Container is now running in Elastic Beanstalk on your own dedicated environment in the AWS Cloud.</p>
  </div>

  <div class="linksColumn">
    <h2>Video Tutorials</h2>
    <ul>

のようになっていて、悪ノリして↓こんなことすると、

 
hogehogeうぇーい的な感じになりました。

 
で、Multi-containerって事でECSにはTaskというメモリとかCPUの条件を決めたりする概念というか、
括りがあるのですが、言葉で説明するとアレですが絵にすると↓こんな感じです。
(Multicontainer Docker Environments に出てくる挿絵です)

こちらはまた別の機会に深堀りしていきたいと思います。
 
 
■ zipファイルを使ったデプロイ
 
上記のように直接SSHでサーバーに入ってファイルを書き直すというのは現実的ではないと思われますので、
ローカルで編集したものをElasticBeanstalkのマネージメントコンソールからデプロイしてみたいと思います。
 
現状動いているサンプルをダウンロードしてきたかったのですが、Elastic Beanstalkのコンソール上の
リンクを押してもリンクでドキュメントのページに飛ばされるだけで、2015年4月18日現在、Multi-containerの
サンプルのzipファイルが見当たらなかったので、、

 
実行環境上でtar.gzにして、、

$ sudo tar cvf current.tar.gz current/*
current/Dockerrun.aws.json
current/cron.yaml
current/php-app/
current/php-app/static.html
current/php-app/index.php
current/php-app/scheduled.php
current/proxy/
current/proxy/conf.d/
current/proxy/conf.d/default.conf

 
コレをS3に上げてから、ローカルにダウンロードしてもってきます。(なんとも古典的なw)

$ aws s3 cp current.tar.gz s3://justabucket2015
upload: ./current.tar.gz to s3://justabucket2015/current.tar.gz

 
ローカルでindex.phpファイルを一部書き換えて、

113     <li><a href="http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/index.html?concepts.html">AWS Elastic Beanstalk concepts</a></li>
114     <li>hogehoge</li>
115     <li>local_hogehoge</li>
116     </ul>

 
zipファイルに圧縮して、

$ zip -r deploy.zip .
  adding: cron.yaml (deflated 21%)
  adding: Dockerrun.aws.json (deflated 75%)
  adding: php-app/ (stored 0%)
  adding: php-app/index.php (deflated 60%)
  adding: php-app/scheduled.php (deflated 31%)
  adding: php-app/static.html (deflated 2%)
  adding: proxy/ (stored 0%)
  adding: proxy/conf.d/ (stored 0%)
  adding: proxy/conf.d/default.conf (deflated 45%)

 
マネージメントコンソールからデプロイすれば、

 
デプロイ出来ました。

 
但し、コレだと毎回zipファイル作らなければならないので大変面倒です…。
 
 
■ ebコマンドを使ったデプロイ
 
Elastic Beanstalkにはebというコマンドラインツールがあって、コレを使うと便利にデプロイ出来ます。
今までは2.6系が主流でgit aws.push〜とかっていうご案内をよくしていたのですが、
最近では↓に書かれているように3系に移行してきていて、少しコマンドの体系が変わってきてきますのでご注意ください
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-reference-eb.html
 
3系のebコマンドのインストールはpipで行います。
普通にやると $ sudo pip install awsebcli だけでよく、
サクッと↓のようにいくはずですが、

$ eb --version
EB CLI 3.2.2 (Python 2.7.8)

私の場合はpipが古かったのかupgradeとかしても上手くいかず、↓この辺のフォーラムにお世話になりました。
https://forums.aws.amazon.com/thread.jspa?threadID=164348&tstart=25
https://forums.aws.amazon.com/thread.jspa?messageID=580745
 
で、eb initを叩くと、既に構築されたElastic BeanstalkのApplicationが出てきて、
↓のように選択できます。

$ eb init

Select an application to use
1) mulcon
2) multi docker test
3) docker
4) [ Create new Application ]
(default is 4): 2

 
続いて、先ほどのdeploy.zipは削除してgit init .しておきます。
そうすると、.elasticbeanstalkと.gitと.gitignoreが出来ているかなと思います。

$ ls -la
total 24
drwxr-xr-x    9 eshinoha  1896053708    306  4 18 12:00 .
drwx------+ 585 eshinoha  1896053708  19890  4 18 11:17 ..
drwxr-xr-x    4 eshinoha  1896053708    136  4 18 12:00 .elasticbeanstalk
drwxr-xr-x   10 eshinoha  1896053708    340  4 18 11:21 .git
-rw-r--r--    1 eshinoha  1896053708    108  4 18 12:00 .gitignore
-rw-r--r--@   1 eshinoha  1896053708   1457  3 23 20:22 Dockerrun.aws.json
-rw-r--r--@   1 eshinoha  1896053708     90  3 23 20:22 cron.yaml
drwxr-xr-x@   5 eshinoha  1896053708    170  4 18 10:37 php-app
drwxr-xr-x@   3 eshinoha  1896053708    102  3 23 20:22 proxy

 
今回はまだEnvironmentを1つしか作っていませんが、実際に開発を進めていく中で、
Dev, Staging, Prodのような形になっていくのかなと思います。
その場合は↓のようにeb useというのを使ってどのEnvironment〜といったところを指定出来るようになります。

git checkout master
eb use prod
git checkout develop
eb use dev

 
では、さっそくローカルのgitに1行変更を入れてコミットしてタグを打ってみます。
ebコマンドを使ってデプロイする場合は、gitのタグをVersionのラベルに出来ます。
(上でzipをアップロードした時に付けたVersion labelの事です)

$ git add .
$ git commit -m "first commit"
$ vim php-app/index.php
114     <li>hogehoge</li>
115     <li>local_hogehoge</li>
116     <li>git_local_hogehoge</li>
117     </ul>
$ git add .
$ git commit -m "added git_local_hogehoge"
$ git tag -a v0.1 -m 'my version 0.1'

 
eb deploy コマンドでデプロイ用のアーカイブを作ってくれて、S3にアップロードしてくれて、
古いECSのTaskから新しいTaskへ〜という様子が見て取れます。
で、新しいVersionがデプロイされて、Environmentの更新が成功しましたよ、と。
(ECS用語とElastic Beanstalk用語をちゃんと抑えておかないと頭が混乱しそうなのでご注意ください…^^;)

$ eb deploy
Creating application version archive "v0_1".
Uploading multi docker test/v0_1.zip to S3. This may take a while.
Upload Complete.
INFO: Environment update is starting.                               
INFO: Deploying new version to instance(s).                         
INFO: Stopping ECS task arn:aws:ecs:ap-northeast-1:832164682569:task/4e859699-b267-4664-9b4d-9553dda03702.
INFO: ECS task: arn:aws:ecs:ap-northeast-1:832164682569:task/4e859699-b267-4664-9b4d-9553dda03702 is DEAD.
INFO: Starting new ECS task with awseb-multiDockerTest-env-upq3tpm3fh.
INFO: ECS task: arn:aws:ecs:ap-northeast-1:832164682569:task/3aac1d84-03b2-402c-a170-bd57772f7162 is RUNNING.
INFO: New application version was deployed to running EC2 instances.
INFO: Environment update completed successfully.  

 
でもって、S3のバケットは↓のようにアーカイブされたものが入っていました。

 
もちろんブラウザからも↓のように確認できました。

 
 
■ 複数インスタンスに対するebのdeploy
 
実際の業務では一日に何回もデプロイがされる可能性があって、その度にサービスをダウン
わけにはいかないものだと思います。
 
Elastic Beanstalkには”Batch”という名前で複数のEC2インスタンスやContainerにデプロイする仕掛けがあります。
詳細は↓に記載されておりますが、こちらを使ってやっていきたいと思います。
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html
 
まずは、AutoScalingの設定で複数のインスタンスになるようにします。

 
PHPに多少負荷がかかるように↓のようなコードを入れて、

118 <?
119   date_default_timezone_set('UTC');
120   echo date('l jS \of F Y h:i:s A');
121   for ($i = 1; $i <= 10000000; $i++) {
122     if ($i % 1000000 === 1) {
123       echo $i;
124     }
125   }
126 ?>

 
複数のターミナルの窓から↓こんな感じでトラフィックを流し続けるようにします。

$ for ((i=0;i<10000;i++)) ; do  curl http://multidockertest-env.elasticbeanstalk.com/ 2>&1 >/dev/null    ; done ;

 
分かりやすいようにBatchのタイプをFixedにして、必ず1台だけという設定にします。

 
上記のような状態で、4つのインスタンスが稼働している状態で、
eb deployしている間のELBの様子は以下のようになります。
 
1. 最初は4つ全てのインスタンスがELB配下にいます

 
2. 1つのインスタンスがELBから切り離されて3インスタンスになります。その間に裏でデプロイが行われます

 
3. 上記2. で切り離されたインスタンスが戻ってきます(Out Of Serviceなのはヘルスチェック中の為)

 
4. 再び別のインスタンスが切り離され、デプロイのプロセスに入ります

 
5. デプロイが終わったインスタンスは再びヘルスチェック後にELB配下に入ります

 
上記のような動きを繰り返して、1つ1つデプロイをしていくことで、サービスへの影響を最小限にします。
  
 
■ その他
 
・eb deployを使用した場合に.gitignoreの扱いについて
 
例えばeb deployでデプロイを行った時に .elasticbeanstalk の設定は持っていく必要が無いわけですが、
.gitignoreには以下の記載があります。

$ cat .gitignore 

# Elastic Beanstalk Files
.elasticbeanstalk/*
!.elasticbeanstalk/*.cfg.yml
!.elasticbeanstalk/*.global.yml

 
eb sshを使用して1つのインスタンスにSSHでログイン後、

$ eb ssh

Select an instance to ssh into
1) i-79ffa98a
2) i-64489991
3) i-cc489939
4) i-8ff4a27c
(default is 1): 1

 
叩いてみたら存在しなかったので、ebコマンドはちゃんと.gitignoreをチェックしてそうです。

[ec2-user@ip-172-31-11-114 ~]$ cd /var/app/current
[ec2-user@ip-172-31-11-114 current]$ ls -la
合計 28
drwxr-xr-x 4 root root 4096  4月 18 07:55 .
drwxr-xr-x 3 root root 4096  4月 18 07:55 ..
-rw-r--r-- 1 root root  108  4月 18 07:50 .gitignore
-rw-r--r-- 1 root root 1459  4月 18 07:50 Dockerrun.aws.json
-rw-r--r-- 1 root root   90  4月 18 07:50 cron.yaml
drwxr-xr-x 2 root root 4096  4月 18 07:50 php-app
drwxr-xr-x 3 root root 4096  4月 18 07:50 proxy

 
 
・hookを使ったデプロイのカスタマイズについて
 
↓は2013年の安川さんのWebinar資料ですが、ココにデプロイ前後のhookに関する記載があります。

 
通常、Elastic Beanstalkでプロビジョニングされる環境の構成変更は .ebextensions というディレクトリの中に
yamlファイルを配置してそこに記載しますが、デプロイの過程の中で、”ココ!”っていうタイミングで処理をしたい場合が
出てくることもあるかと思います。
 
例えばデプロイ前であればデフォルトでは↓のようにディレクトリ内をalphabeticalな順番で処理がされていきますが、
01unzip.sh で解凍された後に、、的な事をやろうとした場合に関して、
ディレクトリ内に01x_afterunzip.shみたいな名前で配置してやれば良い、と。

$ pwd
/opt/elasticbeanstalk/hooks/appdeploy/pre
[ec2-user@ip-172-31-11-114 pre]$ ls -l
合計 20
-rwxr-xr-x 1 root root  862  4月  8 17:29 00enable-eb-ecs.sh
-rwxr-xr-x 1 root root  842  3月 10 23:44 00stop-task.sh
-rwxr-xr-x 1 root root 2095  3月 13 00:52 01unzip.sh
-rwxr-xr-x 1 root root 2992  4月  8 17:29 02update-credentials.sh
-rwxr-xr-x 1 root root  782  3月 11 18:01 03start-task.sh

 
で、コレを1インスタンスずつ配置していたら日が暮れてしまうので、
.ebextensionsで〜的なやり方で行うと、よりBlack Beltな感じかなと思います。
 
こちらは、これまた安川さんがAWSのフォーラムに、Railsのアセットコンパイルを
事前に行ってS3に置いておいて、それをコピってくるだけで、デプロイの時間を短縮させましょう的な例を
(英語で)ガッツリ記載していますので↓を一読されるとよろしいかと思います。
Customizing ElasticBeanstalk deployment hooks(https://forums.aws.amazon.com/thread.jspa?threadID=137136)
 
.ebextensionsに関しては↓に記載されているように、細かく定義が出来て便利なのですが、
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html
あまりやり過ぎると後から辛い目に遭ったりする可能性もあるので、ご利用は計画的に。
(AWSにはOpsWorksというChefベースのプロビジョニング/デプロイサービスがございます)
 
 

Webエンジニアが知っておきたいインフラの基本
マイナビ (2014-12-27)
売り上げランキング: 649

I’ll be at AWS Pop-up Loft in San Francisco on April 6th and 8th


I lived in San Francisco in 2011. Yea, I really love SF. Next week, I’ll be there again on a business trip.
I’ll have sessions at AWS Pop-up Loft(located along Market Street. near Westlake) on April 6th(Mon) and April 8th(Wed).
If you are interested in AWS technology, Japanese Startup things, Amazon CloudSearch, and that kind of things please stop by :)
Look forward to meeting up with SF people!

Following are the details. You can check on Pop-up Loft site also => http://aws.amazon.com/start-ups/loft/

■ April 6th(Mon) 10am – 6pm Ask an Architect (Japanese)

Walk-in anytime between 10AM and 6PM for a 1:1, 60-minute session with a member of the AWS technical team fluent in Japanese. No appointment is necessary, but are available. Don’t be shy, we’re here to help with the AWS foundational questions and the highly technical ones tied to your specific use case. So, bring your questions about AWS architecture, cost optimization, services and features, and anything else AWS-related.
午前10時から午後6時の間に、いつでもお越しください。日本から来たAWS技術担当が1セッション60分間で個別にご相談にお応えします。ご予約いただく必要はございません。基礎的なご質問から、特定領域の高度なご相談まで承りますので、是非この機会に、アーキテクチャ、コスト削減、サービスや機能などAWSに関するご質問をお寄せください。

 
■ April 8th(Wed) 2pm – 3pm Japanese Search with Amazon CloudSearch and JP Startup Use-Cases

To dive into the Japanese market, Japanese-Search is pretty nice to have but not so easy to implement. Japanese language is different from space-separated languages like English, Spanish, French, and so on. In this session, you will learn how to build sophisticated Japanese-Search with Amazon CloudSearch. Bunch of Startups are using CloudSearch in Japan. You will see that Use-Cases.
Amazon CloudSearchを使って洗練された日本語検索を構築する方法をご紹介します。また、日本においては沢山のStartup企業にCloudSearchをご利用いただいており、そのユースケースもご紹介します。