AWS App RunenrでLINE bot開発ハンズオン

この資料は【ハンズオン】AWS App RunnerでLINE Bot入門【BOT AWARDS 2024】内のハンズオンパートの手順について解説します。

AWSを使ってアプリケーションを手軽に動かす方法を知っていただき、BOT AWARDの作品作りに活かしていただければと思います。

システム構成

今回のハンズオンの最終的なシステム構成は以下の画像の通りです。

最初のステップではElastic Container Registry(ECR)にあるコンテナイメージを使って、App Runnerにアプリケーションをデプロイする環境を構築し、オウム返しを行います。

Messaging APIのチャネルシークレットとアクセストークンはSystems Managerの機能であるParameter Storeに保存し、App Runner上で動作しているアプリケーションから呼び出します。

次のステップではCodeCommit、CodeBuildを使ったCI/CD環境をCodePipelineで構築します。

最後のステップでは、Botのコードを変更してCodeCommitにプッシュすることでDynamoDBを使ったTodoボットにアップデートしていきます。

以上の構成になりますが、全部一から手作業で構築すると複雑なので、簡略化させるためにAWS CDKを使用してアプリケーションを構築していきます。また、CDKを使った操作やCodeCommitへのコードのPushなどはAWSのオンラインIDEであるCloud9を使用します。

全体の完成像を紹介したところで、次のページから環境構築を進めていきます。

今回のハンズオンの環境構築をやっていきます。

なお、リージョン違いでのトラブルを防ぐためAWSの作業はすべてap-northeast-1(東京リージョン)で行います

事前準備

