[Azure]Cosmos DBのハンズオンに参加しました

Azure

Azure Antennaさん主催のハンズオン「Cosmos DB と App Service によるグローバル分散アプリ構築」に参加してきました。

Cosmos DB と App Service によるグローバル分散アプリ構築 (2018/05/23 13:00〜)
※本イベントでは、ご参加者自身のブログにて、Azure Antenna で受講いただいた体験をご紹介いただける方に、優先的に参加いただけるよう、抽選前に指名させていただきます。対象者多数の場合は、申込み先着順に指名させていただきます。 ※このハンズオンは2017年12月にゼンアーキテクツ三宅氏によって実施されたスペシ...
azure.connpass.com
Cosmos DBはAzureの機能の中でも比較的新しく、あまり内容を知らなかったため、その内容と、実際にアプリケーションから接続しての挙動も確認できるということで参加してきました。
会場はヒカリエの８階、「8/」にある会議スペースで、通路から丸見えの場所です。ポップな雰囲気の部屋で、Surface Hubもあったりして設備も充実していました。
8/
渋谷駅直結の超立地に、オフィスのような、カフェのような、ギャラリーのような、ショップのようなスペースが誕生。渋谷らしい交流により新しいクリエイションの可能性を探ります。東急文化会館のDNAを持ったクリエイティブスペース。名前は「8/」。ヒカリエ8階にそれは活動をはじめます。
www.hikarie8.com
さてCosmos DBとは何かというと、「グローバル分散」の「マルチモデルデータベース」と言われています。（従来のSQL Databasesとは全く別のサービスです）
グローバル分散、つまりAzureの各地のリージョンに簡単にレプリケーションをすることができるため、地域的に近いリージョンに驚くほど簡単にアプリを構築することができます。また、どこかのリージョンが落ちた場合でもフェイルオーバーが自動的に行われるため、災害にも非常に強いモデルになっています。
また、マルチモデルデータベースということで、従来のDocumentDB（JSONを格納するNoSQLデータベース）の他にも、MongoDB、GraphDBなど、必要に応じたDBエンジンを使用することができます。
ハンズオンでは、
・Cosmos DBの作成
・ASP.NET MVCアプリケーションの構築
・App Serviceの作成
・Traffic Managerの作成
・フェイルオーバーのテスト
と、Cosmos DBの特性を引き出すシナリオで進められました。

CosmosDBの作成

まずはAzure Portalにログインして、Cosmos DBを新規作成しました。モデルはSQL（Document DBのことを指す）を選択します。
Document DBはidをキーにして任意の形式のJSONを格納することができます。RDBMSと異なり、データ毎にスキーマが異なっていても格納できるので、非常に柔軟性が高くなっています。
Cosmos DBは、データ容量とRU（スループット）によって課金体系が変わってきます。専用の見積もりツールがあるのでそれを使うと見積しやすいのですが、書き込みや読み込みのトラフィックがどのくらいあるかはサービス開始前にはなかなか予測できないので、運用しながら見直すことも必要かと思います。


DBを作成すると、Azure Portalの中でデータの検索・閲覧・登録・変更ができるようになります。別途ツールを使わなくてもいいのは便利ですね！


また、上記のことを行える専用ツールも用意されています。Visual StudioのWindows版からも同様のことはできるらしいのですが、MacやLinuxを使っている場合はツールを使うのが便利とのことでした。（ASP.NET Coreはマルチプラットフォーム）


そして、作成したCosmos DBを各リージョンにレプリケーションします。Azure PortalからGUIでポチポチするだけで簡単に世界展開できてしまいます。


なお、Cosmos DBへの書き込みは１つのリージョンに対してしか行えません。レプリケーション先からの読み込みはアプリから一番近い場所（App Serviceならば同じリージョンに展開するのが普通）に対して行うと最大のパフォーマンスを発揮します。

ASP.NET MVCアプリケーションの構築

Cosmos DBにアクセスするASP.NET MVCアプリケーションを構築します。ハンズオンでは１から構築するのではなく、予め出来上がったサンプルアプリケーションに対して、接続文字列を変更する、という内容でした。
接続文字列はappsettings.jsonに書き込むのですが、ローカルでテストする場合はappsettings.Development.jsonに書き込まないと反映されないので注意です。


この内容はAzure App Serviceの「アプリケーション設定」にも書き込む必要があります。
使用したサンプルアプリは、公式サイトのクイックスタートと（恐らく）同じ内容です。
https://docs.microsoft.com/ja-jp/azure/cosmos-db/create-sql-api-dotnet

App Serviceの作成

Azure Portalにて、上記ASP.NETアプリのホスティング先となるApp Serviceを作成しました。リージョンはCosmos DBの書き込みリージョンと、レプリケーション先となるリージョンの２つにしました。
ここで、後程作成するTraffic Managerを使用してディザスタリカバリー対応を行う場合には、S1以上のプランが必要になります。有料のプランとなり、かつ、App Serviceは「停止」を行っても課金が行われるので、検証後は速やかに削除する必要があります。


１つ目のApp ServiceにVisual Studioからデプロイを行った後、Index.cshtmlをちょっとだけ変更して別のアプリだとわかるようにして、２つ目のApp Serviceにデプロイを行います。
（２つのApp Serviceを同期したりする機能は無いので、DevOps的に作りこむ必要があるとのことでした）
そして、「アプリケーション設定」から、DB接続先の「Region」のみを変更して、それぞれのApp Serviceがローカルのリージョンを参照するようにします。
従来のRDBMSを使用するアプリでは、レプリケーションを行った場合は「書き込みサーバ」「読み込みサーバ」のそれぞれの接続文字列をアプリケーションで設定するのが一般的ですが、Cosmos DBを使用する場合は、そのような区別は行いません。（詳細はきちんと見ていませんが、アプリ内に解決する仕組みが入っているようです）
これで、同じ内容のWebアプリが２つできました。

Traffic Managerの作成

上記の２つのWebアプリに対して、グローバルな規模で負荷分散を行うのがTraffic Managerとなります。Azure PortalにてTraffic Managerを作成し、配下に２つのApp Serviceを設定します。負荷分散の方法にもいくつかあり、手動で優先順位を設定することもできますし、地理的に近い位置に誘導したりと設定可能です。Traffic Managerに対してURLが発行されるので、そこに対してアクセスを行えば、内部的に配下のApp Serviceのどれかに振り分けが行われます。

フェイルオーバーのテスト

この状態で、App Serviceの１つを落としてみると、若干切り替えに時間がかかるものの、生きているApp Serviceの方にアクセスが行くのが確認できました。
また、Cosmos DB自体の手動フェイルオーバーも試してみました、


だいぶ昔に関わったシステムでは、SQLServer Enterprise Editionを使ってFabricでクラスタを組んでフェイルオーバーしたりしてましたが、クリック１発で世界規模でフェイルオーバーができちゃうのはほんと隔世の感がありますし、もうオンプレミスは選択肢から消えつつあるんじゃないかという感想です・・

終わりに

３時間程度の短いハンズオンでしたが、Cosmos DBの特性を引き出しているとても良い内容でした。場所もヒカリエとアクセスしやすく、人数も少ないので質問もでき、非常に有意義な内容でした。次回はAzure Functionsの内容で行われるということなのでまた参加したいと思います。

スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

torikasyu

スポンサーリンク