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が永遠に立ち上がらなかったことがあります。

今日はここまで

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

先日、AWS Sysops Administratorに合格してきました。

結果は70%と結構ギリギリな感じでした。

具体的な問題については規約上発信はできないので、学習時のメモを晒します。 受験直前とかに見てもらえると復習にはなるかも?

あ、ちなみに下記のcloudguruのコースを受けました。

https://acloud.guru/learn/aws-certified-sysops-administrator-associate

モニタリングに関するトピックス

AWSサービスの監視が行える。 HostLevelMetricsをデフォルトで監視可能。それ以外はカスタムメトリクスが必要になる。 デフォルトで監視可能なのは以下。

  • CPU
  • Network
  • Disk
  • Status Check

メモリ使用率はカスタムメトリクスであり、デフォルトでは提供されていないので注意。

デフォルトでは5分間隔で詳細モニタリングにすると1分間隔で取得。 デフォルトでは2週間データが保管される。 ターミネートされたEC2のメトリクスも同様に保管される。

カスタムメトリクスは最小で1分間隔まで。

EC2 Status TroubleShootings

StatusCheck 2/2 checks passedってEC2のコンソールに出るけどそれについて。

System Status Checks

物理的なホストで問題が生じた場合、System Status Checkに失敗する。

EC2を提供する端末のハードウェアの問題とかソフトウェアの問題。

このエラーが出た場合は、EC2インスタンスを一度停止して起動し直すことで解決出来る。

インスタンスは停止して起動すると別の物理端末上でホストされることになるので、

問題が生じたホスト以外のホストで起動し直すことができるからだ。

Instance Status Checks

VM自体の問題が生じた場合、Instance Status Checksに失敗する。 要するにEC2インスタンス自体のこと。

インスタンス自体で問題が起きているので、この問題が起きた場合はアプリケーションの設定を見直したり、 インスタンスを再起動することで解決出来る。

EBS

General Purpose SSD

  • 1GiB-16TiB
  • Maximum throughtput => 160 MiB/s
  • IOPS => 最大10kまででる

Provisioned IOPS SSD

  • 4GiB-16TiB
  • Maximum throughtput => 320 MiB/s
  • IPOS => 最大20kまででる

10k以上のIPOSが欲しかったらProvisionedの方に移りましょう

ちなみにEBSボリュームを作ると初めに5.4MのIOCreditがもらえる。これは30分間3000IOPSまでバーストできる量。

暖気運転

EBSボリュームを新しく作ったりスナップショットを適用して、初めにアクセスすると初回処理が走ってIOPSの5-50%が失われる。

事前に全領域をまずは舐めるなどして暖気しておくことで性能を発揮できる。

暖機運転としては全領域に一旦データを書きに行くことが望ましい。

が、これは新規作成したボリュームなら可能だが、スナップショットから復活させたボリュームにデータを書きに行くと消えてしまうため、スナップショットから作成したボリュームでは全てのデータを読み込むことで暖機運転を行う。

今日はここまで

第3回 大阪大学人工知能研究会にお邪魔してきた

第3回 大阪大学人工知能研究会にお邪魔してきました。

大阪大学人工知能研究会 | AIR at Osaka University - 第3回 大阪大学人工知能研究会「Deep Learning...

人工知能の勉強会で、関西から日本の人工知能研究を牽引したいというような思いで勉強会を立ち上げたとのことで、今回は色々と話題のDeepLearningの入門的な講義を聞くことができました。

講義をしていたのはなんと学部4年の方でしたが、かなり堂々と講義されておりすごい立派だなーと思いながら見てました。

内容はニューラルネットワークについてで、単一のパーセプトロンを用いた学習から多重パーセプトロンを用いた学習、そして深層学習へ、といったストーリーでした。

講義メモを取りながら聞いていたのそのまま貼り付けようと思います。

次は中級編的な内容もやりたいと思っているとのことだったので楽しみです!

結構踏み込んだ内容も多かったように感じましたが、なかなかに興味深い時間を過ごすことができました。

以下講義メモ

機械学習の基本的な知識

