本ストレージサービスは極めて堅牢なデータ保管の仕組みを持っている。各ストレージアカウントでのデータ冗長化の方式として「ローカル冗長」「地理冗長」「読み取りアクセス地理冗長」の3種類から選択することができる。

　ローカル冗長では、データを同じデータセンター内の異なる3つのストレージへ複製して格納する。地理冗長では、さらに異なるデータセンター（セカンダリリージョン）の3つのストレージへ複製して格納する。

　つまり、データは最低でも3重化されて格納されており、また、マルチリージョンでデータを6重化して格納させることもできる。ストレージアカウントを複数利用することも可能なので、よほどの用途でなければ無尽蔵にデータを格納できるといえるだろう。もちろん、情報の論理的な整合性はユーザーが担保する必要があるとはいえ、障害によって消失する可能性を極限まで軽減することができると考えて差し支えない。

図2　データ格納の仕組み

縁の下の力持ち

　本ストレージサービスは、単純にファイルサーバとして使うようなストレージサービスとは異なる。BLOBストレージ、Tableストレージ、Queueストレージを適切に使いこなすことで、クラウドシステムの可用性およびスケーラビリティを劇的に向上させることができる。「Microsoft Azure クラウドサービス」や「Microsoft Azure Webサイト」などのように注目されやすいサービスではないが、それらのサービスをサポートする、まさに縁の下の力持ちといえる。一方で、使い方を誤ると性能ダウンやコスト増加を引き起こす可能性があるので注意が必要だ。

　以降、各ストレージの概要および活用方法について説明する。

BLOBストレージ

概要

　BLOBストレージはオブジェクトストレージおよびブロックストレージであり、大量の非構造テキストや動画、画像などのバイナリデータ、VHD（仮想ディスク）ファイルを格納するために使用する。Amazon Web Services（AWS）では「Amazon S3（Simple Storage Service）」と「Amazon EBS（Elastic Block Store）」に相当するサービスといえる。

　BLOBストレージでは、1つのコンテナ（フォルダに相当）に複数のBLOB（ファイルに相当）を配置できる。基本的に、コンテナ内のBLOBへアクセスするためには、アクセスキーによる認証が必要である。しかし、コンテナを「パブリックコンテナ」に設定することで、認証不要で全世界のユーザーがアクセスできるようになり、コンテンツ配信サーバとして用いることができる。また、共有アクセス署名（Shared Access Signature）を用いることで、非常に限定した範囲にのみ配信を行うことも可能である。

　BLOBの利用方法は多岐にわたる。基本的には、Microsoft Azure クラウドサービス／仮想マシンのVHDファイルやログデータの格納に利用される。それ以外には、動画コンテンツをパブリックコンテナへ配置することで、ユーザーへ動画配信をすることができる。また、「Microsoft Azure CDN」と連携することで、全世界へ高速に分散配信をすることもできる。そして、ビックデータ分析サービス「Microsoft Azure HDInsight」と連携することで、BLOB内の大量データに対して高速なデータ分析を行うことも可能である。

図3　多岐にわたるBLOBストレージの利用方法

活用方法

　BLOBストレージの活用方法の1つとして、動画や画像などデータサイズが大きいコンテンツの配信が挙げられる。一般的に動画はデータサイズが大きく、Webサーバから配信すると、Webサーバの帯域圧迫や、CPU負荷を引き起こす。これが原因で、大量にユーザーがアクセスしてきた際に配信遅延や、最悪の場合、配信不能を引き起こす可能性がある。また、画像もデータサイズが小さいとはいえず、配信する数が多くなると通信帯域圧迫の原因となる。これらの問題は、Microsoft Azure Webサイトでは自動スケール機能で対応することができるが、その場合、多くのサーバが必要となりコストが増大してしまう。

　そこで、動画および画像ファイルの配信をBLOBストレージから行わせるようにする。ストレージアカウントは、ローカル冗長ストレージで送信15Gbps、地理冗長ストレージで送信10Gbpsの性能を持つため、大量のユーザーがアクセスしてきても高速にコンテンツを配信することができる。もしWebサイトの公開範囲が広く、世界中からアクセスされる場合にはMicrosoft Azure CDNを用いると、世界中に配置されたエッジサーバからコンテンツを分散配信することができる。これらにより、Webサイトの帯域圧迫やCPU負荷を軽減でき、大量のユーザーに対し、非常に少ないWebサーバで対応できるようになる。

図4　BLOBストレージの活用方法

Tableストレージ

概要

　Tableストレージは分散KVSであり、構造的なデータを格納することができる。AWSでは「Amazon DynamoDB」に相当するサービスといえる。KVSとは「キー」と「値」のペアで保存する方式のストレージである。キーと値のペアだけの単純な構造のため、分散配置が容易である。そのためシャーディングやパーティション分割をすることなく格納するデータ量を容易にスケールアウトできる。

　Tableストレージでのキーと値のペアは「エンティティ」と呼ぶ。エンティティのキーは「PartitionKey」と「RowKey」の2つで構成される。PartitionKeyでは、エンティティをどのパーティションに所属させるかを指定する。同じPartitionKeyのエンティティは一括して取得することができるため、同時に取得することが多いエンティティは同じパーティションに所属させるべきである。ただし、1つのパーティションに多くのエンティティを所属させると検索性能が落ちるため、適切にパーティション設定を行う必要がある。RowKeyには、同じパーティション内でエンティティを一意に特定するための文字列を指定する。エンティティの値には、複数のプロパティを設定することができる。プロパティのデータ型としては、文字列、数値、小数、論理型、日付などが選択できる。

