2016 Microsoft MVP Award を受賞しました

2016年7月期、Microsoft Azure のカテゴリで、Microsoft MVP Award を受賞しました。

今後も、最近 Service Fabric に偏り気味ですが、Cloud Scale なサービス構築をテーマに情報発信をして行きたいと思います。

これからも、よろしくお願いいたします。

Reliable Collection の Lock の挙動

先日、5/18 に、第1回Jazug Tokyo Nightで、Azure Fabric Service の Reliable Collection 話をしました。Global Azure Boot Camp 2016 in Japanでも話をしたのですが、1時間ぐらいだと概要も話し切れない感じでなかなか厳しい。4回ぐらいに分けても少し深いところ(そんなにDeepじゃないですが)をしたいなぁと思っていたところ、ちょうど良い機会が出来たので、早速時間を貰うことにしました。

今回は、その時の補足です。まずは、その時の資料です。Lock compatibility matrixの部分を更新しました

Azure Fabric Service Reliable Collection

勉強会の時に、下記の Lock compatibility matrix の赤枠の部分だけ、SQL Serverと違うという話をしました。「もしかしたら、ドキュメントが間違っているのかも」というようなことをその場では言いましたが、どきょメントが間違っているわけではなく、そこはSQL Serverと動きが違うとのことでした。そのあたりの話を説明します。(公式ドキュメントでは無いので、参考程度で)

Lock compatibility matrix

Lock compatibility matrix

Reliable Collectionは、書込に最適化されていおり、matxi の赤枠の部分が、G(U)/R(S)時の動きが SQL Server とは異なっています。また、Reliable Collection では、update lockの期間は短くほとんどの場合、exclusive に昇格して終わることを前提としています。設計思想が違うという話のようです。

下図のような場合で動作を説明します。

tnx and lock
  • 上が、Reliable Collection,下がSQL Server
  • 横軸が時間で、それぞれ、2つのtransactionがある
  • 黄色線が、tnxid 2 が、shard lock を要求したタイミング

TxnId1が、update lockを掛けている時、TxnId2がShard Lockを要求した場合(垂直黄線)、Reliable CollectionではUpdate Lock が、Exclusive Lock になって更新が終わりlockが開放されるまでshard lockは待機します。それに対して、SQL Serverでは、即時にshard lockは成功します。全てのshard lockが開放されてから、exclusive lock ->更新という処理に流れになります。この違いはなかなか面白いですね。

最後に

Reliable Collection は結構手堅くしっかり作っている感じを受けます。この手のものがあると、Data Localityを健全に保てるのでレイテンシー上は非常に有利になります、いいですね。

「上記2つに更に .NET の ReaderWriterLockSlim と、Jeffrey Richter の OneManyLock を入れて、永続化の有無がどう影響するのか考察したら面白いのかな?」と一瞬思ったのですが、今回はこの辺で。勉強会の前に明確にしておけば良かったのですが、ちょっと見逃してました。でも、SQL Serverと違って、lock やwait の状態が見えないのがちょっと不便ですね。これだと、ラッシュテストしないとデッドロックとかわからないです。

BUILD/2016 Azure Cool Storage

BUILD 2016B816 Learn How to Store and Serve PBs of Object Data with Azure Block BlobsCool Storageという、とても興味深い新機能が発表されていました。Build 2016: Azure Storage announcementsに入ってなくて、見落としそうになります…

Cool Storage

Cool Storageは、アクセス頻度の低いデータを安価に保存するための新機能で、Block Blob でサポートされます。

これで、Block Blob は、2の tier に別れます。

  1. Hot - 通常利用のデータ向け (従来のBlob)
  2. Cool - あまりアクセスしないデータ向け (あたらしいやつ)

概要

  • APIは、100% 互換で、同様のスループットとレイテンシーを実現(Coolでも性能が同じなのは設計しやすくなるので有り難いことです)
  • LRS, GRS, RA-GRSの信頼性オプションを提供( 同じですね)
  • 可用性は、Coolが 99% で、Hot が 99.9%(ちょっと、Coolが低くなります)

お値段関係

Hotは、頻繁に使った場合に費用が抑えられ、Coolは、容量が大きい場合に安くなるという価格体系で構成されるようです。話の中ではちょっとはっきりしませんでしたが、トランザクションコストやデータ転送コストで差を付けるという感じなのかもしれません。

HotからCoolへの切替もできるようなので、履歴系のデータを保存するにはとても便利な気がします。next few weeks で、public preview に入るそうです。楽しみですね。

この話は、動画では、33分、パワポの資料では、30p 当たりで話が出来てますので、興味のある方はぜひ、chanel 9 をご覧ください。[1]

最後に

どうも、AWS の S3 Standard-IA とか、Google Nearline あたりと同じような領域をカバーするサービスのようです。S3 Standard-IA は、Google Nearline とは違って、レスポンスタイムが通常のBlob並ってところは良い感じです。価格の詳しい条件がわからないので、現時点でS3との比較は難しいですが、Cool Storageは、Hot/Coolの切替がアカウント単離っぽいので、実データのコピーは必要無さそうで、そのあたりで差がでてくるのでは無いかと言う気がします。

今回の、BUILDでは、 Server Siide Encription[2]も発表されて、Storage Team に活気を感じました。これからが、楽しみです。

現在 のGuest OS Version の確認方法

.NET Framework 4.5, 4.5.1 のサポート終了に少し遅れましたが、Azure の Cloud Service でも、Gest OS 4.28 から .NET 4.5.2 がサポートされるようになりました。Azure Guest OS releases and SDK compatibility matrix

現在絶賛展開中ですが、手元のCloud Serviceには、すでに来ていました。

Visual Studio での確認

現在の Guest OSのバージョンは、下記のように、Visual Studio で、Roleのプロパティを開くと確認することができます。

vsimage

Azure PowerShell での確認

Azure PowerShell は、1.1.0 では確認できなかったのですが、今回のように、GUEST OSのバージョンが重要な場合に確認出来ないのは不便なので、OSVersionが帰ってくるようなパッチを作って PR を出してみたら、さくっと翌日にはマージされ次のリリースで無事に現在のバージョンがわかるようになりました。(もともと、REST APIには存在するし簡単な修正だったので、なにかの拍子に漏れてしまっただけだと思います)

Fix to missing OS Version in Get-AzureRole #1638

../../../_images/git001.png

Azure PowerShell Team オープンですね!素晴らしい

こんな感じで確認することができます。

$ Get-AzureRole -ServiceName kinmugics10 -Slot Staging

RoleName             : WorkerRole1
InstanceCount        : 1
DeploymentID         : c49d5437f1a84345b9739a79ff333056
OSVersion            : WA-GUEST-OS-4.28_201601-01
ServiceName          : kinmugics10
OperationDescription : Get-AzureRole
OperationId          : 0ffbd548-3b37-6c15-afa4-e091056e0849
OperationStatus      : Succeeded

現状だと、「新ポータル、旧ポータル」では、適応されているcscfgの内容だけで、自動更新に設定されている場合にどのGuest OS が使われているかは確認できません。

おまけ、Get-AzureDeploymant

似たような情報を返してくるコマンドに、Get-AzureDeployment というのがあり、OSVersionが帰ってきます。「*」 が帰ってきて、すぐに実行中のGest OSがかえってくるわけではないことがわかりますが、ソースを確認してみます。コード的には、このあたりでOSVersion のプロパティを設定しています。つまり、csdefで設定されているosVersionが入り、自動更新を設定した場合、「*」となって現在のOS バージョンは分かりません。

最初これで行けるかと思ったんですがね。