Bpstudy20180725

Copyright © Virtual Technology, Inc
サーバ構築ゼロで
フロントエンドが主役の開発を
2018/7/25 BPStudy#131 ⽵嵜伸⼀郎(@stakezaki)
1

⽵嵜伸⼀郎（たけざきしんいちろう）
twitter id:stakezaki
（有）バーチャルテクノロジー代表取締役
元⽇本IBM
元株式会社暮らしのデザインCTO
2

vte.cx 半端ないって！
あいつ半端ないって！
だってjavascriptだけで
Webサービス作れるんやで！
そんなん出来ひんやん普通！
3
vte.cx(ブイテックス)
著作権フリー画像

DEMO
4

何で作ったか？
• 楽しく仕事したい
• ゴールドラッシュではツルハシを売れ
• 既存技術に満⾜できなかった
5
「成功の確率はとても低いことをよく知っています。
それでもスタートアップを始めるのはそれがどうしてもやりたいことだからです。」
＜本⾳＞

楽しく仕事したい
• やっつけ仕事でなく楽しく開発したい
– ミドルウェアや⾃社サービスの開発は楽しい。
しかし、受託開発は⾟い。＝やっつけ感
– ⼈材派遣商売はいつか⾏き詰まる。
• 弊社エンジニアの⼀⼈がうつ病に
6
派遣の仕事をやめ、 vte.cxの受託案件だけに絞った
これで、⾃社サービスと同じような開発スタイルで
「持ち帰り」で「アジャイル」開発することが可能になった
また、積極的にOSSにしていくことでモチベーションアップ

ゴールドラッシュではツルハシを売れ
• ゴールドラッシュで最も⼤きな成功を収めたの
は採掘者たちに必需品を売った⼈
• ⼀般ユーザ向けにサービスを提供する（⾃⾝で
⾦を採掘する）か、⼀般ユーザ向けにサービス
を開発しているデベロッパー向けにツールを売
るか（ツルハシを売る）
7
BaaS＝ツルハシ

業務アプリのお決まり機能を提供
• ログイン認証
• データ⼊⼒フォーム
• ⼀覧表⽰
• ページネーション
• CSVアップロード
• PDF帳票出⼒
• メール送信
• データ分析
8
スクラッチで作る必要がない
⼯数削減、短納期で開発可能
エンジニアはきっと⾶びつく
だろうと考えていた

しかしエンジニアに全く興味持ってもらえず
9
フレームワーク
売ってまーす。
しーん
・・・
ツルハシ(BaaS)
使いませんか？
「つまり、エンジニアが欲しがるものを作っていなかった」
お客様
（エンジニア）

エンドユーザに直接アプローチ
10
⼀緒に作りましょう！
早いし安いよ！
受注システム
欲しいなあ
WoW！
お客様
（エンドユーザ）
顧客の抱える課題の専⾨家になり顧客に愛されるプロダクトを作ることだけに集中

こんなこと⾔われた
11

