himanago

Azure・C#などのMS系技術やLINE関連技術など、好きな技術について書くブログ

LPF REV UP 2020「あなたならどう使う?最新Azureレシピ for LINE Platform」フォローアップ(後半)

はじめに

年が明けて 2021年となりはや1ヶ月。。

年を跨ぎつつまたもや間が空いてしまいましたが、REV UP 2020 でのセッション内容の振り返り後半を書いていきます。
※前半はこちら

f:id:himanago:20201231154120p:plain

Azure × Messaging API(サブ編)

前回は「メイン編」と称して LINE Bot のバックエンドとして使えるサービスを紹介しましたが、「サブ編」ではそれと組み合わせると便利な Azure サービスを紹介します。組み合わせて使うものということで、具体的なレシピも多めに紹介していきます。

Azure Cosmos DB

まずは Azure における NoSQL データベース、Cosmos DB です。

f:id:himanago:20201231022131p:plain

無料枠ができ俄然使いやすくなった Cosmos DB は、小規模サービスとして開発することも多い LINE Bot でも特におすすめできるようになりました(もちろん、登場当初と同じように惑星規模のサービスにも対応できます)。

f:id:himanago:20210129002954p:plain

Cosmos DB の便利な機能は Change Feed(変更フィード)です。Cosmos DB のコレクションへデータ追加・変更があったことを検知し、Azure Functions などにつなげることができます。

docs.microsoft.com

これを利用することで CQRS パターン(コマンド・クエリ責任分離)が実装でき、特に LINE Bot においてはデータの変更をトリガーとして Bot から Push メッセージを送信したり、逆に Bot の操作によって起きたデータの変更を別のアプリ・サービスに通知することができます。

もちろんデータ操作とその結果通知は同一の処理で行っても良いですが、サーバーレス・イベント駆動なアーキテクチャでシステムを組む場合は、データ操作と通知を別々の処理として実装しておくことで、それぞれの処理がシンプルになりつつそれぞれ独立したスケールが可能となります。

docs.microsoft.com

レシピ:リッチメニューの切り替え

Change Feed を使った LINE Bot レシピをひとつ紹介です。

f:id:himanago:20201231022151p:plain

Messaging API ではリッチメニューをユーザーごとに動的に切り替えることのできる API が用意されていますが、Bot を利用している中で、ユーザーの状態に応じてリッチメニューを切り替えたいというケースです。

そのリッチメニューの切り替えを、ユーザーによる Bot の利用によるデータの更新(Bot のメインの処理)と、その結果に応じたリッチメニューの切り替えを分けて実装します。

リッチメニューの切り替えはデータ更新をトリガーとして動く関数(Change Feed によって起動する Cosmos DB トリガーの Azure Functions)とすることで、作りがシンプルになりながら、処理がお互い依存しなくなるため拡張性も高くなります(たとえば、システム管理機能や別の Web アプリなどをユーザーの Bot 利用以外でデータが更新されたときにも、同じリッチメニュー切り替え処理が動いてくれる)。

Azure SignalR Service

つづいては SignalR Service です。

f:id:himanago:20201231022158p:plain

こちらは Web ページなどのクライアントに対してサーバー側の変更を通知しリアルタイム更新を促すためのしくみを提供するサービスで、直接 LINE Bot に対して何かできるわけではありません。

ですが、Azure Functions・Cosmos DB とセットで使うと簡単におもしろいことができます。

f:id:himanago:20201231022205p:plain

SignalR Service は Functions と統合されており、「出力バインディング」によって少ないコードでクライアントへのリアルタイム通知処理が実現できます。

docs.microsoft.com

さらに Cosmos DB の変更フィード(Change Feed)と組み合わせれば、データの変更をクライアントにリアルタイムで通知する処理がとても手軽に実現できます。

これによって、たとえば LINE Bot を入力・Webページを出力とするようなシステムが本当に簡単に構築できます。

レシピ:LINE Botからのメッセージをリアルタイム表示

f:id:himanago:20201231022218p:plain

それがこちら。

Bot からのメッセージをリアルタイムに表示する Web ページを簡単に開発できるのですが、以前公開したハンズオンがまさにこの構成なので、まだこの構成を試したことがない方は、ぜひつながっていく感動を味わってほしいです。

github.com

Azure Cognitive Services

続いて Azure Cognitive Services です。

f:id:himanago:20201231022501p:plain

これはコグニティブ機能を実現する「AI パーツ」ということで、REST API やクライアント SDK から簡単に利用できるもので、ちょっと AI っぽい処理を追加したいな、というときにオススメのものになります。

QnA Maker

f:id:himanago:20201231022452p:plain

