Azure Backupの復元方法について

こんにちは、kc-dreamです。
今回はAzure Backupの復元方法についてご紹介したいと思います。
image.png

Azure Backupとは

Azure Backup サービスでは、Microsoft Azure クラウドにデータをバックアップします。 オンプレミスのマシンとワークロード、および Azure 仮想マシン(VM) をバックアップできます。

下記から抜粋
Azure Backup とは

Azure Backupを使用した復元方法

Azure Backupには大きく3種類の復元方法が用意されています。
本記事では3種類の復元方法について簡単ではありますが、ご紹介していきたいと思います。

1,VM の新規作成

Azure VM が新規作成され、復元されたディスクがアタッチされます。
このオプションでは、容易にVMを作成いただける反面、細かな構成の変更を自身で実施する必要があります。

  • バックアップされた VM が静的 IP アドレスを持っていた場合、復元された VM は競合を回避するために動的 IP アドレスを持つことになる。
  • Ubuntu など cloud-init ベースの Linux ディストリビューションを使用している場合、セキュリティ上の理由から、復元後にパスワードがブロックされます。 復元した VM で VMAccess 拡張機能を使用して、パスワードをリセットしてください。
  • VM でドメイン コントローラーとの関係が破損しているために復元された VM にアクセスできない場合は、下記リンクの手順に従って VM を起動します。
  • 復元された VM には可用性セットがありません。 ディスクの復元オプションを使用する場合、提供されているテンプレートまたは PowerShell を 使用してディスクから VM を作成するときに可用性セットを指定することができます。

復元後の手順 - Azure VM の復元

2,ディスクの復元

こちらのオプションでは、ディスクのみが復元されます。
復元されたディスクを利用して、自由な構成のVMを後から作成することができます。

例えば、PowerShell を使用して Azure VM を作成する方法として、
以下の公開情報に記載のような手順を実施いただくことができます。

既存の VHD を管理ディスク (Managed Disk) に変換し、VM をデプロイする
※バックアップ対象が管理ディスクの場合にも、手順 2 に記載のサンプルコードをお役立ていただけるかと存じます。

3,ディスクの置き換えについて

ディスクの置き換えオプションでは、既存の VM のディスクのみが付け替えられます。
このため、VM の設定をすべて引き継ぐことができる、最も簡単な復元方法となります。

VMにアタッチされていたディスクはすべてディタッチされた状態で残り、
新たに復元され作成されたディスクがアタッチされ、VM が起動します。

ディスクの置き換えオプションは現在管理ディスクでのみサポートされております。
その他の制限事項については以下のリンク参照願います。

復元オプション - Azure VM の復元
*既存ディスクの置き換えは、暗号化されていないマネージド VM でサポートされています。
非管理ディスク、汎用化された VM、またはカスタム イメージを使用して作成された VM では、サポートされていません。

おわりに

簡単ではありますが、Azure Backupの復元方法についてまとめたので参考にしていただければ幸いです。
2020-01-08_11h02_53.png


Excel / Azure Notebooks / Databricks で同じことをやってみる #4 【Databricks編】

はじめに

Excel / Azure Notebook / Databricks で同じことをやってみる #1 【はじめに】
Excel / Azure Notebook / Databricks で同じことをやってみる #2 【Excel編】
Excel / Azure Notebooks / Databricks で同じことをやってみる #3 【Azure Notebook編】
に続き、Databricks を用いて簡易集計及び可視化を行います。

Databricksとは?

概要

以前の記事でも取り上げましたが、こんな特徴のデータ分析基盤プラットフォームです。
・Apache Spark環境を数分でセットアップ
-分析環境がすぐに作れる
-スケーラブル
-自動でスケーリング可能
-Sparkを作った人達が、Spark用にカリカリにチューニングしたプラットフォーム
・Notebookをバッチスクリプトとして使える
-例えば、データストリームに対して、Aの処理を一週間に一回かけて、Bのテーブルに追記する、
という処理が必要な場合、Aの処理を記載したNotebookを、バッチジョブとして設定できる
・バージョン管理が楽
-いわゆるタイムマシーン機能が使える
-複数人での作業がしやすい
・マジックコマンドが便利
-デフォルト言語としてPythonを設定しても、セルの頭にマジックコマンド(%sql)でクエリが書ける
・簡単に可視化
-発行したクエリをそのままグラフ化
-別途ライブラリのインポート不要
・オートターミネーションで安心
-クラスタをxx分未使用の場合には停止(=課金されない) といった設定ができる
-高額なクラスタを立ち上げっぱなしで、気が付いたらものすごい課金が…みたいなケースを回避できる
-今回発生した費用のまとめは後述します

設定

こちらのドキュメントを参照いただき、
・Azure Portal へのサインイン
・Spark クラスタの作成
・notebookの作成
まで行ったら準備完了です。

操作のきほん

Notebook自体の操作は、Jupyter Notebookとほとんど同じです。結構直感的に操作できますが、迷ったときは公式ドキュメントを参照しましょう。

データの準備

ストリーミングデータや大規模なテーブルを接続するのであれば、データの保存先は、Blob Storage Gen 2 や Delta Lake が候補になります。
今回は、そこまで大きくないCSVデータx3ですので、Databricksにテーブルを作成します。
ホーム画面の下記の場所に、CSVデータをドラッグアンドドロップ

Create Table with UIをクリック

作成したクラスタを選択し、Preview Tableをクリック

デフォルトだと、列名やスキーマはこのようになっています

First Row is Header オプションで、一行目を列名として読みこみ、Infer Schema オプションの指定でスキーマを類推してくれます。
Create Tableをクリックし、しばらくするとテーブルの作成が完了します。CSVファイル3つそれぞれでこれらの作業を行います。

Data タブをクリックすると、テーブルを確認できます。

やってみる

流れ

