大家的印象

• 昨年de:codeに参加した時も思ったけれど、HoloLensとか自動翻訳といった、消費者目線で体験が変わるものの話を聞くのはおもしろい。de:codeはセッションのテーマの幅が広いので、普段あまり接点がない分野の話を聞けるのが楽しい。

 

• この半年くらいAzureを使った開発をやった身から見ると、Azure関連のセッションは、まだ各リソースの概要説明的なものが多いように感じた。deep dive的なセッションや、AzureのPaaSを活用した開発事例のセッションが増えるといいなと思った。（富士フイルムさんの事例セッションがとてもおもしろかった）

 

セッション間の移動など会場が昨年より快適だった気がする！（何がどう変わったのか具体的には分からなかったので、思い込みかもしれない）

2017年5月23日

为了改变‘不变的开发现场’- 为企业级遗留系统开发商准备的DevOps再入门。

个人感受

• 大きなSIerだとアーキテクトのキャリアパスがないというのは共感した

 

• 日次ビルドで自動でメトリクスを取ってグラフ化するというのは、やったことがないので、なるほどと思った

 

• “DevOps”のようなキーワードを使わずに、課題解決メリットベースで具体的な議論をすることが大事

 

前職での印象だと、スーパーSEとスーパーPjMにぶら下がっている案件は多く、「スーパー」の度合いによって案件成功することもあるとは思う

开发进展的“可视化”

问题

• 外注した成果物の品質チェックがうまくいかない

 

• 納品直前 or 後になってから品質問題が発覚する

 

• レビューしているのに、品質データを確認しているのに

 

アーキテクトがいない、開発途中の状況を十分に「見える化」できていない

建筑师的重要性

• PM、業務SE、アーキテクト、デベロッパー、テスター

 

• アーキテクト

開発技術を熟知するエンジニア
方式設計（開発標準化）を通して、実装成果物の品質を担保
実装成果物のレビューなどを実施

SIerではアーキテクトの肩身が狭くなることが多い（SE/PjMが圧倒的多数、キャリアパスがない）

全社的に：CoE組織へのメンバー集約、社内コンサルとしてプロジェクト横断的に配置
給与以外でのメリット強化（最新PC・デバイス、書籍）、最先端技術を使ったプロト開発や提案支援

项目进展的“可视化”

• 成果物レビュー

これはこれで重要

継続的インテグレーションによる実装状況の把握

日次ビルドで計数データを自動収集
コード総量、コードチャーン（変更量）、チェックインされた作業数、リードタイム、単体機能テストなどを集計）
⇒グラフ化する
Projectのheart beat

カナリアサーバによる現物チェック

最新版のソースコードを常にデプロイ
数値データを見るよりも、実物を動かした方が、品質状況はわかりやすい

总结

• SIerのコアコンピタンスは、業務、プロマネ、技術

 

• アーキテクトが必要だが、少数派になりやすいため、ケアが必要

 

CI/CD、カナリアサーバなどの実践していくことが必要

掌握现代项目管理技术

• スーパーSEとスーパーPjMにぶら下がって作業すれば成功するようなSIなどもはや存在しない

 

トップダウン型からボトムアップ型へ

项目管理和任务管理的趋势

• WBSの末端レベルは、現場担当者に協力してもらう

末端タスクが漏れたり、情報が古くなるのを防ぐ
末端タスクは現場メンバーにより分解して、更新してもらう

お手軽なタスク管理

タスクの抜け漏れの防止にのみ注力：Office 365 Planner/Trello

しっかりしたタスク管理

進捗状況の把握と終了見積まで実施：TFS Work Item Tracking/Rdmine/JIRA
Scrumの予備知識や、チーム内での標準化が必要になったりする

前提条件的差异 tí de chā yì)

• DevOps自体を導入する必要はない

アメリカはオフショアが急速に進んだため、内製で残っているのは高付加価値な開発（SoE型）
日本はオフショアが進まなかったため、すべてがぐちゃっと残っている

日本にとって重要なのは、「実践的活用による現場改善」

導入時に魔改造する必要など全くない
自分の現場で使えるものだけをピックアップして活用すればよい

「一歩ずつ」理想形に近づける努力を繰り返す

スクラップ＆ビルドでは現場は改善しない
「理想形」と「現実的な制約」を同時に考え、一歩ずつ理想形に近づけていく（ロードマップ的に考える）

