2015/06/02 グランドプリンスホテル新高輪
参加者 : 13,900 (前年比 数10%増)

でした。平日やるの止めてほしいよね。今年は有給取れたけど、毎年取れるとは限らんし。
といわけで、基礎公聴から最終セッションまで参加しました。

疲れたー

動画が公開されました
http://aws.amazon.com/jp/summit2015-report/

*** 本記事は まとめられた情報でもなく、間違いもありそうです。参照にはご注意を ***

基礎公聴 アマゾンデータサービスジャパン 代表取締役

↓ 今回のkeyword
“coloud has become the new normal ”
クラウドが 「new normal」 になっている
実態は、各セッションで現場の声を直接聞いてくれ。とのこと。

AWSビジネスの成長

ちょっとその前に、そもそも Amaozon は 成長を中心として、顧客満足向上→トラフィック増大→セラーの拡大→選択肢の向上→顧客満足向上 … といったサイクルをビジネスモデルとしている。そんな中で、「AWSはamazonのビジネス課題を解決するために生まれた」。その課題とは、、「2010年前後?あらゆるものが間に合わなかった」ので、インフラのソフトウェア化を進めた。これが AWSの前身ですよ。ちなみに aws は 9年ぐらいやってるぜ!
あーそれとね、リージョンはDCではない!→ TokyoRegionは複数のデータセンターのクラスタで できてるからね。

で、AWSの成長具合は

  • SmpleDataService/EC2 およそ 100%の増加
  • 100万を超えるActiveユーザー
  • 顧客層が広い。start up ~ public sectorまで。
    金融 : マネックス/Sony銀行
  • クラウドに適したアーキテクチャーを APN プレミアムコンサルティングパートナー 日本では4社
  • ISV
    OBC / Windgarc first / saizon NRI / cloudpack / server works / class method
  • Enter Prise Solution Pattern (増え続けるAWS対応ソフトウェアと SASS)
    -> AWS ブースにて配布中

ユーザーグループ : JAWS-UG /

Cloud New Normal : 8つの視点

1. スタートアップ企業による利用

特徴 : ゼロスタート、自由な発想、低コスト体質、スピード重視(Try and Error)

企業例(海外) : airbnb / dropbox / supercell /
-> 特にairbn はすごい。この2年急成長。一気に世界展開している。数千台のインスタンスを わずか5人で運用している。
企業例(日本) : SmartNews / cookpad / chatwork / Smart Education


Crowd works (Crowd Sorcing) ゲスト講演

  • そもそも
    • 企業から個人へのお仕事を発注する橋渡しをするサービスです。
    • 個人に対して評価がついているので、発注側は安心です。
  • 経歴
    • 日本ベンチャー大賞の第1回を受賞
    • マザーズ上場(赤字のまま) Cyber Agent より 14年ぶり。
  • 利用状況
    • いま 60万人
    • 大手もつかっているよ(Toyotaとか時価総額Top10のうち8社が利用してる)
    • 世界110か国につながっている
  • 背景
    • 時代は もたざる経営へ
    • 45% が 正社員。残り 55% を未整備。
    • 6.2 本日 パリが雨なら放映

memo : zabbix

2. xxxx ← 見逃した。。。


Recruit Technorogy ゲスト講演

  • 5年前までは 海外事業をしていなかったが、今は 23.6% が 海外の売り上げ。
  • aws x recruit = r-cloud って呼んでます。
    利用シーン : 簡単に予測できるものは、オンプレ。
    予測するものが意味がないサービス・難しいものは クラウド。
    [AWS利用サービス]
  1. FromA Navi – パンダ一郎のスタンプ
    スタンプダスト 150倍。前回はたまたまかも。次は2回かも。

2.受験サプリ
月額 980円 : 30万人。受験生の半分。

  1. push 通知を同時間帯に大量に行う

1,000万人に12分で送れる計算。