Azure Notebookの回でやったように、Sparkで中間テーブルを作成します。
そこから先は、SQLオンリーでグラフ化まで行います。

手順

PySparkのライブラリをインポート。今回の用途であればこれだけでOK
[crayon-616b7b924b073514590971/]
先ほど作成したテーブルの名称を変数に格納
[crayon-616b7b924b07c912873215/]
それぞれのテーブルをSparkで読み込み
[crayon-616b7b924b07f633480288/]
テーブル結合のために、必要な列名を確認しておきます (結果は省略)
[crayon-616b7b924b081616598457/]
中間テーブル (name: sql_tbl) を作成します。コードは#3 Azure Notebookの回で説明したものと同じです。
[crayon-616b7b924b083254093691/]
ここからは全部SQLで記載していきます。%sqlとセルの頭に入れれば、SQL文として処理してくれます。結合処理を再度行うのは面倒なので、このテーブルは永続化しておきましょう。一時テーブルで良いときは、CREATE TABLE を CREATE OR REPLACE TEMPORARY VIEW AS にすればOK
[crayon-616b7b924b085881032237/]
以下で中間テーブルのスキーマが確認できます
[crayon-616b7b924b087847588055/]
結果

集計後テーブル (name: sql_tbl2) を作り、永続化させます。
[crayon-616b7b924b089191741076/]
集計後テーブルに対してクエリを発行します。可視化した時に同じくらいのスケールに収まるように、送料の割合を1000倍しておきます。
[crayon-616b7b924b08b496748615/]
結果はこちら。デフォルトだと表が出力されます。下のボタンでクエリの結果をそのまま可視化可能。

こんな感じです。アドホックな分析にとても便利!

費用

料金体系

クラスターの起動時間に応じて、分単位で、以下のマシンリソースに対して課金されます。 (詳細はこちら)

料金表だけを見ていると意識に上がりずらいのですが、Databricks Unit には Driver とWorkerの2タイプがあり、クラスタを立ち上げると両方が起動され、課金されます。それぞれにインスタンスを割り当てて処理をしてもらうわけですが、当然、性能の高いインスタンス(= 高いDBU値) ほど、高コストになります。
今回使用したのはもっとも安価な 0.5 DBU のインスタンス。

今回の費用概算

今回の簡易分析・可視化で、どのくらいの費用が発生したか概算してみましょう。以下は今回使用したクラスタの設定画面。費用に大きく響いてくるところなので、本格的に分析基盤を立ち上げる際には、分析対象と内容に応じて、必要十分な計算資源を割り当てるように留意する必要があります。

設定は以下の通り。
クラスタのJob履歴を見てみたところ、Workerのスケーリングはしなかったようなので、クラスタの起動中は、0.5 DBU + 0.5 DBU で合計 1 DBU 使ってる計算になります。
・リージョン: 米国西部 2
・ワークロード:データ分析
・レベル:Standard
・Driverタイプ:F4s (0.5 DBU)
・Workerタイプ:F4s (0.5 DBU)
・最小ワーカー数: 1
・最大ワーカー数: 4
・自動停止
・15分操作がなかったらクラスタを停止
分単位の課金なので、Cluster の Event Log から、ここ2日間で何分間クラスタを起動したかざっくり見てみます。3回起動/停止しているようです。合計約70分。

Databricks の料金表を参照し、70分間インスタンスを起動した今回の費用概算と、仮に48時間インスタンスを立てたままにした場合の料金を比較してみました。
当たり前ですが、オートターミネーションした場合と継続利用では、かなりの金額差がありますね。

分析プラットフォームサービスは、どうしてもマシンスペックでの比較がされやすい傾向にあります。
しかし、実運用に則して考えると、Databricks の費用対効果の高さはピカイチじゃないかと思います。

まとめ

さいごにDatabricksの長所をおさらい。
・すぐApache Spark環境を作れる
・Notebookをバッチスクリプトとして使える
・バージョン管理が楽
・マジックコマンドが便利
・簡単に可視化
・オートターミネーション
アドホックな分析をするなら、SQLをそのままかけて、すぐに可視化できて、クラスタのオートターミネーションが利用できる Databricks が最高に便利。

おわりに

Databricks、簡易的な可視化ならできるけど、ちょっと凝ったグラフは?BIとの接続は?
ということで、次回は DatabricksPower BI につなげてみようと思います。お楽しみに!

参考サイト

クイック スタート: Azure portal を使用して Azure Databricks 上で Spark ジョブを実行する
Databricksで分析業務がはかどっている話
平成最後の1月ですし、Databricksでもやってみましょうか

 

 

Azure Databricksの導入ならナレコムにおまかせください。

導入から活用方法までサポートします。お気軽にご相談ください。

Azure Databricksソリューションページはこちら

 

 


Excel / Azure Notebooks / Databricks で同じことをやってみる #3 【Azure Notebook編】

はじめに

前回行ったExcelでの簡易集計と可視化を、Azure Notebooksでやってみます。

Azure Notebooksとは?

概要

データ分析プラットフォームのデファクトスタンダード、Jupyter Notebookをクラウド環境で起動できるAzureサービスです。他にはGoogle Colaboratoryが有名ですね。
ローカルでJupyter Notebookを使う場合、環境構築でつまづくこともしばしば。クラウドであればそのあたりほんと楽です。
・数ステップでAzure上に環境設定可能
・クラウド上で共同作業可能
・メモリ4GB, ストレージ1GBまで無償
Notebookはデータサイエンティストやアナリスト専用のものではありません。
分析に都合のいいプラットフォームがそろってて、メモ書きが残せて、みんなとシェアできる、いい感じに使いやすい "ノート" だと考えて、身構えずに触ってみましょう。

インストール

まずはAzure Notebookをセットアップします。 手順はこちら。Microsoftアカウントがあればすぐに数ステップでできます。

操作のきほん

