読者です 読者をやめる 読者になる 読者になる

hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

Developer Summit 2017に参加してきました(2日めのみ)

Devsumi 2017 2日目のメモと感想です。
走り書き風味になっているのですみません。
途中の()書きは感想です。

今どきのアーキテクチャを現場の立場で斬る(仮)

井上 誠一郎さん [ワークスアプリケーションズ]

すこしメモ取り損ねたのですが、アーキテクチャ選定の意思決定について

YAGNIのジレンマ

YAGNIとは「機能は実際に必要となるまでは追加しないのがよいとする」こと 今必要なければ決定を遅らせる
ミクロには正しいことが多い

(・・・じゃあマクロでは?)
(多分だけど重要だけど緊急じゃないことが先延ばしされるのかな)

合議制のジレンマ

一定の人数以上になるとうまくいかない

合議制と対称的なトップダウンのアプローチ

ただ、規模が大きくなると全てを把握できない

権限委譲するしかない

ミーティングにおいては決定者を決めてしまう その人が決めたことは基本的には従う

(これには賛成。意思決定が不明確にならないことが大事だと思う)

技術的な課題

「適応」は現実的には想定不足に対応すること

『低レイテンシのアーキテクチャ』を目指す

HTML5 Caanvas 最初は使うつもりはなかった

マルチテナント

IAASのコストが上がる サーバレスなどを取り入れる

特定のロールの人しか触れない 認証基盤の問題

「高性能」「非同期」「キャッシュ」などの問題は開発生産性とトレードオフ

プロセス間通信 隠せない キャッシュ一切ナシは難しい

なぜマイクロサービスにしなかったか?

はじめは分割基準がわからないため、そう判断した
だがモノシリックになりすぎた

マイクロサービス:各サービスが独立したデータストアを持っていること
トランザクション:casandra依存なのでデータストアには苦労してない

なぜ最初からマネージドサービスにしなかったか?

サーバレスなど
フロントエンドをサーバサイドレンダリング まだまだ模索中

mutable immutableのハイブリッド

概念をシリアライズ
人が増えることは想定済み だが半分空想
オープソースコミュニティ のように お互いがプルリクを送りあえるようなものを目指す

現実
どこかでうまくコミュニケーション

ワークス伝統のカタログが強み 企業向け製品のパッケージベンダー

ある機能を提供したときに、ユーザがどのようなメリットをえるか?

ダンバー数のジレンマ

人間の関心は有限のリソース 人に対して 技術に対して それをどのようにコントロールしていくか

異能の人材たち

声がでかい 態度がでかい タフな精神力 超人的な体力 綺麗事よりも「闘うプログラマー」 こういう人たちがいると圧倒的にプロジェクトは進みやすい

(この本は読んでる。井上さんの話を聞いてカトラーなどの人物は「圧倒的な当事者意識」があるのではないかと感じた。)
(「尖ったエンジニアの多い現場でも間を埋めて、とにかく進めさせる」みたいなイメージ) (あとやっぱ経営の踊り場問題のブログ記事を思い出す。。)

天才プロダクトマネージャ
色んな人がいる ダイバーシティ
人種のるつぼ
日本がヘッドクォータ

Re: ゼロから文化を創り、技術を伝承する ~客先常駐エンジニアと「社内勉強会」で築いた価値と変化

VSN 須賀俊介さん

www.slideshare.net

現場エンジニアへの技術研修

VSNはエンジニア人材を提供する会社
常駐先では技術研修が行えない 帰属意識が薄れるという問題がある
1,2年目で自己研鑽をする姿勢が持てない

成長する段階

  1. スキルアップを渇望
  2. 仲間を見つける 渇望していることを発信
  3. グループの構築や人脈を作る
  4. スキルアップを進行する

(渇望すごく大事。自分が渇望してることを忘れないようにしなくては)

chatterを活用できないか?

デブサミを聞いて 勉強会をしていきたい 情報共有や育成を行っている

したしらべフェーズ

TokyuRuby会議

もくもく会 永和システムマネジメント

