Developers.IO 2015 Developer Day

お話を聞きに行ってきました。

【クラスメソッドのAWSドッグフーディング】

クラスメソッドメンバーポータル(CMP)という、社内のプロダクトについての話です。

スライドは
http://www.slideshare.net/daisuke_m/20150329-developersio-2015-c1-aws

■役割

• メンバーズのお客様向けポータル


• 社内向け業務システム


• AWS実験場

■CMPのテーマ

• 完全AWSネイティブ


• Java8+SpringFramework


• single command deployとシステムポータビリティ


• APIファースト

●完全AWSネイティブ

• AWSの哲学・推奨に従う


• 実装の都合を一方的に押し付けない
  
  
  
  • アプリとインフラで戦わない。都度最適解を追求する
  
  
  
  


• AWSに寄り添う

• SSKD
  small set of known developer
  ごく一部だけで使う、最適化されていないAPI

• LSUD
  large set of unknown developer
  万人向けのAPI

現状のWebサーバは混在してるので、SSKDはシュリンクしていきたい

• aws-sqsd
  
  
  
  • SQSへのポーリングを行うデーモン。WorkerはHTTPサーバとして実装しておき、sqsdからキューをPOSTする。
  
  
  • エラー時はなにもしないことで、SQSの方で勝手にキュー復活する。
  
  

• ジョブスケジューラ
  遅延処理や定時処理
  
  
  
  • 処理の開始とトリガがHTTPリクエストではない。
  
  

無いので作ったBrian！
https://github.com/classmethod-aws/brian

• Detailed Billing ReportのCSVが1年後には１日数十GB＊数回…
  
  
  
  • よろしい、ならばEMRだ。Brianと組み合わせて取り込みジョブと集計ジョブを登録
  
  

• CloudWatch-Alarm TIPS
  
  
  
  • RDSのFreeStorageSpace。ディスクが有限であるかぎり、DiskFullのリスクは消えない。
  
  
  • SQSのNumberOfMessagesPublished。Brianを利用する場合、メッセージがないのはおかしい。
  
  
  • SQSのApproximateNumberOfMessagesVisible。たまるということはWorkerのバグかキャパ不足。
  
  

• CloudFormationTIPS
  
  
  
  • EnvironmentTypeパラメータ。local,development,productionでMulti-AZの有無、ストレージサイズなどを制御
  
  

●Java8+Spring Framework

• プロジェクト構成
  
  
  
  • api
  
  
  • batch
  
  
  • worker
  
  
  • webapi
  
  
  • webclient
  
  
  • website
  
  

• DomainDrivenDesign
  
  
  
  • Ubiquitous Language ぐらいは覚えとけ。
  
  

• Spring Data
  
  
  
  • DDDのリポジトリパターンの実装フレームワーク
  
  
  • RDB用にはJPA実装。
  
  
  • MirageSQLを好みで採用。
  
  

• 最近のJavaフレームワーク
  
  
  
  • PlayFramework
  
  
  • Dropwizard
  
  
  • Ninja framework
  
  
  • Spring Boot
    全部、アプリケーションサーバ不要。
  
  

ということは…

• １プロセスのための環境　～Docker
  
  
  
  • 最近のJavaフレームワークはDockerと相性がよい。
  
  
  • ElasticBeanstalkもDockerをサポート
  
  

• Beanstalk Appliation Bundle
  
  
  
  • アプリケーション一式を含むZIPファイル
  
  

• SQSとSprignBatch
  
  
  
  • キューはタイミングの問題で複数回送信されることがあるので、メール送信のべき等性が難しい。
  
  
  • SpringBatchは同じIDで複数回実行できないので、ピタリとはまった。
  
  

●single command deployとシステムポータビリティ

• Gradleでやってます。

• Flyway～DBの進化的設計
  
  
  
  • スキーマにもバージョンを付与
  
  

• gradle-aws-plugin
  
  
  
  • GradleからAWSリソースを操作したい。
  
  
  • 無いから作った！
    https://github.com/classmethod-aws/gradle-aws-plugin
  
  

