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

はじめに

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

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

まずはビッグデータが発生した背景と、それを取り巻く近年の流れを整理します。
以下に挙げる変化により、そのままの形では解析に要する計算資源の確保が現実的でないほどに大きなデータセットの蓄積が可能になりました。
・ストレージコストの低下
・データ収集手段の増加
・データ収集のスピードアップ
これに応じて、データを分割し、並列処理を行い、最終的にそれらを統合して分析結果を出力する、というアーキテクチャの要請が強くなっていきます。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]


LogAnalyticsのデータ取得時間の調査方法

こんにちは、kc-dreamです。
前回の記事に引き続き、LogAnalyticsについての補足を書いていきます。

のデータ取得時間の調査方法

LogAnalyticsは各種環境のデータを収集/分析するためのサービスです。
Azure基盤で各種データを収集するので、タイミングによってはデータの取得までに時間がかかることがあります。
例えば、LogAnalyticsを使用してアラートを設定している場合、データの取得時間及びしきい値によってアラートが発報してしまう可能性があります。
そういった場合にデータ取得にかかった時間を調べるためのqueryが用意されているので、本記事で紹介します。

SampleQuery

[crayon-5e4b33cce168c141363104/]

上記はHeartbeatのデータ取得にかかった時間を調べるSampleQueryです。

[crayon-5e4b33cce16a1775646533/]

取得時間は[ingestion_time()]から[TimeGenerated]を差し引いた値からデータの取り込みに要した時間を算出可能です。

参考情報

Azure Monitor でのログ データ インジェスト時間
Azure LogAnalytics 概要についてまとめてみた
Azure LogAnalyticsでWindowsServerを監視してみた


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:直近1ヶ月以内にアップデートされたサービスほど濃い色で表示
・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です。
WebjobsApp Serviceのサービスの一つで、ワーカーの役割を果たします。これらをQueue StorageもしくはService Busでつなげる形です。
アイコンと概要をまとめます。

先ほどの構成図にあるアーキテクチャを組んだ場合、以下のような構成になります。
※ 図ではDocumentDBになっていますが、現在はCosmosDBとしてリニューアルされていますのでご注意を。

まとめ

Webキューワーカーの特徴と、使用されるサービスについて見ていきました。次回はCQRSについてまとめます。お楽しみに!

参考リンク

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


Azureアーキテクチャガイドまとめ 2【N層】

はじめに

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

概要

N層アーキテクチャと呼ばれるもの中で代表的なものが、以下の三層アーキテクチャです。
・プレゼンテーション層
・中間層
・データ層
下記の例では、中間層が二つ(Middle Tier 1 / Middle Tier 2)あり、別々の機能を持たせています。名称はとっつきにくいですが、よく見るような一般的な構成です。

以下のような特徴を持つアプリケーションに適したアーキテクチャスタイルです。
単純なWebアプリケーション
・オンプレアプリをAzureに最小限のリファクタリングで移行
・オンプレアプリとクラウドアプリの統一的開発

特徴は以下の通り。

一般的なIaaSアプリとしての実装
・レイヤー
-論理レイヤーと物理レイヤーに分断し、責任を分離し、依存関係を管理する
-上位レイヤーは下位レイヤーのサービスを利用可。逆は不可
・2種のアーキテクチャ
-クローズドレイヤー (直下のレイヤーのみを呼び出し可)
-オープンレイヤー (下のすべてのレイヤーを呼び出し可)

利点

・オンプレ/クラウド間の移植性が高い
・エンジニアにとって学習コストが低い
・異種混在環境(Windows/Linux)への適合性が高い

課題

・各機能の独立展開不可
管理コストが高い
・大規模システムのセキュリティ管理が難しい場合あり
・中間層が無意味に待ち時間を増やす場合あり

ベストプラクティス

スケーラビリティ、信頼性、セキュリティの各層の境界としてサブネットを活用し、以下のマネージドサービスを利用する
・キャッシング
・オートスケール
・ロードバランサ
・メッセージング
-各層の分離に非同期メッセージングを使用
・データストレージ
-アクセス制限のため、中間層からの要求だけ許可
-高可用性実現のため、可用性グループを使用

対応するAzureサービス

各層のコンピューティングにVirtual Machineを利用し、マネージドサービスを追加していく形です。アイコンと一緒に覚えてしまいましょう。

まとめ

N層アーキテクチャの特徴と、使用されるサービスについて見ていきました。次回はWebキューワーカーについてまとめます。お楽しみに!

参考リンク

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


Azureアーキテクチャガイドまとめ 1 【はじめに】

はじめに

Azureクラウドアプリケーションアーキテクチャガイド。皆さんご存知でしょうか?
いわば、Azure版のWell-Architectedフレームワークです。非常に示唆に富む内容なので、分からない用語や概念を調べつつ、まとめようと思います。
本稿では、「はじめに」から、第一章「アーキテクトスタイルの選択」の導入部までを扱います。

従来のオンプレ環境と最新のクラウド環境

ご存知の通り、クラウドまわりの技術は急速に進化しています。マイクロサービス、コンテナ、AI/MLなどなど。
流れが早すぎて潮流が読めないなと感じていた折、冒頭に従来のオンプレ環境と"最新の"クラウド環境の比較表を発見。図示します。

何かしら指針がないと沈没しそうです。
さて、本ガイドはどんな内容でしょうか?

"このガイドでは、スケーラブルで回復性と可用性が高いクラウド アプリケーションを設計するための構造化されたアプローチについて解説します。
(本文より抜粋)”

構造化されたアプローチ、いい言葉ですね。詳しく見ていきましょう。

ガイドの構成

ガイドは以下の5つステップで構成されています。
1. アーキテクチャスタイルの選択
2. コンピューティングおよびデータストア用テクノロジの選択
3. Azureアプリケーションの設計 10の原則
4. ソフトウェア品質 5つの柱
5. クラウド設計パターンの適用

ステップ1を行う前に、アーキテクチャの要件の明確化が必要になります。
というより、明確にしないと先に進めないようになっています。
設計後半で要件の見落しに気づいて大幅な手戻りが...なんて場面を回避できます。ついつい技術要素に目が向きがちなので、これはありがたい。

アーキテクチャスタイルの選択

要件の集合からテンプレートを選択というイメージです。合計7パターン。

各スタイルの概要は下記の通り。

用語は聞いたことあっても、具体的に何のことを言っているのかわからない、というのが正直な感想。

制約・課題・利点

それぞれのスタイルの説明に移る前に、なぜこの段階で型にはめる必要があるのかを整理します。
スタイルの選択は、制約をもたらす
各スタイルは、固有の課題を持っている
制約を満たす場合、利点が生まれる
制約、課題、利点の概要と関係性を図示します。

もっとも利点マイナス課題が大きくなるスタイルを見つけることで、最適なアーキテクチャに最短距離で近づくことが出来る、という格好です。

おわりに

次回以降は各アーキテクチャスタイルについて解説します。お楽しみに!

参考リンク

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