クラスメソッド株式会社さんの勉強会、re:Growth 2015 SAPPORO に参加してまいりました。

イベントについて

クラスメソッドさんは、あのDevelopers.IOを運営されている注目度急上昇中の企業です。
今回のイベントはAWS re:Inventの内容を踏まえて、クラスメソッドさんのメンバーがAWSに関するセッションを行う内容でした。

今回のイベント公式は以下です。

【クラスメソッド勉強会】re:Growth 2015 SAPPOROを開催します【feat. SORACOM】 #cmdevio #soracom
http://dev.classmethod.jp/news/cm-regrowth-2015-sapporo/

こちらのイベント、公開当初は定員数は30名強でしたが、connpassを今日見直してみると、定員が90名に増加しているじゃありませんか！

会場も2つに増えており、今最も熱い IoTプラットフォームSORACOM様 もご登壇されるとのことで、かなりスケールアアップていました。

セッションについて

メイン会場、サブ会場での2会場にありました。

公式をご覧くださるとわかりますが、セッションのテーマは、次のような感じでした。

  • メイン会場・・・セキュリティ、IoT
  • サブ会場・・・データアナライズとAWSコンポーネントの紹介

自由に移動できるスタイルでしたが、濃いスケジュールでセッションごとの休憩時間はなく移動はちょっとしにくかったです。
私は機械学習に興味があり、ずっとサブ会場におりました。

セッションの内容

私のメモからセッションの内容を簡単にまとめます。

ビッグデータ観点で見たre:Invent

スピーカー：石川さま

  • re:Inventでビックデータ関係のアップデートはあまりなかった

QuickSight

  • QuickSightはクラウド上のビジネス・インテリジェンス（BI）サービス
  • SPICEと呼ぶAWS独自開発の処理エンジンによって、1秒でデータのビジュアル化を行う
  • 列指向、カラム圧縮、I/O少ない、インメモリ、SQLライク
  • データストアはオンプレもOK
  • データを読み取って「こういったグラフが出せる」というところまで自動で行う
  • UIとコンポーネントに分かれており、QuickSightAPIでデータがやり取りされる
  • 従来の1/10の低価格

Kinesis

  • Kinesisはデータのストリーミング、ストリーミングデータのロードおよび分析をまとめて行うことができるコンポーネント
  • コンポーネントが増えた
  • Kinesis Analyticsが従来のサービス
  • Kinesis FireHoseは運用が楽なマネージドサービス
  • まずはFireHoseを使って、要件を満たさなければAnalyticsを使うのがベター

RDSがMariaDBに対応

  • スレッドプールやパラレルレプリケーションが
  • プラグインは利用できないが今後に期待

Database Migration Service

  • 新しいサービス
  • 停止なしでDBを移動できる
  • オンプレからRDSへマイグレ―トすることも可能
  • コンバージョンツールの提供があり、異なるエンジンでもコンバージョン可能

Amazon Machine Learningと機械学習

スピーカー：平田さま

ご紹介のあった関連エントリ

良品計画様とAmazon Machine LearningのPoCを実施しました
http://dev.classmethod.jp/cloud/aws/amazon-machine-learning-poc-with-ryohin-keikaku/

あきんどスシロー様とAmazon Machine Learningを用いた待ち時間予測の精度向上を実施しました
http:// dev.classmethod.jp/machine-learning/amazon-machine-learning-akindo-sushiro/ 現在は削除

※Itpro様に寄稿された記事もあります。

Amazon Machine Learning

  • データ投入、予測モデル、公開まで一貫して行うサービス
  • データさえあればとても簡単に予測モデルの構築が可能
  • モデルの自動更新も可能
  • 予測精度を向上させるためには予測データをいかに作るかがポイントとなる
  • そのため、業務の知識と機械学習の知識両方が必要

機械学習とはなにか

  • 不明確な環境の中で自動的にパターンを見つけ未来の予測や意思決定などを行うための手段