• システムポータビリティ
  
  
  
  • ビルドとデプロイの自動化
  
  
  • 自動化しない部分はポエム（文書）を書く
  
  
  • つまり、システムのすべてが記述されている！ ←これ大事。
  
  

• AWSにおけるシステムポータビリティ
  
  
  
  • １つのアカウント内に複数の環境を構築できる。→本番／開発
  
  
  • あらゆるAWSアカウントに環境を構築できる。→例えば個人環境、SANDBOX環境
  
  
  • あらゆるリージョンに環境を構築できる、といいね。
  
  

●APIファースト

• すべての機能はAPIを介して提供

• HATEOAS
  
  
  
  • hypermedia as the engine of application state
  
  
  • 要するに、HTMLってインデックスがあって、そこからリンクをたどって参照するよね？JSONにも必要じゃないの？、という考え。人間にもやさしい。
  
  

• Spring HATEOAS
  
  
  
  • SpringMVCの拡張
  
  

• HAL
  
  
  
  • Hypertext Application Language
  
  

• LSUDs向けAPIの問題点
  
  
  
  • １ページ表示に必要なAPIコール数が増える
  
  
  • embedded resourceを活用することで、関連オブジェクトをいっしょに返すことも可能
  
  

• REST without PUT
  
  
  
  • リソース自身の削除、アップデートなんて存在しない、という振りきった考え。
  
  

• APIドキュメント
  
  
  
  • Swagger使え。Swagger Spring MVC使え。
  
  

試してみたいです。

• APIファーストの結果、スタッフにCMP-API,SwaggerUI、aurlを配布したら
  
  
  
  • 恐ろしい勢いで業務効率化ハックが始まった。
  
  
  • HATEOASなどのおかげで、みんな自然にAPIを理解して使ってくれてる。
  
  
  • 初歩的な質問が来なくなった。
  
  

【Zombie Web - 倒れないWebシステム ～AWSでAuto-Defense～】

• みんな大好きWordPress
  
  
  
  • 使う方も攻撃する方も
  
  

• 攻撃は
  
  
  
  • 管理ページへの不正ログイン
    デザイナーなどが使うことが多いのでIP制限などしていない場合が多い。
  
  
  • プラグインを中心とした脆弱性を悪用した不正侵入。
  
  

• 見た目の変わらない改竄が怖い。
  
  
  
  • バックエンドでウイルス配布サイトと通信してるのに気づかない
  
  
  
  


• 2014年の不正送金は29億円。2013年の２倍。

• サイト停止後はどうする？
  
  
  
  • ログがなくて調査てきない、いつから仕込まれていたかわからない。
  
  
  • 結局、OSから入れ直し。
  
  
  • 復旧まで時間がかかってビジネス止まってない？
  
  
  • 捨ててやりなおしたら？
  
  

ということで

●AWSを使って自動復旧・防御

• webshellによるハックの実践。
  
  
  
  • 改善検知イベントで、health_check.htmlをmvさせてELBから外すとか、原始的な仕組みだった。
  
  

• やっぱり、キモになるのは攻撃検知。
  
  
  
  • バックドアへのアクセス検知だけではすり抜けるので、ファイル改竄なども含めた複数箇所でのトラップが必要。
  
  
  • Firewall、IDS/IPS、ウイルス対策、変更検知
  
  

【アプリケーションコンテナとAWSの話】
ElasticBeanstalk 押しの話。

• 従来のアプリコンテナの課題
  
  
  
  • 対応するランタイムしか利用できない
  
  
  • モジュールやプログラムの追加に制限がある
  
  

• Dockerとは？
  
  
  
  • OSSのアプリコンテナエンジンとその周辺サービス
  
  
  • 実体はchroot&Cgroups+UnionFS+NAT Networking
  
  

• メリット
  
  
  
  • ランタイムがコンテナに同梱される。ただしサイズは大きくなる
  
  
  • ポータビリティが高い
  
  
  • コンテナ／アプリの起動が早い
  
  

■AWSでDockerを実行する３つのサービス

• EC2


• EC2 Container Service(ECS)


• Elastic Beanstalk(EB)

