ITと哲学と

IT系エンジニアによる技術と哲学のお話。

人工知能研究会なるものに参加させていただきました

下記の研究会に参加させていただきました. 学生さんが主体でやっている研究会だそうです.

第17回 人工知能研究会「今後のDeepLearning技術の発展とビジネス応用」 https://air-osaka.doorkeeper.jp/events/60057

今日の研究会で聞けた内容が良かったのでお話を聞きながら取ったメモを晒します.

ビジネス応用

ビッグデータ解析と人工知能の違い

ビッグデータ解析は解析しておしまい. 一回では大抵良い結果は出ないのでうまくいかない.

人工知能はシステムを利用するたびに精度が上がっていく. 実運用しながら精度が上がっていくのが人工知能の特徴.

溜まったデータを解析することが目的となってはいけない. 何がしたいのか?そのために必要なデータはどんなデータか?を固めていくことが大切.

そしてデータは必ずしもビッグでなくてはならないわけではない

AIを導入しやすい領域

技術的課題

AIとの親和性が高い(ルール化・パターン化されている) データが取りやすい

社会的課題

AIが失敗しても被害が少ない(人が死なない・大損しない) AIに否定的な人が少ない

  • クラスタ別に分析が資料上ではありました.*
  • あの資料欲しいな・・・*

ビジネス利用のための人材育成のお話

データサイエンティストとして備えておくべきもの

  • 統計学
  • プログラミング
  • ビジネス知識 => お客さんの課題をどうAIに落とし込むか

それ以外にも幅広い知識が必要 物理とか数学とか心理学とか英語とか.

統計:理由を説明する学問.要因を見つける. 例)アイスクリームの売り上げを分析して主因を見つけたりする

機械学習:予測.当てればそれでいい.予測精度の追求. 例)アイスクリームの売り上げさえわかればいい!

AIシステム構築の流れ

課題設定=>AIモデル設計=>データ取得=>データ前処理=>アルゴリズム実装=>分析=>結果=>AIモデル設計へフィードバック

この流れを繰り返すのがとても大切. このために,データサイエンティストには幅広いアルゴリズムの利用経験と知識が必要.

よくある誤解

とりあえずネットワークにデータぶち込んだらええやん

分類精度をあげるには,データ前処理がとっても大事. 手法選定とかチューニングとかは支配的ではない. データ前処理が何より支配的!

データ前処理は実データ解析において重要. 手法の選択は研究において重要. チューニングはコンペにおいて重要.

一般物体認識と詳細画像識別の違いを把握しておく

一般的に誰が見ても明らかなものの比較と,専門家ではないと判断が難しいものの識別では難しさが当たり前だけど違う.

一般物体認識であればとりあえずデータをニューラルネットワークにぶち込んだらええ.ここら辺はよく論文として扱われる範囲. だから上のようにとりあえずぶち込んだらええやんという誤解が生まれる.

実社会で求められるような詳細画像識別ではこれだとワークしない.適切な前処理をしてあげることが大切.

データが大量に必要だが,質も大事

分析に適するデータベースは縦長(特徴量の次元に対してデータ量が多いという意味). 横長のデータはデータ量を増やして縦長にしてあげる必要がある. 要するに過学習の話だなきっと.

分類対象が増えても問題がない

分類するものが少ないほど精度が上がります. これは当たり前の話だと思うなぁ・・・よくある誤解なのかー

講師の考える今後大事になってくるDeepLearning技術Top4

DeepLearningは伸び代がやばい. 今できることって氷山の一角. 5年後,10年後にできることはもっといっぱいある.

これまでの技術と比べて複雑なモデルを扱えるようになってきた. 複雑であるがゆえに,表現度が高くなった.

2016年の現状 音声認識:実用レベル 画像認識:開発レベル~実用レベル 言語認識:研究レベル

2017年の現状 音声認識:実用レベル 画像認識:ほぼ実用レベル 言語認識:研究レベル~開発レベル

ということで講師が考える今後大切なDeepLearning技術Top4を紹介

第4位 転移学習