初めてNotebookに触れる人のために、基本操作とショートカットをご紹介します。
セルを選択、コード入力後、Shift + Enterでそのセルのコードを実行できます。

セルの中を選択すると、枠が緑色になりEdit Modeに、セルの外を選択すると、枠が水色になりCommand Modeになります。

モード切り替えは、escとenterでも可能。

Command Modeで、mを押すとセルをMarkdownモードに、yを押すとcodeモードにできます。

これでMarkdownのメモが残せます。

Command Modeでaを押せば上に、bを押せば下にセルを追加可能。xで削除。

Command Mode時に、上下カーソルでセルを移動できます。
編集したいセルでenterを押せば、対象セルのEdit Modeに遷移。

作業をチェックポイントとして保存したいときは、ctrl + sを押します。これでいつでもそのポイントに戻れます。

特定のセルだけ実行されないようにしておきたいな、という時はctrl + / でコメントアウトしておきます。

他にもショートカットはたくさんあります。一覧表はHelpを参照しましょう。

あとは触りながら覚えていけばOK。

データの準備

Brazilian E-Commerce Public Dataset by Olistから、データをダウンロード、解凍しておきます。

Azure Notebook を立ち上げ、作成した Notebook と同じディレクトリで、UploadタブのFrom Computerを選択

以下の画面に遷移するので、解凍先のフォルダにあるCSVデータを、ドラッグアンドドロップ。

Uploadを押して、しばらく待ちます。Notebookと同じディレクトリにCSVファイルがアップロードされてれば完了です。

流れ

データの操作の定番といえば Pandas ですが、興味本位で Databricksとの比較してみたいので、並列分散処理フレームワークである PySpark を用いて中間テーブルを作成します。
そこからSQLで必要な集計処理を行い、最後に可視化のためのライブラリを使って、グラフを描画します。

手順

以下のスクリプトをNotebookのセルに入れ、実行していきます。
まずはPySpark関連のライブラリをインポート。
[crayon-616b7b924bb4d415698979/]
次に、Sparkのコンストラクタの作成。
正直言ってこのコードが何をしているのか良くわかっていないのですが、このコンストラクタが後述のスクリプトを良しなに処理してくれるようです。
[crayon-616b7b924bb54108434486/]
アップロードしたCSVファイル名を変数に放り込んでおきます。
[crayon-616b7b924bb56891537507/]
CSVファイルをSparkに読み込ませます。上から、売上テーブル、製品テーブル、翻訳テーブル。ちょっと時間がかかります。
[crayon-616b7b924bb58689152204/]
テーブル結合のために、製品テーブルの product_id の名称を product_id2 に変更。
[crayon-616b7b924bb5a501095597/]
テーブル結合のために必要な列名を確認しておきます (結果は省略)
[crayon-616b7b924bb5c806852609/]
中間テーブルを作成します。※備考参照のこと
[crayon-616b7b924bb5d789808981/]
作成した中間テーブルのスキーマを確認します。(これも結果省略)
[crayon-616b7b924bb60861612807/]
このテーブルに対してSQLを発行し、売上のTop10カテゴリを抽出、pandas_dfに変換後、平均単価で並べ替えします。こんな形でそのままクエリが書けるのは便利ですね。
[crayon-616b7b924bb62530432968/]
可視化のためのライブラリをインポート。
[crayon-616b7b924bb64182178212/]
グラフを描画。
[crayon-616b7b924bb65117584606/]
出力されるグラフデータはこちら

pros

・ビジネスロジックが埋もれにくい
・どの処理をどんな順番で行うのか明確になる
・Markdownでメモ書きも残せて第三者にもフレンドリー
・意外と習得コストが低い
・今回はPySparkを使ったので参考資料は少ないものの、pandasであれば、たくさんの参考資料あり
・SQLも然り
・環境構築が簡単
・クラウドのNotebookの最大の利点
・違うPCでもアカウントにログインさえできれば同じように動作する

cons

・バージョン管理が大変
・チェックポイントを設けることはできますが、コードを書きたいときにわざわざこれをやるか、というと私はやりません。ちょっと面倒ですがコメントアウトで対応することが多いです。
・可視化に要する工数が大きい
・グラフの成型には結構な手間がかかります。今回はカテゴリの選定なので本来はそこまで凝ったグラフは必要ないのですが、ついいろいろ手を出してしまい、時間を費やしてしまいました(自戒)

まとめ

Azure Notebooksはすごく便利ですが、Jupyter Notebookをそのままクラウドに持ってきたというコンセプトなので、運用という意味では課題がいくつかあるように感じられます。次回はDatabricksでやってみます。お楽しみに!

参考サイト

Kaggle.com
Brazilian E-Commerce Public Dataset by Olist
Class SparkContext

備考: 中間テーブル作成時のPySparkコード

備忘録がてらまとめました

 

 

Azure Databricksの導入ならナレコムにおまかせください。

導入から活用方法までサポートします。お気軽にご相談ください。

Azure Databricksソリューションページはこちら

 

 


Excel / Azure Notebook / Databricks で同じことをやってみる #2 【Excel編】

はじめに

前回紹介した内容に沿った簡易集計と可視化を、Excelで行います。

流れ

3つのCSVデータを組み合わせて、中間テーブルを作成します。

青色は、 各々のレコードに対して feight / (price + freight)で算出した、単価と送料の合計に占める送料の割合。オレンジは、キーとなる値を紐づけて取得した英語のカテゴリ名。
この中間テーブルを参照元にして、pivotテーブルpivotグラフを作成します。

手順

テーブルを跨いでしまうと後続の処理が遅くなってしまうので、まずは一つのファイルにCSVデータをまとめます。左から売上テーブル、製品テーブル、翻訳テーブルを配置。

注文テーブルの最右列に、送料の占める割合を計算する数式を入れます。一つのセルに数式を入れ、行末までコピペします。

