Azure PaaS のメンテナンスについて

API Management のメンテナンス?

Azure というか全体的に Intel CPU が入ってるサーバーでは年始から再起動祭りとなっていました。

マイクロソフト、CPUの脆弱性対策でAzureの計画メンテを前倒し、全リージョンの仮想マシンを今朝から強制再起動。Googleは対策済みと発表 - Publickey

ちょうど今日(1/4)19時頃 API Management を触っていたのですが、15分ほどサービスが停止していて使えないタイミングがありました。

f:id:khei-fuji:20180104193004p:plain

デプロイしていた API Management は Developer Tier だったため、SLA はありません。
料金 - API Management | Microsoft Azure

確信はありませんが、もしかすると今回のメンテナンスによる再起動だったかもしれません。
という出来事から PaaS に思いを馳せていました。

PaaS のメンテナンスについて

Azure では IaaS メンテナンスでは、その上で稼働している PaaS のサービスについてメンテナンスのアナウンスは来ません。
これは PaaS のサービスは SLA の範囲内で稼働する設計になっているためです。

今回の API Management は Developer より上の Tier では SLA が設定されています。
アーキテクチャを調べてませんが、Azure の可用性セットで組まれて冗長化されたサーバーが同時に再起動しないようにしているのでしょう。

他にも例を挙げると、Application Gateway は1インスタンスのみで動かすと、VM再起動のタイミングでサービス停止します。
高可用性を求める場合は2インスタンス以上のデプロイをするものとされています。

Application Gateway に関してよく寄せられる質問 | Microsoft Docs

では PaaS にはメンテナンスがないのかというと、そういうわけでもありません。
たとえば機能の変更によるアナウンスがあります。
App Service で PHP 5.5 をサポート終了するときはこういったアナウンスが出ています。
Retirement of the PHP 5.5 runtime from App Service

これはアプリケーションレイヤーで対応が必要になる場合があります。
(もっとも IaaS であってもサポート終了するミドルウェアには追随していくものでしょうが・・・)

まとめ

PaaS ではメンテナンスというよりは強制的なマイグレーションが発生します。
サービスも多く学習コストがかかりますが、一つ一つのコストは低めに作られているので、サービスに合わせて取り入れていきたいものです。

Azure Data Factory v2 のドキュメントレビュー

以前、初めての執筆業を 日経クラウドファースト で行った。

(日経クラウドファーストは有償の冊子で、上記リンクは購読者向けの Web ページ)

執筆中(しかも終盤)に v2 がプレビューでリリースされるという「クラウドあるある」な出来事が起き、差分についてはある程度おさえて追記した。
たまたま最近 v2 のドキュメントを読んだので、そこで気付いた v1 との違いについて書いておく。

オンプレミス用アプリケーション

統合ランタイムのインストール

Data Factory がオンプレミスのデータを参照するために、ゲートウェイとなるアプリケーションをインストールするが、この名前が変わっている。
v1 では Data Management Gateway だったが、v2 では Azure Data Factory Integration Runtime に変わっている。
最近の Microsoft は何かと名前を変えてくる。

ゲートウェイからアウトバウンドの通信が発生するという仕組み自体は特に変わってない様子。

パイプライン作成

パイプラインを作成する | Microsoft Docs

JSON の定義は特に変わってない様子。

Data Factory 自体はポータルから作成できるが、その先がポータルでは何もできない。
パイプラインの定義は PowerShell, .NET, Python, REST で行う。
2017/12/23 現時点では v2 はパブリックプレビューのため、ポータルがまだ実装できてないのだと思われる。

Azure Portal を使用して Azure データ ファクトリを作成する | Microsoft Docs

v1 のときは Azure ポータルと専用ポータルから作成する手段があったが、v2 では専用ポータルになりそうな様子。

今のところこんなところ。
使う機会があればまた何か書く。

Microsoft Azure実践ガイド (impress top gear)

Microsoft Azure実践ガイド (impress top gear)

Azure のムダ遣いを見つける

この記事は Microsoft Azure Advent Calendar 2017 の15日目の記事です。

