お役立ち Twitter Bot を作りながら学ぶ AWS ドリル

~第 11 回 (完結回) IaC & CI/CD 入門しながら作るリマインダー Bot (後編)

2022-11-02
How to be a Developer

Author : 金澤 圭

ソリューションアーキテクト (SA) の金澤 (@ketancho) です。今年 1 月からスタートした AWS ドリル - Twitter Bot を作りながら学ぶ編、今月号でいよいよ完結回です。この記事を含め計 11 回と、ここまで長い連載記事を書いたのは初めてでしたので、感慨深いものがあります。連載中、Twitter Bot を構築していただいている読者の方もちらほら見受けられ、たまに実装中に手が滑って私にメンションを飛ばしてくださる方もいらっしゃり (嬉しい限りです !)、書いていてやりがいを感じられる連載になりました。1 年を通してご覧いただいた方には感謝を申し上げたいと思います。そして、この記事からご覧いただく方は、ぜひ AWS ドリル 第 1 回 からご覧いただけると嬉しいです。

さて、お役立ち Twitter Bot 編の完結回となる今月号では、前回の記事の最後で告知した通り、継続的インテグレーション (Continuous Integration : CI)、継続的デプロイメント (Continuous Deployment : CD) な仕組みを導入していただきます。

先ほど完結回と書きましたが、読者の皆さまにとってはここがスタートラインで、ぜひ皆さまのオリジナルな Twitter Bot を開発し、運用していただきたいと考えています。運用するにあたって、継続的に機能改善をすることになると思いますが、その際にこの CI/CD の仕組みがあると、とても効率よくその改善を進められると思います。

また、皆さまの日々の業務の中でも、CI/CD な仕組みが必要になるシーンはよくあると思っており、その素振りの意味も込めてぜひ挑戦していただきたいトピックになります。この連載の最初に掲げた目標は「AWS ドリルを通して “手に馴染んだ” AWS サービスを増やしてもらいたい」です。ぜひ、AWS ドリルで得た知見を、皆さまの日々の業務にもお役立ていただければ幸いです。

この連載記事のその他の記事はこちら

選択
  • 選択
  • 第 1 回 おはよう Bot 編
  • 第 2 回 昔書いた記事の宣伝 Bot 編
  • 第 3 回 リファクタリング & 曜日ごとのツイート 編
  • 第 4 回 新章突入 ! 気になるワード検索 & 通知 Bot 編
  • 第 5 回 皆さまの代わりに英語でツイートしておくよ Bot 編
  • 第 6 回 AWS Step Functions を使って Well-being Bot を作ろう ! (前編)
  • 第 7 回 AWS Step Functions を使って Well-being Bot を作ろう ! (後編)
  • 第 8 回 - 総集編 & 夏休みの自由研究のすすめ
  • 第 9 回 - IaC 入門しながら作るリマインダー Bot (前編)
  • 第 10 回 - IaC 入門しながら作るリマインダー Bot (中編)
  • 完結回 - IaC & CI/CD 入門しながら作るリマインダー Bot (後編)

このクラウドレシピ (ハンズオン記事) を無料でお試しいただけます »

毎月提供されるクラウドレシピのアップデート情報とともに、クレジットコードを受け取ることができます。 


1. この記事で作る Bot の機能と、とりあげる AWS サービス・機能

今回の記事でも前々回、前回に引き続き、「あとで読む」と書いたツイートに対して、「本当に読んだ ?」とリマインダーする Bot をお題として取り上げます。この記事は、これまでの作業が済んでいることを前提としますので、もし未実施の方は、まずは AWS ドリル 第 9 回, AWS ドリル 第 10 回 の内容をご実施いただいた上で、この記事に戻ってきていただければと思います。

前回までのリマインダー Bot ですが、実はほぼ完成しておりまして、下記のような実装になっているはずです。

  • 毎日 0 時過ぎに、「あとで読む」ツイートを検索する
    • 前日のツイートを検索し、「あとで読む」を含むツイート一覧を取得する
    • そのツイート ID をデータベースに格納する
    • リマインダするタイミング (日時) は 14 日後 になるようにセットする
    • ★ ただし、テストをしやすくするために、現在は一時的に 1 日後 になるようにセットしている
  • 毎日 12 時に対象のツイートに対してメンションする
    • データベースを検索し、その当日にリマインドすべきツイートを取得する
    • 該当するツイートがあった場合は、「本当にあとで読みましたか ?」とメンションを送る