DevOpsというキーワードを使わない、思考停止に陥らない建設的な提案と議論が必要

MR01 真心投入HoloLens – 计划/设计/开发的关键点 –

感觉

• HoloLensのことをほとんど知らなかったので、特徴や事例から実装イメージまで概観が理解できてよかった

 

AR/MRの違いの定義がなるほどと思った（部屋の壁に穴が開いてそこからモンスターが出てくるとか）

混合现实

• physical reality 実際に存在 / virtual reality 人工的に作られたもの

Mixed Reality: physical realityにvirtualなオブジェクトを置いていく

ARは情報は画面上にあり空間座標は持たない / MRは物理世界との干渉がある（物理的なものの奥に置くと見えない、とか）
3D Mappingしている / Hololensが見た範囲をどんどん認識して、mappingが追加されていく
ARタイプ

ThyssenKrupp：作業者にダッシュボードを表示

MRタイプ

壁に穴が空いて、そこからモンスターが出てくる

VRタイプ

疑似VR的な旅行アプリ（HoloTours）

HoloLens

ケーブルレスのスタンドアローンコンピュータ
最先端のセンサー（Kinectで使っていた技術）、ジェスチャーを拾う
シースルーなレンズ（作業しながらモニターを見られる）、空間上に2Dのアプリを配置して利用できる
spec的に、モバイルアプリくらいの想定でアプリ開発する必要がある（ポリゴンリデュースとか）、CPUは32bit

Windows10に接続するVRヘッドマウントディスプレイがOEM各社から発売予定

OEM各社から発売予定、3-4万円で出てくる予定
ジェスチャーの認識はない、その代わりモーションコントローラーでの操作
空間マッピングがない

为HoloLens开发应用程序。

• 2Dアプリ：ストアに公開されているUWPアプリ

空間上に複数Windowを並べることができる

3Dホログラフィックアプリ：UnityもしくはDirectXで開発（build時にはUWPのパッケージ形式になる）

基本的に排他アプリ、Full Screen起動のイメージ
8-9割のアプリはUnity、VSでコンパイル（メモリ8GBくらいは欲しい）

Device Portal

アプリは立ち上げた場所でないと閉じられない、ここから閉じる
Live Streamingができる

在Unity中的开发

• 背景を黒にすると、透明になる

 

• カメラ = 自分 = HoloLens

 

• Cube（立方体）を配置

 

• scene（画面）を保存

 

• build -> target deviceをWindows Storeに固定、sceneを選択

 

• Visual Studioのプロジェクトを保存

 

• Visual Studioで開く

対象CPUをX86
USB接続もしくはWiFiリモートデバッグ

HoloLens Toolkit for Unity

GitHubにて公開、HoloLens固有の機能をライブラリ化
視線、ジェスチャ、音声コマンド、空間マッピング…

应用程序设计的注意事项

• ホログラムをどこに置くのか？

1.25-5mがスイートスポット
2m:2Dアプリを操作するのに適した距離
ホログラムは触らないように設計（カーソルを使って操作する）

開発に向けて

体験会などの開催、プロトタイプ開発 -> HloLensの機能や特徴についての理解
実案件に向けたシナリオの開発
体験会でお勧めのアプリ：AirCraft Explorer, HoleLenz

成功させるために

Technology Drivenはダメ
Issue Drivenで考える
問題解決をするためのアプリやストーリーを考える、iPadでいいじゃんにならないようにHoloLensでないと解決できないことを考える

Envisioning

HoloLensを使った利用ストーリーを考える
目標の明確化、問題解決のための使い方を考える
利用方法の分類
ペルソナを考えたストーリーの作成
絵コンテ、UIデザイン
その後に、機能や仕様を定義する

例子

• 作業支援：ThyssenKrupp

 

• 建築：Trimble（sharingでオブジェクトを共有）

 

• Catalog：VOLVO（ショールームの１台分のスペースに、好きな車を置く）

 

教育：JAL

DI04 不使用实在是太可惜了！让我们驾驭全球规模的NoSQL服务“Azure Cosmos DB”。

经验所得 / 所感之处

• DocumentDBも統合されたCosmosDBの網羅的な説明という感じ

 

• 整合性モデルを選べるのがおもしろいと思った（実際に選ぶのは難しそうだけど）

 

機能が多くて、50分だと細かい話までいけない・・・

Azure Cosmos DB领域数据库

