Be an Engineer.

社会人からWEBエンジニアになった人間の備忘録的勉強記録

AWS ECS/FargateのデプロイタイプをBlue/Green(CodeDeploy)にしたときにデプロイ実行で叩くべきAPI

AWS ECS

久しぶりにこちらに書きます。（関係ないですけど、QiitaとBlogの使い分けって難しいですよね。

主に自分のスキルアップを目的としてサンプルアプリ的に稼働させている https://jaaxman.shirakiya.com/ というWebサイトのFargate化を進めていたときにデプロイで少しハマったことを書きます。

したかったこと

Web appの実行環境をEC2からFargateに載せ替えるにあたり、デプロイの自動化も進めていました。

f:id:shirakiya:20190210221322p:plain:w600
CircleCI+ECSのデプロイフロー

Web appのデプロイの手順は上の図のような形で作戦を練っていました。

  1. productionブランチにpush
  2. テスト通過後にdocker image作成・ECRにpush
  3. タスク定義を更新（2のimageを使う）
  4. サービスを更新（3のタスク定義を使う）し、既存タスクを最新のサービスを使ったタスクに入れ替える

1はGitの操作なので除きますが、2〜4の操作はCI上（今回はCircleCIを使っています）で行う操作なので、AWSのAPIを叩く必要があります。
2と3は普通にECRにpushし、タスク定義をupdateするためのAPIを叩くことで実現できます。公式にもドキュメントがあるのでこれらが参考になります。

イメージのプッシュ - Amazon ECR
RegisterTaskDefinition - Amazon EC2 Container Service

サービスのデプロイはデプロイタイプによって利用するAPIが異なる

今回の話題の中心は4のデプロイについてです。
Amazon ECSではサービスのデプロイ方法（=デプロイタイプ）は2種類の方法が利用できます。

  1. ローリング更新
    • サービスを更新すると最新版のサービスを使ったタスクを自動で入れ替える
  2. Amazon CodeDeployを利用したBlue/Greenデプロイ
    • 最新版サービスを使ったBlue環境を稼働し、その後に本番用トラフィックを流す
    • 本番用トラフィックを流す前に検証したりすることが可能

実はこの2種類のデプロイタイプのそれぞれで叩くべきAPIが異なります。

  1. ローリング更新 ⇒ ECSのUpdateService
  2. Blue/Greenデプロイによる更新 => CodeDeployのCreateDeployment

ズバリここでハマってしまいました。
勉強がてら進めていたためローリング更新を試してからCodeDeployのBlue/Greenを試すという流れで作業をしていたのですが、CodeDeployを利用した場合はサービスを更新したいのに サービスを更新するAPIを叩く必要は無い のです。

もう少し具体的に見ていきましょう。

デプロイタイプ「ローリング更新」の場合

デプロイタイプを ローリング更新 にしている場合はAWS CLIを用いると以下のような操作でデプロイを行うことができます。（最小限のオプションです）

$ aws ecs update-service \
  --cluster test-cluster \
  --service test-rolling \
  --task-definition test:2

これを叩いた後にサービスのイベントタブを開くと、以下のようにタスクが ea8369c11af3441e9128970e8f4562d6 から 4cd48c97bd3c4f55bc40b6e4a576d892 に入れ替わっていることが見て取れます。

f:id:shirakiya:20190210221445p:plain

つまり「サービスをデプロイするにはサービスを更新（=update-service）すればよい」のです。まぁなんかイメージ通りですね。

デプロイタイプ「Blue/Greenデプロイによる更新」の場合

さて、デプロイタイプを Blue/Greenデプロイによる更新 にしている場合に上記のように update-service を叩くとどうなるでしょうか。

$ aws ecs update-service \
  --cluster test-cluster \
  --service test-codedeploy \
  --task-definition test:2

An error occurred (InvalidParameterException) when calling the UpdateService operation: Unable to update task definition on services with a CODE_DEPLOY deployment controller. Please use Code Deploy to trigger a new deployment.

結果、InvalidParameterExceptionで怒られてしまいました。デプロイするならCodeDeployのdeploymentをトリガーしろと言っていますね。
このようにCodeDeployを使っていると、UpdateServiceを叩いたところでデプロイすることはできません。デプロイする場合は以下のようにCodeDeployの create-deployment を叩く必要があります。（一部マスクしてます）