機械学習とは

データの集合から法則性を学ぶこと。 どんな法則性か?で色々と分けることができる。  回帰とか分類とかクラスタリングとか異常値とか

ルールベースで分けたらええんちゃうの?  =>ルールを作るのが難しいねん。それを機械学習ではデータをもとに勝手にやってくれるねん。すごいねん。

パーセプトロンとは?

順伝搬とは

人間の脳を模倣できるモデルを作るのがニューラルネットワークの発祥。 シナプスを模倣したものがパーセプトロン

複数の入力を受け取って、何らかの出力をする。 その際に入力から出力方向へ一方向へデータが流れ、逆流はしない。 これを順伝搬という。

入力データXと重み関数Wを使って、内部状態はXWの内積で求まり、これらの内部状態に活性化関数を適用して出力値が決まる。 sigmoid関数であれば内部状態の値によって0~1の状態を取る。

学習について

与えられたデータをもとに、望ましい出力が得られるようにモデルを改変することを学習という。 重み関数Wとバイアスがパラメータになる。

学習を複数データに繰り返していくことで、重要な情報とそうではない情報を見極めるモデルを構築することができる。

パーセプトロンの学習則を日本語で説明すると新しい重みは、古い重みを、一定の割合で、教師データと出力データの差分を、関与した分だけ更新すると言い表すことができる

単純なパーセプトロンでは線形分離可能な問題を解くことができる。  =>直線的な線で境界を引くことができるような分類問題のこと。

多層パーセプトロン

パーセプトロンをくっつけて、神経網を模したモデルを作る。これを多層パーセプトロンという。

入力層

inputデータの構造に合わせて形状が決まる。 1入力が1ノードに入る構造になる。

中間層

ノードのパラメータが色々とある。 パラメータの選択は結構難しくて職人技になっている。これを自動化したいという研究もある。

出力層

分類問題であれば、分類したいクラスの数だけノードを用意する。 出力関数は一般的にソフトマックス関数になる。

回帰問題であれば出力したい値を1つ出すノードを1つ用意する。

扱いたい問題を理解して、それに合わせた構造を作ることが大切。

多層パーセプトロンの学習について

与えられたデータをもとに、望ましい出力が得られるようにモデルを改変する。

学習には「損失関数」を用いる。

出力データと教師データがどれだけ違うかを示したもの。 問題によって損失関数を決める。 例えば回帰であれば二乗誤差だったり、多クラスの分類問題であれば交差エントロピーだったりする。 なんにせよ、出力と教師データをできるだけ似せたいので、損失関数を最小化することが大切。

具体的な学習は勾配降下法を使って学習していく。 損失関数が下に凸の関数であれば勾配降下法で最適解まで行ける。 局所解を持つような損失関数であれば、そこに落ち着いてしまうこともある。

勾配計算について

教師データと推定結果の差を計算するわけなので、出力層の勾配計算は簡単にできる。教師データがあるわけだから。

ではそれがない中間層はどうしたら良いか?中間層の理想的な値はわからんよ?

その場合には誤差伝搬法を使う(逆伝搬)

あるべき値と学習データの差をデルタと呼ぶと、前の層のデルタは、次の層のデルタを結合で集約したものに、活性化関数上の自分の値を微分した値をかけることで求めることができる。 ここで微分を計算する必要があるので活性化関数は微分可能な関数を用いる。ヘブサイド関数は使わないでsigmoid関数とかを使う。

確率的勾配降下法とは?

全データを使った学習を行うと、局所解に陥って局所解に陥ることがある これを避けるのが確率的勾配降下法

全訓練データをミニバッチに小分けして学習する。 こうすると損失関数の形状がミニバッチの選び方によって若干変わるので、局所解に陥る可能性を下げることができる。

モデル評価

訓練データで学習させて、未知のデータを推論させる。 なので、得られる教師データの全てを学習データにしたらいけない。評価のためのデータは取っておくこと。

多層パーセプトロンの問題点

