Azure

Azure Cognitive Search入門 はじめに この記事では、Azure Cognitive Searchの基礎知識について紹介します。 Azure Cognitive Searchとは Azure Cognitive Search は、ストレージ上のファイルなどのデータソースに対して、インデックスを作成し、作成したインデックスによる検索を可能にするサービスです。 インデックスには、ファイルの種類や、ファイルの作成日などのファイルに関するメタデータを格納することができ、 Cognitive Searchを使うと、指定した種類に該当するファイルの絞り込みや、 指定した期間に該当する作成日のファイルの検索などが可能になります。 https://learn.microsoft.com/ja-JP/azure/search/search-what-is-azure-search Azure Cognitive Searchの基本要素 Azure Cognitive Searchは以下の要素から構成されています。 データソース インデクサー インデックス ドキュメント フィールド データソース データソースはAzure Cognitive Searchで検索対象となるデータが格納されている場所を指します。 具体例としては、Azure SQL Database、Azure Cosmos DB、Azure Blob Storageなどのデータストレージサービスが該当します。 インデクサー インデクサーはデータソースからデータを読み取り、それをインデックスに格納する役割を持つものです。 インデックス インデックスはデータソースから取得したデータを効率よく検索できる形式で格納したもののことです。 ドキュメント ドキュメントはインデックス内で格納されているユニークな個々のレコードを指します。 各ドキュメントは一連のフィールドとその値から構成され、通常はJSONオブジェクトとして表現されます。 フィールド フィールドはインデックス内の各ドキュメントが持つ属性を指します。 データベースでいうカラムに該当するものです。 Search Explorer Search Explorerは、Azure portalからAzure Cognitive Searchに検索クエリを実行することができる機能です。 Search Explorerは、Cognitive Searchにインデックスを作成すると自動的に利用できるようになります。 Search Explorerを使うことで、クエリのテストや、インデックス内のドキュメントの確認をすることができます。 https://learn.microsoft.com/ja-jp/azure/search/search-explorer 検索の種類 Azure Cognitive Searchでは以下のような様々な種類の検索をサポートしています。

Azure Cognitive Searchクエリリファレンスガイド はじめに この記事では、Azure Cognitive Searchのクエリの使い方について紹介します。 Azure Cognitive Searchとは Azure Cognitive Search は、ストレージ上のファイルなどのデータソースに対して、インデックスを作成し、作成したインデックスによる検索を可能にするサービスです。 インデックスには、ファイルの種類や、ファイルの作成日などのファイルに関するメタデータを格納することができ、 Cognitive Searchを使うと、指定した種類に該当するファイルの絞り込みや、 指定した期間に該当する作成日のファイルの検索などが可能になります。 https://learn.microsoft.com/ja-JP/azure/search/search-what-is-azure-search クエリパラメータ Azure Cognitive Searchでは、検索クエリの実行時にクエリパラメータを渡すことで、検索時に挙動を変更することができます。 クエリパラメータは以下のようなものがあります。 queryType searchMode search searchFields https://learn.microsoft.com/ja-jp/azure/search/search-query-overview queryType queryTypeはクエリのパーサーを設定します。 以下の値が指定できます。 simplefull : 既定のクエリパーサー、単純なフルテキスト検索に最適 full : 正規表現、近接検索、あいまい検索、ワイルドカード検索などの高度なクエリに使用する semantic : セマンティック検索用に設定 searchMode Azure Cognitive SearchのsearchModeパラメータは、検索クエリの動作を指定することができます。 searchModeにはanyとallの2つの値を指定することができます。 デフォルトのsearchModeはanyです。 それぞれのモードは以下のような動作を持ちます。 any このモードを指定すると、検索クエリに含まれる単語のいずれかが存在するすべてのドキュメントを検索します。 # キーワードのいずれかを含むドキュメントを表示 search='キーワード1 キーワード2'&searchMode=any all このモードを指定すると、検索クエリに含まれるすべての単語が存在するドキュメントを検索します。