• 世界中にグローバル分散されたマルチモデルのデータベース

グローバル分散アプリの適切な開発
複雑なスキーマの管理、バージョニング
グローバルの需要をもとにした、スループット／ストレージのスケーリング
強い整合性（一貫性）、結果整合性のバランス
応答性
常時稼働

NoSQLの進化

2010 Project Florence
2014 Document DB Preview
2015 Document DB GA
2017 Cosmos DB GA

Cosmos DB

ターンキー形式のグローバル分散
1対多で、自動的に世界中のリージョンにレプリケーション
リング０（すべてのリージョンで利用可能）
マルチホームAPI（１つのconfigで、書き込み／読み込み先の優先順位を設定可能）
手動/自動フェールオーバーのサポート

ストレージとスループットは、独立してスケールアウト可能

1kbのdocumentのreadが1RUくらいのイメージ：response headerで確認可能
ストレージ：GBからPB
スループット：数百から数億リクエスト/秒
低レイテンシの保証：同一リージョン内であれば99パーセンタイルで、readが10ms以下、インデックス作成されるwriteが15ms以下

パーティション

現状：コンテナ―（コレクション）内の全パーティションが、一つの書き込みリージョンに配置される（ReadOnlyはグローバルにレプリケーションできる）
今後：パーティションごとに、異なる書き込みリージョンに配置可能に

key-value, json, Gremlinグラフ対応が追加されている
indexを自動生成（すべてのfieldに対して）
整合性は５つの整合性モデルから選択可能

コレクション単位でデフォルトの設定、呼び出し単位でオーバーライド可能
Sessionを使っているケースが多い

SLA

可用性SLA／一貫性SLA／スループットSLA／99パーセンタイルのレイテンシSLA

事例

TOYOTA
Jet.com
Next Games

public preview

RU/分（スパイクや予期せぬスループットのニーズに対して、予測可能なパフォーマンスを提供）
Azure Table Storage(KVS) APIサポート、ユーザ定義クエリ向けのセカンダリインデックス
Gremlin APIサポート：グラフの格納と操作に最適化（Apache TinkerPopを使用）

在50分钟内成为Bot开发者！通过实践经验以及结合Azure和Office 365的架构传授。

切身感受

• bot frameworkを利用したbot開発の流れが一通り分かる

 

• 各チャットサービスで、どんなcardsがあるのか知りたいと思った

 

payments対応が発表されたらしく展開が楽しみ

机器人

• bot

人々が費やす時間の84%は、5つのアプリで消費される⇒Messaging Apps
迅速に、どこでも簡単にアクセス、自然に利用できる

Demo

B2C:鎌倉 Navitime Travel
B2B:Microsoft Teamsでmeeting設定

项目开发工程

策划

• デザインガイドラインを読む

 

• スケッチで会話の流れを企画

 

• メッセージ以外のUIも検討

写真とか
Channel InspectorでUI検討

適切なチャンネルを選定

nativeアプリからであればDirect Line API、Skype、Microsoft Teams

早くリリースしてフィードバックを受ける

メッセージログはユーザの要望、ログをベースに機能追加

选择必要的框架

• Bot Framework

Bot Builder SDK:ダイアログ形式のコミュニケーションを実装（C#, Node.js）
Bot Connector（メッセージサービス間の差異を吸収）
Bot Directory
C#, Node.js以外であれば、Rest APIを叩く

Bot Framework Emulator
Azure Web AppsのようなWebサーバ（https）が必須
Bot Service: Azure上で完結

软件开发和调试

• 開発

１話題１Dialog Classとして実装
会話継続中はデータをクラス変数に保持
入力待機するメソッドを指定して会話を組み立てる

StartAsyncから必ず開始、次の入力を待機するMethodを指定、他のダイアログを呼び出すことも可能
State Serviceで状態は保持（Map/Dictionary的にデータ保持）

进行远程调试和分析

• Webサーバに展開

 

• Bot FrameworkのMy botsから登録

messaging endpointにWebサーバのURLを指定（https://—–/messages）
Web.configにID/passを指定

チャンネル設定
botframeworkのanalyticsで利用状況の分析ができる、Application Insightでエラーを確認

将Office365与其他系统或应用程序进行集成

• Microsoft Graph API

Azure ADと、OAuthを使って認証認可

Azure合作

• Cognitive Services

