July Tech Festa 2015に行ってきた。
【数学の知識不要、ITエンジニアのための「機械学習理論」入門】
ガチで文系の人が多くて困る中井さん
日経BPが煽ると一年ぐらいで忘れさられる、と軽いディスり。
資料は↓にあるもののさわりだけ。
http://www.slideshare.net/enakai/ss-46880120
- ビジネスに役立つ学習アルゴリズムの選定が大事。
- データサイエンティストはビジネスに役立つ結論を提案しなければいけない。
- 過去の事実を分析するだけではデータエンジニア。
- データ半分からルールを作って、残り半分で検証するとかは初歩的な手段。
- ビジネスプロセスにデータサイエンスを組み込むのがこれからのトレンドになると思います。
- amazonはやってる。
最後は現在、書いてる機械学習の書籍を宣伝。
【失敗例を成功に変える、AWSアンチパターンの数々(Webアプリ編)】
デザインパターンを知らずにアンチパターンは語れない。
まずは基本のパターンをということで、以下の妄想ストーリー。
================================
①雲の写真をアップするブログを開設
→EC2インスタンス1台でMOVAVLE TYPEを使用
②日本には雲マニアが想像以上にいた
→S3で静的コンテンツ配信
③まさか、海外のニュースサイトでとりあげられるとは‥
→CDN導入
================================
☆構築時のアンチパターン
●EC2一神教
- 目的ごとにEC2を用意してしまい。インスタンスが増えすぎる。
- 可用性担保にも障害となる。
解決策
他のサービスを検討する。
●ノースナップショットアンチパターン
- EBSのスナップショット機能を知らない。
- スナップショットが高価だと思っている。
解決策
新しいことを行ったときはスナップショットを作成する。
定期的に不要なスナップショットを消す。
●AMIなしアンチパターン
- AMI作りが難しいと思っている。
- オンプレミスのインストール手順に固執。
解決策
まずはやってみろ。
●AMI至上主義アンチパターン
- AMI作成をバックアップだと思っている。
解決策
EBSのスナップショットを利用する。
適材適所のバックアップを作成する。
●インスタンス振動アンチパターン
- AUTOSCALINGの設定が敏感すぎてインスタンス数の増減が激しい。
- 課金は1時間単位なので、2回起動したらその段階で2時間分の課金が発生する。(たとえ1時間以内であっても!)
- cloudwatchの条件ソースが不適切。
解決策
起動条件の4倍程度に緩和する。
1時間に切り上げて課金されるので、55分で自殺させるようなスクリプトを仕込んでおく。
●単機能
- サブネット毎に、DB用、アプリ用などと分けてしまい、それぞれを複数設置し忘れる。
- 特定の機能が単一のAZにあるのでSFPになる。
解決策
ELB、RDSなど複数AZを有効に使うサービスを導入する。
●とりあえずELBアンチパターン<
- 冗長化のためにロードバランサを必ず置かないといけないと思う古い知識。
解決策
モダンブラウザ×DNSラウンドロビン。
アプリケーション開発者に聞いてみろ
●cloudfront使わないアンチパターン<
- 配信先が日本だけなので不要と考える。
- キャッシュ設定を嫌う
解決策
cloudfrontのレスポンスを体感しろ。
●ベンチマークソフトウェアアンチパターン<
- システム実態と違うベンチマークソフトウェアによる測定値を使ったサイジング。
解決策
本番システム全く同じシステムを一時的に作成する。
☆運用時のアンチパターン
●ノールック明細アンチパターン<
- 月末の料金請求しかないと思っている。
●インフラ塩漬けアンチパターン<
- 構築当初のままインフラの見直しをしない
解決策
サービスは四半期に一度見直す。
●机上の空論アンチパターン<
- サーバ発注、システムデプロイ、納品の硬直したループにはまっている。
- 事前のプラニングに時間をかけすぎる。
解決策
ともかく小さく試してみる。
☆失敗したら‥
- ブログに書く。
- 周りに面白おかしく話す。
- 解決した方法を発信する。
【仮想化とストレージの新しい形!ハイパーコンバージドインフラの技術解説】<
●これまでのインフラが抱える問題<
- 根本的に複雑
- スケーラビリティの制約
- 非効率なサイロ化、分断
●ハイパーコンバージドインフラ<
ソフトウェア処理で仮想化環境のサーバーと共有ストレージを単一HWに統合
●Nutanixの基本コンセプト - WebスケールIT<
googleやfacebookデータセンターは
- 汎用的なHW
- すべてをソフトウェアで制御
- 管理を自動化
- 計算処理やデータを分散させる
●Controller Virtual Machine<
- Nutanixクラスタのすべてのノード上で動作
- ユーザ空間で実行されるVM
- ハイパーバイザとは別に更新管理
- PCIパススルーでサーバのディスクコントローラを直接認識
- ハイパーバイザとは仮想スイッチ経由で通信
●書き込みI/O<
- 筐体内のRAIDという考えは捨てて、別ノードで保持
- あるノードが倒れたら、コピーの再配布が始まるので、対障害性は強い
- 基本的にローカルストレージから読み込む
●LiveMigration<
- Migration後にリードが発生したら、元ノードのストレージからデータをコピーする。
●あるノードでCVMがダウンしたら<
- ゲストVMはそのまま動き続ける。
- 別ノードのCVMを経由してストレージにアクセスする。
- CVMの更新時にもゲストVMはそのまま動かせる
●拡張性<
- ストレージだけのったノードも発売した
- シャーシ単位ではなく、筐体内のサーバ単位で買える
【運用に自動化を求めるのは間違っているだろうか】<
このセッション目当てに来たといっても過言ではない。
資料公開されてました。
ネタ満載のスライドですが、そこに惑わされてはいけませんね。
http://www.slideshare.net/zembutsu/automation-myth-we-can-advance
前佛さん、まさかのすごいドメイン取得。
http://docker.jp/
こんなのまで。
http://viviop.net/
| 固定リンク
この記事へのコメントは終了しました。
コメント