MicrosoftのAIサービスまとめ はじめに この記事では、AzureやMicrosft 365などMicrosoftが提供しているAIサービスについて紹介します。 Azure AI Service Azure AI Serviceは、事前構築済みのAIモデルを利用することができるAzureのAI系のサービスの総称です。 Azure AI Serviceには以前Cognitive Services および Azure Applied AI Services と呼ばれていたものすべてが含まれています。 https://learn.microsoft.com/ja-jp/azure/ai-services/what-are-ai-services Azure OpenAI Service Azure OpenAI Serviceは、自然言語処理を行うAIモデルをAPIを介して提供するサービスです。 Azure OpenAI Serviceで利用するAIモデルは、OpenAI 社(米)によって開発されたOpenAI APIがもとになっており、 OpenAI API同等のAIモデルを、APIを介して利用することができます。 Open AIで提供されているAIモデルとして以下のようなものがあります。 GPT-4 : ChatGPTで利用されている自然言語を理解、生成するモデル Embeddings : 埋め込み (ベクトル表現) を生成するモデル　※2023/08/05時点で日本では未提供 DALL-E : テキストから画像を生成・編集するモデル ※ 2023/08/05時点で日本では未提供 https://learn.microsoft.com/ja-jp/azure/ai-services/openai/overview 料金 GPT-4 プロンプト (1,000 トークン当たり) 完了 (1,000 トークン当たり) 8K コンテキスト $0.

Azure VMのyumで「Failed to download metadata for repo ‘rhel-8-for-x86_64-baseos-eus-rhui-rpms’」が発生する場合の対応 はじめに Azure VMにおいて、yumコマンド実行時にFailed to download metadata for repo 'rhel-8-for-x86_64-baseos-eus-rhui-rpms'というエラーが発生することがあります。 本記事では、上記のエラーの内容と対処法について紹介します。 エラーの内容 Azure VM上でyum installやyum updateなどを実行した際に以下のエラーが発生することがあります。 Error: Failed to download metadata for repo 'rhel-8-for-x86_64-baseos-eus-rhui-rpms': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried このエラーメッセージは、rhel-8-for-x86_64-baseos-eus-rhui-rpmsからreponmd.xmlのダウンロードに失敗したということを示します。 rhel-8-for-x86_64-baseos-eus-rhui-rpmsとは rhel-8-for-x86_64-baseos-eus-rhui-rpmsは、RHUIを採用したRed Hat Enterprise Linux 8の向けのパッケージ管理システムのことで、yumを使ってVMにパッケージソフトをインストールする際に利用されます。 RHUI Red Hat Update Infrastructure (RHUI) とは、RHEL用のパッケージの配信することができる仕組み(フレームワーク)のことです。 通常、OSがRHELの場合、yumでパッケージをインストールするときは、Red Hatの公式リポジトリからパッケージを取得します。 しかし、セキュリティ上の要件やネットワークの制約などの理由から、インターネットへの直接アクセスを制限する必要があるケースもあります。 このような場合、RHUIを使用することで、Red Hat社がホストしているパッケージリポジトリを自社のプライベートクラウド内のミラーリングリポジトリにクローンし、内部ネットワークでのアクセスを可能にします。 Microsoftなどのクラウドプロバイダーにおいても、RHUIを使用しており、Red Hatがホストするリポジトリをミラーリングし、ミラーリングした独自のリポジトリからAzure VMにパッケージを配信しています。 repomd.xml repomd.xmlは、リポジトリメタデータを示し、yumなどのパッケージマネージャーがリポジトリ内のパッケージ情報を取得するために使用されるXML形式のファイルです。 今回のエラーでは、Microsoftから提供しているパッケージ管理システムであるrhel-8-for-x86_64-baseos-eus-rhui-rpmsから、リポジトリのメタデータがであるrepomd.xmlがダウンロードできないため、 yumでパッケージのインストールや、アップデートができずエラーになっています。 エラーの原因と対応 Azure公式ドキュメントによると、Azure RHUI証明書は通常、2年ごとに期限切れになります。