LINE Developersアカウント
AWSアカウント(AdministratorAccessポリシーが付与されたIAMユーザーが必要です。まだ作成されてない方はhttps://aws.amazon.com/jp/register-flow/ を参考に登録してください)

Messaging APIのチャネルを作成

まずはLINE Botを作るために必要なMessaging APIのチャネルを作成します。

以下のURLを参考にチャネルを作成します。

https://developers.line.biz/ja/docs/messaging-api/getting-started/#using-console

チャネルを作成したらチャネルシークレットとチャネルアクセストークンをコピーしてどこかにメモしておきます。

チャネルシークレットは「チャネル基本設定」タブで確認できます。

チャネルアクセストークンは「Messaging API設定」タブで確認できます。

IAMユーザーを作成(ルートアカウントの場合)

AWSでの作業を進める前に今回のハンズオンを進めるために必要な権限が付与されたIAMユーザーを作成します。後の手順にあるCloud9からCodeCommitのレポジトリにコードをPushするためにIAMユーザーを用意する必要があります。

以下のURLでIAMユーザーのコンソールを開きます。

https://us-east-1.console.aws.amazon.com/iam/home#/users

ユーザー一覧の右上にある「ユーザーの作成」をクリックしてIAMユーザーを作成します。

ユーザー名は「line-apprunner-hands-on」とし、「AWS マネジメントコンソールへのユーザーアクセスを提供する」のチェックボックスにチェックを入れてIAMユーザーのアカウントを作成します。

チェックボックスをクリックしたときに展開される画面で以下の設定を行います。

ユーザータイプ：IAMユーザーを作成します(Identity Centerを有効にしていない場合はこの選択項目は出てきません)
コンソールパスワード：ユーザーのパスワードを設定します(自動生成でもカスタムパスワードでもどちらでも結構です)

許可の設定では「ポリシーを直接アタッチする」を選択して、「AdministratorAccess」を選択します。

設定内容を確認し、問題なければ「ユーザーの作成」をクリックします。

作成されたユーザーのサインインURL、ユーザー名、パスワードをメモをとるかCSVファイルをダウンロードします。画面を閉じるとパスワードが確認できないので忘れずにメモをしておきましょう。

メモを取ったら一度サインアウトをします。

サインアウトをしたらメモを取ったサインインURLで再びサインインを行います。サインイン後、右上のユーザー名をクリックしたときにAWSのアカウントIDと作成したIAMユーザー名が表示されていれば今回の作業アカウントの設定は完了です。

パラメーターストアを設定

Systems Managerの機能の一つでアプリケーションに必要なパラメータを管理するパラメーターストアというものがあります。この機能を使用することでAWS上で動作しているアプリケーションでAPIキーのようなシークレット情報をアプリケーション側で直接設定することなく一括管理をすることができます。

以下のURLからパラメーターストアのコンソールを開きます

https://ap-northeast-1.console.aws.amazon.com/systems-manager/parameters?region=ap-northeast-1#

コンソールを開いたら「パラメータの作成」をクリックします。

Messaging APIのチャネルを作成したときにコピーしたチャネルシークレットをパラメータに設定します。

名前：/linebot-apprunner-handson/CHANNEL_SECRET
データ型：text
値：Messaging APIのチャネルシークレット

同様にメモしておいたアクセストークンも設定します。

名前：/linebot-apprunner-handson/CHANNEL_TOKEN
データ型：text
値：Messaging APIのアクセストークンを設定します

Cloud9を構築する

続いて今回の開発環境であるCloud9を構築していきます。

以下のURLでCloudShellを開きます。

https://ap-northeast-1.console.aws.amazon.com/cloudshell/home?region=ap-northeast-1#

以下のコマンドを実行し、Cloud9の環境を構築していきます。作成には2、3分程度かかります。

git clone https://github.com/aws-samples/cloud9-setup-for-prototyping
cd cloud9-setup-for-prototyping
./bin/bootstrap

コマンドで環境構築が実行されて以下のスクショのように最後に「Done！」と表示されたらCloud9は正常に立ち上がっています。

以下のURLでCloud9のコンソールを開きます。

https://ap-northeast-1.console.aws.amazon.com/cloud9control/home?region=ap-northeast-1#/

「cloud9-for-prototyping」という名前の行にある「開く」をクリックしてCloud9の環境を立ち上げます。

Cloud9の実行環境が立ち上がったら、Cloud9の構築は完了です。今回構築したCloud9の環境は、30分何も操作が無いとインスタンスが自動で停止します。停止した場合はCloud9のコンソール画面からまた開き直すか、Cloud9の画面をリロードすればまた起動します。

ソースコードを用意

環境構築の最後は構築したCloud9にソースコードを用意してきます。

Cloud9のターミナルで以下のコマンドを実行し、今回のハンズオンで使用するソースコード一式をクローンします。

cd /home/ec2-user/environment/
git clone https://github.com/Miura55/line-bot-aws-app-runner-handson.git

以上で環境構築は完了です。次のパートからは実際にアプリケーションのデプロイを進めていきます。

最初のステップはECRとApp Runnerを使った最小構成を構築してLINE BotのHelloWorldであるオウム返しボットを用意します。

ECRレポジトリを作成

今回のApp Runnerのアプリケーションに使うコンテナイメージを保存するECRのレポジトリを用意します。

その前にCDKを使う準備をします。Cloud9のターミナルで以下のコマンドを実行し、CDKの依存パッケージをインストールします。

cd /home/ec2-user/environment/line-bot-aws-app-runner-handson/cdk
npm install

今回初めてCDKを使う場合は以下のコマンドを実行し、CDKをデプロイする環境を準備するプロセス(Bootstrap)を行います。すでにデプロイ先の環境でBootstrapを実行している場合はこのコマンドは実行不要です。

cdk bootstrap

Bootstrapが完了したら、以下のコマンドを実行しECRのレポジトリを作成します。

cdk deploy HandsonDeployStack

途中で Do you wish to deploy these changes (y/n)? と聞かれた場合は構築されるサービスの内容を確認して、 y と入力しデプロイ作業を実行します。

しばらくして、以下のようにアウトプットと実行時間が表示されたらECRの作成は正常に完了しています。

Outputs:
HandsonDeployStack.ExportsOutputFnGetAttEcrRepository4D7B3EE1Arn21868DE8 = arn:aws:ecr:ap-northeast-1:123456789012:repository/line-bot-hands-on
HandsonDeployStack.ExportsOutputRefEcrRepository4D7B3EE140E01346 = line-bot-hands-on
Stack ARN:
arn:aws:cloudformation:ap-northeast-1:123456789012:stack/HandsonDeployStack/6d957bc0-e77f-11ee-9e4d-0ae887ef037d

✨  Total time: 48.86s

Dockerイメージをビルド

ECRにPushするDockerイメージをビルドしていきます。

Cloud9のターミナルで以下のコマンドを実行して、イメージをビルドします。

cd /home/ec2-user/environment/line-bot-aws-app-runner-handson/app
docker build -t line-bot-hands-on .

ビルドが終わったら簡単な動作確認をします。以下のコマンドでコンテナを立ち上げます。

docker run --rm -d --name line-bot-hands-on -p 8080:8080 --env-file ../sample.env line-bot-hands-on

動作確認

立ち上げたら以下のコマンドを実行して、コンテナで起動しているアプリケーションの動作を確認します

curl http://localhost:8080/health

実行後、レスポンスとして OK が返されたらアプリケーションは正常に動作しています。

更にアプリケーション側のログを確認するために以下のコマンドを実行します。

docker logs line-bot-hands-on

以下のようなログが出力されていれば、コンテナのアプリケーションと疎通できていることが確認できます。App Runnerでもこの /health のパスでヘルスチェック(アプリケーションが正常に実行できるか確認すること)を行うようにしています。

Server is running...:8080
2024/03/21 14:14:19 Health check

以上の確認ができたらコンテナの動作確認は完了なので、以下のコマンドでコンテナを止めます。

docker stop line-bot-hands-on

ECRにイメージをPushする

Cloud9のターミナルで以下のコマンドを実行してECRにログインします。

AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)
aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com

