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

[Report] IVS CTO Night & Day 2014 #CTONight


Infinity Ventures Summit(以下IVS)には過去3回スタッフとして
参加させていいただいておりますが、(その時のブログ 1回目 2回目 3回目)
 
今回はIVSと共催という形で、同じ期間中に近くの会場で、CTOを対象とした、
IVS CTO Night and Day powered by AWS』というカンファレンスを開催し、
全体の司会進行などを行わせていただきました。
 
※ 免責 こちらのエントリは私の個人的な振り返りであり、所属する会社とは関係ございません。

 
 
■ Day 1 『Welcome CTO Night! 』
 
CTOは企業の中で技術のトップということで、立食形式のパーティーで
どれだけ盛り上げることができるか、と考えていたのですが、
皆さまに時間より早くお集まりいただけて、ウェルカムドリンクの時間帯からとても良い雰囲気でした。
 
京都で開催なので、関西のCTOに乾杯のご発声を、ということで、
国内最大のAmazon CloudSearchユーザーであり先日AWSのページで事例が公開された
ChatWorkの山本CTOに行っていただきました。
 
事前に取らせていただいたCTO実態調査アンケートの結果発表は熱狂的な盛り上がりになりました。
(@keisuke69が考えた、かなりradicalなアンケートになりましたw)


 
LT大会は皆さん耳を傾けるというよりも、完全に前のめりで内容に聞き入っていました。
(LTというにしては内容が物凄く濃かったり、準備大変だっただろうなという発表の連続でした)
 1. Loco Partners古田さん「CTO体験記」
 2. レジュプレス和田さん「ビットコインの背景技術」
 3. ウェブペイ曾川さん「Hack a Lock(ICカード入退室管理をハッキングする話)」
 4. Capy島田さん「イスラエルのエンジニアとスタートアップ事情」
 5. 白ヤギコーポレーション柴田さん「PyData Tokyoはじまりました」
 6. メルカリ胡さん「フリマアプリNo.1のメルカリを支える技術」
 7. ADSJ清水「Lambda+KinesisでInternet of Things 〜 ど根性Tシャツ」


 
最後までずっと盛り上がって、CTO同士の横繋がり作りの場を出来てる感が凄いあって、
初日から、イベント開催して良かったなー!と胸熱でした。

 
 
 
■ Day 2 『Session & Workshop 』
 
2日目は2部構成。1部はCTOの皆さん&ADSJの技術メンバによるプレゼンテーションで、
2部は参加者によるアンカンファレンスもしくはハッカソン。
 
・開催のご挨拶
 
IVSを主催されている小林さん、ADSJ社長の長崎、AWSのスタートアップ・VC担当トップのBobに一言いただきました。
特に小林さんには、私個人に対しても、壇上でとてもあたたかいお言葉をいただき、ウルっときました。


  
 
・Keynoteスピーチ Keynote はてな CTO 田中慎司「CTO に求められるもの」
 
もちろん はてな は思い入れのあるサービスですが、それだけでなく、
10年来の友だちの @chris4403が、社長就任ということで、応援している会社ですが、
内容は、本当にココでしか聞けないというか、田中さん普段一緒に飲んだりしてると気さくな人ですが、
会場のCTOの皆さんに刺さりまくりの内容でした。


田中さんはプレゼン資料も公開してくださいました!


  
 
・Best Practices#1 nanapi CTO 和田修一「技術を選定する上で考えていること」
 
和田さんのブログ『UNIX的なアレ』は昔から大ファンで。
今でこそドットインストールとかあるけど、昔は会社のデスクトップに入れたUbuntuでUNIX的なアレに
書いてあることを写経した事も多かったです。
 
私は以前楽天に勤務していたのですが、実は同じ会社の人だったんだって知って衝撃を受けたのですが、
今回は和田さんに今までのnanapiを振り返りながら、技術選定、そして、どのように組織・風土を作ってきたか
というCTOの皆さんがズバリ聞きたい内容だったと思います。


 
資料を公開してくださいました↓

 
そして、振り返りブログも書いていただき↓
個人的にも、自分たちが開催したイベントが、『UNIX的なアレ』に取り上げてもらえたのはスッゲー嬉しい!
IVS CTO Night & Day 2014に参加してきた
 
 
・Deep Dive: AWS Update: ADSJ 大谷晋平
 
