えいのうにっき

a-knowの日記です

DeNA TechCon 2019 に参加してきた #denatechcon

勉強会

techcon.dena.com

個人的に今年はGCPをやっていこうと思っていたところに、GCPの話しますよという文脈でこのカンファレンスの存在を知ったため参加してみました。そのレポート的なやつです。

全体的な感想

  • 当たり前なのかもだけど、基本的には良い部分・カッコいいところを中心としたお話で構成されてるな〜〜という印象だった
  • AI、機械学習みたいなところを実用レベルまで昇華させている・させようとしている感じがあった
  • gRPC、ちょっとおさらいしたいなと思った
  • 素敵なノベルティの数々、ありがとうございました！

概要

受付・入場

  • 受付は Peatix アプリで
  • ノベルティがたくさん入ったトートバッグをくれた。DeNAのロゴが入っただけのシンプルなやつで嬉しい。
    • 他にも自由に持って帰っていいノベルティも。自社が出してるソシャゲ？のキャラクターのグッズが中心。
    • 折り畳み傘入っててすごい
    • 会社案内も入ってた、サイズ感はショッピングモールとかの案内図みたいなかんじ
    • 今後開催予定の技術イベントの予定表と、そこへの優先参加権となるカードも同封されていた
  • マスクも置いてあって素晴らしい
  • 新卒向けには別受付が。学生相談ブース・キャリア相談ブースも併設。採用意欲感じる
  • 長机をくっつけたかんじで休憩スペースも用意されている

カンファレンス本編

オープニング

  • システム本部長の方からのお話し
  • TechConは年に一度のものづくり技術カンファレンス
  • テーマは「SHIFT UP」
  • 「オンプレミスからクラウドへの移行を経営レベルで意思決定した」
  • DeNAは「技術に強い会社」ではなく「ものづくりの会社」

ヘルスケアサービス開発の裏側〜品質と開発効率の両立〜

#マイクロサービス #GCP #Mobile or Smartphone #iOS

一番狭い部屋で立ち見が出てた。 「DeNAではどのようなヘルスケアサービスをどのように開発しているのか？」について。

tl;dr

  • 結構早い段階からマイクロサービスを標榜して開発をやっていたが、事業推進を第一に考えてやっていたら気づいたらマイクロサービスのメリットを全く享受できない状況に。
  • サービスを安定して開発・デリバリーし続けることが大事なので、このアーキテクチャを刷新することに。
  • まずは新規事業をGCP上で・マネージドサービスを駆使して構築、その後既存プロダクトをそこに持っていく作戦を取ることに。
    • 【感想】このあたり、「こうやりました」ということだけだったので、やってみてどうだったか・大変だったこと、工夫したこと、といったところが聞けると良かった。

どんなサービスか？

  • 遺伝子診断サービス・MYCODEをはじめ、2015年から実はいろいろやっていた
  • 健康寿命に貢献するために、長期間使ってもらえるものにする必要がある
    • 長期にわたってスピードを維持して開発できるアーキテクチャやプロセスが重要

バックエンドのアーキテクチャ刷新

  • セキュリティを担保しつつ、長期にわたってスピードを維持して開発できるアーキテクチャやプロセスが重要だったが、アーキテクチャやプロセスが起因して開発スピードが低下してしまうという課題があった
  • 2015年ころからマイクロサービスを意識した開発をおこなってはいたが...
    • 自社プロダクトではない、外部プロダクトとの連携サポート（OAuth）の追加や外部医療機関との提携も増え、インターフェイスが増加・複雑化
    • マイクロサービスが急増・その分け方が適当になってしまっていた。密結合状態。改修時の影響範囲も大きく、その調査や対応も時間が掛かってしまうように。
    • 「元マイクロサービス」のような存在も。
  • アーキテクチャ刷新でやろうとしていること
    • サービスの分割と統合
    • BFF（Backend for Frontend）構成に
      • バックエンドのマイクロサービスのAPIレスポンスを集約し、プロダクト毎に必要なレスポンスを返せるようにBFFのためのレイヤーを挟む
    • プロダクトやサービスとチームを対応づける
  • 実現のための大方針
    • 今のプロダクトや環境は一旦そのままにして開発を継続し続けながら、新規プロダクトを新環境で開発・その新環境に対して機能追加をしていくことで、タイミングを見て既存プロダクトを順次新環境に移行する方法を取ることに
  • 基盤技術
    • オンプレミスLinuxから、GCPを使ってコンテナとマネージドサービスを活用する形で構築。一部（マイクロサービス間の通信制限や通信暗号化など）でIstioの機能も使っている
    • GCPを選んだ理由は、GKE（マネージドk8s）を使いたかったことと、セキュリティなどの非機能要件も加味して。
    • キャッシュには Cloud Memorystore、DBは Cloud SQL。
    • マイクロサービスはGoで
    • BFFはnodeで
    • 監視やロギングは Stackdriver
    • 脆弱性対策は Cloud Armor
    • 鍵管理 Cloud KMS
    • ログ分析は BigQuery
  • 現プロダクトの移行方法については現在検討中

