全体の感想

昨年de:codeに参加した時も思ったけれど、HoloLensとか自動翻訳といった、消費者目線で体験が変わるものの話を聞くのはおもしろい。de:codeはセッションのテーマの幅が広いので、普段あまり接点がない分野の話を聞けるのが楽しい。
この半年くらいAzureを使った開発をやった身から見ると、Azure関連のセッションは、まだ各リソースの概要説明的なものが多いように感じた。deep dive的なセッションや、AzureのPaaSを活用した開発事例のセッションが増えるといいなと思った。（富士フイルムさんの事例セッションがとてもおもしろかった）
セッション間の移動など会場が昨年より快適だった気がする！（何がどう変わったのか具体的には分からなかったので、思い込みかもしれない）

2017/05/23

DO08 『変わらない開発現場』を変えていくために〜エンプラ系レガシー SIer のための 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の予備知識や、チーム内での標準化が必要になったりする

前提条件の違い

DevOps自体を導入する必要はない
- アメリカはオフショアが急速に進んだため、内製で残っているのは高付加価値な開発（SoE型）
- 日本はオフショアが進まなかったため、すべてがぐちゃっと残っている
日本にとって重要なのは、「実践的活用による現場改善」
- 導入時に魔改造する必要など全くない
- 自分の現場で使えるものだけをピックアップして活用すればよい
「一歩ずつ」理想形に近づける努力を繰り返す
- スクラップ＆ビルドでは現場は改善しない
- 「理想形」と「現実的な制約」を同時に考え、一歩ずつ理想形に近づけていく（ロードマップ的に考える）
DevOpsというキーワードを使わない、思考停止に陥らない建設的な提案と議論が必要

MR01 本気で始める HoloLens - プラン/設計/開発の勘どころ -

所感

HoloLensのことをほとんど知らなかったので、特徴や事例から実装イメージまで概観が理解できてよかった
AR/MRの違いの定義がなるほどと思った（部屋の壁に穴が開いてそこからモンスターが出てくるとか）

Mixed Reality

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を使用）

TL08 50 分で Bot 開発者になれる! 〜実践的ノウハウと、Azure や Office 365 を組み合わせたアーキテクチャの伝授〜

所感

bot frameworkを利用したbot開発の流れが一通り分かる
各チャットサービスで、どんなcardsがあるのか知りたいと思った
payments対応が発表されたらしく展開が楽しみ

bot

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 Skills

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アカウントを作成

必要なツール

VS2017 / VSC
Bot Builder SDK(.NET or Node.js)
Bot Emulator
MSアカウント
Azureアカウント（配備したBotを配備）
LUISアカウント
Development Center(Cortanaポータル:Dashboard)

Bot Framework & 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 建設現場にイノベーションを起こすコマツ x 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の国内対応）

LS22 事例とデモでお送りする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にべったり依存している）というのが残念。どう依存しているのか知りたいと思った

Azure and Container

なぜコンテナなのか？
- アプリケーションのポータビリティの向上（実行環境をイメージの中に含めることができる）
- 起動時間の短縮（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単位で別々のネットワーク：コンテナ間での内部通信は不可能

CI/CD

デプロイ
- 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

AC06 クラウドネィティブなスケーラブルアプリ開発のために〜12 Factor App on Kubernetes on Azure

所感

「マイクロサービス」に一足飛びにいく必要はなく、どこから手を付ければよいかという話。
DEISは便利そう。Kubernetesをある程度理解してという前提で、どこを抽象化してくれるのか知っておきたいと思った。

マイクロサービス

何のためのマイクロサービス？
- いち早くサービス提供、柔軟にスケール、独立したサービス作り -> MSAでなくてもできる
- 耐障害性を高める（回復性を高める）、変更に強いシステムを作る -> MSAが有効
2017/4 マイクロソフトがDEISを買収
- Kubernetesの上に乗るWorkflowエンジン
- DEISの利用で開発者はよりサービス側に集中、運用側はkubernetesを使う、という運用も考えられる
- Herokuのbuild pack

12 Factor App

ソースコード管理
- 複数サービスが１リポジトリの場合：いつの時点の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

AC08 新世代のアーキテクチャに移行せよ。富士フイルムの事例に学ぶ、クラウドネイティブソリューションのビジョンと設計

所感

AzureのPaaS使いこなし事例で、とてもおもしろかった
cold pool / hot poolの考え方と、サービスの方向性を理解していればどういう機能が出てくるか想像できるという話が印象に残った
Microsoftが、Cloud Design Patternというのを出していることを初めて知った
あと30分くらい枠があって、設計や苦労した点への対策を、もっと掘り下げて聞きたかった

IMAGE WORKS

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の基盤を使っている

IMAGE WORKS アーキテクチャ設計

オンプレミスの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に字幕を付ける（英語の勉強にも使える）
- 言語系を民主化してほしい
開発者へメッセージ
- 不合理なことはたくさんある、それを民主化していく
- 後期高齢者が使えるレベルまで持っていく、自分のリソースの３割くらいはそういうことに使う