少数チームによる高速な事業立ち上げ gcp サービ …...d2-3-s03: gcp...

D2-3-S03:GCP サーバーレスサービスと Sansan データ化技術〜少数チームによる高速な事業立ち上げ

木田悠一郎, DSOC Development Group エンジニア, Sansan 株式会社磯部俊行, カスタマーエンジニア, Google Cloud Japan 2019/8/1

木田悠一郎

Sansan 株式会社DSOC Development Group エンジニア

磯部俊行

Google Cloud Japanカスタマーエンジニア

GCP サーバーレスサービス

Sansan サービス紹介

高精度なデータ化を支えるノウハウ

少数チームで高速にサービスを立ち上げる

Agenda

01GCPサーバーレスサービス

サーバー設定

HW 調達

モニタリング

バージョニング

プログラミング

ネットワーク設定

ロギング

ストレージ設計

オーケストレーション

テスト

OS 設定

MW 設定

アプリケーション開発で考えること

物理サーバー / 仮想マシンの

プロビジョニング、管理、メンテナンスを意識することなく、

ソフトウェアの機能そのものや実行環境を得られる

サーバーレスとは？

No InfraManagement

Fully Managed Security

Pay only for usage

開発ビジネスバリュー

サーバーレスの目的

運用モデルプログラミングモデル

No Provisioning -> Scalability- サーバー不要- サービス単位でスケール

Secure- 組み込みのマネージド

セキュリティ- 自動アップデート

Pay for usage- スモールスタート- コスト最適化

Focus on service- サービス指向の開発- マイクロサービス

Event-driven- 疎結合- 変更容易性

サーバーレスの開発モデル

オーケストレーション vs コレオグラフィ

イベント

イベント

イベント

イベント各サービスが疎結合になり、開発単位が小さくなるため、高速に開発や変更が可能

Event-driven なアーキテクチャ

Compute

Data Analytics ML & AI

Database & Storage

Smart assistants &

chat

DevOps

Messaging

GCP のサーバーレスはフルスタック

Compute Database Messaging, Queue Data Monitoring

App Engine

Cloud Functions BigQuery Cloud

DataflowCloud

Pub/Sub Stackdriver

Cloud Run Cloud Storage

Cloud Memorystore

Cloud SQL

Cloud Spanner

Cloud Firestore

Cloud Bigtable

Cloud Tasks

Web アプリケーションのための GCP サーバーレスサービス

高いスケーラビリティを持つサーバーレス Web アプリケーション

管理が容易

サーバー管理なし

スケールアウトが高速

ゼロにまでスケールイン

パッチなどの更新なし

開発しやすい

アプリのコードに集中できる

バージョニング

トラフィックスプリット

サポートランタイム

Java

Python

Go

PHP

Node.js

Ruby alpha

{}

Google App Engine

● NoSQL データベース

● 強整合性

● 高い可用性

○ マルチリージョンで 99.999%

○ リージョナルで 99.99%

● 2 つのモード

○ ネイティブモード（Realtime）

○ Datastore モード

Cloud Firestore

Cloud Firestore の特長

データ更新をリアルタイムに同期

サーバサイドの DB としても

モバイルバックエンドとしても

name: "ユーザ A"description: "ユーザ A の説明"

My First Note

My Other Note

name: "ユーザ B"description: "ユーザ B の説明"

ドキュメント指向でスケーラブルなデータ構

成

信頼性の高いタスクのオフロード

フルマネージドのタスクキュー : 長時間の非同期タスクも確実にディスパッ

チ。インフラ管理なし、使った分だけお支払い。

レート制御と再試行

必要なスループットに合わせてレート制御や再試行の設定が可能。

HTTP/S Auth（IAM）を使った柔軟なタスクルーティング

GCP 内外のサービスに対してセキュアにタスクをディスパッチ。

マイクロサービス間の非同期タスク向けキューイングシステム

Cloud Tasks

at-least-once 配信

プロビジョニング不要の自動処理

グローバルにデザインされた高い可用性

信頼性の高いリアルタイムのメッセージング