LUIS, Bing Spell Check, Text Analytics, Bing Image Search, Custom Vision
Intentによるロジック分岐
LUISに固有名詞をすべて覚えさせると肥大化するためText Analyticsで拾っていたが、LUISにもカスタム辞書が追加された
Custom Vision: 独自カスタマイズ学習モデルからタグ情報を取得

Direct Line API v3.0

HTTP POSTで投げて、返答はWebSocket
テスト自動化しやすい

API Management

最新のbotのurl+tokenをネイティブアプリに配布

Azure Search

インデックスのスコアリングも柔軟な対応が可能（日本語／英語でスコアを変えている）

Cosmos DB

Azure Searchのデータソース（スポット＋記事データ）
ログ（ユーザーの発話データ）

最新消息

• Payments

 

• Speech

 

SecretaryBot開発ブログ

2017年5月24日

MR10 你的服务可以与Cortana连接起来！从Cortana Skills的功能到实施

我的感受

• Cortanaへの組み込みということだったが、基本はbot frameworkで、特に留意すべき点はあまりないように感じた

 

音声入力＆LUISの概念を含めて、実装方法はalexaとほぼ同じだと感じた。であれば、バックエンドはAzure Functionsとの統合度を上げてほしいと感じた。

Cortana 技能

• iPhone/androidではアプリとして

 

• Cortana Device SDK: connected car / harman

 

• Cortana Skills Ket: 2017 Buildで発表

Bot Framework Cortana Channel / Cognitive Services LUIS / Skill Development Tools

音声でいろいろなSkillsを呼び出すことができる

Hey Cortana Ask Applause
Hey Cortana Ask Bartender how to make a Manhattan

現状ではBot Framework based skillsのみ
Bot Framework Messaging EndpointをCortanaポータルにメタデータ登録
Invocation Name

Start / Launch / Run
Ask

OSの言語設定：US Englishのみ対応、en-usマーケットのみ利用可能：US在住のMSアカウントを作成

必需的工具 (bì xū de jù)

• VS2017 / VSC

 

• Bot Builder SDK(.NET or Node.js)

 

• Bot Emulator

 

• MSアカウント

 

• Azureアカウント（配備したBotを配備）

 

• LUISアカウント

 

Development Center(Cortanaポータル:Dashboard)

机器人框架和LUIS

• 作るbotはなるべくシンプルにしておく、Channelごとに表示できるものは異なる

 

• Bot Builder SDKの3.8以降でCortanaに対応、Cortana Skill用のVSテンプレートが用意されている

IMessageActivity: “Speak”と”InputHint”プロパティ（ユーザからの入力を待つか）
Context.SayAsync
retrySpeak

LUIS

Intent:文章の意図
Entity:文章のキーワード

Cortana Skillカードの表示（HeroCardなど）

Adaptive Cardsは、現状未対応

ユーザプロファイル＆コンテキスト情報の活用
Sign-In Card: Coming soon

在AC03建筑工地上，Komatsu与Azure IoT平台携手创新。

感受

• 建設業界という自分にとって接点のない業界の話だったため、新鮮で楽しかった

 

• IoTの仕組みを積んでいない建機での作業状況も可視化している。素人考えだけどデータの重ね合わせとか相当難しそうで、すごい。

 

発表で言及されていたように、いまのSDKが頻繁にアップデートされる状況は、耐久財には導入しづらいだろうなと感じた

智慧建筑

• 耐久生産財

機械本体の商品力向上
機械の見える化: 機械とのコミュニケーション
施工の見える化：未来の建築現場の実現

ICT建機

2013年
GPS/GLONASS + 位置情報補正（Realtime Kinematic）
３次元の図面通りに自動制御（3cmの誤差）
ただし、ICT建機による施工は施工全体の一部に過ぎず、施工全体の生産性向上には大きく寄与できていない

スマートコンストラクション

熟練工スキルのパッケージ化
施工オペレーション全体の最適化を実現するサービス
顧客のオペレーションを新たなテクノロジで最適化する
二千数百の現場で導入済
建設生産プロセスの「全プロセスを３次元データでつなぐ」（＋時間軸で4D）
やったことを繋げていく（例：ドローンによる現況測量、作業者やダンプトラックの位置など）

KomConnect

KOMTRAX:モノをつなぐ
KomConnect：コトを繋ぐ->施工した土の量／形状
ICTでない建機は、ステレオカメラで測量して、３次元化してKomConnectに集約
現況測量結果と完成施工図面を比較して、切土／盛土をシミュレーション

