「AWS Summit Tokyo 2014 DAY2 #AWSSummit #jawsug」(2014年07月18日)の参加メモ
昨日に引き付き今のすべては1年前のこのイベントから始まった的な↓イベントに参加してきました
AWS Summit Tokyo 2014 ~「あなた」のクラウドがここに~ | 2014年7月17日(木)~18日(金) アマゾン ウェブ サービスの無料クラウドカンファレンスが東京2Days 開催!
講演資料は以下のページを参照お願いします。動画でセッションを見られるのはいいですねー
AWS Summit Tokyo 2014 開催レポート動画・資料一覧 | アマゾン ウェブ サービス(AWS 日本語)
当日の流れなんかは @shinyaa31 さんのTogetterまとめを見てもらうとして
2014/07/18 AWS Summit Tokyo 2014 Day2 基調講演 #awssummit - Togetterまとめ
2014/07/18 AWS Summit Tokyo 2014 Day2 午後の部 #awssummit - Togetterまとめ
以下メモ(個人的感想含む場合あり)
基調講演 #KEY-02
- ADSJの長崎忠雄 氏の話しからスタート
- AWSだけでなくクラウドがこれだけ多くの企業に選択されている理由は「Agility」
- 金額面のコストメリットが多く取り上げるられるなかで、個人的にもコストよりもその即時性・柔軟性が非常にありがたく有益に感じています
- また、この柔軟性により時間面のコストメリットが色濃く出ることもあり本当に助かっています
- 既にクラウドは「何が移行できる」というフェーズではなく、「何が移行できない」のか?を考えるフェーズに来ている
- それだけクラウドが一般的なものになってきている
- イノベーションを起こすには多くの失敗を経験する必要がある
- そのためには早く安く失敗出来るプラットフォームが必要
- それがクラウドとマッチしているのでイノベーションが起きる可能性が高くなる
- AWSは新機能の追加を順次行っている
- これは機能だけでなくEC2インスタンスの性能向上も含まれる
- 従来のオンプレミス環境では機器交換でしかできなかった性能向上も自動的に行われる
- ゲストスピーカーとしてガリバーインターナショナルの許 哲氏の登場
- ナイトライダーだ!!
- LINEを使った「Drive+」の発表
- クラスメソッドさんがここでも活躍!凄いです。
- LINE+AWSの構成で自動車に取り付けた機器から情報をクラウド上に送信
- LINEはUIとして利用し、スタンプを送信するだけで情報を取得することが出来る
- 「Connected car」の考えでは機能が搭載された新車のみが対象となっているが、既存の車にも何か出来る可能性を試している
- このサービスではKinesisやCognitoなどの新しいサービスも使っている
- プレンゼンターとしてADSJの堀内 康弘 / @horiuchi氏の登場
- マネージメントコンソールが日本語化される予定!
- どうやら英語と日本語の切り替えOKになる予定??
- 個人的にはあまり気にならないが日本語化の要望は多いらしい
- AWSは過去44回の値下げを行っている
- この値下げは競合との競争なしにAWSが単独で行っている
- なぜ値下げを行うのか?それがフィロソフィだから
- なんていう顧客第一主義!すごいなー
- 日本のAWSを発展を語るのに外せないのJAWS-UGの存在
- 全国に45以上の支部があり、勉強会・セミナー・ハンズオンといったことでノウハウの共有やアウトプットが行われている
- このコミュニティの存在によってAWSの利用が加速されている
- JAWS-UGにはエンタープライズ向けのグループもありE-JAWSという
- ゲストスピーカーとして積水化学工業の寺嶋 一郎氏の登場
- 自社グループのために作られたグループウェアに課題があり解決のためにAWSを利用
- AWSを利用し始めるにあたっては、セキュリティやパフォーマンス等ありがちな懸念点はあった
- 最初は小さい規模でスタートして順次規模を拡大していった
- こういった柔軟な対応が出来るのがクラウドの強み
- 当然いろいろなAWS移行事例はある
- その中でもすべてのシステムAWSに移行した事例がある
- 日本通運、ローソンは完全に移行済み
- ゲストスピーカーとしてローソンの加茂 正治氏の登場
- ローソンではデータ活用としてCRMとSCMを利用している
- Pontaカード会員から得られるCRM情報を生かしてファンを探している
- また、CRMの情報から店舗に対しても適切に商品を供給できるようにCSMにHadoopを使って分析を行っている
- AWSへの移行はこうした仕組みが長年にわたって積み重ねで作られているため、いわゆる「ベンダーロックイン」や「ハードウェアロックイン」というような現象が起こっている状態
- これを解消するとともに、店舗側からの注文締切時間帯だけトラフィックが増加するような場合も柔軟なキャパシティプランニング出来るようにしたい
- 将来的にはリアルタイムで適切にデータ処理も行っていきたい
- ただ、AWSにフルコミットすることによって今度は「Amazonロックイン」の状態になるのではないか??
- セキュリティに関しても見えない部分があるので完全に大丈夫かどうか不安になることがある
- 個人的にはAmazonロックインは考えない方が幸せだなーと
- 確かにAWSフルマネージドサービスを利用しているなら、移行は大変になりそうだけど。
- 移行しなければならない時に考えればいいので、AWSを使っているうちはAWSを使い倒してラクをしていきたいですねー
- ガバナンスやセキュリティがキーワードになることもあるが、どれもクラウドで実現できないことではない
- 必要なところに必要なだけ注力できるクラウドを選んで進んでいきたいですねー
[Lunch Session] 基幹システムのクラウド化を実現するための実践的ノウハウ #TC-06
- 協和発酵キリンの篠田 敏幸氏のお話
- 業務でITは使うがそもそもシステムを管理運用するのが目的ではない
- ITを使って目的を達成したいだけで手段に過ぎないので、基本的に運用管理に大きなコストを割きたくない
- AWSへの移行を検討するタイミングはシステムを置き換える、更新するタイミング行っている
- 必ずAWSを第一候補として検討する
- こうすることで、部分的にだが着実に移行することが出来る
- また移行できない場合も何となく検証しているわけではないので、理由が明確になる
- コスト圧縮には適切にリザーブドインスタンスを購入している
- SAPのパッケージもAWSに移行した
- オンプレのSAPパッケージが保守期限を過ぎていたので切り替え
- クラウドという部分で、バックアップやDRなどを適切に検討する
- ネットワークの設計は意外と重要
- AWS固有のことかもしれないが、IAMアカウントの権限設定に注意する
- 権限者はMFAなどを使い管理を徹底する
- 社内で出来なければAWSのパートナー企業になっているSIerに発注する事も出来るいい時代になった
- 弊社でも組織変更のあと権限が怪しくなってきているのでMFAは必要かもしれないなーと
- E-JAWSに入ればAWSのノウハウ・事例共有などが出来て非常に効率がいい
- 今後もAWS化は順次進めていく
エンタープライズ向けAWSクラウドデザインパターンのご紹介(ネットワーク編) #TE-06
- ADSJの荒木 靖宏氏のお話
- CDPを有効利用すると構築時にいろいろとメリットがある
- 今回のセッションで扱うのはインフラサイドの話し
- 「Tag」を使おう
- Tagとして情報を記述しておけば、容易にプログラマブルに取り出し可能
- AWS は課金情報ですらTagをサポートしている
- VPCは作る前にIP空間を考える必要がある
- VPCの制約でCIDRは/16 ~ /28までの間
- 構築後のCIDR変更はできず、変更する場合は作りなおす必要がある
- またIP空間はVPC Peeringなどを利用する際に、VPC同士で同じIP空間が利用できないので考慮していないと問題となる
- 単純にVPCとオンプレの環境を繋ぎこむ場合にも同様である
- VPC PeeringはVPC構築時のデフォルト空間だとかぶることが多く実際作り直しをしているものもあるので、気を付けないとなーと。
- VPC内の通信経路は編集も削除もできない
- VPC内には見えないルーターが存在するんじゃなかったっけ??
- Network ACLsとセキュリティグループの使い分け
- ACLsはVPCから出ていく方向の制御に使うといい
- ルールの修正・削除権限はIAMを使って管理する
- MAFの利用を推奨
- EIPとは異なる仕組みで動的パブリックIPを付けることが出来る
- 動的パブリックIPはちょっと試したいときに非常に便利ですよね
- NATインスタンスの冗長化
- HA NAT!オートスケールをNATインスタンスに設定
- min=1,max=1の設定でAZ毎に1つ用意する
- プライベートサブネットのルートテーブルは同じAZのNATに向けておく
- このNAT冗長化はすっきりしてていいなー
- NATが広帯域を利用する場合は、スケールアップをすることが単純かつ効果がある
- S3にアクセスするのに内向きにproxyを設定する
- プライベートサブネットからIGWへの経路を設定せずに、proxy前に置くELBに向ける
- proxyへのアクセスはセキュリティグループで制御する
- VPN、DXを利用する
Amazon Kinesisを用いたリアルタイムのゲーム分析システムと、AWS ElasticBeanstalk&Amazon DynamoDB を活用したゲーム運営 #TC-08
- Ripplationの安藤 達也氏 / 立本 龍馬氏のお話
- 写真がないのは始まるギリギリに入ったので撮るタイミングがなかったのです・・・
- 「騎士とドラゴン」を作成・運用している
- このタイトルを作るときのサーバーサイドは、最少人数!での開発。サーバー運用コストを下げる。この2つを目標にした。
- 目標が達成できるのであれば、手段や環境・構成は問わないと割り切った
- その中で試したのはAWS
- 使うならロックインとか環境依存とか気にせずにAWSを最大限利用する
- 個人的も使い倒してこそいろいろわかることもあるので大賛成です
- 手軽に簡単にスタートしてみる
- ただどうせやるなら、スケールや耐衝撃性も手軽に自動化したい
- 監視も出来るだけ簡単にしたい
- AWS ElasticBeanstalk+Amazon DynamoDB で出来る範囲での構成とした
- AWSはすぐ始められる
- アプリをサーバーにデプロイする流れを作るのが簡単。1から作る必要がなくエコシステムの組み合わせで実現可能
- 思った以上に実用に耐えられている
- 放置していても問題ない。最近マネージメントコンソール上で少し数値を調整したぐらい
- ElasticBeanstalkで注意しなくちゃならないのは、デプロイ時に一瞬だけアクセス不可能になる
- オートスケーリングの調整は必要
- デプロイはスワップURLを使って切り替えてあげればいいかもなーと思った
- DynamoDB の注意点は、IOPSの変更に上限があるので注意が必要
- バックアップするかどうかを事前に決めておく
- 汎用化ってそんなに必要でしょうか?
- AWSを使い倒さないとおいしい部分は見えないのでは?
- これは非常に同意です!!
- ログの集約・集計もRDSを利用せずにDynamoDB で何とかした
- さらに簡単にするためにこの部分を自前でサービス化することにした
- Kinesis Tシャツを着用してた!なにアレ!欲しい
- 10万/秒のデータを集約するとしたら?
- Linuxを頑張ってチューニングすれば受けられるデータ量だが、冗長化なんかも真面目にやろうとすると数百台規模になる
- Kinesisを使えば数百台の管理をしないで済む可能性があり
- 現状ではKinesisでもシャードが自動で増加しないので監視して増やしてあげる必要がある
- Kinesisは世界中のデータを集められるように作られているはずなので、積極的に利用していきたい
Amazon Kinesis Deep Dive #TA-09
- ADSJの大谷 晋平氏 / AWSの堀 剛氏のお話
- 堀さんはアメリカから来てるので参加してもらってる。Kinesisの開発責任者!!
- またもKinesis Tシャツ!
- 立ち見も大勢出てすごい人だった。みんなKinesisのことは気になるんだなー
- 今朝SNSのTLで話題になってたKinesisの東京リージョンでの利用可能になった件が、改めて発表された
- 加えてFluentdプラグインとMQTTアダプターもリリースしている
- これらはAWSが作成したもの
- AWS製とは知らなかった!MQTTがあるのは素晴らしいですねー
- 事例紹介として基調講演で発表のあったガリバーのDrive+の紹介
- Pencilのリアルタイムユーザーモニターについても紹介
- SmartInsightの事例はiBeaconとの距離をロギングする事例
- 実は今年の展示会場にはiBeaconを25基設置して実証実験を行っている
- 会場を歩きまわると管理画面側でヒートマップで可視化される
- SUPERCELLとbizoの事例紹介
- Kinesisはなぜリアルタイムなのか?
- 測定サービスで利用するため。測定サービスとは使った分だけの使った分を測定しているところ
- 数千万レコード/秒、数テラバイト/時、数十万のデータソースを処理して100%の正確性が必要
- 測定サービスで利用しているDWHは数百万/時のファイルを扱い、毎日100以上のETL処理が実行され、毎日数百ユーザーによる数百のクエリが発行されている
- こういった状況の中で課題として「スケールの問題」「リアルタイムの要望」「高い運用コスト」が出てきた
- 従来の要求は、毎時か毎日で大量のデータを処理していればよかった
- 新しい要求は、リアルタイムに早い意思決定のためのデータ処理や "keep everything" ! エラスティックな拡張性、複数の目的に対して同じデータで並行処理をするなどが出てきた
- 新しいデータがそこにあるといろいろ試したくなるので要求が出るのは当たり前
- Kinesisはこれらを解消するために、ストリーミングデータをリアルタイムで収集し処理するフルマネージドサービス
- 1時間あたり数十万のソースから数百TBのデータを収集、処理することが出来る
- データは複数のAZに格納されるため高い信頼性と耐久性を持つ
- パーティションキーを基にshardに分割される
- shardにはキャパシティがある
- なので、パーティションキーの数>shardの数
- カーディナリティーの高いパーティションキーを使うことをお勧めする
- Kinesisはstream内でユニークなシーケンス番号を付与する
- データもシーケンス番号も不変
- 24時間以内ならシーケンス番号で何回もデータが取得可能
- 何度取得してもシーケンス番号の順番は変わらない
- データの操作はAPIでも出来るがKinesis Client Library(KCL)を利用すれば、信頼性と拡張性のあるアプリケーションを作れる
- データの重複は考慮する必要があるが、そもそも冪等なアプリを作ったり重複を許容するなど最初に決めて理解がしていれば問題にはならない
- Kinesis Connector Library を利用してデータの取得、変換、フィルタ、バッファ、書き出しを簡単に実装できる
- 拡張性を保つために1度すべてのデータをKinesisに入れる
- こうすればKinesisからKinesisなどの対応も可能
- Agilityを高める!
- shardにはキャパシティがある
- アプリケーションが動いているEC2にもキャパシティがあるので注意する
- Kinesisがなぜ生まれたのかなど、なかなか聞けない話を聞けて胸熱でした!
【初公開】チャットワーク検索機能を支える技術 #TC-10
- ChatWorkの藤原 吉規氏のお話
- Amazon CloudSearch の利用事例とのことでガンホーのセッションと迷いましたがこちらを選択
- ChatWorkは41万ユーザーが利用している
- Mroonga→Mroonga分割→Elasticsearch検討→Amazon CloudSearch検討←いまここ
- Mroonga3.xの問題として数千万件のデータになると上手く動かなくなった
- この状態で数億規模のデータで運用していくには無理がある
- Elasticsearch 0.9を検討してみた
- かなりがっつり知っていないと運用できない。インデックスの再作成やシャードの再作成など試しながらやってきたが運用は大変
- プロダクションで運用するなら、かなり大きめのインスタンスを数台用意しないとダメなレベル
- 現在はカイゼンされているかもしれないが、この時はバックアップ、Multi-AZ、アクセス制御が出来ず困った
- もうちょっと楽が出来ないかと思っていたところにAmazon CloudSearchの大規模アップデートがあった
- Amazon CloudSearchはフルマネージドサービス
- 検索速度も速くMulti-AZ運用もOK。アクセス制御も希望する形で行える
- ChatWorkは日本語のみではなく17言語でサービスをしている
- Amazon CloudSearchは複数言語対応
- 初期投入するデータは3.2億件!!なにその規模!すごい!
- Indexは多言語用1つと、それぞれの言語用に各1つ
- 言語判定は別途ライブラリを使いアプリ側で実装
- 3.2億件を投入してみたところ、30並列で処理して12時間程度かかった
- 差分投入はある程度の塊になったら投入している
- Amazon CloudSearchは素晴らしいが課題もある
- 現状記号の検索に対応していないので、アプリケーション側で対処する必要がある
- CloudWatchのメトリクスがないので代替え手段で監視している
- search、request発行側をスケールアウトするにはProxyが必須
- アクセスポリシーはグローバルIPのみ指定可能で、即時反映されない。40分以上かかることもある
- Mroonga分割時と比べるとコストは2倍になった
- RIが今のところ存在しないのでコスト圧縮する方法がない
- Amazon CloudSearchを導入したおかげで、保守運用は劇的に楽になった
- 検索速度の向上やデータ反映時間の短縮も行えた
- フルマネージドサービスなのでアプリケーションの構成がシンプルになった
- AWSから日本語のサポートを受けることが出来る
- 3.2億件以上のデータを利用しているとは驚きました
- Amazon CloudSearchはこれからも利用事例が多く出そうですね
展示スペースを見学
- Amazon Fire Phoneの動作している実物があるというので、真っ先にブースに向かう
- 実物がなくAmazon Fire TVならすぐ触れますとか・・・
- 何度目かでやっとあった!
- 通訳の人がいろいろ話してくれたので安心
- Unityが最初から入ってるのか?
- 目の位置を認識して十字の線で傾きとかを見てるみたい
- だから目を隠すと画面のサルが認識できずに探す動作を始めてた
- 想像していたよりも結構楽しいなーという印象
- 他にも色々とまわったりしてみたが、運用とか監視系の出展が多めだった印象
【ナイトイベント】JAWS-UG 勉強会 in AWS Summit Tokyo 2014 #NE-01
- 参加者が結構多かった
- いろいろやってたら、もうLTの時間だった
- Werner Vogels / @Werner とのディスカッション見逃し気味
- というか Werner Vogels / @Werner JAWS DAYSのTシャツ来てるじゃん!すごい!
- LTはさすがの芸人さん。阪神のバースだよBaaS。
- Werner Vogels / @Wernerが登場するとは!場に合わせて演出を変えてくるとか
- LTは超盛り上がってた。楽しかったなー
- いつ見てもネタを考えるところからすでに最高ですよねー芸人さん
- LTが終わればみんなお待ちかねのウルトラクイズです!
- これが本番!ウルトラクイズ前にre:Inventに申し込むと負け犬といわれると言う噂もw
- サミット会場で流れていたスライドにあった問題や、比較的簡単な問題が続き結構な人数が残ってました
- そして大幅に人が減ったのがスーパーコンピュータ「TOP500」リストの最新版でAWSは何位か?という問題でした
- このリストが6月に更新されAWSの順位が変更されていたので、前のリスト順位を選択した人が多かったようです
- 運よくというか、以前参加したHPCのセミナーで最新のリストでは順位が落ちているという話をしていたのを覚えていたので、この問題はセーフでした
November 2013 | TOP500 Supercomputer Sites
June 2014 | TOP500 Supercomputer Sites
- で、結局なんやかんだで壇上に上がるところまで行った!
- この時JAWS DAYSのスッタフ赤Tシャツで会社のTシャツ着ていないことを思い出すw
- その件は正直すまなかったです。はい。
- 壇上に上がって胸熱!な展開かと思いきや、セキュリティの問題で落ちる・・・
- しかも、普通に英語のin とof の用法がわかってれば答えられたんじゃね?的な問題だったので恥ずかしい・・・
- 昨日聞いた「Security Deep Dive」で言ってたじゃん。
- security in the cloud がユーザーの責任
- security of the cloud がAWSの責任
- これ忘れないと思うので良かったのかもしれない
- クイズは進みやっぱり不正解者が出るのはセキュリティの問題
- SOC 3の話しで全滅!これは去年出た問題で間違ったので覚えてた
- で、全滅からの敗者復活ですね。これも恒例。
- 今回の条件はAWS認定資格保有者でアソシエイトレベルの3つの資格を全部保有している人
- そして、今回の会場で日本語版が解禁されたSA プロフェッショナルを持っている人が対象でした
- ウルトラクイズに勝ち残るには資格を全部保有していた方が有利だということを学びましたw
- MFAの数字桁数で落ちる人がいたり、なんだかんだで最後に残った1人はSanSanさんの中の人でした!おめでとうございます!
- 最後まで盛り上がったAWSサミットでした
- クイズは悔しかったなーre:Inventは1回は行ってみたい!
- 次の週には中央線もあるので楽しみはつづきますねー
以上です。