$ aws deploy create-deployment \
  --application-name AppECS-test-cluster-test-codedeploy \
  --deployment-group-name DgpECS-test-cluster-test-codedeploy \
  --revision '{"revisionType": "AppSpecContent", "appSpecContent": {"content": "{\"version\": 1, \"Resources\": [{\"TargetService\": {\"Type\": \"AWS::ECS::Service\", \"Properties\": {\"TaskDefinition\": \"<タスク定義ARN>\", \"LoadBalancerInfo\": {\"ContainerName\": \"nginx\", \"ContainerPort\": 80}}}}]}", "sha256": "192a44b8191ec68bb5bd4861d4960065bdb148d98e9ef74a5b4d9b6930f179b0"}}'

{
    "deploymentId": "d-XXXXXXXXX"
}

これでCodeDeployによるデプロイプロセスが開始されました。

まとめ

ECSのデプロイはデプロイタイプによって叩くべきAPIが異なります。

  • ローリング更新
    • ⇒ Amazon ECS の UpdateService（=aws ecs update-service）
  • Amazon CodeDeployを利用したBlue/Greenデプロイ
    • ⇒ AWS CodeDeploy の CreateDeployment（=aws deploy create-deployment）

以上、何かのご参考になれば幸いです。

【Jaaxman】日本語に翻訳した論文の検索機能をつけました

制作物

jaaxman.shirakiya.com

当ブログでのJaaxmanの紹介記事はこちら↓

shirakiya.hatenablog.com

そのJaaxmanに本日、検索機能をつけたものをリリースしました。

改めてJaaxmanの説明を簡単にしますと、arXiv.org の stat.ML/cs.AI の2カテゴリの論文のタイトルとAbstractをGoogle翻訳で日本語化したものが一覧で見れるWEBアプリです。

元々、日付やカテゴリなどで表示される論文情報のフィルタリングができるようにはしていましたが、記事数も多くなりやはり検索機能はほしいと思い、今回のアップデートを進めました。

使い方

論文情報のタイトル検索を行うための入力欄が右上近くにあるので、こちらから検索したい単語を入れ、「検索」のボタンを押すと検索にヒットした論文情報のみを表示します。

f:id:shirakiya:20180722221516g:plain

検索の対象は、

  1. タイトル - 日本語版
  2. タイトル - 原文（英語）

の2つで、日本語の検索ワードで検索すると日本語版のタイトルを、英語の検索ワードでは英語版のタイトルを対象として検索を行います。上のGIFのように混合の場合でも日本語・英語それぞれの検索ワードでタイトルの検索を行います。 一方、Abstractは検索対象には含まれませんので、ご注意ください。

完全に作者都合の不定期なアップデートとはなりますが、お役に立ちましたら嬉しいですね。

arXiv.orgの人工知能に関する論文を日本語で一覧できるサイト Jaaxman を作った

制作物
f:id:shirakiya:20180107214410p:plain:w300

jaaxman.shirakiya.com

Jaaxmanという名前です。
人工知能関連の論文は専ら arXiv.org に掲載されており、特に stat.ML や cs.AI というカテゴリが付けられてSubmitされていることが多いです。

普段それらの論文で新しいものを拾い読みするときは、FeedlyでarXiv.orgのRSSを連携させてリスト化したものを見ていました。しかし、恥ずかしながら英語を見て脳にダイレクトに情報が入ってこず、情報を脳に入れるためには英語読むモードに切り替えないといけず、英語読むモードはかなり脳のスタミナを消費してしまうので、気軽さに欠けるものがありました。（慣れの問題とはわかっていますが...）

そこで「タイトルとAbstractだけでも日本語化したらスッと脳に入ってくるのでは？」と思ったのが制作のきっかけでした。

できること

f:id:shirakiya:20180107214214g:plain

arXiv.org の stat.ML/cs.AI の2カテゴリの論文のタイトルとAbstractをGoogle翻訳で日本語化したものが一覧で見れる

これに尽きます。基本的に「更新された論文を通勤中の電車内で流し見する」ことを最も重要なユースケースとしていたため、凝った検索などの機能は特別用意していません。
逆に気になった論文はPocketやTwitterなどのシェアができるようにパーマリンクを用意しました（シェアボタンは重たくなるので置きたくなかった）。他にも新規Submitだけのものをフィルタリングできたりします。
ホントは更新があったら通知があれば良いのになぁと思っていたりしますが、それはおいおい。

やっていること