架构

• KomConnectで目指しているもの

オープンプラットフォームとしての位置付け
お客様からの機能要求に即座に回答する
運用負荷の軽減

インフラ構成

Windows VM / SQL DB / Linux VM Cassandra / HDInsight Spark/ IoT Hub
Azure選択理由：日本国内に複数データセンター、準拠法／裁判地
2014/11 Azure採用を決定、2015/12 構築開始、2015/2 お客様向けリリース開始

全体構成

施工実績データ：Traffic Manager -> Load Balancer -> 受信サーバ -> Cassandra
センサーデータ：IoT Hub -> Blob Storage / Stream Analytics -> SQL DB

DataStax Enterpriseを採用

１秒間に数件/建機
大量建機からの同時接続、ペタバイトクラスのデータ読み書きの観点でNoSQLを採用
Premium Disk P30をフル活用するためにVMサイズを選定（IO性能）-> Standard DS4 v2
クラスタリング構成、可用性セット

施工実績データの集計処理（改善後）

HDInsight
バッチの込み具合によって簡単にスケールアウトが可能
並列処理が比較的簡単に書ける

センサーデータの保存

IoT Hubを採用 -> デバイス認証とデータ暗号化を任せている
バイナリファイルはBlob storage
センサーデータはAzure SQL DBに保存
.NET未対応デバイスは、C言語のSDKを利用

KomConnect API

API Managementで、機能レベルが異なるアプリのエンドポイントを統合
AppService/Windows VMで動くAPIを束ねる

Operation Management Suite(OMS)で、仮想マシンのログデータを一括管理
苦労した点

IoTデバイスの通信方式検討（SDKのアップデートが頻繁 -> OSが提供する枯れた仕様を利用）
デバイスの管理方式（デバイス登録の運用管理）
ストリームイベントの解析方法（解析ツールが多く、メリデメを考慮した選定が大変だった）

Azureへの今後の期待

Cassandraのマネージドサービス
海外拠点との通信を高速化するファイル転送サービス
無制限サイズのストレージサービス（Azure Data Lake Storeの国内対応）

通过案例和演示，向您展示Azure的使用模式。

• Azureアップデートに付いて行く会（Facebook Group）

 

• ISAO: SEGA x CSK -> ドリキャスのために作られた、豊田通商の子会社に

 

• terraformでAzure VMのプロビジョニング

サービスプリンシパルの発行

Azure Cloud Shell

Azure CLIを実行するための環境が立ち上がる（もともとGCPにあった機能）
裏で実際にインスタンスが動いている（Ubuntu）

低成本的DR

• Azure Backup

マネージド型のバックアップソリューション
仮想マシン全体を定期バックアップ

RA-GRSを利用した別リージョンへの複製

PremiumStorageは未対応
リージョンペアは固定されている（海外に逃がすことはできない）

Traffic Manager: DNSベースのロードバランサー（他クラウドやオンプレに流すこともできる）

Route 53で、Alias recordeでやる手もある
200以外（304）などでも機能低下状態と判定されるので、ヘルスチェックAPIを用意した方がよい

VPN Gateway

Active/Activeにしないと、１～２週間に１回落ちる
Gatewayのデプロイには30-60分かかる
VNET Peering: バックボーン上で接続（1Gbpsくらい出る）

27,000円/月くらいで構成
Managed Disks(EBS)

可用性／性能をAzure側でコントロールしてくれる
ただしLRS（ローカル冗長）しかない

利用平台即服务（PaaS）来降低成本。

• ドライブレコーダー（数十万台）

ピーク負荷に合わせて停止起動を制御するだけでも、40% OFF
PaaS活用により、67% OFF

Object Storageで直接受けることで、サーバが不要に

PaaS应用模式

• Redshiftに蓄積されたデータをSQL DWHに移設

 

• Data Factory(ETL)でデータをRedshiftから抜いてSLQ Data Warehouseに入れた

 

構築中に、SQL Server Analysis Serviceがリリースされた・・・

MW01您是否訂購了Linux + Docker？不僅僅使用Windows的App Service。

感觉

• デモの見せ方もうまく、楽しかった。特にCircleCIからAzure CLIを叩いてデプロイするデモは初めて見たので、印象に残った。

 