●Docker on EC2

• yumで入れてください


• コンテナ管理ソフトが必要。
  
  
  
  • CoreOS+Fleet、Kubernetes、Docker Swarm
  
  

●EC2 Container Service

• Dockerクラスタ管理をサービスとして提供


• 操作はAWS CLIから。GUIはまだない。


• まだプレビュー。


• スケジューラ、ELBとの連携、GUIは今後追加予定

●Elastic Beanstalk

• PaaSのように、Git拡張、Eclipse連携でAWS環境にデプロイできる


• EC2インスタンスの他、ELB+AutoScaling+RDSもまとめて作ってくれる


• 昨年４月にDockerサポート


• Dockerによって、EBのランタイムが一気に増える契機になった。


• 長らく、１インスタンス１コンテナという制限があったが、３日前(3/26)にマルチコンテナに対応した。


• BeanstalkインスタンスでECSエージェントを実行、コンテナ管理部分をECSが担当。
  
  
  
  • ECSが動いてるので、申請が必要。東京リージョンでは選択不可
  
  

●EB Dockerのマルチコンテナ対応

• AutoScalingでも、１インスタンスごとのコンテナ構成は全インスタンス共通


• 現時点でEB CLI 3.xは非対応

●Dockerクラスタ vs EB Docker

• EC2の課金体系にマッチするのはEB Docker
  
  
  
  • Dockerクラスタは実行コンテナ数によらず、EC2インスタンスのタイプ／数で課金される
  
  
  
  


• リソース管理コストもEB Dockerの方が楽。

• Dockerクラスタが向くのは…
  
  
  
  • マルチテナント展開など、コンテナ自体を細かく管理
  
  
  • コンテナの起動スピード
  
  
  • サービサー向け
  
  

のような要件

●まとめ

• Elastic Beanstalk Docker いい！
  ただし、
  
  
  
  • 一般的なDockerクラスタモデルとは違う
  
  
  • AWSの特徴にマッチした形態になっていて、開発者向け。
  
  

JAWS DAYS 2015

【AWSクラウドを支えるアーキテクチャと技術】

・AWSのサービスはITアーキテクチャにおけるビルディングブロック

●リージョン
・11ヶ所存在
・冗長化されたトランジットセンター
・AZ間では1～2ms

●AZ
・28個存在
・全リージョンは２つ以上のAZ
・各AZは1つ以上のDCで成り立つ
　→同一DCに複数のAZが入ることはない
・マルチAZはAWSのコアコンセプトの１つ

●データセンター
・単一DCで50000～80000台のサーバ
・単一DCで最大102Tbpsのトラフィック
・AWSカスタムNW機器
　→カスタムのネットワークプロトコルスタック

●ラック／サーバ／NIC
・SR-IOVをサポートしたNICを利用
・最初のネットワークホップの全トラフィックは仮想化
・AWSカスタムサーバとストレージ
　クラウドに特化したサーバデザイン
　Intelプロセッサを商用で利用可能なクロック以上にカスタム

★デベロッパーから見たAWSのイノベーション再考
●Larger EBS
16TB,20000IOPS
よりシンプルに、より使いやすく
・今まで持ってこれなかったワークロードが移行可能になった

●EC2 AutoRecovery
自動復旧可能なので、より手離れのよいインフラに

●RDSマルチアベイラビリティゾーン
2014年では、40%がMulti-AZで使用されている

●Amazon Cognito
モバイルデベロッパーの難しいところを全部取り除く
・認証情報の取り扱い
・デバイス間の動機
・プッシュ通知

●Aurora
・MySQLベースで使い勝手は変わらず
・RDBMSの運用負担をより大幅に減らす
・プレビュー中でイノベーション真っ最中
　→今すぐ使える/使えないの判断はやめて。長い目で見てください。

●2lemetry
IoTの会社を買収しました。

★AWSを支える技術
AWSをプログラマ的に効率よく使う技術

●プログラマブルなプラットフォームとしてのAWS
・AWSはプログラマブルなプラットフォーム
・プログラマ的にうまく使うための要素技術

