Developers Summit 2017に行ってきた（2日目） #devsumi

勉強会

デブサミ2日目も行ってきた。 参加したセッションのメモと感じたことなど。

codezine.jp

1日目はこちら。

su-kun1899.hatenablog.com

No-Ops で大量データ処理を簡単に実現する - Google Cloud Platform で実現する次世代データ処理基盤

www.slideshare.net

感じたこと・考えたこと

データ基盤作るのってすごく楽しそうだけど、データは分析して情報になって初めて価値を生むので、直接価値を生むわけではない。
データの世界でエンジニアとして力を発揮したいなら、そこの間を埋めるところ（機械学習なのかAIなのか分からんけど）まで踏み込んでいかないといけないんだろうな。

  • コンテンツに差が無い→UXで差別化→分析が大事→分析にかけられる時間を多くしよう
    • 例えば音楽のストリーミングサービス
    • なるほど
  • なんでも自分たちで作っちゃうGoogleさんかっこよい。。
  • 可視化ツールで最初に出てくるのはやっぱりTableauなのね
  • Google Data Studioはアップを始めた模様？
  • 変なクエリ投げると金額がかなり変わってくるの怖い（今は定額のプランもある？）

Memo

  • No-Ops
    • ユーザのオペレーションが不要という点ではサーバレスに近い
  • なぜデータなのか
    • 音楽ストリーミングが無数にある中で何を選ぶか？
    • コンテンツに差は無い
    • UXで差別化
  • No-Ops
    • 分析に費やす時間を増やす
  • GCPで提供されるサービスのユーザは1Billionを越えた
  • Googleのデータセンターは15箇所
    • GCP用のデータセンターを増やしていく
  • ネットワークが大事
    • ネットワーク機器自作
  • Borg
  • そもそも自分たちで使うために15年以上データの問題に向き合ってきた
    • 論文を発表してOSSにつながっていったり
    • Managed Serviceとして提供したり
  • ビッグデータのライフサイクル
    • 収集→処理→保存→分析
  • 収集
    • Cloud Pub/Sub
    • ストレージが一番多様性がある。どう吸収するか
  • BigQuery
    • フルマネージドDWH
    • SQL使えて高速
    • 必要な列をフルスキャンする
    • 中身はテーブル構造なので、データは構造化する必要がある
  • Dataflow
    • データの構造化する
    • MapReduceだけではひとつの処理しかできない
    • データパイプラインを整理する
    • ストリーミング処理もできるように
  • クラウドプロバイダは成熟してきた
    • コストが下がり、信頼性が増し、様々なサービスが提供されるようになった
    • 物理マシンを所有して運用することは競争優位にならない

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

感じたこと・考えたこと

技術スタックの種類をやたらめったら増やすのは反対だけど、柔軟に特性を活かした選択できるのは素晴らしいことだと思う。
Wantedlyすごいなー、マイクロサービスやるための基盤整った（整えた）感じした。

  • 技術スタックを切り離してルール化しているところのバランスがとてもよい
  • モニタリング・ロギングを統一するのマイクロサービスだと大事よね

Memo

  • Wantedlyの目指すところ
    • ビジネスSNSへの進化
  • アプリケーションのルール
    • The Twelve-Factor App
    • Heroku元から使っていた
  • 設定は環境変数で指定
  • ログをファイル出力でなくSTDOUTにする
  • ステートレスな状態にする（データを置かない)
    • 用途の違うプロセスを複数起動させない
      • アプリとnginx一緒のコンテナにしたりはだめ
  • コード化
    • Docker化
    • どの言語でも共通の実行方法にする
      • script/bootstrap, script/server
    • doc/はドキュメント置き場
    • health check => 共通の死活監視洋エンドポイント
    • インフラ操作するものはCLIツールにする
  • リリースまでに時間がかかる
    • Dockerfileをアプリエンジニアが書くのは大変
    • コンテナをサーバに乗せるまでの準備が多い(Monitor, Logging, etc…)
    • Kubernetes導入
      • 「アプリがどこで動いているか」という世界から「どう動いているかだけを意識する」世界へ
      • 変化に強いインフラ
  • モノリシックを避ける
    • 新しくサービスを作る時、コード追加より新規リポジトリ作成の方がよいという雰囲気作り
  • CI/CD共通のルール
  • 共通のダッシュボード
  • CapstranoのdeployからKubanetesのdeployになったので、技術制約が緩和された
  • Kubanetesがアプリケーションエンジニアからすると使いづらかった
    • 自分のアプリだけ操作したいのに。。
    • MicroServicesを支えるMicrtotools
    • ラッパーコマンドを作った
    • Kubanetesの管理サーバーを用意した
  • Kubanetes入れなかったら全部Railsで書かなきゃ行けなかったはず

正しくプロダクトを作り、リリースプランニングするためのプロダクトオーナーの役割とは

感じたこと・考えたこと

そもそもでプロジェクトを成功させるっていうのがスタートラインな中、チーム（とその周辺）の学習と成長を前提にするとプロジェクトが結果うまくいくという考え方は、ともするとプロジェクト成功の優先度が下がったように見える。
その考え方を理解するのは大変だけど、理解しないと前提条件が揃わないので、対立につながりがちだよなぁ、と思うなど。

  • JIRAのレポーティング便利なんだけど、当然何かしらの入力値が必要になる
    • 現場のメンバが必要を感じていないのに、チケットに色々な値を入力することを強制するようなことはしないでほしいなと思う

Memo

  • プロダクトオーナーのお仕事
  • 見積もりはある時点での情報に基づく最良の推測でしか無い
    • 見積もりはコミットメントではない
    • コミットメントにしてしまうと誰も幸せにならない
      • デスマーチ化していく
      • 要員の追加は時間をより遅らせる
      • バッファの肥大化
    • スケジュールを守らないのではなく、最新の見通しを常に共有して、トレードオフを提示するということ
  • 見積もりは規模で行う
    • Velocityで進捗を測る
  • リリース日とスコープが固定されているのはありえない
  • 実績値で予測するから精度が上がる
  • JIRAのレポーティング機能が強力
    • 順調なら、見といて下さい、で済む

まとめ

本当は他にもセッション聞いてるんだけど、パワーが足りない。。
今回もたくさん刺激をまた自分の現場で頑張ろうと思う。