中間層を増やしてみると、うまく学習ができない。。。と言う問題があった。 初期値がうまく設定できていない例は以下にある。 W1とW2の初期値をいい感じで設定する必要がある。 この例では初期値は正規分布に従う乱数でも事足りるが、さらに多層になっていくとそれでも全く学習がうまくいかなくなる。

GitHub - masamasah/perceptron: 第3回 大阪大学人工知能研究会で学んだ多重(2重)パーセプトロンを用いたMNISTデータ学習のサンプル

これを引き起こしていた問題は2つある

勾配消失問題

ニューラルモデルを深層にすると、勾配がめちゃめちゃになるので学習が適切に行われなくなる問題が起きていた。  =>つまり重みが適切に計算できないということ。劣決定問題的なイメージかな?と講義を聞いてて思った。

過学習問題

訓練データに追従しすぎてテストデータに対して良い精度が得られない問題。 不必要に高次元な関数によるフィッティングになりすぎてしまうことがあるっぽい。

訓練データをできるだけたくさん用意することで過学習問題を緩和できる。

DeepLearningの始まり

各層の初期値をいい感じにすると過学習問題が解消できるということから深層学習いけるやん!ってなった。 いい感じにするには?事前学習ということを行って初期値をいい感じにしておく。 これには確率的・決定論的2つの方法がある。

今回の講義では決定論的な方法を説明する。

決定論的な方法

自己符号化器というやつ。 自分自身を再現できるようにモデルの学習を進める。 特徴表現学習とも呼ぶ。

この初期値を使うことで、情報をうまく伝搬しやすい重みの初期値を得ることができる!

各層についてそれぞれ事前学習を行うことで全ての層の初期値を効果的に得ることができる

畳み込みニューラルネットワーク

いろいろなニューラルネットワークがあるが、その中で結構有名なニューラルネットワークはこれ。

畳み込みニューラルネットワークは、人間の視覚野を模擬した構造を持っている。 画像認識に特化したモデルであると言える。

畳み込みニューラルネットワークはDeepにしても事前学習が不要という利点がある ただし、学習にとっても時間がかかる。GPUの計算リソースは必須。

ちはやふる下の句を見てきた(ネタバレあり)

ちはやふる下の句を見てきました。

上の句がかなり面白かったので、結構期待して下の句も鑑賞してきました。 ネタバレあります。

結構楽しかったです。

上の句でもそうでしたが、映画が始まって最初の方はなんとなくあまり乗れず、楽しめないかなーと思っていたのですが、物語が進むにつれて引き込まれていきました。松岡茉優さんと上白石萌歌さんが良かったです。

下の句では特に、吹奏楽の演奏のくだりから先が良かったと思います。 お礼に応援しよう!と、きっと吹奏楽部の人たちは思ったんだろうなーと。 吹奏楽部の人たちにもきっとそんな感じの物語があるんだろうなと想像ができて良かったです。 また、威風堂々の使い方が感動させつつ笑わせつつで、とてもスマートだったと思います。

その直後の「階段の中央は神の通る道だから通っちゃダメだよ」の後に、そこを通ってしのぶが堂々と上がってくるところ、それを受けてのちはやのリアクションから、クイーンやべえ只者じゃない感が伝わってとても良かったです。

あとはやっぱり最後の「ちはやふる」のシーンも良かった。上の句でも歌とストーリーの絡め方が面白かったですが、下の句でも健在でした。 ちはやの背中のシーンからも、ちはやも同様に只者ではなくなったんだ感が出ていてとても良かったです。

ただ、わざわざ声に出して言わなくていいよなーとか、一番楽しかったのそこ?他のメンバー入ってないやん!とか若干きになるところはありました。 あと、最後の最後のシーンで札を読むのはかなちゃんにして欲しかったなーとか。

まあなんにせよかなり楽しめましたお気に入りです。 続編もあるみたいなんで楽しみにしてます!

あれ?もしかして下の句でちはやって一度も勝ってないんじゃね?

CloudWatchにおけるEC2のStatusCheckについて

EC2の一覧画面に行くと、StatusCheck 2/2 checks passedとか書かれているのですが、それってなんなの?ということで調べてみた。