WebJobは当分難しいだろう（Windowsにべったり依存している）というのが残念。どう依存しているのか知りたいと思った

蔚蓝与容器

• なぜコンテナなのか？

アプリケーションのポータビリティの向上（実行環境をイメージの中に含めることができる）
起動時間の短縮（VMの起動コスト >> (超えられない壁) >> コンテナの起動コスト）
効率的なリソース配分（クラスタ内での柔軟なコンテナ配置）

Azure

Azure Service Fabric: マイクロサービス向けのオーケストレーターとランタイム -> 5台のクラスタが必要（冗長構成のため）
Azure Container Service: Docker Swarm / Kubernetes / DCOSを使ったクラスタを数クリックで作成（master 2台 + Agent 2台くらい必要）
Docker Machine: Azure用のDocker Machine Driber

課題

Azure Service Fabric: 5台のクラスタが必要（冗長構成のため）
Azure Container Service: 最低２台、production環境ではmaster 2台 + Agent 2台くらい必要
ホストVMのメンテナンス:手動でのメンテナンスが必要

AppService

完全に管理されたWindows/IIS環境（Windows Updateとランタイムの更新はAzureがやってくれる）
数秒で新しい実行環境を作成
既存のアプリケーションを簡単にデプロイ（CI/CD）

App Service on Linux

完全に管理されたDocker実行環境（自動でフェールオーバー）、高速なプロビジョニング、柔軟なスケーリング

为了熟练运用

• アプリの実行方法

ランタイムスタックを選択（どの言語を使うか）、Windows Web Appと同じ方法
アプリケーション入りのイメージを実行（一般的なdockerの使い方）

ランタイムスタック

Docker Image内に作られた実行環境、App Serviceのドキュメントルートがマウントされていてコンテナから参照し実行
Imageは公開されている

未対応の機能

Authentication / Authorization
VNET
WebJobs

向かないケース

実行に複数コンテナが必要なケースは向かない：独自のオーケストレーション、Docker Composeが未サポート
Data Volume追加は不可能

Build 2017でのupdate

Deployment slot / Slot swap -> 内部的にはproxyで見る先を切り替える（Containerの再起動などは走らない）
SSH to app container

Internal Architecture

Windows版と同じアーキテクチャ（Linuxはコンテナホストのみ）：LinuxとIISのハイブリッド構成
コンテナホストはUbuntu 16.04 LTSベース
ロードバランサー／プロキシが複数存在：ClientのIPアドレスで取れるものに注意（X-Forwarded-For）
Web App単位で別々のネットワーク：コンテナ間での内部通信は不可能

持续集成/持续交付

• デプロイ

Local Git
GitHub / BitBucketと連携（push trigger）
Docker Imageをビルドして入れ替える（CIサービスとAzure CLIの組み合わせ）
Azure Container RegistryでprivateなDocker RegistryもOK

CIサービス

Docker Hub
Visual Studio Team Service
CI SaaS(Travis CI / CircleCI)：Dockerが動けば環境は問わない

Demo

CIサービスの中でimageがちゃんと動くことをtest（例：docker runのあとにcurlを叩く）
cli用のdocker image（azuresdk/azure-cli-python）でcommandを実行してdeploy

为了在Azure上使用Kubernetes构建可扩展的云原生应用程序，遵循12因素应用。

感觉

• 「マイクロサービス」に一足飛びにいく必要はなく、どこから手を付ければよいかという話。

 

DEISは便利そう。Kubernetesをある程度理解してという前提で、どこを抽象化してくれるのか知っておきたいと思った。

微服务

• 何のためのマイクロサービス？

いち早くサービス提供、柔軟にスケール、独立したサービス作り -> MSAでなくてもできる
耐障害性を高める（回復性を高める）、変更に強いシステムを作る -> MSAが有効

2017/4 マイクロソフトがDEISを買収

Kubernetesの上に乗るWorkflowエンジン
DEISの利用で開発者はよりサービス側に集中、運用側はkubernetesを使う、という運用も考えられる
Herokuのbuild pack

12因素应用程序

• ソースコード管理

複数サービスが１リポジトリの場合：いつの時点のcommitが影響しているか（履歴管理）、どこまでrollbackすればいいか
サービスごとにリポジトリは分ける

実装

まずはビューとロジックを分ける：Front End For Back End
Rest API / Json
Stateless

並列処理・非同期ノンブロッキング