この記事では★の部分を変更する実装を行います。とても簡単な作業なはずですが、完結回ということもあり、この変更作業でミスをするのではないかと急に不安になってきました。ソースコードの修正をミスしてしまうかもしれないですし、デプロイ作業を誤ってしまうかも、とドキドキしています。

そこで、CI/CD のパイプラインを作り、

  • コードを Git 管理し、ミスがないかをコードレビューしてもらえるようにする
  • 問題ないと承認してもらったら、以後のデプロイ作業は手動ではなく、自動で行われるようにする

という世界を目指したいと思います。今回の記事の内容を実装いただくと、下記のような構成になります。

そして、今回の記事では下記の 3 つのサービスが AWS ドリル初登場になります。これまでの記事同様、詳細は具体的な作業を通じて理解を深めていただこうと思うのですが、最初に各 AWS サービスの簡単な紹介だけ行おうと思います。

AWS CodeCommit
フルマネージドなソースコード管理サービス。スケーラブルでセキュア、既存の Git ツールともシームレスに連携可能。
月々のアクティブユーザー数、API リクエスト数、利用容量による課金体系。

AWS CodeBuild
ソースコードをコンパイル、テスト実行し、デプロイ可能なソフトウェアパッケージを作成できるフルマネージド型のビルドサービス。CodeBuild を用いることで、都度ビルド用のサーバーをプロビジョニングされるので、ビルドのためのサーバーを管理・維持する必要がなくなる。利用した分数のみのお支払いとなる。

AWS CodePipeline
フルマネージドな継続的デリバリーサービス。ソースコードの変更をトリガに、ビルド、デプロイといった一連の流れを自動的に実行する。アクティブなパイプライン数で料金が決まる。


今回の記事では下記の流れで開発を進めていきます。

  • 今回の開発、および Code サービス群を使うための事前準備
  • Code サービス群の設定を行い、CI/CD パイプラインを構築する
  • ソースコードを修正し、CI/CD パイプライン経由でリマインド Bot をアップデートする

これまでと比べるとソースコードの修正は軽微なのですが、新しいサービスが 3 つも登場するので内容盛りだくさんになります。ひとつひとつ実践を通して、手に馴染ませていっていただければと思います。それではやっていきましょう !


2. 前提知識と事前準備

それでは Code サービス群を使っていく前に、前提知識の紹介と事前準備をしていきます。

まず、前提知識についてです。今回の記事ではバージョン管理システムのひとつである Git を使っていきます。コマンドは全てコピペできる形にしていますので、初めて使う方でもドリルは問題なく進められるようにしてあります。とはいえ、基本的な部分はぜひご理解いただいた方がよいと思いますので、「Git 基本」や「Git 使い方」と検索していただき、はじめの一歩の部分までご理解いただいてから、今回のドリルを進めていただくことをおすすめします。

続いて、事前準備を進めていきます。これまで編集してきた template.yaml を修正する必要がありますので、今回も AWS Cloud9 環境を立ち上げていきましょう。

AWS Cloud9 が利用できない場合、こちらのブログ をご参考に AWS IDE Toolkits または AWS CloudShell をご利用ください。

AWS Cloud9 から AWS IDE Toolkits または AWS CloudShell に移行する方法 »

2-1. AWS Cloud9 環境の再起動

前々回、前回に引き続き、AWS Cloud9 を使っていきます。前々回の記事で作成した環境をそのまま使うので、既存の環境を再開させていきます。

AWS Cloud9 のホーム画面 に移動すると、このような状態になっていると思います。こちらの「Open IDE」ボタンをクリックしましょう。前回の作業から間が空いている場合、“EC2 instance is stopped. Attempting to start instance...” というメッセージが出て少しお待ちいただく形になります。

クリックすると拡大します

2-2. template.yaml を修正し、Lambda 関数のランタイムを修正する。

AWS Cloud9 の環境が立ち上がりましたら、template.yaml を修正します。これまでの AWS ドリルでは Lambda 関数のランタイムとして Python 3.9 を利用してきたのですが、前々回、前回と AWS Cloud9 環境にデフォルトでインストールされている Python のバージョンに合わせて Python 3.7 に変更してきました。AWS SAM のビルドを AWS Cloud9 環境上で行うためこの変更をしたのでしたね。

