Azureで新サービスやってます

神原 淳史 @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 Box Agenda - 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 名刺以外の顧客情報も統合 Customer Intelligence

Sansan Builders Box Customer 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 Box Serverless FaaSにおける開発⽣産性が最重要 開発⽣産性: 静的型付け⾔語 > 動的型付け⾔語 ※もちろん「状況に依る」が様々な状況を考慮してこう考えた、という話 → Cloud FunctionsでのサポートがJavaScript (Node.js) のみなGCPが脱落 (最終的にメイン⾔語としてC#を採⽤しています ) 開発⽣産性

Sansan Builders Box 当時Sansan社が抱える全てのサービスがAWS上に構築されていた 今のところAWSの覇権は揺るがないがAzure, GCPも存在感を増している 前提となる考え⽅: 技術選定は適材適所で ただ、使ったこともないものを⽐較できるはずがない → 敢えてAWSでなくAzureを選択 組織としての技術的選択肢の獲得

Sansan Builders Box Azureを選んでどうだったか (現場の声) - C#に優しい - ADとの統合で権限管理 - Resource Group便利 - Resource Manager秀逸 - Table Storage激安 - DevOps (旧VSTS) 便利 - Durable Functions - Reserved Instance柔軟 - 監視 - メトリックが… - Alertが… - FunctionsのC#以外のサポート - ポータル: 重い、permalinkない - 課⾦周りで罠多すぎ

Why Microservices?

Sansan Builders Box Conwayの法則を逆⼿に取って組織的スケーラビリティを確保する 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 Box Martin Fowler先⽣の「Microservidesの前提条件」 • 迅速なプロビジョニング • 基本的なモニタリング • アプリケーションの迅速なデプロイ めっちゃハードル⾼いやん… Microservices的にやってみての学び

Sansan Builders Box Martin Fowler先⽣の「Microservidesの前提条件」 • 迅速なプロビジョニング → Functions • 基本的なモニタリング → Application Insights & Monitor • アプリケーションの迅速なデプロイ → DevOps めっちゃハードル⾼いやん… → 意外と何とかなる Microservices的にやってみての学び

Sansan Builders Box 2014年頃から各クラウドベンダーがマネージドサービスによる Microservicesサポートに投資してきた結果、 2018年現在ではだいぶ楽になっている模様 Cloud Native Architecture / Kubernetesが盛り上がっているけど サービスが育つまでは使わなくて戦えるんじゃないかな Microservices的にやってみての学び

No content