■イベント Sansan Builders Box 2018 https://jp.corp-sansan.com/sbb2018/
■登壇概要 タイトル：「Azureで新サービスやってます」 登壇者：Sansan事業部 プロダクト開発部 開発マネージャー 神原 淳史
▼Sansan Builders Box https://buildersbox.corp-sansan.com/
Azureで新サービスやってます
View Slide
神原 淳史 @atsukanrockṗߴग़ͨͷʹͳ͔ͥઐֶߍߦ͙ͬͯΒ͍4*ͬͨޙ4BOTBOʹδϣΠϯɻ͙Β͍ΤϯδχΞຬ٤ޙʹ4BOTBO։ൃେ෦ୂͷ։ൃϚωʔδϟʔʹɻ͙Β͍Ϗδωεͱٕज़Λ݁Μͩޙʹ৽ϓϩμΫτʮ$VTUPNFS*OUFMMJHFODFʯͷ্ཱͪ͛ɻϓϩμΫτϏδωεΛ্ཱͪ͛Δ͜ͱͷຊ࣭త͠͞ʹཱ͔͍ͪͬͯΔɻٕज़తओઓ/&5$"[VSF"84%%%ɻझຯεϊʔϘʔυɻ࠷ۙͷؔ৺ࣄڭɻSansan Customer Intelligence開発者
Sansan Builders Box質問, 応援, ガヤ等はsli.doでhttps://bit.ly/2RLlG23( https://app.sli.do/event/tqkmstqb )
Sansan Builders BoxAgenda- Why Customer Intelligence?- What’s Customer Intelligence?- Why Azure?- Why Microservices?
Why Customer Intelligence?
顧客管理ありとあらゆる企業・組織において必要かつ重要
Sansan Builders Box顧客管理しようにも顧客情報が• 汚い問い合わせフォーム, アンケート回答, 営業の⾛り書き…• ⾜りない業種・業態は? 売上は? 当社と取引がある?• 分散しているCRM / SFA, MA, ERP, 会計, ⼿元のExcel…Customer pain points
Sansan Builders Box顧客管理しようにも顧客情報が• 汚い問い合わせフォーム, アンケート回答, 営業の⾛り書き…• ⾜りない業種・業態は? 売上は? 当社と取引がある?• 分散しているCRM / SFA, MA, ERP, 会計, ⼿元のExcel…→ 名刺管理で⼀定の改善が可能Customer pain points
Sansan Builders Box- 企業の顧客を統合管理- いつ- 誰が- どの会社の- 誰と会ったのか- ⼈脈DBを簡単に構築名刺管理とは
What’s Customer Intelligence?
Sansan Builders Box名刺管理を真の意味で顧客管理へ名刺は⼈脈の証であり顧客情報マスタでは、企業が持ち得る顧客情報は名刺だけですか?What’s Customer Intelligence?
Sansan Builders Box名刺以外の顧客情報も統合CustomerIntelligence
Sansan Builders BoxCustomer Intelligenceの中には、その企業が持ち得ているすべての顧客情報がある。各システムの顧客マスターデータが統合されていることにより、分散されていた時よりも質の⾼いデータとなっている。既存顧客でなく⾒込み客までのデータが企業、事業所、⼈物単位で体系的に管理されている。何も作業をしなくとも、メンテナンスが⾃動でなされ、顧客データが常に最新かつ正確な状態で維持されている。データを利⽤したいユーザーは、許可されている範囲で必要な量の顧客データを取り出し、⾃⾝の業務に利⽤することができる。Product vision
Why Azure?
Sansan Builders Box- 想定するアーキテクチャ設計への適性- 開発⽣産性, 運⽤性- 組織としての技術的選択肢の獲得→ AWS / Azure / GCPの3プラットフォームを上記観点で⽐較して決定Key points
Sansan Builders Box- Serverless- Messaging & Pub/Sub- Schemaless data- Fulltext search→ どのプラットフォームでもマネージドサービスの組み合わせで実現可能想定するアーキテクチャ設計
Sansan Builders BoxServerless FaaSにおける開発⽣産性が最重要開発⽣産性: 静的型付け⾔語 > 動的型付け⾔語※もちろん「状況に依る」が様々な状況を考慮してこう考えた、という話→ Cloud FunctionsでのサポートがJavaScript (Node.js) のみなGCPが脱落(最終的にメイン⾔語としてC#を採⽤しています )開発⽣産性
Sansan Builders Box当時Sansan社が抱える全てのサービスがAWS上に構築されていた今のところAWSの覇権は揺るがないがAzure, GCPも存在感を増している前提となる考え⽅: 技術選定は適材適所でただ、使ったこともないものを⽐較できるはずがない→ 敢えてAWSでなくAzureを選択組織としての技術的選択肢の獲得
Sansan Builders BoxAzureを選んでどうだったか (現場の声)- C#に優しい- ADとの統合で権限管理- Resource Group便利- Resource Manager秀逸- Table Storage激安- DevOps (旧VSTS) 便利- Durable Functions- Reserved Instance柔軟- 監視- メトリックが…- Alertが…- FunctionsのC#以外のサポート- ポータル: 重い、permalinkない- 課⾦周りで罠多すぎ
Why Microservices?
Sansan Builders BoxConwayの法則を逆⼿に取って組織的スケーラビリティを確保するl৫ͷઃܭ͢ΔγεςϜʹ ... ͦͷ৫ͷίϛϡχέʔγϣϯߏΛͦͷ··өͨ͠ઃܭʹͳΔͱ͍͏੍͕͋Δz (Conwayͷ๏ଇ)→ 逆に⾔うと「システム設計はコミュニケーション構造そのものになる」要は「強制的に分割可能性を確保する」ことにより開発チームを増やしても全体の⽣産性が上がらない問題の発⽣を防ぐMicroservicesの⼀般的な⽬的
Sansan Builders Box組織的にはまだMonolithで余裕⼩さなチームで開発している実⾏時スケーラビリティと運⽤性, 耐障害性のために敢えて当初からMicroservices的なアーキテクチャを選択もちろん将来的には組織的スケーラビリティのメリットを享受するつもりぼくらのMicroservices
Sansan Builders Boxアーキテクチャ (イメージ)Azure Functions(serverless FaaS)Service Bus(messaging)
Sansan Builders Boxメリット- 個々のfunctionをいつでも⽌められる- function単位でscale out / in & up / down可能- エラーになった箇所から再実⾏可能デメリット- 設計がいちいち難しい- 冪等性, 結果整合性など⾮同期分散処理の複雑さのため基本形: Azure Functionsをmessage queueで繋ぐ
Sansan Builders BoxMartin Fowler先⽣の「Microservidesの前提条件」• 迅速なプロビジョニング• 基本的なモニタリング• アプリケーションの迅速なデプロイめっちゃハードル⾼いやん…Microservices的にやってみての学び
Sansan Builders BoxMartin Fowler先⽣の「Microservidesの前提条件」• 迅速なプロビジョニング → Functions• 基本的なモニタリング → Application Insights & Monitor• アプリケーションの迅速なデプロイ → DevOpsめっちゃハードル⾼いやん… → 意外と何とかなるMicroservices的にやってみての学び
Sansan Builders Box2014年頃から各クラウドベンダーがマネージドサービスによるMicroservicesサポートに投資してきた結果、2018年現在ではだいぶ楽になっている模様Cloud Native Architecture / Kubernetesが盛り上がっているけどサービスが育つまでは使わなくて戦えるんじゃないかなMicroservices的にやってみての学び
sansanbuildersbox
danielkatz
sat
kosui
route06
coconala_engineer
lemiorhan
nayuts
etaroid
minorun365
h1kita
sinsoku
nikkei_engineer_recruiting
pauljervisheath
kneath
smashingmag
zakiwarfel
chrislema
tammielis
deanohume
keithpitt
addyosmani
maltzj
thoeni
lynnandtonic