今回の記事では AWS CodeBuild 環境上で AWS SAM のビルドを行うのですが、 この CodeBuild 環境には Python 3.9 がデフォルトで導入されておりますので、それにあわせて再度 Python 3.9 を用いる形に戻そうと思います。(実際の開発を行う際は、皆さまの使いたいランタイムに合わせて環境側を変更する (AWS Cloud9 にランタイムをインストールする、CodeBuild 環境のイメージをアップデートする) 形になりますが、AWS ドリルの本質から外れる作業が増えてしまいますので、環境に合わせてランタイムを変更しています。)

復習も兼ねて前回のドリル終了時の template.yaml を全て再掲してみます。AWS Lambda リソースで Runtime を指定している 2 箇所で修正が必要になります。お手元の環境で修正し、保存してください。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  aws-drill-reminder-bot

Globals:
  Function:
    Timeout: 3

Resources:
  FindTweetsToRemindFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: twitter-bot-find-tweets-to-remind-function
      CodeUri: twitter-bot-find-tweets-to-remind-function/
      Handler: app.lambda_handler
      Runtime: python3.9 # 修正
      Policies:
        - AmazonSSMReadOnlyAccess
        - AmazonDynamoDBFullAccess
      Events:
        FindTweetsToRemindEvent:
          Type: Schedule
          Properties:
            Schedule: 'cron(5 15 * * ? *)'
            Name: FindTweetsToRemindEvent
            Enabled: True
  SendReminderFunction:
    Type: AWS::Serverless::Function 
    Properties:
      FunctionName: twitter-bot-send-reminder-function
      CodeUri: twitter-bot-send-reminder-function/
      Handler: app.lambda_handler
      Runtime: python3.9 # 修正
      Policies:
        - AmazonSSMReadOnlyAccess
        - AmazonDynamoDBFullAccess
      Events:
        SendReminderEvent:
          Type: Schedule
          Properties:
            Schedule: 'cron(0 3 * * ? *)'
            Name: SendReminderEvent
            Enabled: True
  TweetsToRemindDynamoDbTbl:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: TweetsToRemindTable
      AttributeDefinitions:
        -
          AttributeName: "RemindDate"
          AttributeType: "S"
        -
          AttributeName: "TweetId"
          AttributeType: "S"
      KeySchema: 
        - 
          AttributeName: 'RemindDate'
          KeyType: 'HASH'
        - 
          AttributeName: 'TweetId'
          KeyType: 'RANGE'
      ProvisionedThroughput:
        ReadCapacityUnits: 1
        WriteCapacityUnits: 1

事前準備は以上になります。ここからは Code サービス群を使った CI/CD パイプラインの作成に入っていきます。


3. Code サービス群を活用し、CI/CD パイプラインを作成する

まずはソースコードを格納する AWS CodeCommit リポジトリを作成します。そして、そのリポジトリに格納されたソースコードを元にビルド&デプロイするための AWS CodeBuild の設定を進めます。最後に AWS CodeCommit リポジトリ (の master ブランチ) に変更があったときに、それをトリガーに AWS CodeBuild のビルドを走らせるパイプラインを AWS CodePipeline を使って定義していこうと思います。

3-1. AWS CodeCommit のディレクトリ作り、これまでのソースコードをプッシュする

まず、AWS CodeCommit のリポジトリを作成していきます。AWS CodeCommit のサービス画面 に移り、右上の「リポジトリの作成」をクリックしてください。

クリックすると拡大します

リポジトリ名に aws-drill-reminder-bot と入力し、 右下の「作成」をクリックしてください。

クリックすると拡大します

これで皆さまのプライベートリポジトリができあがりました。続いて、9 月号から作ってきたリマインダー Bot のソースコードをこの CodeCommit リポジトリに Push していきましょう。AWS Cloud9 環境に戻り、下記のコマンドを流してみてください。

cd ~/environment/aws-drill-reminder-bot/
git init
git add -A
git commit -m 'first commit'
git remote add origin https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/aws-drill-reminder-bot
git push -u origin master

もう一度 CodeCommit リポジトリに戻り画面を更新していただくと、ソースコードが Push されていることが確認できるはずです🎉

クリックすると拡大します

3-2. AWS CodeBuild の設定