ログインを行い、 Login Succeeded と表示されればECRへイメージをPushするための認証は通ってます。

以下のURLでECRのプライベートレポジトリのコンソール画面を開きます。

https://ap-northeast-1.console.aws.amazon.com/ecr/private-registry/repositories?region=ap-northeast-1

コンソール画面から「line-bot-hands-on」の行にあるURIをコピーして、メモしておきます。

以下のコマンドを実行し、ECRレポジトリにPushできるようにタグを付けます。

docker tag line-bot-hands-on 【メモしたDockerイメージのURI】

以下のコマンドを実行し、DockerイメージをPushします。

docker push【メモしたDockerイメージのURI】

ECRのコンソールから「line-bot-hands-on」のレポジトリを開いたときに以下の通り一覧にイメージが表示されていればPushは正常に完了しています。

App Runnerのサービス構築

ECRが用意できたところでApp Runnerで動かすアプリケーションをデプロイしていきます。以下のコマンドを実行してApp Runnerのアプリケーションを構築していきます。

cd /home/ec2-user/environment/line-bot-aws-app-runner-handson/cdk
cdk deploy HandsonAppStack

途中で Do you wish to deploy these changes (y/n)? と聞かれた場合は構築されるサービスの内容を確認して、 y と入力しデプロイ作業を実行します。デプロイが完了するまでに3,4分時間がかかります。

デプロイが完了すると以下の通りApp Runnerで構築されたアプリケーションのURLが HandsonAppStack.AppRunnerServiceUrl に出力されます。このサービスURLがこの後の手順で必要になるのでメモしておきます。

Outputs:
HandsonAppStack.AppRunnerServiceUrl = https://sampleapp.ap-northeast-1.awsapprunner.com
Stack ARN:
arn:aws:cloudformation:ap-northeast-1:123456789012:stack/HandsonAppStack/dc6e4870-e7a1-11ee-9957-0e2f96b4f797

✨  Total time: 200.56s

ターミナルでの動作確認

試しにアプリケーションがデプロイされているか確認するために、ビルドした後の動作確認したときと同様に以下のコマンドで疎通確認をします。

curl【コピーしたサービスURL】/health

実行後、レスポンスとして OK が返されたらアプリケーションは正常に動作しています。

AWSでの確認

ターミナルで動作確認できたところでAWSのコンソールでも確認してみます。以下のURLでApp Runnerのコンソールを開きます。

https://ap-northeast-1.console.aws.amazon.com/apprunner/home?region=ap-northeast-1#/services

サービス一覧から「line-bot-hands-on」を開きます。

サービスの詳細画面の一番下にある「アプリケーションログ」を開きます。