3. お客様のニーズの多様性は異なる

  • もっとも喜ばれるのは、Agirity。スピード。
  • AWSのコアサービス

  • VPNのサービスも数年前に開始。(3-4年前)

  • ほとんどのエンタープライズ小屋宇kが使っている。
  • あとは、ライセンスのクラウド移行。
  • SAP on AWS が 100社に。数年前からやっている。
  • ERPが動くと、ほかのアプリも以降いてい傾向に
  • AWS は 他と異なって、いろいろなサービスがある。分析もモバイルもエンタープライズ向けのデスクトップアプリとか。
    Solution Architects が サポート。
    成功の一つのカギ「クラウドのアーキテクチャに沿って作る」必要がある。
  • AWSはイノベーションを行っている。
  • 機能がどんどん増えている。

  • 対応している例

    1. 共有ファイルシステムの課題
      EFS / ES2のためのフルマネージド型ファイルシステム
      もちろん9イレブンの堅牢性
      現在、プレビュー中。
    2. 管理コンソールが日本語で可能に。

4. 企業のデータ活用はかつてないほど拡大

データの収集、保管、分析、共有は かつては困難なものだった。
それが、AWSでは「kinesis」でリアルタイム分析ができるほどに。

  • 導入企業例
    • finra … 金融業務の監査(アメリカ)
    • スシロー … 需要予測 ビジネスインパクトに台

機械学習には
→ 専門家が必要。非常に骨が折れる優秀なエキスパートにいないと、、、
→ Amazonも同様にやってきていた。
→ リコメンデーション(機械学習のひとつ)専門家が必要。

☆ Amazon Machine Learning … 注目

5. 古い足かせからの解放

2年前の DWH … 高い。運用が高い。 → いまの RedShift
RDB … 高価/制約/ロックイン/ライセンス → Amazon Aurora
DeskTop … → ADとの統合とも可能

6. 継続的な変革

最初は m21 のインスタンスから開始。(Amazon EC2の前例)
Dockerコンテナサービス
chart works の事例

いまは「リソースの極小化」が
→ イベントドリブンでサービスを起動する
→ 画像をUPしたら、リサイズ、圧縮、保存とかが、自動的にやってくれる。ずっと立ち上げる必要ない。
課金はイベントが発生した場合のみ。。。つまり、非常に少ない。本当に動いているのみ。
今時点では、Node.js のみだが、数週間以内にjavaで。
利用想定ケース : 多いのはIOT、
例 : 温度が変わったら、自動で起動する。自動でスケールリングしてくれる。
非常にこれからの時代のテクノロジ。

7 クラウドの移行は 0の1か判断ではない

中長期的にアセスメントして、持ってい行けるものから持って行っている
→ ほとのどの ワークロードはクラウドに移行すると信じている。
ハイブリッドは一時的

セキュリティ
特にアメリカは厳しい。膨大な数の監査を受けている
誰がアクセスしたかなど管理できる。
裏ウドを利用しても

8. 顧客パートナーが AWSへオールイン

NETFIX など 動画配信会社。
全てを AWS へ。

WORKS Application
INFOA … 理由は コストではなく あじりてぃ


ファストりの 玉置CIO ゲスト講演

→ UNIQRO
JPY 1.38 Trillion Revenue 売り上げ
従業員 9万人
新機出店が背景
→ デジタルイノベーション頑張ってます
→ リアルとデジタルを融合して新しいものを作りたい。

IT戦略

1. グローバライゼーション 世界展開してるので、最初からグローバルを視野に入れてます
2. デバイス Agnostic 直感的にマニュアルいらず、どれでも動く
3. クラウド 事業スピードについてこられるのが クラウドのみ。

なぜ AWS?
→ Large Community が 素晴らしいため。
→ マルチリージョン / サイジング ツールが多い

2020年に向けて
→ 5兆円の売り上げを目指す
→20 %の before tax

cloudの導入には顧客変化が必要
→ 重力に逆らえない (=もう流れは止められない。)
あらゆる企業がオールインしている。
デジタルトランスフォーメーション
これだけ手軽にスピーディにできる。ダメならシャットダウンする。でよいのは、すごいこと。
人が足りな用。


セッション

Session Lunch 富士ゼロックス Better Communication

1年前に導入。ハイブリットクラウド。課題/苦労しているポイント/今後の方向性
→ そもそも ハイブリットクラウドって何を指している?オンプレとの双方の利用すること?オンプレとクラウドがリアルタイム通信とかして棲み分けをしているイメージ?