機械学習の扱う問題には

  • 教師あり
    訓練データを与えたときに正解を与えることができる
  • 教師なし
    正解を提示できない場合に利用する
    類似度などの分析に向いている
  • 強化学習
    エージェントの戦略を早発していく学習を行う

Amazon Machine Learningでは「教師あり」が採用されているらしい

re:Inventで発表されたAWS Lambdaの更新情報と使い方考察

スピーカー：横山さま

Lambda

  • サーバ管理が不要でコードが実行
  • 継続的スケーリング
  • イベント駆動

アップデート内容

  • Pythonに対応
  • cron/rateに対応しスケジューリングが可能に
  • VPC対応_予定_

利用例

  • 定期的にインスタンスを起動・停止する
  • Twitter botを実装する

まとめ

  • Pythonが使えるようになったのはGood
  • cron/rateの実行間隔は5分
  • スケジューリング用のEC2が不要
  • スケジューリングできることは、実はかなりすごい

AWS Database Migration Service の紹介

スピーカー：川原さま

  • 現在はプレビュー
  • 最小のダウンタイムで簡単にDBを移行することができる
  • レプリケーションの仕組みを利用している
  • オンプレからAWSのストレージにも、AWSのストレージからオンプレにも移行が可能
  • ただしオンプレからオンプレには移行できない
  • 1TBのDBを移行する場合の所要時間は2.5時間らしい
  • AWS Schema Conversion Toolを利用すれば異なるデータベースプラットフォーム間での移行も可能
  • AWS Schema Conversion Toolの動作デモ

Amazon Aurora Deep Dive

スピーカー：渡辺さま

Amazon Aurora

  • Amazonが考えたさいきょうのRDS
  • RDSのMySQLが限界なので、オーロラを作った
  • MySQL(5.6)互換
  • MySQLの5倍の性能
  • 同様の機能や可用性を提供している商用データベースの1/10の価格
  • Tokyoリージョンも開設

MySQLで何を行っていたか

  • マルチAZの場合、プライマリからスタンバイに同期される
  • I/Oの指定で見るとかなり大変なことになっていた
  1. EBSへの書き込みのissueがある
  2. EBSミラーリングのための2重書き込み
  3. MySQLのログ、バイナリログなどを書き込み
  4. MySQLオプションのDouble Write
  5. メタデータの処理
  6. プライマリの正常処理後、スタンバイで処理する
それはつまり
  • 同じデータの4重書き込み
  • マルチAZで、プライマリとスタンバイで同じ処理
  • シーケンシャルである必要があり非同期にできない

現在求められているもの

  • 高可用性
  • 高耐久性
  • 横にスケールすること
  • ストレージは壊れるという前提
  • 並列処理
  • I/Oは少ないほど良い

そこでAurora

追記のみ
  • 追記型のLog-structured Storageを採用
  • HDのようなランダムアクセス処理を捨て高速化
  • redo logを順番に飛ばしていく
  • S3と相性が良い
可用性
  • 3AZで6本のストレージを持つ
  • デフォルトでマルチAZのようなもの
データの保証
  • redo logに採番してしっかり管理する
  • データ書き込み時は順番を考慮しない
  • それは採番した番号をもとに後で整理すればよいから
  • 6台のストレージがそれぞれ非同期で稼働しており
  • もしログ99の次にログ101が届いたら、仲間にログ100を持っているか問い合わせる
  • Boxcar同士が情報交換する仕組み(ゴシップ?)
速度
  • ログ書き込みのラインがシンプルに
  • redo logを6つのストレージに並列で書き込む
  • 4/6の書き込みが完了すればOK
  • 応答時間が早い
  • ログ書き込み速度が6倍
  • I/Oトラフィックが1/9

感想

濃くて難しいお話をたくさん聞くことができましたが、 常時興奮しっぱなしであっという間の2時間 でした。

また、クラスメソッドさんは玄人ぞろいというイメージでしたが、それは間違いではありませんでしたね。
12月にも合同イベントがあり、そちらも参加したいと思います。