リーン開発と仕組み化

  • 不確定要素のとても多い開発
  • 実際に作り始めるといろんな問題が発覚する
    • 発覚する問題は、リリースが近づくほど大きくなる
  • プロトタイピングをプランニングの時点で実施した
  • alpha / beta test とドッグフーディングも実施した
    • フェーズ、完成度によって配布対象を広げていく
  • iOSアプリ配布サービスやswaggerを使って仕組み化もした

「モビリティ・インテリジェンス」の社会実装〜タクシー運行最適化を実現する機会学習システム〜

#AI #ITS #GCP

tl;dr

  • タクシー運行最適化基盤のアルゴリズムとアーキテクチャ、それぞれをどのように実現させたか。という話。
  • 【感想】実証実験結果（あるエリアにおける平均売上と同程度の売上を記録）、すごい
  • 【感想】空気のようにGCPの各サービスを活用して機械学習基盤を構築されているんだなぁ
  • 【感想】GCPを使ってるとBigQueryを含めたアーキテクチャをワンストップで作れるの、大きいよなぁ
  • 【感想】ロールの違い（データサイエンティストとMLエンジニア）による環境の違いを Docker（コンテナ）を使うことで解消したのはなるほど感あった

タクシー運行最適化とは

  • 配車アプリ・MOV
  • 探客スキルは乗務員に依存している・最大2倍の差
  • 探客をおこなうAIシステムの開発、アルゴリズムの設計をする
  • （探客問題をどのように解くかについてのお話）

MOVの機械学習基盤について

  • GCPでMLやデータ基盤を作る話、とはいえGCPの各コンポーネントについてのお話は少なめ
  • すべてGCP。3つのコンポーネントで構成されている
    • データサービス
    • MLサービス
    • APIサービス
  • データサービス
    • 役割：機械学習で扱うデータを提供するための基盤
    • PubSub -> Dataflow -> BigQuery / GCS。よくある構成、とのこと
    • データ前処理基盤は、処理をおこなうワーカー数を設定する必要があるため、k8s上にクラスタを構築した
      • Dataflowでやらなかった理由としては、処理に必要なリソース量が大きかったため（地図データをメモリ上に展開）
  • DWH
    • ほぼすべてのデータをBigQueryに蓄積。分析用途だけではなく、プロダクションの推論用データ生成にも利用している
    • GISという、地理的関数を実行できるのも利点（実験段階）
    • データ分割対応
      • パーティショニングによる時系列分割・ログ時刻での Column Based partitioning
      • クラスタリングによる地域分割・位置情報に基づく Clusterd Table
      • 何をキーにするかは慎重に、利用者とユースケースについてきちんと詰めた上で。
  • セキュリティ周り
    • MOVプロダクトとは独立したGCPプロジェクトにした
    • プロダクト環境からは書き込みのみを許可
    • BigQuery、GCSへの、顧客管理に暗号鍵の設定
    • Cloud IAP による個人認証
  • MLサービス
    • k8s上にある jupyter hub でデータサイエンティストがモデル生成、それを docker image としてデプロイ・
    • ML推論パイプライン：Cloud Composer（Airflow）定期的に最新データを取り込み、推論ジョブを実行
  • MLOps
    • ありがちなこと：再現性の喪失・MLEとDSとのコミュニケーションギャップ・モデルの経年劣化
      • MLEとDSのインターフェイスを Docker Image にしたことにより解消
      • 経年劣化については stackdriver と grafana でダッシュボード化し、モデル推論の精度を可視化している
      • 機械学習モデル開発のすべてを自動化したいと思っている
        • 性能劣化を検知 -> 再学習 -> テスト、リリース
        • モデルの定期更新と新手法デプロイの融合
      • 精度が落ちても破綻しないサービス設計も必要。適切なフォールバックの仕組みが必要