ダイアログが開き、以下のようにヘルスチェックのログを確認することができます。

Webhook URLを設定

ここでLINEのMessaging APIのチャネル管理画面を開き、App RunnerのサービスURLをWebhook URLとして設定します。Webhook URLの設定は「Messaging API設定」タブにあります。

Webhook URLには【App RunnerのサービスURL】/callback を設定して、「更新」ボタンを入力します。

更新後に表示される「検証」ボタンをクリックするとWebhook URLの疎通確認を行います。以下のダイアログが表示されればWebhook URLは正常に動作しています。

Webhook URLの疎通確認ができたら、「Webhookの利用」を有効にしておきます。

続いてWebhookを使ってやり取りを行うために公式アカウントの機能を無効にします。Webhookの設定の下にある「LINE公式アカウント機能」の項目内の「応答メッセージ」の行にある「編集」のリンクをクリックします。

別タブで開かれる公式アカウントマネージャーの画面にある「応答メッセージ」と「あいさつメッセージ」をそれぞれ無効にします。無効にしたら公式アカウントマネージャーの画面はもう使用しないので、閉じても結構です。

動作確認

ここまでできたら、Messaging API 設定の画面の上部にあるQRコードをスキャンして、LINE Botを友だち追加します。

友だち追加後、以下のメッセージが表示されたらフォローイベントが機能しています

試しに何かテキストでメッセージを送ってみます。送信するとBotから送信したメッセージがそのまま返答されることを確認できます。

App Runnerのコンソール画面からも実際にメッセージを受け取っていることを確認できます。(ログを確認したタイミングによっては実際にメッセージを受け取っていることを確認できないこともあるので、表示範囲を調整してみてください)

これでオウム返しのボットが完成しました。ここからBotを改良して機能拡張させますが、その前に効率よくアプリケーションをデプロイするためにCI/CDの環境を次のステップで更新していきます。

無事にApp RunnerでLINE Botを動かせるようになりました。今回構築したApp RunnerのサービスはECRレポジトリにある latest タグでイメージがPushされたらそれをトリガーにデプロイが実行されます。

このままだと毎回デプロイするためにDockerコマンドを叩くのが手間なのと、ビルドしたDockerイメージはバージョン管理できるような状態にすると後で不具合が出たときに原因の切り分けが簡単になります。

そこでこのステップではDockerイメージを効率よくビルドできるようにCI/CD環境を構築します。

最終的にはCodeCommitにコードを保管し、そこに何かしらの変更がPushされたらDockerイメージがPushされるフローを構築していきます。

CI/CDを構築

早速CI/CDを構築していきます。CI/CDのサービス構成もCDKで記述しているので、以下のコマンドを実行して構築します。

cd /home/ec2-user/environment/line-bot-aws-app-runner-handson/cdk
cdk deploy HandsonPipelineStack

途中で Do you wish to deploy these changes (y/n)? と聞かれた場合は構築されるサービスの内容を確認して、 y と入力しデプロイ作業を実行します。

しばらくして、以下のようにアウトプットと実行時間が表示されたらECRの作成は正常に完了しています。

Stack ARN:
arn:aws:cloudformation:ap-northeast-1:123456789012:stack/HandsonPipelineStack/fb4d05e0-e82f-11ee-aa67-0e246cbcc5b9

✨  Total time: 137.84s

CodeCommitへコードをPushする

以下のURLでCodeCommitのコンソール画面を開きます。

https://ap-northeast-1.console.aws.amazon.com/codesuite/codecommit/repositories?region=ap-northeast-1

コンソール画面を開いたら、「line-bot-hands-on-【AWSのアカウントID】」の行にある「HTTPS」のクリップボードボタンをクリックしてレポジトリのリンクをクリックします。

Cloud9のエディタ画面に戻り、以下のコマンドでアプリケーションのディレクトリ内にGitレポジトリを設定します。

cd /home/ec2-user/environment/line-bot-aws-app-runner-handson/app
git init 
git config --global user.name "【任意のユーザー名】"
git config --global user.email "【任意のEメールアドレス】"
git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true
git remote add origin 【コピーしたレポジトリのURL】
git branch -m main