データが大量にあるドメインで学習させたモデルをデータの少ないドメインに使う. ドメインが大きく違っても高い精度が出るので一般的によく使われる. 別データで学習させたモデルを使って再学習させる.

コンペとかで優勝したモデルを使って転移することが可能. 画像系と音声系でかなり有効 テキストなどではあまり有用性が確認されていないとのこと.

One-Shot学習というものもある. 転移学習よりさらに少ないデータで学習させる. すでに作成されている特徴量空間に新たなクラスをプロットさせる方法. 少ないデータで学習可能だが,分類対象が増えると難しくなる.

第3位 DCGAN

絵の生成とかに使われる. 生成系と判別系のネットワークを戦わせて学習させていく. より本物に近い絵を作り出す技術っぽい.

画像の一部を欠損させて復元させる技術もある.

第2位 DQN

AI同士を戦わせてより強くしていく. 計算コストかかる.相当なリソースを持っていないと強化学習的な手法は難しい.

囲碁のように勝ち負けが明確な場合は有効だが,現実的な問題として良し悪しがわかりにくい問題については 強化学習のアプローチは難しかったりもする.

第1位 マルチモーダルDeepLearning

あらゆる構造のデータを同時に学習して概念を獲得してく. 言語認識精度の向上が見込まれる.

動画とか音声とかテキストとか数値とか,異なる構造のデータを同様に用いる.

テキストから動画を生成したりすることも可能になってきている.

ELBがApplication層でのロードバランシングに対応したらしい

AWSのELBが、Application層でのロードバランシングに対応したらしいです。 Application層で動くロードバランサーということで、ALBと呼ぶらしいです。

Application層で動作するロードバランサー

通信機能を7つの階層に分割するOSI参照モデル(物理層データリンク層・・・などに分割するモデル)の最上層であるアプリケーション層で動作するロードバランサーです。

アプリケーション層で動作するため、この層で使われているHTTPというプロトコル等をもとに負荷分散をすることが可能になったようです。

現状(2016/08)のALBはHTTPリクエストのURLを用いてバランシングすることができます。

ELBでできなかったことと、ALBでできるようになること

ELBは通信を受け、処理を自身の配下のインスタンスに振り分けるという働きをしてくれていました。この際に、全ての処理を同一グループのインスタンスに負荷を分散しながら振り分けるというのがELBの挙動になります。

一方で、ALBではリクエストのURLに基づいて処理を割り振るグループを選択することができるようになります。

例えばhttp://example.com/*へのアクセスはデフォルトでGroup1に振り分けつつ、http://example.com/fugaへのアクセスのみGroup2に割り振るといったことが可能になります。

利点

これにより、より粒度の小さいサービスの組み合わせによるサービスの提供が可能になります。

例えば、ユーザーというドメインCRUDするようなアプリケーションがあったとします。

http://example.com/user/createでユーザーを作成し、http://example.com/user/delete/{id}でユーザーを削除することができるとします。

ELBでは、ユーザーのCRUD機能を全て実装したサーバーをグループに入れておいて、http://example.com/へのリクエストを各グループに負荷分散して処理を振り分けていました。

これがALBではユーザーのCRUD機能をモノリシックに用意する必要がなくなります。

CreateやDeleteなど機能を単体で用意しておき、それらをGroup1とGroup2にそれぞれ格納します。 そして、http://example.com/user/createへの通信はGroup1に処理を振り分け、http://example.com/user/delete/{id}への通信はGroup2に処理を振り分ければいいわけです。

これによって、よりマイクロなサービスの組み合わせでサービス全体を提供することが可能になるわけです。

ALBを使う上で気をつけたいこと

deployの話

アプリケーションのdeploy周りについては考える必要が出てくる気がします。

ELBを使っていた場合はユーザーのCRUD機能が一枚岩で提供されていたので、deploy時にはまるっと入れ替えることができました。

これがALBを使っている場合はCreate機能やUpdate機能が分割できてしまうので、新旧を無停止で入れ替えようとするとタイムラグが起きて問題になる気がします。