ソフトウェア開発で勉強会

業務ではない
興味ある技術について発表 LT
社外の勉強会 イベントにみんなで参加
ハッカソン もくもく会
一年近くやってみて継続できそうだと判断 数人しか参加しないときもあったけど

(こういう勉強会を継続できるのがすごい)

逆に地方に配属されているエンジニアもリモートで参加

(よさしかない)

ネットワークエンジニア強化プロジェクト

今までと違って上からのお達しでの勉強会
資格を取る
現場が忙しい 一人で追いかけるのが辛い
成果としてはよくなかった
モチベーションにつながることが少なかった

IT分野だけで勉強会やってうらやましい 俺達もやってみたい

こういうことするといいよというノウハウを共有

エレクトロニクス分野でも開始 FPGA や CADの勉強 マイコンのプログラミング

  • マウス作ろう勉強会 英語勉強会
  • 営業ファッション勉強会 元アパレル業界のエンジニアが講師 みだしなみについて

(参加してみたいぞこれ!)

失敗事例と成功事例の比較

タイトルにもあるように リゼロ 失敗してやり直すこともある

続かない 実践できない 広がらない 参加できない

かたや車 かたやロケットをつくっている現場 さまざまな仕事をしている人がいる

参加者が固定 気づくといつもいるメンバーばっかりという問題
何回か行かないとだんだんめんどくさくなる
1回休んじゃうとかお出しづらい?

シフト勤務しているエンジニア 土日出勤

アナウンスをみてない
勉強会のSNSグループに入ってないとわからない 社内SNS自体をみてない

場所の問題
お客様先を使わせてもらえればいいが

若手の育成
忙しくなる と 参加できなくなる

転籍 転職の問題 引っ張ってる人がいなくなり、次世代のリーダー育成をどうにかしないと 業務とかを通じて サブリーダー 少しずつ課題

複数人もしくは継続できるリーダーがいる

スケジュール 場所の解決 スケジュールを予め決める 会社でも鍵の管理やセキュリティ要件をクリア 遠方の参加者でもウェブ経由で参加:WebEX Skype

年間スケジュールをたておいて 合間で特集の勉強会をやってみる AWS 少しずつレベルアップ

無理しない

プロジェクトルイーダの立案 お互いに仲間を見つけあって 勉強会を立ち上げる支援

お客様 業後に勉強会

お客様先の若手育成やりたいというのに答える お仕事としてももらえることも

エンジニアに対する言葉 「エンジニア魂」を語れる

暗黙知形式知に 働く意義 気持ちなどを伝承

先輩からちゃんとして場で伝えておきたいと思っていることを効率的に伝えられる

広がりとしての価値 他社のいろいろな考え方 知識

同じ方 向を向いている人と一緒に勉強できる 「場を作る」

若手だけじゃなく キャリアも育成できる

成長が見えないエンジニアの育成 面談などでフォローする人が必要

チャンス

ビジョンの共有

(全体的に素晴らしいなと感じた。) (こういう勉強会に参加できるの本当に羨ましい。)

コンテナをフル活用した現場

wantedly 坂部広大さん

speakerdeck.com

仕事で心躍るひとを増やす

会社のビジョン 

Wantedly People: 名刺管理のサービス 名刺の写真をスマホでとってwantedlyの登録ユーザを自動的に情報を入力 

ビジネスのSNSへの進化
スキル・評判・つながりの3つ資産を充実 プラットフォームを作っていくのが目指すところで単なるリクルーティングを行うのではない

(Wamtedlyのビジョンの話はもっと聞きたいけど、今回はない感じ)

変化に強いインフラを実現していく

Twelve factor appというアプリケーションのルール

Herokuの中の人が書いた
Herokuのすごいとこ-> 意識しなくてもtwelve factor app になっていく

djangoチュートリアルでherokuを使ってみたけど、djangoでもtwelve factor appのことは言及されていた)

コンテナを使い始めたときもTwelve factor appを守る

1つのコードベース 複数のデプロイ

依存関係 Gem

設定config configをgit pushしてしまうとポータビリティがなくなる