続いて、AWS CodeBuild の設定をしていきましょう。まず、AWS CodeBuild を利用するためには「ビルド仕様ファイル」と呼ばれるファイルを作る必要があります。ビルド仕様ファイルは、ビルドプロセスで何をするのかを定義するものになります。詳細な書き方は こちらのドキュメント にまとまっているので、参照していただければと思います。

「ビルド仕様ファイル」と書くと難しそうに聞こえるのですが、基本的には今まで皆さまが実行していたコマンドをファイルに記載いただくだけ、と思っていただいて大丈夫です。それ以外にもビルドのための様々な機能があるのですが、今回のドリルではこれまでの「SAM ビルドしたあとに SAM デプロイしてね」をこのファイルに書いていけばいいだけです。

AWS Cloud9 の環境に戻り、aws-drill-reminder-bot フォルダの直下に buildspec.yaml ファイルを作成します。

cd ~/environment/aws-drill-reminder-bot/
touch buildspec.yaml

この buildspec.yaml が先程の「ビルド仕様ファイル」になります。buildspec.yaml を開き、下記の内容を記載します。

version: 0.2
phases:
  build:
    commands:
      - sam build
      - sam deploy --no-confirm-changeset --no-fail-on-empty-changeset

commands の部分にいつもの sam build sam deploy コマンドを書いているだけですね。(参考ドキュメントは こちら です。)

「ちょっと待って ! その見慣れないコマンドは何 _」と思われた方は最近の AWS ドリルを丁寧にやってくださっている方だと思います。ありがとうございます。詳細は sam deploy のドキュメント に記載があるのでこちらも確認頂ければと思うのですが、--no-confirm-changeset はこれまでのように変更点を表示して「デプロイしていい?」という確認をしないオプションです。--no-fail-on-empty-changeset は変更点がなくても失敗扱いにしないでね、というオプションになります。

buildspec.yaml ファイルの更新が終わりましたら、この変更も CodeCommit リポジトリに Push しましょう。AWS Cloud9 のターミナルで下記のコマンドを流してください。これで CodeBuild のための下準備が完了です。

git add -A
git commit -m 'add buildspec.yaml'
git push -u origin master

それでは、AWS CodeBuild プロジェクトを作成し、buildspec.yaml の指示に従ってビルドできるようにしていきましょう。まず、CodeBuild のページ に遷移し、「プロジェクトの作成」ボタンをクリックしてください。

プロジェクト名には aws-drill-reminder-bot-project と入力します。

クリックすると拡大します

続いて少し下の「ソース」の部分までスクロールし、下記の設定項目を入力/選択してください。

  • ソースプロバイダ : AWS CodeCommit
  • リポジトリ : aws-drill-reminder-bot
  • リファレンスタイプ : ブランチ
  • ブランチ : master

クリックすると拡大します

続いて、「環境」までスクロールし、下記の設定をしてください。

  • オペレーティングシステム : Amazon Linux 2
  • ランタイム : Standard
  • イメージ : aws/codebuild/amazonlinux2-x86_64-standard:4.0

クリックすると拡大します

他の設定についてはデフォルトのまま一番下までスクロールし、「ビルドプロジェクトを作成する」をクリックしてください。

クリックすると拡大します

CodeBuild プロジェクトの作成がおわりましたら、続いて CodeBuild プロジェクトに紐づく IAM ロールに AWS SAM のビルドやデプロイに必要な IAM ポリシーを追加していきます。

作成した CodeBuild プロジェクトの画面に遷移し、「ビルドの詳細」タブをクリックします。

クリックすると拡大します

下にスクロールすると「環境」エリアの中に「サービスロール」という項目があるので、こちらのリンクをクリックします。

クリックすると拡大します

CodeBuild プロジェクトに紐づく IAM ロールの画面に遷移しますので、今回は下記の IAM ポリシーを追加していきます。(本来、最小権限になるような IAM ポリシーを定義すべきですが、今回は標準で用意されている IAM ポリシーを使っていきます。)

  • AmazonS3FullAccess
  • AWSCloudFormationFullAccess
  • IAMFullAccess
  • AWSLambda_FullAccess
  • AmazonDynamoDBFullAccess
  • AmazonEventBridgeFullAccess

許可ポリシー」の右側にある「許可を追加」ボタンをクリックした後、「ポリシーをアタッチ」をクリックしてください。

クリックすると拡大します