特に LINE Bot にオススメなのは、QnA Maker です。事前に用意したナレッジベースを元に、ユーザーからの質問に回答する AI を作成することができるものになります。

ナレッジベースは FAQ ページ等から自動生成して、さらにそこからカスタマイズしていくこともできます。

docs.microsoft.com

LUIS

f:id:himanago:20201231022515p:plain

Bot でよく使うのは、自然言語処理の LUIS(Language Understanding)です。

サンプルの文章を登録して、そのインテント(意図)とエンティティ(文章中の、パラメータ的な意味のある要素)を指定して、自然言語のテキストを理解できるようにするものになります。

これを使うことで自然な会話ができる Bot を作ることができます。Bot Service / Bot Framework Composer の裏でも LUIS が使われているので、Azure における Bot 開発では合わせて使うことが多いものになります。

docs.microsoft.com

Computer Vision

続いて画像系のサービスですが、LINE Bot のある機能と相性がいい Computer Vision を紹介します。

docs.microsoft.com

f:id:himanago:20201231022521p:plain

Computer Vision は画像分析に関する機能を提供するサービスですが、この中に「サムネイル生成」の API があります。

大きな画像を投げると、そこから重要な部分(関心領域)を残してトリミングをして小さいサイズの画像作ってくれます。

docs.microsoft.com

LINE Bot で画像メッセージを送るとき、オリジナル画像と小さいサイズのサムネイル用のプレビュー画像の2つを指定しますよね。このプレビュー用画像を生成するのに、この機能がぴったりなんです。

Azure Blob Storage

続いて Blob Storage です。

f:id:himanago:20201231022538p:plain

ひとつ前に紹介した画像メッセージにも絡みますが、Blob Storage が静的リソースの置き場に適しています。

docs.microsoft.com

f:id:himanago:20201231022548p:plain

LINE Bot の画像メッセージや動画メッセージなどでどのデータを送るか指定する際には、その URL を指定します。

任意の画像を用意し、その URL を得る 1 番簡単な方法は、Blob Storage に画像を置き、パブリックアクセスを許可する設定にすることです。

公開 URL が1つ1つのファイルに対して得られるので、それを LINE Bot で送ってやればよいです。

しかし、問答無用で公開する設定にするのが憚られる場面もあるでしょう。一つのファイルの URL から、同じストレージ上の別ファイルの URL を推測されてしまう危険性もあります。

こういった危険を避けるための方法として紹介したいのが、SAS トークンを使ったセキュア運用です。

f:id:himanago:20201231022557p:plain

SAS(Shared Access Signatures)で Azure Storage のへのアクセス制限をかけることができ、リクエストの有効性を確認する「SAS トークン」をBlob単位・アクセス単位で生成し、URL に付与することで Blob コンテナーのパブリックアクセスレベルを「プライベート」のまま、SAS トークン入りの URL を知っている人のみにアクセスできるようにすることができます。

docs.microsoft.com

こちらに関しては、以前に記事を書いたのであわせてみていただけたらと思います。

himanago.hatenablog.com

コンテナのパブリックアクセスレベルが匿名アクセスできないような形になっていても、このトークンつきの URL からならアクセスできるので、LINE Bot で画像等を送信する時にこのトークンを発行して、そのURLを送ってあげると、よりセキュアに運用できるんじゃないかな、ということでぜひ使ってみてほしい機能です。

レシピ:画像メッセージ用リソースの作成

Computer Vision を活用したレシピです。

f:id:himanago:20201231022609p:plain

サムネイル画像を Logic App で作成するような連携処理を組むことで、LINE Bot で使用するリソースを効率よく作ることができます。

…と思ってスライドを作ったんですが、 「Blob に画像を置いたらサムネイルが自動で作られる」というふうに Logic App でフローを組むほうが手軽かつ便利そうです(そのうち記事を書きます)。

Azure × LIFF/ミニアプリ

概要

f:id:himanago:20201231023224p:plain

LIFF と Azure の組み合わせについては、そもそも LIFF が Web アプリになりますので、通常の動的な Web アプリであれば、Web Apps で全然開発が可能です。

認証の統合ができるようになっているので、Azure AD B2C で LINE ログインと連携したものを組み込むことで、LIFF アプリとしていい感じに動くので便利です。

docs.microsoft.com

Azure AD B2C

f:id:himanago:20201231023253p:plain

Azure AD B2C では、外部の ID プロバイダーとの連携を Azure に組み込むためのものですが、LINE ログインも「カスタムポリシー」を作成すれば実現可能になっています。

カスタムポリシーの作成は結構難しいのですが、これを作れば Web アプリへの LIFF・LINE ログインの統合ができます。

docs.microsoft.com

Azure Static Web Apps