(Dockerを使ってるとこの辺のことは本当になるほど、という感じ。)
(環境変数でよみこんだりとかいろいろしているのだけれど)

バックエンドをつなげる

(やっぱりHerokuを意識した作りになっているんだろうと思う)

ビルドも分離

Gitのpushのたびにビルド

最終的に実行はコンテナの起動だけ

プロセスはデーモンで起動しない は dockerではいいのかな

スパイクの対処、逆に小さくするスケールインも安全に

ログは(Railsなどの)フレームワークとして使うと、ファイルに出力することが多い
だが、stdout, stderrに出力するようにする

アプリケーションのルール

Dockerの仕組みでもtwelve factor appを勝手に実現している

コード化とツール化

microservicesをすすめる

script/bootstrap, script/server どの言語のエンジニアでも設定、サーバ起動ができる

script/check_environment 環境チェック すぐにコードをかける状態

環境設定はどんどんモチベーションが下がってしまう それを防ぐ

アプリケーション以外はインフラ、みたいな感じでツールを作っている

CIの結果を取得できる

.env

暗号キーなど 期限付きURLのS3ホスティング

アカウントのIAMをつくるのもプルリクエスト

変化に強いインフラを作る

大きな課題

Dockerfileをアプリエンジニアが書くのが大変 設定 ASG, Monitor, Logging, ALB, DNS

インフラチームは2人 「なんかログ出てないけど違うんじゃないか」みたいなことを言われることがある

80個位のチェックボックス デプロイ大変

Railsエンジニア いつになったらリリースできるの?

Kubernetes

今までログの設定 サーバに縛られる 純粋にアプリケーションがどう動いてるかだけに集中したい 

利用者はどのように見えるか? マシンスペック CPU デプロイ方法 ブルーグリーンまたはロールデプロイ

Kuberenetesのクラスタリングを作ってしまえば あとはかんたん

サービス

新しくサービスを作るとき * 新しいリポジトリを追加 * 既存のコードベースに追加していく 2番めだとどんどんモノシリックの巨大化する

ブランチ名 + git のハッシュ

ダッシュボード Kubernetes + Datadog

Capistranoでのデプロイ から kubernetesのデプロイに変わった 他の言語でも運用は変わらない 参入の障壁が下がった

(ここがすごい。オーケストレーションをKubernetesで必要なくしたってことだ)
(kubernetes自体どんなコードなのかわからないし、知りたい。。。)

Kubernetesのオフィシャル インフラチームには使いやすいがアプリチームには使いやすいとはいえない?

Unix philosophy

(小さく作ってつなげるとか色々大事な考えの宝庫だ)

Microservicesを支えるMicrotools

ツール自体のバージョニングがKubeサーバーで一括管理する

どうかわったか?

アプリケーションエンジニア側でtwelve factor appを作った

wantedly people

すべてのサービスが同じ運用方法

インフラチームも積極的にコードを書く 全体最適のために

(アプリのエンジニアとうまくやるための仕組みをインフラチームが積極的に押し進めているのがいいなぁ) (インフラのコードまだまだ知らないことが多いので知りたいと思いました。)

スタディサプリを支えるデータ分析基盤 ~設計の勘所と利活用事例~

山邉哲生さん リクルートマーケティングパートナーズ

www.slideshare.net

クラッチから構築した スタディサプリ

カリスマ講師の動画 ゲームをしながら学べる

予備校などよりは安い

公教育でも利用 先生がログインすると課題を配信することができる

宿題の傾向から苦手や得意などを分析して提供する

チーム Dev, Data, Biz SRE

データの基盤 トレジャーデータ cloudでhadoop

一般的なKPIのモニタリング 離脱状況などをレポート

資料を作る

カスタマーサポートのサポート

動画のコンテンツがどのように見られているか コンテンツのパフォーマンスのモニタリング

re dash googel spreadsheet slack

見るもの tableau jupyter

(Dataの人もjupyterも使うんだ。)

学校で利用する人 夏休みの終わりに一気に見る