レポジトリの設定ができたら以下のコマンドでコミットとPushを行います。

git add .
git commit -am "First Commit"
git push origin main

これでCodeCommitのレポジトリにコードが登録されました。試しにCodeCommitのレポジトリの「line-bot-hands-on」を開くと、以下のスクショの通りBotのソースコード一式が登録されていることが確認できます。

CodePipelineの内容を確認

今回のハンズオンではCodeCommitのレポジトリに変更したファイルがPushされるとDockerイメージのビルドが実行されるようにCodePipelineを定義しています。

そこで、以下のURLでCodePipelineのコンソールを開きます。

https://ap-northeast-1.console.aws.amazon.com/codesuite/codepipeline/pipelines?region=ap-northeast-1

パイプラインの一覧から「line-bot-hands-on」をクリックして開きます。

パイプラインを開くとCodeCommitとCodeBuildのステータスが2つとも成功していることが確認できます。

実際にECRのレポジトリを確認するとCodeBuildでビルドしたイメージにlatestとコミットIDのタグがそれぞれ作成されていればCI/CDは正常に機能しています。

これでDockerイメージを自動でビルド・Pushするフローが出来上がり、ECRのイメージもバージョン管理ができるようになる仕組みが出来上がりました。ここまでできたら、最後のステップとしてDynamoDBを使ってユーザーが送信したメッセージの内容を記録、確認、削除できるTodoボットにアップデートしていきます。

コードの修正

ハンズオンの最後はDynamoDBをつなぎ込んでTodoボットにアップデートしていきます。

Cloud9のエディタで app/main.go を開いて215行目以降にある以下の5行のコメントアウトを解除します。コメントアウト解除には Ctrl+/ (MacであればCmd + /)を入力するとできます。

                        // timestamp := e.Timestamp
                        // replyMessages, err = todoController(sourceId, fmt.Sprint(timestamp), message.Text)
                        // if err != nil {
                        //         log.Println(err)
                        //         return
                        // }

以下の通りスラッシュが削除されていれば問題ありません。 Ctrl ＋ S(MacであればCmd ＋ S)で保存します。

                        timestamp := e.Timestamp
                        replyMessages, err = todoController(sourceId, fmt.Sprint(timestamp), message.Text)
                        if err != nil {
                                log.Println(err)
                                return
                        }

レポジトリに変更内容をPush

保存できたらCloud9のターミナルで以下のコマンドを実行して、CodeCommitのレポジトリに変更をコミットします。

cd /home/ec2-user/environment/line-bot-aws-app-runner-handson/app
git commit -am "TODOボットにアップデート"

コマンド実行後、以下の通り変更内容がコミットされたことを確認します。 main の隣の文字列がコミットIDで、この値がCodeBuildでビルドされるコンテナイメージのタグになります。

[main 21cc32b] "TODOボットにアップデート"
 1 file changed, 6 insertions(+), 6 deletions(-)

確認できたら変更内容をCodeCommitのレポジトリにPushします。

git push origin main

Push後CodePipelineを開くと以下の通りイメージのビルドが実行されていることが確認できます。このままビルドが完了するまで待ちます。

ビルドが完了すると今度はApp Runnerのサービス画面でECRのlatestタグのイメージが更新されたことを検知してデプロイが実行されていることが確認できます。これも5分程度かかるので、完了するまで待ちます。

動作確認

デプロイが完了したら動作確認です。先程友だち追加したボットに対して何かタスクをメッセージで投げてみます。その後Step1で作ったオウム返しとは違って、ボットから「登録しました」とリプライが来ます。これでデータベースに登録されている状態になります。

何個かメッセージを入力したあとに list とメッセージを送信するとボットに追加したタスクの一覧をテンプレートメッセージでリプライします。

このテンプレートメッセージはただ一覧を表示するだけではなく、完了したタスクのボタンをタップすると以下のようにDBからタスクのデータを削除したことをリプライします。

DynamoDBのテーブルも確認

実際にBotが保存したデータをDynamoDBでも確認します。

以下のURLでDynamoDBのコンソール画面を開きます。