Azure Active Directoryで認証するJavaアプリケーションが作れるライブラリ「Spring Cloud Azure」を紹介 はじめに Azureでは「Azure Active Directory (Azure AD) 」とJavaライブラリ「Spring Cloud Azure」を使うことで、Azure ADに登録されているユーザで認証を行うWEBアプリケーションの作成を行うことができます。 この記事では「Spring Cloud Azure」について紹介します。 Spring Cloud Azure Springは、VMwareが開発したJava言語のWEBアプリケーション開発に必要な機能を提供するフレームワークです。 Spring Cloud Azureは、AzureのサービスとSpringのシームレスな統合を提供するオープンソースプロジェクトです。 https://microsoft.github.io/spring-cloud-azure/current/reference/html/index.html#spring-security-support https://docs.microsoft.com/ja-jp/azure/active-directory/develop/quickstart-register-app Spring Cloud AzureでのAD認証 Spring FramworkにはSpring Securityというログイン認証やCSRF対策をフレームワークが含まれています。 Spring Cloud AzureではAzure用に拡張されたSpring SecutiryでOAuth2.0での認証を行います。 以下にAD認証のシーケンスを記載しています。 https://microsoft.github.io/spring-cloud-azure/current/reference/html/index.html#spring-security-support https://spring.pleiades.io/spring-security/site/docs/current/api/org/springframework/security/config/annotation/web/builders/HttpSecurity.html Azure ADへのアプリケーション登録 WEBアプリケーションでAzure ADでの認証を行うには、AzureポータルでAzure ADに対象のアプリケーションの登録と、クライアントシークレットの作成を行います。 アプリケーション登録 Azure ADメニューからAzure ADを選択します。 表示名 : 任意のアプリケーション名を入力 サポートされているアカウントの種類 : 今回は任意の組織ディレクトリ内のアカウントを選択します リダイレクトURI : 省略可能。省略した場合は https://WEBアプリホスト名/login/oauth2/code/azure になります クライアントシークレット登録 Azure ADに登録したアプリの「証明書とシークレット」からクライアントシークレットを追加します。 説明 : 任意 有効期間 : 今回は2年を設定します 作成されたクライアントシークレットの値を控えます。(※再表示はできません) その後、クライアントID(アプリケーションID)および、テナントIDを確認し、控えます。

AzureのOCRサービス「Azure Form Recognizer」入門 はじめに Azureには、Azure Cognitive ServicesとAI機能をWeb APIして提供するサービスがあります。　本記事では、Azure Cognitive Servicesのうち、OCRサービス「Azure Form Recognizer」の使い方について紹介します。　Azure Cognitive Servicesとは Azure Cognitive Servicesは、視覚、音声、言語、決定、検索の5ジャンルからなるAI機能をWeb APIとして利用できるAzureのサービスです。 https://azure.microsoft.com/ja-jp/services/cognitive-services/#overview Azure Form Recognizerとは 請求書、レシート、名刺などのドキュメントから文字情報を取得するAzure Cognitive ServicesのOCR機能の一つです。 Azure Form RecognizerのAPIを実行すると、リクエスト時で渡されたPDFファイルなどのドキュメントのURLを解析し、 解析したテキスト情報をHTTPレスポンスとして返します。 https://docs.microsoft.com/ja-jp/azure/applied-ai-services/form-recognizer/ もう一つのOCRサービス「Azure Computer Vision」 Azure Cognitive ServicesのOCRサービスには、Computer Visionというものもあります。 Computer Visonは画像やビデオのコンテンツを分析するAIサービスです。 こちらもOCRの機能がありますが、画像内のオブジェクトの検出、画像の説明の生成、顔認識などOCR以外にも、画像に対してより幅広いことができます。 PDFファイルの上の表にあるテキストの取得や、指定したテキストを取得したい場合は、Azure Form Recognizerの方が適しています。 https://stackoverflow.com/questions/71071309/ai-form-recognizer-vs-cognitiveservices-computervision https://azure.microsoft.com/ja-jp/services/cognitive-services/computer-vision/#overview https://www.alirookie.com/post/azure-ocr-with-pdf-files Azure Form Recognizerの機能 Azure Form Recognizerは、機能で、次のサービスで構成されています。 Layout API 事前構築済みモデル カスタムモデル Layout API Azure Form RecognizerのAPIを実行することで、ドキュメントから、テキストや、テーブルの構造、テキスト、バウンディングボックスの座標と共にドキュメントから抽出します。 事前構築済みモデル(Prebuilt Model) 事前構築済みモデルは請求書、レシート、名刺などMicrosoftが事前に用意している特定のドキュメント専用のAIモデルを使用して、フォームを解析する機能です。 カスタムモデル カスタムモデルは、ユーザが独自に作成することができるAIモデルです。