富士ゼロックスとは

既にコピー機を売るだけの会社じゃないぞ。
それの周りのコミュニケーションを通じてサービス店会s地エイル?

2010年 NRI に Privateクラウドで対応した。
がしかし、コスト高、いろんな不満が発生してたので調べてみた。
→ 結果、不平不満の内容。結局 PVクラウドは、共通部品を共通に使ってコスト削減を!がテーマだったが、
実際に使ってみると、それだと満足できない。。。
サービス個々で 要件や課題が違った。
でもって、専用で利用するようにすると、個別コストが掛かっていた。
でもって、それが積み重なって、DCのコストが嵩んでいくという悪循環に。

不満 : 高い、提供機能がなってない、運用体制がなっていない

→ そもそも、使い方を改革しないと。。。
地道に対面して活動。
→ いままでは 固定費から 従量課金へ
購買システムも 全然、できていない。

AWSを使い子tなして半として、

  1. 体制
    → りおうしゃをナビゲーションする

セル府 amazonと マネージ度 NRI の二つに分けた

クラウド統括を利用者側に作ってみました。

  1. プロセス
    → FujiZerox
    ・申し込みん関わる事務フローと改善する
    ・FujiXeroxのクラウドデザインパターンを作った
    → 外部OK パターンを作ることで 審美プロセスが 簡略化された
    → 則っていれば、OK

・購買と審議の両方をやることで、
→ ついでに 昔誰かがやっていたレベルの審議をSKIP

amazonにおける奪家ロン 。セキュリティ大丈夫?
→ 富士ゼロックスのセキュリティポリシーに則って策定した。
Networkを「RED/イエロー/green」3つに区切って、それぞれにおけるデータを決めたんだ。
利用者間のコミュニティを発足。現場への浸透を図る。なんせ会社大きいからね。

課題

・素のようには使えていない。
→ いろいろな制約がある。
I am セキュリティグループ
– 新サービスが出ても、すぐに使えると限らない。
– 社内手続きのため、即開通にならない。
例1 :新サービスが出ても、社内の審議が必要。。
例2 FXProxy アドレスに制限
→ サービス自身が 直接でやる場合にはつかなかったり。

  1. NACL ネットワークACL
    → NRIさんに Network管理を委託しているため、やや難あり。

  2. セキュリティ機能の一部をIAMで管理しているため、利便性が低下。
    現在は2-3か月だったが、いまは2週間。リードタイムをもっと短くしたいね。
    利用者スキルのばらつきが発生。

    → いままで オンプレミスでハウジングだったひと。とか大変じゃ。
    → 位置からきちっと説明していかないと、結局 しんとうしない。
    → SIer では 手順書作ってもらうのが普通だったので、、、、という あるある話。

社内でプロモーションもやってます
AISATSU → これをして、スケールメリットを出す。

今後どうしたい

・マルチリージョン
→ 世界に顧客がいる。
→ そのため、東京リーじょん のみから、顧客がいる場所の AWSリージョンにしたい
・マルチパブリック
→ 他のサービスともコネクトする。グーグルとかアジュールとか。
この2つが主な方針。今年の。


Session EA01 Recruit Technology Security

2011年 入社 → 主に検討。セキュリティを重きに置いた話っぽい

リクルートグループに対して、様々なソリューションを添加している。
インフラに特化した内容です。今日の話は。

  1. リクルートのビジネスモデルとクラウド
    → リボン図。ひとを結ぶ。が基本の発送。
    → ソリューションが 紙からIDに
    個別のサービスごとにDCを持っていたが、一つのインフラ
    → 徐々にサービスを拡大して、需要予測ができないサービスも。

2012年ぐらいから徐々に使い始めてきたんだけど

なぜ AWS?
1. VPC でセグメントが切れた。
2. 権限が細かく制御可能

→ サービスが多種多様なので、要件も多種多様。
そのため、様々なサービスを利用している。

2012年ごろまでは シンプルなもの
2013年ごろから RedShiftなど いろいろなものを多く使い始めた。
2014年以降は、リリースしたと同時に使い始めるようになった。