Cloud Pub/Sub

GCP サーバーレスサービス

Sansan サービス紹介

高精度なデータ化を支えるノウハウ

少数チームで高速にサービスを立ち上げる

Agenda

02Sansanサービス紹介

法人向けクラウド名刺管理サービス個人向け名刺アプリ

03高精度なデータ化を支えるノウハウ

高精度なデータ化を支えるノウハウ機械の力と人力を組み合わせる

ミステイクディテクター

これにより、オペレーターは効率的

に最終チェックを行うことが可能にな

ります。

誤りの傾向を学習してミスの可

能性を予測

言語処理判定

● ４言語（日英中韓）に対応

● データ化フローの効率化

● オペレータへの振り分けの自

動化

● 精度 98 %

名刺画像から言語を判定

項目セグメンテーション

● 項目判別の結果を学習

● 単体モデルで項目矩形、

項目名の推定

● 精度 98 %

文字を読み取らずに、名刺のデ

ザインから項目を見分ける

高精度なデータ化のための人の力

● 入力ルールやトレーニング問題の作成

● 一つの項目に対する、複数のオペレータによる多重入力

● 入力内容に対する目視チェック

本日は「請求書のデータ化」に関する

取り組みをご紹介します

新たなデータ化サービスの検証

※ 正式な新サービスの発表ではございません

04少数チームで

高速にサービス

を立ち上げる

GCP サーバーレス採用の経緯

課題

運用負荷を下げ、本質的な機能の開発に集中したい

チャレンジすること自体に価値があり、

今後の技術選択の幅を増やすことができる

導入の背景

本気で使わないと分からない

昨年から社内でマルチクラウドを推進参照: https://www.slideshare.net/ShimpeiNagai/gce-sansan

請求書データ化システム

使用言語

フロントエンド

React, Redux, TypeScript

Cloud Functions

Node.js

バックエンド

Node.js, TypeScript, Express

自動化エンジン

C#

サービスの全体像

ユーザー側システム



データ化結果

入力 / データ化システム

社内オペレーター

入力

データ化

請求書画像

サービスの全体像


請求書画像



データ化結果


社内オペレーター

入力

データ化

KPI 基盤

App Engine

Cloud Functions

BigQueryCloud Pub/Sub

ロギング / エラー通知

Stackdriver

Cloud Storage

Cloud Firestore


Compute Engine


Cloud Dataflow

Cloud Tasks

アーキテクチャ



KPI 基盤



Stackdriver


Compute Engine


Cloud Dataflow

App Engine

Cloud Functions

Cloud Storage

Cloud Firestore

Cloud Tasks


KPI 基盤

App Engine

Cloud Functions



Stackdriver

Cloud Storage

Cloud Firestore


Compute Engine


Cloud Dataflow

Cloud Tasks



ファイル連携

KPI 基盤

App Engine

Cloud Functions



Stackdriver

Cloud Storage

Cloud Firestore


Compute Engine


Cloud Dataflow

Cloud Tasks



入力データ化システム

KPI 基盤



Stackdriver


Compute Engine


Cloud Dataflow

App Engine

Cloud Functions

Cloud Storage

Cloud Firestore

Cloud Tasks


● 非同期実行

● 定期実行

● デプロイ

● IP アドレス制限

● トラフィック分割

● オートスケール

新規開発で検討しなければならないこと

● 非同期実行 Cloud Tasks

● 定期実行 App Engine Cron

● デプロイ gcloud app deploy コマンド

● IP アドレス制限 App Engine ファイアウォール

● トラフィック分割 Traffic Splitting

● オートスケールほぼ設定不要

新規開発で検討しなければならないこと

App Engine

非同期実行 - Cloud Tasks

● 最低一回の実行を保証

● http status 200 系以外が返った場合はリトライ

○ リトライ回数の設定なども可能

Cloud Tasks

定期実行 - App Engine Cron

● cron.yaml で設定

● gcloud app deploy cron.yaml で反映

cron:- description: "日次バッチ" url: /tasks/summary schedule: every 24 hours

