「Developers Summit 2019(2日目)」に参加してきました

勉強会メモ

event.shoeisha.jp

codezine.jp

タイムテーブル

10:00～10:45

タイトル 発表者
ドラゴンクエストXを支える失敗事例 青山 公士[スクウェア・エニックス]
エンジニアの知的生産術 ビフォー・アフター 西尾泰和[サイボウズ・ラボ]
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて - 澤田 雅彦[NTT]
プロダクトマネージャーという生き方 熊谷 亘太郎[楽天]
ソフトウェア開発の「今ココ」に適応するために― カイゼン・ジャーニーから見つかった新たなfunと前進への旅路 ― 資料1 資料2 市谷 聡啓 [ギルドワークス]
新井 剛 [ヴァル研究所・エナジャイル]

11:05～11:50

タイトル 発表者
IBM Q - 量子コンピューターの最前線 小野寺 民也[日本アイ・ビー・エム]
メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと 山本 学[ヤフー]
デベロッパーのためのAzureクラウドネイティブスタック 〜 提供したい価値からはじめる高速＋高可用＋高付加価値ソリューション 川崎 庸市[日本マイクロソフト]
デンソーのMaaS開発～アジャイル開発で顧客との協調・チームビルディング・実装概要～ 佐藤 義永[デンソー]
冨田 進[デンソー]
CI/CDを使い倒して数段上のソフトウェア開発をしよう！ 金 洋国[CircleCI]

12:10〜12:40

タイトル 発表社
モンスターストライクにおける負荷対策 ～エンジニアリングチームの挑戦～ 白川 裕介[ミクシィ]
【導入事例】Lychee Redmineのユーザが語る！トラブル予防としての使い方 稲垣 哲也[フューチャーアーキテクト]
機械学習システムのアーキテクチャ アラカルト ～ BrainPad における実例を交えて～ 太田 満久[ブレインパッド]
外食の「明るい未来」にむけたトレタの新たな取り組み 吉田 健吾[トレタ]
Entertainment x Tech～多くのアーティストとファンを繋ぐ技術と組織～ 山田 真一[エイベックス]

13:05～13:50

タイトル 発表者
3周年に突入するAbemaTVの挑戦と苦悩 山中 勇成（みゆっき）［サイバーエージェント］
エンジニアの皆さんに贈る最速キャリア戦略 松本 勇気 [DMM.com]
ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～ 太田 健一郎[スクウェア・エニックス]
OSS開発スタイルを取り入れて、効率的な開発を！～InnerSourceのススメ～ 田中 裕一[GitHub]
中国・深センのテクノロジー最新事情 資料1 資料2 ちゃんとく[dotstudio]
寺尾 英作[SBクラウド]

14:10～14:55

タイトル 発表者
ゲーミフィケーションエバンジェリストが説く、アプリ開発で見落としがちな「おもてなし」とは～面白さを伝える × 面白く魅せる～ 仲 功児[ナノコネクト]
Site Reliability Engineering at Google 中井 悦司[グーグル・クラウド・ジャパン]
今からでも遅くない!?Azureで学ぶ実用Blockchain 廣瀬 一海（デプロイ王子）[日本マイクロソフト]
太田 寛[日本マイクロソフト]
これをまだ知らない Web エンジニアへ贈る - 私が愛する Elixir/Erlang の楽しさと辛さ - 幾田 雅仁 [gumi]
Less Code & Have Fun! IoTアプリ開発をはじめる際のポイント 山崎 亘[ウフル]
IBM Q 量子コンピューターハンズオン 小林 有里 [日本アイ・ビー・エム]

15:15～16:00

タイトル 発表者
プロダクトをGrowthさせるデータ駆動戦略の基礎知識～DMM.comにおけるユーザーレビュー基盤のKPIツリー公開～ 石垣 雅人[DMM.com]
サーバーレスで最高に楽しめるアプリ開発 江藤 武司[Riotz Works]
「仕事なんか楽しいはずないやん」に反発し「ええと思うなら、やったらよろしいやん」を胸に歩んできた話 中村 洋[ギルドワークス]
ことばだけでは足りません、描いてシェアして伝えていこう！ 高野 明子[Sider]
システムエンジニアは空を飛ぶ夢を見れるのか～普通のSEがドローン系SEになるまで～ 佐藤 明
Kubernetesを短時間で体験。IBM Kubernetesで遊んでみよう！ 斎藤 和史[日本アイ・ビー・エム]
今関 靖一郎[日本アイ・ビー・エム システムズ・エンジニアリング]