同じく注文テーブルで、product_idをキーにして、製品カテゴリ(ポルトガル語)データを引っ張ってきます。皆さんおなじみvlookupです。

次は製品カテゴリ(ポルトガル語)をキーにして、製品カテゴリ(英語)を引っ張ってきます。

これでひとまず使おうと思っている情報は一つのテーブルに集約できました。売上ボリュームの大きいカテゴリを出すために、注文テーブルのセル範囲を選択して、pivotグラフ、pivotテーブルを作成します。

グラフの要素を選びます。フィールドリストの値に単価、行にカテゴリを持っていき、テーブルを単価の合計が大きい順にソートします。

この作業で得られた売り上げのトップ10カテゴリがこちら。

次に、トップ10の中から要件に合う3つのカテゴリを選定するために、別のPivotを作成します。Pivotの参照セルは先ほどと同じ。フィールドリストの値に単価と送料に占める割合を入れ、行にカテゴリを入れ、集計データの平均値を算出するように設定を変更します。

先ほど出した売上トップ10のカテゴリが表示されるよう、行ラベルをフィルタリングします。(gifファイルは例として1カテゴリだけフィルタリング)

単価を棒グラフで、送料に占める割合を折れ線グラフに変更し、行ラベルなどのグラフ要素を配置します。

その結果。

このグラフから、
・ある程度売上ボリュームがある (トップ10以内)
・比較的単価が高い
・配送料の割合が低い
の要件を満たすカテゴリを3つ選定するとすれば、
・watched_gifts
・cool_stuff (DVDなどらしいです。なぜにcool_stuffなのか...)
・health_beauty
あたりでしょうか?なんとなくそれっぽい結果が出ました。
それではこの類の簡易分析・可視化をする場合のExcelの長所短所をまとめてみます。

pros

・習得コストが低い
・参照できるドキュメントが多い
・データ量が少ない場合にはさくっと可視化できる

cons

・運用コストが高い
・元データに対する変更 (列の挿入や行の追加) に弱い
・再現性を高めるために必要なコストが高い
・慣れてる人ほどこれに気が付かない
・ビジネスロジックが埋もれやすい
・数式が入れ子になっていて、結局この列で何を計算してるのか、不明瞭になりやすい
・他人が見たら意味不明なシートが出来上がることがある
・not スケーラブル
・処理の可否がローカルマシンのスペックに依存する
・回避する方法はあるものの、それはそれで結構習得コストが高い
・最大で 約100万行 x 1.6万列 をサポートしているが、今回のような用途ではまず使用不可

まとめ

Excelはお手軽で良いのですが、複数テーブルを結合したりといった分析には不向きですね。分析結果を共有したりするのも苦手です。次回はAzure Notebookでやってみます。お楽しみに!

参考サイト

Kaggle.com
Brazilian E-Commerce Public Dataset by Olist

 

 

Azure Databricksの導入ならナレコムにおまかせください。

導入から活用方法までサポートします。お気軽にご相談ください。

Azure Databricksソリューションページはこちら

 

 


Excel / Azure Notebook / Databricks で同じことをやってみる #1 【はじめに】

はじめに/対象者

Excelのつらみを日々体感している以下のような方に向けて、Azureファミリーの便利なサービスを何記事かに分けてご紹介します。
・非技術者でデータを扱っている
・データの集計や可視化に、Excelを使っている
・とりあえず今やってる作業の効率化から進めたい
・今より少し踏み込んだ分析ができるプラットフォームを探してる
・Excelのつらみ
・vlookup関数やmatch関数を入れ子にしがち → フリーズ
・データ量増大 → フリーズ
・うっかりどこかの列を消去 → N/Aを量産
・バージョン管理(ローカルでやる場合) → ………

流れ

Excelでの作業がどのくらいシンプルになるかを感じてもらうために、簡易的にクロス集計を行って可視化するまでを、下記3つのプラットフォームで同じようにやってみます。
・Excel
・Azure Notebooks (クラウド上のJupyter Notebook)
・Databricks (Sparkベースのデータ分析プラットフォーム)
同じ土俵での比較がそもそもナンセンスですが、ともかく無理やりやってみます。
いわゆるデータ分析前段の前処理を一部かじって、可視化する、までの範囲を行うことになります。
データ分析フローで言う、以下のセグメントを行うイメージ。

それぞれの作業環境は以下の通りです。スペックの単純比較はできませんが、メモリ数見てもらうだけでも、ずば抜けてハイスペックなものを使うわけではないのがわかると思います。

そのあと、ちょっと踏み込んだ内容として、
・DatabricksにPower BI(Microsoft謹製データ可視化ツール)を接続
・タイタニック号の生存者分類 (Kaggleで有名なアレです) をAutoMLにやらせてみる
をやってみます

使用データ

お手元のデータを使ってもらうのが一番いいのですが、初めてPythonやSparkに触れる人にとっては少しハードルが高いはず。そこで、
・テーブルの定義が明確
・売上データがExcelで扱うことができるボリューム
・データ自体のイメージしやすい
の条件を満たすデータとして、Kaggleで公開されている以下のデータセットを採用することにしました。
-------------
Brazilian E-Commerce Public Dataset by Olist
・概要
ブラジル市場最大のデパートのeコマースストアの公開データセット
2016-2018年までの10万件の注文データ
小売店はeコマースストアを通じて製品を販売、提携物流会社を用いて、顧客に直接商品を出荷
製品を受け取る or 配達予定日が来ると、顧客はレビュー調査を電子メールで受け取る
顧客は任意でレビューを書ける
・Kaggleでの課題
自然言語処理 (レビュー内容に対して)
顧客クラスタリング (レビューの記載がない顧客の属性)
製品クラスタリング (不満をもちやすい製品カテゴリ)
売上予測
配送料金最適化
-------------