個別に利用してる人 平均的

アカデミックな話 講義の関係性をマップしたもの

膨大な学習データ 講義間の依存関係がデータからわかる

(単純にすごい。ビジネスとしてどう売上をのばすかということだけでなく、学習そのものの研究につながるとは)

アダプティブラーニングの実証実験

何か躓いてるところ それを理解するための勉強をレコメンドを行う

レコメンドをやっていない生徒とやった生徒

リクルート次世代教育院

受験サプリ 勉強サプリ リクルートテクノロジーパートナーズ 英語サプリ 英単語サプリ リクルートパートナーズ

先生と生徒とのコミュニケーションを活発にするサービスを買収

ブランド変更とシステム移管を同時に実施

(やっぱやることのすけーるでかい・・・。)

データの収集と構造化

テーブルのジョインが一般的

ナマのテーブルには興味がない リレーションが入ったテーブルをみる 細かいロジックを入れたカラムを作る

集約して

Dataからopsに依頼をして一週間後に反映

集約、抽象化された情報しかない

データの取得元やスキーマを柔軟に追加変更できない ブラックボックス

データがおかしいときに調査に時間がかかる

(たしかにこういう経験はある。)

移行後 データを全部引っ張ってくる embulk

Extract, load and transform

手元にすべての生データ 異種のDBを結合するることができる

細部を理解してビジネスロジックを基板側で再現しなければならない

アプリのビジネスロジックとずれる可能性

データ分析チームの持っているスキルセットに依存する

デブサミの別のスライドでも見たけれど、ほんとすごい) (自分の前職のデータ分析でもこういうふうに仕組みづくりすればいいのかというのがわかる)

行動ログ

web SPA フロントTDのSDK バック rails -> kinesis -> lambda scriptでトレジャーへ

クライアントサイドのログ SPAなのでサーバサイドでは取れない

信頼性が低い 欠損する割合

タグマネージャ経由 クリックイベント ちょくトラッキングに比べて安定して9割欠損

太古や未来からのログ 信頼できない

(あるあるすぎる。変なUAとかも面白いw)

サーバサイドのログ 信頼性は高い サーバに到達しない DBに反映されない 行動しないと同義 冗長化がかんたん

実装はしにくい

embulk-filter-hash ハッシュ化 embluk-filter-mask 特定の値だけフィルターするプラグイン

embulkを基盤にしたデータ連携

(embulkすっごーい)

マスタデータ連携 並列実行性 帯域

障害発生を前提とした再実行のべき等性

Hive, Prestoによるデータ集計 設計 ワークフローエンジン luigiジョブ

実行計画DAG 有向無閉路グラフ

Digdagジョブ

pythonでガリガリ書くより宣言的 yaml + js slackに通知

(Pythonでがりがり書くの好きだ・・・・)

timeline形式 上から下に流れる

データはどうやって提供するか

Google spreadsheet が至高

(至高なのか!)

スケジュール実行ができる

データに関わるようになってから思うこと

データは組織をまたいで流れる

データはナマモノ 継続的な鮮度管理 機能開発・ログデータのメンテナンス

文脈を考える人が必要

データでみえていると思った部分 サービスの本質を定めるデータ 次のフェーズで重要になるデータ 見えている部分を本質的な部分に近づける ただし、プロダクトはつねに変質しているので、たえまない軌道修正が必要 データの文脈に向き合うチームへ

目指すところを変えて常に探索を続けなければないけない データだけで見ていても解釈できないこともある 「先生が色々操作していた」 というアドホックなところ

一番の勘所

組織設計ではないか

data, dev, bizが小さく一体的になってぐるぐるまわす

足元のKPI指標からアカデミックなデータまで biz x dev x data

(なるほど。。やっぱ小さくぐるぐる回すのが基本か) (そのためにはメトリクスをどうきっちりとるかが重要なんじゃないかな)

全体的な感想

データ分析基盤の話が自分にとっては新鮮だったかも
BIは日々進化してる。。。
スピーカーの皆様、スタッフの皆様、ありがとうございました。