Firebaseとは競合しません！
• vte.cxは業務システム(例えば、受発注システム
や在庫管理システムなど）をターゲットとして
います。
12
• ログイン認証
• データ⼊⼒フォーム
• ⼀覧表⽰
• ページネーション
• CSVアップロード
• PDF帳票出⼒
• メール送信
• データ分析
Vte.cxが得意とするところ

想定しているお客様
• ⾃社でWebサービスを⽴ち上げたい
• 開発＋サービスの運⽤もまかせたい
• SaaS/パッケージ製品では機能がフィット
しない。カスタマイズできるものがほしい
13
これって
機能追加できる？
お客様
はい、
すぐにできます。
vte.cx開発者
BaaS

ビジネス領域
14
所有
利⽤
特化⼀般
SaaS
IaaS
PaaS BaaS
パッケージSI フレームワーク+
カスタマイズ
オンプレミス
クラウド
• 圧倒的なパフォーマンス+スケーラビリティを低価格で提供
• SaaSでは対応できない特定顧客向けソリューションを素早く提供
コンペの多く
がココ
2/17
PHP FW
超高速
開発

特定顧客向けソリューションをやる理由
15
• 最初はツルハシ(BaaS)だけで商売できたらいいな
と思っていたがうまくいかないことがわかった
• 潜在ユーザーを信じて戦い続けるのは鉄のメンタ
ルと経済⾁体双⽅の体⼒が要る。たぶん、負ける
• やはりキラーアプリケーションが必要
• お客様と共同開発でOSS化
• 現在、受注在庫管理システム、倉庫管理シス
テムを開発中(OSSで公開予定）
• 私達は開発⾃体は好き。ミドルウェアだけでなく
新規のサービスを作っていきたいし⾃分たちで作
ることで改善点もわかる（ドックフーディング）

BaaS+OSS戦略で勝算アリ！？
• 既存システム（受注・在庫管理システム
等）のOSSを提供、カストマイズする戦略
• 圧倒的な開発スピードと低コスト
• 運⽤費はもともと安い(オンプレ⽐1/10)
16
オンプレのパッケージには絶対負けないはず
※個⼈的感覚

何で作ったか？
• 楽しく仕事したい
• ゴールドラッシュではツルハシを売れ
• 既存技術に満⾜できなかった
17
ここからは技術的な話が中⼼になります。
あくまで個⼈的で主観的な内容です。
またお客様にとってみたらどうでもいい話

l
View Service Resource
既存技術に満⾜できなかった
2007年頃、ECサイトをオンプレミスで開発(⼀応、マイクロサービス）
品質最悪
スケールしない
三重苦
管理が⼤変

いったい何をやっているのだろう？
•膨⼤な⼯数
•解決しない課題
•⾒えないメリット
19

乗り越えなきゃいけない課題
• 運⽤管理を楽にする
• スケーラビリティを確保
• アプリの品質向上
• 可⽤性向上
20

「先進の技術」なんてのはIT屋の寝⾔
• エンドユーザはシステム開発を必要悪と
して認めているにすぎない。開発しない
で済むならそうしたいと思っている。
• ⼀⽅のエンジニアは新技術を採⽤したが
りそれによって⼯数が膨れても当然とい
う顔をする。
21
サーバレス、マイクロサービス、OpenAPI、GraphQL、・・・
楽しさという罠にハマり、やりたいことをやるのがエンジニア

本質的なことに集中しよう
• 「本来の、本質的な」＝バーチャル
• お客様はWebサービスを素早く構築して
世の中に出したいと思っているはず
• いかに内部の設計が素晴らしくても膨⼤
な⼯数と時間がかかってしまっては意味
がない
22

いろいろやめた
• PHPをやめてReactのSPAに
• RDBをやめKVS(Datastore)+BigQuery
• Microservicesをやめてk8s構成に
• Thin Server Architecture
ではなくBFFの導⼊
23

SPA(Single Page Application)
• サーバーでHTMLを⽣成するよりも、
クライアントで動的に画⾯を更新する⽅が効率的
• ユーザーの操作に応じてインタラクティブに動く
リッチクライアントを実現できる
24
これってネイティブアプリ？
お客様
いいえ、Webアプリです。
開発者
SPA

フロントエンド中⼼の世界感
• HTML、CSS、JavaScriptなどのコーディングだ
けで本格的なWebシステムを作れるようにした
• サーバサイドのAPI (API設計とスキーマ)もフロ
ントエンドエンジニアが⾃由に作れるようにした
• JavaScriptのエコシステムを採⽤することでロッ
クインを排除した
25

vte.cxのこだわり
• バックエンドの複雑さを隠蔽
– サーバ構成の都合をクライアントに押し付けない
– Microservicesでありがちな認証などの考慮をクライア
ントにさせない
• Webアプリのことだけに集中させる
– 重要なのはAPIとスキーマ設計(+ACL)
– 静的コンテンツを含めSame Originで管理する
• ローカル開発環境やCI/CD環境を提供
– JavaScriptエコシステムを利⽤したローカル開発環境
– 複数のブランチに対応したサービスを⾃由に作成可能
– CircleCIなどによる⾃動デプロイ
26

Thin Server Architecture
27
・・・
REST
• クライアントからRESTでサーバリソースにアクセス
• サーバからはJSONやXMLのデータを返すのみ
データ

Copyright © Virtual Technology, Inc28
• URLをフォルダに⾒⽴てて⾃由に設定・追加可能
• リソースを様々なフォーマットに変換可能
• XML、JSON、MessagePack等などのデータ
• HTMLやCSS、JavaScript、PDF、画像などの静的コンテンツ
REST APIと直感的な規約

API以外の余計なことは考えたくない
29
適当に分散して勝⼿にスケールすることを期待
これが真のサーバレスではないのか！？

ちなみにサーバレスアーキテクチャー
(FaaS)
30
API Gateway
Lambda
Cognito SNSDynamoDB
Cloud Front
S3
clientmobile client

Webプラットフォームとしては時期尚早
• 静的コンテンツとAPIが異なるドメイン
– CORSの設定なんか画⾯からやりたくない
– イベント・ドリブンでWebアプリ作れんの？
– あとセッション管理どうすんの？
• デプロイどうすんの？
• Spinup、200ms問題
• サービス利⽤には認証が必要
– CognitoのSecurity Token Service
• たぶん、Knativeも同じ31

Kubernetes !!これでしょ！
•無停⽌メンテナンス
•可⽤性向上
•スケールアウト
•ログ⼀元管理
32

サーバ側すべてをサービス化
• DBの設定⾃体はそれほど難しくないがその後の運⽤が⼤変=>KVSに
• トラフィックが増えたらサーバを増やす、運⽤状態をモニターする、その
他無数の管理業務がある=>k8sの運⽤監視、StackDriver
33
すべてをサービス化することで運⽤コストを劇的に下げる

WebスケールIT
• グーグルやアマゾン、フェイスブックといった
⼤⼿のクラウド特有のアーキテクチャによる分
散システムで、⾼度に⾃動化された運⽤管理に
より、システム規模の拡張にも、負荷を最⼩限
に抑えることが可能な特⻑を備えるもの
• このアーキテクチャを適⽤させることにより、
⼩規模のサービス・プロバイダーでも、「⼤規
模なクラウド・サービス・プロバイダーと同じ
能⼒を提供するグローバル・クラスのコン
ピューティング様式」を実現することが可能
34

Microservicesをやめた
• 機能が増えたらその都度サービスを⽴てるのか?
• BaaSでは論理的にサービスを追加でき⾃由にAPI
を作ることができる。それで⼗分では？
35
“ソフトウェアシステムの⼤多数は、
単⼀のモノリシックアプリケーション
として構築されるべきである”
by Martin Fowler

36
ビジネスロジック PDFService
モノリスにしてkubernetes構成
ビジネスロジック
+PDFService
ビジネスロジック
+PDFService
分散するとスケーラビリティと
可⽤性の対応が難しくなる
Microserviceによる構成
オーケストレーションツールにスケーラ
ビリティと可⽤性の対応を任せられる
ビジネスロジックと PDFServiceは⾮⼲渉化
されており、変更がお互いに影響されること
はない
ノード1 ノード2
ノード1
ノード2
機能単位でわけるならモノリスで⼗分

マルチテナントで実現するMicroservices
それぞれが独⽴して動作するアプリケーション
37
Microservicesの単位は実はもっと⼤きい
販売管理
サービス
受注出荷管理
サービス
API連携

しかしフロントの責務が増える
http://www.slideshare.net/fullscreen/sagawafumio/ss-38480894/6

BFF(Backend for Frontend)の導⼊
• クライアント偏重の是正
– ⾮同期コールバック地獄に陥りがちなクライアントより
サーバで処理実⾏した⽅が有利であることに気づく
• Thin Server Architectureを⾒直し
– サーバサイドの開発はやはり必要
– Server Side Javascriptでビジネスロジック記述
• Isomorphic(Universal)
– SSR、動的PDF出⼒
– サーバで同期実⾏
39
例えば、
鏡と明細の
マージ編集

FrontendとServer Side
40
Browser
(React)
Backends for
Frontends
(Server Side
JavaScripr)
Datastore
Bigquery
vte.cx API
Frontend Server Side
BFFはServer SideにあるFrontend機能のこと
Client Side

GraphQLではなくBFFで
• GraphQLが解決しようとしていること
– クライアントからリクエストを何度も発⾏する
必要がある(N+1問題)
– 提供されているAPIが不⼗分だと、クライアント
側でテーブル結合する必要があるなど
• そもそもAPI変更コストが⼤きいという前提がまずい
– サーバ側の変更は基本的に⼤変なのでAPIはなるべく変更した
くないという背景(変更に数週間かかるなど）
– APIは最⼤公約数的なものになってしまいがち
41
結局はクライアントで頑張る発想から超えられないGraphQL
⼀⽅、柔軟にAPIを作成でき、かつ、開発コストも低い
BFF(ServersideJS)があればGraphQLは不要ではないか!?

型
• 型があれば10%〜20%のバグを減らすこ
とができるとの調査結果
• サーバサイドにおける動的型付け⾔語疲れ
42

エントリスキーマ
• シンプルなシンタックス
– 「項⽬名（型）＝正規表現」の形式で記述
– Indexを指定可能
– 正規表現でバリデーション
• ソフトスキーマ
– 項⽬の追加が可能
– 運⽤中でも変更可
43

エントリスキーマから
TypeScriptの型を⾃動⽣成
44
管理画⾯からTS型定義ファイル出⼒が可能

まとめ：採⽤してよかった技術
• SPA(React/React Native)
• TypeScript
• ソフトスキーマ
• BFF(Server Side JavaScript)
• Kubernetes(GKE)
• Google Datastore
• Google Bigtable
45
圧倒的な開発⽣産性
⾼いクオリティ
スケーラビリティ
⾼可⽤性
低コスト
運⽤保守(DevOps)

まとめ：採⽤しなかった技術
• Microservices
• Serverless(FaaS)
• OpenAPI
• GraphQL
46

ビジョン
”もうフルスタックエンジニアはいらない。
HTMLとJSの知識さえあればWebサービスを
開発できる。
そのような世界を私たちは⽬指しています。”
47

support@virtual-tech.net
パートナー募集中！

Bpstudy20180725

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Bpstudy20180725

Ähnlich wie Bpstudy20180725 (20)

Mehr von Shinichiro Takezaki

Mehr von Shinichiro Takezaki (9)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)

Bpstudy20180725