クラウド

AzureのOCRサービス「Azure Form Recognizer」入門

  • POST
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モデルです。

オンライン学習サイト「Whizlabs」の紹介

  • POST
オンライン学習サイト「Whizlabs」の紹介 はじめに 本記事では、近年日本国内でも利用するエンジニアが増えてきたオンライン学習サイト「Whizlabs」について紹介する。 Whizlabsとは Whizlabsはクラウド、Java、プロジェクト管理、Linux、CCNAなど、さまざまな分野の学習が可能なオンライン学習サイトである。 AWS、Azure、GCP、Salesforceといったメジャークラウドの認定試験が充実しており、2018年頃から日本国内でも利用するエンジニアが増えてきている。 Whizlabs公式HP サービス開始時期 2000年からサービスを開始しており、2020年現在で約20年実績がある。 国籍 WhizlabsはインドのIT企業。 トレンド 他のオンラインの認定試験学習サイトと比較した結果は下記の通り。 学習コース Whizlabsの学習コースは、以下の3つのコンテンツから構成されている。 Free Tests 無料で利用可能なサンプル問題。 10~15問の程度の問題をお試しで利用できる。 Practice Tests 有料で利用できる模擬試験問題コース。 1コースの価格は日本円で3000円~4000円程度で、 50問~60問程度の模擬試験問題が約5回分ほどある。 50%OFFセールなどが頻繫に開催されるので、よりリーズナブルな価格で購入可能。 Online Course 有料で利用できるオンラインビデオ学習コース。 1コースの価格は日本円で3000円~4000円程度で、 7~9時間ほど。 Whizlabs長所・短所 長所 価格が安い 上述したように他の学習コンテンツに比べ、価格が安い上、 セールが頻繁に行われるので、リーズナブルな価格で利用できる。 1年間全てのコースを利用できるサブスリクションプランがある $199で12ヶ月間、すべてのPractice Testsと、Online Courseを利用可能な年間サブスリクションプランがあるので、ヘビーユーザーにとってはお買い得。 年間サブスクリプション UIがシンプルで分かりやすい 簡素なUIなので、操作をしていて特に困ることはない。 各設問に対する解説付きで、即座に解答を可能。 各設問には全て、簡素ではあるものの解説が付いており、 解答も設問ごとに確認可能。 レポート機能付き 模擬試験問題中に間違った問題や、気になる問題としてマークした問題と解答がレポートで出力され、後から見直しができる。 短所 模擬試験問題のアップデートが遅く、古い問題が残っているケースもある 各認定団体の試験問題は日々アップデートされ、内容が変更されているため、これに対応するため模擬試験問題もアップデートが必要となる。 海外レビューによるとWhizlabsは、 模擬試験問題のアップデートが遅いという指摘があり、利用したコースによっては実試験との乖離がある可能性がある。

Azure Functionsのソケット数をモニタリング

  • POST
はじめに 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ソケット数をモニタリングする方法を紹介しました。

Azure FunctionsにLog4Jの脆弱性の暫定対策を実施

  • POST
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にならない事象

  • POST
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の各サービスは、多数のオプションが用意されているので、要件に応じて、適切なオプションを設定するようにしましょう。

Azure DevOpsのパイプラインからAppServiceのデプロイ

  • POST
Azure DevOpsのパイプラインからAppServiceへのデプロイ はじめに 本記事では、マイクロソフトから提供されているサンプルWebアプリケーションを使って,Azure DevOpsでのリポジトリの作成~パイプラインの作成からAppServiceの デプロイを行うまでの一連の操作を記載する。 AppServiceにWebアプリケーションを作成 以下の手順で、Webアプリケーションを作成。 DebOpsで組織を作成 DevOps用のプロジェクトの作成 リポジトリの作成 サービスコネクションを作成 サンプルプログラムを取得。 以下のサイトから、サンプルプログラムを取得してZIPダウンロードする。 先程クローンしたローカルリポジトリに展開する。 https://github.com/MicrosoftDocs/pipelines-java コミットを行い、その後リモートリポジトリにPushする。 $ git add . $ git commit -m "Sample WebAppを追加" $ git push パイプラインYAML作成 以下のパイプラインを作成する。 trigger: - master variables: # Azure Resource Manager connection created during pipeline creation azureSubscription: '作成したサービスコネクション名を指定' # Web app Type webAppType : 'webAppLinux' # Web app name webAppName: 'sample-web-application' # Environment name environmentName: 'sample-enviroment' # Agent VM image name vmImageName: 'ubuntu-latest' stages: - stage: Build displayName: 'Build stage' jobs: - job: Debug displayName: 'Show debug message' steps: - script: | echo "Subscription : $(azureSubscription)" echo "Web App Name : $(webAppName)" echo "Environment Name : $(environmentName)" echo "Vm Image Name : $(vmImageName)" echo "Pipeline Workspace Name : $(Pipeline.

Azure Administrator対策「Azure オンプレミスのデータの取り込み」

  • POST
Azure Administrator対策「オンプレミスのデータの取り込み」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 Azure Import/Export 物理ディスクドライブから、Azure Blob Storage と Azure Filesに大量のデータをインポートすることができるサービス。 Azureデータセンターにデータをコピーした物理ディスクドライブを送付することで、インポートが行われる。 逆にAzure Blob Storageから物理ディスクにデータを転送し、オンプレミスの拠点に送付することでエクスポートを行うことも可能。 Microsoft 提供のディスク ドライブを使用してデータを転送する場合は、Azure Data Box Diskを使用してデータをAzureにインポート。 https://docs.microsoft.com/ja-jp/azure/storage/common/storage-import-export-service#how-does-importexport-work ディスクドライブ ソリッドステートドライブ (SSD) またはハードディスクドライブ (HDD)に対応。 https://docs.microsoft.com/ja-jp/azure/storage/common/storage-import-export-requirements#supported-hardware 構成 以下の2つの機能が用意されている。 Import/Exportサービス Azure Portalからインポートジョブとエクスポートジョブを作成するGUIツール。 WAImportExportツール インポート、エクスポートを支援するコマンドラインツール。 以下の機能を提供する。 ディスクドライブの配送準備 データをドライブにコピーする ドライブ上のデータを暗号化 インポート作成中に使用されるドライブのジャーナルファイルを生成 エクスポートジョブに必要なドライブの数を特定 データセットCSV インポート、エクスポート対象のファイル、ディレクトリの一覧と、インポート、エクスポート設定を記載したCSVファイル。 https://docs.microsoft.com/ja-jp/previous-versions/azure/storage/common/storage-import-export-tool-preparing-hard-drives-import ジョブ Import/Exportサービスを利用にする場合、‘ Azure Portalなどでインポート、エクスポートジョブを作成する必要がある。 各ジョブは、1つのストレージアカウントに関連付けられる。 インポートジョブ Azure Blobsまたは Azure Filesにデータをインポートするためのジョブ。 手順は以下の通り。 インポートするデータ、必要ドライブ数、インポート先のBlobの場所を決定 WAImportExportツールで、データをディスクドライブにコピー