AWS Summit 2014 New York や AWS re:Invent 2014 でAWSの新サービスが沢山発表されました。
AWSはもの凄いスピードで様々なサービスが開発されているので、今回は1枠をそれをご説明する時間に
充てさせていただきました。資料が公開され次第、貼り付けさせていただきます。
 
 
・Best Practices#2 ChatWork 山本正喜「大失敗したサービスから学んだこと」
 
いつもお世話になっているChatWorkのCTO山本さん。
失敗談は自分から話したいものでもないし、こういった所でそれを惜しげも無くお話していただけたのは、
本当にありがたく、イベント全体として、ただのお祭りではなく、CTO同士の悩みや経験の共有の場なんだ
という雰囲気を醸成できたように感じます。
 
山本さんは12月6日に↓のschooの授業に出演された際も、こちらのイベントに触れてくださいました!
CTOの履歴書 ChatWork 山本正喜氏に聞く理想のエンジニア像
 


 
 
・Deep Dive: AWS Mobile Services ADSJ 西谷圭介
 
“まだEC2使ってるの?”といった挑発的な出だしから、AWSのモバイル系サービスを活用しながら2-Tierな
アーキテクチャの実現方法を紹介するセッション。
 
 
・Best Practices#3: クックパッド 舘野祐一「エンジニアからCTO へ」
 
いつも楽しみにしている Rebuild.fm というPodcastで舘野さんのお話は伺った事があって。
先日のTechCrunch TokyoのCTO Nightの後にご挨拶させていただいた際も、FreeeのCTOの横路さんたちと、
エンジニアの評価や育成についてアツい議論をされていて、是非その話題を京都で!といったお話をさせていただいたのですが、
こちらのセッションでは、ガチDeveloperだった舘野さんが、どのようにCTOになったのかというとにかく熱い話でした。
私も、20代の頃は、”一生現場でプログラマ”とか言ってたタイプだったので、本当に興味深くお話を伺わせていただきました。
いつやるんだとか、素振り重要とか、そして、理路整然とロジカルにビシバシ耳に入ってくる語り口調。とにかく刺さるお話でした。


 
 
・“Anti-Pattern” for Architecting ADSJ 星野豊
 
@con_mame のアンチパターン話。現場臭漂う彼だからこそ、システム開発・運用の現場にいるCTOの皆さんに
リアリティのある話が刺さったのではないかと思います。
 
 
・Technical Workshop(ハッカソン) / Management Workshop(アンカンファレンス)
 
私はアンカンファレンス側の取りまとめを行っていたので、レポートはそちらの方になってしまうのですが、
皆さんに沢山ネタをあげてもらって、そこからテーマを決めていって、

 
最終的に↓をCTO100人がそれぞれ興味のある話題に散らばってディスカッションって凄い事ですよね!

 
当初は、ちょっと不安でした。とにかく皆さんお忙しいので、各テーブルに散らばってからノートパソコン開いて
仕事はじめちゃうんじゃないかとか、、が、フタ開けてみたら、凄い盛り上がり。深く語り合っていただきました。
各テーブルを回らせていただきましたが、こんなところじゃ書けない話連発!
孤独なCTOがその悩みを打ち明けて、今後の方向性を見出そうとしているところなど、
“このカンファレンス開催出来て本当に良かった!!”と思えて胸熱でした。

 
 
■ Day 3 『Launch Pad』
 