サーキット・ブレーカー：特定サービスの遅延・障害時に、サービスの切り離して、全体を維持する

共有ライブラリ

個々のサービスごとに、必要なライブラリを入れていく
サービスごとにライブラリのバージョンを変えられる
private repositoryを立てて、社内の共有ライブラリもバージョニングする

リソース設定

これまで：外部リソースの設定、接続先を変えるたびにコード編集が必要だった
これから：環境変数から設定を読み込み（OSに非依存）
いったん停止して、環境変数を書き換えて起動（１変数変更するごとに再起動がかからないように）

ビルド・リリース・実行を分ける

Docker Private Repositoryにimageをアップロードする
Dockerfileから直接DEISでbuild
rollbackも簡単

廃棄容易性

Azure Container Service VMをスケール
Kubernetesのprodレベルでのスケール
DEISにデプロイしたアプリのスケール
Kubernetes Operational View

自己完結で軽量に動くアプリに

portだけ空けておけば、Kubernetes側が管理してくれる
サービスのクラスタIPアドレス（LBのIPアドレス）

開発と本番環境の環境を統一
継続的デプロイ（Feature Flag, Blue/Green Deployなど）

togglz

Log
障害はおきる、起きても大丈夫なように作る

『Release It!』

https://aka.ms/deis-k8s-acs

转向新一代架构。从富士胶片的案例中学习云原生解决方案的愿景和设计。

我所感受的

• AzureのPaaS使いこなし事例で、とてもおもしろかった

 

• cold pool / hot poolの考え方と、サービスの方向性を理解していればどういう機能が出てくるか想像できるという話が印象に残った

 

• Microsoftが、Cloud Design Patternというのを出していることを初めて知った

 

あと30分くらい枠があって、設計や苦労した点への対策を、もっと掘り下げて聞きたかった

图像处理

• IMAGE WORKS

大規模フルPaaSシステム
レガシーWebモダナイゼーション
WFから内製アジャイルへ

IMAGE WORKS

B2Bのストレージサービス
登録データ量：約1TB/日、ユーザ数：約4万人、リクエスト数：500万回/day、ピーク時トラフィック：600Mbps
NPBの各球団の公式写真、伊勢志摩サミットの公式写真

2006/4 オンプレ版のリリース

国内データセンター、IAサーバ+Java+Struts+PosgreSQL、オフショア開発
データベース参照系の処理パフォーマンスの低下（Posgreのfunctionだらけ）
月２回メンテナンスで止めていた

2015 モダナイゼーションの検討開始

オンプレ拡張（リホスト）、APIを用意、基盤をクラウド（IaaS）に刷新、作り直し（リビルド）などを検討したが・・・
リビルド：仕様やドキュメントが残っていない、せっかく作り直すんだからと要件が膨らむ

2015冬

ゼンアーキテクツからの提案
既存システムを活かしたモダナイゼーション
フルPaaSでラッピング

2016/2 フルPaaS案を決断

開発期間６か月
内製開発チーム + ZEN
要求整理 -> PoC -> 製品化（モバイル版リリース） -> 機能拡大（PC版リリース）
PoCで２か月期間をもらって、そこで判断してもらうようにした

2016/11 リリース完了

为什么选择了”大规模×全托管平台即服务（PaaS）”？

• 一般的に知られるPaaSの特徴

posi:簡単に構築できる、開発のみに集中できる
nega:制限が多い、ロックインされる、platform側のバージョンをコントロールできない
可能性：非機能の限界を超えることができる

PaaSで超えられる非機能の壁

負荷に適応するリソース: Adaptive Scale
稼働率 100%: Zero Downtime
運用不要: NoOps

実現の鍵はリソースプール

Cold Pool: いつでもセルフプロビジョニングできるリソースプール（オンデマンドで調達できるリソース）
Hot Pool: どのノードでもいつでもデプロイできるように”暖めている”リソースプール
pre-provisioned and ready to host / pool of ready-to-go
サーバレス基盤を支える仕組み

AppService

無限のホットプールが用意されている前提で設計されている
並列20インスタンスまで「数秒で」自動スケールアウト可能

Azure Functions

App Service WebJobsの仕組みを使って動作している
Functionsが呼ばれると、リアルタイムでデプロイ～実行～アンデプロイが走る

Cosmos DB

インメモリ+SSDネイティブ実装による、低レイテンシでのGEOレプリケーションを実現したNoSQL
各リージョンのHot Poolが使える前提で実装されている
Service Fabricの基盤を使っている