App Engine

デプロイ - gcloud app deploy コマンド

● Google Cloud SDK をインストールして設定

● プロジェクトルートに yaml ファイルを置く

runtime: nodejs10service: default

App Engine

IP アドレス制限 - App Engine ファイアウォール

注意点

● GCP サービス間の通信もブロックされることがある

● Cloud Tasks は内部的に URL フェッチサービスを使っているため、

URL フェッチサービスの IP アドレスを許可する必要がある

● Cloud Pub/Sub はグローバルなサービスであるため、

ホワイトリスト追加はできない

=> Cloud Functions、 Cloud Tasks 経由にすることで解決しました

Cloud Storage

Cloud Functions

App Engine

Cloud Tasks

App Engine

Cloud Pub/Sub

Cloud Storage

トラフィック分割 - Traffic Splitting

● 複数バージョンのインスタンスを同時に動かせる

● IP アドレスや Cookie でトラフィックを分割できる

● 管理画面から前のインスタンスのバージョンにロールバックすることも簡単

App Engine

オートスケール

スタンダード環境 or フレキシブル環境

可能な限りスタンダード環境を使う

○ サンドボックス環境で実行される

○ デプロイやスケーリングが高速

詳しい説明は割愛

○ 公式ドキュメント参照

https://cloud.google.com/appengine/docs/flexible/java/flexible-for-standard-users?hl=ja

https://cloud.google.com/appengine/docs/flexible/java/flexible-for-standard-users?hl=ja

フレキシブル環境を使うパターン①

● インスタンスを VPC ネットワークに紐づける

● Cloud Memorystore は VPC リソースなので、Cloud Memorystore を使いた

い場合も該当する

● 今回は、AWS 上の社内サービスと VPN 接続したかったので、フレキシブル環境を使用

○ 現在は Serverless VPC Access を使えば、スタンダード環境から VPC リソースにアクセス可能。

● 今は US のみだが、Tokyo リージョンに来たら乗り換えたい https://cloud.google.com/vpc/docs/configure-serverless-vpc-access?hl=ja

フレキシブル環境を使うパターン②

● CPU やメモリを消費する処理

● 特定のライブラリを使用する => 別サービスに切り出して Docker を使う

○ 現在は、Cloud Run を使うことでスタンダード環境と同じような

スケーラビリティを保ちつつ、Docker イメージを使った

柔軟な構成にすることができます。

App EngineCloud Functions

Cloud Storage Cloud Tasks App EngineCloud Tasks

Flexible Environment- 画像変換サービス-

データベース

データベース

KPI 基盤



Stackdriver


Compute Engine


Cloud Dataflow

App Engine

Cloud Functions

Cloud Storage

Cloud Firestore

Cloud Tasks


なぜ Cloud Firestore を採用したか

● Google App Engine はオートスケールする

● データベースのスケールがボトルネックになるのは避けたい

○ Cloud Datastore は有力な選択肢の一つ

○ Cloud Firestore は Cloud Datastore の次期メジャーバージョン

○ 公式ドキュメント参照: https://cloud.google.com/datastore/docs/firestore-or-datastore?hl=ja

Cloud Firestore

https://cloud.google.com/datastore/docs/firestore-or-datastore?hl=ja

Cloud Firestore における DB 設計

● 複数のフィールドに対するクエリに複合インデックスを作成する

○ インデックスを作成せずに複合クエリを実行するとエラーになる

● 関連をサブコレクションに持つことができる

● サブコレクションに対して、コレクションをまたいだクエリを発行できなかった

○ 全てのドキュメントに対してクエリを発行したい場合は、

ルートコレクションにする必要があった

○ 現在は Collection Group を使えばサブコレクションにもクエリを実行できる

Cloud Firestore

サブコレクションを使う場面

サブコレクションにすることで、

複合インデックスを作成せずに関連を絞り込める

Cloud Firestore

db.collection ('users').doc ('Kida').collection ('posts').orderBy ('postedAt')=> 複合インデックス不要