ゲーム開発者からMaaS開発者へ〜ゲーム開発のノウハウを活かして移動体情報配信システムを作ってみた〜

#GCP #gRPC #AWS

tl;dr

  • 「移動体情報配信システム」のコンセプトの紹介から、その開発・構築についての紹介。
  • 【感想】「これ（＝移動体情報配信システム）、MMOのLocationServerと同じでは？となった」の、おもしろい
  • 【感想】GCP、AWS、gRPC、k8s、Envoy、盛りだくさんですごい。「なぜそれを選んだか？」みたいなところの掘り下げをもう一段、してもらえると嬉しかったなー
    • もちろん自分の勉強不足もある......、、gRPCとか
  • 【感想】「異なる事業ドメインであっても、身につけた技術や経験は役に立つ」いい話！

MaaS?

  • Mobility as a Service
  • 車輌情報はサービスの根幹
    • リアルタイム情報
    • 履歴情報
    • どちらも簡単に利用できる必要がある
    • 位置情報は個人情報にあたる

移動体情報配信システム

  • コンセプト
    • 移動体＝車両＋人
    • データソースの種類に関係なく、統一された仕組みで移動体の情報をストリーム配信する
    • 適切なアクセス権コントロール
    • 移動体の増加に対応できる、十分なスケーラビリティを持っていること
    • 必要な範囲の情報に限定して受信する
  • MMOのLocationServerと同じでは？となった
  • 技術要素
    • gRPC Stream API
      • 移動体情報配信システムはgRPC-Webの利用も想定
    • Google Cloud Endpoints for gRPC
      • gRPCに対応したAPI管理サービス
      • HTTP/JSON リクエストを gRPC に変換してくれる機能を持っている（今回は利用していない）
      • ESPのサイドカーproxyがAPI認証の仕組みを提供してくれる
        • ESP : nginx ベースの Proxy で構成されている
    • Envoy
      • gRPC-WebのためのProxyとして利用している
    • Redis Pub/Sub
      • Redis が持つ Pub/Sub 機能
      • レプリケーションやクラスタ構成があっても Publish されたメッセージが適切にSubscriberに届く
      • パターンマッチによるSubscribeをサポートしている
    • k8s
      • 今回はGKEを使った
    • Google Cloud Pub/Sub
      • AWS IoT で収集した車輌情報をこれを経由してBigQueryに蓄積させている
    • Kinesis Data Streams
      • 車両情報収集システムで使用
      • 高いリアルタイム性能（収集されたデータは200ms以内には利用可能になる）
      • オートスケールはしない
  • アクセス権コントロール
    • gRPC API の認証は Cloud Endpoints で
    • Google ID Token でユーザーアカウント認証はできるが認可は個別に実装する必要がある。JWTからアカウント情報を参照し、アクセス権を持つユーザーかどうかを判定
    • Cloud IAP でやらなかった理由
      • GKEで利用するばあいはIngressを使うことで対応できるが、gRPCに対応できていない
      • gRPC-Webであっても Server Streaming RPC を使うと生じる不具合もあった
  • k8sの構成
    • gRPC用サービス
    • gRPC-Web用サービス
    • Redis用サービス
    • スケーラビリティについて
      • DBが存在しないため、Disk I/Oネックになることが無い。純粋な計算量やネットワーク帯域によって性能が決まる
      • Redisはクラスタ構成することでスケールアウトは可能
        • パターンマッチによるsubscribeはすべてのノードが動作してしまうため注意が必要

10年目の『エブリスタ』のリニューアルを支える技術

#Kubernetes #GCP #GraphQL #リニューアル