16:20～17:05

タイトル 発表者
Webサーバー利用だけではないNGINXソリューション 田辺 茂也[NGINX]
無意味なアラートからの脱却 〜 Datadogを使ってモダンなモニタリングを始めよう 〜 池山 邦彦[Datadog]
GKEとIstioで構築するクラウドネイティブ・アプリケーション - What, Why, Where and How to use Istio? 福田 潔[グーグル・クラウド・ジャパン]
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング 森廣 隆行[リクルートテクノロジーズ]
セキュアな環境でDevOpsを実現する厳選ツール 根本 竜也[マクニカネットワークス]
上田 展生[セガゲームス]

17:25～18:45

タイトル 発表者
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方 よしおかひろたか[東京大学大学院]
Webアプリのチューニングバトル「（社内）ISUCON」の魅力と楽しさ 資料1 資料2 資料3 櫛井 優介[LINE]
古川 陽介[リクルートテクノロジーズ]
南 直[Wantedly]
とにかく明るい！「Fun! Done! Learn!」でデブサミを振り返ってみましょう！ ヴァッサー ジャンバティスト[yamaneco]
安井 力
川口 恭伸[アギレルゴコンサルティング]
有野 雅士[アトラクタ]
エンジニア採用パネルディスカッション――困難きわまる人材確保、だが成功する方針・施策とは 【モデレーター】市古 明典[翔泳社]
小野 和俊[セゾン情報システムズ]
松尾 奈美[リクルートテクノロジーズ]
三木 明[Repro]
アウトプットのススメ　～技術同人誌・LT登壇・Podcast～ おやかた
ariaki
hekitter
mochikoAsTech
KANE
長村ひろ
erukiti
私たちはどんな課題を解決すべきなのか？ - 自然災害救援のために開発者ができること「Call for Code」 戸倉 彩[日本アイ・ビー・エム]
関 治之[コード・フォー・ジャパン]
小和田 香

デンソーのMaaS開発～アジャイル開発で顧客との協調・チームビルディング・実装概要～

アジャイルチーム

  • 2年前にアジャイルチーム発足
  • 今では6チーム
  • プロジェクトが終わったら解散ではなくチームに対してプロジェクトをアサインしている

mobi-Crews

  • 採用技術
    • Beanstalk
    • Terraform
    • Docker
    • Rails
    • CircleCI

開発の立ち上げ

開発の進め方

  • 次スプリントのバックログにready/not readyの印をつけておく
  • カンバンの一番上は改善タスク
    • 改善することでその後の作業が効率化されるはずなので一番先に
  • プランニング
    • 速くて2時間長いと3,4時間
    • スプリントのサイクルは1週間
  • スプリントレビュー前日の午後は開発チーム内でレビュー
  • 動くものを見せることが大事
    • 出来てないからドキュメントでデモとかやりだすとダメ
    • 全部出来てなくても見せる
  • メンバの追加はせずにスコープ調整が理想
    • そうもいかないことが多い
    • 複数チームにして拡大
    • POは個別に割当

インフラ

  • コード化する
    • Terraformを採用
  • 横展開可能なテンプレート化
  • 極力マネージドサービスを使って負担をへらす
    • Beanstalkを採用

リリースが近づいて

  • 課題
    • 監視
      • 必要なメトリクス洗い出して横展開
    • 性能
      • 性能評価環境を要しし定期的に測定
    • セキュリティ
      • 外部機関と連携して評価
  • プロジェクト横断のチームを結成
    • SREチーム

3周年に突入するAbemaTVの挑戦と苦悩

AbemaTV

  • 特徴
    • 無料
    • 会員登録なし
    • 24時間
  • 2015/10 開発開始
  • 2016/3 仮開局

プロジェクト横断のチームを結成

  • 開発メンバー
    • 当初14人 -> 今90人超
  • Web/iOS/Android/新デバイス/Streaming Client
  • プロジェクト管理
    • クライアントは2週間のスプリントで開発リリース
  • 勤務体制
    • 週一リモート推奨

アプリケーション