私からは特定の Azure のサービスについてではなく、普段 Azure を使っていて困ることとその解決策について書きます。

困ること

  • 請求金額がやけに高いと思ったら、検証で作った VM が生き残っていた
  • イベントのセッション聴きながら作ったリソースが散在してる
  • ちりつもで MSDN サブスクリプションのクレジット を使い切って停止してあとX日しないと復帰しない

クレジットを超過するとこういうことになります。


豆知識ですが、クレジット超過分の制限は一時的に解除できる仕様でした。

解決策

NuGet Gallery | Microsoft.Azure.Management.Fluent 1.4.1

NuGet に Microsoft.Azure.Management.Fluent という Azure のリソース情報を取得するパッケージがあることを知ったので、これを利用して有償のサービスをムダ使いしているものをお知らせする ARMNotify をつくりました。
いや、つくってます。

github.com

みんな大好きな Deploy To Azure ボタンを用意してあるので、簡単に試せるはずです。
ARMNotify は Azure Functions で動かす想定です。
サブスクリプションにアクセスできる Service Principal を用意しておく必要があります。

ARMNotify はムダ使いしていると思われるリソースとそのリソースを操作しているアカウントの情報をまとめてくれます。
現時点のソースコードでは Deploy To Azure でデプロイすると、ARMNotify から Logic App を経由し、指定の WebHookURL までお知らせしてくれます。

f:id:khei-fuji:20171202165324p:plain

VMなどオーソドックスなサービスについては対応してますが、あまり使い馴染んでないサービスについては検証が面倒なので対応できてません。

お願い

ムダ遣いをなくすために、もっといいソリューションがありましたらぜひお聴かせください。

最後に

Azure 始めたばかりの方はこちらもよろしければどうぞ。

kheiakiyama.hateblo.jp

Azure リソース編集方法の使い分けと Azure Resource Explorer が便利だという話

AzureResourceExplorer をときどき使っていて便利だと感じているのでそれについて書く。
Azure をある程度使ってるがまださほど詳しくない、という人には参考になる部分がありそう。

Azure リソース編集方法の使い分け

Azure のリソースを編集する方法は、大きく3つだ。
スクリプト(azure-cli, PowerShell)、Azure ポータル、それから今回の AzureResourceExplorer である。
(他にも ARM TempleteREST API などもあるが割愛)

それぞれ特徴を上げる。

azure-cli, PowerShell

  • 新しいサービスリリース時の対応が早い
  • 特に azure-cli を使ったサンプルをよく見かける
  • Azure Cloud Shell の存在も相まって使い勝手がよい
  • スクリプトの流用しやすい

Azure ポータル

AzureResourceExplorer

  • 一部リソースの編集がしやすい
  • Azure の概念を理解しやすい
  • ARM Templete を書きたいときに参考になる
  • イチから作成するには不向き

このあと解説する。

便利なシーン

Network Security Group(NSG) のルールを一気に変更するときに便利

NSG のルールを編集しようとすると、azure-cli でも Azure ポータルでも一つずつしか変更ができず、毎回更新が入ってしまい、複数のルールをまとめて登録したいときに時間がかかる。
NSG のルール数は 上限が規定で200 なのでそこまで多くのルールを登録することはないかもしれないが、場合によってはあるだろう。
そういったときに JSON ベースで編集ができる Azure Resource Explorer ならば一気に複数ルールを編集し、更新することができる。
間違って設定したルールをまとめて削除するのも簡単だ。
これは非常に便利。

Azure の概念を理解しやすい

Azure ではまずリソースを購入するために必要なサブスクリプションや、AWS など他のクラウドにない概念としてリソースグループという概念がある。

f:id:khei-fuji:20171121235827p:plain

上の図のように、サブスクリプション、リソースグループ、リソースの種類に応じた namespace、リソース名、といった格好だ。
Azure のリソースはこれらの組み合せで URL がつくようになっている。 この URL を Get すればそのリソースの構成情報が JSON で取得できる、というシンプルなものだ。

これがわかると、リソースグループをまたげば同名のリソースを作れることや、サブスクリプション・リソースグループ・リソースの各階層でアクセス権限が設定できることがしっくりくる。