https://ap-northeast-1.console.aws.amazon.com/dynamodbv2/home?region=ap-northeast-1#tables

テーブルの一覧にある line-bot-hands-on-todo を開きます。

「テーブルアイテムの探索」をクリックすると、以下の通りテーブル上にデータが保存されていることが確認できます。

以上でハンズオンの内容はすべて終了です。お疲れ様でした！

最後に片付け手順を解説します。

ここではハンズオン終了後の片付けの手順を解説します。今回構築したアプリケーションは放置していると毎月AWSの利用料金がかかるのでハンズオンを一通り試して不要になったら削除することをお勧めします。

CDKで構築したリソースの削除

CDKで構築したリソースは以下のコマンドで削除できます。

cd /home/ec2-user/environment/line-bot-aws-app-runner-handson/cdk
cdk destroy --all

以下の確認が表示されたら y を入力して、エンターキーを入力します。

Are you sure you want to delete: HandsonPipelineStack, HandsonAppStack, HandsonDeployStack (y/n)?

各スタックの削除を待ちます。最終的には以下の出力の通りすべてのスタックが削除されたらCDKのリソースの削除は完了です。

Cloud9を削除

以下のURLからCloud9のコンソール画面を開きます。

https://ap-northeast-1.console.aws.amazon.com/cloud9control/home?region=ap-northeast-1#/

cloud9-for-prototyping を選択して、「削除」をクリックします。

Bootstrapで作成されたスタックを削除

CDKのBootstrapのときに構築された「CDKToolkit」スタックも不要であれば削除します。

スタックを削除する前にS3バケットの中身を空にする必要があります。以下のURLでS3バケットのコンソール画面を開きます。

https://ap-northeast-1.console.aws.amazon.com/s3/buckets?region=ap-northeast-1

AWSのコンソールから cdk- から始まるバケットを選択して【空にする】を選択します。

削除の確認が表示されるので「完全に削除」と入力して、「空にする」をクリックします。

再びS3のコンソールを開き、同じバケットを選択して「削除」をクリックしてバケットを削除します。

以下のURLからCloudFormationのコンソール画面を開きます。

https://ap-northeast-1.console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/stacks?filteringText=&filteringStatus=active&viewNested=true

CloudFormationのコンソールから「CDKToolkit」をクリックします。

「削除」ボタンをクリックして削除を実行します。

「イベント」タブをクリックして以下の通り論理ID「CDKToolkit」のステータスが DELETE_COMPLETE になればスタックの削除は完了です。

パラメータストアの削除

パラメータストアに登録しているMessaging APIのアクセスキー、シークレットも削除します。

以下のURLをクリックしてパラメータストアのコンソールを開きます。

https://ap-northeast-1.console.aws.amazon.com/systems-manager/parameters?region=ap-northeast-1#

今回設定したパラメータを選択して、「削除」をクリックします。

以下のダイアログが表示されるので、「パラメーターの削除」をクリックします。

CloudWatch Logsを削除

今回構築したアプリケーションのログも削除します。ログを残し続けるとわずかに保存料金がかかるので不要であれば削除しておくと安全です。

以下のURLからロググループのコンソールを開きます。

https://ap-northeast-1.console.aws.amazon.com/cloudwatch/home?region=ap-northeast-1#logsV2:log-groups

今回構築したApp Runnerのサービス名「line-bot-hands-on」で絞り込むと以下の2つのグループが出力されるので選択して、「アクション→ロググループを削除」をクリックします。

以下のダイアログが表示されたら、「削除」をクリックします。

Messaging APIのチャネルを削除

Messaging APIのチャネルを開き、「チャネル基本設定」タブをクリックして画面の一番下にある「削除」ボタンをクリックします。

削除の確認ダイアログが表示されます。このチャネルに紐づけられたLINE公式アカウントを削除するため、「LINE Official Account Managerを表示」をクリックしてLINE Official Account Managerの管理画面を確認します。

削除の同意画面が表示されるので、注意事項を確認してチェックボックスにチェックを入れて、「アカウントを削除」をクリックします。

確認のダイアログが表示されるので、「削除」をクリックします。公式アカウントの一覧画面に戻れば、LINE公式アカウントとMessaging APIのチャネルは正常に削除できています。