GCP

  • 高機能L7ロードバランサ
  • GKE/K8s
  • ネットワーク帯域に対するコストの安さ
  • ログ収集サービスの充実

言語

  • CAのバックエンドはではJava -> Node -> Go
  • Goを採用

アーキテクチャ

  • Microservices
    • 約80サービス
    • コンテナ化でリソース有効活用
    • サービス間通信はgRPC
    • Gateway Pattern

  • Go + Microservicesの課題

    • パッケージ管理
    • Goのバージョン管理
    • 共通ロジックどこにまとめるか

      データベース

  • MongoDB

  • シャーディングによる分散とレプリカセットで冗長化
  • コネクションプール管理

キャッシュ

  • In-Memory
  • Redis
    • 開発当初GCPでマネージドなものがなかったから
    • セッション管理
    • ロック目的
    • ネットワーク負荷軽減

構成管理

  • Terraform
    • インフラ構築を自動化
  • Packer
    • マシンイメージの作成起動

ネットワーク

クライアント/サーバ間通信

  • gRPCも検討したが
    • 当時http2での通信に対応してなかった
  • 通信フォーマットはProtocol Buffers

CDN

  • Akamai Media Delivery
    • 映像配信に特化したものが少なかった
  • Cloud CDN

開発支援

CI/CD

  • Codeship
    • バックエンドのテストやイメージの作成
  • Deploykun
    • 内製のchatopsツール

モニタリング

監視

  • bugsnag
  • Google Cloud Monitoring
    • GCE/GKEの挙動監視
  • Slack連携
  • PagerDuty
    • インシデント管理ソリューション
    • SREチームで1次対応

ログ

  • アプリログ
    • Goの標準出力にJSONで出力
    • GKEのfluentdで収集
    • StackDriver Loggingで表示
  • アクセスログ
    • 当初はfluentd
      • Goとの相性
    • CloudPubSubとBigQueryへ変更
      • Streaming Insterterの運用管理
      • BigQueryのStreaming Insertのキャパシティ
    • => 今はCloud Dataflow + Apache Avroへ変更

メトリクス

  • Redis/MongoDBはStackdriver
  • 各アプリはPrometheus + Grafana

今後

  • サービス規模の拡大
  • さらなる安定化の追求
  • 既存システムの老朽化対応

目指すアーキテクチャ

  • 配信レイヤーの全二重化
    • サーバや回線等ユーザの直前まで全て
  • チャンネル別リソース
    • RedisやMongoDB等のリソースをチャンネルごとに分ける
  • 実績と予測に基づいたオートスケール
    • 過去実績や時間帯をもとにオートスケールさせたい

Site Reliability Engineering at Google

Googleについて

  • 担当していないサービスでも全てのコードを見ることができる
  • 目指すところ
    • 世界中の情報を整理し世界中の人ボトがアクセスできて使えるようにする
  • 世界中専用回線でつながってる
  • 世界中のデータセンターに巨大なk8sクラスタっぽいものがある
    • 標準化されていてどこも同じ
  • ミドルウェアのレイヤも標準化されている
  • GCPは社内で使われていたものをオープンにしたもの
  • プロジェクト外のソフトウェアもコード修正・改善案を自由に出せる

SRE

  • リリースしたサービスをいかに安定して運用し続けるか
  • システムを運用するだけでなく安定運用するために必要なソフトウェア開発をあわせて行うチーム
    • => Site Reliability Engineering

50%ルール

  • 50%以上をシステム安定に関わるプロジェクト活動にあてる
  • 障害対応等々は50%以下にする
  • 障害が多い/マニュアル作業が多すぎて50%ルールが厳しくなるシステム
    • 開発側に突き返す
    • システムを改善する

SREが見る範囲

  • 運用範囲
  • 運用範囲外
    • 小規模で重要度が低いアプリ
    • 安定運用できてるシステム

SREの活動原則

SLO

  • 何を持って「安定」というか
  • Service Level Objective
  • システムの安定稼働の目標値
  • エラーバジェット
    • エラーバジェット = 1.0 - SLO
    • 消費状況をモニタリング
    • エラーバジェットがなくなりそうになったら新機能の開発はストップして改善に注力

Toil

  • 労力のかかる作業の削減

Postmortem

  • 障害対応が終わった後の文書
    • 発生要因
    • 反省点
    • 改善点
  • 個人を非難する内容は絶対に書かない
  • 障害報告ではなく未来につなげるための知見とする