AWS で考えるセキュリティ

特にセキュリティは重要。個人情報を扱うことが非常に多いためシビア。

セキュリティ担保のポイント
1. 仮想NW設計/ACL管理
2. 権限設計/ID管理
3. ログの共通取得

IAM権限設計ってなんだ?
統合認証基盤によるID管理と運用ってあるけど、具体的にはどうやってる?
→ そもそも OSの統合認証基盤って、どうなってるの?何を指しているの?

VPC / IAM / CloudTrail(ログ)

VPCがあるから、選んだ。
IAMがなければ、選ばなかったかなぁ
監査の一元化したいなぁ。

IAMについて、
→ ロック機能とかは自分で実装
→ DirectoryServiceがあるけど、要件と会わず。
→ ユーザー/グループ/ロール
→ 2014年ぐらいから、ロールに対してポリシーがくっつけられるようになった


Session EG02 AGC旭硝子 – メインフレームをクラウドへ

私が見たなかでは、最も

クラウドで情シス部の赤を変える
車のガラスについては、1/3 は 旭硝子。今回聞いた戦略次第では、株式購入をめどにさらに調べる。

OA Serverの泥臭い業務を行う
どう話を上に持って行ったか。をありのままに話すつもり。

1.なぜクラウドに行こうと思ったか

meinfure-mude kadousiteita
大規模基幹システムの保守切れ

がしかし、オンプレもクラウドもそれぞれ課題があった。。
[オンプレ]
1.劇的なコストダウンはもうない
2.十分なBCP対策はできない

[クラウド]
1. かえって高くなるのでは?→ そうやって言われた。
2. 法律的・セキュリティ的にはどうなの?
→法律については ほとんどまとまった資料はない。
技術系の計算データってもって一定ーの?
3. そもそもクラウドは不向きでは?

基幹システムの

クラウドに行くべき理由(AGCにとって)
1.BCP (真の事業継続性)
2.SystemLifeCycle 戦略的更改計画 → 5年
3.Govenenace → これでグループ内を標準かだっ

コストについて
おそらく 20% Down
インフラ、開発も減るんじゃん?話もあるけど、それの試算が難しいので、

ある低緯度規模のあるやつ。
→ 土日に開発機不要ジャン

サービスレベルの見直し
→ 過度なHWの情調化をやめる単一AZを許容する。
→ そのまま 持ち込む必要ない。冗長化。再起動さえすれば、大丈夫だから いいじゃん。
→ 再移動の間だけでも とまるのは難しい。

ハードウェア更改
→データセンタ固定費、BCP対策(Bあc九pサーバーも止められるやん)

2. 本当に他大丈夫なの?

いい面は説明しやすいんだけど、、Accentureに協力を仰いで使った。

4側面から大丈夫かを検討した。
法律面 → データをカテゴライズして
例:技術情報、だと 外為法。とか

東京リージョンに置くのが前提して、確認の範囲を狭めた。
→ どの法律も適切に管理する。のが前提であって、場所はOK
まずいのは、欧州の人事データぐらい。

いまと同じ統制がACGじしんでできる
→ いまと同じ統制がAWSによってされるもの

例えば、入退室管理など。監査レポートで確認できるのでOKとか。

セキュリティリスク
内部犯行 → いまと同じレベル。
外部反抗 → データ暗号化

採用に至るまで、調査してから約6か月かかった。

3. で、入れてみてどうなの?

→ 失敗したと思うところはない。
安定稼働 / 使い勝手

安定稼働
→ 障害はなかったか

メンテナンスの影響はあったか。
1. 通信軽作業メンテ
→ 自多重化されているため、無影響
2. セキュリティ対策。
→ 夜間。本番環境は、長期間の availability zone 停止に備えた構成にした。

パフォーマンス
体感鉄器な問題なし
Internet SalesのSub SYsてmも良好
大規模なバッチベースのパフォーマンステストはこれかr。

楽になったこと
・機械の調達概念と、DC関連作業が一切なし。
→ 通常2か月ぐらいかかるので、、、、
→ 物理作業がゼロになるので、5分で開始可能になる