課題設定

今回はシンプルに以下のような立て付けで課題設定します。
-----------
・あなたは Olist のマーケティング担当者です。
・クリスマス商戦用に、配送料無料キャンペーンを検討中
・単価と配送料の合計に占める配送料の割合が高いカテゴリは避けたい
・クリスマスなので、比較的単価が高いカテゴリを選定したい
・ある程度売上ボリュームのある3つのカテゴリに絞り込みたい
・この課題を解決するために、以下のテーブルを用いて簡易分析し、結果を可視化する
・売上明細データ
・カテゴリデータ
・翻訳データ
・(小売店がOlistに支払う手数料は製品単価に比例しているものとする)
-----------

テーブルスキーマ

まずこのデータセットに含まれる8つのテーブルの関係図を眺めてみましょう。
それぞれのテーブルはCSVデータで提供されます。
黄色が注文の製品データ、オレンジが注文の明細データです。この2テーブルがproduct_idで紐づいています。
今回はこれら2テーブルと翻訳テーブル、併せて3つのテーブルを使用します。

今回使用するテーブルを簡単に説明します。

1.売上明細データテーブル

左から、注文番号、注文番号ごと/製品IDごとに割り当てられる通し番号、製品ID、販売者ID、出荷期日、単価、送料です。今回参照するのは、製品ID、単価、送料の三点です。

2.カテゴリデータテーブル

左から、製品ID、カテゴリ名(ポルトガル語)、製品名の長さ、製品明細の長さ、製品写真枚数、パッケージの重量、パッケージのサイズ(縦/横/深さ)です。今回は参照するのは、製品IDとカテゴリ名(ポルトガル語)の2点です。

3.翻訳データテーブル

カテゴリ名(ポルトガル語)とカテゴリ名(英語)の対応表です

中間テーブル概要

これらの3テーブルをキーとなっている値で紐づけて、中間テーブルを作ります。
単価と配送料の合計に占める配送料の割合を、各々の注文データで算出します。以下のようなイメージです。

まとめ

さて、前置きはここで終わり。次回はこの作業をExcelでやってみたいと思います。お楽しみに!

参考サイト

Kaggle.com
Brazilian E-Commerce Public Dataset by Olist

 

 

Azure Databricksの導入ならナレコムにおまかせください。

導入から活用方法までサポートします。お気軽にご相談ください。

Azure Databricksソリューションページはこちら

 

 


Azureアーキテクチャガイドまとめ 8 【ビックコンピューティングアーキテクチャ】

はじめに

Azureクラウドアプリケーションアーキテクチャガイドより、7つあるスタイルの最後の1つ、ビッグコンピューティングアーキテクチャに関してまとめます。

概要

作業を個別のタスクに分割し、多数のコアを使って同時に処理するアーキテクチャスタイル。大量のコアを一気にプロビジョニングし、アプリケーションが完了すると、プロビジョニングを解除します。
以下のような特徴を持つアプリケーションに適します。
計算負荷が高く、複数へのコンピュータのCPUへの分割が必要なシミュレーションや数値演算
・一台のコンピュータでは時間がかかりすぎる処理時間の長い計算
小さな計算処理を数百万回から数千回実行する必要がある場合
以下のようなケースで活用します
・画像のレンダリング
・流体力学
・金融リスクモデリング
・石油探査
・新薬開発
・応力解析

対応するAzureコンポーネント

大規模なパイパフォーマンスコンピューティングアプリケーションを実行するためのマネージドサービスである、Azure Batchが主要なサービスです。
Azure Batchはワークロードに合わせて、Virtual Machineを自動的にスケールアウトします。

利点

・単純並列処理によるハイパフォーマンス
・大規模な問題を迅速に解決
・専用の高速ネットワークを備えた専用HWにアクセスできる
・作業に必要な数だけVMをプロビジョニング可能

課題

・マシンリソースの管理
・数値演算ボリュームの管理
・数千のコアのタイムリーなプロビジョニング

参考リンク

Azure でのハイ パフォーマンス コンピューティング (HPC)
ビッグ コンピューティング アーキテクチャ スタイル


Azureアーキテクチャガイドまとめ 7 【ビックデータアーキテクチャ】

はじめに

Azureクラウドアプリケーションアーキテクチャガイドより、ビッグデータアーキテクチャに関してまとめます。

連載目次

Azureアーキテクチャガイドまとめ 1 【はじめに】
Azureアーキテクチャガイドまとめ 2【N層】
Azureアーキテクチャガイドまとめ 3 【Webキューワーカー】
Azureアーキテクチャガイドまとめ 4 【マイクロサービス】
Azureアーキテクチャガイドまとめ 5 【CQRS】
Azureアーキテクチャガイドまとめ 6 【イベントドリブンアーキテクチャ】
Azureアーキテクチャガイドまとめ 7 【ビッグデータアーキテクチャ】 → 本記事
Azureアーキテクチャガイドまとめ 8 【ビッグコンピューティングアーキテクチャ】

ビッグデータの背景と最近の流れ

まずはビッグデータが発生した背景と、それを取り巻く近年の流れを整理します。
以下に挙げる変化により、そのままの形では解析に要する計算資源の確保が現実的でないほどに大きなデータセットの蓄積が可能になりました。
・ストレージコストの低下
・データ収集手段の増加
・データ収集のスピードアップ
これに応じて、データを分割し、並列処理を行い、最終的にそれらを統合して分析結果を出力する、というアーキテクチャの要請が強くなっていきます。HadoopやApache Sparkは、そんな中開発されたオープンソースフレームワークの代表選手です。
以前はこれらを使いこなすために高いスキルが必要でしたが、現在はハードルを数段下げてくれるAIサービスが揃ってきています。Azureサービスで代表的なものは以下の3種類。
Machine Learning Services: 専門家向け分析基盤
Databricks: 非専門家にも扱いやすい分析基盤
Cognitive Services: AIのアプリ実装のためのAPI
以下のように自身のスキルや要件に応じて選ぶのが良さそうです。