検索窓に前述の IAM ポリシーの名前を入力し、エンターを押すと IAM ポリシーが絞り込まれるので、該当する IAM ポリシーの左側にチェックを入れてください。検索フィルターをクリアし、この作業を先程の6つの IAM ポリシーの分だけ繰り返してください。

全て終わりましたら右下の「ポリシーをアタッチ」をクリックしてください。

クリックすると拡大します

最終的にこちらのように設定できていれば OK です。

クリックすると拡大します

こちらで CodeBuild プロジェクトが完成です。CodeBuild プロジェクトの画面に戻り、早速「ビルドを開始」をクリックしてみましょう。

クリックすると拡大します

無事にビルドは成功しましたでしょうか ? リマインダー Bot としての機能には変化はないのですが、ランタイムが Python3.9 に変更された 2 つの Lambda 関数が作られている (元々の 2 つの関数に置き換わっている) はずです。

3-3. AWS CodePipeline の設定

それでは最後に AWS CodePipeline を設定し、CI/CD パイプラインを作っていきましょう。具体的には、これまで作成してきた CodeCommit リポジトリと CodeBuild プロジェクトが連携するようにし、CodeCommit リポジトリに新しいコードが Push されたら自動的に SAM ビルド&デプロイが行われるようにします。

まず、AWS CodePipeline のサービス画面 に遷移し、「パイプラインの作成」をクリックします。

パイプライン名を aws-drill-reminder-bot-pipeline とし、「次に」をクリックしてください。

クリックすると拡大します

ソースステージには下記の項目を設定し、

  • ソースプロバイダ : AWS CodeCommit
  • リポジトリ名 : aws-drill-reminder-bot
  • ブランチ名 : master

次に」をクリックします。

クリックすると拡大します

ビルドステージには下記の項目を設定し、

  • プロバイダーを構築する : AWS CodeBuild
  • プロジェクト名 : aws-drill-reminder-bot-project

次に」をクリックします。

クリックすると拡大します

続いてデプロイステージの設定を行う画面が出てきます。今回はビルドステージでビルドとデプロイをあわせて行っているので、右下の「導入段階をスキップ」をクリックします。

「省略してもよろしいですか ?」という確認が出てくるので、「スキップ」をクリックしてください。レビュー画面を下までスクロールし、「パイプラインを作成する」をクリックすれば設定が完了です。

パイプラインが完成すると自動的に初回実行が始まるのですがこちらは停止してしまって構いません。「実行を停止」ボタンをクリックし、その後「停止して中止」の方を選び、初回実行を停止してください。

以上で CI/CD パイプラインが完成しました🎉


4. コードを修正し、作成した CI/CD パイプラインのテストを行う

それでは作成した CI/CD パイプラインのテストも兼ねて、前回の最後に積み残しとした「1 日後ではなく、14 日後にリマインドする」という修正を行っていきましょう。

今回は、開発用の develop ブランチを作成し、そこに新しい機能の実装を追加していきます。実装が完了したら、develop ブランチから master ブランチにプルリクエストを送ります。それがマージされたタイミングで CI/CD パイプラインが動き出し、Lambda 関数をはじめとした AWS リソースに更新がかかる、といった流れで開発を進めます。

まず、新しく develop ブランチを作成します。AWS Cloud9 環境上で下記のコマンドを実行してください。

cd ~/environment/aws-drill-reminder-bot/
git branch develop
git checkout develop

続いて、今回の要件にあわせてプログラムを修正します。と言ってもとても簡単な修正で、twitter-bot-find-tweets-to-remind-function 配下の app.py を1行だけ修正します。

         tweet_text_id = matched_tweet['id']
         dynamodb_tweets_to_remind_tbl.put_item(
           Item = {
             # "RemindDate": (datetime.now() + timedelta(days=+1)).strftime('%Y%m%d'), # テストのために1日後の日付にする
             "RemindDate": (datetime.now() + timedelta(days=+14)).strftime('%Y%m%d'),
             "TweetId": tweet_text_id
           }
         )

修正が終わりましたらコミット & プッシュしていきましょう。

git add -A
git commit -m "Change RemindDate."
git push -u origin develop

ここまで完了しましたら、CodeCommit リポジトリの画面に戻りましょう。上部にブランチを選択するプルダウンがあるので、こちらから develop ブランチを選択します。

クリックすると拡大します

develop ブランチに遷移したら、「プルリクエストの作成」ボタンをクリックします。