朝の6時に arXiv.org の stat.ML/cs.AI の2カテゴリのRSSの更新分のタイトルとAbstractをGoogle Translate APIにかけて保存してします。
WEBサイトは普段仕事でPythonでサーバサイドのコードしか書いてなかったので、久しぶりにJavaScript書きたいと思い Vue.js でSPAとして構築しています。

一応コードはこちら。

github.com

あと、別にロゴとかいらんでしょとか思ってたのですが、少し調べてみるとLOGASTERというサービスでそれっぽいロゴが1000円ほどで買えたので、1000円ぐらいなら出すかと思い、買いました。1000円だろうが、ロゴがあるのとないのとでは製作時のやる気アップ度が全然違ったのでいい買い物したと思います。（ちなみに .aiなどのイラストレーション用ソフトに対応したファイルは1000円のプランだと含まれていないのですが、そもそも使えないので必要ありませんでした。）

作ってみて気づいたこと

アカデミックな文章に対するGoogle翻訳の精度はそこそこ高いという印象を持っていて、実際にAbstractの翻訳を読んでみるとめちゃめちゃいい精度で翻訳されていてGoogle様すごいという気持ちになりました。しかしながら、コンピュータサイエンスにおいて「英語で言われた方がわかる（というか誤訳？）」ということがままあることに気づきました。

  • 「bandit algorithms」→「盗賊アルゴリズム」
  • 「butterfly effect」→「蝶効果」

これはあくまで一例ですが、逆にGoogle翻訳のクセを見抜いて日本語を見たときに何を言っているのかを少し考えるということが必要だというのは若干の本末転倒感があり、残念ポイントでした。

メンテナンス頻度

自分が使っていく中で不都合なりが発生した場合は対応しおうかなと思っていますが、めちゃめちゃ丹精込めて機能改善を行う予定はあまりないです。ですが、強い要望などがあれば対応できる範囲で行おうとも思っています。
一方で、オープンソースとしていますので（誰も興味がないとは思いますが）ご興味のある方は見ていただいても構わないと思っています。

基本的に自分のために作ったものではありますが、誰かのためにお役に立てれば幸いです。

Boostnoteは良いMarkdownエディタ

f:id:shirakiya:20171115031019p:plain

めっちゃ久しぶりの更新。

当方エンジニアで、日々手順やメモを取ることが多いが、これまで理想とするMarkdownエディタには巡り会えていなかった。

これまでのMarkdownエディタ遍歴

  1. Kobito
  2. Dropbox Paper
  3. Atom

どれも満足はしていない中で使い続けてきて、そろそろ個人的な決定版が欲しかった。
Markdownエディタに求めるものは以下の点。

  1. 「フォルダ」のような概念があること
  2. 異なるPC間でメモが同期できること
  3. 一覧性が高いこと
  4. 安い（月額料金は払いたくない）
  5. データのexportができること

「フォルダ」

ここでフォルダと言っているのは、例えばEvernoteのノートブックに対応するイメージで、中にあるメモがある分類でまとめられるものとしている。このフォルダのようなものがあれば、例えばMySQLに関するメモを作成するときは「MySQLフォルダ」にメモを保存しておけば、MySQLのメモを探すときにまず「MySQL」フォルダに見にいけばいい。
メモを見返すときにフォルダがあれば圧倒的に楽になると思っている。（何かを思い出すときや探すときに、そういう階層構造のようにインデックスを作って、思い出している気がする。）

残念ながらKobitoにはフォルダはなく、編集した順序でメモが並ぶというのが不満足だった。
また、Dropbox Paperはフォルダはあるものの、メモの編集画面とは異なる画面にフォルダの一覧画面があるため、別タブに表示している一覧にタブ移動しないといけないのが煩わしかった。
Atomは左カラムにディレクトリの階層構造が常に表示することができるのでGood。

異なるPCでの同期

当然ながら、自分の作業メモであったり何かのライブラリに関するメモは、いつでもどのPCでも見れるような状態にしておきたい。

Kobitoで同期をしようと思うと月額480円のプレミアムプランに入らないといけない。
Dropbox Paperなんかはそもそもクラウドの保存しているメモをブラウザ上で編集するのでこの点は良かった。

一覧性が高いこと

メモを探す時にとても重要。
Dropbox Paperはフォルダ毎にメモ一覧ページがあり、別のフォルダのメモ一覧を見ようと思うと一度フォルダ一覧ページに戻ってから再び見たいフォルダからメモ一覧ページに遷移しないといけず、なかなか煩わしい。（フォルダ毎だけでなく全メモ一覧ページがあるものの、それだとフォルダ毎にまとまらないのでNG）