概要

スタイルの説明に入ります。従来のデータベースシステムにとって、大きすぎる/複雑すぎるデータの処理や分析を行うのに適したアーキテクチャです。例えば以下のようなケース。
・保管中のビッグデータソースのバッチ処理
・伝送中のビックデータのリアルタイム処理
・ビックデータの対話的な調査
予測分析
機械学習

コンポーネント

ほとんどのビックデータアーキテクチャには次のコンポーネントの一部、またはすべてが含まれます。
・データソース
・アプリケーションデータストア (RDBなど)
・静的ファイル (ログファイルなど)
・リアルタイムデータソース (IoTデバイスなど)
・ストレージ
・一般にデータレイクと呼ばれる
・分散型ファイルストア
・様々な形式の大規模ファイルを大量に保存
・バッチ処理
・データセットが非常に大きいため、バッチ処理が必要
・リアルタイムのメッセージ取り込み
・キャプチャして保存する手段をアーキテクチャに取り込む
・メッセージ取り込みストア
・ストリーム処理
・分析データストア
・分析とレポート作成
・オーケストレーション

データを集めるところから含めると、ざっくりと以下のような流れになります。

対応するAzureサービス

データの保存や中継点に使用するサービス、HadoopベースのテクノロジスタックであるHDInsightに加えて、よりマネージドな分析環境構築が可能なAIサービス群もまとめます。

Machine Learning Service

・モデルの構築
・クラウドからエッジまで場所を選ばないデプロイ
・デスクトップからオンデマンドでのスケーリング
・自動化された特徴量エンジニアリング、アルゴリズム選択、ハイパーパラメータスイープ
・ドラッグアンドドロップ対応のビジュアルインターフェイスあり
・MLOps (機械学習用のDevOpcs)

・学習のライフサイクル全体の管理
・パイプラインの構築・効率化
・デプロイ済モデルのパフォーマンス管理
・各種データサイエンス向けフレームワーク及びライブラリサポート

Azure Databricks

・高速で最適化されたApache Spark環境を数分でセットアップ
・Azure Machine Learningがネイティブ統合
・自動でスケーリング
・GitHubとAzure DevOpsで容易にノートブックのバージョン管理
・各種データサイエンス向けフレームワーク及びライブラリサポート
・多種の言語サポート

・Python
・Scala
・R
・Java
・SQL
・データの取得から分析から可視化までのシームレスな連携

Cognitive Services

以下5つのカテゴリで、学習済AIのAPIが用意されています。本当に数多くのサービスがあるので、こちらをチェックしてみてください。プレビューを見てみるだけでも面白いですよ。
・視覚
・音声
・言語
・決定
・検索

データの保存や中継点に使用するサービス

分析基盤のコアサービス周辺を支えるサービス群です。
Azure Data Factory
Azure Data Lake Storage
Azure Data Lake Analytics
Azure Data Warehouse
Azure Stream Analytics
Azure Event Hub
Azure IoT Hub

HDInsight

Apache Hadoopのオープンソース分析プラットフォーム各種を統合的に使えるようにしたサービスがHDInsightです。

利点

・AzureマネージドサービスとApacheテクノロジを混在させ、既存のスキルや投資を活用
・並列処理によるハイパフォーマンス
・スケールアウトプロビジョニングによる柔軟な拡張性
・既存のソリューションとの相互運用性

課題

・複雑性
・複数の処理が必要になるので、複雑なアーキテクチャになる
・構築、テスト、トラブルシューティングが困難な作業になりやすい
・パフォーマンス最適化のために多数の構成設定を使用する必要がある場合あり
・スキルセット
・高度に専門的で他のアプリケーションアーキテクチャでは一般的でないフレームワークや言語
・一方で普及している言語に基づいた新しいAPIも生まれている
・テクノロジの成熟度
・テクノロジの多くは現在も進化中
・Sparkのような新しいテクノロジの場合、新リリースのたびに大幅な変更や機能拡張も
・マネージドサービスも今後進化していく可能性が高い
・セキュリティ
・データはデータレイクに集中的に保存
・このデータへのアクセス保護に困難が伴う場合も

ベストプラクティス

本アーキテクチャのベストプラクティスは以下の通り。AIサービスの活用によって、かなりのパートがカバーされます。
・並列処理
・静的データファイルを分割可能な形式で作成・保存
・複数のクラスターノードの並列実行でジョブ時間の短縮
・データの分割
・データファイルとテーブルなどのデータ構造を分割
・クエリで用いられるテーブルの分割
・データ取り込みやジョブスケジューリングの簡略化
・データレイクの使用
・「収集 → 蓄積 → 処理 → 分析・ビジュアライズ」の順になるような分析基盤
・データは処理の前にスキーマを適用
・アーキテクチャに柔軟性が生まれ、データ取り込みのボトルネックを防げる
・適所でのデータ処理
・データを分散データストアで処理し、必要な構造に変換して分析へ
・変換 → 抽出 → 読み込みの順
・使用率と時間コストのバランス
・クラスターの処理時間、個数、単価を考慮
・最も費用対効果の高い構成にする
・クラスターリソースの分割
・ワークロードに応じて分割することでパフォーマンスを向上
・データ取り込みの調整・オーケストレーション
・Azure Data Factoryやオーケストレーションワークフロー、パイプラインを使用
・機密データの除外
・データ取り込みの早い段階で機密性の高いデータを除外し、データレイクに保存されないようにする

まとめ

ビッグデータアーキテクチャの特徴と使用されるサービスについて見ていきました。次回は最後の一つ、ビッグコンピューティングアーキテクチャについてまとめます。お楽しみに!

参考リンク