クリックすると拡大します

タイトルを「リマインドするタイミングを 1 日後から 14 日後に変更します」とし、「プルリクエストの作成」をクリックしてください。

クリックすると拡大します

実務であればこのプルリクエストを別のメンバーにレビューしてもらうのですが、今回はこのままご自身でチェックしていきます。変更が自身の期待するものになっているかを確認していただき、「マージ」ボタンをクリックします。

クリックすると拡大します

マージ後にソースブランチ develop を削除しますか ?」のチェックを外し、「プルリクエストのマージ」ボタンをクリックします。

クリックすると拡大します

このあとすぐに CodePipeline の画面に遷移すると、パイプラインの実行が始まっていると思います。これはパイプライン実行のトリガーにした CodeCommit リポジトリの master ブランチにアップデートが入ったからです。

クリックすると拡大します

パイプラインを確認しながら少し待つと少しずつ実行が進み、こちらのように Build まで完了するはずです。

クリックすると拡大します

Lambda 関数 twitter-bot-find-tweets-to-remind-function を確認し、更新が反映されていれば成功です🎉 皆さまのお手元でもうまくいきましたでしょうか ?


5. 落ち穂拾い&参考情報& Next Action のすすめ

Code サービスを用いた CI/CD パイプラインの構築、いかがでしたでしょうか ? 初めて CI/CD パイプラインを構築された方も多くいらっしゃったと思いますので、ぜひ改めてどのような作業を進めてきたかを振り返っていただくことをおすすめします。関連する情報として、この記事では紹介できなかった CI/CD に関連する情報と、更に Code サービスへの学びを深める Next Step としての参考情報を紹介したいと思います。

まず落ち穂拾いからです。今回は皆さまに AWS CodeCommit, AWS CodeBuild, AWS CodePipeline を使って、ひとつひとつ CI/CD を構築していただきました。実は AWS CodeStar というサービスをご利用いただくことで、テンプレートから CI/CD の仕組みを作っていただくことが可能です。また、AWS SAM にも sam pipeline bootstrap / sam pipeline init という機能があり、CI/CD パイプラインを CLI で対話形式で作成していただくことができます。今回の記事でもこれらの機能を利用することを検討したのですが、初めて Code サービスを触る方も多く、これらのサービス・機能から始めてしまうと、裏側がブラックボックスになってしまう気がしました。これらのサービス・機能は便利なのでぜひ今後試してみていただきたいのですが、まずはそれを構成する要素を理解いただきたいと考え、各 Code サービスの設定をひとつひとつ行っていただきました。

続いて、Next Step としての参考情報です。今回は Code サービスを使って AWS SAM のビルド & デプロイを行う CI/CD パイプラインを作りましたが、それ以外のシーンでもお使いいただけます。特に今回は AWS CodeDeploy というデプロイに特化したサービスを使っていただくことができなかったので、この点も含め様々なパターンで Code サービスを使ってみていただきたいです。そこでおすすめなのが、AWS Hands-on for Beginners シリーズの Code サービス編です。

AWS Hands-on for Beginners - AWS Code サービス群を活用して、CI/CD のための構成を構築しよう!編 »

こちらは 4 つの Code シリーズサービスを動画形式で学んでいただくハンズオンです。今回のドリルとは異なり、デプロイ先を Amazon S3 バケットや Amazon EC2 インスタンスにするパターンの CI/CD パイプラインを構築していただきます。特に EC2 インスタンスにデプロイするパターンは、実際の業務でも多く登場すると思いますので、ぜひこちらもあわせてご実施いただき、学びを深めていただければ嬉しいです。

クリックすると拡大します

最後に、AWS ドリルを完走していただいた皆さまに Next Action のおすすめをしたいと思います。

ぜひこれまで作ってきた Twitter Bot を参考にして、皆さまのオリジナルな Bot を作ってみていただきたいです。これまでの Twitter Bot を機能改善するでもいいですし、「こんな Bot あったら便利そうだな」という案を温めている方はぜひそれを実装してみるというのもおすすめです。オリジナルなことをやる中であーでもないこーでもないと試行錯誤していただくのが、皆さまにとって一番力が付く方法だと思っています。その試行錯誤の中で「全部自分で実装するの大変だな・・・」と思うことがあれば、ぜひ AWS のサービスを眺めてみてください。そしてフィットしそうな AWS サービスが見つかりましたらぜひそれをお試しいただきたいです。そんな流れでこれからも新しい AWS サービスを使う機会を増やしていっていただければ嬉しいです。