ARM Templete を書きたいときに参考になる

Azure には ARM Templete という、JSON で書いたファイルを使ってリソース群をまとめてデプロイする方法がある。
どんな風に書けば作れるかは azure-quick-templates を覗き見するのが早いだろう。
これを使って GitHub 上に Deploy To Azure ボタンをつけることもできる。

Deploy To Azure ボタンについてはこのあたりが詳しい。

ARM Templete を書くのは面倒なのだが、正しい状況を作ってから Azure Resource Explorer で JSON を確認しつつ編集すると捗る。

最後に

ということで AzureResourceExplorer の紹介おわり。


Azureテクノロジ入門 2018

Azureテクノロジ入門 2018

Azure Database for MySQL を使いたかったので証明書の検証エラーを回避した話

昨日しばやん先生の記事を見かけてました。 まさに使おうとしていたところで、他人ごとではありませんでした。

blog.shibayan.jp


公式情報

まずは公式情報。

現在、サービスへの mysql.exe 接続で “–ssl-mode=VERIFY_IDENTITY” オプションを使用した場合に、接続が次のエラーで失敗するという既知の問題が確認されています: ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure Please downgrade to “–ssl-mode=VERIFY_CA” or lesser SSL modes (エラー 2026 (HY000): SSL 接続エラー: SSL 証明書の検証エラー “–ssl-mode=VERIFY_CA” または以前の SSL モードにダウングレードしてください)。 “–ssl-mode=VERIFY_IDENTITY” の使用が必要な場合は、サーバー名に ping を実行して、リージョン サーバー名を解決し (westeurope1-a.control.database.windows.net など)、この問題が解決するまで、接続内でそのリージョン サーバー名を使用します。 この制限は、今後削除する予定です。 Azure Database for MySQL に安全に接続するためにアプリケーションで SSL 接続を構成する | Microsoft Docs

ということなのでそのうち修正されるとは思いますが、現時点で使いたかったため、検証エラーを回避することにしました。


PHP はそれほど詳しくないため、以下の接続ドライバしか確認していません。

回避策

mysqli

mysqli_real_connect(
    $connection,
    $host,
    $user,
    $pass,
    $name,
    3306,
    '',
    MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT
);

参考: http://blog.machek.co.uk/2016/06/php-with-mysql-and-ssl.html

PDO

まだ対応できません。 PullReq 中のようです。

add a attribute to specify CN in PDO(version 7) by ghfjdksl · Pull Request #1913 · php/php-src · GitHub

おわりに

アップデートされたらこの記事の価値はなくなるので、そのころに見かけた人はスルーしてください。

微分積分?何それ?Azure Machine Learning を使って実践から入る機械学習

はじめに

機械学習、流行ってますね。
流行りに飛びつくのはシャクだが、少しは理解を深めたい。
しかし流行りに乗じて本を買っても数学などの基礎部分でつまずいてあきらめていた。 そんな自分にも機械学習を始められた。
そう、Azure ならね。

想定する読み手

  • 機械学習に興味がある
  • 地道に数学を学ぶモチベーションが維持できない
  • 動くプロダクトを早く見たい
  • 学習コストを低く機械学習を始めたい
  • 「ゼロから作るDeep Learning」を途中で挫折した

検証をはじめる前に

前提知識

さっそく手を動かしたいところだが、ちょっとだけこれを読んでほしい

一般的に機械学習で必要な手順は以下のとおり

  1. 題材を決める
  2. 元となるデータを用意する
  3. モデルを作成する(モデル=AI と思ってくれていい)
  4. 結果を確認し、必要があればモデルを修正する
  5. 4 を繰り返す

大事なのは1と2だ。
いきなり手を動かすにはデータがないといけない。
Azure Machine Learning にもいくつかサンプルデータが用意されている

自分にはピンとくるものがなく、英語も読みたくないし、複雑なものは理解しづらいので自分で準備した。

https://raw.githubusercontent.com/kheiakiyama/HolidayEstimation/master/holiday.csv

日本の祝日かどうかを50年分出力したデータ。
人間もプログラムも読みやすいようにしたつもり。