tl;dr

  • 10年目のサービスをインフラからアプリケーションからゴリっとやる話
  • GraphQLとクラウドのマネージドサービスのフル活用がキモだった
  • 【感想】GraphQLがうまくハマったパターンなんだなー。新サービスではなく今あるサービスのリプレースっていうのも良い方向に働いたのかな
  • 【感想】クラウドの活用方針も割り切っていて好感が持てた、事業部エンジニアが足りないのでプロダクションも手元もk8sで、というのは、各メンバーの地力があるからこそ、っていうのもありそう。

はじめに

  • エブリスタは小説投稿サイト
  • 10年目のサービスなので技術的負債も多い
    • コピペコード
    • 独自フレームワーク
    • etc.
  • アプリケーションのみならずインフラも含めたすべてを作り直すしかない、となった
  • 課題
    • エンジニア人数3,4人
    • コントローラ数換算で900

アプリケーション開発パート

  • Railsを用いてサブシステムごとに分割されたアーキテクチャ
  • GraphQLの活用
    • バックエンドに手を入れずにUI改善ができる点を評価
    • ドキュメント作成も不要に（GraphiQL（グラフィクル）とGraphQL Voyager を使う）
    • ファットになりがちなモデル、といった問題も GraphQL の導入によりクリア
      • Modelの関連を GraphQL が吸収
      • ネイティブアプリエンジニアがサーバーサイドのコードを変更することもできるように
  • k8sを活用した開発環境
    • minikubeを利用、そこからNFSマウント
    • Helmによるテンプレート化

クラウド活用パート

  • これまでの、インフラのことはすべてインフラエンジニアに任せていた運用体制から、事業部のエンジニアがインフラも管理するように
    • エンジニア不足という別の問題が。インフラ管理コストを削減するため、クラウドを活用することに。
  • 構築した環境
    • ローカルと同じ構成で動作することを念頭に。
    • アプリケーションはGKE
    • その他のミドルウェアもできるだけGCP マネージドサービスで完結できるように
    • 一部GCPでサポートがないところは、AWS の Elasticsearch Service や SES を活用
  • ネットワーク周りや他のマネージドサービスの構築については、管理コストも考慮してコード管理はしないことに。
  • とにかく「マネージドサービス以外は使わない」方針。
    • spinnaker、prometheus などは利用を断念。
  • 環境について
    • コンテナ
      • pumaを使ってシングルプロセスでRailsを起動、それを1コンテナに。
      • ubuntuベースのコンテナを採用
    • ログ
      • 収集はstackdriver -> Dataflow -> BigQuery
      • MySQLのログは embulkをつかって BigQuery に。
    • 監視
      • stackdriver
      • 外形監視のみ monitis を使っている
    • ネットワーク
      • Cloud Armor
      • できる限りVPCを活用したネットワークを構築
      • Cloud NAT でアウトバウンドIP固定
      • fastly
    • CI/CD
      • GitHub -> CircleCI -> Cloud Source Repository -> Container Builder -> Container Registry -> Compute Engine が Deploy Server
    • データコンバート
      • MySQL -> Perl -> JSON -> gsutil rsync -> Cloud Storage -> スクリプトx2 -> Cloud SQL

DeNAゲーム事業におけるデータエンジニアの貢献

#BigQuery #GCP #データ分析基盤 #AdTech #機械学習

tl;dr

  • ゲームサービス事業部 分析部の方々による、LTV予測システムの紹介とそれを支えるデータ基盤の運用について。
  • 【感想】BigQueryのコストを2/3にできたのすごい。ハッシュタグ #BQ警察 で知見が得られそう。
    • 「萎縮して使われなくなっては意味がない」と、厳しく取り締まるばかりではないのは素晴らしいなと思った

はじめに

  • ゲームサービス事業部 分析部
    • ゲーム事業における意思決定の支援をおこなう
    • データエンジニア
    • データアナリスト
    • データサイエンティスト

LTV予測による事業への貢献

  • LTVはマーケティングを中心とした業務/意思決定の基準になるため、重要性は高い
  • 特定の期間にゲームをインストールしたユーザーがその後支払った金額の平均をLTVとする
  • LTV予測の難しさ
    • 時系列の変化により、ユーザーの熱量・傾向が変化する
    • ゲーム内施策が未確定
  • 運用の課題も
    • 予測における恣意性の考慮
    • 予測モデル更新の負荷
    • 予実評価の難しさ・予測手順があとでわからなくなる