●AWSを支える技術：非同期API
・多くのユーザから送られてくるリクエストを公平に効率よく処理したい
・ユーザ側の利点
　→アプリケーションがブロックされず、処理が継続できる
・サーバ側の利点
　→スケーラブルかつ高可用なバックエンド

EC2での非同期API
→インスタンスIDは即座に返されるが、起動はあとから。

●べき等性
ある処理を何度やっても同じ結果が返ってくる
・べき等性のあるなしで、システムのしなやかさは決まる
例’EC2起動インスタンス

●一貫性
理想的な一貫性

・結果整合性
→データが更新されたらすぐに反映されてほしい
→複数サーバではやはり難しい
→データを複製し、複数のストレージに保持
→全体に行き渡ってから更新を反映

・強一貫性
→アップデートが即座に反映され、そのあとの読み込みから更新を読み込むことが可能。

AWSでは結果整合性と強一貫性を使い分ける

公式blog、ソリューションアーキテクトblog、パートナーSAblogの他、Qiitaにも書いてます！

★最後に
・ビルディングブロックをよりよく使うために

SAが主催する、JAWS-UG目黒を設立準備中！
・JAWS-UG東京の支部
・テーマ毎で技術の追求
・いっしょに運営されるかた募集中

【MMORPG on AWS】
・膨大な数のメッセージハンドリング
・ゲームサーバーのロードバランス
・サーバ間のデータ同期をいかに減らすか
・大量のIOをいかに低いレイテンシでさばくか

●メッセージハンドリング
EC2はマルチキャスト／ブロードキャストをサポートしていない。
ZeroMQを使ってみました。

●ロードバランス
経験値、アイテムドロップの効率のよいエリアにはユーザが偏るなどホットスポットの問題がある。
動的にエリアを分割＝サーバを追加して負荷を下げていきます。

●データ同期の最少化
植物、動物、プレイヤーがオーバーラップしたエリアだけを同期してレンダリングしていきます。
オーバーラップ時に相手サーバに射影、攻撃などはRPCで元のサーバに戻します。

●低レイテンシで大量のIO
DBのアクセスを非同期化
MMORPGではJOINするようなデータはあまりないので、DynamoDBがおすすめです。
検索ではelasticsearchを使用しました。

まとめ
・SPOFを避けて高可用性を実現するためには分散アーキテクチャが重要
・あらゆる場所のレイテンシを考慮する。お客様はAZ間のレイテンシも計測している。
・N:Nメッセージングを実現するためのPubSubモデル
・EC2のエンハンスドネットワーキングはとても優秀
・NoSQLの検索の組み合わせーDynamoDBはとても優秀！
・データ同期の平均所要時間を縮めるために非同期IOを利用する。
・分散環境においてゲームキャラクター同士のインタラクションを実現するためにRPCを利用する

【モバイルファースト時代のクラウドネイティブアーキテクチャ】
・小さく産んで大きく育てるための設計をおろそかにしない
・AmazonSNSを使うと配信を早くできる
・ただし配信が早く終わると、瞬間的なリクエストが増える
・一気に負荷がかかるため、AutoScalingでは対応できない

●一斉アクセス対策
・配信量のコントロール
・サービスの対策
　あらかじめスケールアウト
　RDSを読み取りインスタンスで用意
　静的コンテンツならS3で。

Push配信を制するものがモバイルアプリを制する

●モバイルアプリで考えておくこと
モバイル用のAPIを作るべき
・何度も異なるAPIを呼ぶのは非効率
・画面表示までに時間がかかる
・ユーザ体験が悪い
・API毎にエラーハンドリングなどを考えなきゃダメ。

「1Screen, 1API call」

この本がオススメです。
O'Reilly
Web API: The Good Parts
http://www.oreilly.co.jp/books/9784873116860/

●クラウドネイティブ
アマゾンCTOヴォーゲルズの言葉
「AWSのすべての機能やツールには、存在している理由がある」

21世紀的なアプリケーション開発のあり方
http://www.atmarkit.co.jp/ait/articles/1212/03/news125.html