今回は例を示す際にユーザーのCRUD機能をあげましたが、分割の単位はドメインごとに切るなりなんなり、サービスにあった切り口を考える必要があるでしょう。

可用性の話

各グループにそれぞれ別の責務を負わせるわけで、それぞれのグループで可用性を確保する必要があると思われます。複数AZで各グループ用のインスタンスを起動してあげる必要があるでしょう。 結構構成が煩雑になりそうなので、CloudFormationによるコード化はしておいたほうがいいかもしれません。

CloudFormationにはすでにALBも対応しているようで、AWS::ElasticLoadBalancingV2::LoadBalancerというようにElasticLoadBalancingV2ってやつを使ってあげればいいみたいです。

MySQLのスキーマ変更をオンラインでやるための選択肢比較

MySQLを使っていて、スキーマを変更したい場合はAlterTableを流す必要があります。 すでに稼動しているサービスのスキーマを変更する際に、可能な限り稼働中システムに影響を与えずにスキーマの変更を行いたいです。

理想はオンライン状態を保った状態でAlterTableが全て完了することで、これが実現できれば少なくともスキーマ変更に伴うメンテナンスのためのダウンタイムが発生しません。

これを実現するためには幾つか方法が存在し、制約もあるみたいなので調べてまとめてみました。

その前にAlterTableのこれまでの挙動を調べる

オンラインでのスキーマ変更を調べる前に、まずはAlterTableの伝統的な挙動(MySQL5.1まで)について簡単にまとめてみます。これによってオンラインスキーマ変更のために何が問題になっているか?が理解できると思います。

MySQL5.1までのAlterTableは、変更したいスキーマ定義に沿った空のテーブルを作り、そこに古いテーブルのデータをコピーすることでスキーマの変更を行います。 この際にデータの不整合を防ぐため、まずは古いテーブルへのデータの書き込みをブロックするlock状態に入ります(ちなみに、古いテーブルからデータが読み込まれたとしても、新しいテーブルへのデータコピー時に不整合は起きないため、読み込みはブロックされません)。

つまり、AlterTable実行中は書き込みがlockされるわけです。 古いテーブルに大量のデータが入っている場合には、新しいテーブルへのデータコピーに時間が掛かるわけなので、書き込みlockによるメンテナンスのためのダウンタイムがどんどん伸びていくわけです。

これがMySQL5.1までのスキーマ変更の挙動でした。

参考にさせていただいた記事はこちら

MySQL5.6からサポートされているオンラインDDL

DDLはデータ定義言語というもので、データベース自体を操作するためのSQL命令文のセットです。 AlterもDDLに含まれます。

多くのAlterTableの操作時に、上記のテーブルのコピーが発生しないようにする変更と、テーブルが変更されている時でも書き込みがロックされないようにした変更の2つを合わせてオンラインDDLと呼ばれています(ちなみに念のためですが、ロックが発生しないだけで、性能上の影響は当然出ます)。

あくまで 多くのAlterTable時であり、全てにおいてコピーが発生せず、書き込みがロックされないというわけではありません。 ざっくり書き込みロックされるされないで分類してみます。

書き込みロックされない

インデックスの作成,追加,削除 カラムのデフォルト値を設定する カラムの自動インクリメント値を変更する 外部キー制約を追加,削除する カラムを名前変更,追加※,削除,並べ替え 主キーを追加する ※オートインクリメントカラムの追加を除く

書き込みロックされる

全文検索インデックスを追加する カラムを追加する(オートインクリメントカラムの追加) カラムのデータ型を変更する 主キーを削除する 文字セットを変換する

参考にさせていただいたのはこちら

つまり、MySQL5.6からは変更の内容によりますが、AlterTable実施時にロックが発生しないケースもあるということです。

pt-online-schema-change

Percona-Toolkitという有名なツールキットに同梱されているpt-online-schema-changeというツールがあり、こちらを使うことでも読み書きロックなしでオンラインスキーマ変更が可能です。

pt-online-schema-change(長いので以後PT)はMySQLのAlterTableの挙動を内部的に再現してスキーマの変更を行いますが、工夫することでロックなしでの動作を可能にしています。