f:id:himanago:20201231023303p:plain

バックエンドで Java .NET が動くような動的な Web アプリであれば、Web Apps を使いますが、静的な Web アプリであれば、Static Web Apps がおすすめです。

docs.microsoft.com

f:id:himanago:20201231023327p:plain

静的な Web アプリは、クライアントサイドで JavaScript が動いて実現するようなウェブサイトのことですが、もともと Azure には静的サイトホスティングのために Blob Storage で Web ページとして公開できる機能がありました。

docs.microsoft.com

ただ、機能としては貧弱だったので、より高機能な Static Web Apps が登場しました。

Static Web Apps は、GitHub との統合によって、リポジトリの更新のたびに自動でビルド・デプロイされるようになっています。

f:id:himanago:20201231023336p:plain

また、同時にバックエンドの API が開発できるようになっており、LIFF と Bot・連携機能まで同時に開発したりなどができます。

f:id:himanago:20201231023346p:plain

まだプレビューですが、GA のタイミングではもっと便利になるのではと思ってすごく期待しております(個人的には Azure DevOps 対応を待っています。GitHub を見る限り、もうすぐな様子)。

※以前ハンズオンイベントで簡単にまとめたスライドを作って発表しましたのでこちらもよろしければご参考に。

www.slideshare.net

その他便利な Azure サービス

そのほか、開発・運用サポートの面で LINE プラットフォームと相性がいいサービスを紹介です。

Azure Key Vault

f:id:himanago:20201231023639p:plain

シークレット情報や設定内容などを保存するのに便利。

docs.microsoft.com

Azure DevOps

f:id:himanago:20201231023657p:plain

ソースコード管理からプロジェクト管理、CI/CD パイプラインなどを提供。Azure 以外でも組み合わせて使えるので広く使われてほしいサービスです。

5人まで無料だし、Azure サブスクリプションとは関係なしに使えるので、ぜひ!

Application Insights

f:id:himanago:20201231023708p:plain

「Azure Monitor」と呼ばれる、監視系サービス群のひとつ。使用しているアプリのログを貯めておいたり、アラートを受け取ることができます。

docs.microsoft.com

アプリケーションマップという、システムで使用しているサービスの全体像と障害箇所を確認できる機能もあります。

docs.microsoft.com

アラートはすばやく障害を検知するために、Logic Apps と連携してそこから Teams や Slack といったチャットを投げるように組んでおくのがおすすめです。

もちろん障害通知専用の LINE Bot を作っても OK。障害通知だけなので Push も確実に無料枠に収まります(おさまらないならそれはシステムがやばい…)。

[実装例] Azure × LINE Platform によるチャットシステムの構築

最後に実装例です。

Azure と LINE プラットフォームによるチャットシステムの構築です。

f:id:himanago:20201231024402p:plain

このような Web 画面を用意して、Web と LINE Bot でやりとりをする、というものです。

上で Cosmos DB と SignalR Service で画面を更新する話を書きましたが、LINE → 画面がそれ。

f:id:himanago:20201231024413p:plain

そして画面 → Web はその逆です。

f:id:himanago:20201231024425p:plain

画面側から送ったメッセージにも、この Change Feed の流れをそのまま活かして Push メッセージが送れます。

Azure Communication Service

上のような構成で Bot と Web 画面で双方向にやり取りができるようなシステムを作ることができますが、最近プレビューで登場してた Communication Service を使うと、これだけで往復の処理が作れるようになります。

f:id:himanago:20201231024431p:plain

docs.microsoft.com

実装についてはこちらの記事に書いています。

himanago.hatenablog.com

実際に動かしたデモです。セッション当日はうまくいかなかったので(スマホミラーリングが止まってしまった…)、終了後に突貫で撮ったものがこれです。

デモのもとになったサンプルアプリはこちらです。

docs.microsoft.com

まとめ

f:id:himanago:20201231024751p:plain

Azure は PaaS がやっぱり強い!ので、(特に小規模向けや個人開発などでは)あまり複雑なことを考えたり設定したりしなくても、コツさえつかめば簡単に動くものが作れてしまいます。

おなじく手軽に UI が手に入る LINE Bot と組み合わせることで、すぐに面白いものが作れます。なので、どんどん LINE × Azure を試してほしいと思っています。

おわりに

長い…

とりあえず、いままで Azure × LINE でいろいろやってきて、それの総まとめ的なものにしたかったセッションです。

詰め込みすぎた感はありますが、詰め込めるだけ詰め込んでしまいたい!という気持ちでした。

実はまだまだ紹介し足りない部分も多いですが(たとえば大規模向けの話とか…)、ひとまず今回まではここまでです。ありがとうございました。