IVSの目玉イベントであるLaunch Pad(http://www.infinityventures.com/ivs/launch/)。
私は今までステージ担当として、登壇される方のプレゼン機材のセッティングなど、
舞台の袖から痺れる大舞台をみてきました。
 
現場にいなきゃわからないビリビリした雰囲気。人生がかかった大一番。
コレをCTOの皆さんにも感じていただきたくて。
 
皆さん朝早くから会場に集まっていただいて、前の方の席にお座りいただいたことで、
Ustreamで後からみたら、審査員の後ろで黄色いストラップの皆さんが沢山映ってて、
ナイス!と思ったと共に、皆さんが後からLaunch Pad熱かったです!って言ってくださったのも
とても嬉しかったです。
 
今回のLaunch Padは前職のフットサル仲間(&今もたまに呼んでいただいてます)や、
お仕事で技術支援させていただいた企業が登壇したりと、とても楽しみにしていました。
が、唯一、もの凄く不満な事としては、私自身は外で受付やってたので現場でLaunch Pad見れてないっていう…(T_T)


 
 
■ Day 3 『Session & Panel Discussion』
 
・Deep Dive: Big Data on AWS: ADSJ 蒋逸峰
 
前職からの友人でサンフランシスコにいた頃は同じ家に済んでたYifeng(@uprush)による
Black BeltなBig Dataに関するセッション。ガチでテンコ盛りな内容の技術セッションになりました。
 
 
・CTO Q&A Session: ADSJ 西谷圭介
 
こちら、事前アンケートを元に、会場全体にいろんな質問を問いかけるセッション。
進行を担当した西谷は、かなり荒っぽかったですが、笑
例えば、”Dockerどうしてる?別に要らなくない?”的な質問に、
“ffmpeg+ImageMagickといったようなディストリビューションや環境に依存してしまうようなものには便利”といった、
非常にプラグマティックな回答があったり、やっぱりCTO凄いなと思わせる盛り上がりを見せました。
 
 
・CTO Discussion 1: モデレーター ADSJ 今井雄太
 
Freee横路さん、Vasily今村さん、Timers椎名さん、SpotLight高橋さん。
勢いあり過ぎなCTOの皆さん。日頃こういう方たちとお仕事をさせていただけてるわけですが、
インスパイヤされまくりで、お話伺いながら、イイ職業に転職したな〜なんて思ったりしました。笑


 
 
・CTO Discussion 2: モデレーター ADSJ 松尾康博
 
はてな田中さん、CrowdWorks大場さん、Bizreach竹内さん、BASE藤川さん。
経験豊富なCTOの皆さんと、元CTOなマッツォさん(昨年のグローバルでのAWS SA of the Year!)のパネル。
高い視点で、柔らかい口調の中にも、固い意志が感じられるようなお話の連続でした。


 
 
・CEOからCTOへ: モデレーター ADSJ 玉川憲
 
KLab真田さん、CrowdWorks吉田さん、nanapi古川さん。
このメンツで盛り上がらないわけないっしょ!っていう。
ビール飲みながら、凄い熱気で白熱したディスカッションになりました。

会場からの質疑応答も盛り上がり、IVSと共催でなければ有り得ない、このような場を作れたのは、
後から考えても凄い事だなと思います。このアレンジは事業開発の畑の真骨頂。


 
 
■ Day 3 『Farewell CTO Night!』
 
乾杯の音頭をはてなの田中さんとっていただき、開始と同時にもの凄い盛り上がり。
 
WebPayの曾川さんにTechnology Workshopの成果で
KMSの非常にプラグマティックな内容披露いただき、
(後から資料公開されると思いますが、要チェックです!)


 
篠原の方でManagement Workshopの様子をシェアさせていただいたり、


 
最後は全員で集合社員を撮って3日間の #CTONight 終了!燃え尽きました!
(新幹線等の時間の影響で最後まで残れなかった方が多かったので、撮影時間帯は次回改善します)

 
そして、参加していただいた皆さんからいただいたコメントとか、本当に宝物です!
今後ともよろしくお願い致します!

 
 

凄いWork Hardしましたが、開催期間中は本当にHave Funで、後から振り返ってみるとコリャMake Historyだな、と :)

 