Azureアーキテクチャセンター
Azureクラウドアプリケーションアーキテクチャガイド ダウンロードページ
ビッグデータアーキテクチャ


Azureアーキテクチャガイドまとめ 6 【イベントドリブンアーキテクチャ】

はじめに

Azureクラウドアプリケーションアーキテクチャガイドより、7つあるアーキテクチャスタイルの一つ、イベントドリブンアーキテクチャに関してまとめます。

概要

情報の送り手が「イベント」を発行し、それを保持する箇所を設け、情報の受け手はそこにイベントを取りに行く、というアーキテクチャスタイルです。Webキューワーカーアーキテクチャと似ていますが、以下のようなイメージで違いを理解しています。
・キューの格納先 = パイプ
・処理したい命令を流しつつ保持しておける
・パイプの形状変更は一苦労
・配信者や受信者を変更/追加する場合には、配信側のコードをいじる必要あり
・イベントの格納先 = 箱
・処理のためのトリガーを放り込める
・複雑なものが入ってても大丈夫そう (パイプだと詰まりそう)
・受信者は能動的に箱の中身を取りに行く必要あり
・何人で箱を共有してもOKで、拡張性が高い
要件に応じて、パブリッシュサブスクライブモデルとイベントストリームモデル、2種類のモデルが使用可能です。
それぞれ、ざっくりとした構成を図示します。

適するアプリケーション

このアーキテクチャスタイルには以下のようなアプリケーションに適しています。
複数のサブシステムが同じイベントを処理
最小のタイムラグのリアルタイム処理
・パターンマッチングや特定の時間範囲内の集計など、複雑なイベント処理
・IoTなど、大量の高速データを処理

利点

・送り手と受け手を分離できる
・Point to Pointがないので、新しい受け手を容易にシステムへ追加できる
・受け手はイベントが到着すると即座に応答できる
・高い拡張性と分散性

課題

配信の保証
・イベントを正しい順序で処理する必要がある場合

対応するAzureサービス

コンシューマー側の処理方式は、以下3種に大別されます。要件に応じて使い分けます。

組み合わせる各サービスの概要とアイコンは以下の通り。

まとめ

イベントドリブンアーキテクチャの特徴と使用されるサービスについて見ていきました。次回はビッグデータアーキテクチャスタイルについてまとめます。お楽しみに!

参考リンク

Azureアーキテクチャセンター イベントドリブンアーキテクチャ
Azureクラウドアプリケーションアーキテクチャガイド ダウンロードページ


Azureアーキテクチャガイドまとめ 5 【CQRS】

はじめに

Azureクラウドアプリケーションアーキテクチャガイドより、7つあるアーキテクチャスタイルの一つ、CQRSに関してまとめます。

概要

Command > 状態を変更するコマンド > Write処理
Query > 状態を読み込むクエリ > Read処理
Responsibility > 責任
Segregation > 分離
で、CQRS です。
つまり、Write処理とRead処理を適切に切り分けてパフォーマンスを上げよう、というアーキテクチャです。
具体的には、タスクの属性を考慮し、クエリとコマンドに以下のような役割を持たせます。

適用条件

読み取りと書き込みが発生する箇所すべてにこれを適用してしまうと、アーキテクチャ全体が過度に複雑になってしまいます。
よって、書き込みと読み取りの分離に明確な利点があるとみなされた場合にのみ採用します。例えば以下のようなケース。
・読み取りと書き込みでパフォーマンスやスケールの要件が大きく異なる
・読み取りが極端に多い
・多くのユーザーが同じデータにアクセスする (共同ドメインなど)

構成例

マネージドサービスを活用し、それぞれの処理がスムーズにいくように構築します。
例えばAzure FunctionsとCosmos DBを書き込み側に、App ServiceとSQL DBを読み込み側に配置した、以下のような構成です。
こちらのスライドを参考にさせていただきました。

利点

・独立した拡張性
・読み取りと書き込みのワークロードを独立に拡張
・ロックの競合を減らせる可能性
・最適化されたデータスキーマ
・読み取り側ではクエリに最適化されたスキーマ
・書き込み側では更新に最適化されたスキーマ
・セキュリティ
・適切なドメインエンティティ以外がデータを書き込めないようにできる
・懸念事項を分離し、保守性と柔軟性を向上できる
・複雑なビジネスロジックのほとんどは書き込み側に存在
・読み取りモデルは比較的単純にできる
・クエリを単純化できる

課題

・アプリの設計が複雑になる場合も
・高頻度の処理や更新イベントの発生にメッセージングを用いることが多く、メッセージのエラーや重複に対処する必要あり
・データベースを分離した場合、読み取りデータが古くなる可能性あり (CQRSは基本的に結果整合性)

ベストプラクティス

実装の詳細
更新の競合を避ける
読み取りモデルのスキーマ最適化

まとめ

CQRSアーキテクチャの特徴と、構成例ついて見ていきました。次回はイベントドリブンアーキテクチャについてまとめます。お楽しみに!

参考リンク

Azureアーキテクチャセンター
Azureクラウドアプリケーションアーキテクチャガイド ダウンロードページ
Azure Cosmos DB と Databricks を使ったCQRSパターンとラムダアーキテクチャ


Azureアーキテクチャガイドまとめ 4 【マイクロサービス】

はじめに

Azureクラウドアプリケーションアーキテクチャガイドより、7つあるアーキテクチャスタイルの一つ、マイクロサービスに関してまとめます。
※前回記事
Azureアーキテクチャガイドまとめ 1 【はじめに】
Azureアーキテクチャガイドまとめ 2【N層】
Azureアーキテクチャガイドまとめ 3 【Webキューワーカー】

対応するAzureサービス

今回はやや長くなるので、最初にマイクロサービスアーキテクチャで活用されるAzureサービスをまとめます。
サーバレスであればAzure Functions、コンテナであればAzure AKSがコアサービスになります。