MySQL5.1では古いテーブルの書き込みをロックしてデータの不整合を防いでいました。 これに対して、PTはトリガーの仕組みを使うことで、書き込みロックを行わずにデータの整合性を保ちます。 古いテーブルから新しいテーブルへのデータコピー中に古いテーブルに対して更新が走った場合、トリガーが古いテーブルのデータ更新に伴って新しいテーブルのデータも更新するわけです。

トリガーはInsert, Update, Deleteの3種類全てが貼られます。 そのため 1つのテーブルに対して同じ種類のトリガーは貼れないため、トリガーがすでに貼られているようなテーブルにはPTは使えません。 なお、トリガーはMySQL5.0.2からサポートされるので、PTはMySQL5.0.2以上で動作するそうです。

参考にさせていただいたのはこちら

比較とまとめ

MySQLのオンラインDDLでもPTでもそれぞれ制約はありますがオンラインでスキーマ変更が可能であることがわかりました。オンラインDLLは、オンラインで実行可能なスキーマ変更の種類に制約があり、PTでは既存トリガーの有無が制約になることがわかりました。 また、オンラインDDLはMySQL5.6から、PTはトリガーをサポートしているMySQL5.0.2から動作することがわかりました。

次に性能比較ですが、こちらの記事によると、スキーマ変更にかかる時間は対して変わらないものの、スキーマ変更中の影響という観点からはPTの方オンラインDDLよりも小さいそうです。 さらに、PTでは設定できるオプションが多く、既存システムへの影響を考えながらきめ細やかな実行戦略が組めそうです。 サイバーエージェントさんのこちらの記事にある慎重に使うオプションや過去の失敗事例もすごく参考になります。

以上です。

機械学習のコースを修了した

Stanford大学のオンライン授業で機械学習コースを受講していましたが、この度めでたく修了しました。

機械学習をお勉強したい人には強くお勧めできる内容だったのでアウトラインだけ共有しようと思います。

ちなみに受講自体は無料です。 終了証明を取得したい場合はお金かかりますが、完全に自己満なのでどっちでもいいかと思います。

概要

機械学習の世界では知らない人はいない(?)というくらい有名な先生がわかりやすく機械学習の面白いところを教えてくれる動画授業です。

各動画には小テストがあり、自身の理解度を確認しながら進めることができます。

週に1トピックスの内容を学ぶスケジュールでコースは設計されており、1週間分の動画を全て見た後にはoctaveという言語を用いて実際に学んだ内容を実装してみるプログラミング課題を解きます。

動画授業を受けるだけではなく実際に手を動かしてみるので、理解度が上がります。

学習できる内容

毎週のトピックはざっくり以下の通りです。

線形回帰について

コース全体を通して使われる基礎的な考え方が説明されます。 コスト関数とか最急勾配法とかの説明がされます。

ロジスティック回帰について

線形回帰から派生してロジスティック回帰についてです。 線形回帰で扱えない問題の説明と、それを扱うためのロジスティック回帰の説明です。

ニュラルネットワークについて

今はやりのDeepLearningにつながるニューラルネットについてです。 ニューラルネットのアイディアの説明と、ロジスティック回帰との関連性についてわかりやすく説明されています。

機械学習を用いたシステムを開発していく時の注意点について

機械学習を用いたシステム開発を行う上で身につけておくべき考え方や評価指標についてです。 これを知らないでシステム開発を行うのは時間の浪費だとはっきり理解できる構成になっています。

具体的には学習曲線を用いたアルゴリズムの評価方法を学びます。

自身の構築しているシステムについて、アルゴリズムが適切なのか?学習モデルは適切なのか?学習サンプルを増やすことで性能改善が見込めそうか?それとも学習サンプルを増やしても別の問題が起きているので性能改善が見込めないのか?といった知見を得られるようになり、次に試すべきことが判断できるようになります。

SVMについて

ロジスティック回帰から派生してSVMについてです。 SVMの利点とかが説明されます。

教師なし学習(クラスタリング)について

教師なしデータに対する機械学習の例についてです。 得られたデータをクラス分けする方法を学びます。

