何気にこういうの大好きですが、私の場合は「そのうち考えるのをやめた」状態になりそうです。私が勝手に汲み取った感じでは、ビックデータは流れを見るもので、データ間のインスピレーションの欠片を見つけたら、イマジネーションを膨らませてロジカルに落とし込む。アジャイル的にガンガン回すべし。AWSで初期投資少ない。すいません(/ω\)運用の大事なポイントとしては、大量のデータが集まってくるので、データ品質を保つためにDWHへの集約と徹底が必要になりそうです。時にはETLも視野に入れると良い。ビッグデータとはいえ不必要なデータと判断したら捨てるのも大事との事。大量のデータを捌き始めると機械学習が顔を出してくる様です。Learningで自動でタグを付けるかっちょいいなー。技術的な注目としてAmazon.com(小売)のRedshiftの紹介がありました。記載して良いのかわからないのでこちらは割愛させて頂きます。他にも分析手法とか事例とか強いツールの紹介とかAMLについてとか素晴らしい講演がありましたです。なんとなく全体像が見えたのでちょっと色々実験してみようと思います。それにしてもクラウドやIoTの躍進により、色々な業界が近しくなった事を実感した1日でした。Beanstalk2015年7月23日ハンズラボPocketこんにちは、井上です。リプレイスを行いましたのでその紹介をしたいと思います。ハンズネットはシステム構成として、ざっくりとフロントのWEBアプリケーション・サーバーとバックエンドのAPIサーバーにより構成されています。バックエンドのAPIサーバーについては、2014年の4月頃からBeanstalk/PHPに順次置き換える作業を進めており、DynamoDBとBeanstalkによるオートスケールの効果もありそこそこ負荷に耐えられるようになってきたのですが、それに伴いフロントエンドの部分がスケールしないことがボトルネックになってきていました。TVの放送時などの突発的なアクセス増の際には、手動によるスケールには限界があり、ヒルナンデスや、マツコの知らない世界などの特集でハンズの商品が紹介されると、サーバーに接続しづらい状況になることが度々ありました。オートスケール化の一番のポイントは、サーバー自体に状態を持たないようにするという部分だと思うのですが、以前よりWEBアプリケーション・サーバーとAPIサーバーが分離されていたため、その部分では大きな障壁なく進める事が出来ました。一部、特集コンテンツのようなものや、画像、CSSなど、サーバー内で保持しているデータがあったため、まずはそれらをCloudFront経由での配信に切り替え、第2段階としてBeanstalkに乗せる作業を行いました。今回この作業によりフロントエンドの部分もオートスケールに対応したため、スパイクアクセスで接続しにくくなる状況は改善されるのではと思っています。Dockerについては、本番環境に投入して間もないことから、運用上どういう問題が発生するかまだ未知数な部分がありますが、何かありましたら、こちらで報告させていただきます。今のところ、レスポンスタイムも切り替え前と変わらず、安定して稼働しています。1点困ったのが、ルートドメインとBeanstalkの相性の悪さです。いったドメインを指定することができません。URLなどの機能があってもそれを使う事はできず、AliasレコードとしてBeanstalkの生成するELBを指定するという形になってしまっています。EnvironmetするとELBが変わってしまうのでうかつに行えません。何か良い方法などありましたら教えて頂けると嬉しいです。ハンズがなぜサーバー負荷対策を必死こいてやってるかというと、毎年8月末に、ハンズメッセという大バーゲンがあるのも要因のひとつです。