オリジナルな Bot を作られた方は、ぜひ私まで教えていただければ嬉しいです🎉


6. まとめ

「お役立ち Twitter Bot を作りながら学ぶ AWS ドリル」連載の第 11 弾および完結号として、リマインダー Bot を作りながら IaC + CI/CD な仕組みを構築する方法をお届けしました。新たな AWS サービスとして Code シリーズの 3 サービスをお試しいただきました。基本的な使い方のみの紹介となりましたので、ぜひ振り返りに加えて記事の中では使わなかった機能も試しいただければと考えています。

そして、今月号で AWS ドリル Twitter Bot 編は完結となります。1 年間連載をさせていただきましたが、いかがでしたでしょうか ? 読者の皆さまからのやってみたコメントや温かい感想をたくさん頂けたおかげで (まだの方は今からでもホカホカなコメントお願いします😉) 最後まで走り切ることができました。また、この連載の裏では何名かの同僚に記事のレビューや磨き込みに毎回協力してもらっています。1 年間並走していただいたことを、この場を借りてお礼を申し上げたいと思います。

AWS ドリル Twitter Bot 編は、全 11 回の連載で、合計 15 の AWS サービス・機能を利用していただきました。実際に使っていただく中でお気に入りのサービス・機能は見つかりましたでしょうか ?


こう並べてみると改めてたくさんの AWS サービスを使ってきたなーと感慨深い気持ちでおります。AWS では 200 を超えるサービスを提供していますので、そういう意味だと 1 割にも満たないのですが、日頃お客様とお話しする中でよく話題に挙がるものを扱えていると思いますので、読者の皆さまの素振りとして、とてもよいストーリーにできたと自負しています。一気にやれば 2 日ほどで完走できる分量だと思いますので、近くに「AWS の勉強をし始めたい ! 」という方がいらっしゃいましたら、ぜひご紹介いただければと思います。

さて、AWS ドリル “Twitter Bot 編” は完結しますが、またいつか別の AWS ドリルを連載したいと思っています。皆さまのご感想・ご要望に加え、来年以降こんな連載があれば読んでみたい ! というご希望をぜひ頂きたいと思っています。#AWSウェブマガジン タグをつけてツイートしていただくか、DM を開放しておりますので、@ketancho まで直接投げつけていただいても構いません。ぜひお待ちしております🙏

それでは長きに渡り、ご愛読いただきありがとうございました ! 次の記事、次の連載でまたお会いしましょう🙌

この連載記事のその他の記事はこちら

選択
  • 選択
  • 第 1 回 おはよう Bot 編
  • 第 2 回 昔書いた記事の宣伝 Bot 編
  • 第 3 回 リファクタリング & 曜日ごとのツイート 編
  • 第 4 回 新章突入 ! 気になるワード検索 & 通知 Bot 編
  • 第 5 回 皆さまの代わりに英語でツイートしておくよ Bot 編
  • 第 6 回 AWS Step Functions を使って Well-being Bot を作ろう ! (前編)
  • 第 7 回 AWS Step Functions を使って Well-being Bot を作ろう ! (後編)
  • 第 8 回 - 総集編 & 夏休みの自由研究のすすめ
  • 第 9 回 - IaC 入門しながら作るリマインダー Bot (前編)
  • 第 10 回 - IaC 入門しながら作るリマインダー Bot (中編)
  • 完結回 - IaC & CI/CD 入門しながら作るリマインダー Bot (後編)

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者プロフィール

金澤 圭 @ketancho
アマゾン ウェブ サービス ジャパン合同会社
技術統括本部 ソリューションアーキテクト

サーバーレスが好きなソリューションアーキテクト。業種業界問わず、お客様のプロダクト開発をサポートさせていただいています。オンデマンドで視聴できるハンズオン「AWS Hands-on for Beginners」、実際にものづくりをしながら AWS を学ぶ「AWS ドリルシリーズ」を企画・推進しており、楽しく学べるコンテンツを日々考えています。好きなサービスは AWS Lambda、AWS Step Functions、Amazon Personalize で、好きな休日の過ごし方は娘ふたりと川の字になって昼寝👧👧と赤ん坊を抱っこしながらの散歩です👶

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する