AWSを利用し、サービス全体を考える
・サーバーはダウンするという前提
・急なリクエストが発生するという前提
・定期的なシステムメンテナンスが発生するという前提
・ユーザ数が増えてもコストが激増しないように
という設計をする必要がある。

●AWS MobileSDK
モバイルから直接使えるAWSサービス
・Cognito,DynamoDB,S3,SNS,Mobile Analytucs,Kinesis,SQS

2Tier Archtecture
・クライアントとバックエンド
・クライアントに処理を持つ
・クライアントからAWSのサービスを利用する

2Tierのいいところ
・フルマネージドのサービスに直接アクセス
・サーバーレス
・EC2、RDSへの一極集中の負荷を減らせる
・なんかカッコイイ。

2Tierの課題
・AWS MobileSDKをラップする必要がある
・iOSとAndroidで実装が必要
・各サービス同士のつなぎ込みがしにくい
・ロールバックがある場合は大変

2Tierの救世主？ーLambdaー
・イベントをトリガーに処理を実行
・実行環境はAWSが管理
・オートスケール
・EC2インスタンス費用が不要
・AWS MobileSDKからは呼べない。

課題は色々あるけれど…
モバイルアプリは2Tierが増える！

・「小さく産んで大きく育てる」そのための設計をおろそかにしない
・Pushを制するものがモバイルアプリを制する
・1 Screen, 1 API Call
・AWSのすべての機能やツールには存在している理由がある
・AWSを知り、サービスを知らなければ勝利はない
・サービスは疎結合、チームは密結合

CloudDays Tokyo 2015 spring 2日目

【GEのインダストリアル・インターネット戦略】
何度も聞いた話なのでメモは割愛。

【今後のクラウドの姿～来るべきIntercloudの世界に向けて～】
パネルディスカッションです。
進行：新野
パネリスト：東(CTC)、本城(NTTデータ)、梁瀬(CISCO)、宮川(CISCO)

●国内市場におけるクラウドのニーズと課題
東：ここ数年はオンプレミスとクラウドの比較、ハイブリッドでの提案を求められる。大きな会社は運用をまかせる情報系子会社を持つため、クラウドへの舵を切りづらい。中堅の方がクラウドの使用率が高い。
本城：震災以降、自社でITシステムを持つことの不安があるので調査資料よりもクラウドの使用傾向が高いように感じる。現地でIT人材を雇って運用することは難しいので、グローバル企業はクラウドで立ち上げることが多い。

●シスコのクラウド構想の全体像と戦略の鍵となるIntercloudの概要
梁瀬：CISCOは各ベンダーの独自プロトコルネットワークをIPで繋いでインターネットにした会社です。これから各社の独自クラウドを繋いでIntercloudにしていきます。現在、６０社を越える企業がパートナーとして参加しています。
新野：Intercloudは戦略名ですか？
梁瀬：その通りです。製品名は「Intercloud Fabric」です。社内の環境とパブリッククラウドをL2トンネルでセキュアにつなぎます。クラウド事業者側にはIntercloud Fabric for Providerを導入します。
宮川：今のところはまだKVMにしか対応していません。４月にはマルチハイパーバイザ対応します。

●各社のクラウド戦略と現在の取り組み
東：マルチクラウドにおけるシステムインテグレーションに注力している。
　　今までは１VMいくら、というリソース貸しの形だったが、非機能要件まで含めての引き合いが増えている。
本城：NTTデータのクラウドサービスはあまり大きくうたっていない。どちらかというと要件の厳しいお客様向けにトータルソリューションを提供している。機材持ち込み、専用線接続の希望など「きれいな」クラウドで対応できるお客さまだけではない。

本城：「アプリケーションが要件を決める」と思っています。CISCOのACIの概念と同じです。

新野：AWS等でもプライベートとの接続ツールはありますが？
本城：システム移行の過渡期にはいいと思いますが、将来的なロックインを避けたいお客様がいます。
東：APIだけでの接続は難しいです。現状のL2ネットワークでのインフラ構築はこの先も続きますので
Intercloud Fabricは重要です。
CTCにはお客様担当のエンジニアとCICSOの中にいるエンジニアもいて、Intercloud Fabric fot BusinessとIntercloud Fabric for Providersの両方の知識があります。