2014年は #CTONight として、今回の『IVS CTO Night and Day』に加えて
AmazonのCTOである Werner Vogels を招いた『Startup CTO Night with Amazon CTO』、

 
TechCrunch Tokyo 2014において、日本の”CTO of the year”を決める
『TechCrunch Tokyo CTO Night powered by AWS』という、

 
3つの大きなイベントを開催しました。2015年もガンガン行きますので、引き続きご期待ください!
 

IVS CTO Night and Day 2014 #CTONight

EZさん(@shinodogg)が投稿した写真 –

Lucene/Solr Revolution 2014 at Washington DC


Lucidworks主催で、世界中から数百人の検索エンジニアが参加する、
Lucene/SolrのビッグイベントであるLucene/Solr Revolutionにいってきました。

 
 
■ Welcome Reception
 
会場はこんな感じのイカしたホテルのボールルーム。

 
各所にスポンサーブースがあって。こちらはA9。

 
Bloomberg。コンソール叩かせてもらったけど動きが凄い軽快でした。

 
ClouderaのブースではHueからSolrのクエリ叩くのとか見せてもらいました。
ブースのモニタに繋がってるヤツはイマイチなのでわざわざ自分のラップトップ出してくれましたw
Kibana的なUIで地図と連携とか出来たりして、かなりナイスな印象でした。
インデックスをHDFSでっていうアプローチ。検索もHadoopのビッグデータのエコシステムの中の1つに
なりつつあるのかな〜なんて、今回のカンファレンスではかなり感じました。
(業界的には機械学習とかその辺で差別化していかないとって感じですかね、、)

 
主催のLucidworksブース。検索業界狭いというか、遠く日本から来ても、xxさん知ってるよ的な。

 
Lucidworks Fusion見せてもらったけどイイ感じだったなぁ。

 
Basis Technologyのブースでもらったチラシには、昔関わったアレが載ってたりして、なんだか感慨深い。

 
たくさんの検索エンジニアとカジュアルに色んな話して、パーティーそのものとしては、
コレと言った催し物も無く、サーッと終わりましたw
 
軽くホテルのそばのヌードル屋でパッタイ食った後、深夜までホテルのバーで
A9やLucidworksの人たちと飲みながら、業界動向的な話をしました。
 
 
■ Day 1
 
・Breakfast

海外カンファレンスの楽しみは食事中に色んな人と話せることで。
朝っぱらからEvernoteやMicrosoftのイケてる検索エンジニア達と突っ込んだ話が出来ました。
Solr使わないでLuceneに薄い自分たち専用のHTTPなラッパーを作ってるとことか多いんだな、と。
東京から来たんだよって言うと、皆んな日本語の対応大変なんだよね的な。
CloudSearchにも日本独自に向けた設定とかイロイロ入ってるのでその辺の話とか。
 
 
・Opening
Keynoteの会場は大きい部屋にズラ~っと椅子が並んでるだけでなく、後ろの方は円卓になってたりして。

 
一番前の方の席に座って、まずはCTOのGrantから。この人の言葉には力がありますね。

 
スポンサーの紹介とか、

 
ハッシュタグは #LuceneSolrRev だよーなんてアナウンスがあったりしつつ、
たまにTweetをfavしてくれるCEOのWill Hayesさん。
にしても、このニッチなエリアで、スタートアップ的な会社がこんだけのカンファレンスやるってスゲーよな、と。

 
 
・Keynote

アメリカ合衆国の初代CTOのAneesh Chopraさん。http://en.wikipedia.org/wiki/Aneesh_Chopra
ガチの検索エンジニアのたちの前でするには、それどっかで聞いたことある的な話でしたが、
『Facebookが3000人くらいの規模の時に、その中でDeveloper何人?って聞いたら、
 シェリルから35000人って返事がかえってきて、API使ってるDeveloperがそんくらいいる』
っていうエピソードとか、たまにこういうの聞くと、最近全くコード書いてない自分としては、
ちょっと悶々としてきたりします。。
 
 
・Search at Twitter