システム運用の改善について

  • BQのサイズ、2PB+
  • 昨年時点で680万円/月、それが420万円/月に
  • その過程で何をやったのか？
    • 現状の可視化
      • 3ヶ月ごとに+100万円、ストレージ・クエリ共に
      • stackdriver により GUI から簡単にBigQueryのメタデータの可視化を設定できる
    • システム的な改善、運用の改善
      • データライフサイクルを設定
      • ローテーションスクリプトを自動実行
      • Clustered Table を導入
        • Where句で指定するカラムにインデックスを付与することで検索範囲を絞ることが可能に
        • 新規テーブルを作成して既存テーブルからのコピーにより移行が可能
      • 巨大なjsonペイロードを1カラムに入れたまま使わない
        • よく使うデータはパースしてカラムに切り出す
      • BIツールの不要な定期実行機能を停止する
      • 巨大クエリ実行時に気づける仕組みを構築
        • システム的にガードを掛ける方向にはしないようにした、クエリを実行されなくなることを防ぐため。

Global Game Apps を支える Backend as a Service

#GAE #LiveOps #DevOps #mBaaS

tl;dr

  • GAEをもちいて構築されたmBaaS基盤の開発・DevOpsオペレーションについてのお話
  • 【感想】がっつりGAEについてのお話が聞けて満足
    • Pub/SubへのエンキューのフォールバックとしてTaskqueueを二段構えにして使っているの、面白い
  • 【感想】Ask the Speaker で GAE に対する stackdriver の使い方についてちょろっと聞けたので試してみよう〜

はじめに

  • 共通基盤としての mBaaS 基盤
  • 共通基盤機能
    • ユーザー管理
    • プレイログ
    • 認証機能
    • 仮想通貨管理
    • Push通知
    • etc.
  • mBaaS基盤の課題
    • 開発者に環境を提供できるまでの速度
  • mBaaSアーキテクチャをGCPマネージドサービスをフル活用したものに大幅刷新

GAE アプリケーションの DevOps

  • プロジェクトは「GameA」「GameB」「mBaaS」といった形で分割
  • タイトルごとのプロジェクトはおおきく2つ
    • 本番 / 開発検証
    • 本番プロジェクトに負荷試験環境もいれることで、Quotaの緩和制限のとりこぼしが発生しないように
  • GAE(SE)/Java
    • 非同期push型のsubscriberについては、internal な GAE アプリケーションを介する
  • 1つのプロジェクトで複数の環境を扱う
    • Datastore の Namespace を活用
    • Objectify を利用して Memcache を前段に Datastore を利用
  • 非同期処理には Taskqueue か Pub/Sub
    • TQは 500req/sec の制限あり
    • Pub/Sub は TQ よりは柔軟性がかなり低い
      • キューの中のタスクが見えなかったりとか
    • publish（enqueue）さえできれば異常があってもリトライされる
    • Pub/Sub への Publish に失敗したときに TQ に enqueue
    • Pub/Sub への publish は Datastore のトランザクションに含めることができない、要件を踏まえて許容できるようにした
  • デプロイは CircleCI から
  • nopromote オプションを利用し、デプロイしたものが即座に使われることがないようにしている
  • 定期的にアクセスが増えるタイミングが把握できている場合には計画spikeさせる
    • appengine-web.xml から min-idle-instance を指定する方法はデプロイが必要になる
    • Admin API からリクエストするとデプロイ不要でおすすめ
  • 監視
    • AppEngine / Dataflow にて出力されたログに対してMetricを設定、定期的にチェック。
      • アラート設定が簡単でよい、デフォルトメトリックが充実している
  • ロギング
    • GAE x stackdriver logging が素晴らしい、何も設定しなくてもフィルタが可能
    • 苦手なクエリというのもあるので、別途BigQueryにもExportしておき、そちらで検索するということも。

これ以降のLTとか

社の歓迎会があったので参加できませんでした、残念 ><

（以上）