db.collection ('posts').where ('user', '==', 'Kida').orderBy ('postedAt')=> posts コレクションの user と postedAt フィールドに複合インデックスが必要

例）特定のユーザーの投稿を投稿時間の順に取得するケース

Cloud Firestore における DB 設計

SQL のような COUNT 関数はない

● ドキュメントをガバっと取ってきてカウントすることはできる

● 分散カウンタを使う

○ 1 ドキュメントあたり 1 秒間に約 1 回しか更新できない

○ カウンタ用のドキュメントを複数用意して、ランダムにインクリメントする

○ 全ドキュメントを取得して合計を計算する

● FieldValue.increment（）を使う

● v1.1.0 でリリースされた

● 要件によっては、Redis などでカウントするのもあり

Cloud Firestore

KPI 基盤

App Engine

Cloud Functions



Stackdriver

Cloud Storage

Cloud Firestore


Compute Engine


Cloud Dataflow

Cloud Tasks

ロギング・エラー通知


StackdriverStackdriver Logging

● 標準出力するだけでログを蓄積できる

Stackdriver Error Reporting

● 近いエラーをグルーピングしてくれる

● 同じエラーを何度も通知しない

● GCP Console からステータス変更

● メール通知できる

○ Gmail のフィルタ機能で Slack 通知も可能

Stackdriver

連携システム

KPI 基盤

App Engine

Cloud Functions



Stackdriver

Cloud Storage

Cloud Firestore


Compute Engine


Cloud Dataflow

Cloud Tasks

連携システム


自動化エンジン - Compute Engine

少しずつ自動化していく

※Web API として連携

請求書画像とオペレーターの入力データのセットを学習

KPI 基盤

● アプリケーションから Cloud Pub/Sub 経由でログを送信

● Tableau で可視化

App Engine BigQueryCloud Pub/Sub Cloud Dataflow

Tableau

GCP サーバーレスで

得られたメリット

GCP サーバーレス採用の経緯

課題

運用負荷を下げ、本質的な機能の開発に集中したい



導入の背景

本気で使わないと分からない

昨年から社内でマルチクラウドを推進参照 https://www.slideshare.net/ShimpeiNagai/gce-sansan

初期構築コスト

運用コストが削減本質的な機能の

開発に集中できた

GCP サーバーレスで得られたメリット

デプロイ

オートスケール非同期処理

定期実行

ファイアウォール

トラフィック分割


既存システムとの比較

名刺データ化システム

アプリケーションエンジニア複数名 / 定常的に運用業務あり


アプリケーションエンジニア 1 名 / 運用業務なし

サーバレス

※ 処理量が異なるので、あくまで参考になります

コスト最適化

● 新規事業 = サーバー費用などのコストもなるべく抑えたい

● Google App Engine はインスタンスが 0 台までスケールイン

○ コスト管理の手間も削減して最適化

今後やりたいこと

Cloud AutoML による請求書分類

現状、以下のような分類が存在する○ 振込先が海外の口座

○ 口座振替（引き落とし）

○ その他

振込先:国内

振込先:海外

口座振替（引き落とし）

・・・その他

現状オペレータによる仕分け

Cloud AutoML を活用できないか

● Node.js クライアントライブラリを使ってアクセスする

● 書き込み、読み取りの際にただのオブジェクトになってしまう

○ TypeScript を使っている旨味を享受しづらい

● クライアントライブラリをラップして set(), update() などの引数に

型を指定できるようにしているが、少し煩雑になっている

● リポジトリ層のようなレイヤーを導入して、ドメインオブジェクトとのマッピング

などを模索中

Cloud Firestore まわりの実装

Cloud Firestore

社内での GCP 普及活動



● プロジェクトで閉じてしまっては意味がない

● 得られた知見を社内で共有し、

全社的に技術選択の幅を増やす

Sansan のデータ化ノウハウを活かした、新たなサービスの創出にチャ

レンジする仲間を募集しています！！

We are hiring!

Enjoy GCP!!

少数チームによる高速な事業立ち上げ gcp サービ …...d2-3-s03: gcp...

Documents