以上で今回のハンズオンの片付けは完了です。

ここでは今回のハンズオンの関連トピックについて解説します。

Messaging APIのWebhookで使用したイベント

今回Messaging APIのWebhookではメッセージイベント以外にフォローイベントとPostBackイベントを導入しています。

フォローイベントは友だち追加を行ったときにリクエストされるイベントです。このイベントは新規で友だち追加された時のパターンとブロックした後に再度友だち追加された時の２パターンの状態を受け取ることができますが、この状態は完全な正確性を保証するものではないです。

https://developers.line.biz/ja/reference/messaging-api/#follow-event

ポストバックイベントは今回使用したテンプレートメッセージやフレックスメッセージなどに仕込まれたボタンを押すとそれを data プロパティに格納させることでメッセージとしては送信する必要なく、サーバーサイドでデータ処理をしたいときに使えます。今回はTodoリストのテンプレートメッセージに仕込んだボタンをタップした時のアクションとしてポストバックを採用しています。

https://developers.line.biz/ja/reference/messaging-api/#postback-action

LINE Botに使用した言語

今回、LINE BotはGo言語を使って記述しました。Googleが開発した静的型付け言語です。C言語のように型付けができて、かつPythonをはじめとしたスクリプト言語のように生産性が高く読みやすい言語設計になっています。そして、軽量で高速な処理を実現しているため、コンテナアプリケーションとの相性も抜群なので選定しました。

AWS CDKについて

AWS CDKはAWSのサービス構成をコードで定義するためのIaCツールです。IaCとはInfrastracture as Codeの略で、インフラ構成をコードベースで管理する仕組みをいいます。

クラウドのアプリケーション構成をモダンなプログラミング言語で定義することができて、最終的にはCloudFormationのテンプレートに変換されてデプロイをされます。

CDKを使って開発することで以下のようなメリットがあります。

AWSのサービス構成をアプリケーションのコードと一緒にGitレポジトリと一緒に管理することができる→チームメンバーがインフラベースからアプリケーション構成を理解しやすくなる
構成変更が出てきたときにあとから変更することが簡単にできる
別のAWS環境でも全く同じ構成でデプロイできるので再現性が高い

CDKはものすごくアップデートが頻繁に行われており、CDKを使う際には公式ドキュメントなどでキャッチアップをするといいです。

https://github.com/aws/aws-cdk/releases

AWS App Runnerについて

App Runnerにはデプロイのパターンが2つあります。一つはソースコードのレポジトリからデプロイするパターンと今回行ったビルドしたコンテナイメージデプロイするパターンと2つあります。

ソースコードのパターンは、Github、またはBitbucketのレポジトリを使って、コンテナが分からなくてもアプリケーションをデプロイをすることができます。対応している言語はNode.js、Python、Go、PHP、Rubyなどですが、対応言語によってはバージョンを細かく指定できないところがデメリットです。そのため、細かくバージョンを指定したい時やそもそも対応していない言語で構築したアプリケーションを動かしたい時にはコンテナイメージをデプロイする方が早いので、今回のハンズオンでは自由度が高めのコンテナイメージをデプロイするパターンを紹介しました。

CI/CDについて

今回はAWSのサービスで完結できるようにCodeCommitのレポジトリ、CodeBuildを組み合わせたCI/CDを構築していますが、CodeBuild自体はGithubやBitbucketのレポジトリと連携してビルドするフローを構築することもできます。GithubやBitbucketでソースコード管理している場合はCodeCommitのレポジトリから置き換えるのもありです。

DynamoDBのテーブル設計

今回使用したDynamoDBのテーブルは以下の設計になっています。LINEのユーザーIDをパーティションキー、Webhookのイベントで取得できるtimestampをソートキーにした複合キーになっています。Queryを使用してLINEのユーザーIDでデータを絞り込むことでユーザー毎のTodoリストを作成できるような構成になっています。

アトリビュート名	キー	型	説明
userId	partition	Text	LINEのユーザーID
timestamp	sort	Text	Webhookで受け取ったタイムスタンプ
text	-	Text	ユーザーが送信したタスク