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]
Microsoft Azure メンテナンス通知
こんにちは、kc-dreamです。
今回は、Microsoft Azureでのメンテナンスメールについてご紹介していきます。
メンテナンス通知について
Azureでは、年に一度程度の頻度で、仮想マシンの再起動を伴うメンテナンスが計画しております。
特に何月、と決定されているわけではなく、時期は不定期ですが、通常行われる VM 再起動を伴わないメンテナンスで行えないような、ハードウェアの BIOS・ファームウェア アップデートや、基盤側の OS などソフトウェアの大幅な更新といった目的で行われます。
Azureでは、メンテナンスや大きな障害等がある際にメール通知を行える仕組みがあります。
※各サブスクリプション毎に設定が必要
本記事では、この仕組についてご紹介していきます。
通知の種類
大きく分けて4種類あります。
(1) サービスの問題
ユーザーに今すぐ影響を及ぼす Azure サービスの問題。
(2) 定期的なメンテナンス
お使いのサービスの可用性に将来影響を及ぼす可能性のある今後のメンテナンス。
(3) 正常性に関する勧告
ユーザーが注目する必要のある Azure サービスの変化。 Azure の機能が非推奨となるタイミングや、使用量のクォータを超えた場合に関する例も含まれます。
(4) リソース正常性
Azureサービスの問題でリソースが影響を受けている際に確認いただくことが可能となります。
※2019/07/29時点ではプレビューとして提供
設定方法
(1)~(3)の設定方法
AzurePortalより、[モニター]から[Service Health]を選択
[サービス正常性アラートの作成]を選択
必要事項を入力し、作成することで通知が可能
(4)の設定方法
AzurePortalからの設定は現時点ではできません。
本記事では、詳細を省かせていただきますが、下記リンクを参考にして頂ければ簡単に設定可能です。
※本機能は2019/07/29時点ではプレビューとなっております。
Resource Manager テンプレートを使用して Resource Health アラートを構成する
参考情報
Azure Monitor を使ってメンテナンス通知を受け取る
[2018/3/26更新] 新規リリースされた “Azure Monitor” 機能を使って、利用中のリソースに影響しうるメンテナンスや障害のメール通知を受け取る
サービス正常性
Azure Resource Health の概要
Resource Manager テンプレートを使用して Resource Health アラートを構成する
Resource Health は Azure の状態や Service Health ダッシュボードと何が違うのでしょうか。
サービス通知のアクティビティ ログ アラートを作成する
Azure Heat Map の使い方
はじめに
今回は、Azure Heat Map について紹介したいと思います。
Microsoft の社員が作成したこちらのサイトを見れば、各サービスのアップデート状況やリージョン毎の利用可能状況などが一目で分かると思います。
本サイトについては、こちらからどうぞ：Azure Heat Map
Azure Heat Map について
What is Azure Heat Map ?
Heat Map とは、大まかには色の強弱や濃淡をつけることで、様々な情報を可視化しやすくしたもののことです。Azure Heat Map では、その内容に応じて色の強弱や濃淡やをつけることで、ユーザに Azure が提供しているサービスの状態や状況を一目で理解できるようになっております。
ちなみにこちらのサイトは Microsoft の社員が作ったもので、Microsoft のサービスや商品ではありませんので、よろしくお願いします。
Azure Heat Map
こちらは、Azure Heat Map のサイトのトップページです。最初にこのサイトに飛ぶと、こちらが表示されます。
ここでは、Azure のサービスを機能毎に色分けしておりますが、そこに色の強弱ををつけることでサービスのアップデート状況をユーザに提供しております。
右上のタブを選択すると、以下の情報を確認することができます。
・All Updates Equal：直近6ヶ月以内にアップデートされたサービスほど濃い色で表示
・Latest More Important：直近１ヶ月以内にアップデートされたサービスほど濃い色で表示
・Only Last 7 days：直近7日以内にアップデートされたサービスのみ濃い色で表示（直近のものは白枠で表示）
・Heat ALL Up：アルファベット順にそれぞれのサービス毎に並び替え（アップデート状況は別）
また、サービスにカーソルを合わせることで、以下の情報を知ることが出来ます。
・アップデート回数
・直近6ヶ月以内のアップデート回数
・直近1ヶ月以内のアップデート回数
・最新更新日
・最新更新内容
Azure Changes Highlights
こちらは、 Azure サービスを直近3ヶ月以内にアップデートしたトピック毎に分けて表示しております。
以下のアップデート項目に分けて、表示しております。
・Region & Datacenters：サービス利用地域関連のアップデート
・Pricing & Offerings：料金関連のアップデート
・Retirements：サービスの全体、または部分的な廃止関連のアップデート
・Security：セキュリティ関連のアップデート
・Compliance：コンプライアンス関連のアップデート
・Open Source：オープンソース関連のアップデート
・SDK & Tools：SDK やツールのアップデート
・Services：サービス関連のアップデート
・Features：機能面関連のアップデート
サービスにカーソルを合わせることで以下の情報が分かります。
・そのサービスの分野
・最新更新日
Azure SLA Board
こちらは、Azure の SLA (Service Level Agreement) を表したものになります。
サービス毎に、それぞれの SLA を見分けられるようになっております。
サービスにカーソルを合わせることで、以下の情報が分かります。
・SLAの状態
・最終更新日
・バージョンの状態
Azure Region Scope
リージョン毎にサービスの使用可能状況を見ることが出来ます。
こちらのページでは以下の情報が得られます。
・Current Region：選択地域のサービスの使用可能状況
-Non-Regional：どの地域でも同じ様に利用可能なサービス
-Generally Available：選択地域で基本的に利用可能なサービス
-In Preview：今後、利用可能となる予定
-Futer Availability：将来的には利用可能となる予定
・Compared To：Current Region と比較した場合のそのリージョンにおける Azure サービスの利用可能状況
また、リージョン同士で利用可能なサービスの状況を比較することもできます。
・Ahead：Current Region が Compared To に比べて優れているサービス（アップデート状況や利用可能状況などにおいて）
・Behind：Current Region が Compared To に比べて劣っているサービス（アップデート状況や利用可能状況などにおいて）
Azure Services Menu
Azure サービスがクラウド環境でどれだけ親しまれて利用されているかをメニュー形式で表したものです。
・Starters：IaaS や基本的なサービスなど
・Main Dishes：PaaS やマネージドサービスなど
・Desserts：特徴的なサービスなど
おわりに
Azure Heat Map の紹介は以上となります。
こちらのページを使えば、Azure サービスの最新状況や利用可能状況がひと目で分かるので、ぜひ一度、このサイトを見て頂ければと思います。
Azureアーキテクチャガイドまとめ 3 【Webキューワーカー】
はじめに
Azureクラウドアプリケーションアーキテクチャガイドより、7つあるアーキテクチャスタイルの一つ、Webキューワーカーに関してまとめます。
※前回記事
Azureアーキテクチャガイドまとめ 1 【はじめに】
Azureアーキテクチャガイドまとめ 2【N層】
概要
このアーキテクチャスタイルのコアコンポーネントは以下の3点。
クライアント要求にこたえるWebフロントエンド
バッチジョブを実行するワーカー
もしくはCPUを集中的に使用するタスク
非同期メッセージキュー
これらに加えて、一般的に以下のコンポーネントが組み込まれます。
システムの要件にフィットする範囲で、特定の機能を分離し、各種マネージドサービスを組み合わせる、というイメージです。
1つまたは複数のデータベース
DB読み取り高速化のためのキャッシュ
静的コンテンツを提供するCDN
構成図は以下の通り。
以下のような特徴を持つアプリケーションに適しています。
・比較的単純なドメインのアプリケーション
・時間のかかるワークフローやバッチ操作があるアプリケーション
利点
・理解しやすい比較的単純なアーキテクチャ
・展開と管理の容易さ
・フロントエンドとワーカーは独立に拡張可
・懸念事項の明確な分離
課題
情報の入出力が多いコンポーネントでは、システムの要望に応じてコードが肥大化しやすい傾向があります。
・フロントエンドとワーカーが、複数の機能を持った単一のコンポーネントになりやすい (= モノリシックコンポーネント)
・フロントエンドとワーカーがデータスキーマやコードモジュールを共有している場合、隠れた依存関係が存在する可能性あり
ベストプラクティス
各マネージドサービスでベストプラクティスが用意されています。
・適切であれば、複数のストレージ技術を混在させる
・以下のベストプラクティス設計に準ずる
API 設計のベストプラクティス
自動スケールのベストプラクティス
キャッシングのベストプラクティス
CDN のベストプラクティス
ジョブに最適なデータストアの使用 データのパーティション分割のベストプラクティス
対応するAzureサービス
核となるサービスは、App Serviceです。
WebjobsはApp Serviceのサービスの一つで、ワーカーの役割を果たします。これらをQueue StorageもしくはService Busでつなげる形です。
アイコンと概要をまとめます。
先ほどの構成図にあるアーキテクチャを組んだ場合、以下のような構成になります。
※ 図ではDocumentDBになっていますが、現在はCosmosDBとしてリニューアルされていますのでご注意を。
まとめ
Webキューワーカーの特徴と、使用されるサービスについて見ていきました。次回はCQRSについてまとめます。お楽しみに！
参考リンク
Azureアーキテクチャセンター
Azureクラウドアプリケーションアーキテクチャガイド ダウンロードページ