いわゆるラムダアーキテクチャな感じ。
リアルタイムはストリームで、アーカイブはHDFS。Mesosで〜、とか。
ロック回避の工夫や断片化対策などハイレベルな話でスライドも充実してたので、
資料公開が楽しみです。
 
 
・Edanz Journal Selector(Case Study)

European Bioinformatics Instituteに在籍している中国の方によるユーザー事例セッション。
論文検索用のサーチエンジンというか、ポータルサイトにおいて、クロールして情報集めてきたり、
 
データプロセッシングにHadoop使ってたり、大規模感があって、かなりグローバルなAWS事例でした。
↓全世界のリージョン使いながら、日本の福岡にもオフィスがあるそうです。

 
 
・Semantic & Multilingual Strategies in Lucene/Solr

Solr in Actionの著者の人のセッション。
多言語を扱うのって大変で↓のようなアプローチがあるよねって話とか、
・それぞれの言語ごとにフィールド分ける
・検索ドメインを言語ごとに分けちゃう
・1つのフィールドで複数言語扱っちゃう(not yet in SolrだけどSolr in Actionの中で紹介されてる)
こういう話が聞きたかった!って感じでした。
 
 
・Lunch

お昼はセッション会場の後ろにあるテーブルで。よく仕事でやりとりしてるA9のTomとか、
政府系のシステム構築をやっているっていうKateさんという女性エンジニアと。
Kateさんは元Ruby Developer(シンタックスがビューティフルで大好きだって言ってました)、
元iOS Developer、現在は検索エンジニアということで。
とにかく話の引き出しが多く、色んなお話を聞かせてもらいましたが、オンプレで大きなデータを扱うと、
ちょっとした修正でも、環境を専有しなくてはいけなくて〜みたいな辛さがあったり、
(クラウドみたいに並行して環境立てて、検証して要らなくなったら捨てちゃうとかできない、とか、
毎日のようにFull GC避けるためにバランサからノードを切り離して再起動してる〜とか、、)
アメリカと言えど、まだクラウドへの以降には消極的なところも沢山あるとか。
あとはjpsでプロセス番号引き当てて、どうやってそのジョブキャンセルするかとか話ましたw
 
 
・Interactively Search and Visualize Your Big Data

ClouderaのRomain Rigauxさんのセッション。
“クラウデハ”って発音してたので、スペインとかブラジルとかの人ですかね〜。
内容はHUEの紹介セッション。WebのUIからSolrのクエリ叩けたり、
地図と連携したダッシュボード等かなりイケてる感じしました。
 
 
・Search Architecture at Evernote: Not Your Typical Big Data Problem

Evernoteの検索の話。一緒に朝飯食ったChristianさん。
冒頭にContextっていう新機能の紹介があったけど、確かに30分の講演で10分の説明は長かったかも…
↓こんなTweetが流れてたり、、


Solrは使わずLuceneとか、メタデータはMySQLに〜とか、興味深い話でしたが、
前に話した時に聞いた感じだから、新発見的なのはなかったな、と。。
Big Data会社じゃないから、ユーザーのデータを使って金稼ぎしようとは思ってない的な発言とか、
普段から使ってるEvernote好感度アップでした :)
 
 
・This Ain’t Your Parent’s Search Engine

この表題って某アレへのDisなのでしょうか?なんかそんなエピソード聞いたような気がするのですが、、
んま、相変わらず力強い口調でのプレゼンテーション。
検索エンジン的にはグルーピングとかピボットとかセクシーな機能出てきてるよねー
なんて話があってから、Lucidworks Fusionの紹介。
HUEとか、Lucidworks Fusionとか、Kibanaもそうだし、この界隈アツいですね。
 
 
・Stump the Chump at Cuba Libre Sponsored by A9
ホテルからバスでダウンタウンの方に移動して、

 
イカした雰囲気のレストラン貸し切り的な。

 
このイベントはA9がスポンサーしてるってことで、バーに設置されてるモニターがAWSだったり。

 
Solrのコミッター陣がオーディエンスからのキワドイ質問に答えまくるっていう催し物。
音響が微妙とか、英語早過ぎとか、内容deep過ぎとか、、って感じで雰囲気を楽しみましたw

 
会が終了後、チャイナタウンに行って、

 
Daikayaって店でラーメン食おうと思ったら満席で入れず、

 
中華料理屋でヌードル食って〆ました。

 
日本から参加した皆さんと〜

 
 
