こんにちは。 研究開発室の岡田です。
前回のブログでGoogle Meetの仮想背景用のAIモデルをwasm化したTensorflow Lite(TFLite)で動かす方法についてご紹介しました。今回は、この技術の活用先の一つとして、軽量、高速なバーコードスキャナを作成してみたのでご紹介したいと思います。
動作としてはこのような感じになります。様々の向きを向いている複数のバーコードを高速に読み取れています。
続きを読む研究開発室の馮 志聖(マイク)です。 In this blog, I will describe how the wifi positioning system works, and explain the difficulties and solutions that the wifi positioning system will encounter in the iOS system.
Wi-Fi is a family of wireless network protocols, based on the IEEE 802.11 family of standards, which are commonly used for local area networking of devices and Internet access, allowing nearby digital devices to exchange data by radio waves. These are the most widely used computer networks in the world, used globally in home and small office networks to link desktop and laptop computers, tablet computers, smartphones, smart TVs, printers, and smart speakers together and to a wireless router to connect them to the Internet, and in wireless access points in public places like coffee shops, hotels, libraries and airports to provide the public Internet access for mobile devices.
Wi-Fi uses multiple parts of the IEEE 802 protocol family and is designed to interwork seamlessly with its wired sibling Ethernet. Compatible devices can network through wireless access points to each other as well as to wired devices and the Internet. The different versions of Wi-Fi are specified by various IEEE 802.11 protocol standards, with the different radio technologies determining radio bands, and the maximum ranges, and speeds that may be achieved.
IEEE 802 https://en.wikipedia.org/wiki/IEEE_802
Association of Wi-Fi positioning system (WPS) and AR remote instructions system.
This is the previous blog about AR remote instruction.
AR Remote Instructions base on ARKit - フレクトのクラウドblog re:newal
In AR remote instruction, the supporter or the client will have a problem, that is very often unable to find the target location and cannot provide assistance. Almost all locations are indoor environments, such as warehouses or offices.
Therefore, we searched some existing research information to investigate which methods are suitable for find out the target location.
Indoor positioning system (IPS) includes many kinds of methods. And we talk about the Indoor positioning system (IPS) in the previous blog. It explains in detail how to use iBeacon as IPS auxiliary positioning.
https://cloud.flect.co.jp/entry/2021/03/31/101614
The other method name is the Wi-Fi positioning system.
The previous blog did not include the Wi-Fi positioning system information. So this time I will talk about WPS (Wi-Fi positioning system) on iOS.
続きを読むこんにちはCI事業部の川瀬です。
今回は冗長化について記事を書いてみたいと思います。冗長化というとActive-Active、ホットスタンバイ、コールドスタンバイとかを考えると思います。MuleSoftですと関連する記事は以下になります。
昔ですと、ロードバランサがあってインスタンスを複数作成し割り当てをしていました。MuleSoftも同様でイメージは以下のようになります。
ここからどのようにMuleSoftでは構築すればよいのでしょうか?最初にVPCを作成し、次にロードバランサの設定をします。
Runtime Managerの設定で、Workerの設定を2にするだけで、冗長化の完成です。簡単にできてしまいます。
問題は、デプロイするアプリケーションです。以下のような、フォルダ監視のアプリケーションがあったとします。
冗長化してしまうと、2つのWorkerから、タイミングによっては同時に処理してしまいます。実はMuleSoftには便利な機能があるのですが、これが問題です。以下のようにPrimary node onlyという便利な機能があり、使えそうなのですが、残念ながらこれはCloudHub上では使えません。
次に目につくのはWatermarkという機能です。これも一見、よさげなのですが、同時に実行してしまうと片方のWorkerではWatermarkを書き込めませんというエラーがログに出力されます。もし、運用の設定でアラートを通知しているなら、通知としてメールが送信されてしまうかもしれません。
最後の手段として、スケジューラを使用して定期的にポーリングするようにします。スケジューラは冗長化すると1つのWorkerでしか動作しません。これにより、同時に処理してしまうという問題は解決できました。
しかし、片方のWokerがクラッシュしてしまったどうでしょうか?勿論、MuleSoftには自動再起動という機能があるので、これを使用すれば問題は解決できます。ただ、これならWorker1つでいいのでは?となりますよね。
今回はここまでにして、次回はどのように解決するのかを考えていきたいと思います。
みなさまこんにちは、CI事業部の釜谷です。
フレクトでは、2020年度からMuleSoftに注力しています。 MuleSoftに興味のあるそこの貴方!是非フレクトにお問い合わせください!!
今回は、前回紹介したAnypoint Platformの機能の1つ「Design Center」について、紹介したいと思います。
※前回のブログ
cloud.flect.co.jp
Design Centerは、2つの機能を提供しています。
それぞれについて、紹介したいと思います。
次回は、Exchangeについて、紹介したいと思います。
本記事で、少しでもMuleSoftに興味を持って頂けたら幸いです!
みなさまこんにちは、CI事業部の釜谷です。
フレクトでは、2020年度からMuleSoftに注力しています。 MuleSoftに興味のあるそこの貴方!是非フレクトにお問い合わせください!!
今回は、Anypoint Platformを紹介しようと思います。 www.mulesoft.com
Anypoint Platformは、MuleSoftが提供する、APIの開発・管理・監視・運用するための必要な様々な機能を持つクラウド環境です。
Anypoint Platformでは以下の機能を提供しており、これらの機能を活用することで、APIの開発・管理・監視・運用がスムーズに行うことができます。
機能名 | 説明 |
---|---|
Access Management | API作成対象の組織の管理(リソース、アクセス権、開発環境などの管理)ができます。 |
Design Center | API 定義の設計 と シンプルなAPI実装の開発機能を提供します。 |
Exchange | MuleSoft 上で公開中の社内外 API アセットの管理・検索・参照 や、モック機能によるAPI の試行ができます。 |
API Manager | API管理のためのGateway/Proxy を定義します。 |
Runtime Manager | デプロイしたAPIの管理(環境変数設定やログ・アラート監視)や、VPCとLoad balancerの管理ができます。 |
Monitoring | デプロイしたAPIのモニタリング(CPU負荷やレスポンスタイム、使用リソースなどの監視)ができます。 |
次回以降は、これらの機能について紹介しようと思います。
本記事で、少しでもMuleSoftに興味を持って頂けたら幸いです!
みなさまこんにちは、CI事業部の釜谷です。
フレクトでは、2020年度からMuleSoftに注力しています。 MuleSoftに興味のあるそこの貴方!是非フレクトにお問い合わせください!!
今回は、MuleSoftの特徴である「API-led Connectivity」についてお話ししたいと思います。
API-led Connectivity(API主導のシステム間連携)は、再利用可能な3つの層(Experience、Process、System)に所属するAPIを使用してデータとアプリケーションを接続する方法です。
各層の概要は以下になります。
APIの種類 | 説明 |
---|---|
Experience API (ユーザーエクスペリエンス) |
APIを使用する様々なクライアント(デバイス・Webシステムなど)に応じたAPIを提供する層です。APIを使用するクライアントは、API内のビジネスロジックやデータベース操作などを気にする必要はありません。APIは、複数のProccess APIやSystem APIを組合せてサービスを提供します。 |
Process API (業務プロセス) |
ビジネスロジックを提供する層です。複数の System API を組み合わせて、業務的な機能を提供します。 |
System API (ソースシステム) |
外部システムとの連携やデータベース操作などの機能を提供する層です。再利用性を高くするために業務色をできるだけ排除した設計になっています。 |
複数の層に分けることでAPIの再利用がスムーズに行うことが可能になり、新規APIやAPIの機能拡張時の開発コストの削減につながります。
例えば、Experience API:電話受付API(Process API:ハンバーガー注文API、System API:ハンバーガーAPI)以外に、Experience API:Web受付APIを新規開発したいとき、Process API:ハンバーガー注文API、System API:ハンバーガーAPIを再利用するだけで、APIの開発が可能になります。
本記事で、少しでもMuleSoftに興味を持って頂けたら幸いです!
こんにちは。CI事業部の川瀬です。
今回は運用で役立つAlert通知について説明します。Alertと言えば、キャパシティ管理でCPUの利用率が70%を超えたら通知、5分回にXX回以上のエラーが発生したら通知ということを思い浮かべる人が多いと思います。勿論、MuleSoftのAPI Platformでもいろいろな通知方法が提供されています。このいろいろという所が実は悩ましいです。
では、実際に機能を見ていきましょう。
Runtime Mangerによる通知
ここでは、以下の通知が提供されています。
Deployment failed (デプロイに失敗しました)
Deployment success (デプロイメントに成功しました)
Worker not responding (ワーカーが応答していません)
実際の設定画面はこんな感じです。
API Mangerによる通知
CPU Utilization (CPU 使用率)
Memory Utilization (メモリ使用量)
Thread Count (スレッド数)
Message count (メッセージ数)
Message error count (メッセージエラー数)
Message response time (メッセージ応答時間)
実際の設定画面はこんな感じです。
Monitoringによる通知
API を管理する 1 つ以上のポリシーで違反が発生する。
要求数
ユーザが指定された期間で許可されている回数を超えて API にアクセスを要求する。
応答コード
API が要求を受信したときに、400、401、403、404、408、500、502、503 のいずれかの HTTP コードを返す。
実際の設定画面はこんな感じです。
Monitoringのカスタムダッシュボードでの通知
カスタムダッシュボードで設定したメトリクスに応じて設定できる項目が変わります。
実際の設定画面はこんな感じです。
MonitoringのFunction Monitoringでの通知
期待するHTTPレスポンスを定期的に監視することができます。例えば、死活監視を設定することができます。
実際の設定画面はこんな感じです。
Runtime ManagerによるAlert通知はどのライセンス形態でも使用できますが、その他のAlert通知はライセンス形態により使用できない場合があるので注意してください。
いろいろな個所でAlert通知ができるので、最初のうちは混乱してしまうかもしれませんが、ライセンスに応じでできることがどんどんできることが増えていくと考えればよいです。
ここでクイズです。Function Monitoringで死活監視ができますが、Runtime ManagerのWorker not respondingを使用しても死活監視ができます。どちらを使えばいいでしょうか?
即時性を求めるならFunction Monitoringです。Runtime ManagerのWorker not respondingによる通知は、若干、時間がかかります。ただし、Function Monitoringではバッチ系のアプリに対し死活監視ができません。その場合は、Runtime ManagerのWorker not respondingを使うしかありません。