图像作品的建筑设计

• オンプレミスのWorkloadをクラウドにオフロード、オンプレデータを非同期でクラウドにキャッシュ

 

• Cache Aside(Microsoft Cloud Design Pattern)

 

• 参照系の鉄板構成：WebApps + CosmosDB(Document) + Search

 

• Web Document Search Pattern

一覧/全文検索はSearch
詳細はDocument(CosmosDB):大量データに対する主キー以外での検索は苦手

Cosmos DBでスケールアウトの概念がほぼ不要になった（RU/min）

前はtelemetryが閾値を超えたらfunctionsでスケールアウトしていた

Queue-based Load Leveling(OLL)
高弾力設計

エンドポイントは軽い処理のみ
非同期分散処理が基本
Workerの粒度は小さく
処理、接続はStateless
Stateは適切なデータストアで保持

RDBのConnectionは、弾力性の最大の敵

Azure全面PaaS化的困难与挑战

• RDBとCosmos DBの同期

Dirty Readをどれくらいの期間 許容できるか

RDBとCosmos DBのマッピング

元のDBがブラックボックスではできない
例：このファイルにアクセスできるIDは誰か、このIDがアクセスできるファイルはどれか -> これによってパフォーマンスが大きく変わる

Cosumos DBとAzure Searchの同期

Searchに1,000万オブジェクト入っている
APIやIndexer（性能が出ずにtimeoutした）ではダメだった
WebJobsで両方同時に更新することで同期した

開発方法の変更（waterfall -> Agile）

20名のプロジェクトメンバーを教育して、すべてAgileにした

随着Azure的发展，IMAGE WORKS也在不断进化。

• グローバル分散・DR構成（グローバル単一エンドポイントサービス、Blobは未サポート）

 

AIの導入：富士フイルムの画像処理技術 + AzureのAI技術

窍门

• 成功の7割りは設計（アーキテクチャ設計）

利用技術を深く理解
サービスの素性・方向性を理解すれば将来どうなっていくかは分かる、それに乗っかる

未知の技術も恐れずに挑む
ロックインはもう恐れなくていい時代

“コード”と”データ”でポータビリティを確保できる

ビジネスも技術も、状況は刻々と変化する

WFからの脱却は必須
組織（人） / プロセス / テクノロジー、ミドルマネージャがキーマン（現場や技術が分かっていて、経営層とも話せる人が、覚悟を持って決断する）

SP07 落合陽一探讨AI/人工智能的潜力，西脇作为传道者提出了问题！

所感

• Holographic Near-Eye Displaysは知らなかったのでおもしろかった。

 

英語の議事録を、写真を撮って自動翻訳にかけるという話が印象に残った。Google翻訳も含め、ここから１～２年で自動翻訳が爆発的に試行され、新しい携帯文化も生まれそう。

请提供更多上下文，以便我能够更好地为您进行中文的重述。

• メディアアーティスト

新しい感覚を作る表現：発明により生み出される芸術
インスタレーション（例：プロジェクションマッピング）

Holographic Near-Eye Displays

Holographic Near-Eye Displays for Virtual and Augmented Reality
視野角80度
LCOSが200万/1枚くらいするので、500万円くらいするはず

今のMSの技術・戦略

すべてをコモディティ化していっている、コモディティ化したハードウェアの上のソフトで勝負するのは強い
OEM先が競って、いい製品を出してくれる

超AI時代の生存戦略

Deep Learningはぬか漬け、ウィスキー醸造（ほとんどコーディングしない）、従来とは手間が全然違う

Custom Vision

Demo：犬か猫か？
特徴量を覚えさせている
meta deep learningっぽい

秘書の人を雇っている

メールに触らないと決めてから、時間が１日に２時間増えた
messangerは分類できないので飽和した、slackを使っている

Microsoft Translatorによる同時通訳

パワーポイントの自動翻訳
英語の議事録を写真撮って翻訳する

2017年 最も注目するITキーワード

日本語の音声認識、家庭の中にマイク付きのデバイスが入る
YouTubeに字幕を付ける（英語の勉強にも使える）
言語系を民主化してほしい

開発者へメッセージ

不合理なことはたくさんある、それを民主化していく
後期高齢者が使えるレベルまで持っていく、自分のリソースの３割くらいはそういうことに使う