はじめに Azure Functionsには、同時に利用できるTCPソケット数に上限数が設定されています。 そのため、同時利用するソケット数を抑えるようにアプリを実装していないと、処理量が増えた際に、 ソケットが枯渇してしまう可能性があります。 この記事では、Functionsが利用しているソケット数をモニタリングする方法を紹介します。 Functionsのソケット数の上限 従量課金プランのFunctionsの場合、送信接続数は、インスタンスあたり600アクティブに設定されています。 上記のように同時接続数に上限があるので、Functionsアプリケーションを開発する際は、 利用後終わったソケットは開き放しにせずに、すぐにクローズするなどベストプラクティスに基づいた実装が必要です。 https://docs.microsoft.com/ja-jp/azure/azure-functions/manage-connections?tabs=csharp https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-best-practices Functionsのソケット数をモニタリング ソケット数は、Azureポータルを使って、Functionsの診断設定や、Azure Monitorのメトリックからモニタリングできます。 取得できる接続数として、以下の2つがあります。 Connections : Functionsごとの接続するの瞬間値 TCP Established ： 仮想マシン単位(App Service Plan)の瞬間値 Connections Connections Azure Monitor の Connectionsから取得できる項目です。 Functionsの関数アプリが利用している接続数をモニタリングできます。 TCP Established App Service Planの接続上限を超過する可能性がございます。 https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-monitoring おわりに 本記事ではAzure Functionsでの同時に利用できるTCPソケット数をモニタリングする方法を紹介しました。 I

Azure FunctionsにLog4Jの脆弱性の暫定対策を実施 はじめに 2021年12月10日に発覚したJavaのログ出力ライブラリ「Apache Log4j」にて、深刻な脆弱性「CVE-2021-44228」があることが発覚しています。 https://milestone-of-se.nesuke.com/sv-advanced/sv-security/cve-2021-44228-log4shell-logjam/ 上記について、暫定的な回避策として、以下の2点が公開されています。 Log4j バージョン 2.10 およびそれ以降 Log4j を実行する Java 仮想マシンを起動時に「log4j2.formatMsgNoLookups」という JVM フラグオプションを指定する 環境変数「LOG4J_FORMAT_MSG_NO_LOOKUPS」を「true」に設定する Log4j バージョン2.10 より前 JndiLookup クラスをクラスパスから削除する https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/ 通常の物理サーバまたは、仮想サーバ上でJavaアプリケーションを動作させているケースと違い、 サーバレスのAzure Functionsの場合、どのように設定すればいいのか分からないという方もいるかと思われます。 本記事では、Azure Functions に対して、上記の1.Log4j バージョン 2.10 およびそれ以降への回避策を設定する方法を紹介します。 Azure Functionsのアプリケーション設定に環境変数を追加 Azure Functionsには、アプリケーション設定という、Functions内で利用することができる環境変数を定義することができる項目があります。 以下のAzure CLIコマンドを実行することで、Azure Functionsのアプリケーション設定に変数を追加することができます。 az webapp config appsettings set -g "リソースグループ名" -n "関数アプリ名" --settings JAVA_OPTS='-Dlog4j2.formatMsgNoLookups=true' az webapp config appsettings set -g "リソースグループ名" -n "関数アプリ名" --settings LOG4J_FORMAT_MSG_NO_LOOKUPS='true' おわりに 本記事では、Azure FunctionsにLog4Jの脆弱性の暫定対策を設定する方法を紹介しました、