・リストア・テストの制約なし。空いてるハードなんていくらでもあるし、いつでもできる。

設計構築補法が変化
インフラの厚生委変更が非常に柔軟で助かった。
オンプレだと、負荷分散は 数百万掛かるけど。。。
Server追加・削除

サイジングと性能テストが事後でOK
ソフトウェアライセンスの考慮点 →

実際にはどれくらいがコストが?
→ 高度に利用することで、AWSはさらに安くなる。
→ いろいろ止めることができる。負荷分散数の調整とか。

4.横展開を見据えた使い方

いまは5つのシステムのみだけど、もっと展開を。
共通基盤を作る。コマンド基盤をとくに気に掛けた。誰でも何でもできると困るからね。

VPCがやっぱキーだなぁ

オートリカバリー
1. ネットワーク標準
・ VPCとDirect COんえt で鉄壁なセキュリティね。社内LAN延長の位置づけ。

セキュリティについては、
・データ機密性保持のためデータ暗号化。
→ 第三者から確実に削除される。
→ 唯一、我々が望んだタイミングでは削除されない。という問題がある。

いろいろ調べてみると、、、自分のデータセンターんほうが不安。
自宅の金庫と銀行の金庫。なイメージ。

調達とか手続きが大変とか、考えるともう戻れないなぁ。
新機能を絶えず取り込むアジャイル的な発想が重要。

AWS導入に関してアクセンチュア強いなぁ。


Session EA03 NTT DATA クラウドを活用したオムにチャネル基盤と、それを支えるAWS運用ノウハウの伝授

主に運用な話を聞くべきなんだけど、、また、IAMの話?VPCつかって、DirectConnectoしてみたいな?
と思いつつ、ふたを開けたら ただのHinemosの製品紹介でした orz

聞く価値はなかった。。

オムにチャネル

なぜいまオムにちゃるねうが必要なのか?
なぜ AWSなのか?
NTTデータのオムにチャネル美人巣の強み

チャネルの話。
→ 予測困難なチャネルの使い方がされる。

→ 店で調べて Netで買うとか、いままでのパターンからかい離し始めてきた。
→ 全体の2から3割がそんな感じ。

→ 通常の同線では対応できず。機会損失が発生。
???
いまいち理解できないが。。

これから接点店を増やすこと
システム的にはどうアプローチする?

→ データの一元化とチャネル追加に対応しているケル基盤の作成
この二つ。

分散データに対s知恵、API連携すればb?
という案は、一元化されていないと、チャネル追加に対するオーバーヘッドが大きくなる。
。。。オーバーヘッドって具体的に何だろう。。。

メディア、デバイスの増加、多様化
顧客の機能が、多面化、複雑化しているぞ。

何が起こるかよくわかんないから、
追従できる AWSにすればいいじゃんということでAWSに。

オムにチャネル基盤を迅速に提供するために何をしているか?

  1. 詳細設計と 標準化、構築を自動化、テストを自動化 ServerSPEC使ってるよん。

構築自動化、クラウド子メーションを使って自動化しているよ。
cloud formation を使って。
→ こうやります。具体的には。
書くサーバー単位でAMI化する。
クラウドフォーメーションで パッケージ化する
クラウドフォーメーションの細かい話。
最初にネットワークをぶった切る。次にサーバーを立てる。次にOSの設定を載せる→次に監視設定とかする。4STEP。

次は Server SPECの話。
ドキュメントからコードを自動生成している。
一部はテストコード書いてるよ。

安定運用に向けて、

3.手順の統一化をしている
バックアップ&リストア
→ ねちまった。

  1. 監視
    運用監視サーバーを立てて効率化しているよ。

AWSを使ったシステムン用のノウハウ
運用管理ソフトウェア使うよね?じゃぁどう会えればう?

☆新しい運用観点
・正確なリソース情報 → いろいろログ伯からね。
・メンテナンスの情報を管理する → AWSでのメンテナンス
・利用料金を管理、分析すること → Billing csv がでるけど、ひがみruji
・1fuyouna riro-suwotomeru
・操作ログを監視

新しい運用手法。どうやってやる?
・一元的にやるべき。magement console
・アジリティを活かした運用