http://azurerecipe.blob.core.windows.net/2019-08-10-02/2.jpg
どちらの場合も、以下のコンポーネントで構成されます。
・サービスを体現するコンポーネント
・ドメイン駆動設計でいうモデルを実装しているアプリケーションが動作するコンポーネント
・管理
・サービスのノードへの配置
・障害の発見
・ノード間でのサービスの再調整
・サービス検出
・サービスとそれが配置されているノードのリスト保持
・サービスのエンドポイントを知るためのサービス検索機能
・APIゲートウェイ
・クライアントのためのエントリポイント
・クライアントをサービスから分離
・Webと親和的ではないメッセージングプロトコルでも対応
・横断的機能の実行
・認証
・ログ記録
・SSLターミネーション
・負荷分散
コアサービスとともに併用されるサービスも一覧にしておきます。

構成図にするとこのような感じ。

ちょっと寄り道

どんなサービスがあって、どのように組み合わせるのか、おぼろげながらイメージできました。
数あるサービスの中でも専門性が高く、しかも進化が続いているアーキテクチャだけに、ガイドだけだとなかなか理解が進まなさそう、というのが正直なところ。
そこで、いったんガイドを離れ、理解が進みやすいような情報をつまみ食いしようと思います。

ドメイン駆動設計って何ぞ?

マイクロサービスアーキテクチャの設計で避けて通れないのが、ドメイン駆動設計 (Domain-Driven Design, DDD)。
設計の勘所はAzure公式ドキュメントに網羅されているのですが、専門用語が多く、頭になかなか入りません。
そこで、こちらの記事を参考にさせていただき、概要を図示しました。

先の表や後述する内容と重複しますが、マイクロサービスアーキテクチャには多くの利点がある反面、仕組みも管理も複雑になりやすいという傾向があります。
しかも、ドメインにフォーカスし続けて開発するためには、ステークホルダー間の認識の祖語を最小限にするメソッドを明示しておく必要があります。
この開発手法を体系化したものがドメイン駆動設計、と理解しました。大枠はこれで大丈夫(のはず)。

サーバレスとコンテナの比較

Azureアーキテクチャセンターにサーバレスとコンテナの比較がありました。革新が早い技術ですので、とりあえずベースラインの知識として頭に入れておきたいところです。

概要

さて、ここでガイドに戻ります。アーキテクチャスタイルの特徴を挙げてみましょう。
・小規模な自律的サービスの集合
・各サービスは自己完結型で、疎結合
・各サービスは別個のコードベース
・各サービスは明確に定義されたAPIを使用して互いに通信

具体的には、以下のような特徴を持つアプリケーションに適しています。
・高速なリリースが必要
・大規模
・高い拡張性が必要で複雑
・多様なドメインや多数のサブドメインを持つ
・複数の小規模な開発チームから構成される組織によって作られる

利点

・独立した展開
・アプリ全体を再展開せずにサービスを更新
・バグ修正と機能リリースの管理の容易さ
・独立した開発
・継続的なイノベーションの実現
・リリースのペースを速める
・一つの開発チームが、サービスの構築、テスト、展開を行える
・小規模な専任チーム
・チームは一つのサービスに専念
・コードベースが分かりやすくなり、新しいチームメンバーでも理解しやすい
・障害の分離
・サービスがダウンした場合でも、その部分以外はサービス継続できる。
・とはいえ、回復性が自動的に得られるわけではない点に留意。
・テクノロジスタックの混在
・各サービスが違ったテクノロジスタッフ、フレームワークを持つことを許容する
・つまり、特定のサービスに最適な技術を選定できる
・きめ細やかな規模拡張
・各サービスは独立に拡張可
・マシンリソースの効率的活用

課題

・複雑性
相当する、複数の機能を持った単一のアプリ(モノリシックアプリケーション)に比べ、多くの可動部分があり管理が複雑
・開発とテスト
既存のツールは、サービスの依存関係を考慮するように設計されていない場合あり
サービスの境界を超えるリファクタリングが困難な場合も
特にアプリケーションが急速に進化している場合には、サービスの依存関係テストは困難に
・ガバナンスの欠如
使用される言語やフレームワークが多くなりすぎるとアプリの保守が困難に
特にログ規則などの横断的機能に対して、何らかの基準を設けたほうが良い
・ネットワークの輻輳と待ち時間
サービス間通信の増加で待ち時間が増える可能性
適切な場合には、非同期通信パターンを使用すること。
・データ整合性
各サービスが自身のデータ永続性に責任を負う必要がある
可能な場合は、結果整合性を採用する
・管理
成熟したDevOpsカルチャーが不可欠
サービス間でのログの相関が課題になることも
・バージョン管理
慎重に設計しないと、過去または将来との互換性に問題が生じることも
・スキルセット
チームに成功のためにはスキルと経験が求められる

ベストプラクティス

・ビジネスドメインを中心にモデル化する
・すべてを分散する。
・設計と構築には、個々のチームが責任を負う
・コードやデータスキーマの共有は避ける
・サービスは疎結合にし、機能の凝集度を高くする。
・二つのサービス間の通信量が多すぎる場合は、結合が密で、凝集度が低い可能性あり
・障害を分離する
・データストレージ
・データを所有するサービス専用にする
・データの種類に応じてストレージを選択
・API
・サービスの内部実装ではなく、ドメインをモデル化する
・ゲートウェイ
・認証やSSLターミネーションなどの横断的な作業を行う
・ドメインの知識を持ち込まない

まとめ

マイクロサービスの特徴と使用されるサービスについて見ていきました。いやー難しい。次回はCQRSアーキテクチャスタイルについてまとめます。お楽しみに!

参考リンク

Azureアーキテクチャセンター
Azureでのマイクロサービスの実装
ドメイン駆動設計は何を解決しようとしているのか[DDD]