●クラウド市場における各社の今後の展開とは
東：Intercloudを共通アーキテクチャとしてパートナー同士の協業を行っていきます。
　　これに参加する前からvirtustreamとの協業を開始していたので強化していきたい。
本城：クラウドにおける一番の問題はライセンスだった。
　　　これから各社（特に○racle）がライセンスを見直していけばさらに加速する。
　　　クラウドのゆるい連携はこれからも進んでいく。CISCOにはリーダーシップを期待したい。
梁瀬：ソリューションパートナーだけではなく、アプリケーションパートナーを増やしていく。

●最後に
東：クラウドの使い分けを考えている企業への提案パターンは出揃いつつある。
　　アーキテクチャに踏み込んだ検討をして決める必要がある。
　　→APIベースなのかL2,L3ベースの接続なのか？など。
　　アプリケーションの用途から考えたインフラ選択が必要
本城：機能としてはどのクラウドベンダーもあまり変わらない。「どこまでまかせる」のかが判断材料。
梁瀬：CISCOは新しいビジネスのopportunityを目指している。

【PTCが導く「モノのインターネット」の始め方】
・IoTアプリケーションはノウハウを吸収して進化する。
視認型→遠隔操作型→自律型

ThingWorxを買収したのに続き、Axedaを買収しました。
Axedaはすでにクラウドでデバイス管理をしているので、データはこちらを生かして、見える化をThingWorxで行うようにした。
現在はThingWorxのデータ管理にCassandraが使えるように実装中。

【オンプレミス環境のクラウド化と運用を楽にするOpenStackソリューション～ハイブリッド・クラウドを見据え、システム部門が準備すること～】
・OpenStackでコンテナのデプロイ機能を追加中です。

【WAFで対策！ウェブへの攻撃はIPSや統合型製品では防げない～パスワードリスト攻撃やL7 DDoSの対策方法～】
L7 DDoS→Slow Client Attackと呼んでます。
・従来のSYN floodやSmurfなどレイヤーの低い攻撃だけでなく、
　Slow HTTP Headers
　Slow HTTP POST
　など、L7でIPSが検知できない攻撃が増えている。

●Webサイトクローキング
・まずは攻撃のターゲットにならないように色々な情報を隠す

●情報収集対策
・WAF製品自身の存在を隠す。

●攻撃定義ファイルによる防御
・常にバラクーダセントラルからダウンロードして最新状態に保つことが可能。
　→１０～３０分おきに更新。

●CAPTCHA認証
・同一IPからリクエストが連続した場合にWAFに挿入させるような設定も可能。

●IPレピュテーション
・国／地域IP辞書を搭載し、外国からの通信を遮断することが可能。
・Tor、匿名プロキシにも対応

●SlowClient攻撃防御
・クライアント－WAF間の平均通信量を観測し、想定より明らかに少ない場合、リアルタイムで通信ブロック。
　→CAPTCHAを挟むことも可能。

●パブリッククラウドへの導入。
・Azure,AWS,vCloudAirに対応しました。

なぜ、Barracuda WAFなのか？
・開梱後、30分でSQLインジェクションの学習完了。
・L7 DDoS 、IPレピュテーションが可能
・日本語GUI
・認証、LB、SSLを搭載
・豊富なモデル。仮想アプライアンス版も提供。初年度保守込みで128万～

【開発力アップに直結！統合開発環境の最新トレンド】
展示場内メインシアターでのセミナー。

●なぜ統合環境？
・最新のノウハウがつまったテンプレート
・コード入力支援機能
・フォーマットを整えて読みやすく
・実行／確認が頻繁に行える

●注目すべきIDEは？
VisualStudio
NetBeans
Eclipse
IntelliJ IDEA
Xcode

各IDEの○×
●VisualStudioCommunity2013
○分割されていない
○アドインが使える
×機能が妙に隠れている
×Microsoftアカウントが必須
×アンインストールが手間