github.com

上記プログラムで出力した。

Azureサブスクリプションを用意する

メールアドレスがあれば下のリンクから始められる。

azure.microsoft.com

正直 Azure はこのアカウント周りが非常にわかりづらく、最初のハードルになりやすい。


ログインに必要なのは Microsoft アカウントで、既存のメルアドから作成できる。
Azure のリソースを管理する単位が Azure サブスクリプションで、この単位で請求が来る。


登録にクレジットカードが必要になるが、有料の支払いをオンにしない限りは勝手に決済されることはない。
(ただしこの設定は一度オンにするともう戻せないので注意)
無料のクレジットがついているので、ちょっと試すくらいなら十分ペイできるはず。

Azure Machine Learning Studio で検証

モデル(experiment)の作成

いよいよ本題。
とはいえ説明することは特にない。

↓に大変よくできたドキュメントがある。

docs.microsoft.com

ドキュメントは日本語だが Machine Learning Studio が英語だと混乱しがちだが、ほとんどつまづくことはないはず。
ポチポチするだけで結果が出て来るのはよい。


ということでドキュメント読みながらポチポチ進めるだけなので、途中経過は飛ばす。


以下はデータをフィルタせず、アルゴリズムにランダムフォレスト(Multiclass Decision Forest) を使ってみた結果。

f:id:khei-fuji:20170304152419p:plain

そこそこの正答率が出ている。
誤答している箇所をピックアップしてみる。

  • 2030/1/13 祝日ではないが祝日扱い
  • 2004/10/11 祝日だが祝日でない扱い

成人の日や体育の日は第2月曜となっているため、傾向が見えにくいのだろう。

国民の祝日 - Wikipedia


そもそもインプットしているデータに「曜日」や「第2週」という概念がない。
このへんを与えれば改善するだろうか。

ということでデータセット自体を作り変えてみたのがこちら。

https://raw.githubusercontent.com/kheiakiyama/HolidayEstimation/master/holiday-with-dayofweek.csv

曜日と第何週かをデータに追記した。


ロジックは特に変えずに出した結果。

f:id:khei-fuji:20170304160915p:plain

かなり改善している。
今回はデータセット自体を自分で用意したのでデータセットを置き換えたが、本来は Data Transformation で加工する。
データの型の特徴を正しく認識されるように加工してあげる必要があることがわかった。

あとは春分秋分の日あたりに間違いが見られるが、アルゴリズムの取捨選択でどうにかならない気がする。


本来、自分で実装できることを機械学習に頼るべきではなく、規則性の見えないこと・表現できないことをやってくれるもの、という位置づけで考えておくのがいいのだろう。
今回は機械学習を理解するために人間が理解できるものを例にして取り上げた。

デプロイ

こうして作成したモデルは簡単に WebService にデプロイできる。

f:id:khei-fuji:20170305122555p:plain

WebAPI で公開されるので後は既存のサービスから呼び出すだけ。
Bot 連携程度なら AzureFunctions 使っておけばいい。


API のドキュメントも生成されている。
Swagger フォーマットはもうスタンダードになりつつあるるのだろうか。

f:id:khei-fuji:20170305122925p:plain

認証は下の画面にある Key を Header に含めるだけ。

f:id:khei-fuji:20170305123024p:plain

デプロイされたAPIトランザクション数とコンピューティング時間の従量課金となっている。

料金 - Machine Learning | Microsoft Azure


今回は AzureFunction で毎朝 API コールして結果を Slack に流すようにしてみた。 本題ではないので詳細は省く。

f:id:khei-fuji:20170305124202p:plain

3/5(日) は祝日ではないけど休日ですね。。
英語力が足りてない。

まとめ

研究者みたいに学問として学ぶのが苦にならない人は数学を着実に学び直すのはいいと思う。
しかし専門職でもない自分が、機械学習に大量の学習コストを割くという判断はしづらい。
Azure Machine Learning のように短時間でお手軽に触れるテクノロジーをうまく活用してやっていきたい。