■ Day 2
 
・Breakfast

全米を渡り歩いて検索エンジンの導入コンサルやってる人とか、
現場でバリバリ検索エンジン使ってシステム構築やってるDeveloperとかと一緒に。
今回はCloudSearchパーカーをずっと着てたのですが、色んな人にAmazonで働いてるの?
って気軽に声かけてもらえて、服装重要だなぁと思ったりしました。
 
 
・SolrCloud at Apple: Automating and Scaling for Massive Multi-Tenancy

すっごい聴き応えのある話で、今回のカンファレンスの中で、個人的には一番アツかったです。
マルチテナントって観点だと、ほんとイロイロ大変だよね、と。
昔、色んなサービスから叩かれる広告配信プラットフォーム作ってた時は、
インフラ構成を柔軟に変更したり、データセンターをまたいだディザスタリカバリーとかって
ところまで手が出せなかったけど、いやー、さすがApple頑張ってんなーって印象。
AppleでSolr技術者募集してるらしいですが…
 
 
・Scaling SolrCloud to a Large Number of Collections

AWS使ってガッツリ使ってSolrCloudで負荷かけてやったぜ的なセッション。
検証終わったら、環境捨てられるからコスト低く抑えられてAWS最高!的なメッセージは
聞いててとても嬉しかったです。
 
 
・Never Stop Exploring: Pushing the Limits of Solr

Bloombergの人のセッション。NRT(Near Real Time)実現のために〜とか。
割りと早足で話が進み、どちらかと言うと会場とのコミュニケーション重視というか、
質問ある〜?的な感じ。
 
 
・CloudSearch, the Amazon Web Service on top of Solr

A9で働くSolrコミッターのTomas(from Argentina)。
かなり突っ込んだところまでCloudSearchの内部アーキテクチャを紹介したセッション。
 
Jackが作ったクエリパーサーをSolrにコントリビュート〜とかw

 
ハッシュタグ #LuceneSolrRev を付けてTweetしたら、色んな人にリツイートやFavしていただきました :)


こちらの内容は後から公開されますが、日本の皆さんにも分かりやすいようにスライドを作って
私の方でも勉強会等でシェアさせていただければと思っております。
 
 
・High Performance Solr and JVM Tuning Techniques Used in MapQuest’s Autocomplete Service

結構みんな頭抱えてる感があるJVMに関して、MapQuestっていうサービスのサジェスト機能における
チューニングの話。カスタムDoc Routingとかへぇ〜っていう。
JVMのパラメータとか、まんまデ~ンって資料に記載されてたので、資料公開楽しみですね。
そんなパラメータあるんだ?とか、参考になるところ多いかなと思います。
 
 
・Building a Large scale SEO/SEM Application with Apache Solr

なんかインターネットっぽいセッションタイトルだなーって思って、参加したのですが、
SEOやSEMの話はあんまり出てこなくて、どうやって集計やレポートを効率良く的な。
 
使ってるプロダクトとか、昔やってたのと近いかなぁと。

 
 
・Lunch

最初はオンラインゲーム作ってるディベロッパーとかと食ってて、
その後A9のメンバーとお互いの状況をイロイロアップデート。
こんな感じで月1くらいで情報収集できると、とてもナイスだなぁ。
 
 
・Visualize Solr Data with Banana

バンコク(って言ってたかな?)からきたAndrewさんによるBananaのセッション。
最初は個人的にやってたのがガッツリプロジェクトになった的な。
A port of Kibanaって事で、Solrユーザーには気になるところですね〜
 
 
・The LinkedIn Search Architecture