Hinemosは統合運用管理ソフトウェア。AWSは昔から対応しているよ。


企業ブース

全体的にこんな感じに大別できたと思う。
1.オンプレでやってたことをAWSでもやります。
2.AWSへの導入をサポートします
3.AWSを便利に使うためのツールを入れます

| NetApp | AWS上でもうちのNASの便利機能使えるようにするぜ!唯一コンパニオンの姉ちゃんがいてエロかった。来年も期待。 |
| ????? | OracleをAWS上にて導入することについて、xxx パートナーシップを取ったとのこと。AWS上でのOracleを動かす話なら安心かも。 |


所感

各セッション

[参加前の考え]
ざっくりと 話の内容は、検討→導入→活用→運用ぐらいに大別できそう。
それと、大事なのは「導入したシステム」が 業務の基幹システムか否か。

検討時に課題になるのは、費用/セキュリティ/運用。(RASISの他の指標は割愛。だいたいクリアしてるでしょ。)
ということで、大体費用は「安い」話になりそうなので、一番重要なのは セキュリティか?
あと、大規模な会社の場合、AWSであるがゆえに、社内ルールに則った運用ができないケースが発生しそう。

[結果]
まず、最近は基幹システムでも AWSする流れが できつつある。
検討時の課題については、だいたいどこも同じ。
導入した一番の理由や実感したメリットは「アジリティ」。という話が多かった。
運用については、大きい会社だと社内稟議とか購買側との調整とか、AWSの布教とかいろいろ大変だよね。という話があり。
AWSが選ばれる理由の一つとして、サービスの多様性が挙げられたのは、認識がなかったところ。

確認したかったポイントと結果(太字が結果)

検討

  • クラウドとオンプレミスとの棲み分け
    • 基幹システムでもいっちゃえ。感はある。棲み分けをするなら、スケールなどの予測が立っているビジネスはオンプレにするといったぐらい。あとはEOSを迎えていないやつは、迎えるタイミングでよさそう。
  • 他者のクラウドサービスとの比較
    • サービスの多様性が圧倒的。また、多くが使っているので知見が多い。また、周辺の関連サービスも多数。
  • 各社はセキュリティについて、どのようなとらえ方/考え方をしているか?
    • 例 : 個人情報を含むデータを AWS上に保管しているか否か
    • そもそも「クラウド」であるが故の セキュリティ的なリスクは、「他者に一任している」というだけな気がする。。
    • セキュリティについては、だいたい調べた結果、AWSのほうがよっぽどしっかり管理している。という結論に達するようだ。あとは、AWS上に各社のセキュリティポリシーに則った共通基盤を作成して、導入までの速度を速めるとしているところが多い。手法としては、 VPC(VirtualPrivateCloud) x DirectConnectがメジャーなようだ。

効果

  • 実際に大きく効果を上げているのは、どのようなサービスか?
    • 需要予測で成功したスシローはよい例。一方で、どの企業でも運用コストが下がった。一度AWS知ったら、調達とかDCの管理とかやってられんぜとなる。
  • 具体的に解決できた課題は?
  • インフラ技術者が 数なくてよくなったってホント?
    • この話はあまり出ず。

運用

  • 運用上で課題となったことは?
    • 全般的に、導入 活用事例が多い。AWS入れて失敗したことをもう少し知りたい。。
    • 作りこんでいると、新製品が出た際に「あー、やったの無意味だった。このタイミングでサービスとして登場かよ。」となる
    • 新しいモノが出てくるがゆえに、それに慣れていく必要があること
    • メンテを見逃すとまずいことに。。。

疑問

  • クラウドのアーキテクチャに沿って作るとは?
  • なんでクライアントでは、選考から漏れた

自分がどう動くか?

  • 当面は、AWSの情報提供/導入支援な位置付けでも価値は出せそう。
  • がしかし、AWSでビジネス的に内ができるか?一つ上のレベルの 提案ができるようになるべき。ただ、それには、まだまだ知識が不足。無数のサービスすべてを把握することは不可能なので、いかにアンテナを張って情報を収集するべきか検討する必要あり。
    • 当面については、機械学習のサービス Machine Learning 話題性はあるところか。