Azure を使用したソリューションを設計する
アプリケーション アーキテクチャを作成するには、幅広い機能の要件と機能以外の要件を理解し、それらの要件を、それらの要件に対応できるツール、テクノロジ、サービスと組み合わせる必要があります。
バス乗車のシナリオでは、いくつかの主要な要件があります。
- バスの現在位置をリアルタイムで監視するための Web サイト
- バスが近くに来ているときの通知
- デプロイとスケーリングの自動化
このシナリオと、さまざまな Azure サービスを使用してソリューションを設計する方法について詳しく説明します。
バスのリアルタイム データを取得する
多くの都市では、General Transit Feed Specification (GTFS) を使用して公共交通機関のデータを提供しています。これは、GTFS リアルタイム リファレンス v2 (GTFS-RT) と呼ばれるリアルタイム フィードもサポートしています。 このフィードは、次のサンプル (King County Metro のフィード) のような JSON ドキュメントで構成されます。
{
"id": "1618418866_4318",
"vehicle": {
"trip": {
"trip_id": "49195161",
"direction_id": 0,
"route_id": "100001",
"start_date": "20210414",
"schedule_relationship": "SCHEDULED"
},
"vehicle": {
"id": "4318",
"label": "4318"
},
"position": {
"latitude": 47.64524,
"longitude": -122.370171
},
"current_stop_sequence": 228,
"stop_id": "2010",
"current_status": "IN_TRANSIT_TO",
"timestamp": 1618418841
}
},
このようなフィードが利用可能であることがわかったので、次に知る必要があるのは、バスが近くに来ているときの通知方法です。そうすれば、時間通りにバスに乗車できるようにバス停に向かうことができます。 そのためには、目的のバス停の手前にある 2 つのバス停のジオフェンスを作成できます。 これにより、バスがジオフェンスに入るか、出るときに通知を受け取ることができます。 そのタイミングで通知を受け取ることができれば、バスの現在位置を地図で確認する必要もなくなります。 通知を受け取ったら、いつ出発すればよいかがわかります。
Azure サービスを使用してソリューションを設計する
シナリオと理想的なソリューションに基づき、考えられるアーキテクチャを次に示します。
このアーキテクチャでは、作成する必要があるコードの量を最小限に抑え、Azure で提供されるスケーラビリティとインフラストラクチャの利点を最大限に活用するために、いくつかの異なるサービスが使用されています。
Well-Known Text (WKT) は、マップ上のベクター ジオメトリ位置を表すプレーン テキスト マークアップ言語です。 WKT は、空間データをテキスト形式で表すために使用される Open Geospatial Consortium (OGC) 標準です。 ほとんどの OGC 準拠システムは、Well-Known Text に対応しています。
ここでは、選択するソリューション コンポーネントの概要と選択する理由を把握します。 次に、このモジュールではデータベース サービスに注目します。
Azure SQL Database を使用してデータを格納および処理する
Azure SQL Database は、このシナリオに最適です。 その理由を解明しましょう。
Azure SQL Database はネイティブで JSON をサポートします。これにより、データベースとの間で送受信されるデータを操作するために必要なコードの量を削減することができます。 また、ソリューションの俊敏性が向上し、JSON の柔軟性により、ソリューションの改善も容易になります。 さらに、データの配列を Azure SQL に効率的に渡すことができ、ラウンドトリップを最適化し、待ち時間を短縮できるようになります。
Azure SQL では、地理空間も完全にサポートされます。地理空間データの操作はそれほど簡単な作業ではないため、これは優れた機能です。 完全な機能を備えた地理空間エンジンをデータベース内に配置することで、外部ライブラリとの統合の複雑さを回避できます。 また、たとえば、バスが定義されたジオフェンス内に入っているかどうかを判断するためにデータを移動する必要もありません。 Azure SQL は、Open Geospatial Consortium 標準に準拠しているため、Azure SQL に格納されているデータを OpenLayers などの視覚化ライブラリと簡単に統合できます。
前述の機能は、リレーショナル モデルの堅固な基盤の上に構築されており、最新のアプリケーションの要件を満たすために長年にわたる改善によって進化してきました。 Azure SQL Database は、Hyperscale レベルで最大 100 TB までスケーリングできます。つまり、ストレージを集中的に使用するアプリケーション (大規模なデータベースなど) に使用できます。 Azure SQL Database は、サーバーレス レベル (自動スケーリングおよび一時停止と再開をサポート) を使用する場合は、コスト効率も高くなります。 Azure SQL では、高速の分析クエリを実行するための列ストア インデックス、複雑なオブジェクト リレーションシップ管理を簡素化するグラフ モデル、継続的に改善され、今日の大規模なマルチプレーヤー オンライン ゲームで要求されるもののような最も要求の厳しいワークロードでも処理できる最先端のクエリ オプティマイザーもサポートされています。
Azure SQL を使用すると、Azure Blob Storage アカウントに格納できる静的データ (GTFS 標準で提供される経路情報など) にも簡単にアクセスできます。 Azure SQL の OPENROWSET 関数を使用して、別のサービスを必要とせずにテキスト ファイルからデータをインポートできます。 これにより、ソリューションの複雑さを最小限に抑えることができます。
これらの理由から、Azure SQL Database は JSON および地理空間データを扱うバス乗車アプリのようなアプリケーションに最適ですが、エンジンに組み込みのデータ アクセス機能とプロシージャ機能を活用する必要もあります。 Azure SQL Database サーバーレスは自動スケール要件を満たすのに最適なオプションです。このオプションを使用すると、多くの利用者がバスに乗車しようとしている日中の混雑する時間帯をアプリケーションで処理できます。 さらに Azure SQL Database では、デプロイの自動化を簡素化する継続的インテグレーションと継続的デリバリーまたは継続的デプロイ (CI/CD) テクノロジ (Azure DevOps や GitHub Actions など) もサポートされています。
Azure Functions を使用して API サービスをビルドする
GTFS フィードにアクセスして利用し、バスがジオフェンスに入った場合にユーザーに通知し、Web アプリケーションにデータを提供するには、API が必要です。 Azure Functions は、そのシンプルさとサーバーレス アーキテクチャを理由に、最適なサービスとして選ばれています。 Azure Functions では、サーバーレスという性質によって、必要なものに自動スケーリングされ、ほとんどすべてのインフラストラクチャの側面を Azure Functions に任せることができるため、これは優れたサービスです。 Azure Functions ではさまざまな言語がサポートされているため、好みの言語を選択することも、純粋なマイクロサービス アプローチに従って、作業中のタスクに最適な言語を選択することもできます。
Azure Logic Apps を使用して通知を送信する
バスがジオフェンス内に入っており、バス停に向かう必要があるという通知を受け取るための Azure のオプションの 1 つは、Azure Logic Apps を使用することです。 Azure Logic Apps には、他のサービスと統合できるように、多数のコネクタが用意されています。 たとえば、Azure Logic Apps を使用して、SMS メッセージを送信したり、Outlook または Gmail アカウントから電子メールを送信したりすることができます。 Azure Logic Apps の優れている点は、ローコードまたはノーコードのプラットフォームであるため、バスに乗車するための通知サービスを設定するのが簡単で、数回のマウス操作だけで行えることです。
Azure Static Web Apps を使用して Web アプリケーションをホストする
地図上でジオフェンスとバスの位置を表す地理空間データを視覚化するには、よく知られている jQuery と OpenLayers ライブラリを使用して静的な HTML ページを作成することができます。 静的ページでは、別の Azure 関数によって提供されるサーバー側の REST API からデータを取り込む必要があります。 視覚化ページを機能させるにはクライアントとバックエンドの両方の部分が必要であるため、Azure Static Web Apps を利用できます。 Azure Static Web Apps は、Azure Web Apps と Azure Functions の機能を組み合わせただけではなく、GitHub Actions との統合も組み込まれているため、ソリューションの開発とデプロイを簡単に行うことができます。
GitHub Actions を使用してデプロイを自動化する
既に説明したとおり、完全なソリューションは、リアルタイム フィードからデータをプルするバックエンド サービス、データを格納、処理、提供するデータベース、静的 HTML ファイルと REST API エンドポイントで構成されるフロントエンドの視覚化ソリューションなど、複数の可動部分で構成されます。 GitHub Actions を介して CI/CD パイプラインを使用することにより、変更をコミットするたびに、GitHub と Visual Studio Code を介してすべての部分のデプロイを自動化できます。 データベースの変更がある場合は、Azure Functions および Azure Static Web Apps の変更と共に、完全に自動化され、調整された方法でデプロイされます。