　Tableストレージでは、正規化したテーブル間のリレーション設定やトランザクション処理を行うことができない。もしこれらを要するデータ管理を行うのであれば、リレーショナルデータベースサービスである「Microsoft Azure SQLデータベース」を用いるべきである。

図5　Tableストレージの「キー」と「値」

活用方法

　Tableストレージの活用方法の1つとして、大量のデバイスから情報を収集する、いわゆるIoT（モノのインターネット）ソリューションにおける、収集情報の格納先としての利用が挙げられる。一般的に各デバイスから送られてくる情報は、BLOBに書き込むのに適するほど大きくない。しかし累積して莫大なデータ量となるため、リレーショナルデータベースだといずれ格納しきれなくなる。

　そこでTableストレージの利用が視野に入る。Tableストレージは小規模で大量なデータを格納するのに適しており、最大500Tバイトのほぼ無尽蔵なデータ容量を持つ。また、パーティションキーを利用したデータの配置設計を適切に行うことで、データ量が多くなっても高速な検索性能を保つことができる。もし収集した情報を分析するのであれば、Tableストレージの全エンティティをマージしてBLOBストレージへ格納し、HDInsightでビックデータ分析を行うこともできる。

図6　Tableストレージの活用事例

Queueストレージ

概要

　Queueストレージはメッセージキューストレージであり、主にアプリケーション間のメッセージングに使用される。AWSでは「Amazon SQS（Simple Queue Service）」に相当するサービスといえる。Queueストレージに対して、テキストまたは少量のバイナリデータを投入できる（エンキュー）。また、投入したものを取り出すことができる（デキュー）。取り出し方式は、先入れ先出し（FIFO：First In First Out）方式であり、投入した順に取り出すことができる。格納できるメッセージは最大64Kバイトで、7日間しか保管することができないため、長期保管には向いていない。

図7　Queueの動作

活用方法

　連続した処理をMicrosoft Azure クラウドサービスのWorkerロールなどで分離して、それらをQueueストレージで連携させることによって、処理の非同期化を実現することができる。処理の非同期化により、変動が激しい処理の負荷を平準化できる。突発的に大きい処理負荷が発生しても、Queueストレージにより処理要求をいったん吸収し平準化、リクエストをロストせずに全て処理することが可能だ。

　例えば、Microsoft Azure Webサイトで全てのリクエストを受け付けて処理している場合、負荷の高い処理についても同様に処理すると、WebサイトのスレッドやCPUなどのリソースが占有されてしまい、リクエストが突発的に増大した際に処理しきれなくなり、リクエストをロストしてしまう可能性がある。これに関し、非同期でのリクエストを許容するサービスについてはQueueストレージに投入し、バックグラウンドで稼働するタスク（クラウドサービスのWorkerロールなど）に渡すように設計することが可能だ。この設計により、タスクで処理しきれないほどのリクエストが突発的に発生しても、リクエストはQueueストレージに蓄積されているため、リクエストがロストすることがない。リクエストの平均量を処理しきれるだけのタスクが稼働していれば、時間をかけて全て処理しきることができる。

図8　Queueを使った処理負荷の平準化と処理の非同期化

よいクラウドシステムを構築するためのキーとなるAzureストレージ

　以上のように、ストレージサービスのBlobストレージ、Tableストレージ、Queueストレージは、それぞれシステムのスケールアウトや可用性向上のために活用することができる。

　Blobストレージは、データサイズの大きい動画などのコンテンツを配信するMicrosoft Azure Webサイトで活用することで、Webサイトへの負荷を低減でき、大量のユーザーに少ないサーバ台数で対応できるようになる。Tableストレージは、大量のデバイスから送られてくる比較的サイズの小さい情報の格納先に活用することで、データのスケールアウトを実現することができる。Queueストレージはサービス間連携で活用することで、処理の非同期化、負荷の平準化を実現することができる。ストレージサービスは、ストレージ用途だけではなく、メッセージングシステムとしても活用することで、真の価値を発揮すると言っても過言ではない。

　今回紹介した方法以外にも活用方法は多岐にわたり、クラウドデザインパターンに合致した使い方だけでなく、アイデア次第でさまざまな応用ができるだろう。各ストレージを適切に使うことができれば、よりよいクラウドシステムを構築できるようになる。

日山雅之（ひやま まさゆき）

株式会社FIXER Enterprise Cloud Unit クラウドエンジニア

学生時代に地元のITベンチャー企業にてプログラミングのアルバイトを行い、そこでプログラミングの奥深さに魅了され、スーパープログラマを目指す。大学院を卒業後、現日立システムズに入社し、App Bridgeシリーズの開発に携わる。その後、プログラミング技術をより高めるべく株式会社FIXERに入社。Microsoft Azureの虜になる。マイクロソフト認定ソリューションデベロッパー（WebApplication）およびAWS認定ソリューションアーキテクト（アソシエイト）。

【FIXER公式サイト】http://www.fixer.co.jp/

【cloud.config公式サイト】http://www.cloud-config.jp/

【Blog】http://www.cloud-config.jp/category/programmer_hiyama