安い

一般的な庶民なもので、やはり安いにこしたことはなく、ただ良いMarkdownエディタなのであれば多少の金額は払うつもりでいた。

データのexportができること

あまり優先度が高いわけではなかったが、やはりデータのexportができる方が嬉しい。いつそのエディタがサービス・開発中止になるともしれないので、いざとなったときに簡単に移行できるような備えはあった方が安心。

以上のような観点でエディタを探したときに巡り合ったのがBoostnoteだった。

Boostnote

Boostnote はOSS製のプログラマ向けMarkdownエディタで、無料で利用可能である。
Electronをベースにしているが故にMac・Windows・Linuxと使えるプラットフォームの幅も広く、またiOS・Androidでもネイティブアプリがある。すごい。

基本的に使い方はGithubにWikiといくつか使い方に関する記事があるので、それらを見るとだいたいわかる。

上に記した求める点に対してBoostnoteの良さをつらっと書いていく。

「フォルダ」

Boostnoteでは「Storage」と呼ばれるものがフォルダに相当するもので、好きなようにラベルが付けられて言うことなし。

異なるPCでの同期

Dropbox や GoogleDrive を使えば可能。
Boostnoteは初期設定の中で、メモのrawデータ(CSONデータ)を格納するディレクトリを指定する。このディレクトリを例えば Dropbox や GoogleDrive などの同期ディレクトリ内に指定することによって、同期しているデバイス同士ではデータを共有することが可能になる。
https://github.com/BoostIO/Boostnote/wiki/Cloud-Syncing

一覧性が高い

特に気に入っているところだが、Boostnoteは様々な観点からメモを一覧にして閲覧することができる。

  1. 全メモ一覧（All Notes）
  2. スター付きメモ一覧（Starred）
  3. 各Storage毎のメモ一覧（Folders）
  4. 各タグ毎のメモ一覧（Tags）

これだけ一覧で見る方法があると、メモも見つけやすい。（あとElectronアプリの割に動作がサクサクでそれも見つけやすさに遠からず寄与している気がする。が、メモが増えると遅くなるなどの検証はしていないのでここは何とも言えない。）

安い

無料。最高。ありがとうございます。

データのexportができること

メモ一件毎にプレーンテキストファイルあるいはMarkdownファイルにexportすることは可能。ただし、全件一度にexportすることはできない。（最悪CSONをパースしてどうにかするというスクリプトを書けばいいか、とも思っている。）

まとめ

総じてとても使いやすいと思っているMarkdownエディタで、かなりライフチェンジングな思いをしている。文字ばかりで伝わらないよなぁと思いつつ非常にオススメなので一度使ってみてはいかが？

Facebook Messanger Platformを調べてみた

Bot熱が冷めないshirakiyaです。
昨日のLINE Botを調べてみたに引き続き、今回はFecebookのMessanger Platformについて調べてみました。

作成の流れと詳細

Messanger Platform 公式ドキュメント
↑のGetting Startedを参考に調べて行きました。

0. 必要なもの

いきなり流れとかじゃないのですが、前提として以下のものが必要になります。

  1. Facebookページ
    • 作成するFacebookページがBotのアカウントとなる
  2. Facebookアプリ
    • これがMessanger Platformと呼ばれるBotなAPIを有効にするためのもの
  3. Webhook URL
    • ユーザーからのメッセージの送信などでMPからフックされる先のURL。いわば自前で用意しないといけないBotアプリ。

1. FacebookアプリとFacebookページを作成する

まず始めにFacebookアプリを作成します。
あまり重要なところじゃないので端折りますが、fecebook for developersからアプリを作成します。
作成するときは、Webサイトでもモバイルアプリでもなんでもないので下図のようにbasic setupから進めると、余計な作成フローを進まずにいけるのでおすすめです。

f:id:shirakiya:20160531151256p:plain

アプリと共にFacebookページも作成する必要があります。作成の方法は割愛します。（ヘッダーにある下向き三角マークから「ページを作成する」があるので、そこから作成できます。）
とりあえず適当に進めて作成してみました。

f:id:shirakiya:20160531151922p:plain

2. FacebookアプリにMessangerを追加する

Messangerの追加

左カラムにある「製品を追加」から、Messangerという製品("Product"の直訳なので日本語では不自然になってる?)を追加します。

f:id:shirakiya:20160531152205p:plain