●NetBeans
Java開発元ならではの熱心さ
JavaFXでデスクトップを狙う
PHPのIDEとしても優秀

●Eclipse
インストールは展開のみ
アンインストールは削除のみ
プロジェクトごとに用意するのも簡単
しかし重い。

●JetBRAINS
AndroidStuidoに採用された
製品のよっては無償のCommunityEditionがある

●Xcode
Mac/iPhone/iPadの開発はこれ。
新言語Swiftが登場

あとはIDEのデモ。
・VisualStudioでHTML
・NetBeansでJavaFX
→1.8.0_40からダイアログを出せるようになりました！

マイク持って片手でキーボード。遅くて時間切れ。

IDE調査時の注意点
・できれば仮想環境で。
・CPU、メモリ、ディスクは潤沢に。
・あきらめずに何度も。

CloudDays Tokyo 2015 spring １日目

【「グループウェア変革」が企業のワークスタイルとコミュニケーションのあり方を変える】
・昔のインターネットは集合知だったが、今は巨大な広告場。
・メールは電話／内線など１：１のコミュニケーションの代替だった。
　→多：多のやりとりには不向き。今やメールは仕事に割り込む存在。
・電子掲示板「よくある失敗」
　→何を書けばいい？どこまで書いていい？誰がチェックしてるの？など一歩引いた存在になる。
　→会社が掲示板に「目的」を与えると失敗する。
・コミュニケーションが活性化する場の共通点
　→飲み会、喫煙所、ミーティング後の余った時間など「他の人にみられていない・聞かれていない」からこそ活発。
　→電子掲示板を利用者に預けてしまう。中は現場で好き勝手に使わせる。

●デスクネッツの自社事例
・「仕事に割り込まない」情報共有
・「言うだけならタダ」企画提案

※ルールは２つだけ
・気に入らない書き込みは無視する。反発しない。
・無視されても泣かない。

●「ゆるい場」を演出する掲示板のヒント
・落とし物掲示板
・あげます、探してます掲示板
・ランチ情報掲示板
→仕事に関係ない、がポイント。

あとは少しの協力者（サクラ）
※「お疲れさまです」で始めない！

●しかし…
通達などがあるグループウェアのトップページにゆるい書き込みができる？
→「広告スタイル」の情報発信
→経営層を巻き込みましょう。メッセージの発信が嫌いなマネジメントなんていない。

【今までなかった！クラウド上の情報漏洩監視とフォレンジック最前線】
ハズレ。ひたすら製品紹介。
　

【Brave New IT～VMwareで実現するOne Cloud,Any Application,Any Deviceの世界～】
VMwareCOO　エッシェンバックの同時通訳セッション。
やっぱり、ネイティヴの「Application」連呼でゲシュタルト崩壊。

・OneCloud(ハイブリッドクラウド)→AnyApplication→AnyDeviceのスタック構造に変わります。

・NSX,vCloudAir,vSphere6,vSAN6,AirWatchを２月にリリースしました。
・もはや、Oracleも仮想環境で動かす時代です。

・VMのプロビジョニングが簡単になったら、ネットワークがボトルネックに。
　→SDNは必然な流れでした。
・DCのトラフィックは外部２割、内部８割ですが、投資の８割が外部トラフィックにかけられています。
・OpenStackの最適な実行環境はVMware！
　→vSphere Enterprise Plusを利用の方はVMware Integrated OpenStackが無償で使えます。

男性通訳がひどかったなー

【Cloudを守る４つのセキュリティー【Dynamic Cloud Security】】
・４半期ごとに新たに3100万種のマルウェアが発見されている。
・１回の情報漏洩で、470万件のIDが流出する。
・情報漏洩の原因は
　悪意ある攻撃：42％
　システム障害：29％
　人的エラー；30％
　合計が100%にならないんですがそれは…

・クラウドのセキュリティを懸念する声が多いが、そもそもそれ以外のセキュリティは完璧なのか？
　→すべてをひっくるめてセキュリティ技術を進歩させるいい機会だ！

・IBM Dynamic Cloud Security
　→当然ながらSoftLayer上で実装されています。