Service Bus Queues Triggerのメッセージ処理順がFIFOにならない事 はじめに Service Bus Queues Triggerを用いたAzure Functionsにおいて、メッセージ処理順がキューに送信された順番にならず、FIFOにならないケースがあります。 本記事では、Service Bus Queues Triggerのメッセージ処理順がFIFOにならない事象と対策について、ご紹介します。 Service Bus Queues Triggerのメッセージ処理順がFIFOにならない原因 Service Bus TriggerのFunctionsはPeek&LockというモードでService Busからのメッセージの受信とロックを行います。 https://docs.microsoft.com/ja-jp/azure/service-bus-messaging/message-transfers-locks-settlement#peeklock Service Busを利用していると際に、Service BusとFunctionsからのネットワークが切断されたりすると、 Message processing errorというエラーログが出力されます。 https://stackoverflow.com/questions/65999984/azure-function-v3-net-core-3-1-servicebustrigger-message-processing-error-act Peek&Lockモードの場合、特定のスレッド/プロセスにて受信対象のメッセージのロック中に Message processing errorが発生すると、次回起動時に当該メッセージがロックされたままになっているために、後続のメッセージを先に受信してしまいます。 Service Busのセッションを用いた対策 上記のケースへの対応として、Service Busにはセッションという機能があります。 https://devblogs.microsoft.com/premier-developer/ordering-messages-in-azure-service-bus/ https://docs.microsoft.com/ja-jp/azure/service-bus-messaging/message-sessions 上記のドキュメントの内容を要約すると、以下のような挙動になるものと思われます。 Service Busのキューを作成する際に、セッションを有効にして作成すると、送信側はメッセージをキューに挿入する際に、セッションIDを付与することが可能になります。 受信側のFunctionsでService Bus Triggerの属性 IsSessionsEnabled を有効にすると、セッションが付与されたメッセージを受信することが可能になります。 https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-bindings-service-bus-trigger?tabs=csharp#configuration セッションを有効にするとFunctionsはメッセージ受信時に、セッションIDが同じメッセージを全て、排他ロックします。 Message processing error などエラーが発生した場合は、メッセージのロックを解除して、同じメッセージを受信するため、FIFOを維持することができます。 おわりに この記事では、Service Bus Queues Triggerのメッセージ処理順がFIFOにならない事象と対策について、ご紹介しました。 Azureの各サービスは、多数のオプションが用意されているので、要件に応じて、適切なオプションを設定するようにしましょう。 本サイトへのご意見、お問い合わせなどありましたらこちらからご連絡下さい。 お問合せフォーム I

はじめに 以下のフォーラムの投稿にあるようにAzure Functions(Windows OS)でSDKに用意されているAzure SDK標準のロガーを使用せずに、日本語文字を標準出力するとApplication Insightで文字化けする事象が発生するケースがしたので、本記事では原因について、紹介します。 https://social.msdn.microsoft.com/Forums/ja-JP/9febb20c-f348-4554-af11-93f5dcfb587f/azure?forum=windowsazureja 文字化けの原因 日本語環境に設定された Windows OSの場合では MS932 (Shift-JIS の一種) という文字コードが使われます。 Azure 上では CP1252というラテン文字用のエンコーディングが使われますが、CP1252では日本語が表現できないため、文字化けしてしまいます。 また、AzureポータルのFunctionsの[Debug Console] 、Application Insightsは Shift JIS での表示に対応していないため、日本語をログ出力すると、文字化けしてしまうことになります。