Webhook設定

ページトークンの下にある「Setup Webhooks」から設定します。

f:id:shirakiya:20160531152255p:plain

f:id:shirakiya:20160531152309p:plain

ここでcallback URLとトークンを自由に設定できます。
が、 この時点でこちらで用意すべきBotのシステムができていないので、一旦パスして後で入力することとします 。

3. Botアプリを作成する

ここで言うBotアプリは「Botを動作させるためにユーザーが用意するシステム」のことで、Facebookアプリのことではないのであしからず。

3-1. Webhook設定のためのWebアプリを用意する

まず、「Webhook設定」を完了することを目指します。
ここでしないといけないのは、要は"疎通確認"ですので、以下を満たすようにサーバーや簡単なWebアプリを構築します。

  1. callback URLが用意できていなかったので、そのURLを用意する
  2. Facebook側から送られるGETリクエストに対し、Verify Tokenを確認してchallengeを返す

今回も簡単のため、Heroku+Flaskを用いて構築しました。
Herokuの構築手順は割愛することとして、Webアプリには以下のような処理を行います。

  • app.py
# -*- coding: utf-8 -*-

import os
from flask import Flask
from flask import request

app = Flask(__name__)

# エンドポイントはなんでも良い
@app.route('/webhook', methods=['GET'])
def varification():
    VERIFY_TOKEN = os.getenv('VERIFY_TOKEN')

    # Facebookからは
    # `?hub.mode=subscribe&hub.challenge=<value>&hub.verify_token=<verify-token>`
    # というパラメータが送られてくる
    # `hub.verify_tokenが一致していることを確認する
    if request.args.get('hub.verify_token') == VERIFY_TOKEN:
        # 一致している場合は`hub.challenge`をそのまま返す
        return request.args.get('hub.challenge')
    return 'Error, wrong validation token'

if __name__ == '__main__':
    app.run()

構築しアクセス可能な状態にした後に、Facebookアプリ側の画面に戻りWebhook設定を行います。
URLと任意のVerify Token（今回であればHerokuの環境変数に定義したものと同じもの）を入力し、フォロー入力欄には少なくとも「message」にチェックを入れます。
「確認して保存」を押すと、裏で疎通確認が行われます。失敗すればエラー原因と共にダメって言われます。

f:id:shirakiya:20160531152453p:plain

ちなみにここにある「フォロー入力欄」は以下の意味のようです。