具体的にはk-meansアルゴリズムを使ったクラスタリングを学びます。

異常検知学習について

こちらも教師なしデータについての機械学習です。 「いつもとなんか違う!」を検出する方法を学びます。

具体的には得られているデータから事象の確率を求め、 異常に低い確率でしか発生しないデータが得られたら「いつもと違う!」と判定するようなアルゴリズムについて学びます

大規模機械学習について

大量データを扱う上での注意点とかそこらへんのトピックスが説明されます。この内容についてはプログラミンング演習はありません。

Photo OCRを例とした機械学習ワークフローについて

複数の機械学習コンポーネントを組み合わせて開発を行う上でいかに全体最適を満たすために開発リソースを割り振っていくか?というないようです。

大きくて複雑なシステムを効率良く開発していくために必要な知見が得られます。

まとめ

以上長くなりましたが、こんな内容を学ぶことができます。

高度な数学的な背景は知らなくても理解できる講義になっているので興味のある方は是非受講してみてください!

ちなみに最後まで受けると有料ですが、受講証明書をもらうことができます。 完全に自己満ですが、かなり良いコースだったのでお礼の意味も込めて取得しました。

CloudFormationでストリーム名を指定してKinesisストリームを作成することができるようになりました!

2016/06/09のアップデートでストリーム名を指定してKinesisストリームを作成することができるようになりました!

https://aws.amazon.com/about-aws/whats-new/2016/06/aws-cloudformation-adds-support-for-amazon-vpc-flow-logs-amazon-kinesis-firehose-streams-and-other-updates/

詳しい方法は下記をご参照ください。 http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-kinesis-stream.html

ここでは簡単にCloudFormationに用いるJsonをご紹介します。 と言ってもかなり直感的にNameを指定してあげたらいけます。

{
  "AWSTemplateFormatVersion" : "2010-09-09",

  "Resources" : {
    "KinesisSample": {
       "Type" : "AWS::Kinesis::Stream",
       "Properties" : {
          "Name" : "Kinesisストリーム名",
          "ShardCount" : シャード数
       }
    }
  }
}

ストリーム名を指定するために、わざわざKinesisストリームを別の手段で作成していたケースにおいて、CloudFormationに集約することができるようになりました!

AgileJapanOsakaサテライトにお邪魔しました

6/4に開催されmAgileJapanの大阪サテライトにお邪魔してきました。

agilejapanosaka.doorkeeper.jp

スクラムイノベーションを加速する 〜ソフトウェア以外にも適用されはじめたアジャイル〜(Joe Justice 氏)

5月に行われたAgileJapanのKeyNote映像を見ました。講演の資料は以下のリンクにあります。

http://www.event-info.jp/aj2016/Keynote1_ScrumIncAgileJapanJ.pdf

ソフトウェアの分野で広く浸透したアジャイルが、ハードウェアの世界でも使われ始めているというお話でした。 幾つかの具体例が示されれていましたが、その中でも圧巻だったのが飛行機の例です。 あんな大きな物理な物もアジャイルで作られるんですね。

1台の飛行機を1チームで作ろうとするとチームが大きくなりすぎてしまうので、2pizzaチームの枠に収まりません。 なのでこの例ではチームを7つに分解して作っていたようです。

会場からその後の質疑応答でありましたが、「チームを適切に分けるって難しいよね」的な話があり、実はこの飛行機作るチームも チームの分け方では失敗を繰り返し、試行錯誤したそうです。

ただ、なんか納得できないところもありました。 Scrum: 倍の仕事を半分の時間でこなす技(上記資料より引用)とか認定スクラムマスター資格を持ったコーチがチームにいれば生産性が2~4倍上がる的な話がありました。

個人的にはこんなの見てしまうと、ほんまかよ、と身構えてしまいます。 あんまり僕はアジャイルとか詳しくないんですが、タスクを短い時間でこなす技だったんですかね?うーん。。。

アジャイルの論点はタスクを効率良くこなせるかではなく、変化を取り入れながら価値を最大化するといったことだと思っていました。