クリックするとSystem Status ChecksとInstance Status Checksの二つがそれぞれ成功したというふうに書かれている。

ではそれらは何なのか?そしてそれらが失敗していたらどうしたらいいのか?をいかにまとめてみた。

System Status Checks

物理的なホストで問題が生じた場合、System Status Checkに失敗する。 EC2を提供する端末のハードウェアの問題とかソフトウェアの問題。 このエラーが出た場合は、EC2インスタンスを一度停止して起動し直すことで解決出来る。 インスタンスは停止して起動すると別の物理端末上でホストされることになるので、 問題が生じたホスト以外のホストで起動し直すことができるからだ。

Instance Status Checks

VM自体の問題が生じた場合、Instance Status Checksに失敗する。 要するにEC2インスタンス自体のこと。 インスタンス自体で問題が起きているので、この問題が起きた場合はアプリケーションの設定を見直したり、 インスタンスを再起動することで解決出来る。

なのでもしもこれらのStatusCheckに失敗していたら、まず落ち着いてどちらの原因で失敗しているかを確認し、 Systemの方なら停止=>起動で、Instanceの方なら再起動をするということをまずは試してみましょう。

情報セキュリティマネジメント試験を受けてきた(本番編〜その5)

RTO

RTOとは、Recovery Time Objectiveの略であり、復旧目標時間を指します。 インシデント発生後に復旧されるまでの時間のことです。

RPOはRecovery Point Objectiveの略であり、復旧目標地点です。 インシデント発生後に復旧する際に、復旧できる点を示します。 例えば毎日0時にバックアップを取得しているシステムの復旧可能な点はその日の0時時点になります。

見える化

種類別件数と総件数の推移を1つの図で表す際に最も適した図を選択する問題。 総数の推移を見える化するのには棒グラフが妥当だと思います。

レスポンスタイムとターンアラウンドタイム

例えばECサイトの注文システムにおいて、入力フォームに入力させ購入が完了しました画面が表示されるまでの時間、つまり画面を操作し、目的を達成するまでのトータルの時間をターンアラウンドタイムと言います。 一方で、購入ボタンを押してから次の画面が開くまでのシステムの動作を待っている時間のことをレスポンスタイムと言います。

データウェアハウスについて

大量のデータを整理して何かの判断に役立てたりする際に利用するものをデータウェアハウスと呼びます。

ルータについて

ルーターネットワーク層でLAN同士やLANとWANを繋ぐ機器。 物理層で増幅するのはリピーターで、データリンク層を繋ぐものはブリッジです。

プロキシサーバー

ローカルネットワークからインターネットへのアクセスを中継し、コンテンツをキャッシュすることもできる仕組みは、プロキシサーバーと言います。 ファイアウォールはネットワークの前に設置された門みたいなもので、通信の取捨選択をします。DMZとは非武装地帯を示し、外部に公開するWebサーバーなどを置く場所です。

SaaSの説明

アプリケーションの機能をインターネット越しに必要な時に必要なだけ使用することができるサービス形態のことを指します。

情報システムの調達手順について

まず、ベンダーに情報システム化の目的などを説明し、ベンダーから情報をもらいます。これをRFI(Request for Information)と言います。 次に、調達したい情報システムの条件などを示し、ベンダーから提案をもらいます。これをRFP(Request for Proposal)と言います。 さらに、ベンダーからの提案を比較し、供給者の選定を行い、情報システムを調達するためのベンダーを決定します。 最後に、そのベンダーと契約を締結します。

リスクへの対応方針について

リスクへ対応する上では全てのリスクをゼロにすることは難しいので、優先順位をつけて対応をしていくことが大切です。 細かな内容やリスクを回避するために莫大なコストがかかる場合など様々な状況がある中で必要なものは対応してリスクを回避しますし、 ものによってはリスクを受容することも大切です。 リスクを受容する際にはリスク保有者の承認を得て、その後はリスクを監視し、レビューしていくことが必要です。

コーポレートガバナンスについて

企業経営の透明性を確保するために、企業の経営方針や経営の実態などを監視・監督する必要があります。