チェック 説明
messaging_optins Send-to-Messanger Pluginボタンを押されてMessangerにやってきた時にcallbackするかどうか
messages ユーザーからのメッセージが送られた時にcallbackするかどうか
message_deliveries メッセージが送信できた後にcallbackするかどうか（？） 「This callback will occur when a message a page has sent has been delivered.」 ←Facebookのタイポ？
messaging_postbacks [構造化メッセージ」と呼ばれるボタン付きメッセージで、ボタンが押された時にcallbackするかどうか

3-2. メッセージを受信し、返信するようにする

次はユーザーから送信されたメッセージを受信して、オウム返しするプログラムを書いていこうと思います。

まず、作成しているFacebookアプリとFacebookページを紐付けます。
ページを選択から、先ほど作成したFacebookページを選択し、フォローします。

f:id:shirakiya:20160531152703p:plain

フォローしたら、トークン生成からFacebookページのページトークンを生成します。このトークンがあればAPI利用の認証ができるようになります。

f:id:shirakiya:20160531152903p:plain

実際の開発したものに関して、オウム返しするだけですがコードはこちらです。

github.com

イメージとしては、例えばユーザーがメッセージを送った場合ではMPから以下の1つ目の様なJSONがPOSTで送られてくるので、それに対応して2つ目のJSON共にAPIを叩くとBot側から簡単なメッセージを送信することができます。

  • receive
{
  "object":"page",
  "entry":[
    {
      "id":"PAGE_ID",
      "time":1460245674269,
      "messaging":[
        {
          "sender":{
            "id":"USER_ID"
          },
          "recipient":{
            "id":"PAGE_ID"
          },
          "timestamp":1460245672080,
          "message":{
            "mid":"mid.1460245671959:dad2ec9421b03d6f78",
            "seq":216,
            "text":"hogefugapiyo"
          }
        }
      ]
    }
  ]
}
  • request
{
    "recipient":{
        "id":"<entry[0]['sender']['id']>"
    }, 
    "message":{
        "text":"みゅ！"
    }
}

Facebookの画面にて、FacebookページとMessageのやり取りを行います。

f:id:shirakiya:20160531153133p:plain
（やっぱり感じるデバック感。。返事が来ないと二重で悲しい）

できました！
これで簡単なBotは作成できました。

参考:Messengerで簡単なBotつくる(Facebook Messenger Platform from F8) - Qiita

システム構成

まとめがてら、全体像はこんな感じです。

f:id:shirakiya:20160531153208p:plain

LINE Botと異なるのは、LINEではLINE Bot Trial Accountを作成すればその時点でアカウントが作成されましたが、FacebookではFacebookページのアカウントとMessangerでやりとりを行うため、Facebookページが必要になります。

何ができるのか

  • メッセージの送信
    • テキスト/画像の送信
    • Facebookが用意しているテンプレートメッセージ
      • Generic（テキスト&画像&ボタン）
      • Button（テキスト&ボタン）
      • Receipt（領収書）
  • メッセージ開始時のメッセージ送信
  • Web埋め込み用の"Send to Messanger" / "Message Us" ボタンをデフォルトでサポート
    • → エントリーポイントを増やしやすい
  • ユーザーの情報取得
    • （別にMPならではのAPIではなさそうですが）

https://developers.facebook.com/docs/messenger-platform/implementation
このページに全てが書かれているので詳細はこちらから。

その他情報

審査

作成したBotを公開するには、Facebookによる審査が必要のようです。

  • page_messaging
  • pages_messaging_phone_number (optional)

という二つの権限があり、それらの利用範囲を以下の表にまとめました。

page_messaging pages_messaging_phone_number
(OK) ユーザーとの初期接触時の体験 (OK) SMSを使ったメッセージの送信
(OK) 予約・購入・注文の確約 (NG) ユーザーの同意無しでSMSを使ったメッセージを送信すること
(OK) カスタマーサポートなメッセージの送信
(NG) サービス・商品のアップセリングやクロスセリング
(NG) 広告やニュースレター、お知らせ等の送信

https://developers.facebook.com/docs/messenger-platform/app-review

料金

Bot作成では基本無料のようです。
が、Customer Matchingなる機能を利用する場合は、Customer Matchingしたユーザー一人毎に$99を払わないといけないようです。
Cutormer Matchingとは電話番号からユーザーを特定してMessangerでそのユーザーにリーチすることを可能にする機能のようです。ただし、FacebookページがUSのアドレスで登録されているか、一人の管理者がUSのアドレスで登録されていることが条件のようです。

（ってかめっちゃ高い…）

Wit.ai

http://www.torchlight.co.jp/blog/facebook/f8-2016-messenger-bots.html
こちらの記事にある通り、Wit.aiという自然言語処理に長けた人工知能が含まれる「bots on Messanger」も利用可能なのかなと思いきや、今は使うことができなかったです（ドキュメントには一部に紹介があるのみです）。
が、現状で特別何か連携がないというだけで、Wit.aiは利用可能なので使ってみるのも面白いかもです。

簡単にブロック可能

ユーザーはボットを簡単にブロックすることができます。あるいは、広告メッセージだけブロックすることもできるようです。
完全に、お助けツールという立ち位置だけしか認めないし、プロモーションのためにBotを使うなというFacebookのメッセージが受け取れますね。

感想

  • MPは何か"契約"を結ぶための商用Botに特化している
    • テンプレートを用意しているのはLINE Botになかったところ
    • LINE Botは「rich message」で自分で構造を作らないといけない
  • LINEにはGreatingメッセージのようなものがBussiness Connectしかなかったので便利っぽい

Enjoy Bot Life!!

LINE Bot（LINE Bot API Trial）を調べてみた

（※2016/11/10追記　こちらの記事はBot API Trialについて書いた記事です。2016年9月29日でもってBot API TrialはDeprecatedとなり、2016年11月16日をもって廃止となります。ただし、新たなAPIとしてMessaging APIが公開されています。）

作成した時の流れに沿って、そこでやったことと調べてみたことを書きます。

1. アカウント作成

会社/事業者情報作成

まずはLINE　BUSINESS CENTERにある「BOT API Trial Account」へ。

ページ下部の「利用開始」をするとログインを求められるので、今回は普段利用している個人のアカウントを使用しました。

そういえばLINEは（できなくはないけど）複数アカウント持ちづらいサービスなので、会社利用するにしてもここのログインアカウントは個人のものを使うことになりそうです。
（ちなみに複数アカウントを持つには、スマホ版のアプリを一度インストールしなおさないと二つ目のアカウントを作成して、また別のアカウントでログインし直したい場合は、再度インストールし直さないといけない、、という流れを踏むはず。ログアウトが無いというだけでこんなことになるんですね。完全にわざとだと思いますが。）

その後、会社/事業者情報を登録します…たしか…。（ここはずっと前に登録だけしておいて、メモをしてなかったので適当な感じになっていますが、会社/事業者情報を個人として登録した記憶があります。）

ビジネスアカウント作成

LINE BUSINESS CENTERでは、ビジネスアカウントというものがあります。
ビジネスアカウントは、いわば「サービス」を指し、ビジネスアカウントからBotを作ったり、LINE@を作ります。
例えばXというサービスを持つAという会社では、会社/事業者情報をAで登録し、ビジネスアカウントはXという単位でビジネスアカウントを作る形ですね。

LINE Business Centerの会社/事業者情報を登録後のトップページから「ビジネスアカウントを作成する」からビジネスアカウントを登録します。
今回は「モルちゃんBot」というBotを作ろうと思うので、それっぽい感じで作ります。

f:id:shirakiya:20160530104051p:plain

※ビジネスアカウントを作成しなくてもBot API Trial Accountは作成できます。１つの事業者で複数のサービスを持つ場合はビジネスアカウントは作らないと、事業者に紐付いてBotが１つしか作れないので注意。

2. Bot API Trial Account作成

ビジネスアカウントを作成したら次は、Bot API Trial Accountを作成します。
ビジネスアカウントを選択してBot API Trial Accountで「始める」から、次のページでページ最下部の「利用開始」を押すと、Bot API Trial Accountの作成確認画面に行きます。（ここから英語）

f:id:shirakiya:20160530104127p:plain

おもむろにCreate~!!

f:id:shirakiya:20160530104144p:plain

これがトップ画面で、Channel ID、Channel Secret、MID等の情報が書かれています。
一応この画面からBotの名前と画像は変更可能なので、なんかちゃうなってなっても安心です。

左カラムを見ると「Server IP　Whitelist」とあるので、API call元のIPも制限できるようです。

f:id:shirakiya:20160530104221p:plain

3. アプリケーションを作成する

詳しいドキュメントはこちら。
（Bot API Trial Accountの画面の右上にある「Documents」から参照できます。）

システム構成

以下にLINE Botの全体像を表すシステムを図示してみました。

f:id:shirakiya:20160530104247p:plain

トークを始めたユーザーからメッセージが送られると、LINE Bot Serverが開発者が用意したcallback URLにPOSTが投げられます。BodyにはJSONで記述されたテキストが入っています。例えばメッセージを返答するようなBotでは、開発者はそれを受けて返答するメッセージをJSONで用意し、LINEが用意しているAPIをcallします。するとLINE Bot Serverが処理してLINEアプリ上に返答メッセージが表示される、という仕組みになっているようです。

また、アプリケーション側が用意するシステムに関してアーキテクチャの考察がなされており、大量メッセージが来ても安心なLINE BOTサーバのアーキテクチャ等が参考になります。（この記事はかなりなるほどなーと思ったので、必読だと思います。）
また、そのアーキテクチャを参考にAWSで構築したというLINE Bot を AWSを使ってシステム構築してみた。等も参考になります。

アプリケーションを作ってみる

今回はサクッと試したいというのと調査が目的だったため、無料で使える範囲でHerokuとPython（FLASK）で作ってみました。Herokuだとhttpsをデフォルトでサポートしてくれていて、かつサーバホスティングしてくれているので、調査用としてはちょうどよいです。

実際のコードです。ただメッセージが送られるとそれをトリガーとして「みゅ？」とメッセージを返すのみのものにしました。
github.com

大きな流れはこんな感じ。

  1. アプリを作る
  2. herokuにデプロイ
  3. LINE Bot Trial Accountにcallback URLを登録
  4. Server IP Whitelistに用意したサーバーのIPを登録

注意するべきは、

  • LINE Bot ServerからhttpsをサポートしているURLに対してPOSTリクエストされること
  • Server IP Whitelistに登録しないとAPIへのリクエストが通らないこと
  • （細かい実装の話ですが）Botからのメッセージ送信の際のtoは配列であること（30分ハマった）

などでした。いずれもわかっていればそんなに問題ではないですね。

作成にあたっての参考記事:
LINE BOT をとりあえずタダで Heroku で動かす - Qiita
今更だけどラウル様と会話できる LINE bot を作ってみようとしてやめました→動きました - Qiita

4. Botとトークする

Botとトークするには、まずLINEアプリでBotと友だちにならないといけません。
作ったLINE Bot Trial Accountのトップページの下の方にQRコードがあるので、そのQRコードから友だちになってトークの画面まで行きます。

で、メッセージを送ると返ってきました。
f:id:shirakiya:20160530104440j:plain
（返事をしてもらえてない感じ、なんともデバック感を感じさせる…）

できること

https://developers.line.me/bot-api/overview#bot_accounts
を見ると、ビジネスアカウントが「Business Connect」なのか「Bot API Trial」なのかで利用可能なAPIに違いがあるようです。

Business Connect BOT API Trial
Send and receive messages using APIs Send and receive messages using APIs
Send link messages Send rich messages
Send rich messages
Send mission stickers
Use rich menus
Use Channel Web Applications
Have a searchable official account

https://developers.line.me/type-of-accounts/business-connect#anc1

基本的に「Send and receive messages using APIs」では、

が行えるようです。
「rich messages」はLINEの公式アカウントとかが普段クーポンを送ってきたりとかあると思うのですが、あれを想像してもらえるとOKです。

※1. 今回作ってみたのはBot API Trialの方のアカウントです。Business Connectの詳細については公式ページを参考にしてください。
※2. LINE@はBot API Trial側に含まれるようです。

その他の情報

複数人でBotとトークする

できないようです。
まだなのか将来的にも無いのかはわかりませんが、公式アカウント的な振る舞いをするので、複数人がいるトークに招待しても、グループに入れても参加してくれませんでした。

利用条件

詳細な日付は調べていませんが、昔は10000人に限りこのLINE Bot Trial Accountが登録できたという状況だったようですが、現在は基本的にLINEのアカウントさえ持っていれば試用可能です。

料金

料金については、今のところ公表されておらず、まだトライアル段階です。ただトライアルのため、Botとの友だち数の上限が50人までになっているようです。 ただ、ビジネス利用で法人アカウントに限り、BOT API Trial Accountの制限解除プログラムに登録できるようで、デフォルトで友だち数上限が5000人まで可能で、それ以上の制限解除は応相談のようです。（料金もそこで決まる？）
ただ、プログラムには審査があるようなので、そこは１つのハードルになりそうです。
https://feedback.line.me/enquete/public/915-RRUi5HII

Heroku Add-onのProcess SchedulerでAPI Keyを変更する方法

久しぶりの更新ですが、ショートにメモ。

先日Herokuに作成しているアカウントのパスワードを変更したらHeroku API Key（以降、API Key）の値も変わる仕組みらしく、Heroku Add-onのProcess Scheduler から [<Project Name>] Failure to scale web process type という件名のメールが送られてきました。（Process Schedulerが何者なのかは今回は割愛します。）

メール本文には、さらに

Process Scheduler failed to scale the web process type for your application shirachan from to . The following error occurred : Invalid credentials provided.

This error means the API key you provided is no longer valid. This is the case when you change your Heroku's account password.
To resolve this error, you must connect on Process Scheduler web interface and change your API Token in the settings panel.

という内容が親切にも書いてくれていたので、不適切にAPI Keyが設定されてしまっているとのことでした。

ただ、このProcess Schedulerの画面からAPI Keyの設定を編集するリンクがとても気づきにくかったので、ご紹介。

Heroku Add-ons → Process Scheduler画面

Process Schedulerを使っているならば説明しなくてもいいとは思いますが、一応。
下の画像の赤く囲ったリンクから、Process Schedulerの設定画面にいけます。

f:id:shirakiya:20160322095833p:plain

Process Scheduler → API Keyの設定画面

今回めっちゃ苦労したのは、下の画像で歯車のアイコンが見つけられなかったことでした。（あまりコントラストがはっきりしているディスプレイを使っていなかったというのも相まって見つけづらかったです。）

f:id:shirakiya:20160322100532p:plain

この歯車をクリックすれば、以下に例示するAPI Keyを設定できる画面にいけます。

f:id:shirakiya:20160322101057p:plain

いやー見つけられなかった自分もアレかなとは思いますが、いいディスプレイを使っているユーザーばかりではないので、こういったUIは考えないといけないですね！
デザインは難しい…。