【Azure Antenna】分散アプリの構築 Hands-on!【Cosmos DB】

【Azure Antenna】分散アプリの構築 Hands-on!【Cosmos DB】

お疲れ様です。最近色々やっていて時間がとれず、今日は昼休みにちょっとだけ更新しています。

先日プレオープンの記事を書いた Azure Antenna です。また行ってきました!
今回参加したイベントは「話題の Cosmos DB と App Service によるグローバル分散アプリ構築のコツ」

Cosmos DB と App Service 共に興味ありです!

時間は3時間と短めですが十分体験できました。なによりも早くて早くてびっくりです。

Cosmos DB

最近なにかと Microsoft が推してくる分散 DB の Cosmos DB です。

まずインパクトという意味で SLA 99.999% が保証されているのがすごいね!
あと、分散については意味があるかは別にして Azure のリージョンすべてに DB を配置できるみたい。

Cosmos DB の特徴である レイテンシは、読み取りが 10 ms(99パーセンタイル) 書き込みが 15 ms という数字。
RDB と比較するのは違いますが、すごく早いことが分かります。

全世界に分散することができて可用性が高く、低レイテンシな Cosmos DB ですが使いどころはどこかということ。

任意の1カ所のリージョンの Cosmos DB に書き込みを行い、読み取りは全世界からするわけで、データの整合性はどうなるのかというと、あまり強くない。
トランザクションがあるような処理には向かないのが分散 DB 当たり前の事だけど。
しかし、それに対してなにもソリューションがない訳ではなく、一貫性レベルを設定することでデータの整合性が担保されるようになるとのこと。

整合性レベル 保証内容
Strong 線形化可能性。 読み取りでは、項目の最新バージョンが返ることが保証されています
Bounded Staleness 一貫性のあるプレフィックス。 読み取りが、書き込みからプレフィックス k または間隔 t ごとに実行される
Session 一貫性のあるプレフィックス。 単調読み取り、単調書き込み、書き込み後の読み取り、読み取り後の書き込み
Consistent Prefix 返される更新が、それ以外の全更新の一部のプレフィックスとなる (ギャップなし)
Eventual 読み取りは順不同

Strong 一貫性 に設定をすれば常に最新のデータを取得することができますが、そうすると当然オーバーヘッドが発生する。
それって多分 Cosmos DB の良さを潰していてこれを使う意味が無い。

このようなトランザクションが必要なデータに関しては RDB を使うのが正解なのだそう。
データ・処理のの特性をみて、Cosmos DB が適しているのか RDB が適しているのかを考え ハイブリッドで利用するのが正解みたい。

具体的には、EC サイトの商品マスタなんかは Cosmos DB が適しているんではないかなと思う。
Cosmos DB はデフォルトですべての項目にインデックスが作成されるので、検索が非常に早い。
何度も検索され、早いレスポンス、アクセスの量など Cosmos DB の恩恵を受けることができる。
更新も少なくトランザクションも必要ないので Cosmos DB のためのデータなのではないかと思う。

逆に EC サイトであると買い物かごとか、ログイン情報の管理なんかは、トランザクションの制御が必要だし、一貫性が担保されていないと困る。
そういった部分は RDB で構築していく必要があるんだろうね。

Azure Portal で Cosmos DB を立ち上げるのは、本当簡単であっという間にできる。
さらに面白いのは、リージョンに分散させるために必要な事は数回のクリックのみであるということ。

世界地図から展開するリージョンを選択して「新しいリージョンを追加する」というボタンを押下するだけ。
これで数分以内でリージョンを立ち上がるからすごい。

書き込みリージョンの変更、手動フェールオーバーも数クリックで完了。
とても早いのでびっくりした。

App Service

今回参加したハンズオンのタイトルは分散アプリ構築だったので、Azure の Paas サービスである App Service を利用して Web アプリを複数のリージョンにデプロイ、動きを見ました。

開発は Visual Sturio で Mac で開発するため言語は .NET Core を利用。
.NET Core はクロスプラットフォームなので Linux でも実行可能なんだそう。

App Service は、作成時に Linux と Windows を選択することができますが、今回は Windows Server で。

少し面倒に感じたのは、分散 DB の設定くらいかな。まぁ当たり前のの設定なんだけど。
今回は、東日本・西日本のリージョンに Cosmos DB と App Service を立ち上げて、App Service は、一番近くの Cosmos DB を参照するように。つまり同一リージョンの Cosmos DB を参照する。

そういった事を自動的にやってくれる訳ではなくて、そこに関してはアプリ側に設定が必要。
具体的には Connection を作成するときに、リージョンを指定することができるんだけど、App Service ごとにアプリケーション設定にリージョン情報を持たせて、それをアプリで読み込んで実行する流れ。

App Service を最初に作成するときだけにリージョン文字列を指定してあげる。それだけは必要だとのこと。

あとは Traffic Manager プロファイル を利用することで、ユーザーに一番違いリージョンの App Service に振り分けてくれる。

とっても簡単に強いシステムを構築することができた。
アプリと DB だけの本当シンプルなシステムだったけど、これがすべて基本になるだろうなぁと思う。

所感

いままで仕事では RDB それも Oracle のみを使ってきて分散DB なんて知らない。
Web アプリも Java 万歳! Node? Rails? そんなの知らないって僕だけど、使ってみてすごい面白かった。
自分で時間を見つけて簡単なアプリを作ってみようかなと思う。

雑談のなかで Struts が App Service が動いたとか聞いてなんか笑ってしまいました。
最新のプラットフォームの上でレガシーなフレームワークが動く。
しかも自動でスケーリングなんてされちゃったりして・・・・・・
怖い怖い。

今回のハンズオンの資料は、Conpass に公開されていたので、是非見てみてください。