プロダクトをGrowthさせるデータ駆動戦略の基礎知識～DMM.comにおけるユーザーレビュー基盤のKPIツリー公開～

データ駆動戦略とは?

  • データドリブンで戦略を組み立てる
  • 不確実性につい良い組織にする

なぜデータ駆動戦略?

  • 直感に頼るとプロダクトバックログが肥大化し開発者を圧迫する
  • データがないとなぜうまくいった/いかなかったが分からない

データ駆動戦略のなにがいいか?

  • プロダクトの状態を可視化できる
  • 意思決定を高速化できる
  • 意思決定を定量的に共有できる
  • 未来を予測して戦略を作れる

どうやってデータ駆動戦略?

DMM.comのデータ駆動戦略

  • SoEとSoRな領域がある
  • 40種類以上のサービス
  • ドメインごとにスクラムチーム
  • データアナリストがPOを支える

データ分析基盤

  • データを提示できないといけない
    • 分析しやすいデータ分析基盤が必要

優れた指標

  • データが駆動する
    • データを見ることで次の行動につながること
  • 3つの土台
    • 比較できる
    • わかりやすい
    • 比率や割合である
  • 4つの指標
    • 定量的指標と定性的指標
      • 主観的/科学的数値
    • 虚栄の指標と本物の指標
      • 次の行動につながる/つながらない
    • 先行指標と遅行指標
      • 未来の予測/変動後の数値
    • 相関指標と因果指標
      • AとBが関係/Aが起こるとBが起こる
      • 因果関係を探すために相関関係のある数値をを観察

開発プロセス

最後に

タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング

背景

  • 入稿システムはリボンモデルの根幹の部分
  • ディフェンシブで既存システムに手を加えるのではなく新規で作ることが多い
  • 急激な性能劣化
  • リプレイスでは時間がかかりすぎる

性能改善

  • 過去の技術的負債を分析し改善
    • 泥臭い作業で改善を重ねた
  • 品質の担保
    • 本番データと突き合わせて確認
    • オフショア使って力技で

まとめ

  • リビルドリプレイスに頼らなくても効果は出せる
  • システム単体で最適だったとしても経年劣化を考えるとそうでない

Webアプリのチューニングバトル「（社内）ISUCON」の魅力と楽しさ

ISCONの誕生

  • 2011年の夏
  • tagomorisさんが発起人
    • 「言い訳できない環境で1番を決めたい」
  • 当時のライブドア

名前の由来

  • 当初lpc
  • パフォーマンス遅いと椅子投げるといっていた
    • ISU
  • Iikanjini Speed Up Contest

概要

  • 制限時間8時間
  • 与えられたWebアプリを高速化する

今年のISUCON

R-ISUCON

なぜR-ISUCONはじめたか

  • ISUCONで勝てない..
  • 過去出題している人たちが強い
  • やってみると方向性が変わってきた

本家ISUCONとの違い

  • 本家は出題する会社がそれぞれお題を出す
    • 会社の特色が出る
  • リクルートなりの問題を作った
    • 本家はバックエンドの要素が多いがフロントエンドの要素も入れた
      • CSS/JSをあえて重くしたり
    • 社内で実際に起きたり困ってたりすることをお題に
  • 本家は8時間だけどR-ISUCONは合宿で1泊2日
  • 教育的な側面も強いが障害振り返り的な側面も強い

これまでの振り返り

スピードハッカソン

  • 仮想サービスでなく本物のサービスでISUCONする
  • 実際のサービスでの制約を度外視して試せる

PIGICON

IMOCON

その後

  • みんなに学んでほしいことをコンテキスト形式にする流れができた
  • 実際のアプリにも効果が出せた

新卒研修でISUCON

  • Wantedlyで新卒研修でISUCONした
  • パフォーマンス改善は学ぶのが難しいし実践できる機会が少ない
    • ISUCONで体験してもらう
  • 幅広い技術にふれてほしい
    • 高速化にはあらゆるスキルが必要

新卒ISUCONの運営

  • 問題と環境があればできる
  • 問題
    • Webアプリとベンチマーカー
  • 環境
    • アプリを動かす環境
    • スコアボード
    • 場所

今後

  • 企業横断での新卒ISUCONとかできると面白うそう