倍の価値を半分の時間で出すとかならまだわからないでもないのですが、倍の仕事をこなす技ってのは違う気がします。

アジャイルと比べて、WFでは変更コストが高くつくので、アジャイルと同じアウトプットに至るまでに、変更コストを払った結果、倍の時間がかかるという事であれば、それは価値の話であって仕事量の話ではないのでは。。。

なんか言葉の表現の問題な気もしてきました。原文はどう書いてあったのでしょうか気になります。

カイゼン見える化ーチームワーク(原田 騎郎さん)

すごくすごい講演でした。グサグサ刺さる刺さる。 すごいお人ですねこの方は。

衝撃を受けすぎて散文的なメモしかありませんが、再構成しながら載せます。

見える化の文脈で出たお言葉

プロジェクトが混乱するのは、何かが見えないから。

自立していて、納期を守る、従順なチームが欲しいマネージャについてのお言葉

従順であれ!的なことをマネージャが言うと、タックマンモデルの混乱期に入れない。 乗り越えられない。チームが強くならない。

自分の欲しいものを測る方法をしらないマネージャーは、結局自分の測れるものを欲するようになる。 みなさんのマネージャはいいエンジニアを知っていますか? みなさんのマネージャはエンジニアをどう評価しますか? みなさんのマネージャのエンジニアの評価軸は何ですか?

改善について

何のために改善するの? 改善って、仕事をより簡単に安全にすることだ。

改善のために時間を。 改善のための時間は優先度高い。 改善のための時間をとって、喧嘩するべき。 それをしないからクソコードを量産するんだ。

変化を抱擁して前に進むためには

変化を抱擁するには、余裕が必要だ。

  • 時間の
  • リソースの
  • 体力の
  • やる気の
  • 心の

余裕が必要だ。

これがない状態で変化を抱擁せよとか言われてもこのやろう!としかならない。

事あるごとにこれ思い出そうと思いました。

AWS Sysops Administratorを取ってきたのでお勉強メモを晒す02

前回から時間が空いてしまったが、メモのバージョン2をさらします。

Serverにログインできるサービス

以下の4つのみサーバーにログインできる * Elastic Beanstalk * Elastic MapReduce * OpsWork * EC2

Elastic Load Balancer Configurations

Sticky session types

2種類のスティッキーセッションタイプがある。 スティッキーセッションはCookieを用いて行うが、そのCookieを誰が管理するかが これらのオプションの違いになる。

Duration Based Session Stickiness

ELBがCookieを払い出す方式。 リクエストに対してまずELBがCookieの有無を確認する。 Cookieがなければ既存のELBの振り分けアルゴリズムに従ってロードバランシングする。 その後、clientにCookieを渡す。このCookieには処理を行ったインスタンスを特定する何かが含まれる。 Cookeiがあれば、そのCookieに基づいて以前処理を行ったインスタンスに処理を流す。

Cookieが有効である限りStickyセッションは継続される。 Cookieの有効期間はStickiness Policyの設定によってコントロールされる。 また、処理するサーバーに問題があった場合もCookieがなかった場合と同様に処理が委譲される。

Application-Controlled Session Stickiness

アプリケーションが指定したCookieを使う。 Cookie名をELB側に教えてあげる必要がある

有効時間が来るまでは、AutoScalingしてインスタンスを増やしても すでに確立されたセッションに従って処理を振り分けるので、 有効時間が長いとなかなかスケールしない問題があるので注意。

ELBでバランシングしているASGroup内部のEC2インスタンスが、処理メトリクスを超えたので スケーリングが走って、EC2が正しくプロビジョニングされても、新しく作成したEC2に負荷が分散されない場合は スティッキーセッションを疑いましょう。 ちなみに、EC2がプロビジョニングされずに落ちている場合はEC2のコンフィグ設定が正しいか?プロビジョニングされ切る前に ヘルスチェックに引っかかってないか?を疑ってみてください。

僕はEBS最適化をサポートされてEC2インスタンスにつけようとしてEC2が永遠に立ち上がらなかったことがあります。

今日はここまで