[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をご利用いただいており、そのユースケースもご紹介します。


 

 

Developers.IO 2015( #cmdevio2015 )で◯◯ウォッチをかっさらってきました!


お仕事でも、AWSに関わるエンジニアとしても、いつもお世話になっているクラスメソッドさんのイベント、Developers.IO 2015に参加させていただきました。
 
私のセッション Japanese Startup Use-Cases and Tech Deep Dive に関しては、後ほど資料をSlideShareに上げますし、クラスメソッドさんにブログレポートをしていただけるとのことなので、割愛させて頂いて、、
 
懇親会の抽選会で某ウォッチをいただきましたので、レポートさせていただきます。
 
抽選会では、すごい数の、魅力的な書籍、Tシャツ、ボイスレコーダー、ソフトウェア等のプレゼントがあり、
なかなか当選せず、ひたすらテンションを溜め込んでいたのですが、、
 
最後の最後、クラスメソッドさんからの◯◯ウォッチプレゼント!なところで、なんと当選!!
 
4名が当選し、Appleウォッチ争奪的な戦いになりました!
 
右から2番目が私です。

 
で、頂いたものがこちら!
 
Apple Watchではなく、、、
HUDSON SHOOTING WATCH!! いや〜、ガキの頃、ひたすらやりましたやねぇ〜(*´∀`*)
 

 
アマゾンデータサービスジャパンのAWSソリューションアーキテクトチームでプレイしておりますが、
2015年3月30日現在、 @imai_factory 118 が最高記録となっております。

 
年齢が若い方が体力的にも有利なのかと考え、 @con_mame に挑戦してもらいました。が、あんまりパッとしませんでしたw

#HUDSON shooting watch!! @con_mame worked hard! had fun! but didn't make history 😛

AZさん(@shinodogg)が投稿した動画 –


 
こちら、今後もチームビルディングに活用させていただきます!!ありがとうございました(´▽`)ノ
 
イベント自体も非常にハイレベルな内容で興味深く、運営されているクラスメソッドの皆さんのホスピタリティ溢れるものでした。
今後も是非参加させていただければと思いますので、引き続きよろしくお願い致します!
 

シューティングウォッチ
ハドソン (2008-12-18)
売り上げランキング: 11,968

Amazon CloudSearch の Dynamic Fields を使ってみる


ちょうど去年の今頃にApache Solrの copyField と dynamicField についてブログを書きました↓
SolrのcopyFieldとdynamicFieldを使いこなす | shinodogg.com
 
Amazon CloudSearchにおいては、Solr の copyField に該当する Source Field という機能があるので
そちらが使えますが、今まで dynamicField に該当する機能がありませんでした。

 
この度、米国時間の12月22日の↓の発表で、Amazon CloudSearchでDynamic Fieldsが使えるようになったと。
Lean and Flexible Configuration with Dynamic Fields
 
詳しくは↓こちらのドキュメントをご覧くださいね、と。。
Using Dynamic Fields in Amazon CloudSearch
 
 
では、さっそく試してみましょう。
 
■ お知らせ系の3つの情報があったとします
 

 
ファシリティ系、飲み会系、イベント系。
こういうのってドンドン検索対象フィールドが増えていったりしますよね。
その都度、スキーマ定義変えて〜ってワーキャーやってくのって大変です。
 
 
■ スキーマ定義
 
今回はフィールドを1つだけ。 *_txt という名前で定義してみます。

 
 
■ インデクシング
 
マネージメントコンソールからCSVファイルをアップロードします。

 
そんなフィールド無いよって言われますが、ココは無視してそのまま突っ込みます。
(この辺のユーザービリティは改善の余地がありそうカモですね)

 
突き進みます。

 
無事にインデクシング出来た旨、表示されればOKです。
今回は上記3ファイルを全てアップロードします。
 
 
■ 検索
 
ドキュメントにも書いてありますが、検索の際には、インデクシングした時のフィールド名を指定する必要があります。
今回は foo_txt, bar_txt, buz_txt です。フィールド名を *_txt とかって検索してもヒットはしません。
 
↓こんな感じになりました。

・foo_txt

 
・bar_txt

 
・buz_txt

 
 

こちらの機能は日本のお客様からも沢山ご要望をいただいていたものになりますし、
あんなことやこんなことに使えるのでは?と考えている方も多いのではないかと思います。
 
2014年にAmazon CloudSearchはLucene/Solrベースに置き換わり、様々な機能追加を行ってきました。
内部の挙動についても↓の資料などで公開しておりますし、2015年もガンガン攻めていきますのでよろしくお願いします!

– 
免責
本投稿は2014年12月23日時点の公開情報に基づいて個人でまとめたものであり、
所属する企業や団体における公式見解ならびに公式発表ではございません。
 

[改訂新版] Apache Solr入門 ~オープンソース全文検索エンジン (Software Design plus)
大谷 純 阿部 慎一朗 大須賀 稔 北野 太郎 鈴木 教嗣 平賀 一昭
技術評論社
売り上げランキング: 134,263