LinkedInの検索話。ここでもSolrは使わずLucene。
有名ドコロは割りとLuceneを直で使ってるところが多いなー、と。
リアルタイムはストリーム、全体のデータセットはHadoop。この構成多いですね。
C++で新しいエンジン作ってるって言ってたけど、そっちも今後楽しみ。
 
 
・10 Keys to Solr’s Future

Grantのセッション。LucidworksはSolrのMeetupだったら世界中どこでもピザとビールのスポンサーするぜ!とか、
コミュニティに対する情熱の高さも感じました。
 
こちらはスライド公開されてました↓

 
 
・Closing Remarks

ほんとありがとう!的な感じで簡素にカジュアルに〆て来る辺りが好感度高いというか。
この辺のイイ意味での営業っ気なさが、支持されてる理由だったりするのかな、と。
 
 
■ Smartphone App
 
今回doubledutch(http://doubledutch.me/)っていうカンファレンス用のスマホアプリ的なヤツで
スケジュールとか、会場地図とか、それみれば分かるようになっててとても便利でした。

 
フィードとか写真載っけたり、このアプリ上でコミュニケーション取れるのも良かったな〜

 
 
■ A9ブース
 
ちょこちょこお邪魔して、私もいろんな人とお話させていただきました。
マーケティングやセールスのメンバーだけでなく、
CloudSearchを実際に開発してるメンバーもブース対応してました。

 
 
■ DJ
 
イベント中に音楽かけてた彼のスピンはナイスでした!

 
 
■ グッズ
 
ブースまわって話聞くとグッズもらえたりしますが、
ミーハーな自分はこういうの大好きで…w

 
 
■ 2014年12月8日 第15回Solr勉強会 #SolrJP
 
こちらのカンファレンスの様子は、Solr勉強会でロンウイットの打田さんのレポートがセッションが
あるので、そちらでも詳しく内容をチェックできます。
お時間あれば是非→http://solr.doorkeeper.jp/events/16389
 
こちらの勉強会は私も登壇します〜(´▽`)ノ


 
 

来年も是非参加したいです〜!
 

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

Washington DC [Nov 2014]


出張でワシントンDCに行ってきました。
空き時間に軽く市内観光したので、その時のブログです。
 
■ 出発
 
成田から12時間半ロングフライトと言うことで、前日はジム行ってガッツリトレーニングして、
戦略的にギリギリまで準備をしないであまり寝ずに、
クタクタな状態で飛行機乗ってやろうと思っていたのですが、、
諸事情でアラームが鳴っておらず、思いきり寝坊してしまいました。。
11時5分のフライトで起きたら8時ちょっと過ぎっていうスリリングな状況で
最短で行けるのが東京駅からの成田エクスプレスっていうことで。
↓に乗って1時間前までに搭乗手続きを無事に済ませる事ができました…。
(やっぱり目覚ましはスマホとは別でアナログな感じでも確実なヤツがイイなと。。)

 
飛行機の中は結構ガッツリ寝てたのですが、映画2本見ました。
 
・Jersey Boys
郊外(神奈川県海老名市)出身の自分としてはニュージャージーって親近感湧くとこかも、とか。
やっぱり仲間が大事だやねぇ、と。クリントイーストウッドさすがイイ仕事しやすね。

 
・Raging bull
デ・ニーロまじハンパねーわー。んま、上記のジャージー・ボーイズに続き、
あんまりイイ話なわけじゃないんだけど、痩せたり太ったり大変だっただろうなと。。

 
IADに到着後、乗り継ぎ便な人と、DCが最終目的地な人で乗るバスが分かれて、

 
無事に送り届けてくれて、ありがとうございました〜的な感じ。

 
空港からホテルまではSuperShuttleってヤツで$29。

 
いわゆる乗り合いのシャトルバスでございやす。

 
小一時間でホテルについてから、チェックインまで時間があったので、
荷物を預かってもらいつつ、ワシントンDCの中心部に向かいます。

 
 
■ ワシントンDC
 
地下鉄のWoodley Park Zooって駅から3駅のMetro Centerってとこまで。
ホテルから駅向かうまでにやけにテキーラのショットが安い店あったけど…w

 
若干切符買う自動販売機の難易度高いと思うんだけど、こういうのもカード決済できちゃうのは楽チン。
#今回は一度も小銭を触ることありませんでした。

 
Metro Centerの駅出たら、なんかデカイのあるなと思って行ってみると、

 
Department of the Treasuryって書いてあったので、財務省っぽいですね。
この辺はこういうのがイッパイありましたが、スーツ着てる人より、ジョギングしてる人の方が全然多かったです。
#霞ヶ関にいる官僚っぽい人は全然見かけませんでした。。

 
とにかく日差しが強くて、逆光だと写真撮るのキツイ的な。
朝晩はすっごい寒いのですが、日中日差しが強いと半袖でもOKなくらいな陽気。

 
ホントにそこら中にこんなのがたってます。

 
ホワイトハウス周辺は怪しそうな宗教団体的な人や、Policeや、観光客や、、
って感じで、あんまりナイスな雰囲気でもなかったかな。。

 
ホワイトハウスの隣はなんちゃらExective Officeってヤツ。

 
フォトジェニックな場所でございやす。

 
上記とは反対側からみたホワイトハウスはナイスな感じでした。

 
そのまま歩いてワシントンモニュメントへ。
ちょうどこの日はThe Concert for Valorって無料のフェスがやってて、
辿り着くのに手荷物検査とかあって大変でした。。

 
テクテク歩いてリンカーンメモリアルへ。
#途中に第二次世界大戦とか朝鮮戦争とかベトナム戦争とかの記念碑的なのあったけど、
#当たり前ですが、ガチなアメリカマンセー的な感じで、なんかちょっとな、と。。

 
お約束な感じで。

 
ココから見たワシントンモニュメントはビューティフォーでした。

 
この辺一体の公園は掃除も行き届いてて、紅葉もキレイで、良いところでした。

 
ナショナル・モールの方に戻ってきて、

 
チョロっとフェス見つつ、
#夜はメタリカやエミネムが出演するってことだったのですが、そこまでは居られないので。。

 
National Museum of Natural Historyは小学生の遠足向け的なとこでした、、

 
フードコートで食ったメシは美味かったけど、、

 
National Museum of American Historyはチョイチョイ見応えあったかな〜

 
歴代大統領とか。

 
National Air and Space Museumは、シアトルにあるそれっぽいヤツの方が
全然凄いなって思うけど、そこそこ楽しめました。

 
Airbus320の操縦席とか。

 
個人的に一番楽しめたのはココ。American Art Museum and National Portrait Gallery。

 
各階が半分づつ美術展と肖像画展になってる。ゴージャスな展示物とかありつつ、

 
トラディショナルな肖像画とかから、

 
スヌーピーとか、

 
フランク・シナトラとか、

 
どっかで見たことのある、、

 
LL Cool J(Ladies Love Cool James)じゃないすか、と。Hard as Hellなとこで2枚使いされまくる彼です。

 
ちょっと話題が逸れましたが、中庭的なフードコートもナイスでした。

 
その他、とにかくジョギングしてる人が多かった印象で、街なかでもこんなお店とか。

 
後はカソリック系の教会とか。
中入ったら、そういう人を救済する為の目的もあるんだよな的な人が居たり…。

 
 
■ Rock Creek Park Trails
 
ホテルの周りを散歩してたら、とても良いところでした。

 
紅葉キレイだし。

 
東京だと市内の中心から地下鉄で3つ目の駅にあんまこういうとこないかな、と。

 
久しぶりにイイ空気吸った感。

 
隣に川が流れてるのもイイ雰囲気。

 
走ってる人や犬の散歩してる人も多かったです。

 
こんなとこ近所にあったら毎日でもきたい。

 
写真撮るの好きな人にもイイんじゃないかなぁ。

 
トレイルの入り口はこんな感じのとこ。

 
 

B08 地球の歩き方 ワシントンDC 2013~2014
ダイヤモンド社
売り上げランキング: 60,992