機械学習そのものについては、これをとっかかりにしてもう少し複雑なことをやらせてみたい。
やりたいことはあるが、試行錯誤そのものよりもデータ集めるのが大変なのでどうするか迷う。

さわってわかる機械学習 Azure Macine Learning 実践ガイド

さわってわかる機械学習 Azure Macine Learning 実践ガイド

Azure+Cognitive Servicesで英語の発音を練習するWebサービスを作った

はじめに

今年から Azure により深く関わることになった。
手始めに Cognitive Services の SpeechAPI でちょっとしたWebサービスをつくった。

kheiakiyama.github.io


PCで動作確認済み。
iPhone のMobileSafariではHTML5の音声入力が動かないので動作しない。


www.microsoft.com

システム構成

趣味のサービスなのでコストがかからないように、いわゆるサーバーレスな構成。

  • フロントは GitHub Pages で静的サイトホスティング
  • バックエンドは Azure Function
  • 英語の文章はスクレイピングして結果を TableStorage に保存
    同時に QueueStorage にも登録
  • Azure Function で Queue をトリガーに Cognitive Services の Text to Speech で音声化し、BlobStorage に保存

Azure について

Cognitive Services

サイトで試しに聴いてみればわかるとおり、Text to Speech で出力した音声は自然に聴き取れる。


一方、Speech Recognition は全然自分の英語を認識してくれないので評価しづらい。
英語が堪能な人に試してもらうと認識されるので、練習あるのみ。


Speech API が $4 per 1000 calls なので、API を軸にしたサービスでペイするのはなかなか厳しそう。
あくまでも既存のサービスの満足度を高めるために利用するのがベターそう。

Azure Function

全体的にすごくよい。
Function ごとにディレクトリ切って実装するだけなので簡単。


大半が WebApps と同じ感覚で使えるので学習コストが低くて済む。
単純に REST API を簡単に作れるだけではなく、Storage をはじめとした Azure のサービスとの連携が気持ちよくできる。
たとえば Queue と Table を入力に Blob へ出力するための設定は以下のような感じ。

{
  "bindings": [
    {
      "name" : "queueItem",
      "queueName" : "speech",
      "connection" : "{queue_accesskey}",
      "type" : "queueTrigger",
      "direction" : "in"
    },
    {
      "name": "entity",
      "type": "table",
      "direction": "in",
      "tableName": "sentences",
      "partitionKey": "speech-eng",
      "rowKey": "{queueTrigger}",
      "connection": "{table_accesskey}"
    },
    {
      "name": "outBlob",
      "type": "blob",
      "direction": "out",
      "path": "speechs/{queueTrigger}.wav",
      "connection": "{blob_accesskey}"
    }
  ],
  "disabled": false
}

name に指定した名前が実装する function のパラメータ名になる。

public static async Task Run(
    string queueItem, //in queue の binding
    TableEntity entity, //in table の binding
    Stream outBlob, //out blob の binding
    TraceWriter log)
{
    //do something...
}

公式ドキュメントでは functions-triggers-bindings のあたりを読むといろんなパターンが載っている。

おそらく厳しいが、DataFactory のように今後他のパブリッククラウドとも連携されたらいいなと夢が広がる。


悪い部分をあげるとささいなレベル。
ポータル上のエディタが不便(ローカルで書けばいい)とか、下に書いたハマりポイントがあった程度。

AzureFunctions で開発するときにハマったこと - Qiita

あとがき

サービス自体について思ってること

  • もうちょっと練習に適した文章使いたい。けど本などの教材からパクるわけにもいかないので悩む。
    サイトに載せていいようなまとまった資料あったらぜひ教えてください
  • 日本語訳くらいは表示しておきたい。
  • 正答の精度もうちょっとゆるくしたい。もしくは精度自体表示する。
  • 正答率表示は回答者いないとワークしないから後で実装すべきだった。
  • というかスクレイピングによって出題が増え続けるのはよくない気がする

と書いてみたものの、こうしてブログ書くとあまりいじらなくなるのでやる保証はない。

英会話・ぜったい・音読 【続・入門編】 (CDブック)

英会話・ぜったい・音読 【続・入門編】 (CDブック)